mboost-dp1
SXC - Gokoroko
mazing (99) skrev:Hvis den fungerer acceptabelt, hvorfor så forbedre den? Sidder du også og laver custom quicksort implementeringer?
Det burde give sig selv hvor væsentlig en forbedring på blot 2% vil gøre en algoritme der måske skal køres tusind gange dagligt... Hvis jeg sad som udviklingsleder ville jeg sq godt nok kræve at samtlige algoritmer blev set igennem og optimeret til præcis det system de skulle anvendes i...
Coney (101) skrev:Det burde give sig selv hvor væsentlig en forbedring på blot 2% vil gøre en algoritme der måske skal køres tusind gange dagligt... Hvis jeg sad som udviklingsleder ville jeg sq godt nok kræve at samtlige algoritmer blev set igennem og optimeret til præcis det system de skulle anvendes i...
Og det var derfor jeg skrev "Hvis den fungerer acceptabelt". Optimering øger som regel kompleksiteten og det er derfor ikke noget som man umiddelbart vil have, medmindre det er nødvendigt.
KISS
Der er selvfølgeligt nogle få områder hvor performance er ekstremt vigtigt, som spiludvikling og embeded devices, men stadig her er det bedst at KISS og derefter profile og kun optimere de dele som har brug for det.
IMO selvfølgelig :)
mazing (102) skrev:Og det var derfor jeg skrev "Hvis den fungerer acceptabelt". Optimering øger som regel kompleksiteten og det er derfor ikke noget som man umiddelbart vil have, medmindre det er nødvendigt.
KISS
Der er selvfølgeligt nogle få områder hvor performance er ekstremt vigtigt, som spiludvikling og embeded devices, men stadig her er det bedst at KISS og derefter profile og kun optimere de dele som har brug for det.
IMO selvfølgelig :)
Det er rigtigt... Men et ordentlig design helt fra starten af, før implementeringen, vil kunne give det bedste fra begge måder...
Spørgsmålet er om det er relevant.Coney (101) skrev:Det burde give sig selv hvor væsentlig en forbedring på blot 2% vil gøre en algoritme der måske skal køres tusind gange dagligt... Hvis jeg sad som udviklingsleder ville jeg sq godt nok kræve at samtlige algoritmer blev set igennem og optimeret til præcis det system de skulle anvendes i...
At en algoritme er 1-2 sekunder langsommere i et GUI program til en slutbruger som skal administere et eller andet, er lige meget.
De optimeringer du snakker om er mest relevante i embedded software. Og vi kan altså stadigvæk ikke alle være bitnisser.
Coney (103) skrev:Det er rigtigt... Men et ordentlig design helt fra starten af, før implementeringen, vil kunne give det bedste fra begge måder...
Så sandt, men min erfaring med design siger også at der ikke findes en ting som hedder "perfekt design fra start" -- jeg har i hvert fald ikke oplevet det endnu ;) Ofte er djævlen i alle detaljerne..
mrF0x (97) skrev:
Ærlig talt - jeg kan forstå at skal der udvikles nye algoritmer - så er der god grund til at ha' dataloger i huset. Mit postulat er dog at i 9/10 tilfælde finder du nok en sorteringsalgoritme du kan bruge i det framework du arbejder op imod.
Der er ikke ret mange som sidder og opfinder nye algoritmer.
Men der er en del som vælger eksisterende algoritme fordi de forstår hvorvidt algoritmenten er god til deres problem.
Desværre er der også en del som bare vælger en tilfældig.
#optimering af quicksort
Jeg antager at det her ikke har noget med algoritmen som sådan at gøre, men udelukkende drejer sig om en effektiv implementering af algoritmen. Det er en anden problem stilling.
Hvorvidt det giver mening at lave den form for optimering afhænger af hvad koden skal bruges til.
Men det er efterhånden sjældent at det giver mening. Standarden idag er: skriv klar kode og lad compileren tage sig af optimeringen. På grund af hardware omkostninger versus software maintenance omkostninger.
Lowend embedded systemer som produceres i stort antal er naturligvis en af de mulige undtagelser.
Hvis man skal optimere er det ret vigtigt at gribe det systematisk an. Der er mange som har optimeret korrekt langsom kode til hurtig kode med fejl i.
Jeg antager at det her ikke har noget med algoritmen som sådan at gøre, men udelukkende drejer sig om en effektiv implementering af algoritmen. Det er en anden problem stilling.
Hvorvidt det giver mening at lave den form for optimering afhænger af hvad koden skal bruges til.
Men det er efterhånden sjældent at det giver mening. Standarden idag er: skriv klar kode og lad compileren tage sig af optimeringen. På grund af hardware omkostninger versus software maintenance omkostninger.
Lowend embedded systemer som produceres i stort antal er naturligvis en af de mulige undtagelser.
Hvis man skal optimere er det ret vigtigt at gribe det systematisk an. Der er mange som har optimeret korrekt langsom kode til hurtig kode med fejl i.
#108
Hvis det er fordi man tror at man kan optimere bedre end compileren er det næsten altid forkert.
Men der er tilfælde hvor man ved at tilgå hardware mere direkte kan få store performance gevindster.
I andre tilfælde har man brug for at have meget stram kontrol over hvordan koden tilgår memory (OS kernel stuff).
Men til sådan den helt almindelige desktop eller web app giver jeg helt ret.
Jeg hørte for nylig om nogen som sad og kæmpede med at portere et system til en ny hardware platform. Et system til at styre emergency response (det må være ambulancer og/eller politi). 250000 linier kode. Alle linier skrevet i assembler engang først i 80'erne.
Hvis det er fordi man tror at man kan optimere bedre end compileren er det næsten altid forkert.
Men der er tilfælde hvor man ved at tilgå hardware mere direkte kan få store performance gevindster.
I andre tilfælde har man brug for at have meget stram kontrol over hvordan koden tilgår memory (OS kernel stuff).
Men til sådan den helt almindelige desktop eller web app giver jeg helt ret.
Jeg hørte for nylig om nogen som sad og kæmpede med at portere et system til en ny hardware platform. Et system til at styre emergency response (det må være ambulancer og/eller politi). 250000 linier kode. Alle linier skrevet i assembler engang først i 80'erne.
arne_v (109) skrev:#108
Hvis det er fordi man tror at man kan optimere bedre end compileren er det næsten altid forkert.
Men der er tilfælde hvor man ved at tilgå hardware mere direkte kan få store performance gevindster.
I andre tilfælde har man brug for at have meget stram kontrol over hvordan koden tilgår memory (OS kernel stuff).
Men til sådan den helt almindelige desktop eller web app giver jeg helt ret.
Jeg hørte for nylig om nogen som sad og kæmpede med at portere et system til en ny hardware platform. Et system til at styre emergency response (det må være ambulancer og/eller politi). 250000 linier kode. Alle linier skrevet i assembler engang først i 80'erne.
Det er også en af de vigtigste faktorer idag, som du netop påpeger..
Hvor performance mindet bør man være, kontra læsbarhed.
Jeg kan kun give dig ret i at det er ti gange bedre at forstå din compiler. På den måde kan man bedre udnytte en compilers stærke egenskaber og undgå de dårlige.
Der er naturligvis forskel på god og dårligt skrevet kode og det bør ikke blive en sovepude at det ta'r compileren sig nok af..
Dog med nogle faste principper i f.eks. en kodestandard bør umiddelbar hardcore optimering på algoritme niveau slet ikke være nødvendigt.... Ihvertfald ikke med dagens udviklingsværktøjer.
Embedded er en helt anden snak.
Skulle jeg idag kode mod en embedded platform ville jeg nok vælge et mix af C og ASM, men altså på embeddet platform.
#96: Egon er ret god (jeg er selv på EUC Syd i Sønderborg). Han giver dig guiden for at du kan have et reference emne. Selv gjorde jeg følgende:
Læs opgaven (altså, hvad skal der opnås), prøv selv - hvis det fejler, så kig på guiden.
Tilgengæld har jeg ikke meget til overs for den "teoretiske" prøve - hvor kan du finde dit & dat i hvilken tab osv.. Det er fjollet. :-)
Læs opgaven (altså, hvad skal der opnås), prøv selv - hvis det fejler, så kig på guiden.
Tilgengæld har jeg ikke meget til overs for den "teoretiske" prøve - hvor kan du finde dit & dat i hvilken tab osv.. Det er fjollet. :-)
#81: arne_v
Forskellig erfaring, forskellig uddannelse, forskellige interesser gør et team stærkere.
Helt enig :o)
Det er vel de færreste der synes at alle områder er lige spændende og er lige god til alt.
Jeg har minimal interesse for at pille med hardware beskrivende sprog eller sidde og pille med compiler.
Formelle specifikationssprog og Computer grafik er min interesse :o)
#59: Windcape
Men jeg forstår ikke matematikken bag. Generelt ser jeg ikke nogen grund til at forstå matematikken bag ved, hvis man kan forstå hvordan man laver en implementering.
Enig til dels. Datamatikeren ikke behøver at forstå matematikken bag ved. hvis der indgår en datalog eller software ingeniør der har styr på det i dit udviklingsteam.
Nogen i dit team burde forstå det, for at kunne lave en passende løsning.
Vi er enig om at software er et formelt medium, ikke?
Er det så ikke passende at softwaren beskrives formelt?
F.eks. blev der tilført OCL til UML 2.0, som førhen var et uformelt grafisk specifikationssprog.
Måske gik det op for folkene i IBM at formalismen var nødvendigt i UML, som var abstrakt og for upræcist :o)
On topic:
Artiklen går ud på at virksomhederne der er medlem af ITEK i DI,
mangler folk med langvarige it-uddannelser. som ingeniører, dataloger og it-arkitekter.
Kunne vist heller ikke være en dårlig idé med at de søger folk med tværfaglig viden som Økonomi, Sundhedsvidenskab, Fysik, Kemi osv osv.
Men det er måske en delmængde af de folk der efterspørges?
Ikke alle arbejder med software det kræver advanceret matematisk forståelse.Stryder (113) skrev:Enig til dels. Datamatikeren ikke behøver at forstå matematikken bag ved. hvis der indgår en datalog eller software ingeniør der har styr på det i dit udviklingsteam.
Nogen i dit team burde forstå det, for at kunne lave en passende løsning.
Der er ikke meget mening i at være god til integralregning hvis man skal lave et børssystem. Eller en IM klient, browser, eller hvad som helst der kan relateret op med webudvikling (hvilket er ret meget i dag).
Jeg vil næsten vove at påstå at alt JEE og ASP.NET udvikling ikke kræver mere end folkeskole niveau af matematik.
#115: Windcape
Der er ikke meget mening i at være god til integralregning hvis man skal lave et børssystem
Det har du helt ret i.
Det er diskret matematik/formelle metoder man skal bruge til
det formål som jeg trods alt valgte at lære på mit diplom studie.
Faktisk meget sjovt at du nævner det, pga. der er faktisk
et børssystem, der er udviklet med formelle specifikationer.
Det er så ikke hardcore formelle metoder, hvor
alt skal bevises, men formal methods lite, som de fleste der beskæftiger sig med det i idustrien, vil sige er tilstrækkeligt.
Børs systemer må jo helst ikke crashe eller fejle på andre måder,
de er jo rimeligt missionskritiske.
Google efter TradeOne og "Recent Industrial Applications of VDM in Japan" hvis du er interesseret :o)
Det minder mig om at for nogle år siden, var der et firma der gik faliit pga. deres aktie pris og antal blev byttet om.
Beløbet husker jeg ikke, men princippet var at istedet for f.eks at 1 akties pris var 1000 kr, blev det af software fejl byttet om til 1000 aktiers pris var blevet til 1 kr.
Beklager, kan ikke henvise til nogle kilder hvor det skete;
det har været en ret stor omtale for nogle år siden.
#115: Windcape
Jeg vil næsten vove at påstå at alt JEE og ASP.NET udvikling ikke kræver mere end folkeskole niveau af matematik.
Diskret matematik er en del af det obligatoriske kurser og formelle metoder er videregående civilkurser som jeg valgte på mit diplomingeniør studie. Måske lidt svært for folk der kun
har forståelse for matematik undervist i folkeskolen.
Software er jo logiske systemer, hvor med formel logik ville kunne beskrive deres opførsel bedst.
#115: Windcape
Eller en IM klient, browser, eller hvad som helst der kan relateret op med webudvikling (hvilket er ret meget i dag).
Netteknologiske systemer indeholder jo som regel også samme slags kode back end, som desktop applikationerne.
Man oplever jo tit at de crasher, pga. uforudsete fejl som ikke er specificeret.
Men ja ok, det er ikke livstruende systemer, hvor folk dør eller går fallit, i tilfælde af fejl. Folk bliver blot irriteret over det er noget lort, andet sker der så ikke.
#115: Windcape
Ikke alle arbejder med software det kræver advanceret matematisk forståelse
Enig. Men når folk eller teams der ikke har forståelse for matematikken bagved, får et projekt hvor det netop ville være en passende løsning, så går det galt.
Ville man kunne skelne mellem om der er brug for det eller ej, hvis man ikke har kendskab til matematikken?
Ved matematik mener jeg diskret matematik og formelle metoder.
De fleste i software industrien har ikke kendskab det eller synes ikke at det er nødvendigt pga. økonomi.
Der er så også mange projekter der går død eller over budgettet.
Min personlige holdning er at hellere betale kassen for at tingene bliver lavet ordentligt og fejlfrit end at betale for et projekt der bliver aflyst eller et system der ikke virker.
Der er som at give folk et arbejde for at være beskæftiget og til
intet andet formål :D
Det er en kritik af managers, chefer, ledelsen osv. i software industrien, at man prøver at nedskære i alt og komme med et urealistisk bud for et projekt der gør at det går over budgettet
eller bliver aflyst. Også en kritik af klienterne der netop søger de absolut billigeste udbud.
Det er bare mig der spyr ild over at software industrien er fyldt med ignorante chefer og administrative folk, undskyld :D
At der er kun er få der udøver det, burde da ikke være en hindring i at lære det.
Ville da også være røvsygt og måske også uoverskueligt at komme tilbage til skolebænken 25 år efter man er startet med at arbejde,
eller firmaet skal betale svindende summer for at oplære personen i det, fordi det er gået op for de fleste folk i industrien at det ikke er så tosset en metode alligevel.
Software udviklingsopgaver burde ikke være som et slagtilbud i grønttorvet, hvor man går efter de billigste og
højtråbende. Det går ud over kvaliteten. og det går derfor ud over økonomien.
Surt at købe billige bananer for at finde ud af at de smager dårligt,
hvor man bagefter bliver nødt til at købe de dyrere alligevel :D
Det havde jo været billigere at købe den dyre banan fra starten set i helheden. Man kan selvfølgelig også være heldig ;)
Det er en evig kamp mellem kvalitet og kvantitet, hvor man dagen idag hælder mest til kvantitet.
Men ja, jeg kan godt se hvad du mener.
Man ville ikke bruge advanceret matematiske modeller for at lave et hundehus, men det er nødvendigt hvis man vil opbygge en skyskraber.
Nogle systemer er simple nok og overkill til at man bruger formelle metoder. Andre er gigantiske projekter som er uoverskueligt,
hvor det er stregt nødvendigt hvis man vil få projektet til at lykkedes.
Det ville da være hensigtsmæssigt at nogen i det team datamatikkeren indgår, er i standt til at skelne om der er brug for matematiske modeller eller ej i en given situation.
Men jeg ville netop have en finansøkonom til at lave formlerne og forklare dem til mig, i stedet for at skulle udarbejde dem selv.Stryder (116) skrev:
Det er diskret matematik/formelle metoder man skal bruge til
det formål som jeg trods alt valgte at lære på mit diplom studie.
Faktisk meget sjovt at du nævner det, pga. der er faktisk
et børssystem, der er udviklet med formelle specifikationer.
Jeg kan godt implementere formler jeg ikke forstår meningen med. Selve forståelsen for komplicerede formler lærer man i 9kl. / 1g.
Dertil er selve implementeringen utrolig vigtig som du også påpeger, hvor at det er meget vigtigt at have godt kendskab til udviklingsmetoder og test. At skrive en lang række unit-test før man implementere en given formel til f.eks. børs-software, ville jo være det bedste man kunne gøre.
Igen et punkt hvor en datamatiker har specialiseret på sin uddanelse, men hvor datalogen/ingenøren kun har overfladisk kendskab (medmindre de har lavet selvstudie).
Jeg synes man undervudere dette. Hvad god er en datalog som måske forstår matematikken, men skriver en invalid unit-test (eller slet ingen) så systemet ikke virker alligevel?
Matematik for mig er mere situationsbestemt end noget man bør bruge 3 år på at specialisere sig i. I stedet bør man specialisere sig i udviklingskompetancer, så man kan lave noget solidt håndværk fra dag 1.
#117: Windcape
Men jeg ville netop have en finansøkonom til at lave formlerne og forklare dem til mig, i stedet for at skulle udarbejde dem selv.
Yes yes, det skal finansøkonomet om alle omstændigheder.
Men hvad hvis man skulle lave et system til lægejournal?
Eller andre domæner hvor folk fatter hat af diskret matematik?
Folk kan ikke finde ud af at lave relationer mellem de forskellige ting i hans domæne med logiske formler.
Det burde være software udviklerens (eller konsulentens) opgave at beskrive relationer mellem de forskellige ting formelt og informelt for at validere om det man vil lave er det klienten vil have.
Altså ikke (nødvendigvis) om en given formel er korrekt, men
hvordan tingene hænger sammen i domænet og deraf hvordan softwaren skal opføre sig.
Nu siger jeg hvordan tingene BØR gøres, og ikke hvordan det gøres i praksis de fleste steder :P
Men ja, spørgsmålet er om datamatikeren har brug for at have fingerne nede i matematikken, så det bare kan overlades til dataloger eller civilingeniører, det skal jeg ikke kunne svare på.
#117: Windcape
Igen et punkt hvor en datamatiker har specialiseret på sin uddanelse, men hvor datalogen/ingenøren kun har overfladisk kendskab (medmindre de har lavet selvstudie).
Ej, ligesom din uddannelse specialiserer man sig også som
IT ingeniør både i diplom, civilbachelor og især i kandidat.
Det gør man også indenfor Datalogi.
Jeg har specialiseret mig i generel software udvikling for typiske applikationer og formelle metoder i min diplom og nu computer grafik og formelle metoder i min kandidat fordi jeg kan lide de områder.
Gider ikke at rode med management kurser eller hardware beskrivende sprog.
Det er der andre der kan gøre :o)
Der er da folk som netop er interesseret i de samme kurser som du har haft, og vælger at specialisere sig i det på mit universitet.
Jeg har flere venner der også læser/læste på diplom og kandidat på DTU som har en datamatiker uddannelse som baggrund.
Det datamatikeren datalogen og ingeniøren burde lave i et projekt,
er i de fleste tilfælde forskellige ting de skal koncentrere sig om?
Som du selv påpeger:
#117: Windcape
Hvad god er en datalog som måske forstår matematikken, men skriver en invalid unit-test (eller slet ingen) så systemet ikke virker alligevel?
Lige units testning er der ikke så meget ben i, det kan enhver software ingeniør også finde ud af at skrive.
(Jeg er også sikker på at datalogen kan finde ud af det).
Men ja, det var vel et eksempel på at der er nogle ting som datamatikeren fokuserer på og datalogen ikke gør det :)
Sæt datamatikeren eller software ingeniøren til at gøre det.
Datalogen behøver ikke at gøre det hele selv (det behøver datamatikeren eller software ingeniøren heller ikke).
#117: Windcape
Matematik for mig er mere situationsbestemt end noget man bør bruge 3 år på at specialisere sig i.
Det behøver man heller ikke, selvfølgelig kan man da godt hvis man elsker det :P
Et kursus i diskret matematik og et kursus i formelle metoder, så har man en god start.
#117: Windcape
I stedet bør man specialisere sig i udviklingskompetancer, så man kan lave noget solidt håndværk fra dag 1.
Ville hellere sige dag 180 eller 365, efter man har lært lidt relavant matematik :P
Jeg synes ikke det er hensigtsmæssigt at sige den ene uddannelse er bedre end den anden: Datamatiker
vs. Datalog (vs. Software Ingeniør). Det er forskellige emner der undervises i, hvor nogle af dem overlapper.
Også på helt forskellige niveauer.
Det er ligesom at samligne en byggetekniker med en civilingeniør i bygning.
Stryder (118) skrev:Jeg synes ikke det er hensigtsmæssigt at sige den ene uddannelse er bedre end den anden: Datamatiker
Jeg vil gerne: Datamatikeren er ren ferie. Niveauet trækkes ned så alle kan følge med og skolen kan tjene flere penge. Alle kan køre på cruisecontrol og stadig komme igennem. Hvis en datamatiker er bedre end en datalog (eller bare god i det hele taget) er det pga. datamatikerens egen interesse for stoffet, ifølge mine oplevelser.
Windcape (115) skrev:Ikke alle arbejder med software det kræver advanceret matematisk forståelse.
Der er ikke meget mening i at være god til integralregning hvis man skal lave et børssystem. Eller en IM klient, browser, eller hvad som helst der kan relateret op med webudvikling (hvilket er ret meget i dag).
Jeg vil næsten vove at påstå at alt JEE og ASP.NET udvikling ikke kræver mere end folkeskole niveau af matematik.
Der er jeg så uenig.
Lige så snart du skal skrive kode som ikke er totalt triviel, så er matematik særdeles nyttigt.
Og specielt da et børs system med realtime requirements og et hav af beregninger.
----
En anden måde at se på det er, at dem med andre naturvidenskabelige uddannelser end datalogi: rene matematikere, fysiskere, kemikere, non-IT ingeniører etc. ofte bliver lige så gode IT folk som dataloger. Den grundliggende matematiske tankegang er vigtigere end den specielle anvendelse på datalogiske problemer.
Windcape (117) skrev:Men jeg ville netop have en finansøkonom til at lave formlerne og forklare dem til mig, i stedet for at skulle udarbejde dem selv.
Jeg kan godt implementere formler jeg ikke forstår meningen med. Selve forståelsen for komplicerede formler lærer man i 9kl. / 1g.
Jeg er meget skeptisk overfor kvaliteten af software som bliver skrevet af programmører der ikke aner hvad den kode de skriver gør.
Der er tårnhøj sandsynlighed for problemer et eller andet sted mellem den matematisk formel og computer implementeringen.
Medmindre at domain eksperten faktisk kan programmere og overtage alt det vanskelige arbejde fra programmøren.
Og hvis det er tilfældet så må man jo spørge om hvad man betaler for ved at ansætte en programmør.
Windcape (117) skrev:
Dertil er selve implementeringen utrolig vigtig som du også påpeger, hvor at det er meget vigtigt at have godt kendskab til udviklingsmetoder og test. At skrive en lang række unit-test før man implementere en given formel til f.eks. børs-software, ville jo være det bedste man kunne gøre.
Igen et punkt hvor en datamatiker har specialiseret på sin uddanelse, men hvor datalogen/ingenøren kun har overfladisk kendskab (medmindre de har lavet selvstudie).
Jeg synes man undervudere dette. Hvad god er en datalog som måske forstår matematikken, men skriver en invalid unit-test (eller slet ingen) så systemet ikke virker alligevel?
Hvis man på datamatiker lærer at man kan skrive unit tests til at teste noget kode som man ikke forstår hvordan virker, så er den da helt gal.
Windcape (117) skrev:Matematik for mig er mere situationsbestemt end noget man bør bruge 3 år på at specialisere sig i. I stedet bør man specialisere sig i udviklingskompetancer, så man kan lave noget solidt håndværk fra dag 1.
Det er en meget kortsigtet betragtning.
Jeg mener at en videregående uddannelse skal give et godt fundament for at arbejde i 40 år.
Virksomhederne må så selv sig tage sig af deres helt specifikke her og nu behov.
#128
Det vil ingen påstå det ikke er, men vi kan jo ikke fyre alle i IT branchen der ikke har en doktorgrad i computer science og matematik. Desuden, så er triviel kode vel ikke at rakke ned på? I sidste ende drejer det sig vel om at lave et produkt som kunden har behov for og er villig til at betale en masse penge for.
Om man skal lave et 'hav af beregninger' afhænger også i om man arbejder i et problemområde der kræver det.
Desuden laver man jo ikke et kæmpe børssystem ene mand, så man får rig mulighed for at spørge sine kollegaer.
Det kræver flere års studieren af børser oveni ens programmør-uddannelse at kunne lave sådan et stykke software.
Nu er der også mange andre ikke-matematiske aspekter indenfor software-udvikling som er nødvendige for at det bliver en success. At man er hammerdygtig til matematik og skrive de bedste algoritmer, betyder jo ikke at man per automatisk bliver god til OOA/OOP samt at have gode evner til at kommunikere og snakke på samme niveau som kunderne og kollegaerne der arbejder med fx databasen. God software bliver ikke båret frem af god matematisk forståelse alene. Ellers var alle de elendige offentlige systemer som danskerne har betalt for, vel blevet en success?
#129
Hvis man er så ringe, så har man forhåbenligt heller ikke et arbejde.
Sålænge der er mennesker indblandet kan der opstå fejl. Datalogen kan sagtens have taget fejl, og skrevet en algoritme som virker, men som ikke var det der skulle bruges.
"Den virker ikke" vs. "virker, men ikke på den rigtige måde" = failure!
Men er det ikke derfor folk bruger agile, evolutionære og iterative processer? Netop for at kunne finde sådanne problemer i god tid, istedet for at skulle rette flere hundrede tusind klasser igennem når produktet er leveret?
Min erfaring er, at det mere er kompleksiteten af systemet som er problemet, og ikke så meget matematikken.
Lige så snart du skal skrive kode som ikke er totalt triviel, så er matematik særdeles nyttigt.
Det vil ingen påstå det ikke er, men vi kan jo ikke fyre alle i IT branchen der ikke har en doktorgrad i computer science og matematik. Desuden, så er triviel kode vel ikke at rakke ned på? I sidste ende drejer det sig vel om at lave et produkt som kunden har behov for og er villig til at betale en masse penge for.
Og specielt da et børs system med realtime requirements og et hav af beregninger.
Om man skal lave et 'hav af beregninger' afhænger også i om man arbejder i et problemområde der kræver det.
Desuden laver man jo ikke et kæmpe børssystem ene mand, så man får rig mulighed for at spørge sine kollegaer.
Det kræver flere års studieren af børser oveni ens programmør-uddannelse at kunne lave sådan et stykke software.
En anden måde at se på det er, at dem med andre naturvidenskabelige uddannelser end datalogi: rene matematikere, fysiskere, kemikere, non-IT ingeniører etc. ofte bliver lige så gode IT folk som dataloger. Den grundliggende matematiske tankegang er vigtigere end den specielle anvendelse på datalogiske problemer.
Nu er der også mange andre ikke-matematiske aspekter indenfor software-udvikling som er nødvendige for at det bliver en success. At man er hammerdygtig til matematik og skrive de bedste algoritmer, betyder jo ikke at man per automatisk bliver god til OOA/OOP samt at have gode evner til at kommunikere og snakke på samme niveau som kunderne og kollegaerne der arbejder med fx databasen. God software bliver ikke båret frem af god matematisk forståelse alene. Ellers var alle de elendige offentlige systemer som danskerne har betalt for, vel blevet en success?
#129
Jeg er meget skeptisk overfor kvaliteten af software som bliver skrevet af programmører der ikke aner hvad den kode de skriver gør.
Hvis man er så ringe, så har man forhåbenligt heller ikke et arbejde.
Der er tårnhøj sandsynlighed for problemer et eller andet sted mellem den matematisk formel og computer implementeringen.
Sålænge der er mennesker indblandet kan der opstå fejl. Datalogen kan sagtens have taget fejl, og skrevet en algoritme som virker, men som ikke var det der skulle bruges.
"Den virker ikke" vs. "virker, men ikke på den rigtige måde" = failure!
Men er det ikke derfor folk bruger agile, evolutionære og iterative processer? Netop for at kunne finde sådanne problemer i god tid, istedet for at skulle rette flere hundrede tusind klasser igennem når produktet er leveret?
Min erfaring er, at det mere er kompleksiteten af systemet som er problemet, og ikke så meget matematikken.
squad2nd (130) skrev:Det vil ingen påstå det ikke er, men vi kan jo ikke fyre alle i IT branchen der ikke har en doktorgrad i computer science og matematik.
squad2nd (130) skrev:Desuden laver man jo ikke et kæmpe børssystem ene mand, så man får rig mulighed for at spørge sine kollegaer.
Ganske rigtigt.
Vi er hvor vi er.
Men snakker vi om unge mennesker der skal igang med en uddannelse, så synes jeg at man skal anbefale noget med en solid dosis matematik.
squad2nd (130) skrev:Desuden, så er triviel kode vel ikke at rakke ned på? I sidste ende drejer det sig vel om at lave et produkt som kunden har behov for og er villig til at betale en masse penge for.
De største værdier er som oftest i det som er vanskeligst at lave.
squad2nd (130) skrev:Nu er der også mange andre ikke-matematiske aspekter indenfor software-udvikling som er nødvendige for at det bliver en success. At man er hammerdygtig til matematik og skrive de bedste algoritmer, betyder jo ikke at man per automatisk bliver god til OOA/OOP samt at have gode evner til at kommunikere og snakke på samme niveau som kunderne og kollegaerne der arbejder med fx databasen.
Der er mange andre faktorer end matematik. Men matematik er notorisk en af dem som det er sværrest at tilegne sig efter afslutning af studiet.
squad2nd (130) skrev:Sålænge der er mennesker indblandet kan der opstå fejl. Datalogen kan sagtens have taget fejl, og skrevet en algoritme som virker, men som ikke var det der skulle bruges.
"Den virker ikke" vs. "virker, men ikke på den rigtige måde" = failure!
Der kan altid ske fejl.
Men det nedsætter risikoen for fejl en hel del, hvis der er en person som både forstår matematikken i en formel og hvordan computeren beregner det.
squad2nd (130) skrev:God software bliver ikke båret frem af god matematisk forståelse alene. Ellers var alle de elendige offentlige systemer som danskerne har betalt for, vel blevet en success?
squad2nd (130) skrev:Min erfaring er, at det mere er kompleksiteten af systemet som er problemet, og ikke så meget matematikken.
Matematik er ikke nogen silver-bullet. Det er kun et værktøj i værktøjs kassen.
Mit eksempel var taget fra en ven fra min Guild.squad2nd (130) skrev:Det kræver flere års studieren af børser oveni ens programmør-uddannelse at kunne lave sådan et stykke software.
Han har udviklet en brugerflade i WPF/C# til stockmarked displays (real-time informationer).
Og nej, det er ikke ham som står for matematikken. Han er frontend udvikler.
:-)
arne_v (135) skrev:#134
Der er nogle udviklere som betragter frontend udvikling som anden klasses udvikling.
Rendyrket snobberi. Og ikke specielt velbegrundet.
Men der _er_ jo forskel. Jeg siger ikke det anden klasse, men hvis frontenden er en webside i HTML, så laver man vel primært layout og ikke "kode".
Er jeg en snob?
#140
Der er forskel på design og kode.
Sammenligningen frontend-backend giver naturligvis kun mening for den del af frontend som er kode orienteret (HTML forms, JavaScript etc.) ikke for det rent visuelle.
Hvis du ser ned på dem som vælger den helt rette baggrundsfarve og et matchende logo, så *er* du en snob.
Der er forskel på design og kode.
Sammenligningen frontend-backend giver naturligvis kun mening for den del af frontend som er kode orienteret (HTML forms, JavaScript etc.) ikke for det rent visuelle.
Hvis du ser ned på dem som vælger den helt rette baggrundsfarve og et matchende logo, så *er* du en snob.
arne_v (141) skrev:#140
Der er forskel på design og kode.
Sammenligningen frontend-backend giver naturligvis kun mening for den del af frontend som er kode orienteret (HTML forms, JavaScript etc.) ikke for det rent visuelle.
Hvis du ser ned på dem som vælger den helt rette baggrundsfarve og et matchende logo, så *er* du en snob.
Okay. :) Men der er vel stadig forskel på det arbejde der oftest skal laves i frontends kontra backends, så på en eller anden måde ér det vel "en anden klasse" af udvikling. :) At individuelle udviklere foretrækker forskellige områder er vel kun naturligt, men derfor er det selvfølgelig åndssvagt at kalde andre for "underudviklere".
arne_v (141) skrev:Hvis du ser ned på dem som vælger den helt rette baggrundsfarve og et matchende logo, så *er* du en snob.
Jeg ville aldrig se ned på dem, specielt hvis de kan deres ting. Derfor synes jeg stadig at programmering er federe. ;)
#142
Oh ja.
Der er stor forskel på de specifikke kompetancer.
Frontend udvikleren kan alle HTML tags, JavaScript DOM model, MVC frameworket der bruges etc.. Og han hader IE 6.
Backend udvikleren forstår transaction isolation levels, memory modellen, SOAP og WSDL etc.. Og han hader MyISAM tabeller.
Men man skal bare være forsigtig med at gøre noget finere end andet.
Oh ja.
Der er stor forskel på de specifikke kompetancer.
Frontend udvikleren kan alle HTML tags, JavaScript DOM model, MVC frameworket der bruges etc.. Og han hader IE 6.
Backend udvikleren forstår transaction isolation levels, memory modellen, SOAP og WSDL etc.. Og han hader MyISAM tabeller.
Men man skal bare være forsigtig med at gøre noget finere end andet.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund