Intervju: Matematikere foretrekkes til tunge IT-oppgaver

[thelomen]

Hvem er disse famøse "GUI-programmerne" som blir trekt frem som eksempel? Det kan uansett være krevende nok å programmere et kompleks GUI til å fungere riktig, være vedlikeholdbart og få testing og test-automasjon satt opp. Og det har ingenting med design å gjøre.

 

Forøvrig har jeg (heldigvis) aldri hatt et oppdrag der det ikke generelt forventes at alle kan jobbe både med GUI, backend, services og database. Alternativet er at du ender opp med spesialister som kun kan en ting og sitter med samme kodebasen over lang tid. Det fører nesten alltid til sære / dårligere løsninger, vanskeligere vedlikehold og større sårbarhet for utskiftinger.

[Del]

Heh, jeg brukte en mattestudent til gui-programmering i fjor. Funket fett

[Shruggie]

Hvem er disse famøse "GUI-programmerne" som blir trekt frem som eksempel? Det kan uansett være krevende nok å programmere et kompleks GUI til å fungere riktig, være vedlikeholdbart og få testing og test-automasjon satt opp. Og det har ingenting med design å gjøre.

 

Forøvrig har jeg (heldigvis) aldri hatt et oppdrag der det ikke generelt forventes at alle kan jobbe både med GUI, backend, services og database. Alternativet er at du ender opp med spesialister som kun kan en ting og sitter med samme kodebasen over lang tid. Det fører nesten alltid til sære / dårligere løsninger, vanskeligere vedlikehold og større sårbarhet for utskiftinger.

 

Da har du antageligvis jobbet med webprogrammering

[Skinney]

Skjønner ikke hvorfor folk skal dra frem GUI-programmering hele tiden da det å programmere GUI i seg selv ikke er vanskelig (med mindre du lager selve rammeverket). Selvfølgelig, alt kan være vanskelig å gjennomføre godt, men GUI-programmering i seg selv er ikke spesielt vanskelig. Til eksempel er vanligvis en del vanskeligere å lage ett program som skal sortere en liste alfabetisk ved bruk av flere tråder enn det er å lage gui'et som viser resultatet (hvis du da ikke skal vise frem linje for linje i 3D-flyby).

 

@Del: Joda, jeg jeg sier ikke at mattematikere IKKE kan programmere. Det jeg reagerer på er at i artikkelen virka det som om man måtte ha matte-bakgrunn for å drive med avansert programmering, som jo er fullstendig feil. Her på UiO har vi ett kurs som går ut på å lage vårt eget OS, som er en av de vanskeligste oppgavene du kan ta på deg, og det er flere av oss som har E i matte. Selvfølgelig vil en mattematiker klare å programmere bedre mattematiske formler, det betyr ikke at du er bedre egnet til å drive med avansert programmering (som, i min mening, er det som antydes i artikkelen). Jeg sier heller ikke at mattematikere ikke er i stand til avansert programmering, det finnes alltid noen som takler begge deler veldig greit, men det er langt ifra tilfellet alltid.

[Ozwald]

Problemet her er at det ikke er gitt en spesifikk definisjon på "avansert programmering". Jeg tviler veldig sterkt på at en matematiker er godt egnet til å designe og lage software i stor skala, som også kan betegnes som avansert programmering. At matematikere er flinke i problemløsning har jeg ingen tvil om, og at dette fører til at de klarer å løse problemer bedre enn andre programmerere har jeg heller ingen tvil om, sett at disse problemene er matematiske. Det jeg ikke er enig i, er å kalle det å løse en avansert matematisk oppgave med programmering avansert programmering; det er avansert matematikk.

 

Programmering er et verktøy, akkurat som en hammer. Hva er "avansert hamring"?

[Nornamor]

Det høres ut som professoren ikke er klar over at diverse algoritmefag er obligatorisk i mer eller mindre alle programmeringsutdanningsløp?Er det gitt at den gjennomsnittlige matematiker er bedre egnet til å beregne kjøretid enn den gjennomsnittlige informatiker?Enhver programmerer som kun har et minimum med algoritme-orientert programmering bak seg er klar over at nøstede algoritmer - eksempelvis en algoritme som itererer over et datasett, og som for hvert element itererer over hele datasettet på nytt (O(n^2) eller verre) - er forferdelig tidkrevende.....

 

Som numerisk matematiker kan jeg si at det er ikke dette han mener med "numeriske metoder", det du snakker om er nemmelig kjøretid på en gitt implementering. Det han snakker om er hvilken matematisk teori som ligger i bakhånd får å løse et aktuellt matematisk problem. Det er hva og ikke hvordan noe skal implementeres. For å ta et veldig enkelt eksempel: Å løse et stort (n=høyt tall) matematisk problem, en eller annen form for diffligning, med tilstrekkelig høy presisjon. Du kan da ende opp med å få en situasjon der Eulers metode, selv om den er implementert som O(n^2*log n) som trolig er det raskeste du han få den, vil ha en kjøretid på flere timer, mens en Runge-Kutta metode implementert som O(n^5) kan løse problemet på sekunder.

 

[Nornamor]

Og ja, som mange har pekt på så definerer artikkelen veldig dårlig hva som menes med "avansert programmering".... Implementering og systemutvikling er og forblir noe programmerere er veldig mye dyktigere til enn matematikere.

[Del]

Her på UiO har vi ett kurs som går ut på å lage vårt eget OS, som er en av de vanskeligste oppgavene du kan ta på deg, og det er flere av oss som har E i matte.

Da vil jeg varmt anbefale dere å anstrenge dere betydelig for å bedre mattekarakterene. Det kan fort utgjøre forskjellen på å få en utfordrende jobb, eller å få litt mindre inspirerende oppgaver.

Problemet her er at det ikke er gitt en spesifikk definisjon på "avansert programmering". Jeg tviler veldig sterkt på at en matematiker er godt egnet til å designe og lage software i stor skala, som også kan betegnes som avansert programmering.

Matematikere har et bedre grunnlag for dette enn de fleste (som ikke har direkte utdannelse i det). Matematikk og data har dype felles røtter. Programmering har et nærmere forhold til matematikken enn til noen annen vitenskap. Den første til å definere en digital computer var matematiker:

http://en.wikipedia.org/wiki/John_von_Neumann

Den som formaliserte algoritmer var matematiker:

http://en.wikipedia.org/wiki/Alan_Turing

men siden da har computer science og programmering utviklet seg til egne fag med rette. Så nei, det er ingen automatikk i at en god matematiker enkelt blir en god programmerer.

[Matsemann]

Er det gitt at den gjennomsnittlige matematiker er bedre egnet til å beregne kjøretid enn den gjennomsnittlige informatiker?

Det er ikke bare snakk om eksakte algoritmer her. Jeg tror jeg ville kunne implementert Dijkstras algoritme bedre enn en matematiker fordi jeg kan bruke min kunnskap om maskinvaren/programmeringsspråket og dermed redusert konstantleddet. Men det er ikke dette det er snakk om. Skal jeg skrive et program som beregner trykk over alt areal i et oljereservoar kan jeg enten naivt implementere en algoritme som løser det på veldig mange timer, eller la en matematiker sette opp et numerisk uttrykk som kan itereres over til man har god nok nøyaktighet på veldig mye kortere tid.

Dessuten kan man, for prosessor som er så kjøretidsintensive at selv 1% reduksjon i kjøretid er vesentlig, optimere kildekoden for plattformen man kjører på. Å operere med boolske verdier satt til true i Java krever færre prosessorticks enn verdier satt til false (eller var det omvendt?), og de aritmetiske operatorene + og - krever færre ticks enn operatorene * og /. For de fleste er disse forskjellene så minimale at det vil ikke være merkbart, men for trege algoritmer på uhyre store datasett kan det utgjøre en viss forskjell.

->

That's the other problem with micro-optimizations. You gotta ask youself, why am I doing the compiler's work? Something's wrong here.

- Jeff Atwood

[_dundun_]

Det er klart utdannede programmerere er bedre enn matematikere på "Implementering og systemutvikling" som det sies over her. Det skulle da bare mangle.

 

Problemet er bare at implementasjonen og utviklingen i de fleste tunge IT-prosjekter er den siste lille biten i et stort puslespill. Først skal man forstå problemet, så skal man løse det teoretisk, så skal man designe en IT-løsning som faktisk svarer til løsningen på problemet, og når alt dette er gjort begynner man å få bruk for de "rene" programmererene.

 

Om man setter koderne på jobben med en gang får man sikkert en programmeringsmessig flott løsning, men også gjerne en flott løsning som løser helt feil problem eller som løser problemet med en ekstremt effektivt implementert bruteforce-løsning som kunne vært modellert mye mye bedre av en matematiker.

 

Til de som snakker om å tweake på mikronivå for å tjene 1%; neineinei! Det finnes kanskje noen veldig få situasjoner der man må holde på sånn (men jeg er litt usikker på hvor - i tidskritiske applikasjoner er det jo ikke fart, men forutsigbarhet som er poenget). Jeg kan ikke se for meg hvor det ikke ville lønt seg å bruke pengene man bruker på slik optimalisering på bedre HW i stedet.

 

(Jeg er programmerer selv, men kjenner mine begrensninger).

[grusisalaten]

http://www.scott-a-s.com/cs-is-not-math/

 

 

[Shruggie]

Grunnen til at jeg valgte GUI som eksempel er at GUI-programmering rett og slett er totalt forskjellig fra algoritme-programmering. Noen kan begge deler, noen er sikkert like gode på begge deler, men det betyr ikke at det er det samme.

Og det skjønte du, men du valgte å skrive et innlegg fordi du kjedet deg eller følte deg pedantisk... Tsk tsk tsk...

[_dundun_]

http://www.scott-a-s...cs-is-not-math/

 

Bra artikkel som egentlig sier mye av det samme som artikkelen denne diskusjonen bygger på, bare fra et litt annet standpunkt.

 

> Those who claim that “computer science is math” generally have good intentions. They are usually responding to the notion that computer science is just programming, which is, of course, false. Anyone who has taught beginning programmers knows how difficult it is to convey to them that underneath all of the accidental complexities lies something fundamental. But it is still a gross simplification to call the entire discipline of computer science “math.” Related to math, foundations in math—sure. But after a while, it makes sense to group the theoretical foundations of computation along with the design and implementation itself. That grouping is computer science.

[Skinney]

Grunnen til at jeg valgte GUI som eksempel er at GUI-programmering rett og slett er totalt forskjellig fra algoritme-programmering. Noen kan begge deler, noen er sikkert like gode på begge deler, men det betyr ikke at det er det samme.

Og det skjønte du, men du valgte å skrive et innlegg fordi du kjedet deg eller følte deg pedantisk... Tsk tsk tsk...

 

GUI-Programmering består av å koble funksjoner/metoder til events, og disse funksjonene skal i utgangspunktet kalle en backend som utgjør en eller annen form for arbeid. Med andre ord setter du opp hendelser som skal utføres ved en gitt hendelser. Det er ikke annerledes eller vanskeligere fra annen programmering, bare kjedelig. Design av GUI derimot, er noe annet, men igjen, det er design og ikke programmering.

 

@Del: man har kun mattematikk første semester, etter det er det kun fokus på systemutviklingsfag, og det med rette. Vi går faget for å lage dataprogrammer, ikke for å løse mattematiske problemer. Skulle man bli ansatt til å lage ett finans-program, ja så skaffer man en mattematiker til å programere de nødvendige funksjonene som er direkte relatert til finans, resten kan utføres av folk som har fordypet seg i databaser, nettverk og eventuelle andre problemer som måtte svares på. Som sagt, jeg reagerer ikke på at mattematikere er flinke i programmering, for all del de har sin plass i ulike programmeringsprosjekter, det jeg reagerte på er at det virker som om du må ha en mattebakgrunn for å drive med "avansert programmering" som bare er tull.

[Shruggie]

GUI-programmering innebærer som regel design. Herregud, for noen pedanter....

[Skinney]

Til de som snakker om å tweake på mikronivå for å tjene 1%; neineinei! Det finnes kanskje noen veldig få situasjoner der man må holde på sånn (men jeg er litt usikker på hvor - i tidskritiske applikasjoner er det jo ikke fart, men forutsigbarhet som er poenget). Jeg kan ikke se for meg hvor det ikke ville lønt seg å bruke pengene man bruker på slik optimalisering på bedre HW i stedet.

 

(Jeg er programmerer selv, men kjenner mine begrensninger).

 

Jeg er enig med det du sier, men troooor det var snakk om å bruke det i en litte større skala. La oss si du skal løse ett sudoku brett. Du har en funksjon som skal sjekke om tallet 9 finnes på nåværende rad. Det er mye raskere å finne ut om rad[8] (altså, tall nr 9 i arrayen rad) er true, enn å finne ut om tallet 9 finnes i en array som representerer tallene på nåværende rad... Og den ytelsesforskjellen er VELDIG merkbar (skrev en sudoku løser som ett skoleprosjekt for noen måneder siden).

 

Selvfølgelig, her kunne sannsynligvis en mattematiker funnet en enda bedre løsning enn brute force metoden vi brukte, så i akkurat dette prosjektet hadde det nok vært bedre å bruke en mattematiker ja.

[Skinney]

GUI-programmering innebærer som regel design. Herregud, for noen pedanter....

 

Du må skille mellom programmering og design, det er to vidt forskjellige ting. På min nåværende jobb (lager web-løsninger) så har vi egne folk som designer GUI, mens vi implementerer det. Forskjellen ligger i at når du programmerer noe, så handler det om hvordan noe fungerer, ikke hvordan det ser ut (som er design).

 

Vi har en egen informatikk linje på UiO som er rettet mot design, og en egen rettet mot programmering. Det er også slik i konsulent-selskaper at de har egne designere.

 

Så nei, GUI-programmering og GUI-design er to forskjellige ting.

[Shruggie]

Sa jeg at GUI-programmering og Design var det samme? Nei, jeg sa at programmering innebærer design.

[Skinney]

Og jeg er uenig (med design regner jeg ikke med du tenker på hvordan du skal bygge opp koden, hvilke komponenter som hører sammen osv)

[_dundun_]

I større prosjekter bør også overordnet systemdesign være ferdig i god tid før den første linjen med kode skrives, akkurat som GUI-designet bør være ferdig lenge før man starter på GUI.

Endret 11. juni 2012 av kvasbo