Nico Coesel wrote:
> John Bokma <postmaster@castleamber.com> wrote:
> Als je niet kunt programmeren / software ontwerpen, dan wordt het
> nooit wat. Ongeacht de taal. Helaas zijn er nog vele webdesigners die
> het programmeren er nog wel even bij doen.
Omgekeerd ook :-D. Maar je mist mijn punt. Iemand die goed kan
programmeren en ff hop hop PHP leert in 3 dagen, die zal in het begin
zeer zeker niet goed PHP programmeren (of welke taal dan ook). Sterker,
ik beweer nu probleemloos dat die aankloot code gewoon na 3 maanden ook
door de uitvoerder als gekloot wordt aangemerkt (excuses voor het
Frans).
>>> In geval van een nieuwe
>>> taal zoek ik een voorbeeldje op voor de syntax en ik begin met
>>> programmeren van _mijn_ applicatie.
>>
>>Tja, en naar mijn niet zo heel erg bescheiden mening is dat de meest
>>foute manier om het te leren.
>
> Het is een vorm van extreme programming.
Extreem gekloot. Werkt prima voor u roept, wij draaien. Maar niet als
het over 3 maanden eens onderhouden moet worden. Ok, uitzondering zijn
kleine dingen, ook omdat je bij kleine dingen vaak min of meer op het
zelfde uitkomt.
Maar zodra het een groot project is, wordt het diepe tranen als er
mensen op werken die ff on-the-fly denken een taal te kunnen leren.
> Knip en plak je eerste
> programma in elkaar van bestaande code en focusseer alleen op de
> probleemgebieden.
Jaaa, heerlijk, ik heb zo een ding gezien met 650 perl modules. Na een
paar jaar was het probleemgebied de gehele applicatie. En wellicht ook
dat niemand er langer dan 3 maanden onderhoud op kon doen (ik verving de
vervanger of zoiets, en werd ook weer vervangen).
>>En dus "ontdek" jij een vreemd dialect. Leuk hoor, en ja, je krijgt
>>uiteindelijk wel iets werkend. Het vervelende is dat je code extreem
>>onleesbaar is voor iemand die wat langer in de taal zit.
>
> Juist niet, zie onder.
Vreemd, ik zie dat al zo'n 20 jaar in de praktijk gebeuren, ook bij
eigen werk als ik het op de door jouw omschreven manier doe.
>>Ik zie regelmatig dingen in Perl code (ik vertel zo de bron), a la:
>>
>>for ( $i = 0; $i < 100; $i++ ) {
>>
>> print("<td>\n");
>> printf("%d\n", @items[ $i ]);
>> print("</td>");
>>}
>
> Niets mis mee toch? Perfect juist;
Omdat je wellicht geen Perl kent. Voor iemand die dagelijks Perl
programmeert is dit dus extreem lastig te lezen. Daarnaast mankeren er
wat dingen aan.
> leesbaar voor iemand die ook C kent
Juist, en die zal dus de helft van mijn Perl, en Perl van elke
programmeur die het langer doet dan 2 jaar niet kunnen lezen. En
omgekeerd, zijn halve C pogingen maken de Perl code onleesbaar, en
ononderhoudbaar.
Door te zeggen dat ik ongelijk heb, bevestig je alleen maar mijn gelijk
:-D
> (en wellicht nog wat andere talen). Lekker standaard (C kun je toch
> min of meer als standaard beschouwen). Programma's moet je vooral
> standaard houden dan kan iedereen ze onderhouden.
Mis, bovenstaande code is extreem onhandig in Perl (ook omdat er een
foute aanname in zit, maar een die *juist* gemaakt wordt als een C
programmeur aan de Perl gaat).
> Mensen die langer met een programmeertaal bezig zijn gebruiken vaak
> allerlei truukjes en shortcuts. De ervaring leert dat juist het
> gebruik van deze truukjes en shortcuts het onderhoud aan software voor
> anderen lastig maakt.
Wiens ervaring? Ah, de ervaring van de onervaren programmeur. Oh, vast,
ik denk dat een C programmeur die Perl op de aankloot manier geleerd
heeft niet 1,2,3 dit snapt:
print "<td>\n$_\n</td>" for @items;
En toch is dit gelijk aan bovenstaande "C" gepruts (ff uitgegaan dat
@items 100 dingen bevat).
En sterker, het is nog leesbaarder ook: druk af voor alle dingen. Geen
zorgen om ondergrens, bovengrens, enz.
Ik ben het niet zo ver eens met Dijkstra, die ooit iets riep dat als
iemand ooit Basic had geprogrammeerd had die verloren was, maar iemand
die denkt dat Perl een soort C on acid is, is verkeerd bezig.
> De kans dat iemand naar je code kijkt die meer
> ervaring heeft dan jezelf is kleiner
In mijn geval met Perl of Java of straks Python, ja, zal vaak opgaan.
Maar die bovenstaande Perl = C prutser? Ik hoop van harte van niet.
> dan de kans dat iemand naar je
> code die minder ervaring heeft dan jezelf.
En zo filter je dus mensen die nog meer aankloten dus mooi uit als je
het op mijn manier doet. Ik bedoel, wie neemt er een zeer onervaren
programmeur aan die zo dom programmeert dat iemand met nog minder
ervaring het ook kan snappen? Hemeltje.
Ga jij in Java ook in C zitten programmeren, dus geen OO maar (want dat
is complex)? Iets van C is de ondergrens?
En merk op: ik promoot niet om de smart ass uit te hangen, dat zie ik
ook wel eens in code, iemand die denkt dat als het allemaal op 1 regel
past dat het dan helemaal mooi is.
Maar wel: gebruik idiomen die gangbaar zijn in de taal. De bovengenoemde
.... for .. is er zo een.
>>Ik kan in ca. 2 uur 2 Python boeken doorlezen, en na die 2 uur
>>"programmeren" in Python. Ik weet dan dat ik echter maanden nodig heb
>>om echt Python te produceren, en als ik de libraries wil gebruiken,
>>nog meer maanden.
>
> In het vakgebied waarin ik momenteel nog werkzaam ben, ben je dan
> compleet onbruikbaar :-)
Een klassieke vergissing. Vaak gedaan door mensen die menen dat
programmeren 12 uur lang knopjes indrukken is.
Op "jouw" manier leren programmeren betekent dat je alle nieuwe kennis
op te breken in brokken die dom genoeg zijn, en je leert dus in feite
niks nieuws. En als er vervolgens iemand naar kijkt die een paar jaar er
in zit, dan heeft die geen idee waar het gekloot over gaat.
> Deze week iets met DCOM objecten, volgende
> week iets met een seriele poort en de week daarna weer een of ander
> protocol dat via UDP berichten loopt en op Linux moet draaien. Als ik
> eerst alles zou lezen, dan zou ik alleen maar aan het lezen zijn en
> het werk komt niet af. Uit de documentatie pikken wat nodig is (en dat
> tot op het bot uitpluizen)
Ben je stiekem toch aan het lezen geslagen. Je kan iets pas overslaan
als je weet wat er staat natuurlijk.
Tenzij het totaal buiten hetgeen wat je nodig hebt valt, ik ga voorlopig
ook niet leren hoe ik C code met Python kan interfacen. Maar ik heb wel
gelezen dat het kan (en dus kan ik het opzoeken).
Jouw manier van leren klinkt mij te veel in de oren als:
nieuwe taal: ok, ik heb een variabele nodig, index.... variabele...
pagina 20. Ok, nu wil ik printen naar het scherm, print... print... ah,
ok, print... Nu wil ik een for loop... for... for...
> en de rest laten liggen is het devies.
En dus krijg je halfbrakke implementaties die vaak terugkomen als je
niet voldoende gelezen hebt. Je verschuift dan de ellende naar een later
tijdstip. Als je wel voldoende gelezen hebt, ben je het met mij eens
:-D.
> Een resultaat dat werkt, onder alle omstandigheden blijft werken en
> onderhoudbaar is, is veel belangrijker dan een efficient taalgebruik.
Ik hoop dat soort code niet vaak onder ogen te krijgen. De laatste keer
was erg genoeg.
Tenslotte, ik kom het ook wel eens tegen hoor, dat ik in erg korte tijd
iets onder de knie moet krijgen. Maar tot nu toe gemerkt dat het beter
werkt om er ff een dag voor te zitten (niet achter de computer vaak) en
het dan te programmeren (soms eerst op papier) dan:
met boek op de schoot trial en erreur until it workz ferry prima.
--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html