[alg] Eerst basics of meteen best practices leren?

[flowerp]

Vroeger (ja ja, oma spreekt) begonnen we altijd heel basic met programmeren. De meeste van de iets oudere generatie zullen met basic (wat vroeger nog echt basic was), assembly of iets procudereels begonnen zijn.

Tegenwoordig zitten we op een wat hoger niveau dan vroeger. Was OOP in mijn tijd nog iets academisch voor de anti-mainstream mensen, tegenwoordig is het gewoon harstikke ingeburgerd en absoluut een "best practice". Nu zit ik me al een tijdje af te vragen waarmee beginners vandaag de dag nou moeten beginnen met programmeren. Er lijken over het algemeen twee kampen te zijn.

Het ene kamp zegt eigenlijk dat nieuwe mensen net zo moeten beginnen als zij zelf ook ooit begonnen zijn. Voor C++ betekent dat bv C achtig beginnen. Geen STL maar zoveel mogelijk C libs. Dus niet de classe string gebruiken of de vector en andere collection classes, maar char*'s en native arrays. Geen GUI (event driven) apps, maar console applicaties en cout.

En zelfs voor talen die veel low-level constructies niet kennen zie je dan hetzelfde. Mensen die met Java willen beginnen wordt aangeraden eerst met enkel JSP's aan de gang te gaan en daar dan maar vooral veel Java code op te kwakken, want de mensen die ooit met Java begonnen schreven eerst ook alleen maar JSP's (zonder JSTL of JSF).

Het andere kamp zegt eigenlijk precies het tegenovergestelde. Het gebruik van char*'s in C++ voor strings is volkomen deprecated. Best practice is om gewoon de [i]string[/b] class te gebruiken. Dit levert betere, veiligere en vooral makkelijkere code op. Het argument van het basic kamp is dat je makkelijk moet beginnen, maar is een char* echt makkelijker dan een string class? In de praktijk blijkt juist dat die string class velen malen makkelijk is en beginners die dan ook liever gebruiken (zelfs als het eigenlijk niet 'mag' op een school omdat ze 'dat nog niet gehad hebben').

Het zelfde geldt voor JSP vs JSF. JSP's zijn veel meer low-level. Je moet zelf itereren over datasets, zelf met low-level stuff als request parameters en HTML rommelen, terwijl je in JSF gewoon een component tag op je pagina zet, deze een dataset geeft en hij wordt gedisplayed (vergelijk ook met ASP.NET). Eigenlijk veel makkelijker. Toch zeggen mensen altijd dat je pas met JSF kan beginnen als je echt geavanceerd bent. Exact een zelfde verhaal kan opgehangen worden voor console apps in java vs iets met Swing ofzo.

De bottomline is, is het verstandig om mensen eerst een basis te leren, terwijl die basis eigenlijk precies is wat mensen niet moeten doen in het echt, of leer je ze eerst de gangbare best practices en laat je ze pas als ze wat verder zijn kennis maken met de onderliggende basis?

[LordLarry]

Joel On Software verwoord het mooi:

"One reason the law of leaky abstractions is problematic is that it means that abstractions do not really simplify our lives as much as they were meant to. When I'm training someone to be a C++ programmer, it would be nice if I never had to teach them about char*'s and pointer arithmetic. It would be nice if I could go straight to STL strings. But one day they'll write the code "foo" + "bar", and truly bizarre things will happen, and then I'll have to stop and teach them all about char*'s anyway. Or one day they'll be trying to call a Windows API function that is documented as having an OUT LPTSTR argument and they won't be able to understand how to call it until they learn about char*'s, and pointers, and Unicode, and wchar_t's, and the TCHAR header files, and all that stuff that leaks up."

http://www.joelonsoftware...es/LeakyAbstractions.html

[kenneth]

Joel legt The Law of Leaky Abstractions uit, hij trekt geen conclusie eruit, voor zover ik lees.

Er is m.i. een groot grijs gebied: een Quick Sort aanleren terwijl in ieder zichzelf respecterend framework een SortedList of whatever zit, is nog enigzins te verdedigen. Maar assembly gaan aanleren voor mensen die nooit real time software gaan ontwikkelen? Tsja ...

Procedureel programmeren is leuk voor historische doeleinden, maar ik zou toch echt gaan voor OO.

[flowerp]

LordLarry schreef op zondag 08 januari 2006 @ 21:01:
Joel On Software verwoord het mooi:

[...]

http://www.joelonsoftware...es/LeakyAbstractions.html

In Joel's stuk lees ik vooral met nadruk het stukje: "[...] Or one day [...] ".

Natuurlijk, als profesional moet je niet alleen code schrijven maar ook code lezen, en natuurlijk code van andere aanroepen. Maar dat doe je over het algemeen pas in een later stadium.

Mijn punt was niet helemaal of je het moeten kennen of niet (dat is ook wel een interesante discussie hoor, moeten wij vandaag de dag nog weten hoe punch-cards werkten?). Waar mijn punt echter vooral om ging is of je er mee moet beginnen om niet. Het ging dus meer om de volgorde van leren zeg maar. Voor de ene groep is char* iets wat eigenlijk alleen voor beginners is, en leer je later gewoon dat string veel beter is, terwijl de andere groep juist zegt dat string veel makkelijker is, en dat pas als je verder bent en wat onderliggende code gaat lezen / gebruiken je moet weten wat een char* is.

Procedureel programmeren is leuk voor historische doeleinden, maar ik zou toch echt gaan voor OO.

Denk ik zelf ook. Toch denken heel veel scholen en zelfs universiteiten hier nog anders over. Ik klapperde dan ook met mijn oren van verbazing toen ik hoorde dat iemand die informatica ging studeren aan de universiteit van leiden bij het vak waar ze C++ leren niet van STL gebruik mocht maken, maar waar ze bijna alleen met native constructies werkten. (hoewel dat voor de universiteit mischien nog verdedigbaar is, die lui moeten immers vooral concepten leren en worden niet perse voor een best-practices programmeur opgeleid).

Practisch gezien vraag ik me ook af hoe je het beste met web programmeren kan beginnen. Ga je daar ook nog eerst het oude "html met itteratieve-code mixen" aanleren, of begin je meteen aan te leren web components / controls te gebruiken (zoals DataGrid in ASP). Wat voor zin heeft het om mensen eerst te leren hoe ze over een dataset moeten ittereren en dan handmatig HTML td's en tr's te outputten, als ze dan in de praktijk gewoon hun dataset aan een datagrid geven en zich dus nooit met die low-level details zullen bezighouden?

[ Voor 36% gewijzigd door flowerp op 08-01-2006 21:41 ]

[bigbeng]

@kenneth:
Procedureel is minder ver van OO dan assembly zou ik durven beweren. Ik zou ze dan ook niet over 1 kam scheren. Anyhow, er wordt op de meeste scholen (HBO iig) voornamelijk OO geprogrammeerd, dus ik denk dat scholen in zijn algemeenheid het met jou eens zijn.

@TS:
Ik ben zelf een aanhanger van eerst basisvaardigheden opdoen en dan pas met de echte tools aan het werk. En dat is niet omdat ik geloof in makkelijk beginnen, da's iets voor de eerste les, maar ook omdat je behalve programmeren ook een basiskennis van dat kreng dat een computer heet moet hebben. Het gedrag van een computer is daar dus een essentieel onderdeel van. Ik denk dan ook, dat je meer over het wel en wee van een computer leert als je leert hoe je met chars, ints (8,16,32,64 bit, whatever) en pointers moet omgaan. Assembly kan daarin ook nuttig zijn, maar voert voor HBO/MBO wat ver door. Met dat in het achterhoofd zou ik het ook beter hebben gevonden als mijn school (HBO) C++ als basistaal had gekozen ipv Java. Maar goed, zelfs met Java kun je al een eind komen.

Nu dan een reactie op je JSP verhaal: ik ben van mening dat je prima OO principes kunt naleven zonder dat je jezelf inlaat met JSF, Spring, Struts of welk framework dan ook. Echter, die frameworks zijn bedoeld om je het leven makkelijker te maken (tenminste dat hopen we ).

Concluderend:
Ik denk dat het dus ook zeker mogelijk moet zijn om zonder dergelijke frameworks te beginnen en dat geleidelijk aan te introduceren. Eerst de ins en outs van de taal opdoen, daarvoor zit je immers op school. Ik denk ook dat er meer bij programmeren komt kijken dan alleen het kunnen gebruiken van een IDE en de diverse toolkits.

[Gerco]

Ik vind dat Joel het in Back to basics veel beter verwoord

Leer eerst hoe het werkt en dan hoe de computer dat bijna allemaal voor je kan doen. Als je niet weet hoe het werkt, kun je ook eventuele problemen niet oplossen als het niet helemaal werkt zoals het zou moeten (wanneer de abstractie lekt, tnx Joel).

Ik ben altijd erg geinteresseerd geweest in hoe computers op laag nivo werken (tot op microcode nivo, hoe de transistors precies de bewerkingen uitvoeren weet ik niet). Ik merk dat die kennis van hoe dingen op laag nivo werken me helpt om dingen beter te begrijpen dan mijn collega's die dat niet weten.

Bijvoorbeeld COM objecten, ik heb met een aantal mensen gewerkt aan een VB6 applicatie die uit honderden COM objecten bestond. Af en toe ging er iets fout, de app riep een verkeerde versie van een component aan bijvoorbeeld, de meeste collega's konden zoiets moeilijk oplossen omdat ze niet begrepen wat er nu eigenlijk mis was. De mensen die wel wisten hoe COM intern werkt, konden dit soort dingen makkelijk oplossen.

Ander voorbeeld:
Ik heb een jaar aan een ASP.NET webapplicatie gewerkt met allerlei mensen van verschillende kennisnivos. Sommigen programmeerden prima applicaties, maar er zaten dan regelmatig enorme security fouten in, zoals SQL injections en soms zelfs plain SQL execution(!). Omdat die mensen geen idee hadden wat er nu echt gebeurde, maakten ze die fouten. De mensen die het wel wisten, maakten die fouten dus niet.

[ Voor 60% gewijzigd door Gerco op 08-01-2006 21:49 ]

[kenneth]

bigbeng schreef op zondag 08 januari 2006 @ 21:42:
@kenneth:
Procedureel is minder ver van OO dan assembly zou ik durven beweren. Ik zou ze dan ook niet over 1 kam scheren.

Daarom zat er ook een witregel tussen
Hoe inactueel mag een technologie zijn voordat je hem naast je legt, daar ging het om.

[EfBe]

Eerst basisbegrippen, dan specifieke zaken en de daarbij horende best practises. Best practises horen altijd bij toepassingen van theorie, niet bij theorie zelf. Leer eerst de theorie en daarna dus de best practises, anders ben je truukjes aan het leren en geen echte kennis en dus al helemaal geen wijsheid.

Ik bedoel: de hedendaagse armoede vwb algoritme-kennis is stuitend: men negeert de basisbouwsteen van elk stukje software: het algoritme. Begin daar dus mee: basisbegrippen. Succes!

[flowerp]

bigbeng schreef op zondag 08 januari 2006 @ 21:42:
Nu dan een reactie op je JSP verhaal: ik ben van mening dat je prima OO principes kunt naleven zonder dat je jezelf inlaat met JSF, Spring, Struts of welk framework dan ook.

Het gaat dan natuurlijk alleen om dingen die standaard in een taal / platform zitten. 3rd party frameworks zijn natuurlijk niet echt een kandidaat voor een beginner. Dus C++ beginners wel met STL laten werken, maar niet met Boost (ook al zitten daar een paar erg makkelijk te gebruiken dingen in).

Voor het JSP verhaal; Spring & Struts zijn 3rd party dingen, maar JSF komt gewoon standaard in Java. Dat is een redelijk groot verschil. In ASP.NET zie je het zelfde. Al die web controlls zitten gewoon standaard in het platform. Het is geen apart framework. Ga je ASP mensen nu eerst leren hoe ze een simpele list ofzo met een datagrid op het scherm zetten, of laat je ze eerst wat met C# loops rommelen direct op een pagina?

Overigens ben ik zeer zeker een voorstander van zoveel mogelijk basis kennis opdoen. Als je echt verder gaat met je vak dan moet je zeker eens assembly gezien hebben, weten hoe een CPU werkt, hoe de computer architectuur in elkaar zit, hoe een OS werkt, hoe je zelf een compiler of een CPU emulator bouwt etc etc. (edit: en zoals efbe zegt, kennis van wiskunde, algortimes en fundamentele informatica als turing machines, FSM's etc)

Waar het gedeeltelijk omgaat is ook de vraag van wat is de norm, en wat is 'extra' & verbredend? Is procudereel de norm en is OO verdiepend, of is OO de norm en is procudereel verdiepend? Het punt is dat we steeds meer high-level gaan werken. Over 10 jaar is mischien OO low-level en is AOP of SOA de norm. En over nog maals 10 jaar is mischien XXX de norm. Volgens aanhangers van "basis eerst" zullen mensen dan steeds meer basis moeten leren voordat ze bij de norm aankomen. Dus in het laatste geval eerst assembly, dan procudereel, dan OO, dan AOP en dan pas komen ze aan bij XXX. Over 100 jaar kun je je dan afvragen of mensen ooit nog bij de norm aan kunnen komen.

[ Voor 4% gewijzigd door flowerp op 08-01-2006 22:03 ]

[Not Pingu]

flowerp schreef op zondag 08 januari 2006 @ 20:44:
Het ene kamp zegt eigenlijk dat nieuwe mensen net zo moeten beginnen als zij zelf ook ooit begonnen zijn. Voor C++ betekent dat bv C achtig beginnen. Geen STL maar zoveel mogelijk C libs. Dus niet de classe string gebruiken of de vector en andere collection classes, maar char*'s en native arrays. Geen GUI (event driven) apps, maar console applicaties en cout.

Zoals alle antwoorden in de IT, begint de mijne ook met: "Dat hangt ervan af".
Je hebt niet echt gespecificeerd over wat voor iemand we het hebben. Is het iemand die nog geen concept heeft van wat programmeren inhoudt, en wil weten of het wat voor hem/haar is? Of is het iemand die redelijk beta-aanleg heeft, al het een en ander van computers weet (en misschien zelfs programmeren in whatever taal/platform kent) en die gemotiveerd is?

Kijk, perfectie bereik je vanzelf wel als je gedreven bent en zelf op onderzoek uitgaat. Zeker in het begin zou ik met een ding tegelijk beginnen, want iemand die nog niet de programmeur-mindset heeft, krijgt al moeite genoeg met typfouten, rare formuleringen en de exacte manier waarop in- en output verwacht wordt.

Als ik terugga naar hoe ik het geleerd heb, dan heb ik een hoop van de pietluttige/low level dingen later zelf uitgezocht, maar dat had ik nooit gekund zonder een zekere basis. Best-practices leer je vanzelf wel, en als mensen niet uit hun aangeleerde patroon kunnen breken om zich andere concepten of werkwijzen eigen te maken, dan zijn ze sowieso niet erg geschikt als programmeur

Ik ben het er wel mee eens dat je kennis van low-level zaken moet hebben. Ik als webdeveloper ben ook begonnen met de barebones scriptingtaaltjes waarin je zelf elk stukje HTML intypt. Nu ik met ASP.NET werk, heb ik die kennis vaak nodig om problemen op te lossen of bepaalde dingen te realiseren, maar iemand die in ASP.NET begint kan dat allemaal makkelijk negeren.
Dus zou je zeggen, laat zo iemand met PHP beginnen.

Het hangt er nogmaals vanaf om wat voor persoon het gaat. Als het iemand is die als hobby wat bij wil klooien, maak het dan zo makkelijk mogelijk. Als het iemand is die er professioneel mee verder moet, laat diegene dan zoveel mogelijk de basis verkennen en beheersen voordat je een voor een de diepere concepten aanleert.

Anyway, that's my opinion.

[Calvin&Hobbes]

Ben zelf een beginner en vanuit een beginners point of view, vindt ik best practices en daarna de basics een praktische volgorde (logischer zou zijn basics en dan best practices) puur omdat het me eigenlijk in het begin nog niks kan schelen wat er in de lower levels gebeurt, als het maar werkt (moeten mensen maar een snellere pc kopen )

[Verwijderd]

ja, het ligt er net aan of je programmeur wilt worden of als je een kijkje wilt nemen in hoe het leven van een programmeur eruit ziet..

denk dat het afhankelijk is welke niveau (mbo/hbo/uni) en wat men ermee wilt doen (en natuurlijk tijd)...

[Ivo]

Calvin&Hobbes schreef op maandag 09 januari 2006 @ 01:09:
Ben zelf een beginner en vanuit een beginners point of view, vindt ik best practices en daarna de basics een praktische volgorde (logischer zou zijn basics en dan best practices) puur omdat het me eigenlijk in het begin nog niks kan schelen wat er in de lower levels gebeurt, als het maar werkt (moeten mensen maar een snellere pc kopen )

En voor je het weet zit er een enorme exploit in je applicatie, waardoor een bedrijf schade lijdt.

[.oisyn]

Als beginnend programmeur werk je dan ook niet bij een bedrijf maar zit je op school, denk je ook niet Ivo?

En een zichzelf respecterende school zou imho beide aan moeten leren: zowel hoe system werken op microniveau (datastructuren, algoritmen, etc.) als op macroniveau (applicatie- en systeemontwerp, waarbij een vraag als 'hoe concateneer je twee strings' uiteraard onnodige details zijn). En ik denk dat de volgorde daarbij niet eens uitmaakt, veelal gebeurt het zelfs parallel aan elkaar, door die twee gebieden op te delen in aparte vakken.

[ Voor 76% gewijzigd door .oisyn op 09-01-2006 03:09 ]

[Mephix]

Ik zou toch zeker kiezen voor wat historie en basics.. wat je ziet is dat een hoop beginners vastlopen en zich eigenlijk geen raad weten hoe te zoeken naar de oplossing, omdat ze niet begrijpen wat de achterliggende gedachte/structuur is.

Ze hebben zich nooit een manier van denken eigen gemaakt, waarmee je begrijpt hoe zaken in elkaar steken en wat de consequenties kunnen zijn van je code.

Eigenlijk vind ik dit ook gelden voor zaken buiten het programmeren om.. Systeembeheerders moeten m.i. ook kunnen werken met fdisk of format of whatever en niet alleen hun weg kennen binnen windows of een andere grafische omgeving. Niet dat je dat iedere dag nodig gaat hebben, maar er komt een moment dat een applicatie niet start omdat bijv. een pad in je %path% mist.. ik noem maar wat.. mensen met een dos achtergrond snappen direct wat er aan de hand is en lossen het zonder moeite op.. iemand met enkel windows ervaring kan zich een slag in de rondte zoeken zonder succes.

Het voorbeeld is misschien wat flauw, maar het gaat mij er maar om dat mensen begrijpen hoe zaken werken en niet, bijna geconditioneerd, te werk gaan door probleem A met oplossing B te verbinden.

Ivo schreef op maandag 09 januari 2006 @ 02:12:
[...]

En voor je het weet zit er een enorme exploit in je applicatie, waardoor een bedrijf schade lijdt.

Dit is ook een belangrijk punt idd.. door de basics te kennen overzie / doorzie je het geheel en voorkom je dat je door onwetendheid de zaak niet goed afdicht.

[ Voor 14% gewijzigd door Mephix op 09-01-2006 11:53 ]

[Ivo]

.oisyn schreef op maandag 09 januari 2006 @ 03:04:
Als beginnend programmeur werk je dan ook niet bij een bedrijf maar zit je op school, denk je ook niet Ivo?

En een zichzelf respecterende school zou imho beide aan moeten leren: zowel hoe system werken op microniveau (datastructuren, algoritmen, etc.) als op macroniveau (applicatie- en systeemontwerp, waarbij een vraag als 'hoe concateneer je twee strings' uiteraard onnodige details zijn). En ik denk dat de volgorde daarbij niet eens uitmaakt, veelal gebeurt het zelfs parallel aan elkaar, door die twee gebieden op te delen in aparte vakken.

Inderdaad, zolang je het maar gehad hebt.

[Verwijderd]

Hallo

Ik zelf ben voorstander van eerst een basis te leggen in een procedurele taal (zoals C). Ik geef toe dat veel dingen die je dan maakt elegant(er) met een OO taal, zoals Java/C++ op te lossen zijn, maar een gefundeerde basis vind ik echt wel onontbeerlijk. Het schrijven van methods zal dan volgens mij eenvoudiger gaan als je eerst procedureel geschreven hebt, en dan kan de "programmeur in spe" zich meer concentreren op het toepassen van de "OO-wetten".

Verder mag ook niet uit het oog verloren worden dat niet alles met OO kan gedaan worden. Stel nu bv het programmeren van een embedded system, of nog lagen: een microcontroller. Dit gebeurt tegenwoordig (vaak) niet meer in assembler, maar in C ofzo. Op zo een 16 bit dingetje met hoop en al 16k geheugen en een harware stack van 16 lagen moet je geen objecten gaan instantieren, want dan zit de Stack en het werkgeheugen toch direct vol... En zo zijn er nog veel voorbeelden van programmeeromgevingen waar OO niet toepasbaar is.

En aangezien men niet weet waar de student ooit terecht zal komen later,vind ik het dus beter ook een goede procedurele basis te geven, aangezien dit het OO gebeuren ondersteunt. Als je het dan echt wil doordrijven, kan je als ondersteuning van de procedurele taal (vb C, wat eigenlijk Assembly met een IF structuur is ) assembler/microprocessortechniek geven. Maar dit is dan denk ik voor een Webapplicatie-programmeur niet zo belangrijk, omdat hij er (bijna) nooit met in contact zal komen, maar voor die embedded-systems programmer dan juist wel weer belangrijk, omdat hij op 1 niveau erboven werkt.

Bottom-line: Ik vind dat elke programmeur een (basis)kennis zou moeten hebben van het niveau onder het niveau wat hij gebruikt:
zo moet een assemblerprogrammer de kennis hebben van de microcodes/processoropbouw/Digitale techniek
een C programmer zouden wat assembly en geheugenstructuren enzo moeten kennen
en OO-programmeurs zouden een procedurele basis moeten hebben.

Just my five Cents...
MvG
Jan

[ Voor 3% gewijzigd door Verwijderd op 09-01-2006 12:24 ]

[Soultaker]

Iedereen is het er mee eens is dat een goede programmeur zowel 'high level' ontwerpprincipes kent, die nodig zijn om correcte, onderhoudbare applicaties te ontwerpen, als 'low level' implementatiedetails, die belangrijk zijn om veilige, efficiënte code te kunnen schrijven en te kunnen debuggen. De vraag van de TS komt dus vooral neer op: wat leer je éérst?

Ik denk dat in principe 'high level' onderwerpen voorrang hebben; dat is uiteindelijk waar het om gaat. De low level onderwerpen worden dan behandeld voor zover ze de high level onderwerpen ondersteunen. Ik heb namelijk het idee dat het erg lastig is voor mensen om low level details te begrijpen zonder te weten waar die voor gebruikt worden. Het is veel simpeler om éérst uit te leggen hoe (bijvoorbeeld) een linked list in elkaar zit en welke operaties je er mee kunt doen, en dan pas uit te leggen hoe die geïmplementeerd wordt.

EfBe schreef op zondag 08 januari 2006 @ 21:52:
Ik bedoel: de hedendaagse armoede vwb algoritme-kennis is stuitend: men negeert de basisbouwsteen van elk stukje software: het algoritme. Begin daar dus mee: basisbegrippen.

Ik heb het idee dat mensen die al kunnen programmeren kennis over algoritmen veel sneller oppikken dan mensen die dat niet kunnen. Dat komt naar mijn idee weer doordat die al relevante kennis hebben van welke constructies er mogelijk in een programmeertaal. Ik zou dus zeker mensen willen aanraden om eerst wat simpele dingen te programmeren, voordat ze zich aan geavanceerde algoritmen (en minstens zo belangrijk: datastructuren) wagen.

Waar jij je aan ergert is volgens mij dat veel mensen niet genoeg weten van algoritmen en datastructuren op zich; dat is iets heel anders natuurlijk. De vraag is niet of je het moet weten, maar in welke volgorde je het moet leren.

[Michali]

Hoe staan jullie er tegenover om iemand die met OO begint gelijk aan de design patterns te laten gaan? In principe zijn design patterns best practices voor bepaalde problemen en kan het ook goed helpen om OO snel en effectief onder de knie te krijgen. Zelf ben ik er redelijk snel mee begonnen. Ik wilde echt OO leren, en goed, en ben daarom gelijk met design patterns begonnen. Dat heeft mij iig erg goed op weg geholpen.

[.oisyn]

Het lijkt me echter wel handig om te weten welk probleem een bepaald design pattern precies oplost. Ik prefereer zelf iig altijd de aanpak om eerst zelf te proberen, en dan te kijken naar wat anderen hebben gedaan. Dat geeft, naar mijn idee iig, een beter idee van waarom een dergelijke oplossing is gekozen, en wat de voor- en nadelen ervan zijn.

Ik zag het in je vorige post ook al; "principe" schrijf je met één e

[Michali]

.oisyn schreef op maandag 09 januari 2006 @ 17:14:
Het lijkt me echter wel handig om te weten welk probleem een bepaald design pattern precies oplost. Ik prefereer zelf iig altijd de aanpak om eerst zelf te proberen, en dan te kijken naar wat anderen hebben gedaan. Dat geeft, naar mijn idee iig, een beter idee van waarom een dergelijke oplossing is gekozen, en wat de voor- en nadelen ervan zijn.

Dat is ook zeker zo, maar design patterns zijn ook niet bedoeld als voorgekauwde oplossingen. In principe () hoeft een design pattern je helemaal niet te weerhouden ergens je eigen weg mee in te gaan. Beter is om de principes er achter goed door te krijgen en die proberen toe te passen (soms in de vorm van een design pattern dus).

[Soultaker]

Maar design patterns zijn (in ieder geval volgens de GoF) voor een groot deel codificatie van bestaande technieken. Ik denk niet dat het echt zinnig is om die dingen uit je hoofd te leren zonder dat je begrijpt hoe en waarom ze van pas komen - m.a.w. zonder dat je ze al zelf een keer uitgevonden hebt.

Om dezelfde reden ga je als beginnende schaker geen gangbare openingen uit je hoofd leren; je kunt die pas op waarde schatten als je enig inzicht hebt in het spel zelf. Daarom kan een beginnend programmeur ook beter zelf een beetje aanklooien, z'n vingers branden, oplossingen bedenken, en later inlezen welke terminologie daarbij hoort en welke alternatieven er nog meer zijn.

[Michali]

Ik denk zelf niet dat iemand eerst zelf zijn vingers hoeft te branden wil hij het goed aanleren. Als je door middel van een boek of techniek iets gelijk op de goede manier aanleert, dat heb je imo een streepje voor op iemand die het zelf heeft moeten uitzoeken. Uiteraard heeft de ander mischien meer inzicht in bepaalde gebieden, maar het resultaat uiteindelijk is denk ik hetzelfde.

Het gaat om de principes er achter die je moet kennen, als je dat doorhebt maakt het niet zo veel uit hoe je er bent gekomen. Ik denk dat hoe sneller je dat aanleert, hoe beter, en ook hoe sneller je inzicht krijgt op andere gebieden. Het leren van Design Pattterns houdt zeker niet in dat je ze puur uit je hoofd gaat leren. Dat heb ik ook niet gedaan. Het is naar mijn mening dan ook beter om eerst de principes te leren, en dan ze in de vorm van een design patterns toegepast te zien. Boeken als Design Patterns explained en Agile Software Development zijn daar uitstekende voorbeelden van.

Het puur kennen van de patterns zonder de achterliggende gedachten, principes en motivatie kan denk ik snel leiden tot toepassing voor problemen waar ze helemaal niet bruikbaar zijn, oftwel misbruik. Maar met een goed boek hoeft dat helemaal geen probleem te zijn.

Ik zie het verder ook een beetje als cheaten met ervaring. Je hoeft je dan niet meer je vingers te branden op punten waar anderen dat wel hebben gedaan. Dat is denk ook het hele punt waarom design patterns bestaan. Juist om die ervaring sneller over te brengen, zonder of met minder trial en error. Je kunt dan, met in het achterhoofd wetend waarom, er sneller een goede oplossing vinden. Bovendien leert je anders jezelf zaken aan die je later weer moet afleren, en dat heeft, denk ik, weinig voordeel.

[H!GHGuY]

Gerco schreef op zondag 08 januari 2006 @ 21:44:
Leer eerst hoe het werkt en dan hoe de computer dat bijna allemaal voor je kan doen. Als je niet weet hoe het werkt, kun je ook eventuele problemen niet oplossen als het niet helemaal werkt zoals het zou moeten (wanneer de abstractie lekt, tnx Joel).

Ik ben altijd erg geinteresseerd geweest in hoe computers op laag nivo werken (tot op microcode nivo, hoe de transistors precies de bewerkingen uitvoeren weet ik niet). Ik merk dat die kennis van hoe dingen op laag nivo werken me helpt om dingen beter te begrijpen dan mijn collega's die dat niet weten.

Mephix schreef op maandag 09 januari 2006 @ 11:50:
Ik zou toch zeker kiezen voor wat historie en basics.. wat je ziet is dat een hoop beginners vastlopen en zich eigenlijk geen raad weten hoe te zoeken naar de oplossing, omdat ze niet begrijpen wat de achterliggende gedachte/structuur is.

Ze hebben zich nooit een manier van denken eigen gemaakt, waarmee je begrijpt hoe zaken in elkaar steken en wat de consequenties kunnen zijn van je code.
[...]
Dit is ook een belangrijk punt idd.. door de basics te kennen overzie / doorzie je het geheel en voorkom je dat je door onwetendheid de zaak niet goed afdicht.

^^ with stupids

Ik kan zonder schroom zeggen dat ik een stuk meer ervaring heb dan mijn gemiddelde klasgenoot.
En ik merk dan bijvoorbeeld ook dat wanneer ze een stuk code van zichzelf debuggen veel vastlopen op dingen die ik "basic" zou durven noemen of omdat ze de internals niet kennen.

char*'s leren in C vind ik dan ook een must-do. Je kan imo niet efficient STL strings programmeren als je niet weet dat er onderliggend een char tabel zit. (je kan in JAVA niet efficient met strings werken als je niet weet dat String immutable is en StringBuilder niet)
Veel van die dingen leer je met de tijd maar een goeie basis is onontbeerlijk. Bovendien denk ik dat je sneller overstapt van char*'s op STL strings dan omgekeerd. Eens je weet hoe de internals werken kun je veel sneller weg met de bovenbouw.

[EfBe]

Internals zijn niet basisdingen. Basisdingen zijn hoe doe ik goede analyse, hoe transformeer ik mijn analyseresultaten in algorithmen en datastructuren, hoe transformeer ik algorithmen in runnable code.

Gewoon generieke kennis, die niet afhangt van char pointers of andere troep, want dat is specifiek voor een taal/techniek, maar generieke kennis kun je overal toepassen. Zoals hoe je erg veel problemen op kunt lossen met generieke grafentheorie en hoe je algoritmes die daarbij horen makkelijk toe kunt passen in het oplossen van de problemen waar je dagelijks tegenaanloopt wanneer je code schrijft.

[Verwijderd]

Het gaat er deels ook om dat mensen altijd voortbouwen op dingen die de vorige generatie heeft bedacht. Dat voortbouwen gaat duizenden en duizenden jaren terug voor gewone dingen. Wij rijden nu auto, gebruiken de telefoon, zetten de radio/mp3 speler aan zonder dat we echt de basis dingen hebben geleerd die tot de ontwikkeling van al die apparaten heeft geleidt. We hoeven niet meer ons eigen wiel uit te vinden en leren ook niet meer vuur te maken.

Gaan we ons echter specialiseren, dan leren we wel degelijk weer een gedeelte van de basis technieken, maar toch ook niet alles.

In de ICT is het zo dat dat er inderdaad mensen zijn die voorstaan dat de evolutie van de informatica in precies de volgorde als het historisch gezien plaatsvond doorlopen wordt. Nu is het vakgebied van de informatica nog jong en hedentendage is het nog net te doen. Ik voorzie echter dat na verloop van tijd dit niet meer haalbaar is. Er is dan gewoon te veel informatica geschiedenis om die dan allemaal in de exacte volgorde te gaan doorlopen.

Daarbij komt nog, wat is de volgorde historisch gezien? Veel concepten die we nu gebruiken en als modern zien stammen al uit de jaren 60. Om verschillende redenen zijn diverse technieken toen niet populair geworden en later, in een iets gewijzigde versie, opeens wel. Wil je de geschiedenis van de informatica herhalen in de volgorde van uitvinden (uitvinden in de zin van dat er een artikel over gepubliceerd is) of in de volgorde van dat het mainstream werd?

Wat ik ook een beetje proef in de vraag van de TS is wat je op een school gebruikt voor vakken waar de techniek eigenlijk secundair is aan het onderwerp. Toen ik op de universiteit zat kregen we als allereerste programmeer vak C++ (UL, had ook in mijn tijd al een beetje een 'ban' op het STL gebeuren). Later kregen we expliciet procedureel (C), assembly (MIPS), functioneel (scheme), logisch (prolog) etc etc.

Bij alle vakken met practica waarin de programmeer taal zelf niet het object van studie was, werd voornamelijk C++ gebruikt uit practische redenen. (bv bij vakken als datastructuren, operating systems, computer architecture, grid computing, etc etc). Nu bleek echter dat het overgrote deel van de studenten de programmeer style die ze als eerste geleerd hadden bleven gebruiken, dwz C++ met iets meer de nadruk op het procedurele en zonder STL. Bij ons was dus "C-achtig C++" duidelijk de soort 'norm' waar TS over spreekt.

Voorderest sluit ik me bij de anderen aan dat je natuurlijk kennis moet hebben van alle fundamentele dingen. Op de universiteit heb ik die veel gehad, maar ik zag ook dat er nog enorm veel meer dingen waren. Als profesioneel developper moet je eigenlijk ook heel goed op de hoogte zijn van alle software engineering concepten. Requirements engineering, software architecture, patterns heb ik gedaan, maar er waren nog enorm veel andere dingen in de SE specialisatie die je ook best als basis kunt bestempellen.

Eigenlijk zijn software engineering, fundamentele informatica en de algoritmiek al complete studies opzich. Om echt van -alles- wat te weten wordt steeds moeilijker. Als ICT prof moet je dus keuzes maken; binnen je specialisatie meer de diepte in (bv bij een meer programmeren gericht persoon procedureel, assembly en andere paradigma's leren), of meer de breedte in (ook eens kijken naar dingen als quantum-, DNA-, en grid-computing, om maar eens wat random gebieden te noemen).

[H!GHGuY]

EfBe schreef op maandag 09 januari 2006 @ 20:44:
Internals zijn niet basisdingen. Basisdingen zijn hoe doe ik goede analyse, hoe transformeer ik mijn analyseresultaten in algorithmen en datastructuren, hoe transformeer ik algorithmen in runnable code.

Gewoon generieke kennis, die niet afhangt van char pointers of andere troep, want dat is specifiek voor een taal/techniek, maar generieke kennis kun je overal toepassen. Zoals hoe je erg veel problemen op kunt lossen met generieke grafentheorie en hoe je algoritmes die daarbij horen makkelijk toe kunt passen in het oplossen van de problemen waar je dagelijks tegenaanloopt wanneer je code schrijft.

internals zijn bevoorbeeld hoe stringbewerkingen intern uitgevoerd worden. hoe deze optimaal uitgevoerd worden. wat zijn copy-constructor en hoe werken ze, hoe implementeer je ze best, etc etc.
deze laatste is C++, maar zelfs dit kom je ook tegen in bvb Java (System.Object.clone()) en ook daar kom je het probleem tegen van referentie/kopie.

algoritmen leren, begrijpen en kunnen omzetten in code is ook van belang. Een paar goeie bookmarks in je browser of enkele boeken op de plank kunnen hier wonderen doen.
imo kan je geen goeie red-black tree coden als je niet de basics van efficient klassen coden kent.

[EfBe]

HIGHGuY schreef op dinsdag 10 januari 2006 @ 13:59:
[...]
internals zijn bevoorbeeld hoe stringbewerkingen intern uitgevoerd worden. hoe deze optimaal uitgevoerd worden. wat zijn copy-constructor en hoe werken ze, hoe implementeer je ze best, etc etc.
deze laatste is C++, maar zelfs dit kom je ook tegen in bvb Java (System.Object.clone()) en ook daar kom je het probleem tegen van referentie/kopie.

Maar dan praat je toch over iets generieks als datastructuren en hoe die ontsloten worden in verschillende programmeertalen en niet over iets specifieks? Of beter: leer hoe verschillende datastructuren gebruikt worden in verschillende soorten talen en je hebt meer kennis opgedaan dan het leren hoe C++ intern in STL met copy constructors werkt, want het concept van de copy constructor is wat anders dan de Clone() method.

algoritmen leren, begrijpen en kunnen omzetten in code is ook van belang. Een paar goeie bookmarks in je browser of enkele boeken op de plank kunnen hier wonderen doen.
imo kan je geen goeie red-black tree coden als je niet de basics van efficient klassen coden kent.

Ik denk dat dat best mogelijk is, want een red-black tree is prima in C te schrijven zonder ook maar het concept van 'class' ooit te hebben gezien. Waar het DUS om gaat is te begrijpen wat een red-black tree is en hoe deze intern werkt oftewel het algoritme doorgronden. Als je verder kennis aanleert hoe algoritmen naar programmeertalen te vertalen is het niet boeiend welke taal je gebruikt.

Verwijderd schreef op dinsdag 10 januari 2006 @ 00:10:
Eigenlijk zijn software engineering, fundamentele informatica en de algoritmiek al complete studies opzich. Om echt van -alles- wat te weten wordt steeds moeilijker. Als ICT prof moet je dus keuzes maken; binnen je specialisatie meer de diepte in (bv bij een meer programmeren gericht persoon procedureel, assembly en andere paradigma's leren), of meer de breedte in (ook eens kijken naar dingen als quantum-, DNA-, en grid-computing, om maar eens wat random gebieden te noemen).

Mee eens. In de subset van de informatica waar ik me in beweeg (code generatie/parser technologie/data-access/database theorie) is het al nauwelijks bij te houden. Maar je hoeft ook niet meteen altijd het nieuwste te doen/leren. Men maakt al vele vele jaren software en 10 jaar geleden dacht men ook dat wat men deed de top of the bill was, en die software werkte ook, sterker: performde veelal uitstekend op hardware dat we nu als stenen-tijdperk-hardware zouden noemen. Waarom dat dan achterhaald zou zijn en niet meer nuttig heden ten dage is IMHO dus onzin dus men kan, indien men de vooruitgang niet helemaal bijhoudt, best teruggrijpen op bewezen technieken en die blijven gebruiken totdat er tijd is om de nieuwe technieken te omarmen.

[H!GHGuY]

EfBe schreef op dinsdag 10 januari 2006 @ 17:31:
[...]
Maar dan praat je toch over iets generieks als datastructuren en hoe die ontsloten worden in verschillende programmeertalen en niet over iets specifieks? Of beter: leer hoe verschillende datastructuren gebruikt worden in verschillende soorten talen en je hebt meer kennis opgedaan dan het leren hoe C++ intern in STL met copy constructors werkt, want het concept van de copy constructor is wat anders dan de Clone() method.
[...]
Ik denk dat dat best mogelijk is, want een red-black tree is prima in C te schrijven zonder ook maar het concept van 'class' ooit te hebben gezien. Waar het DUS om gaat is te begrijpen wat een red-black tree is en hoe deze intern werkt oftewel het algoritme doorgronden. Als je verder kennis aanleert hoe algoritmen naar programmeertalen te vertalen is het niet boeiend welke taal je gebruikt.

imo staan die 2 dingen wel wat naast elkaar.
maar ik zou beginnen bij het begin:

C++:

#include <iostream>

using namespace std;

int main(int argc, char** argv)
{
   int aantal;
   cin>>aantal;
   while (aantal > 0)
   {
      cout<<"het kwadraat van "<<aantal<<" is "<<aantal*aantal<<endl;
      cin>>aantal;
   }
  return 0;
}

Je kan geen algo implementeren zonder kennis van een taal.
Kennis van een taal is nutteloos als je er nix mee kan.
Ze staan dus beide _naast_ elkaar. Ik persoonlijk zou beginnen met een taal onder de knie te krijgen, en wanneer je de basics begrijpt, eens wat algoritmes proberen te implementeren en vergelijken met andere implementaties. imo is dit de snelste manier van leren. Een nieuwe taal leer je in 1 week de basics van als je al kan programmeren. Meer dan basics is dan ervaring. Ik werk nu reeds een 2tal jaar met C# en ik leer nog geregeld best-practise of taalspecifieke dingen.
Ik merk zeker dat hoe beter je een taal kent, hoe effectiever/beter je code wordt. (op voorwaarde dat je je taal niet misbruikt.)

bovendien is clone() nog zo verschillend niet van de copy-constructor in die zin dat ze beide een deep-copy (zouden moeten) maken van je object ipv een reference of shallow-copy.

Al doende leert men, maar zonder basis kan je niet beginnen

[farlane]

Zolang computersystemen bestaan uit CPU's met registers en geheugen dat via adres/databussen wordt aangesproken is het naar mijn idee onontbeerlijk om te weten wat een (char)pointer is, hoe een stackframe eruit ziet en weet ik wat. Het vergroot je inzicht enorm, ook al ben je bezig om een taal als Java of *.Net onder de knie te krijgen.

Als het algoritme het doel is, kun je met deze kennis ook veel doen. Je snapt waarom je de STL auto_ptr niet moet gebruiken in een STL container en weet ik wat. Het een kan niet zonder het ander.