mboost-dp1
Vise ord fra Bjarne Stroustrup
At være en god udvikler handler vel rent praktisk mindre om at være god til at kode i flere sprog, eller forstå advancerede algoritmer, men mere om at kunne kode ren, læsbar kode, som nemt kan vedligeholdes af andre.
Jeg synes stadigvæk at han fokusere for meget på de traditionelle dyder, og ikke har opdaget at verden har flyttet sig omkring ham, til hvor det handler mere om teamwork og vedligeholdelse, frem for at være god til at kunne diverse quirks i sprogene.
Det er jo også kun hans eget mærkværdige sprog som nærmest ikke består af quirks.
Så jeg synes ikke hans "vise ord" er synderligt fornuftige, udover at man bør lære mere end ét sprog.
Jeg så hellere at nye programmører brugte tiden på at læse Robert Martin's "Clean Code", end at fokusere på matematik/fysik, når det kommer til at sætte perspektiv i udviklingen.
Jeg synes stadigvæk at han fokusere for meget på de traditionelle dyder, og ikke har opdaget at verden har flyttet sig omkring ham, til hvor det handler mere om teamwork og vedligeholdelse, frem for at være god til at kunne diverse quirks i sprogene.
Det er jo også kun hans eget mærkværdige sprog som nærmest ikke består af quirks.
Så jeg synes ikke hans "vise ord" er synderligt fornuftige, udover at man bør lære mere end ét sprog.
Jeg så hellere at nye programmører brugte tiden på at læse Robert Martin's "Clean Code", end at fokusere på matematik/fysik, når det kommer til at sætte perspektiv i udviklingen.
en anden ting der er utroligt vigtigt er at være god til at google......
det er fandeme mange libaries derude der er utroligt dårligt dokumenterede, og bare kræver at man kan finde ud af at google og så forstå de svar man får tilbage..... som eksempel kan jeg nævne xmlsec/openssl/xerces/xalan komboen- det er et mareridt at arbejde med uden google.
det er fandeme mange libaries derude der er utroligt dårligt dokumenterede, og bare kræver at man kan finde ud af at google og så forstå de svar man får tilbage..... som eksempel kan jeg nævne xmlsec/openssl/xerces/xalan komboen- det er et mareridt at arbejde med uden google.
#2
Jeg er fuldstændig enig. Med de vanvittige krav der er til arkitekturer idag for at et system kan skalere, skal der mere til end bare nærstuderen af algoritmer og matematik.
Det bedste man nok kan gøre ved sig selv, er at erkende at man ikke kan være ekspert på alle områder indenfor udvikling, men at man i det mindste kan lave sit system så flexibelt, at en anden (der kender til området) ville kunne skrive koden istedet og nemt plugge det.
Efter jeg begyndte at fokusere mere på arkitektur end på kode, er jeg personligt blevet bedre til at kunne overskue ting, og er ikke bange for at noget går i stykker, fordi det kan udskiftes senere.
Når det er sagt, så er det egenligt overraskende hvor lang tid C++ har levet, og hvor mange år det kommer til at leve.
Personligt kan jeg ikke udstå sproget, de biblioteker der følger med, mixet af C og C++ kode, samt al det forpulede kode man skal skrive bare for at få lidt 'bang'.
Giv mig C# eller Java anytime, men C++? Så ville jeg hellere kastreres med en tom Windows 7 Ultimate æske.
Jeg er fuldstændig enig. Med de vanvittige krav der er til arkitekturer idag for at et system kan skalere, skal der mere til end bare nærstuderen af algoritmer og matematik.
Det bedste man nok kan gøre ved sig selv, er at erkende at man ikke kan være ekspert på alle områder indenfor udvikling, men at man i det mindste kan lave sit system så flexibelt, at en anden (der kender til området) ville kunne skrive koden istedet og nemt plugge det.
Efter jeg begyndte at fokusere mere på arkitektur end på kode, er jeg personligt blevet bedre til at kunne overskue ting, og er ikke bange for at noget går i stykker, fordi det kan udskiftes senere.
Når det er sagt, så er det egenligt overraskende hvor lang tid C++ har levet, og hvor mange år det kommer til at leve.
Personligt kan jeg ikke udstå sproget, de biblioteker der følger med, mixet af C og C++ kode, samt al det forpulede kode man skal skrive bare for at få lidt 'bang'.
Giv mig C# eller Java anytime, men C++? Så ville jeg hellere kastreres med en tom Windows 7 Ultimate æske.
Jeg synes nu det giver meget god mening det manden skriver.
Det manden mener er at du skal træne dig selv i at kunne sætte dig grundigt ind i nye emner, også selv om de ikke ligger inden for dit eget felt, og det kræver træning. Ikke at du skal bruge fagene matematik og fysik til direkte at blive en bedre programmør.
Og jeg så gerne at nye programmører brugte tiden på at læse Dahl, Dijkstra & Hoare's "Structured Programming" fremragende notesæt fra 1972 (Academic Press).
Du udelader så også den væsentlige del "Lær at kommunikere effektivt i tekst og tale". Det kan lyde åndsvagt, men jeg er ret sikker på at det han mener er at du skal kunne forklare præcist hvordan din løsning på et problem fungerer og om den faktisk løser problemet.
Der er stadig behov have en solid bagage i algoritmik. Du skal ikke bare lære algoritmer for at vide hvordan de fungerer. Du skal lære dem fordi der er en struktureret tankegang bag dem, og den skal gerne smitte af på dig selv. Det kan gå galt, i en af mine lærebøger om parallelprogammering bruger de et kapitel på at håndoptimere en DFT-algoritme, uden at nævne noget som helst om FFT-algoritmen. Vores forelæser i det pågældende fag viste os så kørselstiderne, hvor FFT i en ikke-paralleludgave klarer sig hurtigere end den optimerede paralleludgave.
Og med henblik på at kunne flere sprog idiomatisk, så styrker det din evne til at udtrykke dig bedst muligt i den givne kontekst, og dermed også få din løsning til at se bedre ud.
Windcape (2) skrev:
Jeg så hellere at nye programmører brugte tiden på at læse Robert Martin's "Clean Code", end at fokusere på matematik/fysik, når det kommer til at sætte perspektiv i udviklingen.
Det manden mener er at du skal træne dig selv i at kunne sætte dig grundigt ind i nye emner, også selv om de ikke ligger inden for dit eget felt, og det kræver træning. Ikke at du skal bruge fagene matematik og fysik til direkte at blive en bedre programmør.
Og jeg så gerne at nye programmører brugte tiden på at læse Dahl, Dijkstra & Hoare's "Structured Programming" fremragende notesæt fra 1972 (Academic Press).
Windcape (2) skrev:
Så jeg synes ikke hans "vise ord" er synderligt fornuftige, udover at man bør lære mere end ét sprog.
Du udelader så også den væsentlige del "Lær at kommunikere effektivt i tekst og tale". Det kan lyde åndsvagt, men jeg er ret sikker på at det han mener er at du skal kunne forklare præcist hvordan din løsning på et problem fungerer og om den faktisk løser problemet.
Windcape (2) skrev:
At være en god udvikler handler vel rent praktisk mindre om at være god til at kode i flere sprog, eller forstå advancerede algoritmer, men mere om at kunne kode ren, læsbar kode, som nemt kan vedligeholdes af andre.
Der er stadig behov have en solid bagage i algoritmik. Du skal ikke bare lære algoritmer for at vide hvordan de fungerer. Du skal lære dem fordi der er en struktureret tankegang bag dem, og den skal gerne smitte af på dig selv. Det kan gå galt, i en af mine lærebøger om parallelprogammering bruger de et kapitel på at håndoptimere en DFT-algoritme, uden at nævne noget som helst om FFT-algoritmen. Vores forelæser i det pågældende fag viste os så kørselstiderne, hvor FFT i en ikke-paralleludgave klarer sig hurtigere end den optimerede paralleludgave.
Og med henblik på at kunne flere sprog idiomatisk, så styrker det din evne til at udtrykke dig bedst muligt i den givne kontekst, og dermed også få din løsning til at se bedre ud.
#5
Med måde selvfølgelig. Det afhænger så sandelig af hvilket område man arbejder indenfor. Personligt, foretrækker jeg at koncentrere mig om den branche / business jeg har kastet mig over for at kunne forstå kundernes behov og sprog bedre. Så må avancerede algoritmer og teknik komme i anden række.
Det lyder nemt at kunne flere sprog, men de API's og finesser og best practices der følger med hvert sprog, er så vanvittigt store at man ikke "bare" kan lære det uden videre.
Min erfaring siger mig, at det bedst kan betale sig at lære ét sprog og blive hardcore i det, så man kender det ud og ind, istedet for at kaste sig over flere sprog hvor man er middelmådig og kun kan producere lidt, uden at vide om det er kvalitet, om man har brugt de rigtige værktøjer, eller ej.
Der er stadig behov have en solid bagage i algoritmik.
Med måde selvfølgelig. Det afhænger så sandelig af hvilket område man arbejder indenfor. Personligt, foretrækker jeg at koncentrere mig om den branche / business jeg har kastet mig over for at kunne forstå kundernes behov og sprog bedre. Så må avancerede algoritmer og teknik komme i anden række.
Og med henblik på at kunne flere sprog idiomatisk, så styrker det din evne til at udtrykke dig bedst muligt i den givne kontekst, og dermed også f
å din løsning til at se bedre ud.
Det lyder nemt at kunne flere sprog, men de API's og finesser og best practices der følger med hvert sprog, er så vanvittigt store at man ikke "bare" kan lære det uden videre.
Min erfaring siger mig, at det bedst kan betale sig at lære ét sprog og blive hardcore i det, så man kender det ud og ind, istedet for at kaste sig over flere sprog hvor man er middelmådig og kun kan producere lidt, uden at vide om det er kvalitet, om man har brugt de rigtige værktøjer, eller ej.
squad2nd (6) skrev:#5
Det lyder nemt at kunne flere sprog, men de API's og finesser og best practices der følger med hvert sprog, er så vanvittigt store at man ikke "bare" kan lære det uden videre.
Siger heller ikke det skal være nemt og kunne læres på ingen tid. Det er også det artiklen på Version2 starter ud med..
Artiklen skrev:"Der er ingen nemme genveje til at blive en dygtig udvikler. Sådan må man tolke meldingen fra Bjarne Stroustrup"
squad2nd (6) skrev:#5
Min erfaring siger mig, at det bedst kan betale sig at lære ét sprog og blive hardcore i det, så man kender det ud og ind, istedet for at kaste sig over flere sprog hvor man er middelmådig og kun kan producere lidt, uden at vide om det er kvalitet, om man har brugt de rigtige værktøjer, eller ej.
Men Stroustrup prædiker ikke at man skal blive middelmådig til mange sprog. Han siger derimod at du skal blive stærk i flere programmeringssprog.
Problemet er bare at det ikke handler om programmeringssprog.Ildhesten (7) skrev:Men Stroustrup prædiker ikke at man skal blive middelmådig til mange sprog. Han siger derimod at du skal blive stærk i flere programmeringssprog.
Det handler om programmeringsmiljøer.
C++ er ikke bare C++. Det er C++, BOOST, Linux og/eller WINAPI, C, asm, make/diverse-gnu-tools etc.
Ligeledes er C# ikke bare C#. Det er .NET, Visual Studio, Windows...
Windcape (2) skrev:At være en god udvikler handler vel rent praktisk mindre om at være god til at kode i flere sprog, eller forstå advancerede algoritmer, men mere om at kunne kode ren, læsbar kode, som nemt kan vedligeholdes af andre.
Windcape (2) skrev:Jeg synes stadigvæk at han fokusere for meget på de traditionelle dyder, og ikke har opdaget at verden har flyttet sig omkring ham, til hvor det handler mere om teamwork og vedligeholdelse, frem for at være god til at kunne diverse quirks i sprogene.
Windcape (2) skrev:eg så hellere at nye programmører brugte tiden på at læse Robert Martin's "Clean Code", end at fokusere på matematik/fysik, når det kommer til at sætte perspektiv i udviklingen.
Software udvikling er meget mere end de "hårde" discipliner.
Men derfor giver det alligevel mening at fokusere på de "hårde" discipliner under uddannelse.
Fordi hvis folk ikke lærer de "hårde" discipliner under uddannelsen, så lærer de dem aldrig.
Mens hvis folk ikke lærer de "bløde" discipliner under uddannelsen, så lærer de dem i løbet af de første 5 år på arbejdsmarkedet.
Begge postulater gælder kun for størstedelen ikke for for alle.
squad2nd (4) skrev:Jeg er fuldstændig enig. Med de vanvittige krav der er til arkitekturer idag for at et system kan skalere, skal der mere til end bare nærstuderen af algoritmer og matematik.
Jeg er noget skeptisk overfor skalerbare systemer der ikke bygger på algoritmer og matematik.
squad2nd (4) skrev:Når det er sagt, så er det egenligt overraskende hvor lang tid C++ har levet, og hvor mange år det kommer til at leve.
COBOL er ældre og lever også i bedste velgående.
Årsagen til at COBOL stadig eksisterer og en af årsagerne til at C++ stadig eksisterer er mængden af eksisterende koe, som man ikke har lyst til at omskrive fra scratch.
(der skulle eksistere 1 trillion linier COBOL!)
En anden årsag til at C++ stadig eksisterer er at der er visse ting som det er bedre til end Java og C#:
- hardware nært
- OS nært
- real time
etc.
Både MS CLR og alle de kendte JVM er skrevet i C/C+.
squad2nd (6) skrev:Med måde selvfølgelig. Det afhænger så sandelig af hvilket område man arbejder indenfor. Personligt, foretrækker jeg at koncentrere mig om den branche / business jeg har kastet mig over for at kunne forstå kundernes behov og sprog bedre. Så må avancerede algoritmer og teknik komme i anden række.
Sådan lidt firkantet så:
- dem der ikke får lært big O analyse under studiet bliver aldrig gode til det
- dem der ikke får lært at snakke med kunder under uddannelsen lærer det hurtigt når de kommer på arbejdsmarkedet
Der er masser af job typer hvor de bløde discpliner er det vigtigste: project manager, BA etc..
Men for en software engineer er det vigtigt at kunne noget teknik.
squad2nd (6) skrev:Det lyder nemt at kunne flere sprog, men de API's og finesser og best practices der følger med hvert sprog, er så vanvittigt store at man ikke "bare" kan lære det uden videre.
squad2nd (6) skrev:Min erfaring siger mig, at det bedst kan betale sig at lære ét sprog og blive hardcore i det, så man kender det ud og ind, istedet for at kaste sig over flere sprog hvor man er middelmådig og kun kan producere lidt, uden at vide om det er kvalitet, om man har brugt de rigtige værktøjer, eller ej.
Ja. Det tager tid at mestre et sprog med tilhørende API'er og paradigmer.
Men det giver også noget ekstra at kende flere forskellige måder at gøre tingene på. Man kan godt blive bedre til X ved at lære Y og Z.
Dem som lærer big O analyse, har glemt det et par måneder senere (hvis de ikke skal til eksamen i det, ellers så næste semester).arne_v (12) skrev:Sådan lidt firkantet så:
- dem der ikke får lært big O analyse under studiet bliver aldrig gode til det
Det benyttes ikke som en del af projekter i løbet af uddannelsen, og derfor vil folk hurtigt glemme det igen. Jeg har lavet meget kode, og har ALDRIG haft brug for big O analyse.
Med dette her link behøver man ikke kunne huske mere, for at kunne forstå notationen i et hverdags job.
Studerende der ikke lærer udviklingsmetodologier lærer ikke ordenligt teamwork, og lærer ikke at strukturer deres arbejde.arne_v (12) skrev:- dem der ikke får lært at snakke med kunder under uddannelsen lærer det hurtigt når de kommer på arbejdsmarkedet
Hvis man bruger alt sin tid på at nørkle med en teknisk optimization, og en masse matematik, men ikke kan dokumentere processen, så kan man godt forberede sig på at dumpe, medmindre man er ph.d. studerende.
Det tekniske vurderes aldrig. Hverken på Datamatiker eller Ingeniør studiet, har underviserne kigget på kode som led i afleveringer. Faktisk er reglerne således, at hvis kode ikke er indlejret som en del af rapporten (bilag), så behøver lærer/censor ikke at kigge på den.arne_v (12) skrev:Men for en software engineer er det vigtigt at kunne noget teknik.
Kodens kvalitet vurderes heller aldrig, så en nyuddannet ingeniør eller datamatiker kan sagtens have kode kompetancer på under nul. (Der var en 3 stykker fra mit hold med så lave kompetancer!)
Det samme gør sig gældende for datalogi, hvor programmering ikke er en hoveddel af studiet, men blog tillæg for at kunne løse de stillede opgaver.
Så nej, det er ikke vigtigt at kunne noget tekniske, ihvertfald ikke hvis man vurdere ud fra de givne karakterer i uddannelsessystemet, og dermed samfundet.
Og mig vurdering er at arbejdsgiverne også fokusere mere på at du kan arbejde metodisk, end at du er super god til algoritmer. Medmindre du altså vil arbejde hos Google.
Webudvikling!arne_v (10) skrev:Jeg er noget skeptisk overfor skalerbare systemer der ikke bygger på algoritmer og matematik.
Matematik betyder intet i forhold til at kunne skrive skalerbar kode, som kræver en mere teknisk indsigt i hvordan systemerne fungere, hvilket så igen bygger på at koden til systemet er letlæseligt og kan vedligeholdes nemt.
Kendskab til patterns som IoC er mere vigtigt end at kunne implementere en FFT-algoritme.
Absolut. F.eks. at lære funktionel programmering.arne_v (13) skrev:Ja. Det tager tid at mestre et sprog med tilhørende API'er og paradigmer.
Men det giver også noget ekstra at kende flere forskellige måder at gøre tingene på. Man kan godt blive bedre til X ved at lære Y og Z.
Men det kræver også at man er på et højt nok niveau til at kunne perspektivere den viden, til at blive brugt under et andet paradigm.
Min vurdering er at folk skal bruge 3-4 års erfaring med programmering, før de kan det.
Men overordnet er budskabet vel bare, at hvis man vil være god, så skal man bruge tid på lære ting -- uden at blive spurt først.
Windcape (15) skrev:Dem som lærer big O analyse, har glemt det et par måneder senere (hvis de ikke skal til eksamen i det, ellers så næste semester).
Det benyttes ikke som en del af projekter i løbet af uddannelsen, og derfor vil folk hurtigt glemme det igen. Jeg har lavet meget kode, og har ALDRIG haft brug for big O analyse.
Med dette her link behøver man ikke kunne huske mere, for at kunne forstå notationen i et hverdags job.
Dette er netop kernen i hele problematikken. Efter min mening og hvis jeg forstår Bjarnes udtalelser rigtigt også efter hans mening.
Der er nogen som lærer indholdet af den Wikipedia side udenad, kan forklare det til eksamen og glemmer det.
Og så er det dem som bruger den tid det tager at forstå det og derefter per automatik bruger det resten af livet.
Det er noget som kan finde anvendelse om ikke hver dag så ihvertfald hver uge, når man programmerer.
Det er sådan noget som adskiller de gode fra de middelmådige.
Windcape (15) skrev:Det tekniske vurderes aldrig. Hverken på Datamatiker eller Ingeniør studiet, har underviserne kigget på kode som led i afleveringer.
Windcape (15) skrev:Kodens kvalitet vurderes heller aldrig, så en nyuddannet ingeniør eller datamatiker kan sagtens have kode kompetancer på under nul. (Der var en 3 stykker fra mit hold med så lave kompetancer!)
Windcape (15) skrev:Så nej, det er ikke vigtigt at kunne noget tekniske, ihvertfald ikke hvis man vurdere ud fra de givne karakterer i uddannelsessystemet, og dermed samfundet.
Jeg håber meget at de uddannelser vurderer folks evner til den tekniske problem løsning.
Hvorvidt den vurderes udfra Java kode, pseudo kode eller dansk tekst er ikke så vigtigt.
Windcape (15) skrev:Og mig vurdering er at arbejdsgiverne også fokusere mere på at du kan arbejde metodisk, end at du er super god til algoritmer.
Det er (desværre) langt nemmere at vurdere ansøgeres evner til at "snakke fornuftigt" end deres evner til at løse vanskelige tekniske problem stillinger.
Windcape (16) skrev:Matematik betyder intet i forhold til at kunne skrive skalerbar kode,
Givet at skalerbarhed vel definitorisk er O(n) egenskab, så ...
Windcape (16) skrev:som kræver en mere teknisk indsigt i hvordan systemerne fungere,
Det hjælper altid vide noget om det man arbejder med.
Windcape (16) skrev:hvilket så igen bygger på at koden til systemet er letlæseligt og kan vedligeholdes nemt.
Letlæselig kode har en stor betydning for omkostning over kodens life cycle.
Men det har ikke noget med skalerbarhed at gøre og meget lidt med at forstå hvordan systemet fungerer (normalt er der alt for meget kode til at det at læse kode er en brugbar vej til overblik).
Windcape (16) skrev:Kendskab til patterns som IoC er mere vigtigt end at kunne implementere en FFT-algoritme.
Ja og nej.
Der er næppe mange web apps som har brug for FFT.
Men evnen til at lære FFT er en langt bedre indikator for evner end at lære IoC.
En bonus ved funktionel programmering: http://en.wikipedia.org/wiki/Referential_transpare...
Jeg er absolut ikke enig.arne_v (18) skrev:Og så er det dem som bruger den tid det tager at forstå det og derefter per automatik bruger det resten af livet.
Det er noget som kan finde anvendelse om ikke hver dag så ihvertfald hver uge, når man programmerer.
Jeg har ikke haft brug for big O analyse nogensinde i praktisk programmering.
Og det er fordi at enten er der allerede taget hånd om det i de APIs jeg bruger,
eller også er det ikke relevant.
Kendskab til SCRUM giver dig højere chance for at lande et job, end kendskab til FFT.arne_v (19) skrev:Det skal de nok lære efter studiet når de får et arbejde.
Specielt når det er HR afdelingen som foretager interviewet.
arne_v (21) skrev:Givet at skalerbarhed vel definitorisk er O(n) egenskab, så ...
Skalerbarhed for web handler mere om kendskab til cache. Hvordan vil du definere brugen af et webcache system i form af O(n) ?
Og har det overhovedet nogen relevans for den praktiske udførsel? I think not!
arne_v (21) skrev:Men evnen til at lære FFT er en langt bedre indikator for evner end at lære IoC.
Men evnen til at forstå og bruge IoC er af en højere praktisk værdi, som betyder du udfør dit arbejde bedre.
Jeps, det er en af de bonuser man opnår ved at bruge det funktionelle paradigm, i alle sprog.onetreehell (22) skrev:En bonus ved funktionel programmering: http://en.wikipedia.org/wiki/Referential_transpare...
Det er hvad jeg selv fokusere på at lære folk når jeg forklare det funktionelle paradigm, frem for at fokusere på "i F# skal du skrive mindre kode, fordi vi har 150 ASCII operators!!!!"
Tilføjelse:Windcape (23) skrev:Jeg har ikke haft brug for big O analyse nogensinde i praktisk programmering.
Optimering via. big O analyse er relevant på algoritmer, som typisk udmunder i en form for iteration og/eller søgning.
Men i det meste software jeg har arbejdet med, er søgning noget som foretages af en database, og derfor igen, er optimeringsdelen abstraheret væk.
Ja, hvis man havde muligheden for at vælge database, og sige at "NoSQL ville være bedre her fordi bla bla bla big O bla bla", så giver det mening.
Men det er ikke et normalt valg af have.
Tag en helt almindelige side som newz.dk -- Hvor ville du i dine vildeste drømme forestille dig at man har brugt big O analyse til at optimere siden?
Bjarne Stroustrup blev lidt sur over et "fake" interview der engang blev skrevet med ham i, men for jer der ikke kender det, er det faktisk morsomt.
Bjarne Stroustrup - IEEE interview
Bjarne Stroustrup - IEEE interview
Bjarne Stroustrup skriver følgende i hans artikel: "Learning C++ as a new language":
Udfra det kan jeg læse, at Stroustrup understrege vigtigheden i at bruge eksisterende biblioteker og let tilgængelige algoritmer, uden fuldstændig at komme ned på et niveau hvor man næsten skriver det selv.
Fx skalering, som man næsten får serveret på et sølvfad hvis man skriver sin kode ordenligt og spiller indenfor fx .NET og Java's regler for application server clustering/skalering.
Noget andet er selvfølgelig algoritmer og collections. De er sjove at studere, men er totalt waste at skrive selv hvis der allerede eksisterer et library der kan tage sig af de grumme detaljer.
Der er nogen programmører der mener at man ikke er en rigtig programmør hvis man ikke ved hvordan en given implementation er udviklet eller kan løse og læse de mest avancerede matematiske algoritmer (total waste hvis det ikke har noget med ens forretningsområde at gøre).
Education must play a major role in this move to cleaner and higher-level programming styles. The C++ community doesn't need another generation of programmers who by default use the lowest level of language and library facilities available out of misplaced fear of inefficiencies. Experienced C++ programmers as well as C++ novices must learn to use Standard C++ as a new and higher-level language as a matter of course, and descend to lower levels of abstraction only where absolutely necessary.
Udfra det kan jeg læse, at Stroustrup understrege vigtigheden i at bruge eksisterende biblioteker og let tilgængelige algoritmer, uden fuldstændig at komme ned på et niveau hvor man næsten skriver det selv.
Fx skalering, som man næsten får serveret på et sølvfad hvis man skriver sin kode ordenligt og spiller indenfor fx .NET og Java's regler for application server clustering/skalering.
Noget andet er selvfølgelig algoritmer og collections. De er sjove at studere, men er totalt waste at skrive selv hvis der allerede eksisterer et library der kan tage sig af de grumme detaljer.
Der er nogen programmører der mener at man ikke er en rigtig programmør hvis man ikke ved hvordan en given implementation er udviklet eller kan løse og læse de mest avancerede matematiske algoritmer (total waste hvis det ikke har noget med ens forretningsområde at gøre).
#27
Igen det er tankegangen man opnår ved at bruge tid på at lære de svære algoritmer man vinder noget på.
Som der fint bliver nævnt i tråden, kan man skrive masser af programmer som ikke kræver specifik kendskab til algoritmer. Det kræver ikke en god programmør at bruge et godt library, men det kræver en til at skrive det.
Men, forskellen på den gode og den middelmådige programmør, er at den gode programmør ikke er hjælpeløs når han ikke lige kan finde et library som kan løse de problemer han får stillet.
Hvis man ikke har ambitioner om mere end fx at skrive "The average web-app", så lad være med at lære om algoritmer, så simpelt er det. Men så skal man også bare acceptere man derved afskærer sig selv fra at kunne skrive en lang række programmer, og løse en lang række ikke trivielle problemstillinger.
squad2nd (27) skrev:
Der er nogen programmører der mener at man ikke er en rigtig programmør hvis man ikke ved hvordan en given implementation er udviklet eller kan løse og læse de mest avancerede matematiske algoritmer (total waste hvis det ikke har noget med ens forretningsområde at gøre).
Igen det er tankegangen man opnår ved at bruge tid på at lære de svære algoritmer man vinder noget på.
Som der fint bliver nævnt i tråden, kan man skrive masser af programmer som ikke kræver specifik kendskab til algoritmer. Det kræver ikke en god programmør at bruge et godt library, men det kræver en til at skrive det.
Men, forskellen på den gode og den middelmådige programmør, er at den gode programmør ikke er hjælpeløs når han ikke lige kan finde et library som kan løse de problemer han får stillet.
Hvis man ikke har ambitioner om mere end fx at skrive "The average web-app", så lad være med at lære om algoritmer, så simpelt er det. Men så skal man også bare acceptere man derved afskærer sig selv fra at kunne skrive en lang række programmer, og løse en lang række ikke trivielle problemstillinger.
det man får ud af at kunne skrive libaries er at man ved hvilket et man skal vælge.
F.eks. hvornår man skal vælge en linked list eller en array baseret container. Det er god universel viden man kan bruge i alle sprog :)
Det svarer lidt til at lære at smugle en flaske vodka med i lommen, istedet for at lære at bestille 20 øl på alle sprog.
Med vodka metoden har du en metode der vil virke i barer i alle lande, og det er bare mest effektivt.
Alternativet er at skulle lære at bestille både øl og sprut på ny hver gang du kommer til et nyt land.
skål.....god efterårs ferie :)
F.eks. hvornår man skal vælge en linked list eller en array baseret container. Det er god universel viden man kan bruge i alle sprog :)
Det svarer lidt til at lære at smugle en flaske vodka med i lommen, istedet for at lære at bestille 20 øl på alle sprog.
Med vodka metoden har du en metode der vil virke i barer i alle lande, og det er bare mest effektivt.
Alternativet er at skulle lære at bestille både øl og sprut på ny hver gang du kommer til et nyt land.
skål.....god efterårs ferie :)
http://www.codinghorror.com/blog/2007/11/mort-elvis-einstein-and-you.htmlsquad2nd (27) skrev:Der er nogen programmører der mener at man ikke er en rigtig programmør hvis man ikke ved hvordan en given implementation er udviklet eller kan løse og læse de mest avancerede matematiske algoritmer (total waste hvis det ikke har noget med ens forretningsområde at gøre).
Jeg er stadigvæk ikke enig i at en programmørs ansvar kun er for de matematiske emner.Ildhesten (28) skrev:Hvis man ikke har ambitioner om mere end fx at skrive "The average web-app", så lad være med at lære om algoritmer, så simpelt er det.
Jeg ser faktisk at vores ansvar i dag handler mere om artkitektur, test og skalerbarhed. Og skalerbarhed inden for web-apps handler mere om domæne-viden end det handler om algoritmer.
Der er ingen synd i at specialisere sig i emner der mere ingeniør praktiske, end det er datalogisk teori.
Windcape (23) skrev:
Jeg har ikke haft brug for big O analyse nogensinde i praktisk programmering.
Og det er fordi at enten er der allerede taget hånd om det i de APIs jeg bruger,
eller også er det ikke relevant.
Alt arbejde med "mange af samme slags" har brug for big O.
Det inkluderer bl.a. brug af collections og databaser tabeller.
Windcape (23) skrev:
Kendskab til SCRUM giver dig højere chance for at lande et job, end kendskab til FFT.
Specielt når det er HR afdelingen som foretager interviewet.
Uden tvivl.
Hvis man prioriterer at score max. i keyword matching hos HR, så er det med at kende alle de rigtige teknologier og metodikker mens evnen til at udvikle software er mindre vigtig.
Windcape (23) skrev:arne_v (21) skrev:Givet at skalerbarhed vel definitorisk er O(n) egenskab, så ...
Skalerbarhed for web handler mere om kendskab til cache. Hvordan vil du definere brugen af et webcache system i form af O(n) ?
Og har det overhovedet nogen relevans for den praktiske udførsel? I think not!
Nej.
Cache forbedrer normalt performance men ikke skalerbarhed.
Og cache er vigtig for performance, men det er ikke den eneste faktor.
Windcape (23) skrev:Men evnen til at forstå og bruge IoC er af en højere praktisk værdi, som betyder du udfør dit arbejde bedre.
Efter min mening er der ikke nogen egenskab som har større praktisk værdi for en udvikler end evnen til at løse et vanskeligt problem hvor løsningen ikke er kendt på en god måde.
Windcape (25) skrev:Optimering via. big O analyse er relevant på algoritmer, som typisk udmunder i en form for iteration og/eller søgning.
Korrekt.
Windcape (25) skrev:Men i det meste software jeg har arbejdet med, er søgning noget som foretages af en database, og derfor igen, er optimeringsdelen abstraheret væk.
Jeg gætter på at du også engang imellem bruger nogle collections krydret med lidt LINQ og lambda expressions.
Men derudover er det da en misforståelse at tro at big O ikke er relevant for almindelige databaser - det er skam særdeles relevant.
Windcape (25) skrev:Tag en helt almindelige side som newz.dk -- Hvor ville du i dine vildeste drømme forestille dig at man har brugt big O analyse til at optimere siden?
Jeg kender ikke newz.dk koden, men jeg har en stærk mistanke om at der bruges PHP arrays og/eller database tabeller.
squad2nd (27) skrev:Fx skalering, som man næsten får serveret på et sølvfad hvis man skriver sin kode ordenligt og spiller indenfor fx .NET og Java's regler for application server clustering/skalering.
Det hjælper meget hvis man holder sig indenfor et meget veldefineret framework.
Men ved ihærdig indsats kan en udvikler sagtens ødelægge skalerbarheden uanset hvor godt frameworket er.
squad2nd (27) skrev:Noget andet er selvfølgelig algoritmer og collections. De er sjove at studere, men er totalt waste at skrive selv hvis der allerede eksisterer et library der kan tage sig af de grumme detaljer.
Det er meget sjældent at der er brug for selv at lave en ny collection type.
Men man har brug for at forstå egenskaberne ved de eksisterende.
De basale søg og sorter algoritmer er normalt også implementeret i ens standard library.
Men har altså også brug for at implementere algoritmer som ikke findes prædefineret.
squad2nd (27) skrev:Der er nogen programmører der mener at man ikke er en rigtig programmør hvis man ikke ved hvordan en given implementation er udviklet eller kan løse og læse de mest avancerede matematiske algoritmer (total waste hvis det ikke har noget med ens forretningsområde at gøre).
Man bør have evnen til selv at udvikle en løsning.
Hvis der findes en eksisterende løsning bør man genbruge den.
Men hvad nu hvis der ikke findes en eksisterende løsning, så er man jo nødt til selv at finde en løsning.
Windcape (31) skrev:Jeg er stadigvæk ikke enig i at en programmørs ansvar kun er for de matematiske emner.
Det er der vist heller ingen som har hævdet.
Men det er blevet hævdet at det er en nødvendig del af en programmørs toolbox.
Og der er rimelig solid erfaring for at folk med en uddannelse med pæn matematik kan blive gode programmører.
Software udvikling er fuldt med fysikere, astronomer, kemikere, statistikere, rigtige matematikere, elektro ingeniører, bygnings ingeniører og lignende godt folk.
Windcape (31) skrev:Jeg ser faktisk at vores ansvar i dag handler mere om artkitektur, test og skalerbarhed. Og skalerbarhed inden for web-apps handler mere om domæne-viden end det handler om algoritmer.
Nej.
Problemstillingen vil definere de bedst mulige skalerings egenskaber.
Men det er teknik at opnå denne.
Og der er masser af erfaring for at uanset hvor dårlig den bedst mulige løsning er, så er det altid muligt at finde en dårligere.
Windcape (31) skrev:Der er ingen synd i at specialisere sig i emner der mere ingeniør praktiske, end det er datalogisk teori.
Jeg tror at der er lidt forskel på ingeniører. DTU uddanner bl.a. folk med ekspertise i formelle metoder o.lign..
Ja. Og igen, her er det eneste du har brug for at vide, er hvilken algoritme der er bedst til dit givne datasæt, og kunne forstå performance beskrivelsen (ie. quickshort er O(nlogn)).arne_v (33) skrev:Jeg kender ikke newz.dk koden, men jeg har en stærk mistanke om at der bruges PHP arrays og/eller database tabeller.
Det er langt fra at kunne forstå (eller overhovedet have lært) den matematiske baggrundsviden, eller dybere forståelse for emnet!
Uden domæneviden vil man slet ikke have kompetancerne til at forstå problemstillingen i første omgang, og slet ikke til at vælge løsning.arne_v (36) skrev:Nej.
Problemstillingen vil definere de bedst mulige skalerings egenskaber.
Men det er teknik at opnå denne.
Og at udvikle løsningen (ie. et værktøj eller API til formålet) skal gøres med et helt andet perspektiv end at løse et domænespecifikt problem.
Med formålet med formelle metoder er jo hovedsageligt at forskel. Det er jo ikke just et særlig udbredt konceptet i praktis.arne_v (36) skrev:Jeg tror at der er lidt forskel på ingeniører. DTU uddanner bl.a. folk med ekspertise i formelle metoder o.lign..
Windcape (37) skrev:Ja. Og igen, her er det eneste du har brug for at vide, er hvilken algoritme der er bedst til dit givne datasæt, og kunne forstå performance beskrivelsen (ie. quickshort er O(nlogn)).
Der har du så ikke helt styr på din algoritmik alligevel, den forventede kørselstid for en randomiseret QuickSort er højst O(n lg(n)). Worst case kørselstiden er stadig O(n^2). Selv om det er meget sjældent at det forekommer i praksis.
Se evt. "Randomized Algorithms" af Rajeev Motwani og Prabhakar Raghavan.
#39 Der er en normal brugt konvention at skrive at 2-talslogaritmen som lg. Hvis du tænker over hvad O-notationen er, så er det en øvre grænse for kørselstiden, skriver du O(n^2) mener du at n^2 er en øvre grænse for det antal operationer som algoritmen i værste fald skal udføre. Hvis du skriver O(n lg n) uden videre angivelse, er det rimeligt at du antager algoritmen er øvre begrænset af O(n lg n), men det er ikke altid tilfældet. Derfor er det mest korrekte at læse O som worst case, med mindre andet er eksplicit angivet, som fx når der står forventet, og lad nu være med at forsvare dit sjuskeri.
I et dokument/bog/artikel måske, ikke i en samtale/diskussion.Ildhesten (42) skrev:Derfor er det mest korrekte at læse O som worst case, med mindre andet er eksplicit angivet
Her snakker man altid om average/best case. Sammenligninger er typisk også altid best-case, da det for de fleste handler om "hvad kan køre hurtigest på vores type data".
Lad nu være med at forsvare du ikke kan læse.Ildhesten (42) skrev:lad nu være med at forsvare dit sjuskeri.
Wikipedia er forresten enig med mig i at man overordnet beskriver big O performance med average case performance.
Så det er mig + internettet mod dig.
nu bliver jeg altså nødt til at spørge dig windscape:
Hvor meget ægte erfaring har du med programmering i erhvervslivet?
Jeg er ofte uenig i dine filosofiske antagelser om hvad der skal til for at man er en god/nyttig arbejdskraft- som du ofte udtaler dig om.
Det er ikke noget angreb- dine ideér minder bare meget om mine egne mens jeg studerede.
Hvor meget ægte erfaring har du med programmering i erhvervslivet?
Jeg er ofte uenig i dine filosofiske antagelser om hvad der skal til for at man er en god/nyttig arbejdskraft- som du ofte udtaler dig om.
Det er ikke noget angreb- dine ideér minder bare meget om mine egne mens jeg studerede.
#43 Smid lige den wiki reference der siger at forventet kørsel har præcedens over worstcase når man bruger O-notation. Så kan vi snakke, gerne som quote.
Desuden bruger man lille omega notation til at nedre begrænse notation ikke store O. Tilbage til skolebænken med dig.
Måske i en samtale med dig, men de fleste jeg har snakket med mener at når O står uden andet angivet, hvad end det har været professorer i datalogi, bøger, artikler eller bare medstuderende er det worst case O henviser til, ikke forventet performance. At man så ofte vælger at bruge den til average performance kan forsvares fordi man eksplicit smider "forventet" foran. Jeg sætter min lid til resten af verden, mod dig og din drømmeverden.
Desuden bruger man lille omega notation til at nedre begrænse notation ikke store O. Tilbage til skolebænken med dig.
Windcape (43) skrev:I et dokument/bog/artikel måske, ikke i en samtale/diskussion.
Her snakker man altid om average/best case. Sammenligninger er typisk også altid best-case, da det for de fleste handler om "hvad kan køre hurtigest på vores type data".
Måske i en samtale med dig, men de fleste jeg har snakket med mener at når O står uden andet angivet, hvad end det har været professorer i datalogi, bøger, artikler eller bare medstuderende er det worst case O henviser til, ikke forventet performance. At man så ofte vælger at bruge den til average performance kan forsvares fordi man eksplicit smider "forventet" foran. Jeg sætter min lid til resten af verden, mod dig og din drømmeverden.
Windcape (43) skrev:I et dokument/bog/artikel måske, ikke i en samtale/diskussion.
Her snakker man altid om average/best case. Sammenligninger er typisk også altid best-case, da det for de fleste handler om "hvad kan køre hurtigest på vores type data".Lad nu være med at forsvare du ikke kan læse.Ildhesten (42) skrev:lad nu være med at forsvare dit sjuskeri.
Wikipedia er forresten enig med mig i at man overordnet beskriver big O performance med average case performance.
Så det er mig + internettet mod dig.
Hvad er det for en omgang vrøvl!
Det er sgu aldrig underforstået at O(n) er best-case køretiden! Tag for eksempel en eller anden bogus-sort algoritme der kører således:
while not sorted:
shuffle elements into next permutation
I best-case er array'et allerede sorteret og det skal kun verificeres, hvilket tager O(n) tid. I worst-case tager det O(n!) (dvs. O af n fakultet), hvilket er pænt langt fra O(n).
Jeg vil gerne se det wikipedia-citat.
Og btw, O(ln n) = O(lg n) = O(log n).
Det er meget almindeligt at man skal bruge en datastruktur der ikke er at finde i X standard library. Så er man nødt til at kunne designe både datastrukturen og de tilhørende operationer på denne. Så er det praktisk at kunne analysere ens algoritme for operationerne for at være sikker på at man ikke har skrevet noget der kører elendigt.
Quicksort is a sorting algorithm developed by C. A. R. Hoare that, on average, makes O(nlogn) (big O notation) comparisons to sort n items.http://en.wikipedia.org/wiki/Quicksort
Happy now?
Hvem har snakket om det? Kun dig hvis nogen. Du skal vist have dine skolepenge i Dansk tilbage, hvis du ikke kan læse.Ildhesten (46) skrev:Desuden bruger man lille o notation til at nedre begrænse notation ikke store O. Tilbage til skolebænken med dig.
"forventet" != "average". Utrolig dårligt ord at bruge.Ildhesten (46) skrev:at man så ofte vælger at bruge den til average performance kan forsvares fordi man eksplicit smider "forventet" foran.
Godt jeg sjældent debattere det på dansk. Og godt det endnu mere sjældent er med fjollede teoretikere.
Jeg sætter min lid til min litteratur og internettet, frem for fjolser som dig der ikke kan læse, og ikke har den fjerneste ide om en diskussion fra et praktisk synspunkt.Ildhesten (46) skrev:Jeg sætter min lid til resten af verden, mod dig og din drømmeverden.
Det er jo tydeligt at se at du er en verdensfjern teoretiker.
Nej, det er sku ikke meget almindeligt at sidde og designe egne graf/træ strukturer.onetreehell (47) skrev:Det er meget almindeligt at man skal bruge en datastruktur der ikke er at finde i X standard library. Så er man nødt til at kunne designe både datastrukturen og de tilhørende operationer på denne.
Og hvis du mangler andet, er det vel fordi du bruger C/C++ eller et eller andet niche sprog uden et ordenlig bagvedliggende framework.
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
- ⟨
- Tagwall
Gå til bund