Mooie cursus "algo & datastructuren" + welk boek?

Post by user
Gisteren een postscript boek gevonden "Mathematical illustrations"
Casselman.

boek hier als pdf/ps
http://www.math.ubc.ca/~cass/graphics/manual/

--
--
What's on Shortwave guide: choose an hour, go!
http://shortwave.tk
700+ Radio Stations on SW http://swstations.tk
300+ languages on SW http://radiolanguages.tk

John Bokma

2009-12-29 19:26:16 UTC

Post by user
Een kereltje gaf me recent een handleiding "cds branden", en beweerde "je
gaat nu wat bijleren over informatica". Wat? Alsof je met een handleiding
van een video recorder een cursus fysica (magnetisme, electronica) kunt
vervangen. Dat is geen informatica, maar gewoon een beetje vuile
business... Verandert om de zoveel maanden, want er moet omzet gehaald
worden, BTW gekakt worden.
Ik heb bovendien les gehad, en oefeningen gevolgd, zonder computer. Gewoon
op papier nadenken. Je kunt de cursussen aan de unifs er eens op
natrekken. Waarom geen selectie van deze onderwerpen in het middelbaar
onderwijs?
Hier een online cursus
http://cg.scs.carleton.ca/~luc/252.html

Na je post helemaal gelezen te hebben wilde ik je "An Introduction to
Algorithms" aanraden, en zie nu dat het precies dat boek is wat op 3/5e
van die pagina genoemd wordt. Als je niet vies bent van zelf-studie en
je wilt een erg goed boek, kopen, echt. Het is iets meer dan 30 euro,
maar zeker waard. Let op dat je de laatste editie (3e) koopt.

Andere boeken die ik zelf heb (of nog op mijn wish list staan):

* Elements of Programming by Alexander A. Stepanov
* Programming Language Pragmatics, Third Edition by Michael L. Scott
* Computational Geometry: Algorithms and Applications by Mark de Berg,
Otfried Cheong, Marc van Kreveld, and Mark Overmars
* Algorithms in a Nutshell, O'Reilly (uitgever)
* Essentials of Programming Languages, 3rd Edition
* Structure and Interpretation of Computer Programs, 2nd edition

Wat je hierboven gedaan hebt: kijken naar informatica programma's van
universiteiten is een aanrader. Ik doe dat ook als ik over een bepaald
onderwerp een goed boek wil hebben (en lees vervolgens de reviews op
Amazon).

Als je onder Linux wilt programmeren en Python wilt leren:

* Practical Programming: An Introduction to Computer Science Using Python

Ik ken het boek verder niet, maar ik heb er een tijdje over getwijfelt
of ik het wel/niet zou aanschaffen. Als je Python overweegt, laat het
hier weten, want dan kan ik je een lijst van boeken geven die ik erg
goed vind.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

jaap

2009-12-29 21:08:27 UTC

The Pragmatic Programmer van Andrew Hunt en David Thomas:
http://tinyurl.com/ykvm96h

Werkelijk zeer de moeite waard. Na het lezen van dit boek sta je weer
steviger in je schoenen en is programmeren nog leuker geworden.

Veel plezier er mee,
Jaap

John Bokma

2009-12-29 21:52:24 UTC

Post by jaap

http://tinyurl.com/ykvm96h

Goed boek, heb het al een aantal keer doorgebladerd, samen met

* Code Complete (2nd edition), Steve McConnell

Ook een dikke aanrader.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

unknown

2010-01-01 12:13:15 UTC

Ik denk dat middelbaar algemeen onderwijs zich niet teveel moet bemoeien
met specifieke beroepen. Wiskunde is al moeilijk genoeg voor veel
mensen. Wel zou programmeren misschien wiskunde kunnen helpen, maar dan
ben je echt al met hogere wiskunde bezig.

Post by user
Hier een online cursus
http://cg.scs.carleton.ca/~luc/252.html

Niet echt een online cursus ...

Post by user
Ik heb een bon van 30 euro bij DS boekhandel, en moet die besteden ...
Iemand hints?? (anders)Iets over C misschien?/ development in linux. Ik
zag al wel "betere" boeken in de franse FNAC/Le Furet du Nord.
Gisteren een postscript boek gevonden "Mathematical illustrations"
Casselman. Daar staat deze belg LD in. Ik had hem al eens gevonden toen
ik naar postscript op zoek was..
http://cg.scs.carleton.ca/~luc/postscript.html
Ik zou deze
http://users.fulladsl.be/~spb13810/research/loc.tar.bz2
met tijd wat mooier willen maken...

Lezen en leren over algoritmen is een goed idee. Maar veel van die zaken
gebruik je in het dagelijks leven als programmeur nooit. Je bent niet
slim bezig als je zelf een sorteerroutine implementeert of een linked
list. Er zijn stomweg teveel libraries die dat veel beter en efficienter
doen dan jij (en zonder segfaults en memory leaks). Datzelfde geldt als
wet zelfs voor alles wat met encryptie te maken heeft. Goed om het te
snappen, dom om het zelf te implementeren.

Wat ik absoluut gemist heb in alle lessen en cursussen die ik gehad heb,
is hoe de hele program-compile-link keten in elkaar steekt en hoe
bijvoorbeeld dynamic linking werkt.

Ook belangrijk is weten hoe een compiler werkt, en over zaken als
geheugengebruik (en -lekken). Zelf heb ik nogal wat geleerd in "Write
Great Code, volume 2" (vol 1 gaat over 'understanding the machine', wat
ik op de universiteit en hbo ruim geleerd heb met programmeerlessen (C +
assembly)):
http://www.amazon.com/Write-Great-Code-Low-Level-High-Level/dp/1593270658.
Ook "Exploiting Software"
(http://www.bol.com/nl/p/engelse-boeken/exploiting-software/1001004002209871/index.html)
geeft je veel inzichten hoe software werkt.

Succes
Bart

PS
Ik 'programmeer' sinds mijn 7e, maar durf me pas sinds een paar jaar
programmeur te noemen. Na een aantal jaar ervaring in 'the real world'.

--
Bart Blogt Beter: blog.friesoft.nl

Rob

2010-01-01 12:31:05 UTC

Post by unknown
Wat ik absoluut gemist heb in alle lessen en cursussen die ik gehad heb,
is hoe de hele program-compile-link keten in elkaar steekt en hoe
bijvoorbeeld dynamic linking werkt.
Ook belangrijk is weten hoe een compiler werkt, en over zaken als
geheugengebruik (en -lekken).

Nou toen ik in de jaren 80 op school zat werd dat toch allemaal wel heel
uitgebreid behandeld. Kan zijn doordat de docent (Leen Ammeraal) hier
speciaal in geinteresseerd was.

Van hem heb ik in ieder geval een manier van werken geleerd die je bij
tegenwoordige programmeurs vaak niet meer ziet. In die tijd had je meestal
geen IDE (er bestond wel UCSD p-system en Turbo Pascal), dus je werkte
al zorgvuldiger omdat iedere compilatieslag een hoop tijd kostte.

Maar vooral het critisch kijken naar je code en zelf begrijpen dat het
correct is in plaats van net zo lang er aan friemelen en proberen tot
het zo te zien goed werkt, dat houd ik nog steeds in ere.

unknown

2010-01-01 12:36:24 UTC

Post by Rob

Nou toen ik in de jaren 80 op school zat werd dat toch allemaal wel heel
uitgebreid behandeld. Kan zijn doordat de docent (Leen Ammeraal) hier
speciaal in geinteresseerd was.

Zelf zat ik in de jaren 90-00 op school, en er werd wel wat tijd aan
besteed, maar niet heel veel. Software werd inderdaad in een editor
geschreven en met command-line gecompileerd. Maar gcc doet het nu
allemaal voor jou.

Post by Rob
Van hem heb ik in ieder geval een manier van werken geleerd die je bij
tegenwoordige programmeurs vaak niet meer ziet. In die tijd had je meestal
geen IDE (er bestond wel UCSD p-system en Turbo Pascal), dus je werkte
al zorgvuldiger omdat iedere compilatieslag een hoop tijd kostte.

Ik denk dat talen als Python en Java ervoor gezorgd hebben dat steeds
meer programmeurs geen idee hebben, wat er in die machine gebeurt. Om
maar te zwijgen over C#.NET en Javascript. Ik zie behoorlijk veel
crapware, die alleen maar redelijk draait, omdat er een monsterlijke
machine onder zit. (Je hebt écht geen 1 gig RAM nodig en 2000 MHz om
alleen maar een simpel animatietje te laten zien...).

Post by Rob
Maar vooral het critisch kijken naar je code en zelf begrijpen dat het
correct is in plaats van net zo lang er aan friemelen en proberen tot
het zo te zien goed werkt, dat houd ik nog steeds in ere.

Zo is dat.

Bart

PS
Een goed 2010.

--
Bart Blogt Beter: blog.friesoft.nl

Martijn van Buul

2010-01-01 13:33:39 UTC

In die tijd had je meestal geen IDE

Nu is er ook geen IDE :X

Ik heb in mijn kerstvakantie eens geprobeerd om een van de applicaties die
ik tijdens $dayjob ontwikkel onder Win32 te porten naar een toolkit die
wat beter cross-platform is, in de hoop dat het ons een beetje uit de
wurggreep van Microsoft kan halen. Ik weet het, gekkenwerk - zoiets hoor je
niet te doen tijdens je vakantie. De haalbaarheid van zo'n actie valt of staat
natuurlijk wel bij het vinden van een ontwikkelomgeving waarin het enigszins
prettig werken is - het gebruiksgemak van Visual Studio is nou niet echt
briljant te noemen, zoiets moet goed te evenaren zijn. Voor mij is (g)vim
en make voldoende, maar voor mijn collega's waarschijnlijk niet.

Tot mijn spijt moet ik constateren dat zoiets wederom niet bestaat. Ik word
heel graag overtuigd van het tegendeel; dit is mijn eisenlijstje:

Ik zoek een IDE die:

1. Overweg kan met grote projecten, bestaande uit duizenden files. Alleen
dit blijkt al een onoverkomelijk probleem voor veel beschikbare IDE's
onder Linux te zijn.
2. Het moet overweg kunnen met C++. Liefst met fatsoenlijke integratie van
een debugger, en met fatsoenlijke syntax highlighting en code completion.
Hierdoor vallen Monodevelop (want alleen mono) en eclipse (Want alleen
java; de C++ development tools zijn kapotgebitrot en niet meer
beschikbaar) af.
3. Gezien 1): Het moet mij in staat stellen mijn files te ordenen zoals ik
dat wil. Gezien de omvang van de projecten is dat waarschijnlijk niet
de standaardoplossing van de IDEbakker, te meer aangezien veel van deze
files geshared zijn tussen meerdere projecten, en dus wel eens in een
andere directory te vinden zijn. Ook dit is een struikelblok voor
bijvoorbeeld Anjuta (Die mij opdwingt hoe ik mijn code moet ordenen,
danwel vereist dat de directoryrepresentatie hetzelfde moet zijn) en
qtCreator, die van mening is dat 3000 files in *een* enkele lijst gooien
geen enkel bezwaar is.
4. Aangezien we cross-platform development doen is het een vereiste dat er
een custom build optie moet zijn, waarin *ik* bepaal hoe en wat er
gecompileerd wordt. Make en een gemakkelijk te parsen project file formaat
is voldoende; op dit moment gebruiken we visual studio + GNU make op
deze manier. Autotools zijn in ieder geval niet welkom.
5. Een nette integratie heeft met een mooie resource editor voor de te kiezen
toolkit. Op dit moment neig ik naar wxWindows (want gejat van MFC, en ik
vermoed dat de conversie eenvoudiger gaat zijn), maar GTK (wxWindows ziet
er wat gedateerd uit) en Qt (GTK *en* wxWindows zijn vervelend in gebruik
en leveren lelijke code op) mogen ook.
6. Het moet op een zinnige manier overweg kunnen met multiple monitors. Op
zijn minst wil ik meerdere files tegelijkertijd kunnen editen, en op
meerdere plaatsen in dezelfde file kunnen werken.

Ik kon er geen vinden, en ik heb er veel geprobeerd. KDevelop gaat stuk op
grote projecten. Eclipse doet niet meer aan C++. qtCreator is vervelend en
legt beperkingen op in mijn ordening. CodeBlocks snapt ook niet dat *IK*
bepaal hoe mijn project eruitziet, en niet CodeBlocks - en tevens legt het
een toolchain en build type op. CodeLite is leuk, maar de editor is te licht.

En oh ja; IDE's die na het aanmaken van een template project meteen al crashen
als je een enkele file wil toevoegen (Anjuta..) tellen ook niet mee.

Ik sta open voor suggesties; tot die tijd moet ik bekennen dat Visual Studio
eigenlijk zo slecht nog niet is, want behalve een wat matige multi-monitor
support en een code completion cq codebrowser die wel heel vaak de plank
misslaat voldoet het *wel* aan alle andere eisen.

--
Martijn van Buul - ***@dohd.org

unknown

2010-01-01 13:44:01 UTC

Post by Martijn van Buul
Ik sta open voor suggesties;

Ik ook (zie ook
http://blog.friesoft.nl/2009/11/18/ui-programming-in-linux-sucks-a-little-less/).

Post by Martijn van Buul
tot die tijd moet ik bekennen dat Visual Studio
eigenlijk zo slecht nog niet is, want behalve een wat matige multi-monitor
support en een code completion cq codebrowser die wel heel vaak de plank
misslaat voldoet het *wel* aan alle andere eisen.

Is dit niet wat Ballmer bedoelde met 'developers, developers,
developers, ...' (ad inifitum) ?

Bart

--
Bart Blogt Beter: blog.friesoft.nl

John Bokma

2010-01-01 22:59:30 UTC

Martijn van Buul <***@dohd.org> writes:

[IDE eisen]

Post by Martijn van Buul
5. Een nette integratie heeft met een mooie resource editor voor de te kiezen
toolkit. Op dit moment neig ik naar wxWindows (want gejat van MFC, en ik
vermoed dat de conversie eenvoudiger gaat zijn), maar GTK (wxWindows ziet
er wat gedateerd uit) en Qt (GTK *en* wxWindows zijn vervelend in gebruik
en leveren lelijke code op) mogen ook.

Ik heb redelijk wat ervaring met wxWindows, en ben er niet echt over te
spreken. Ik weet vrij weinig van Qt af, maar wat ik gezien heb geeft mij
heel sterk het gevoel dat Qt veel prettiger werkt dan wxWindows, ook
omdat wxWindows duidelijk van de vorige eeuw is.

Post by Martijn van Buul
6. Het moet op een zinnige manier overweg kunnen met multiple monitors. Op
zijn minst wil ik meerdere files tegelijkertijd kunnen editen, en op
meerdere plaatsen in dezelfde file kunnen werken.

2-6 kan prima met Emacs. Ik ken zowel vi(m) (maar niet goed genoeg, wil
ik dit jaar wat aan gaan doen) als emacs (vrij goed), en neig meer naar
Emacs.

Qua je eerste punt: het zou mij totaal niets verbazen als er een (of
zelfs meer) uitbreidingen zijn op Emacs om dat mogelijk te maken.

(terzijde: ik gebruik zelf veel ant, maar dan meer om dingen bij elkaar
in een tarball of zip te pakken)

Vraag is of Emacs een IDE te noemen is ;-) (Ik doe er ook Usenet mee, en
dat is fijn, om te kunnen schrijven in je dagelijkse editor).

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Martijn van Buul

2010-01-03 20:32:37 UTC

Post by John Bokma
Ik heb redelijk wat ervaring met wxWindows, en ben er niet echt over te
spreken.

Hmja, het lijkt nogal op MFC. Heel eerlijk gezegd vind ik dat ook niet echt
tof, maar het is nou eenmaal de toolkit waarin de bestaande dialogs
geschreven zijn, en het is de manier van denken waar mijn gewaardeerde
collegae aan gewend zijn.

Post by John Bokma
Ik weet vrij weinig van Qt af, maar wat ik gezien heb geeft mij
heel sterk het gevoel dat Qt veel prettiger werkt dan wxWindows,

Tsja, ik heb wel met Qt gewerkt, en het is ook niet echt je-dat. Ze
gebruiken een houtjes-touwtjes oplossing om C++ uit te breiden met nieuwe
constructies, en dat heeft zo zijn nadelen. Van de andere kant is de
uiteindelijke code wel redelijk elegant - iets wat je van GTK+ (de andere
grote toolkit) niet kunt zeggen.

Post by John Bokma
ook omdat wxWindows duidelijk van de vorige eeuw is.

Zelden zo'n onzinnig argument gezien, maar Qt is ook niet nieuw. Sterker nog,
Qt is ouder dan wxWindows/wxWidgets *en* GTK+.

2-6 kan prima met Emacs.

Euh, ik had toch al gezegd dat vim+make niet echt een acceptabele oplossing
is? Waarom zou emacs+make dat dan wel zijn?

Post by John Bokma
Vraag is of Emacs een IDE te noemen is ;-) (Ik doe er ook Usenet mee, en
dat is fijn, om te kunnen schrijven in je dagelijkse editor).

Tsja. ik ben eerlijk gezegd geen emacs-fan; de toetsenbordcombinaties zijn
mij te bizar.

Martijn - die zich spontaan afvraagt welk Stallmangedrocht hij wel fijn vindt..

--
Martijn van Buul - ***@dohd.org

John Bokma

2010-01-03 21:32:15 UTC

Post by John Bokma
ook omdat wxWindows duidelijk van de vorige eeuw is.

Zelden zo'n onzinnig argument gezien, maar Qt is ook niet nieuw.

Het gaat niet om ouderdom in jaren, maar gewoon hoe het
aanvoelt. Uiteraard is het een persoonlijke mening.

2-6 kan prima met Emacs.

Euh, ik had toch al gezegd dat vim+make niet echt een acceptabele oplossing
is? Waarom zou emacs+make dat dan wel zijn?

Geen idee, ik gaf alleen aan dat 2 t/m 6 prima met Emacs te doen
is. Emacs is verder geen vim en vice versa natuurlijk.

Post by John Bokma
Vraag is of Emacs een IDE te noemen is ;-) (Ik doe er ook Usenet mee, en
dat is fijn, om te kunnen schrijven in je dagelijkse editor).

Tsja. ik ben eerlijk gezegd geen emacs-fan; de toetsenbordcombinaties zijn
mij te bizar.

Kijk, en dat is dus /wel/ een onzinnig argument, want daar kan je
probleemloos /zelf/ wat aan doen.

Post by Martijn van Buul
Martijn - die zich spontaan afvraagt welk Stallmangedrocht hij wel fijn vindt..

Ik heb altijd het idee dat Martijn niks echt fijn vind wat andere fijn
vinden.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

gast

2010-01-14 20:16:45 UTC

Post by John Bokma
Ik heb redelijk wat ervaring met wxWindows, en

ben er niet echt over te

Post by John Bokma
spreken. Ik weet vrij weinig van Qt af, maar

wat ik gezien heb geeft mij

Post by John Bokma
heel sterk het gevoel dat Qt veel prettiger

werkt dan wxWindows, ook

Post by John Bokma
omdat wxWindows duidelijk van de vorige eeuw

is.

Je zou Motif beter kunnen vinden dan programmeren
in X11.

Motif is van ?? 1989, X11 van 1984. Maar het
werkt beide nog, want is "open bron".....

Zo rendeert opgedane kennis. Pas op je pensioen
gooi je het definitief weg? Neen, dan maak je
openbroncode??

unknown

2010-01-14 20:55:22 UTC

Post by John Bokma
Ik heb redelijk wat ervaring met wxWindows, en ben er niet echt over te
spreken. Ik weet vrij weinig van Qt af, maar wat ik gezien heb geeft mij
heel sterk het gevoel dat Qt veel prettiger werkt dan wxWindows, ook
omdat wxWindows duidelijk van de vorige eeuw is.

Je zou Motif beter kunnen vinden dan programmeren in X11.
Motif is van ?? 1989, X11 van 1984. Maar het werkt beide nog, want is
"open bron".....

Maar Motif sucks...

--
robert

John Bokma

2010-01-01 22:51:33 UTC

Kenmerk van een goede programmeur, echt. Als ik ergens een hekel aan heb
is het wel "trial and error" "programmeurs", zeker als ze beweren dat ze
anders leren dan andere mensen, en praktischer zijn (dwz: ze leren iets
met boek op de schoot achter een computer of erger door te googlen, code
pasten en dan maar veranderen tot het werkt).

Ooit ergens op een opdracht gezeten waar kunde gemeten werd aan het
aantal toetsaanslagen per minuut. Ik kwam daar achter toen iemand mij
wat uitlegde achter zijn computer en constant zenuwachtig de op de
cursor toetsen zat te tikken. Hij vertelde dat we zo de indruk gaven
hard aan het werk te zijn....

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Martijn Lievaart

2010-01-02 09:51:14 UTC

Post by John Bokma
Kenmerk van een goede programmeur, echt. Als ik ergens een hekel aan heb
is het wel "trial and error" "programmeurs", zeker als ze beweren dat ze
anders leren dan andere mensen, en praktischer zijn (dwz: ze leren iets
met boek op de schoot achter een computer of erger door te googlen, code
pasten en dan maar veranderen tot het werkt).

Dan heb je nog nooit met VBA gewerkt. Trial and error is de enige manier
bij gebrek aan goede documentatie.... :-)

M4

John Bokma

2010-01-02 19:21:56 UTC

Dan heb je nog nooit met VBA gewerkt.

Jawel, maar dat is al weer eventjes geleden (eind jaren 90).

Post by Martijn Lievaart
Trial and error is de enige manier
bij gebrek aan goede documentatie.... :-)

Toen ik VBA gebruikte was er tenminste 1 boek (Microsoft Press). Verder
vond ik e.e.a. wel logisch in elkaar zitten.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Martijn van Buul

2010-01-01 12:54:45 UTC

["Followup-To:" header set to nl.comp.os.linux.discussie.]

Je bent niet slim bezig als je zelf een sorteerroutine implementeert of een
linked list.

Mwah. Je bent niet slim bezig als je je vastbijt in generalisaties.
"Generalisations considered harmful" enzo.

Er zijn stomweg teveel libraries die dat veel beter en efficienter doen dan
jij (en zonder segfaults en memory leaks).

Dat ben ik absoluut niet met je eens. Ik implementeer regelmatig een linked
list - omdat de standaard oplossingen onhandig, inefficient of domweg
onmogelijk zijn. Dito voor sorteerroutines - een generieke QuickSort is *niet*
altijd de beste oplossing. Integendeel.

Een slecht programmeur schrijft alles zelf - maar een programmeur die denkt
dat standaard oplossingen per definitie de juiste zijn, zal altijd maar
matigjes blijven. Van de andere kant is iemand die alles zelf schrijft omdat
de rest toch bagger is (en dus last heeft van het Not Invented Here syndroom)
waarschijnlijk bijzonder intelligent en slim - maar hij is ook niet handig
bezig. Een goed programmeur weet wanneer hij genoegen kan nemen met een
generieke oplossing, en wanneer het gebruik van die generieke oplossing
meer problemen oplevert dan oplost.

Datzelfde geldt als wet

Het is geen wet. Hooguit een richtlijn voor matige programmeurs.

zelfs voor alles wat met encryptie te maken heeft. Goed om het te snappen,
dom om het zelf te implementeren.

Onzin. Als dat waar zou zijn, zouden er nooit nieuwe cryptoalgoritmen komen.
Of herimplementaties van cryptoalgoritmen. Tevens zou er nooit iemand de
moeite nemen om eens een crypto algoritme proberen te kraken, danwel te
verbeteren.

Wat niet wil zeggen dat iedereen maar even zijn eigen encryptiealgoritme
moet gaan verzinnen, overigens.

Wat ik absoluut gemist heb in alle lessen en cursussen die ik gehad heb,
is hoe de hele program-compile-link keten in elkaar steekt en hoe
bijvoorbeeld dynamic linking werkt.

Dan heb je de verkeerde cursussen gevolgd. Overigens is het niet zo heel
erg ingewikkeld op hoofdlijnen. Jammer genoeg zijn er wel veel platform-
afhankelijke details en eigenaardigheden.

Ook belangrijk is weten hoe een compiler werkt,

Waarom *wel* weten hoe een compiler werkt, maar *niet* hoeven te weten hoe
een linked list werkt. Hmm, ergens klinkt dat als een contradictio in
teminus; als je weet wat voor bagger code gcc en stdlibc++ uit een simpele
std::list<bla> bouwen, is alleen *dat* al een argument waarom het gebruik
van STL in een aantal situaties voorkomen dient te worden - en dan heb ik het
nog niet eens gehad over de onhebbelijkheden van diezelfde STL die niet eens
compiler en implementatieafhankelijk zijn.

Hetgeen overigens niet wegneemt dat het gebruik van standaard containers
en dergelijke bijzonder nuttig kan zijn op plaatsen waar performance
niet zo belangrijk is.

--
Martijn van Buul - ***@dohd.org

unknown

2010-01-01 13:23:31 UTC

Post by Martijn van Buul
["Followup-To:" header set to nl.comp.os.linux.discussie.]

Je bent niet slim bezig als je zelf een sorteerroutine implementeert of een
linked list.

Mwah. Je bent niet slim bezig als je je vastbijt in generalisaties.
"Generalisations considered harmful" enzo.

Er zijn stomweg teveel libraries die dat veel beter en efficienter doen dan
jij (en zonder segfaults en memory leaks).

Daar ben ik het wel mee eens. Wat van belang is, dat je weet hoe die
generalisatie in elkaar steekt, en ook de beslissing kan nemen dat je
beter een eigen implementatie kan gebruiken.

Post by Martijn van Buul
Een slecht programmeur schrijft alles zelf - maar een programmeur die denkt
dat standaard oplossingen per definitie de juiste zijn, zal altijd maar
matigjes blijven. Van de andere kant is iemand die alles zelf schrijft omdat
de rest toch bagger is (en dus last heeft van het Not Invented Here syndroom)
waarschijnlijk bijzonder intelligent en slim - maar hij is ook niet handig
bezig. Een goed programmeur weet wanneer hij genoegen kan nemen met een
generieke oplossing, en wanneer het gebruik van die generieke oplossing
meer problemen oplevert dan oplost.

Mee eens. Ik heb niet willen beweren dat iedereen altijd de bestaande
implementaties moet gebruiken. Maar, als je een beginnend programmeur
bent (en ik meen dat we het daarover hebben), lijkt het me geen goed
idee om zelf zaken te implementeren die anderen waarschijnlijk beter
hebben gedaan.

Datzelfde geldt als wet

Het is geen wet. Hooguit een richtlijn voor matige programmeurs.

zelfs voor alles wat met encryptie te maken heeft. Goed om het te snappen,
dom om het zelf te implementeren.

Weer, ik dacht dat we het over een beginner hadden. Overigens denk ik
ook dat het geldt voor programmeurs die niet heel veel van encryptie
weten. Wat niet per se een matig programmeur hoeft te zijn.

Post by Martijn van Buul
Wat niet wil zeggen dat iedereen maar even zijn eigen encryptiealgoritme
moet gaan verzinnen, overigens.

Dat is wat ik bedoelde.

Wat ik absoluut gemist heb in alle lessen en cursussen die ik gehad heb,
is hoe de hele program-compile-link keten in elkaar steekt en hoe
bijvoorbeeld dynamic linking werkt.

Dan heb je de verkeerde cursussen gevolgd. Overigens is het niet zo heel
erg ingewikkeld op hoofdlijnen. Jammer genoeg zijn er wel veel platform-
afhankelijke details en eigenaardigheden.

Ook belangrijk is weten hoe een compiler werkt,

Waarom *wel* weten hoe een compiler werkt, maar *niet* hoeven te weten hoe
een linked list werkt.

Dat heb ik niet beweerd. Ik zeg nog "lezen en leren over algoritmen is
een goed idee". Je moet zeker *wel* weten hoe een LL werkt. Maar zelf
implementeren is niet per se een goed idee. Dat is wat ik bedoel.

Post by Martijn van Buul
Hmm, ergens klinkt dat als een contradictio in
teminus;

'in terminis'

Post by Martijn van Buul
als je weet wat voor bagger code gcc en stdlibc++ uit een simpele
std::list<bla> bouwen, is alleen *dat* al een argument waarom het gebruik
van STL in een aantal situaties voorkomen dient te worden - en dan heb ik het
nog niet eens gehad over de onhebbelijkheden van diezelfde STL die niet eens
compiler en implementatieafhankelijk zijn.
Hetgeen overigens niet wegneemt dat het gebruik van standaard containers
en dergelijke bijzonder nuttig kan zijn op plaatsen waar performance
niet zo belangrijk is.

Wat meestal niet geval is, tenminste, in mijn vakgebied is 'programmer
time' duurder dan 'computer time'. Ergens zwaardere hardware inzetten is
vaak goedkoper dan een algoritme tot de laatste klokcycle optimaliseren.

Bart

--
Bart Blogt Beter: blog.friesoft.nl

Ximinez

2010-01-01 14:49:09 UTC

Post by Martijn van Buul
["Followup-To:" header set to nl.comp.os.linux.discussie.]

Je bent niet slim bezig als je zelf een sorteerroutine implementeert of een
linked list.

Mwah. Je bent niet slim bezig als je je vastbijt in generalisaties.
"Generalisations considered harmful" enzo.

Er zijn stomweg teveel libraries die dat veel beter en efficienter doen dan
jij (en zonder segfaults en memory leaks).

Daar ben ik het wel mee eens. Wat van belang is, dat je weet hoe die
generalisatie in elkaar steekt, en ook de beslissing kan nemen dat je
beter een eigen implementatie kan gebruiken.

Datzelfde geldt als wet

Het is geen wet. Hooguit een richtlijn voor matige programmeurs.

zelfs voor alles wat met encryptie te maken heeft. Goed om het te snappen,
dom om het zelf te implementeren.

Weer, ik dacht dat we het over een beginner hadden. Overigens denk ik
ook dat het geldt voor programmeurs die niet heel veel van encryptie
weten. Wat niet per se een matig programmeur hoeft te zijn.

Post by Martijn van Buul
Wat niet wil zeggen dat iedereen maar even zijn eigen encryptiealgoritme
moet gaan verzinnen, overigens.

Dat is wat ik bedoelde.

Wat ik absoluut gemist heb in alle lessen en cursussen die ik gehad heb,
is hoe de hele program-compile-link keten in elkaar steekt en hoe
bijvoorbeeld dynamic linking werkt.

Dan heb je de verkeerde cursussen gevolgd. Overigens is het niet zo heel
erg ingewikkeld op hoofdlijnen. Jammer genoeg zijn er wel veel platform-
afhankelijke details en eigenaardigheden.

Ook belangrijk is weten hoe een compiler werkt,

Waarom *wel* weten hoe een compiler werkt, maar *niet* hoeven te weten hoe
een linked list werkt.

Post by Martijn van Buul
Hmm, ergens klinkt dat als een contradictio in
teminus;

'in terminis'

De hele discussie doet me denken aan Larry Wall's 3 virtues of a programmer:

1. Laziness - The quality that makes you go to great effort to
reduce overall energy expenditure. It makes you write labor-saving
programs that other people will find useful, and document what you wrote
so you don't have to answer so many questions about it. Hence, the first
great virtue of a programmer. Also hence, this book. See also impatience
and hubris.
2. Impatience - The anger you feel when the computer is being lazy.
This makes you write programs that don't just react to your needs, but
actually anticipate them. Or at least pretend to. Hence, the second
great virtue of a programmer. See also laziness and hubris.
3. Hubris - Excessive pride, the sort of thing Zeus zaps you for.
Also the quality that makes you write (and maintain) programs that other
people won't want to say bad things about. Hence, the third great virtue
of a programmer. See also laziness and impatience.

X.

richard lucassen

2010-01-01 15:25:36 UTC

On Fri, 01 Jan 2010 15:49:09 +0100
[..]

En niet te vergeten:

Program complexity grows until it exceeds the capabilities of the
programmer who must maintain it. Laws of Computer Programming, VII

A computer does what you ask, not what you want (K&R IIRC)

R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

Ximinez

2010-01-01 19:00:14 UTC

Post by richard lucassen
On Fri, 01 Jan 2010 15:49:09 +0100
[..]
Program complexity grows until it exceeds the capabilities of the
programmer who must maintain it. Laws of Computer Programming, VII

Die wet probeer ik al een tijdje te breken.

Post by richard lucassen
A computer does what you ask, not what you want (K&R IIRC)

Dat gold ook al voor de wens-vervullende geesten uit de sprookjes uit
1001 nacht.

X.

Martijn van Buul

2010-01-01 22:26:54 UTC

Besef wel dat we het hier over Papa Perl hebben. Dat alleen al zou voldoende
reden moeten wezen om zijn wijsheden met een korreltje zout te nemen ;)

--
Martijn van Buul - ***@dohd.org

John Bokma

2010-01-01 23:10:10 UTC

Post by Martijn van Buul
Besef wel dat we het hier over Papa Perl hebben. Dat alleen al zou voldoende
reden moeten wezen om zijn wijsheden met een korreltje zout te nemen ;)

Waarom?

Sterker, geef eens aan wat er mis is met die 3 regels? Ze gelden zeer
zeker voor mij. Ik bedoel: ik programmeer vaak dingen omdat ik (of
opdrachtgever) geen zin heb om dezelfde handeling met het handje te
blijven doen (1, het heet niet voor niets automatisering), als een
programma ergens te lang over doet, kijk ik of het slimmer kan (2), en
ik ben inderdaad trots op mijn werk, en doe vreselijk mijn best om
kwaliteit af te leveren (3)

De meeste mensen die iets over Perl te zeiken hebben (ik wil het
namelijk geen zeggen noemen) hebben er nooit serieus tijd in gestoken.

Is Perl perfect? Welnee, maar wat ik vaak zeg: er is geen perfecte
programmeertaal, want anders programmeerde ik daar wel in.

Overigens ben ik druk bezig met Python leren. Maar da's niet omdat ik
uitgePerlt ben.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Ximinez

2010-01-02 17:12:42 UTC

Post by Martijn van Buul
Besef wel dat we het hier over Papa Perl hebben. Dat alleen al zou voldoende
reden moeten wezen om zijn wijsheden met een korreltje zout te nemen ;)

Waarom?

Perl heeft tenminste humor ;)

X.

John Bokma

2010-01-02 19:23:07 UTC

Post by Ximinez

Post by Martijn van Buul
Besef wel dat we het hier over Papa Perl hebben. Dat alleen al zou voldoende
reden moeten wezen om zijn wijsheden met een korreltje zout te nemen ;)

Waarom?

Perl heeft tenminste humor ;)

Oh, dat zeker, maar is serieus waar nodig. Ik heb die "three virtues"
nooit als humor gelezen.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Ximinez

2010-01-03 13:50:41 UTC

Post by Martijn van Buul
Besef wel dat we het hier over Papa Perl hebben. Dat alleen al zou voldoende
reden moeten wezen om zijn wijsheden met een korreltje zout te nemen ;)

Waarom?

Perl heeft tenminste humor ;)

Oh, dat zeker, maar is serieus waar nodig. Ik heb die "three virtues"
nooit als humor gelezen.

De grap is natuurlijk dat die virtues doorgaans als vices worden gezien.

X.

John Bokma

2010-01-03 19:18:17 UTC

Post by Martijn van Buul
Besef wel dat we het hier over Papa Perl hebben. Dat alleen al zou voldoende
reden moeten wezen om zijn wijsheden met een korreltje zout te nemen ;)

Waarom?

Perl heeft tenminste humor ;)

Oh, dat zeker, maar is serieus waar nodig. Ik heb die "three virtues"
nooit als humor gelezen.

De grap is natuurlijk dat die virtues doorgaans als vices worden gezien.

Tuurlijk, er zijn altijd mensen die heel goed zijn in het aan overal een
negatieve draai geven, en overal vragen bij te stellen. Ik zie dat soort
mensen altijd bij bosjes op Slashdot, steeds meer over de jaren (helaas,
het lijkt soms wel een azijnzeikwedstrijd).

Er is best wel e.e.a. over Perl te zeggen, maar de luidste roeperts
zijn, mijn ervaring, vaak de mensen die dachten dat Perl een soort
shellscripten was, en met een beetje klooien dat wel even in een weekje
door konden krijgen /of/ mensen die dat soort zooi uiteindelijk moesten
onderhouden. Daarnaast zijn er bosjes mensen die aan Perl geroken hebben
eind vorige eeuw, toen het even leek dat het /de/ web ontwikkeltaal ging
worden, en ook dat kan je nu nog goed terugzien als die mensen Perl
schrijven...

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Martijn van Buul

2010-01-03 20:13:03 UTC

Post by John Bokma
Tuurlijk, er zijn altijd mensen die heel goed zijn in het aan overal een
negatieve draai geven,

Net zoals er mensen zijn die een knutseltaaltje als perl *zo* ze hemel in
prijzen dat ze iedere vorm van kritiek wegwimpelen als onzin en slecht
geinformeerd...

--
Martijn van Buul - ***@dohd.org

John Bokma

2010-01-03 21:23:57 UTC

Post by John Bokma
Tuurlijk, er zijn altijd mensen die heel goed zijn in het aan overal een
negatieve draai geven,

Net zoals er mensen zijn die een knutseltaaltje als perl *zo* ze hemel in
prijzen dat ze iedere vorm van kritiek wegwimpelen als onzin en slecht
geinformeerd...

Uiteraard zijn die mensen er ook, en dat is /ook/ gebrek aan kennis. Ze
weten vaak net iets meer dan de draaiers, maar nog steeds te weinig.

De enige programmeertaal waar ik echt niet mee kan opschieten is PHP. En
ik weet vrij zeker dat dat voor een deel (wellicht een groot deel) aan
mijn onkunde kan worden geweten.

Tenslotte, ik denk dat het een compliment is als je in een
programmeertaal kan knutselen, want ik denk dat het merendeel van de
programmeurs precies dat doet.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Martijn van Buul

2010-01-04 10:13:53 UTC

Post by John Bokma
Tenslotte, ik denk dat het een compliment is als je in een
programmeertaal kan knutselen, want ik denk dat het merendeel van de
programmeurs precies dat doet.

Het was ook niet als een pejoratief bedoeld. Perl, python en nog een paar
andere taaltjes (lua!) zijn erg geschikt om in te knutselen, en om
experimentjes te doen, en dat is ook prima. Het punt is alleen dat op het
moment dat iets het experimentele stadium voorbij is, het tijd wordt voor
een fatsoenlijke herimplementatie die te onderhouden valt - en met name
daarin schort het m.i. bij perl.

Je kunt in alle talen braswerk schrijven - maar perl maakt het je wel *heel*
moeilijk om het niet te doen.

YMMV

--
Martijn van Buul - ***@dohd.org

John Bokma

2010-01-04 15:20:49 UTC

Post by John Bokma
Tenslotte, ik denk dat het een compliment is als je in een
programmeertaal kan knutselen, want ik denk dat het merendeel van de
programmeurs precies dat doet.

Het was ook niet als een pejoratief bedoeld.

Daar hoopte ik ook op, vandaar mijn reaktie dat het een compliment is.

Post by Martijn van Buul
Perl, python en nog een paar
andere taaltjes (lua!) zijn erg geschikt om in te knutselen, en om
experimentjes te doen, en dat is ook prima. Het punt is alleen dat op het
moment dat iets het experimentele stadium voorbij is, het tijd wordt voor
een fatsoenlijke herimplementatie die te onderhouden valt - en met name
daarin schort het m.i. bij perl.

Waaraan? Het refactoren van de code, of het onderhouden?

Refactoren (herimplementatie) is te voorkomen door het experiment goed
te plannen (net als met een "niet-knutsel-taal", en met de nodige
documentatie is de code ook goed te onderhouden is mijn ervaring. De
noodzaak van herimplementatie in een andere programmeertaal ben ik zelf
nog niet tegengekomen. Dat komt ook omdat ik een aardig idee heb van wat
Perl wel/niet kan, en het uiteindelijke programma (meer dan) snel genoeg
is (voorbeeld: nabewerken van een complexe netlijst [1] van 5+ MB kost
een paar seconden, wat meer dan acceptabel is in dit geval).

Post by Martijn van Buul
Je kunt in alle talen braswerk schrijven - maar perl maakt het je wel *heel*
moeilijk om het niet te doen.

Heb je een voorbeeld? Ik ben nog geen enkele taal tegengekomen die het
mij moeilijk maakte om netjes en leesbaar te programmeren en makkelijk
om er een zooitje van te schoppen. Ik heb het altijd een beetje een
onzin verhaal gevonden: Perl nodigt uit tot slordig programmeren. Sinds
wanneer bepaald een programmeertaal hoe ik (jij) programmeerd? Voor mij
is dat net zo maf als roepen dat het aan de editor (het programma, niet
de persoon die je schrijfsels naakijkt) ligt.

Wat ik al eerder schreef: waar Perl het meeste last van heeft is dat het
in de jaren 90 ineens door iedereen "geleerd" werd, vaak als 2e of 3e
taal (oh, ik kan al programmeren, en Perl is een soort shell
scripten). En veel rommel (en ideeen over Perl) stamt uit die tijd.

Tenslotte, ik wil zeker niet beweren dat Perl perfect is; net als elke
taal zijn er veel punten wat anders gedaan zou kunnen worden. Een deel
van die punten is persoonlijk, en een deel zijn veel mensen het over
eens. Het niet eenvoudig is om een taal even op de schop te nemen als
die al 20+ jaar oud is, zeker niet als de ontwikkelaars van die taal zo
veel mogelijk oud spul zo lang mogelijk willen ondersteunen (een groot
deel van de CPAN modules draaien nog probleemloos op Perl 5.00x, ik heb
nog klanten die "net" op het bijna 10 jaar oude 5.6 zitten, etc. ). Niet
voor niets is Perl 6 dan ook een nieuwe programmeertaal, en niet Perl 5
met wat toeters en bellen [2]. Perl 5 ontwikkeling gaat ook nog gewoon door
en een aantal ideeen uit 6 duiken langzaamaan in 5 op.

[1] netlijst als in modules met ORs, ANDs, flip-flops, etc.
[2] ik voel de grappen al als: Perl 6 is alleen maar toeters en bellen

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

unknown

2010-01-04 19:45:41 UTC

Post by John Bokma
De enige programmeertaal waar ik echt niet mee kan opschieten is PHP. En
ik weet vrij zeker dat dat voor een deel (wellicht een groot deel) aan
mijn onkunde kan worden geweten.

Ik kan behoorlijk opschieten met PHP, en je kan er best mooie dingen mee
maken, maar al met al is het een draak van een taal. Alles mag en alles
kan zo'n beetje. Het wordt evolutionair ontwikkeld zonder een zekere
roadmap (tenminste, zo voelt het aan).

Maar heerlijk taaltje om lekker even snel iets in elkaar te knallen,
SQL, file handling, etc.

Bart

--
Bart Blogt Beter: blog.friesoft.nl

John Bokma

2010-01-04 19:59:06 UTC

Post by John Bokma
De enige programmeertaal waar ik echt niet mee kan opschieten is PHP. En
ik weet vrij zeker dat dat voor een deel (wellicht een groot deel) aan
mijn onkunde kan worden geweten.

Wat bij mij niet helpt is dat ik diep in Perl zit, en PHP heeft een
aantal overeenkomsten met Perl, en dan bergen weer niet, het is dus
lastig, zeker als ik beiden op 1 dag naast elkaar gebruik, om het goed
te scheiden. (Ik heb ook wel eens dat ik per ongeluk een ; inklop in
Python na een dag Perl, maar daar is eenvoudig op te zoeken, ik zou
emacs zelfs het kunnen laten markeren)

Post by unknown
Maar heerlijk taaltje om lekker even snel iets in elkaar te knallen,
SQL, file handling, etc.

Yup, daar heb ik nu Perl vnl. voor.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

unknown

2010-01-04 20:17:37 UTC

Post by John Bokma
Wat bij mij niet helpt is dat ik diep in Perl zit, en PHP heeft een
aantal overeenkomsten met Perl, en dan bergen weer niet, het is dus
lastig, zeker als ik beiden op 1 dag naast elkaar gebruik, om het goed
te scheiden. (Ik heb ook wel eens dat ik per ongeluk een ; inklop in
Python na een dag Perl, maar daar is eenvoudig op te zoeken, ik zou
emacs zelfs het kunnen laten markeren)

Ik ken het. PHP laat ik nog wel eens Javascript code genereren. Of je
switcht tussen Javascript en PHP en C. Dan staat er wel eens een $ voor
je variable in C en gaat gcc weer lopen mutsen ;).

Post by unknown
Maar heerlijk taaltje om lekker even snel iets in elkaar te knallen,
SQL, file handling, etc.

Yup, daar heb ik nu Perl vnl. voor.

Kan het idd ook heel goed mee.

Bart

--
Bart Blogt Beter: blog.friesoft.nl

Lolo

2010-01-04 23:49:39 UTC

Post by John Bokma
Tuurlijk, er zijn altijd mensen die heel goed zijn in het aan overal een
negatieve draai geven,

Net zoals er mensen zijn die een knutseltaaltje als perl *zo* ze hemel in
prijzen dat ze iedere vorm van kritiek wegwimpelen als onzin en slecht
geinformeerd...

En toch, PHP heeft ook wel weer wat, het is vaak appels en peren met die
talen vergelijken omdat het toepassingsgebied vaak specifiek is. Maar
wat Perl betreft, ik heb eigenlijk aangeboren met een diepe afkeer van
Perl, vond een aantal boeken heel naar om te lezen en als je code zag
dan zag ik een paar vishaken die een loop blijken te zijn, pfff dat is
geen fijne syntax. Maar ook weer wel nu ik er wel mee te maken heb sinds
een tijd. En toch is mijn enthousiasme erg toegenomen, je flanst snel
wat in elkaar een vooral die enorme zwik bibliotheken, een heel handige
taal en een echte programmeertaal bij de hand, reguliere expressie heel
goed, een mooie stap bovenop de shell. Wat natuurlijk niet wegneemt dat
ook een uiterst ongelukkige taal in een aantal opzichten is, de
mogelijkheid tot het gebruik van die $ variabelen en alles maar
impliciet, ik neem aan dat dat dat in Perl 6 volledig is uitgeschakeld.
Maar misschien moet ik nog over die hobbel heen, schaamteloos mininmaal
programmeren maar daar dat is toch wel heel lastig.

Louis

John Bokma

2010-01-05 00:48:18 UTC

Post by Lolo
En toch, PHP heeft ook wel weer wat, het is vaak appels en peren met
die talen vergelijken omdat het toepassingsgebied vaak specifiek
is. Maar wat Perl betreft, ik heb eigenlijk aangeboren met een diepe
afkeer van Perl, vond een aantal boeken heel naar om te lezen

Programming Perl soms? Dat is ook zeer zeker geen beginnersboek maar
meer een (inmiddels redelijk veroudert) naslagwerk. Het is een beetje
als een taal proberen te leren uit een encyclopedie, geen feest.

Post by Lolo
en als
je code zag dan zag ik een paar vishaken die een loop blijken te zijn,

Eh, dat was geen Perl, tenminste in Perl zijn vishaken geen loop. Wat je
wellicht wel bedoelt is iets als:

open my $fh, '<', $filename
or die "Can't open '$filename for reading: $!";
while ( my $line = <$fh> ) {

:
:

De vishaken (diamond operator cq. angle operator) is gewoon een kortere
notatitie voor readline. Het is even wennen, tot je inziet wat het
bespaard aan geklop. Zie het als ipv add_numbers( 4, 5 ) gewoon 4 + 5
kunnen schrijven ;-)

Post by Lolo
pfff dat is geen fijne syntax. Maar ook weer wel nu ik er wel mee te
maken heb sinds een tijd. En toch is mijn enthousiasme erg toegenomen,
je flanst snel wat in elkaar een vooral die enorme zwik bibliotheken,
een heel handige taal en een echte programmeertaal bij de hand,
reguliere expressie heel goed, een mooie stap bovenop de shell. Wat
natuurlijk niet wegneemt dat ook een uiterst ongelukkige taal in een
aantal opzichten is,

Welke (naast die je gaat noemen)

Post by Lolo
de mogelijkheid tot het gebruik van die $variabelen

Welke? Je bedoelt dingen als $|, $!, $., etc? Dan zet je boven aan je
programma use English; ;-)

Post by Lolo
variabelen en alles maar impliciet,

Dat is een keuze, het hoeft niet overal en altijd.
($_ bedoel je gok ik) als het er niet zo toe doet hoe de variabele heet,
of als het hele korte code is, en uit de context blijkt waar het over
gaat. Net zoals wij dat in Nederlands ook gewoon doen.

Post by Lolo
ik neem aan dat dat dat in Perl 6
volledig is uitgeschakeld. Maar misschien moet ik nog over die hobbel
heen, schaamteloos mininmaal programmeren maar daar dat is toch wel
heel lastig.

Het hoeft dan ook niet. Ik schrijf dingen gewoon uit als het de code
duidelijker maakt (zie boven, ik ken de ingelezen regel netjes aan $line
toe).

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Lolo

2010-01-05 22:58:25 UTC

Post by John Bokma
Programming Perl soms? Dat is ook zeer zeker geen beginnersboek maar
meer een (inmiddels redelijk veroudert) naslagwerk. Het is een beetje
als een taal proberen te leren uit een encyclopedie, geen feest.

Geen feest nee.

Post by unknown
en als
je code zag dan zag ik een paar vishaken die een loop blijken te zijn,

Eh, dat was geen Perl, tenminste in Perl zijn vishaken geen loop. Wat je
open my $fh, '<', $filename
or die "Can't open '$filename for reading: $!";
while ( my $line = <$fh> ) {
De vishaken (diamond operator cq. angle operator) is gewoon een kortere
notatitie voor readline. Het is even wennen, tot je inziet wat het
bespaard aan geklop. Zie het als ipv add_numbers( 4, 5 ) gewoon 4 + 5
kunnen schrijven ;-)

Inderdaad die bedoel ik en wat jij nu schrijft is uitgebreid perl maar
in de regel zie je anders.

Post by unknown
pfff dat is geen fijne syntax. Maar ook weer wel nu ik er wel mee te
maken heb sinds een tijd. En toch is mijn enthousiasme erg toegenomen,
je flanst snel wat in elkaar een vooral die enorme zwik bibliotheken,
een heel handige taal en een echte programmeertaal bij de hand,
reguliere expressie heel goed, een mooie stap bovenop de shell. Wat
natuurlijk niet wegneemt dat ook een uiterst ongelukkige taal in een
aantal opzichten is,

Welke (naast die je gaat noemen)

Het omgaan met variabelen vind ik wat mal, je hoeft niets aan te geven
bij een functie en inderdaad wat ik al noem maar dat is ook wel de
belangrijkste, het impliciete wat het zeer lastig maakt, het nodigt uit
tot onbegrijpelijkheid. Maar goh, ik neem de voors, en je kan er ook
weer korte en handige dingen mee doen, ja ben ook echt enthousiast
geworden al vind ik het een van de lastigste die ik zo ken.

Post by John Bokma
Het hoeft dan ook niet. Ik schrijf dingen gewoon uit als het de code
duidelijker maakt (zie boven, ik ken de ingelezen regel netjes aan $line
toe).

Die weg probeer ik ook wat te gaan. Al was het maar dat ik er zelf nog
iets van begrijp.

Louis

John Bokma

2010-01-06 00:28:26 UTC

Lolo <***@xs4all.nl> writes:

[angle/diamond operator]

Post by Lolo
Inderdaad die bedoel ik en wat jij nu schrijft is uitgebreid perl
maar in de regel zie je anders.

Ja, dat komt voor een deel door wat ik al eerder noemde: Perl is een
tijdje "hot" geweest, en uit die tijd stamt een enorme berg zooi
code. Je ziet dat nu erg terug bij PHP vind ik, kijk maar eens bij de
online manual pages van PHP wat voor code daar nu en dan in de reakties
voorgesteld wordt..

Post by Lolo
Het omgaan met variabelen vind ik wat mal, je hoeft niets aan te geven
bij een functie

Je bedoelt dat iets als chomp default op $_ werkt. Ja, ik probeer dat
zoveel mogelijk niet te doen /tenzij/ het duidelijk is (korte code) en
een expliciete variabele niet echt nodig is. Een voorbeeld waar ik $_
impliciet gebruik is iets als:

for ( $string ) {

s/.../.../;
s/.../.../;
:
:
}

Wat dit doet is dat $_ een alias wordt voor $string, waardoor je
je niet telkens $string =~ s/.../.../; hoeft te schrijven.

Als dit "onbegrijpelijke" Perl code is, dan kan je in een for lus op je
neus gaan ;-)

Post by Lolo
en inderdaad wat ik al noem maar dat is ook wel de
belangrijkste, het impliciete wat het zeer lastig maakt, het nodigt
uit tot onbegrijpelijkheid.

Het is de programmeur die ingaat op die uitnodiging. Dat je source kan
kloppen in unicode is toch ook geen uitnodiging om alle identifiers maar
in Tengwar te kloppen? Het is een minirok-argument!

Post by Lolo
Maar goh, ik neem de voors, en je kan er
ook weer korte en handige dingen mee doen, ja ben ook echt enthousiast
geworden al vind ik het een van de lastigste die ik zo ken.

Ik ken geen programmeertalen die niet lastig zijn. Ik ben al een tijd
bezig met het leren van Python, maar ik ben nog wel zeker een jaartje
zoet voor ik er vloeiend in ben.

Post by Lolo

Post by John Bokma
Het hoeft dan ook niet. Ik schrijf dingen gewoon uit als het de code
duidelijker maakt (zie boven, ik ken de ingelezen regel netjes aan
$line toe).

Die weg probeer ik ook wat te gaan. Al was het maar dat ik er zelf nog
iets van begrijp.

Dat is altijd belangrijk ;-)

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Jawade

2010-01-06 17:35:58 UTC

John Bokma <***@castleamber.com> schreef op Tue, 5 Jan 2010 18:28:26 -0600 in artikel <***@castleamber.com>:

..

Post by John Bokma
Ik ken geen programmeertalen die niet lastig zijn. Ik ben al een tijd
bezig met het leren van Python, maar ik ben nog wel zeker een jaartje
zoet voor ik er vloeiend in ben.

..

Nou, wat denk je van BASIC? Dat begrijpt een kind nog wel, het is bijna
spreektaal.

--
Met vriendelijke groeten, Jawade. Kolibrie Software Tools:
http://jawade.nl/ 14 nov: HexEditor, Diskeditors met MBR-rebuilders!
Bootmanager (+Vista +Linux +Engels), ClrMBR, SDir(DIRsize), POP3lezer,
Console-filebrowser, Kalender, Webtellers en IP-log, USB-stick tester.

John Bokma

2010-01-06 19:15:14 UTC

Post by Jawade
..

Post by John Bokma
Ik ken geen programmeertalen die niet lastig zijn. Ik ben al een tijd
bezig met het leren van Python, maar ik ben nog wel zeker een jaartje
zoet voor ik er vloeiend in ben.

..
Nou, wat denk je van BASIC? Dat begrijpt een kind nog wel, het is bijna
spreektaal.

Wellicht verwar je syntax (wat inderdaad simpel is, voor veel
programmeertalen) met echt begrijpen wat iets doet en het goed kunnen
toepassen? En alle uitzonderingen, en natuurlijk de belangrijke
bibliotheken kunnen toepassen.

Ik doe Perl professioneel sinds 1994 (ik had al eens eerder aan Perl (3
IIRC) geroken, maar niet echt veel er in geprogrammeerd) en leer nog
regelmatig nieuwe dingen, of zie dingen waarvan ik zeg: aha, dat kan ook
op die manier.

Leuk (algemeen, niet Perl specifiek) leesvoer hierover:
http://norvig.com/21-days.html

Overigens heb ik een hele tijd in BASIC geprogrammeerd (op de ZX 81, ZX
Spectrum, Acorn Archimedes en heel weinig op een PC (GW-BASIC?)). En op
de uni (UU) was het niet ongewoon om bij een vak een taal te leren, en
dan op het tentame er in te moeten kunnen "programmeren". Bij het vak
OOP kwamen er zelfs 5+ talen voorbij (C++, Object Pascal, Objective C,
Smalltalk, Eiffel, etc.) en waren er dus vragen als: hoe doe je dit in
Objective C. Dus ja, syntax leren is niet zo ingewikkeld, en kleine
dingetjes doen in een taal. Maar een taal van voren tot achteren
beheersen kost nogal wat tijd.

Het is een beetje het verschil tussen een maaltijd kunnen bestellen in
een taal (Engels, Frans, Spaans, etc.), en er een gedicht/boek in kunnen
schrijven en/of de meeste grappen er in kunnen begrijpen. Dat eerste
leren nogal wat mensen tijdens een vakantie. Dat laatste kost de nodige tijd.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Jawade

2010-01-06 20:48:51 UTC

Post by Jawade
..

Post by John Bokma
Ik ken geen programmeertalen die niet lastig zijn. Ik ben al een tijd
bezig met het leren van Python, maar ik ben nog wel zeker een jaartje
zoet voor ik er vloeiend in ben.

..
Nou, wat denk je van BASIC? Dat begrijpt een kind nog wel, het is bijna
spreektaal.

Wellicht verwar je syntax (wat inderdaad simpel is, voor veel
programmeertalen) met echt begrijpen wat iets doet en het goed kunnen
toepassen? En alle uitzonderingen, en natuurlijk de belangrijke
bibliotheken kunnen toepassen.
Ik doe Perl professioneel sinds 1994 (ik had al eens eerder aan Perl (3
IIRC) geroken, maar niet echt veel er in geprogrammeerd) en leer nog
regelmatig nieuwe dingen, of zie dingen waarvan ik zeg: aha, dat kan ook
op die manier.
http://norvig.com/21-days.html
Overigens heb ik een hele tijd in BASIC geprogrammeerd (op de ZX 81, ZX
Spectrum, Acorn Archimedes en heel weinig op een PC (GW-BASIC?)). En op
de uni (UU) was het niet ongewoon om bij een vak een taal te leren, en
dan op het tentame er in te moeten kunnen "programmeren". Bij het vak
OOP kwamen er zelfs 5+ talen voorbij (C++, Object Pascal, Objective C,
Smalltalk, Eiffel, etc.) en waren er dus vragen als: hoe doe je dit in
Objective C. Dus ja, syntax leren is niet zo ingewikkeld, en kleine
dingetjes doen in een taal. Maar een taal van voren tot achteren
beheersen kost nogal wat tijd.
Het is een beetje het verschil tussen een maaltijd kunnen bestellen in
een taal (Engels, Frans, Spaans, etc.), en er een gedicht/boek in kunnen
schrijven en/of de meeste grappen er in kunnen begrijpen. Dat eerste
leren nogal wat mensen tijdens een vakantie. Dat laatste kost de nodige tijd.

Je moet natuurlijk wel kunnen programmeren. Dat moet je gewoon leren.
Maar als je dat kunt, kun je met BASIC snel uit de voeten. Ik heb pas
nog wat geprogrammeerd op de Archimedes, een bijzonder krachtige
BASIC, mede omdat je assembly kunt insluiten en je rechtstreeks
gebruik kunt maken van de systeemroutines. Daar heb je dan wel weer
de Programmers Reference Manual voor nodig, maar die heb ik destijds
gekocht. Tegenwoordig is FreeBASIC mijn favoriet, erg uitgebreid,
ook C-style, en kleine executables. Ook enclosed assembly. Perl is
mooi, maar heeft voor mij het nadeel dat je het nauwelijks kunt
distribueren, of je moet perl2exe gebruiken, en die output wordt per
Perl-versie reusabler. Ik gebruik het nog wel voor net-toepassingen,
waar het erg geschikt voor is.

John Bokma

2010-01-06 23:46:38 UTC

Post by Jawade
Je moet natuurlijk wel kunnen programmeren. Dat moet je gewoon leren.
Maar als je dat kunt, kun je met BASIC snel uit de voeten.

Maar wat is uit de voeten kunnen precies? Ik kan programmeren (sinds
1983) maar vloeiend Python, om maar iets te noemen, kost mij toch de
nodige tijd. Ik gok dat jij een maaltijd bestellen bedoelt, terwijl ik
meer een boek schrijven bedoel ;-).

Post by Jawade
Ik heb pas nog wat geprogrammeerd op de Archimedes, een bijzonder
krachtige BASIC, mede omdat je assembly kunt insluiten en je
rechtstreeks gebruik kunt maken van de systeemroutines.

Been there, done that ;-) Van +/- 1987 (als ik mij goed herinner) t/m
ergens medio jaren 90. Niet alleen BASIC, maar ook Pascal (ik kocht
Pascal er toendertijd bij, maar.... geen editor [1]), C en C++ (en wat Perl
en Gofer).

Post by Jawade
Daar heb je dan wel weer de Programmers Reference Manual voor nodig,
maar die heb ik destijds gekocht.

Yup, ik ook. Tegenwoordig kan je de PDFjes gewoon downloaden
e.d. (legaal voor zover ik kan zien).

http://foundation.riscos.com/Private/index.htm

Post by Jawade
Tegenwoordig is FreeBASIC mijn favoriet, erg uitgebreid, ook C-style,
en kleine executables. Ook enclosed assembly. Perl is mooi, maar heeft
voor mij het nadeel dat je het nauwelijks kunt distribueren, of je
moet perl2exe gebruiken,

of PAR (toevallig vandaag nog :-D). Ander nadeel is dat het ietwat groot
wordt, ActivePerl + WxWidgets ~ 8MB exe.

Post by Jawade
en die output wordt per Perl-versie reusabler. Ik gebruik het nog wel
voor net-toepassingen, waar het erg geschikt voor is.

[1] Dus zelf een simpele editor in BASIC gemaakt :-).

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Jawade

2010-01-07 16:09:41 UTC

Post by Jawade
Je moet natuurlijk wel kunnen programmeren. Dat moet je gewoon leren.
Maar als je dat kunt, kun je met BASIC snel uit de voeten.

Als je de essentie van programmeren niet begrijpt, helpt het natuurlijk
niet als je de syntaxis wel kent. Programmeren is eigenlijk problemen
oplossen. Als ik dat boek letterlijk neem, dat is wel heel eenvoudig te
programmeren. :-) Ik doe elk terrein, behalve databases, tenminste, die
maak ik zelf.

Post by Jawade
Ik heb pas nog wat geprogrammeerd op de Archimedes, een bijzonder
krachtige BASIC, mede omdat je assembly kunt insluiten en je
rechtstreeks gebruik kunt maken van de systeemroutines.

Ja, wist ik. De kracht van a?b of a!b is uniek, was al aanwezig op de
Atom (1980). Nee, ik heb nooit andere talen gedaan op de Arc. Geen
behoefte aan, i.c.m. slechte verkrijgbaarheid (ook duur).
Een editor maken is natuurlijk een leuke uitdaging. Die maakte ik ook
al voor de Atom, voor BASIC.

Post by Jawade
Daar heb je dan wel weer de Programmers Reference Manual voor nodig,
maar die heb ik destijds gekocht.

Yup, ik ook. Tegenwoordig kan je de PDFjes gewoon downloaden
e.d. (legaal voor zover ik kan zien).
http://foundation.riscos.com/Private/index.htm

Mooie link. Ja, dat had je toen niet, geen internet. Mijn 3-delige PRM
kosste iets van 350 gulden.

of PAR (toevallig vandaag nog :-D). Ander nadeel is dat het ietwat groot
wordt, ActivePerl + WxWidgets ~ 8MB exe.

Ja, daarom houd ik het maar op FreeBASIC, op wat net-tooltjes na dan.

Post by Jawade
en die output wordt per Perl-versie reusabler. Ik gebruik het nog wel
voor net-toepassingen, waar het erg geschikt voor is.

[1] Dus zelf een simpele editor in BASIC gemaakt :-).

John Bokma

2010-01-07 18:27:55 UTC

Post by Jawade
Je moet natuurlijk wel kunnen programmeren. Dat moet je gewoon leren.
Maar als je dat kunt, kun je met BASIC snel uit de voeten.

Als je de essentie van programmeren niet begrijpt, helpt het natuurlijk
niet als je de syntaxis wel kent. Programmeren is eigenlijk problemen
oplossen.

En dan heb je dus aan de syntax alleen niet genoeg, je moet ook de
idiomen in de taal kennen. Ik bedoel, ik kan praten, ik ken voldoende
Spaanse worden, maar het ontbreekt mij aan idiomen om een gesprek te
kunnen voeren ;-).

Als wat jij zegt zou kloppen zou een nieuwe taal leren een eitje moeten
zijn: je kan al programmeren, en syntax is meestal het probleem
niet. Toch kost het mij de nodige tijd om goed in Python te worden. En
ik ben vrij zeker dat elke programmeur hier last van heeft.

Post by Jawade
Als ik dat boek letterlijk neem, dat is wel heel eenvoudig te
programmeren. :-)

Welk boek?

Post by Jawade
Ja, wist ik. De kracht van a?b of a!b is uniek, was al aanwezig op de
Atom (1980). Nee, ik heb nooit andere talen gedaan op de Arc. Geen
behoefte aan, i.c.m. slechte verkrijgbaarheid (ook duur).

Gofer en Perl (om er maar twee te noemen) zijn gratis. Volgens mij was
er ook een gratis Forth voor de Archimedes. Maar inderdaad, je moest
toen of een Internet aansluiting hebben (of minstens een modem) of
mensen kennen die dat hadden (evt. via via).

Post by John Bokma
http://foundation.riscos.com/Private/index.htm

Mooie link. Ja, dat had je toen niet, geen internet. Mijn 3-delige PRM
kosste iets van 350 gulden.

Yup, in een mooie box. Enne, het was 3 delen + dun index boekje, toch?
Over prijzen gesproken, ik kocht rond die tijd ook een Acorn SCSI kaart
met een 125 MB (!) Conner diskje. Was volgens mij ergens rond de 1500
gulden...

Leuke tijd, deed toen ook veel hardware hacking: MEMC1a upgrade,
RISC OS 3 roms, Joystick interface, VIDC enhancer, 4MB upgrade (the hard
way, totaal ca. 10 computers zo gedaan), en mijn eigen ARM3 upgrade
(heel veel werk).

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Jawade

2010-01-07 21:06:52 UTC

Post by Jawade
Als je de essentie van programmeren niet begrijpt, helpt het natuurlijk
niet als je de syntaxis wel kent. Programmeren is eigenlijk problemen
oplossen.

Als je kunt programmeren lijkt mij dat geen punt. In Perl moet ik
alles opzoeken, maar ik weet wat ik wil en hoe het ongeveer gaat,
dus dat is verder geen probleem.

Post by John Bokma
Als wat jij zegt zou kloppen zou een nieuwe taal leren een eitje moeten
zijn: je kan al programmeren, en syntax is meestal het probleem
niet. Toch kost het mij de nodige tijd om goed in Python te worden. En
ik ben vrij zeker dat elke programmeur hier last van heeft.

Nogmaals Perl, ondanks de lastige syntax kon ik daar toch vrij snel
iets nuttigs mee maken.

Post by Jawade
Als ik dat boek letterlijk neem, dat is wel heel eenvoudig te
programmeren. :-)

Welk boek?

Het boek uit jouw beeldspraak. :-)

Ik had beide niet, dus dat was lastig. Het is ook een belangrijke
reden dat ik overgegaan ben naar MS.

Post by John Bokma
http://foundation.riscos.com/Private/index.htm

Mooie link. Ja, dat had je toen niet, geen internet. Mijn 3-delige PRM
kosste iets van 350 gulden.

Yup, in een mooie box. Enne, het was 3 delen + dun index boekje, toch?
Over prijzen gesproken, ik kocht rond die tijd ook een Acorn SCSI kaart
met een 125 MB (!) Conner diskje. Was volgens mij ergens rond de 1500
gulden...
Leuke tijd, deed toen ook veel hardware hacking: MEMC1a upgrade,
RISC OS 3 roms, Joystick interface, VIDC enhancer, 4MB upgrade (the hard
way, totaal ca. 10 computers zo gedaan), en mijn eigen ARM3 upgrade
(heel veel werk).

Ja, met dun boekje. Ik geloof zelfs dat het meer delen waren. Het moet
nog ergens liggen, maar ik zou even niet weten waar. Wel vond ik een
prijslijstje:

A410/1 met RGB-monitor: F 5150,-
Upgrade naar 4 MB: 800,-
Nec st506 40 MB drive: 950,-
Risc OS PRM: 392,-

Later heb ik nog eenzelfde drive opgescharreld en erin gezet.
Ik heb versie 2 vorig jaar geupgrade naar 3 dankzij een behulpzame
medehobbyist. Alleen deden verschillende tools het toen niet meer
goed. Maar dat komt waarschijnlijk ondat ik toen nog niet zo netjes
programmeerde. Ook de opmaak, alles aan elkaar geplakt, doe ik nu
heel wat beter. :-)

Ik heb het toetsenbord nog geopend en schoongemaakt, is erg vuil-
gevoelig, maar nu draait 'ie weer als een tierelier. Dik 21 jaar
oud!

John Bokma

2010-01-07 21:38:31 UTC

Post by Jawade
Als je de essentie van programmeren niet begrijpt, helpt het natuurlijk
niet als je de syntaxis wel kent. Programmeren is eigenlijk problemen
oplossen.

Als je kunt programmeren lijkt mij dat geen punt. In Perl moet ik
alles opzoeken, maar ik weet wat ik wil en hoe het ongeveer gaat,
dus dat is verder geen probleem.

Ja, dat is dus net als een gesprek voeren met een zinnetjesboek. Dat is
geen vloeiend programmeren, en je bent overgelaten aan de (on)kunde van
de samensteller van dat zinnetjesboek.

Nogmaals Perl, ondanks de lastige syntax kon ik daar toch vrij snel
iets nuttigs mee maken.

Mijn vraag is: hoe leesbaar is het voor een ervaren Perl programmeur, en
wat vind die er van. De meeste Nederlanders kunnen wel steenkolen-
Engels, maar het is daarmee lastig een gesprek te voeren, een boek te
lezen, of een film te volgen.

Post by John Bokma
Gofer en Perl (om er maar twee te noemen) zijn gratis. Volgens mij was
er ook een gratis Forth voor de Archimedes. Maar inderdaad, je moest
toen of een Internet aansluiting hebben (of minstens een modem) of
mensen kennen die dat hadden (evt. via via).

Ik had beide niet, dus dat was lastig. Het is ook een belangrijke
reden dat ik overgegaan ben naar MS.

Ja, kan ik mij voorstellen. Alles zelf moeten programmeren houd op den
duur een keer op. Ik kon op zekere dag in een winkel diverse floppies
kopieeren als ik daar maar de floppies kocht (echt waar).

Post by Jawade
Ja, met dun boekje. Ik geloof zelfs dat het meer delen waren. Het moet
nog ergens liggen, maar ik zou even niet weten waar. Wel vond ik een
A410/1 met RGB-monitor: F 5150,-
Upgrade naar 4 MB: 800,-
Nec st506 40 MB drive: 950,-
Risc OS PRM: 392,-

Ja, een Acorn was best een hoop geld toen. Pascal was ook een paar
honderd gulden (300+ of zo).

Post by Jawade
Ik heb het toetsenbord nog geopend en schoongemaakt, is erg vuil-
gevoelig, maar nu draait 'ie weer als een tierelier. Dik 21 jaar
oud!

Yup, ik twijfel er niet echt aan dat mijn oude Archie het ook nog doet
(staat in Nederland) ondanks de vele hardware hacks :-D. Maar eh, draai
jij geen Archimedes emulator op je PC? Heb ik heel kort gedaan, en het
werkt erg goed.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Jawade

2010-01-08 17:26:17 UTC

Post by John Bokma
En dan heb je dus aan de syntax alleen niet genoeg, je moet ook de
idiomen in de taal kennen. Ik bedoel, ik kan praten, ik ken voldoende
Spaanse worden, maar het ontbreekt mij aan idiomen om een gesprek te
kunnen voeren ;-).

Als je kunt programmeren lijkt mij dat geen punt. In Perl moet ik
alles opzoeken, maar ik weet wat ik wil en hoe het ongeveer gaat,
dus dat is verder geen probleem.

Ja, dat is dus net als een gesprek voeren met een zinnetjesboek. Dat is
geen vloeiend programmeren, en je bent overgelaten aan de (on)kunde van
de samensteller van dat zinnetjesboek.

Ik snap jou wel, maar het werkt best hoor, er zijn legio voorbeelden
op internet. Ik kan eigenlijk alleen maar in BASIC en Assembly zonder
'afkijken' iets maken. C++ lijkt weer erg veel op andere talen, dus da's
altijd even zoeken. Terwijl de syntax feitelijk simpel is.

Nogmaals Perl, ondanks de lastige syntax kon ik daar toch vrij snel
iets nuttigs mee maken.

Oh, gegarandeerd leesbaar. Ik programmeer altijd netjes, al was het
maar om ervoor te zorgen dat ik het later zelf nog begrijp.

Ik had beide niet, dus dat was lastig. Het is ook een belangrijke
reden dat ik overgegaan ben naar MS.

Ja, kan ik mij voorstellen. Alles zelf moeten programmeren houd op den
duur een keer op. Ik kon op zekere dag in een winkel diverse floppies
kopieeren als ik daar maar de floppies kocht (echt waar).

Ja, ik ook, bij ECD in Delft. Er stond speciaal een computer voor. :-)
Maar ja, een doos floppies was best een hele investering.

Ja, een Acorn was best een hoop geld toen. Pascal was ook een paar
honderd gulden (300+ of zo).

Post by Jawade
Ik heb het toetsenbord nog geopend en schoongemaakt, is erg vuil-
gevoelig, maar nu draait 'ie weer als een tierelier. Dik 21 jaar
oud!

Ja, best degelijk spul. Overigens staat hier nog een Wang 286, die is
ook onverslijtbaar. Je hebt er niks aan, maar ja, nostalgie he.
Ja, ik heb Red Squirrel, een hele beste. Maar er gaat natuurlijk niks
boven de echte Arc, het enige is dat de monitor (type 1) beperkt is.
Maar ja, een Taxan kostte 1600 gulden...

John Bokma

2010-01-08 19:44:41 UTC

[..]

Post by Jawade
Ik snap jou wel, maar het werkt best hoor, er zijn legio voorbeelden
op internet.

Ja, precies, die bedoel ik. Als je wat dieper in een taal ziet, zie je
toch (ik dan wel) dat veel van die voorbeelden rammelen, en wel aan alle
kanten. Tenminste ik zie dat met Perl en PHP. Ik moet mijn voorbeelden
op mijn site ook nodig eens op de schop nemen ;-)

Post by John Bokma
Mijn vraag is: hoe leesbaar is het voor een ervaren Perl programmeur, en
wat vind die er van. De meeste Nederlanders kunnen wel steenkolen-
Engels, maar het is daarmee lastig een gesprek te voeren, een boek te
lezen, of een film te volgen.

Oh, gegarandeerd leesbaar. Ik programmeer altijd netjes, al was het
maar om ervoor te zorgen dat ik het later zelf nog begrijp.

Wat ik meer bedoel: er zijn vele manier om iets op te schrijven. Een
tijd terug moest ik Pascal source omzetten in Perl (jawel), en er was
een vrij lange procedure. Na even kijken ontdekte ik dat het een sorteer
routine was, waarbij achteraf nog even de elementen in omgekeerde
volgorde gezet werden... Die lange lap Pascal werd dus uiteindelijk een
paar regels Perl. Het was allemaal leesbare code op statement-nivo, maar
het kostte even om te zien wat alles precies deed. Dingen als de
volgorde omkeren achteraf (wat je natuurlijk prima tijdens het sorteren
kan doen zonder extra kosten), geven dan toch het gevoel dat er meer
gebeurd terwijl dat niet zo is.

In mijn ervaring is een ervaren programmeur beter in een algoritme
compact opschrijven, en toch leesbaar houden. En natuurlijk weet zo'n
programmeur wanneer iets gewoon in een bibliotheek beschikbaar is, en
gebruikt die.

Post by Jawade
Ja, ik ook, bij ECD in Delft. Er stond speciaal een computer voor. :-)
Maar ja, een doos floppies was best een hele investering.

:-). Ik deed daar van de winter 1990 tot zomer 1990 stage. Mocht je in
die tijd je Archimedes daar eens langsgebracht hebben (voor update,
reparatie (zeldzaam)) kan het heel goed dat ik dat gedaan heb :-) (of
Atari, als je die had :-D). Was een erg leuke tijd.

Post by John Bokma
Yup, ik twijfel er niet echt aan dat mijn oude Archie het ook nog doet
(staat in Nederland) ondanks de vele hardware hacks :-D. Maar eh, draai
jij geen Archimedes emulator op je PC? Heb ik heel kort gedaan, en het
werkt erg goed.

Yup, en Eizo nog meer. Maar goed, dijk van een computer. Ik heb toen een
hele tijd gezegd: wil je een erg goede computer dan ben je zo rond de
5000 gulden kwijt, misschien gaat dat nog wel op.

Over degelijk spul gesproken, ik heb in NL nog wat SGI hardware
staan. Ondertussen heb ik wel zo iets, wat moet ik daar mee als ik het
ooit over laat komen, want voor een Indy moest ik al ooit een
geheugenupgrade kopen om Netscape er wat langer op te kunnen laten
werken (dat kreng lekte geheugen bij het leven). Aan de andere kant kan
er zo Apache op en veel programmeerwerk wat ik nu doe zou er nog prima
op gedaan kunnen worden. Plus dat die machines er mooi uit zien
:-). Helaas nog geen emulator voor vzviw. (Er is wel een MIPS emulator,
maar de rest van de hardware...)

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Jawade

2010-01-09 22:44:48 UTC

Post by Jawade
Ik snap jou wel, maar het werkt best hoor, er zijn legio voorbeelden
op internet.

Als het grotere voorbeelden zijn, misschien wel, maar ik zoek dan b.v.
naar de juiste manier om een bestand te openen en uit te lezen. Verder
kan ik het zelf wel tot nu toe.

Oh, gegarandeerd leesbaar. Ik programmeer altijd netjes, al was het
maar om ervoor te zorgen dat ik het later zelf nog begrijp.

Wat ik meer bedoel: er zijn vele manier om iets op te schrijven. Een
tijd terug moest ik Pascal source omzetten in Perl (jawel), en er was
een vrij lange procedure. Na even kijken ontdekte ik dat het een sorteer
routine was, waarbij achteraf nog even de elementen in omgekeerde
volgorde gezet werden... Die lange lap Pascal werd dus uiteindelijk een
paar regels Perl. Het was allemaal leesbare code op statement-nivo, maar
het kostte even om te zien wat alles precies deed. Dingen als de
volgorde omkeren achteraf (wat je natuurlijk prima tijdens het sorteren
kan doen zonder extra kosten), geven dan toch het gevoel dat er meer
gebeurd terwijl dat niet zo is.
In mijn ervaring is een ervaren programmeur beter in een algoritme
compact opschrijven, en toch leesbaar houden. En natuurlijk weet zo'n
programmeur wanneer iets gewoon in een bibliotheek beschikbaar is, en
gebruikt die.

Ik kom in mijn eigen code ook weleens stukken tegen die sneller kunnen.
Was dan gewoon een soort blindheid tijdens het ontwikkelen zelf.
Ongetwijfeld komt dat vaker voor, maar dat vind ik niet zo'n ramp.
Iedereen heeft toch z'n eigen stijl. Zo gebruik ik zelden locale
variabelen, zodat ik ze overal beschikbaar heb. En ik zal weer meer
moeite met een source van jou hebben, en andersom.

Post by Jawade
Ja, ik ook, bij ECD in Delft. Er stond speciaal een computer voor. :-)
Maar ja, een doos floppies was best een hele investering.

Ik weet wel dat die chef ook een fervent hobbyist was. Nee, ik heb
de uitbreiding er eerder in laten zetten. Later gingen ze naar Rijswijk,
ben er nog 1 x geweest, volgens mij zaten ze in Delft beter. Atari had
ik niet, weinig ervaring mee, maar die hadden ook al vroeg een grafisch
OS, dat weet ik wel.

Yup, en Eizo nog meer. Maar goed, dijk van een computer. Ik heb toen een
hele tijd gezegd: wil je een erg goede computer dan ben je zo rond de
5000 gulden kwijt, misschien gaat dat nog wel op.

Lijkt mij niet, ik heb nu een 'state of the art' voor 2500 euro,
en ik reken het niet meer domweg om, dat is niet correct.

Post by John Bokma
Over degelijk spul gesproken, ik heb in NL nog wat SGI hardware
staan. Ondertussen heb ik wel zo iets, wat moet ik daar mee als ik het
ooit over laat komen, want voor een Indy moest ik al ooit een
geheugenupgrade kopen om Netscape er wat langer op te kunnen laten
werken (dat kreng lekte geheugen bij het leven). Aan de andere kant kan
er zo Apache op en veel programmeerwerk wat ik nu doe zou er nog prima
op gedaan kunnen worden. Plus dat die machines er mooi uit zien
:-). Helaas nog geen emulator voor vzviw. (Er is wel een MIPS emulator,
maar de rest van de hardware...)

Ja, dat is wel jammer. Je ziet ook een nadeel van degelijk spul: het
blijft goed ook al is het uit de tijd. Ook als ontwikkelingen snel
gaan valt er wat voor te zeggen om budget-spul te kopen, ik doe
gemiddeld 5 jaar met een pc, en dat is 'ie ondanks de hoge dimensionering
toch wel verouderd. Ik had in 2008 8GB RAM, en ik denk dat dat volgend
jaar al gemeengoed is. Het gaat nog steeds snel.

John Bokma

2010-01-09 23:27:48 UTC

Post by Jawade
Ik snap jou wel, maar het werkt best hoor, er zijn legio voorbeelden
op internet.

Als het grotere voorbeelden zijn, misschien wel, maar ik zoek dan b.v.
naar de juiste manier om een bestand te openen en uit te lezen. Verder
kan ik het zelf wel tot nu toe.

Zeker met Perl zal je dan 9 van de 10 keer code tegenkomen die niet
het beste is. (bareword FILE, geen 'die', of in 'die' argument niet de
waarde van $! opnemen). En ik ben bang dat Perl daar niet uniek in is.
Google gebruiken om code-snippets te vinden werkt, mijn ervaring, alleen
als je echt snapt wat het doet. En als je dat moet doen voor eenvoudige
dingen als een bestand openen...

Post by John Bokma
en programmeur beter in een algoritme
compact opschrijven, en toch leesbaar houden. En natuurlijk weet zo'n
programmeur wanneer iets gewoon in een bibliotheek beschikbaar is, en
gebruikt die.

Ik kom in mijn eigen code ook weleens stukken tegen die sneller kunnen.

Yup, wie niet. Niet altijd is dat belangrijk. Maar in dit voorbeeld ging
het om een knullig uitgeschreven sorteerroutine van 80+ regels die
vervangen kon worden door een paar regels.

Post by Jawade
Iedereen heeft toch z'n eigen stijl. Zo gebruik ik zelden locale
variabelen, zodat ik ze overal beschikbaar heb.

Huh, je gebruikt dus meestal globale variabelen? Yikes.

Post by Jawade
En ik zal weer meer moeite met een source van jou hebben, en andersom.

Dat eerste hoop ik niet, dat andere zal dan vast wel.

[ECD]

Post by Jawade
Ik weet wel dat die chef ook een fervent hobbyist was.

Als in fervent Acorn gebruiker, ja dat zeker. Hij stond in mijn ervaring
altijd 100% achter Acorn en deed vreselijk zijn best om bezoekers te
laten zien waarom RISC OS en programmas als ArtWorks gewoon in hun tijd
erg vooruit waren.

Post by John Bokma
Yup, en Eizo nog meer. Maar goed, dijk van een computer. Ik heb toen een
hele tijd gezegd: wil je een erg goede computer dan ben je zo rond de
5000 gulden kwijt, misschien gaat dat nog wel op.

Lijkt mij niet, ik heb nu een 'state of the art' voor 2500 euro,
en ik reken het niet meer domweg om, dat is niet correct.

Ik denk dat 2500 euro van nu meer in de richting van de 7K gulden gaat.

Post by Jawade
Ja, dat is wel jammer. Je ziet ook een nadeel van degelijk spul: het
blijft goed ook al is het uit de tijd. Ook als ontwikkelingen snel
gaan valt er wat voor te zeggen om budget-spul te kopen, ik doe
gemiddeld 5 jaar met een pc, en dat is 'ie ondanks de hoge dimensionering
toch wel verouderd. Ik had in 2008 8GB RAM, en ik denk dat dat volgend
jaar al gemeengoed is. Het gaat nog steeds snel.

Ja, ik koop sinds een jaar of 15 toch liever de middenmoot en schrijf
die af over 3 jaar. Meestal werkt die machine dan zeker nog 2 jaar extra
(5 in totaal) als extra/voor nood. Ik zit hier nog met 2G RAM, en merk
dat alleen als ik VirtualBox gebruik en Firefox en Thunderbird alle drie
heb draaien. Ik upgrade zelden een computer, ik ben van mening dat het
beter is om dat geld in een nieuwe computer te stoppen. (Zeker als een
nieuwe grafische kaart tot gevolg heeft dat er een nieuwe voeding moet
komen, enz.).

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Jawade

2010-01-11 20:43:43 UTC

Post by John Bokma
Ja, precies, die bedoel ik. Als je wat dieper in een taal ziet, zie je
toch (ik dan wel) dat veel van die voorbeelden rammelen, en wel aan alle
kanten. Tenminste ik zie dat met Perl en PHP. Ik moet mijn voorbeelden
op mijn site ook nodig eens op de schop nemen ;-)

Als het grotere voorbeelden zijn, misschien wel, maar ik zoek dan b.v.
naar de juiste manier om een bestand te openen en uit te lezen. Verder
kan ik het zelf wel tot nu toe.

Tja, zulk soort syntaxis ken ik gewoon niet uit m'n hoofd, vandaar.
Maar ik weet wel wat ik wil en dat lukt dan ook wel.
Maar hier kan toch weinig fout mee gaan:

...

if($comm eq "deles"){
open(INPUT,"<deles.dat");
while (<INPUT>) {
chomp();
$pop->print("dele ",$_);
$line = $pop->getline;
}
close(INPUT);
print $line;
$pop->print("quit");
$line = $pop->getline;
print $line;
}

...

Ik kom in mijn eigen code ook weleens stukken tegen die sneller kunnen.

Yup, wie niet. Niet altijd is dat belangrijk. Maar in dit voorbeeld ging
het om een knullig uitgeschreven sorteerroutine van 80+ regels die
vervangen kon worden door een paar regels.

Ja, dan scheelt het wel veel, ws ook in snelheid.

Post by Jawade
Iedereen heeft toch z'n eigen stijl. Zo gebruik ik zelden locale
variabelen, zodat ik ze overal beschikbaar heb.

Huh, je gebruikt dus meestal globale variabelen? Yikes.

Alleen echt aparte routines krijgen eigen variabelen, maar ik
ben het zo gewend zodat ik variabelen ook elders kan gebruiken.
Geen nadeel hoor, en het is ook nog eens makkelijk zoeken.

Post by Jawade
En ik zal weer meer moeite met een source van jou hebben, en andersom.

Dat eerste hoop ik niet, dat andere zal dan vast wel.

Ik ben hobbyist en wissel zelden sources uit. Ik weet wel dat ik
een eigen stijl heb, maar die is voor mij volstrekt duidelijk.
En dat is het voornaamste. uitbreidingen of aanpassingen zijn geen
probleem. En strict zijn met versienummers natuurlijk.

Post by John Bokma
[ECD]

Post by Jawade
Ik weet wel dat die chef ook een fervent hobbyist was.

En terecht. Windows was nog niks toen.

Lijkt mij niet, ik heb nu een 'state of the art' voor 2500 euro,
en ik reken het niet meer domweg om, dat is niet correct.

Ik denk dat 2500 euro van nu meer in de richting van de 7K gulden gaat.

Nee joh, eerder iets van 3000 gulden, we hebben sinds de euro een
flinke (onder tafel geschoven) inflatie gehad. Globaal koop je nu
voor een euro hetzelfde als toen voor een gulden.

Ja, ben ik wel met je eens, ik rust een nieuwe PC uit met 2 schijven
en een flink geheugen, verder doe ik er weinig meer aan. Waarschijnlijk
wordt mijn volgende PC een Aldi-aanbieding o.i.d. Mijn W95-PC werkt ook
nog prima, en de XP uit 2002 uiteraard ook. Ik gebruik ze niet vaak,
maar het is weleens makkelijk.

John Bokma

2010-01-11 21:58:43 UTC

[ Perl ]

Post by Jawade
...
if($comm eq "deles"){
open(INPUT,"<deles.dat");

En wat als dit bestand er niet is?

my $filename = 'deles.dat';
open my $fh, '<', $filename
or die "Can't open '$filename' for reading: $!";

(gebruik zeker geen bareword filehandles tenzij je een hele oude Perl
versie gebruikt)

Post by Jawade
while (<INPUT>) {

wordt dan: while ( <$fh> ) {

Post by Jawade
chomp();
$pop->print("dele ",$_);
$line = $pop->getline;
}
close(INPUT);

Ikzelf controleer die ook altijd:

close $fh or die "Can't close '$filename' after reading: $!";

Je zou zelfs $! van readline (<>) kunnen controleren, als je echt alles
op safe wilt spelen. Of beter: gebruik de autodie module.

Post by John Bokma
Huh, je gebruikt dus meestal globale variabelen? Yikes.

Alleen echt aparte routines krijgen eigen variabelen, maar ik
ben het zo gewend zodat ik variabelen ook elders kan gebruiken.
Geen nadeel hoor, en het is ook nog eens makkelijk zoeken.

In Perl zou ik je dan sterk aanraden om eens te kijken naar hoe je een
class kan maken. Je kan dan je "globale variabelen" in instance
variabelen bijhouden, en jezelf een hoop problemen besparen.

Post by Jawade
En ik zal weer meer moeite met een source van jou hebben, en andersom.

Dat eerste hoop ik niet, dat andere zal dan vast wel.

Een van de belangrijkste dingen om te doen als programmeur is
bijleren. En daar hoort ook het bijschaven van een "eigen stijl"
bij. Iedereen heeft wel een eigen stijl, maar ik denk dat het erg goed
is als je opmerkt dat de stijl van de ervaren programmeurs in de taal
die je gebruikt erg op die van jezelf lijkt.

[Hardware]

Post by Jawade
Ja, ben ik wel met je eens, ik rust een nieuwe PC uit met 2 schijven
en een flink geheugen, verder doe ik er weinig meer aan. Waarschijnlijk
wordt mijn volgende PC een Aldi-aanbieding o.i.d. Mijn W95-PC werkt ook
nog prima, en de XP uit 2002 uiteraard ook. Ik gebruik ze niet vaak,
maar het is weleens makkelijk.

Ikzelf heb het niet zo met supermarktcomputers (bij de laatste viel de
heatsink van de Northbridge (of Southbridge) er zomaar af omdat Asus
knoeiwerk had afgeleverd voor een Compaq PC). Ik koop nu Dell omdat dat
het enige is wat hier (Mexico) fatsoenlijk te koop is (goede prijs,
goede service tot nu toe).

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Jawade

2010-01-14 20:18:34 UTC

Post by John Bokma
[ Perl ]

Post by Jawade
...
if($comm eq "deles"){
open(INPUT,"<deles.dat");

En wat als dit bestand er niet is?

Het bestand is er altijd.

Post by John Bokma
my $filename = 'deles.dat';
open my $fh, '<', $filename
or die "Can't open '$filename' for reading: $!";
(gebruik zeker geen bareword filehandles tenzij je een hele oude Perl
versie gebruikt)

5.10, is dat heel oud?

Post by Jawade
while (<INPUT>) {

wordt dan: while ( <$fh> ) {

Post by Jawade
chomp();
$pop->print("dele ",$_);
$line = $pop->getline;
}
close(INPUT);

close $fh or die "Can't close '$filename' after reading: $!";
Je zou zelfs $! van readline (<>) kunnen controleren, als je echt alles
op safe wilt spelen. Of beter: gebruik de autodie module.

Het is een vaststaand proces, ik denk dat er weinig mee fout kan.
Ik ga e.e.a. aanpassen.

Post by John Bokma
Huh, je gebruikt dus meestal globale variabelen? Yikes.

Alleen echt aparte routines krijgen eigen variabelen, maar ik
ben het zo gewend zodat ik variabelen ook elders kan gebruiken.
Geen nadeel hoor, en het is ook nog eens makkelijk zoeken.

In Perl zou ik je dan sterk aanraden om eens te kijken naar hoe je een
class kan maken. Je kan dan je "globale variabelen" in instance
variabelen bijhouden, en jezelf een hoop problemen besparen.

Tot nu toe gebruik ik kleine scriptjes, misschien is het dan
een beetje overkill?

Post by Jawade
En ik zal weer meer moeite met een source van jou hebben, en andersom.

Dat eerste hoop ik niet, dat andere zal dan vast wel.

Ja, klopt, ik schaaf nog steeds hoor. Zo moest ik 'vroeger' een
programma vaak herschrijven omdat het aanpassen/uitbreiden te
ingewikkeld werd. Voordelen heeft herschrijven wel, het wordt
vaak een beter product.

Post by John Bokma
[Hardware]

Ik zag een mooie bij de Aldi, daarom noemde ik die. Maar Dell is zeker
een goede prijs/kwaliteit, die adviseer ik zelf ook wel.

John Bokma

2010-01-14 22:18:53 UTC

Post by John Bokma
[ Perl ]

Post by Jawade
...
if($comm eq "deles"){
open(INPUT,"<deles.dat");

En wat als dit bestand er niet is?

Het bestand is er altijd.

Heh... Toch raad ik je sterk aan om te controleren of die open lukt ja
of nee.

Post by John Bokma
(gebruik zeker geen bareword filehandles tenzij je een hele oude Perl
versie gebruikt)

5.10, is dat heel oud?

Nee, 5.00x wel. Met 5.10 kan je beter gebruiken wat ik liet zien dan
bareword filehandles. Zeker in subs om zut als:

sub read_deles {

my $filename = shift;
local( *FILE ); # <--- deze dus
open( FILE, '<', $filename ) or die ....

te voorkomen.

Post by Jawade
Het is een vaststaand proces, ik denk dat er weinig mee fout kan.
Ik ga e.e.a. aanpassen.

Ja, het is zeker aan te raden om elke functie die $! (of equivalent) kan
aanpassen te testen, en $! af te drukken zodat je precies kan zien wat
er mis ging. Die autodie module kan je veel werk besparen. Aan de
andere kant, als je het zelf afhandelt kan je vaak een duidelijke(re)
foutmelding geven.

Post by John Bokma
In Perl zou ik je dan sterk aanraden om eens te kijken naar hoe je een
class kan maken. Je kan dan je "globale variabelen" in instance
variabelen bijhouden, en jezelf een hoop problemen besparen.

Tot nu toe gebruik ik kleine scriptjes, misschien is het dan
een beetje overkill?

Als je globale variabelen nodig hebt om het aantal parameters per
functie te beperken denk ik niet. Wat ik doe met kleine programmas waar
ik niet wil dat ik of tig parameters de hele tijd heen en weer moet
sluizen, of globale variabelen gebruiken:

package POPCleaner;

use strict;
use warnings;
use Net::POP3;

sub new {

my $class = shift;
my $self = {
username => 'jawade',
password => 'geheim', # hoe weet ik dat!
host => 'pop.example.com',
pop => undef,
}
bless $class, $self;
return $self;
}

sub connect {
my $self = shift;
my $pop = Net::POP3->new( $self->{ host } );
$pop->login( $self->{ username }, $self->{ password } );
return;
}

sub delete_spam {
my $self = shift;
print "Cleaning up $self->{ username } on $self->{ host }\n";
...
return;
}

sub disconnect {
...
$self->{ pop }->quit();
return;
}

package main;

my $cleaner = POPCleaner->new();
$cleaner->connect();
$cleaner->delete_spam();
$cleaner->disconnect();

NB: dit is een vlug in elkaar geklopt voorbeeld om te laten zien hoe je
via member variabelen (instance variabelen) globale variabelen en/of
lange parameterlijsten in functies kan voorkomen. Zie het zeker niet als
een (goed) voorbeeld om een POP spam cleaner te schrijven ;-).

De "globale" variabelen gaan nu via de member variabelen. Een bijkomend
voordeel is dat als die class POPCleaner erg handig is, je die af kunt
splitsen, in een eigen bestand kan zetten, en hop, je hebt een
POPCleaner module (wel ff 1; aan het einde van dat bestand zetten).

De "overkill" is wat extra regels, en dat je $self->{ naam } moet tikken
ipv. $naam. (En het risico dat je $self->{ naan } kan tikken, b.v.)

Verder, als je echt met OO aan de slag wilt, is het wellicht beter om
iets als Moose te gaan bekijken. Een site om te volgen is dan:
http://www.modernperlbooks.com/mt/

Post by John Bokma
Een van de belangrijkste dingen om te doen als programmeur is
bijleren. En daar hoort ook het bijschaven van een "eigen stijl"
bij. Iedereen heeft wel een eigen stijl, maar ik denk dat het erg goed
is als je opmerkt dat de stijl van de ervaren programmeurs in de taal
die je gebruikt erg op die van jezelf lijkt.

Yup, en hoe langer je programmeerd hoe handiger je word in anticiperen,
en dingen niet te ruim te willen doen (zo van: laten we eventjes 400
classes ontwerpen), en niet te nauw. Die balans vinden is op den duur
een echte uitdaging, zeker als je fixed price werkt.

Qua Perl kan ik je Perl Best Practices aanraden. Zoek ook middels Google
op kritieken op dit boek (het is hier en daar een beetje verouderd, en
natuurlijk zijn er mensen die met bepaalde dingen niet eens
zijn). Ikzelf volg deels PBP, en werk aan om het meer te volgen (muv de
verouderde delen).

--
John Bokma j3b

Hacking & Hiking in Mexico - - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

Jawade

2010-01-16 07:18:51 UTC

Post by Jawade
Het bestand is er altijd.

Heh... Toch raad ik je sterk aan om te controleren of die open lukt ja
of nee.

Okee, doe ik. Maar hij is er altijd, dat is een voorwaarde voor het
aanroepen.

Post by Jawade
5.10, is dat heel oud?

Nee, 5.00x wel. Met 5.10 kan je beter gebruiken wat ik liet zien dan
sub read_deles {
my $filename = shift;
local( *FILE ); # <--- deze dus
open( FILE, '<', $filename ) or die ....
te voorkomen.

Post by Jawade
Het is een vaststaand proces, ik denk dat er weinig mee fout kan.
Ik ga e.e.a. aanpassen.

Ja, oke. Maar mijn scriptjes zijn vrij rechtlijnig, ik heb nog geen
problemen met foutzoeken gehad.

Post by Jawade
Tot nu toe gebruik ik kleine scriptjes, misschien is het dan
een beetje overkill?

Als je globale variabelen nodig hebt om het aantal parameters per
functie te beperken denk ik niet. Wat ik doe met kleine programmas waar
ik niet wil dat ik of tig parameters de hele tijd heen en weer moet
package POPCleaner;
use strict;
use warnings;
use Net::POP3;
sub new {
my $class = shift;
my $self = {
username => 'jawade',
password => 'geheim', # hoe weet ik dat!
host => 'pop.example.com',
pop => undef,
}
bless $class, $self;
return $self;
}
sub connect {
my $self = shift;
my $pop = Net::POP3->new( $self->{ host } );
$pop->login( $self->{ username }, $self->{ password } );
return;
}
sub delete_spam {
my $self = shift;
print "Cleaning up $self->{ username } on $self->{ host }\n";
...
return;
}
sub disconnect {
...
$self->{ pop }->quit();
return;
}
package main;
my $cleaner = POPCleaner->new();
$cleaner->connect();
$cleaner->delete_spam();
$cleaner->disconnect();
NB: dit is een vlug in elkaar geklopt voorbeeld om te laten zien hoe je
via member variabelen (instance variabelen) globale variabelen en/of
lange parameterlijsten in functies kan voorkomen. Zie het zeker niet als
een (goed) voorbeeld om een POP spam cleaner te schrijven ;-).
De "globale" variabelen gaan nu via de member variabelen. Een bijkomend
voordeel is dat als die class POPCleaner erg handig is, je die af kunt
splitsen, in een eigen bestand kan zetten, en hop, je hebt een
POPCleaner module (wel ff 1; aan het einde van dat bestand zetten).
De "overkill" is wat extra regels, en dat je $self->{ naam } moet tikken
ipv. $naam. (En het risico dat je $self->{ naan } kan tikken, b.v.)
Verder, als je echt met OO aan de slag wilt, is het wellicht beter om
http://www.modernperlbooks.com/mt/

Bedankt voor het voorbeeld, geeft weer een nieuw perspectief.
Ik zal het in elk geval even opslaan. Ik ben echter niet van
plan om echt veel in Perl te gaan doen, maar soms 'moet' je wel
omdat het een krachtige taal is. Je kunt dan met enkele regels
bereiken waar je in een andere taal een heel programma voor
zou moeten schrijven.

Post by Jawade
Ja, klopt, ik schaaf nog steeds hoor. Zo moest ik 'vroeger' een
programma vaak herschrijven omdat het aanpassen/uitbreiden te
ingewikkeld werd. Voordelen heeft herschrijven wel, het wordt
vaak een beter product.

Yup, en hoe langer je programmeerd hoe handiger je word in anticiperen,
en dingen niet te ruim te willen doen (zo van: laten we eventjes 400
classes ontwerpen), en niet te nauw. Die balans vinden is op den duur
een echte uitdaging, zeker als je fixed price werkt.
Qua Perl kan ik je Perl Best Practices aanraden. Zoek ook middels Google
op kritieken op dit boek (het is hier en daar een beetje verouderd, en
natuurlijk zijn er mensen die met bepaalde dingen niet eens
zijn). Ikzelf volg deels PBP, en werk aan om het meer te volgen (muv de
verouderde delen).

Ik bewaar deze posting, kan ik altijd even terugkijken. Voordeel van
Perl is dat er veel gerichte voorbeelden op het web te vinden zijn,
dat heeft mij tot nu toe altijd de oplossing gebracht. Ik zie me nog
niet zou gauw dat boek kopen, maar wie weet.

John Bokma

2010-01-16 17:36:41 UTC

Post by Jawade
Het bestand is er altijd.

Heh... Toch raad ik je sterk aan om te controleren of die open lukt ja
of nee.

Okee, doe ik. Maar hij is er altijd, dat is een voorwaarde voor het
aanroepen.

Die controle is er om een duidelijke melding te geven als het bestand er
wel is, maar de permissies staan niet goed (kan gebeuren), of als het
per ongeluk toch een keer gewist wordt. In zo'n geval wil je, zelfs als
ontwikkelaar (ik wel tenminste) direct zien /wat/ er mis ging in plaats
van alles na lopen tot je er achter komt dat een bestand ontbreekt.

Post by John Bokma
Ja, het is zeker aan te raden om elke functie die $! (of equivalent) kan
aanpassen te testen, en $! af te drukken zodat je precies kan zien wat
er mis ging. Die autodie module kan je veel werk besparen. Aan de
andere kant, als je het zelf afhandelt kan je vaak een duidelijke(re)
foutmelding geven.

Ja, oke. Maar mijn scriptjes zijn vrij rechtlijnig, ik heb nog geen
problemen met foutzoeken gehad.

Maar als je programma uit gaat dat alles er is en altijd werkt, kan het
een klus zijn om uit te zoeken waar dat precies is. Zolang alles werkt,
geen probleem, maar als er dan wat mis gaat kan je veel tijd moeten
steken in het vinden van de fout.

Post by John Bokma
Verder, als je echt met OO aan de slag wilt, is het wellicht beter om
http://www.modernperlbooks.com/mt/

Ik gebruikte Perl ook oorspronkelijk om die laatste reden: om snel een
tooltje in elkaar te zetten. Ik gebruikte toen C, C++ (weinig), en BBC
Basic V. En Perl won het van die 3 qua snel iets in elkaar draaien. Iets
later kwam Perl ook in opmars op Internet, dus ging ik er meer en meer
tijd in steken, en het is nu mijn specialisme zeg maar.

Post by Jawade
Ik bewaar deze posting, kan ik altijd even terugkijken. Voordeel van
Perl is dat er veel gerichte voorbeelden op het web te vinden zijn,
dat heeft mij tot nu toe altijd de oplossing gebracht. Ik zie me nog
niet zou gauw dat boek kopen, maar wie weet.

Zodra je een boek of twee over Perl doorgelezen hebt kom je wellicht tot
de ontdekking dat heel veel Perl voorbeelden op het Internet aan alle
kanten rammelen: ze gaan uit van Perl van 10(+) jaar terug, ze gaan uit
van eigen gecodeerde libraries terwijl er veel betere beschikbaar zijn,
of geschreven door mensen die Perl er (heel erg) naast doen.

Naast het voorgenoemde Perl Best Practices kan ik je zeker Intermediate
Perl aanraden. Op het Internet/Usenet: de voorgenoemde modern Perl site,
http://www.perlmonks.org/ en comp.lang.perl.misc hoewel die laatste
nogal last heeft van onvriendelijke nerds (been there, done that). Maar
als je nieuwslezer mensen kan scoren, dan kan je er veel van opsteken.

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

Jawade

2010-01-22 18:45:59 UTC

Post by Jawade
Het bestand is er altijd.

Heh... Toch raad ik je sterk aan om te controleren of die open lukt ja
of nee.

Okee, doe ik. Maar hij is er altijd, dat is een voorwaarde voor het
aanroepen.

Ja, oke. Maar mijn scriptjes zijn vrij rechtlijnig, ik heb nog geen
problemen met foutzoeken gehad.

Over het algemeen natuurlijk wel, maar in dit geval niet.
En Perl geeft een fout- en regelnummer. Fouten die lastig zijn,
dat zijn de gecompliceerde met allerlei invloeden, waarbij ook
het foutpunt niet de plaats van de fout is. Haar hier allemaal niet
van toepassing.

Post by John Bokma
Verder, als je echt met OO aan de slag wilt, is het wellicht beter om
http://www.modernperlbooks.com/mt/

Ja, zo heb ik Perl ontdekt. Voor die netwerktoepassing. Is eindeloos
te controleren. Dat red je in FreeBASIC niet. 't Is alleen wel eens
jammer dat er geen compacte executable van te maken is.

Het gaat mij vnl om de syntax, en ik ga ook niet op 1 voorbeeld af.

Post by John Bokma
Naast het voorgenoemde Perl Best Practices kan ik je zeker Intermediate
Perl aanraden. Op het Internet/Usenet: de voorgenoemde modern Perl site,
http://www.perlmonks.org/ en comp.lang.perl.misc hoewel die laatste
nogal last heeft van onvriendelijke nerds (been there, done that). Maar
als je nieuwslezer mensen kan scoren, dan kan je er veel van opsteken.

Natuurlijk :-) Maar het is voor mij slechts een 'bij'taal, ondanks
dat ik het wel erg ben gaan waarderen.

John Bokma

2010-01-22 19:29:27 UTC

Post by John Bokma
Maar als je programma uit gaat dat alles er is en altijd werkt, kan het
een klus zijn om uit te zoeken waar dat precies is. Zolang alles werkt,
geen probleem, maar als er dan wat mis gaat kan je veel tijd moeten
steken in het vinden van de fout.

Over het algemeen natuurlijk wel, maar in dit geval niet.
En Perl geeft een fout- en regelnummer.

Niet als je dingen doet als:

open(FILE, "<bestandje");

Dat loopt gewoon rustig door. En als je bestandje er wel is, maar
bijvoorbeeld niet de juiste permissies heeft, dan ben je zo een half uur
zoet met print statements hier en daar neerzetten om te ontdekken wat er
mis ging...

[ .. ]

Post by Jawade
Ja, zo heb ik Perl ontdekt. Voor die netwerktoepassing. Is eindeloos
te controleren. Dat red je in FreeBASIC niet. 't Is alleen wel eens
jammer dat er geen compacte executable van te maken is.

Yup, je zit vlug aan 1MB+

Post by John Bokma
Zodra je een boek of twee over Perl doorgelezen hebt kom je wellicht tot
de ontdekking dat heel veel Perl voorbeelden op het Internet aan alle
kanten rammelen: ze gaan uit van Perl van 10(+) jaar terug, ze gaan uit
van eigen gecodeerde libraries terwijl er veel betere beschikbaar zijn,
of geschreven door mensen die Perl er (heel erg) naast doen.

Het gaat mij vnl om de syntax,

Die vind je terug met perldoc -f <naam functie>, bijvoorbeeld als jij
niet meer weet hoe open werkt (op de command line):

perldoc -f open

en hop. Ik zou dat *zeker* niet op Internet zoeken, met uitzondering van
de online documentatie. Daarnaast heb in Firefox een keymark [1] met de
volgende URL: http://search.cpan.org/perldoc?%s ik kan dan in de locatie
bar (Crtl+L) perldoc DBI intikken, en heb dan de documentatie van de DBI
module op CPAN. Je kan dat ook met perldoc op de command line doen,
uiteraard:

perldoc DBI

zie verder:

perldoc perldoc

Wat veel belangrijker is, is om de idiomen van de taal (in dit geval
Perl) te leren. De voorgenoemde boeken en Usenet groep helpen daar
bij. Een willekeurige Internet site zeker niet (tenzij je toevallig op
perlmonks o.i.d. terecht komt)

[1] http://johnbokma.com/firefox/keymarks-explained.html

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

Jawade

2010-01-25 20:36:33 UTC

Post by John Bokma
open(FILE, "<bestandje");
Dat loopt gewoon rustig door. En als je bestandje er wel is, maar
bijvoorbeeld niet de juiste permissies heeft, dan ben je zo een half uur
zoet met print statements hier en daar neerzetten om te ontdekken wat er
mis ging...

De Perl-module wordt aangeroepen nadat het bestandje is gemaakt.
Maar oke, het is misschien beter een extra controle te doen.

Post by John Bokma
[ .. ]

Yup, je zit vlug aan 1MB+

Ik kwam erachter dat een oudere Perl2exe veel kleinere .exe 's maakt.

Post by Jawade
Het gaat mij vnl om de syntax,

Die vind je terug met perldoc -f <naam functie>, bijvoorbeeld als jij
perldoc -f open
en hop. Ik zou dat *zeker* niet op Internet zoeken, met uitzondering van
de online documentatie. Daarnaast heb in Firefox een keymark [1] met de
volgende URL: http://search.cpan.org/perldoc?%s ik kan dan in de locatie
bar (Crtl+L) perldoc DBI intikken, en heb dan de documentatie van de DBI
module op CPAN. Je kan dat ook met perldoc op de command line doen,
perldoc DBI
perldoc perldoc
Wat veel belangrijker is, is om de idiomen van de taal (in dit geval
Perl) te leren. De voorgenoemde boeken en Usenet groep helpen daar
bij. Een willekeurige Internet site zeker niet (tenzij je toevallig op
perlmonks o.i.d. terecht komt)
[1] http://johnbokma.com/firefox/keymarks-explained.html

Tja, daar gebruik ik het toch te weinig voor. Perldoc kende ik ook,
maar die geeft niet precies aan hoe het toe te passen. Daarvoor zoek
ik dus op internet naar voorbeelden. Ik heb ook nog mijn C++ bagage,
dus fouten zijn snel gemaakt.

John Bokma

2010-01-25 21:40:42 UTC

[PAR]

Post by John Bokma
Yup, je zit vlug aan 1MB+

Ik kwam erachter dat een oudere Perl2exe veel kleinere .exe 's maakt.

Ik ken perl2exe verder niet, de keren dat ik zoiets nodig had voldeed
PAR prima. Maar ik dacht dat beide programma's min of meer hetzelfde
deden.

[perldoc]

Post by Jawade
Tja, daar gebruik ik het toch te weinig voor. Perldoc kende ik ook,
maar die geeft niet precies aan hoe het toe te passen.

Mijn ervaring is juist dat perldoc -f /functie/ juist voorbeelden heeft
voor /functie/. Daarnaast is er ook documentatie, beschikbaar via
perldoc, over specifieke onderwerpen.

Als je ActivePerl gebruikt kan je die ook als HTML lezen in je
browser. Bij programmeren is het belangrijk om de documentatie van het
product zelf als 1e lijn te gebruiken. Internet zie ik zelf meer als een
laatste redmiddel [1], en waar je alleen maar wat mee kan als je de taal
aardig beheerst.

[1] m.u.v. de sites die de productdocumentatie hosten en sites van
ervaren programmeurs.

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

Martijn van Buul

2010-01-15 11:36:45 UTC

Post by Jawade
if($comm eq "deles"){
open(INPUT,"<deles.dat");

En wat als dit bestand er niet is?

Het bestand is er altijd.

En daar komen dus de vele securityleaks vandaan - door dit soort 'maar dat
gaat vast nooit verkeerd' aannames.

[misbruik van globale variablen]

Post by Jawade
Tot nu toe gebruik ik kleine scriptjes, misschien is het dan
een beetje overkill?

Nee, het is geen overkill. Wat je nu doet is spelen met vuur - en dat
gaat gegarandeerd eens goed mis.

Overigens gaat het niet automagisch goed op het moment dat je variablen in
classes gaat stoppen - dat kan namelijk nog steeds verkeerd gaan. Locale
variablen, member variablen, static class member variablen en globale
variablen zijn nou eenmaal fundamenteel verschillend - welke taal je
ook gebruikt.

--
Martijn van Buul - ***@dohd.org

Jawade

2010-01-16 07:35:23 UTC

Post by Jawade
if($comm eq "deles"){
open(INPUT,"<deles.dat");

En wat als dit bestand er niet is?

Het bestand is er altijd.

En daar komen dus de vele securityleaks vandaan - door dit soort 'maar dat
gaat vast nooit verkeerd' aannames.

Het is geen aanname, de script wordt pas aangeroepen als het bestand
er is.

Post by Martijn van Buul
[misbruik van globale variablen]

Post by Jawade
Tot nu toe gebruik ik kleine scriptjes, misschien is het dan
een beetje overkill?

Nee, het is geen overkill. Wat je nu doet is spelen met vuur - en dat
gaat gegarandeerd eens goed mis.

Het gaat al jaren goed.

Post by Martijn van Buul
Overigens gaat het niet automagisch goed op het moment dat je variablen in
classes gaat stoppen - dat kan namelijk nog steeds verkeerd gaan. Locale
variablen, member variablen, static class member variablen en globale
variablen zijn nou eenmaal fundamenteel verschillend - welke taal je
ook gebruikt.

Ik gebruik ze allemaal, daar waar het het meest practisch is.

richard lucassen

2010-01-16 11:13:02 UTC

On Sat, 16 Jan 2010 08:35:23 +0100

Post by Martijn van Buul
Nee, het is geen overkill. Wat je nu doet is spelen met vuur - en
dat gaat gegarandeerd eens goed mis.

Het gaat al jaren goed.

De Ariane4 raket ging ook al jaren goed.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

Rob

2010-01-16 11:18:44 UTC

Post by richard lucassen
On Sat, 16 Jan 2010 08:35:23 +0100

Post by Martijn van Buul
Nee, het is geen overkill. Wat je nu doet is spelen met vuur - en
dat gaat gegarandeerd eens goed mis.

Het gaat al jaren goed.

De Ariane4 raket ging ook al jaren goed.

Maar dat het vervolgens met de Ariane5 niet goed ging dat kwam juist
doordat er overdreven veel controles gedaan werden en er gekozen was
voor een foutafhandeling vergelijkbaar met de hier gepropageerde "die"
in Perl.

Als dat stukje software slordig geprogrammeerd was (zonder fout afhandeling
en/of gewoon een meldinkje sturen en doorgaan) dan was er niks aan de
hand geweest.

richard lucassen

2010-01-16 11:45:56 UTC

On 16 Jan 2010 11:18:44 GMT

Post by Rob

Post by richard lucassen
De Ariane4 raket ging ook al jaren goed.

Maar dat het vervolgens met de Ariane5 niet goed ging dat kwam juist
doordat er overdreven veel controles gedaan werden en er gekozen was
voor een foutafhandeling vergelijkbaar met de hier gepropageerde "die"
in Perl.
Als dat stukje software slordig geprogrammeerd was (zonder fout
afhandeling en/of gewoon een meldinkje sturen en doorgaan) dan was er
niks aan de hand geweest.

Klusje voor Jawade :)
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

Jawade

2010-01-16 12:47:28 UTC

Post by richard lucassen
On 16 Jan 2010 11:18:44 GMT

Post by Rob

Post by richard lucassen
De Ariane4 raket ging ook al jaren goed.

Maar dat het vervolgens met de Ariane5 niet goed ging dat kwam juist
doordat er overdreven veel controles gedaan werden en er gekozen was
voor een foutafhandeling vergelijkbaar met de hier gepropageerde "die"
in Perl.
Als dat stukje software slordig geprogrammeerd was (zonder fout
afhandeling en/of gewoon een meldinkje sturen en doorgaan) dan was er
niks aan de hand geweest.

Klusje voor Jawade :)

Overdrijven is ook een kunst. Het gaat over een script van enige
tientallen regels, rechtlijnig en foutloos, wat al jaren in bedrijf
is. Het is niet eens mogelijk dat er omstandigheden zouden kunnen
ontstaan, waardoor het mis gaat, wat op zich al niet mogelijk is.

Maar ik weet de echte reden van het commentaar, en schud m'n hoofd
maar eens.

unknown

2010-01-16 12:58:18 UTC

Post by Jawade
Overdrijven is ook een kunst. Het gaat over een script van enige
tientallen regels, rechtlijnig en foutloos, wat al jaren in bedrijf
is. Het is niet eens mogelijk dat er omstandigheden zouden kunnen
ontstaan, waardoor het mis gaat, wat op zich al niet mogelijk is.

Schijf stuk? Filesysteem kapot?

--
robert

Jan Kuiken

2010-01-16 17:56:29 UTC

Schijf stuk? Filesysteem kapot?

Ik weet niet waar het script voor is, maar ik kan me voorstellen dat
een kapotte schijf een probleem is waarbij de correcte werking van
een script een ondergeschikt probleem is.

Jan Kuiken

unknown

2010-01-16 18:46:33 UTC

Post by Jawade
Overdrijven is ook een kunst. Het gaat over een script van enige
tientallen regels, rechtlijnig en foutloos, wat al jaren in bedrijf is.
Het is niet eens mogelijk dat er omstandigheden zouden kunnen ontstaan,
waardoor het mis gaat, wat op zich al niet mogelijk is.

Schijf stuk? Filesysteem kapot?

Ik weet niet waar het script voor is, maar ik kan me voorstellen dat een
kapotte schijf een probleem is waarbij de correcte werking van een script
een ondergeschikt probleem is.

Het ging mij even om de onmogelijke omstandigheden.

--
robert

Jan Kuiken

2010-01-16 19:28:53 UTC

Post by Jawade
Overdrijven is ook een kunst. Het gaat over een script van enige
tientallen regels, rechtlijnig en foutloos, wat al jaren in bedrijf is.
Het is niet eens mogelijk dat er omstandigheden zouden kunnen ontstaan,
waardoor het mis gaat, wat op zich al niet mogelijk is.

Schijf stuk? Filesysteem kapot?

Ik weet niet waar het script voor is, maar ik kan me voorstellen dat een
kapotte schijf een probleem is waarbij de correcte werking van een script
een ondergeschikt probleem is.

Het ging mij even om de onmogelijke omstandigheden.

check, het blijft een afweging, soms een lastige, in hoeverre je
rekening moet/wil houden met onvoorziene omstandigheden (gebruikers
die 'het niet snappen', andere processen die aan jouw files frutten,
hardware problemen, stroomuitval).

Jan Kuiken

Ximinez

2010-01-16 20:54:05 UTC

Post by Jan Kuiken

Post by Jawade
Overdrijven is ook een kunst. Het gaat over een script van enige
tientallen regels, rechtlijnig en foutloos, wat al jaren in bedrijf is.
Het is niet eens mogelijk dat er omstandigheden zouden kunnen ontstaan,
waardoor het mis gaat, wat op zich al niet mogelijk is.

Schijf stuk? Filesysteem kapot?

Ik weet niet waar het script voor is, maar ik kan me voorstellen dat een
kapotte schijf een probleem is waarbij de correcte werking van een script
een ondergeschikt probleem is.

Het ging mij even om de onmogelijke omstandigheden.

Volle schijf.

X.

Jawade

2010-01-22 18:56:50 UTC

Post by Jawade
Overdrijven is ook een kunst. Het gaat over een script van enige
tientallen regels, rechtlijnig en foutloos, wat al jaren in bedrijf is.
Het is niet eens mogelijk dat er omstandigheden zouden kunnen ontstaan,
waardoor het mis gaat, wat op zich al niet mogelijk is.

Schijf stuk? Filesysteem kapot?

Ik weet niet waar het script voor is, maar ik kan me voorstellen dat een
kapotte schijf een probleem is waarbij de correcte werking van een script
een ondergeschikt probleem is.

Het ging mij even om de onmogelijke omstandigheden.

Tja, daar is geen enkele taal tegen opgewassen.

Martijn Lievaart

2010-01-22 20:57:45 UTC

Post by unknown
Het ging mij even om de onmogelijke omstandigheden.

Tja, daar is geen enkele taal tegen opgewassen.

Inderdaad geen enkele taal, alleen goed programmeren. :-)

M4

Ximinez

2010-01-10 12:34:17 UTC

Post by Jawade
Iedereen heeft toch z'n eigen stijl. Zo gebruik ik zelden locale
variabelen, zodat ik ze overal beschikbaar heb. En ik zal weer meer

Heh? wat? Dat is dan wel een heeeel bijzondere eigen stijl. De rest van
de wereld doet al decennia weinig anders dan globale variabelen zoveel
mogelijk overbodig te maken.

X.

Jawade

2010-01-11 21:03:43 UTC

Post by Ximinez

Post by Jawade
Iedereen heeft toch z'n eigen stijl. Zo gebruik ik zelden locale
variabelen, zodat ik ze overal beschikbaar heb. En ik zal weer meer

Heh? wat? Dat is dan wel een heeeel bijzondere eigen stijl. De rest van
de wereld doet al decennia weinig anders dan globale variabelen zoveel
mogelijk overbodig te maken.

Ja, inderdaad. :-)

Martijn Lievaart

2010-01-10 07:08:29 UTC

Ik snap jou wel, maar het werkt best hoor, er zijn legio voorbeelden op
internet. Ik kan eigenlijk alleen maar in BASIC en Assembly zonder
'afkijken' iets maken. C++ lijkt weer erg veel op andere talen, dus da's
altijd even zoeken. Terwijl de syntax feitelijk simpel is.

Uch! Herinner me eraan jouw nooit in de buurt van C++ code te laten
komen. Ken je de "rule of three"? Exceptional C++ gelezen? C++ is
gevaarlijk als je het niet kent.

Voorbeeld: Vind de twee bugs in de volgende class:

class testje {
private:
char *p;
public:
testje() : p(new char[100]) {}
~testje() { delete p; }
};

M4
-- C++ is a nice academic experiment that went horribly wrong --

Jawade

2010-01-10 07:55:12 UTC

Ik snap jou wel, maar het werkt best hoor, er zijn legio voorbeelden op
internet. Ik kan eigenlijk alleen maar in BASIC en Assembly zonder
'afkijken' iets maken. C++ lijkt weer erg veel op andere talen, dus da's
altijd even zoeken. Terwijl de syntax feitelijk simpel is.

Uch! Herinner me eraan jouw nooit in de buurt van C++ code te laten
komen. Ken je de "rule of three"? Exceptional C++ gelezen? C++ is
gevaarlijk als je het niet kent.
class testje {
char *p;
testje() : p(new char[100]) {}
~testje() { delete p; }
};
M4
-- C++ is a nice academic experiment that went horribly wrong --

Ik heb zat gemaakt in C++, maar zulke streken als hierboven haal ik
echt niet uit. Het zal wel met re-declareren te maken hebben. Ik heb
geen zin om het precies uit te zoeken, daar heb ik niks aan.

Martijn Lievaart

2010-01-10 12:36:04 UTC

Post by Jawade
Ik snap jou wel, maar het werkt best hoor, er zijn legio voorbeelden
op internet. Ik kan eigenlijk alleen maar in BASIC en Assembly zonder
'afkijken' iets maken. C++ lijkt weer erg veel op andere talen, dus
da's altijd even zoeken. Terwijl de syntax feitelijk simpel is.

Ik heb zat gemaakt in C++, maar zulke streken als hierboven haal ik echt
niet uit. Het zal wel met re-declareren te maken hebben. Ik heb geen zin
om het precies uit te zoeken, daar heb ik niks aan.

Hoezo streken? Dit is gewoon basis C++. Een class met 1 member en die
member is een pointer. Of gebruik jij nooit pointers in C++?

M4

Jawade

2010-01-10 14:29:57 UTC

Post by Martijn Lievaart
Uch! Herinner me eraan jouw nooit in de buurt van C++ code te laten
komen. Ken je de "rule of three"? Exceptional C++ gelezen? C++ is
gevaarlijk als je het niet kent.
class testje {
char *p;
testje() : p(new char[100]) {}
~testje() { delete p; }
};

Ik heb zat gemaakt in C++, maar zulke streken als hierboven haal ik echt
niet uit. Het zal wel met re-declareren te maken hebben. Ik heb geen zin
om het precies uit te zoeken, daar heb ik niks aan.

Hoezo streken? Dit is gewoon basis C++. Een class met 1 member en die
member is een pointer. Of gebruik jij nooit pointers in C++?

Ja, daar kom ik niet onderuit. Maar het is alweer een tijdje geleden,
FreeBASIC is ruim voldoende, met indien nodig enclosed assembly. En..
je kunt ook C-style programmeren. En de .exe's zijn schattig klein.

Martijn Lievaart

2010-01-10 20:17:09 UTC

Post by Jawade
Ik heb zat gemaakt in C++, maar zulke streken als hierboven haal ik
echt niet uit. Het zal wel met re-declareren te maken hebben. Ik heb
geen zin om het precies uit te zoeken, daar heb ik niks aan.

Hoezo streken? Dit is gewoon basis C++. Een class met 1 member en die
member is een pointer. Of gebruik jij nooit pointers in C++?

Ja, daar kom ik niet onderuit. Maar het is alweer een tijdje geleden,
FreeBASIC is ruim voldoende, met indien nodig enclosed assembly. En.. je
kunt ook C-style programmeren. En de .exe's zijn schattig klein.

Waarmee je zowel John's als mijn punt duidelijk onderschrijft, dank u.

M4

Martijn van Buul

2010-01-10 21:43:31 UTC

Post by Martijn Lievaart
class testje {
char *p;
testje() : p(new char[100]) {}
~testje() { delete p; }
};

twee?

1) delete van een pointer uit new[] (soit, omdat het POD is zal het wel
meevallen in de praktijk, maar het *is* stuk)
2) De default assignment operator heeft een memory leak *en* zal later
voor nog meer hoofdpijn zorgen.
3) Dito voor de default copy constructor

--
Martijn van Buul - ***@dohd.org

Martijn Lievaart

2010-01-11 06:12:07 UTC

Post by Martijn van Buul
1) delete van een pointer uit new[] (soit, omdat het POD is zal het wel
meevallen in de praktijk, maar het *is* stuk)
2) De default assignment operator heeft een memory leak *en* zal later
voor nog meer hoofdpijn zorgen.
3) Dito voor de default copy constructor

Gefeliciteerd. Maar 2) en 3) vind ik dezelfde bug. Overigens his er geen
memory leak, wel hoofdpijn (double free).

M4

Martijn van Buul

2010-01-11 10:02:50 UTC

Gefeliciteerd. Maar 2) en 3) vind ik dezelfde bug.

Bijna - behalve dat ik vaak wel zie dat er wel aan de copy constructor is
gedacht (al was het maar door hem private te declareren zonder implementatie)
maar niet aan de assignment operator. Bovendien zijn er wel degelijk

Post by Martijn Lievaart
Overigens his er geen memory leak, wel hoofdpijn (double free).

Hm, ik denk het toch echt van wel - juist in het geval van de assignment
operator. Ik heb er even je code bijgepakt:

class testje {
private:
char *p;
public:
testje() : p(new char[100]) {}
~testje() { delete p; }
};

De default copy constructor en assignment operator zullen equivalent zijn
met

testje (const testje& rhs) : p(rhs.p) { }
testje& testje::operator=(const testje &rhs)
{
p = rhs.p;
return *this;
}

Maar het verschil is dat de assignment operator wordt uitgevoerd op een
object dat al geconstrueerd is. Als ik nu iets doe als

void bla()
{
testje T1; // Impliciet: T1.p = new char[100]
testje T2;
[..]
T1 = T2; // Impliciet: T1.p = T2.p
}

dan zal de oorspronkelijke inhoud van T1.p (die in de constructor van T1 is
ingevuld) toch echt gelekt zijn. Verder heb je inderdaad de bijkomende ellende
van de dubbele delete.

In het geval van de copy constructor heb je gelijk, en zal er niets lekken.

--
Martijn van Buul - ***@dohd.org

Martijn Lievaart

2010-01-11 18:06:19 UTC

Gefeliciteerd. Maar 2) en 3) vind ik dezelfde bug.

Bijna - behalve dat ik vaak wel zie dat er wel aan de copy constructor
is gedacht (al was het maar door hem private te declareren zonder
implementatie) maar niet aan de assignment operator. Bovendien zijn er

Rule of three. Als aan de copy constructor wel gedacht is maar aan de
assignment operator niet, dan is dat een grove fout. Als één van de drie
non-triviaal is, heb je ze alle drie nodig.

Post by Martijn Lievaart
Overigens his er geen memory leak, wel hoofdpijn (double free).

Hm, ik denk het toch echt van wel - juist in het geval van de assignment
class testje {
char *p;
testje() : p(new char[100]) {}
~testje() { delete p; }
};
De default copy constructor en assignment operator zullen equivalent
zijn met
testje (const testje& rhs) : p(rhs.p) { } testje&
testje::operator=(const testje &rhs) {
p = rhs.p;
return *this;
}
Maar het verschil is dat de assignment operator wordt uitgevoerd op een
object dat al geconstrueerd is. Als ik nu iets doe als
void bla()
{
testje T1; // Impliciet: T1.p = new char[100] testje T2;
[..]
T1 = T2; // Impliciet: T1.p = T2.p
}
dan zal de oorspronkelijke inhoud van T1.p (die in de constructor van T1
is ingevuld) toch echt gelekt zijn. Verder heb je inderdaad de
bijkomende ellende van de dubbele delete.

Dan hebben we verschillende definities van lekken. Ik noem het een lek
als het wel gealloceerd wordt maar niet gefreed. In dit geval wordt er 1x
gealloceerd en 2x gefreed, het tegenovergestelde van een lek dus. Zie ook
http://en.wikipedia.org/wiki/Memory_leak.

M4

Martijn van Buul

2010-01-12 09:04:17 UTC

Post by Martijn van Buul
void bla()
{
testje T1; // Impliciet: T1.p = new char[100] testje T2;
[..]
T1 = T2; // Impliciet: T1.p = T2.p
}
dan zal de oorspronkelijke inhoud van T1.p (die in de constructor van T1
is ingevuld) toch echt gelekt zijn. Verder heb je inderdaad de
bijkomende ellende van de dubbele delete.

Dan hebben we verschillende definities van lekken.

Nee, we hebben dezelfde definitie.

Post by Martijn Lievaart
Ik noem het een lek als het wel gealloceerd wordt maar niet gefreed. In dit
geval wordt er 1x gealloceerd en 2x gefreed, het tegenovergestelde van een
lek dus.

En wat gebeurt er met de oorspronkelijke allocatie van T1.p? Die
pointer uit new char[100] in de constructor van T1, waar geen referenties meer
naar zijn (want T1.p is overschreven met de waarde van T2.p - terwijl de
assignment operator verzuimt de oorspronkelijke allocatie vrij te geven), en
die dus ook niet meer gedeletet kan worden?

Post by Martijn Lievaart
Zie ook http://en.wikipedia.org/wiki/Memory_leak.

Zie ook mijn vorige posting, waarin ik uitleg waarom er hier wel degelijk
wordt gelekt.

--
Martijn van Buul - ***@dohd.org

Martijn Lievaart

2010-01-12 20:37:25 UTC

En wat gebeurt er met de oorspronkelijke allocatie van T1.p? Die pointer
uit new char[100] in de constructor van T1, waar geen referenties meer
naar zijn (want T1.p is overschreven met de waarde van T2.p - terwijl de
assignment operator verzuimt de oorspronkelijke allocatie vrij te
geven), en die dus ook niet meer gedeletet kan worden?

Je hebt gelijk!

/me goes sulking in the corner.

M4

Ximinez

2010-01-07 19:49:59 UTC

Post by Jawade
Je moet natuurlijk wel kunnen programmeren. Dat moet je gewoon leren.
Maar als je dat kunt, kun je met BASIC snel uit de voeten.

Post by Jawade
Ik heb pas nog wat geprogrammeerd op de Archimedes, een bijzonder
krachtige BASIC, mede omdat je assembly kunt insluiten en je
rechtstreeks gebruik kunt maken van de systeemroutines.

Post by Jawade
Daar heb je dan wel weer de Programmers Reference Manual voor nodig,
maar die heb ik destijds gekocht.

Yup, ik ook. Tegenwoordig kan je de PDFjes gewoon downloaden
e.d. (legaal voor zover ik kan zien).
http://foundation.riscos.com/Private/index.htm

of PAR (toevallig vandaag nog :-D). Ander nadeel is dat het ietwat groot
wordt, ActivePerl + WxWidgets ~ 8MB exe.

Zo distribueer ik ook wel eens wat. Afgezien van de grootte starten de
programmaatjes ook erg langzaam. (eerst alles uitpakken, dan compileren,
dan executen).

Er zijn dus toch nog wel wat wxperl gebruikers, gezien de m.i. vrij
treurige status van dat pakket (docs) verbaast me dat...

X.

John Bokma

2010-01-07 20:16:22 UTC

Post by Ximinez

Post by John Bokma
of PAR (toevallig vandaag nog :-D). Ander nadeel is dat het ietwat groot
wordt, ActivePerl + WxWidgets ~ 8MB exe.

Zo distribueer ik ook wel eens wat. Afgezien van de grootte starten de
programmaatjes ook erg langzaam. (eerst alles uitpakken, dan
compileren, dan executen).

Ja, klopt, dat viel mij gisteren ook al op.

Post by Ximinez
Er zijn dus toch nog wel wat wxperl gebruikers, gezien de m.i. vrij
treurige status van dat pakket (docs) verbaast me dat...

Mij ook :-). Tip: ik gebruik zelf "wxPython in action" om e.e.a. beter
te begrijpen. Het is meestal geen probleem (voor mij dan) om een
voorbeeld naar Perl om te zetten, ook omdat ik Python aan het leren ben.

En inderdaad, de documentatie is hier en daar diep triest.

Voor ik het vergeet, er is ook:
http://www.wxwidgets.org/about/datasheets/wxWidgetsBook.pdf

gratis ter beschikking gesteld door de uitgever.

Errata: http://wxwidgets.org/docs/book/errata.htm

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Jan Kuiken

2010-01-06 18:53:05 UTC

Post by John Bokma
[angle/diamond operator]

<knip>

Post by Lolo
en inderdaad wat ik al noem maar dat is ook wel de
belangrijkste, het impliciete wat het zeer lastig maakt, het nodigt
uit tot onbegrijpelijkheid.

Het is de programmeur die ingaat op die uitnodiging. Dat je source kan
kloppen in unicode is toch ook geen uitnodiging om alle identifiers maar
in Tengwar te kloppen? Het is een minirok-argument!

Ik zou griekse letters vaoor identifiers nog wel wat vinden, pi en
delta_... etc. vind ik altijd wel wat jammer

Post by Lolo
Maar goh, ik neem de voors, en je kan er
ook weer korte en handige dingen mee doen, ja ben ook echt enthousiast
geworden al vind ik het een van de lastigste die ik zo ken.

Ik ken geen programmeertalen die niet lastig zijn. Ik ben al een tijd
bezig met het leren van Python, maar ik ben nog wel zeker een jaartje
zoet voor ik er vloeiend in ben.

Ik denk het ook lastig is om in meerdere talen vloeiend te kunnen zijn.
Ten eerste om vloeiend in een taal te zijn en blijven moet je de meeste
tijd die taal gebruiken en dat kunnen er nooit twee tegelijk zijn.
Ten tweede (daar betrap ik mezelf wel eens op) ga je in de tweede taal
programmeren zoals je in de eerste taal gewend bent.

Desalniettemin, vind ik het leuk om naar andere talen te kijken,
afgelopen kerstvakantie in de vrije uurtjes, heb ik me door de eerste
hoofdstukken van een online boek over Haskell gewroet. Erg leuk, maar
ik vrees dat ik er alleen in vrije tijd niet 'vloeiend' in zal worden.

btw. zijn er onder de lezers van deze groep nog van 'functional
programming'? Ik hoor er goede verhalen over.

Jan kuiken

John Bokma

2010-01-06 19:37:23 UTC

Jan Kuiken <***@quicknet.nl> writes:

[identifiers]

Post by Jan Kuiken
Ik zou griekse letters vaoor identifiers nog wel wat vinden, pi en
delta_... etc. vind ik altijd wel wat jammer

In een aantal programmeertalen kan dit.

Post by Jan Kuiken
Ik denk het ook lastig is om in meerdere talen vloeiend te kunnen zijn.

Yup, net als met "gewone" talen. Ik denk dat mijn max rond de 3 talen ligt.

Post by Jan Kuiken
Ten eerste om vloeiend in een taal te zijn en blijven moet je de meeste
tijd die taal gebruiken en dat kunnen er nooit twee tegelijk zijn.

Dat ligt er aan, je kan op even dagen taal 1 gebruiken en op oneven
dagen taal 2. Of, eenvoudiger, op het werk programmeer je in een taal,
en in je vrije tijd in een andere.

Post by Jan Kuiken
Ten tweede (daar betrap ik mezelf wel eens op) ga je in de tweede taal
programmeren zoals je in de eerste taal gewend bent.

Met sommige talen zal dat niet zo'n probleem zijn, en er zijn talen waar
dit vrij lastig in is.

Post by Jan Kuiken
Desalniettemin, vind ik het leuk om naar andere talen te kijken,

Yup, ik ook. Ook omdat soms een idee uit een taal best gewoon
probleemloos in een andere taal gebruikt kan worden zonder dat dat
verwarring opleverd, en zelfs een idioom kan worden (een goed voorbeeld
is de zgn Schwartzian transform)

Post by Jan Kuiken
afgelopen kerstvakantie in de vrije uurtjes, heb ik me door de eerste
hoofdstukken van een online boek over Haskell gewroet. Erg leuk, maar
ik vrees dat ik er alleen in vrije tijd niet 'vloeiend' in zal worden.
btw. zijn er onder de lezers van deze groep nog van 'functional
programming'? Ik hoor er goede verhalen over.

Op de UU o.a. Miranda gehad, en wat kleine dingen met Gofer gedaan. Ik
heb recent een boek over Haskell gehad (stond op mijn wensenlijst), en
wil er zeker eens opnieuw induiken.

Andere talen, naast Haskell, die op mijn lijstje "moet ik eens naar
kijken" staan (willekeurige volgorde): Scheme, LUA, Ruby, C#.

Dit jaar wil ik goed in Python worden, en mij (verder) verdiepen in
Emacs Lisp.

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

unknown

2010-01-06 20:25:45 UTC

Post by Jan Kuiken
Ik zou griekse letters vaoor identifiers nog wel wat vinden, pi en
delta_... etc. vind ik altijd wel wat jammer

Eventueel kan je Perl wel in het Latijn programmeren als je zou willen:
http://search.cpan.org/perldoc?Lingua::Romana::Perligata

--
robert

Jan Kuiken

2010-01-06 21:11:51 UTC

Post by Jan Kuiken
Ik zou griekse letters vaoor identifiers nog wel wat vinden, pi en
delta_... etc. vind ik altijd wel wat jammer

http://search.cpan.org/perldoc?Lingua::Romana::Perligata

Ik denk niet dat dat gaat helpen, ik ken griek noch latijns, kom uit de
beta hoek waar men vaak kriebeltjes placht te gebruiken waarvan ik de
naam soms niet ken.
(xi en zeta samen in één mathematisch betoog gebruiken blijft leuk...)

Jan Kuiken

Martijn van Buul

2010-01-02 21:20:46 UTC

Post by Martijn van Buul
Besef wel dat we het hier over Papa Perl hebben. Dat alleen al zou voldoende
reden moeten wezen om zijn wijsheden met een korreltje zout te nemen ;)

Waarom?
Sterker, geef eens aan wat er mis is met die 3 regels?

Het zijn misschien 3 regels voor een perlprogrammeur, maar ik voel me
er absoluut niet door aangesproken:

1. Luiheid, waardoor je dingen wil automatiseren

Dat herken ik niet; ik automatiseer dingen uit noodzaak, of uit efficientie-
overwegigen. Mensen die lui zijn bedenken met zo min mogelijk werk een korte
termijnoplossing, die niet schaalbaar is. En iets rigoreus refactoren zal
er wel helemaal niet inzitten.

2. Ongeduld, waardoor je efficientere software zou schrijven.
Het schrijven van efficiente software vereist juist een behoorlijke
hoeveelheid doorzettingsvermogen. Ongeduldige programmeurs zullen juist het
mes in het varken laten steken, en er gewoon dikkere hardware tegenaan gooien.
Todat dat opeens niet meer kan - en dan is het altijd de schuld van iemand
anders.

3. Grootheidswaanzin leidt helemaal niet tot betere code omdat je een
kwalitatief hoogwaardig product zou willen afleveren, maar juist tot
brakke code omdat je in je hoogmoed aanneemt dat wat *jij* bakt ongetwijfeld
het neusje van de zalm is. Het leidt er ook toe dat je een taal die aan
elkaar hangt van inconsistenties en rommeligheid als "af" beschouwt..

Dus nee, ik herken me er absoluut niet in - ik denk dat het op zekere hoogte
tekenend is dat het in de Perl community blijkbaar *wel* herkend wordt...

Post by John Bokma
De meeste mensen die iets over Perl te zeiken hebben (ik wil het
namelijk geen zeggen noemen) hebben er nooit serieus tijd in gestoken.

Ik heb dat wel. Meer dan me lief is.

--
Martijn van Buul - ***@dohd.org

John Bokma

2010-01-02 21:54:02 UTC

Post by Martijn van Buul
Besef wel dat we het hier over Papa Perl hebben. Dat alleen al zou voldoende
reden moeten wezen om zijn wijsheden met een korreltje zout te nemen ;)

Waarom?
Sterker, geef eens aan wat er mis is met die 3 regels?

Juist niet: als je lui wilt zijn, moet je dat wel goed doen ;-)

Post by Martijn van Buul
die niet schaalbaar is. En iets rigoreus refactoren zal
er wel helemaal niet inzitten.

Juist wel, als je daardoor later nog minder werk hebt ;-)

Ik versta er zelf ook onder: een dusdanig product opleveren dat je
zelden tot nooit vragen van je klant krijgt, niet nu, en niet in de
toekomst (dus: goede documentatie, goed doordacht, enz.)

Post by Martijn van Buul
2. Ongeduld, waardoor je efficientere software zou schrijven.
Het schrijven van efficiente software vereist juist een behoorlijke
hoeveelheid doorzettingsvermogen. Ongeduldige programmeurs zullen juist het
mes in het varken laten steken, en er gewoon dikkere hardware tegenaan gooien.
Todat dat opeens niet meer kan - en dan is het altijd de schuld van iemand
anders.

Uhm, ik heb 'm ff geherkwoot:

Impatience
The anger you feel when the computer is being lazy. This makes you
write programs that don't just react to your needs, but actually
anticipate them. Or at least pretend to. Hence, the second great
virtue of a programmer. See also laziness and hubris. (p.608)

Post by Martijn van Buul
3. Grootheidswaanzin leidt helemaal niet tot betere code omdat je een
kwalitatief hoogwaardig product zou willen afleveren, maar juist tot
brakke code omdat je in je hoogmoed aanneemt dat wat *jij* bakt ongetwijfeld
het neusje van de zalm is.

Tja, zo kunnen we van alles wel wat bakken, natuurlijk. Jij wilt het
lezen zodat het met jouw denkbeeld van Perl overeenkomt.

Post by Martijn van Buul
Het leidt er ook toe dat je een taal die aan
elkaar hangt van inconsistenties en rommeligheid als "af" beschouwt..

Ik wist niet dat Perl af was? Of tenminste: het is in zo verre af dat
het geen zin heeft om dingen verder op de schop te nemen, dat is met
meer talen zo. Dat maakt ze niet perfect. Er is een reden dat er hard
aan Perl 6 word gewerkt.

Post by Martijn van Buul
Dus nee, ik herken me er absoluut niet in - ik denk dat het op zekere hoogte
tekenend is dat het in de Perl community blijkbaar *wel* herkend wordt...

Maar dan niet in jouw "vertaling", en zeker niet in hoe ik werk, laat
dat even duidelijk wezen.

Post by John Bokma
De meeste mensen die iets over Perl te zeiken hebben (ik wil het
namelijk geen zeggen noemen) hebben er nooit serieus tijd in gestoken.

Ik heb dat wel. Meer dan me lief is.

Wellicht definieeren we serieus dan ook anders ;-)

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Martijn van Buul

2010-01-03 20:43:50 UTC

Post by John Bokma
Tja, zo kunnen we van alles wel wat bakken, natuurlijk. Jij wilt het
lezen zodat het met jouw denkbeeld van Perl overeenkomt.

Nee, eigenlijk niet. Ik wil het hooguit *niet* lezen zoals het bedoeld
wordt, omdat ik me erger aan de zonden die me hier worden aangemeten.

Zo zo je kunnen beweren dat iedere Open Source programmeur eigenlijk een
ziekelijke kleptomaan is omdat 'ie het kunnen stelen van andermans code
tot hoger doel heeft gemaakt - maar dat bekt niet erg vriendelijk.
Persoonlijk stel ik het dus helemaal niet op prijs om uitgescholden te
worden voor werkschuw, ongeduldig stuk eigenpijper. Ook niet door Larry Wall -
ook al weet ik ook wel dat het tongue-in-cheek was.

Post by Martijn van Buul
Dus nee, ik herken me er absoluut niet in - ik denk dat het op zekere hoogte
tekenend is dat het in de Perl community blijkbaar *wel* herkend wordt...

Maar dan niet in jouw "vertaling", en zeker niet in hoe ik werk, laat
dat even duidelijk wezen.

Natuurlijk. Maar dat is dan ook het hele punt - wat jij een leuke
vergelijking vind kan ik duidelijk minder waarderen. Net zoals ik perl
niet zo kan waarderen. Het zal wel iets met referentiekaders te maken
hebben ofzo.

--
Martijn van Buul - ***@dohd.org

Ximinez

2010-01-03 21:54:15 UTC

Post by John Bokma
Tja, zo kunnen we van alles wel wat bakken, natuurlijk. Jij wilt het
lezen zodat het met jouw denkbeeld van Perl overeenkomt.

Nee, eigenlijk niet. Ik wil het hooguit *niet* lezen zoals het bedoeld
wordt, omdat ik me erger aan de zonden die me hier worden aangemeten.
Zo zo je kunnen beweren dat iedere Open Source programmeur eigenlijk een
ziekelijke kleptomaan is omdat 'ie het kunnen stelen van andermans code
tot hoger doel heeft gemaakt - maar dat bekt niet erg vriendelijk.
Persoonlijk stel ik het dus helemaal niet op prijs om uitgescholden te
worden voor werkschuw, ongeduldig stuk eigenpijper. Ook niet door Larry Wall -
ook al weet ik ook wel dat het tongue-in-cheek was.

Post by Martijn van Buul
Dus nee, ik herken me er absoluut niet in - ik denk dat het op zekere hoogte
tekenend is dat het in de Perl community blijkbaar *wel* herkend wordt...

Maar dan niet in jouw "vertaling", en zeker niet in hoe ik werk, laat
dat even duidelijk wezen.

Meer met jezelf (te) serieus nemen, lijkt me ;)

X.

Ximinez

2010-01-03 08:16:19 UTC

Post by Martijn van Buul
Besef wel dat we het hier over Papa Perl hebben. Dat alleen al zou voldoende
reden moeten wezen om zijn wijsheden met een korreltje zout te nemen ;)

Waarom?
Sterker, geef eens aan wat er mis is met die 3 regels?

Het zijn misschien 3 regels voor een perlprogrammeur, maar ik voel me
1. Luiheid, waardoor je dingen wil automatiseren
Dat herken ik niet; ik automatiseer dingen uit noodzaak, of uit efficientie-
overwegigen. Mensen die lui zijn bedenken met zo min mogelijk werk een korte
termijnoplossing, die niet schaalbaar is. En iets rigoreus refactoren zal
er wel helemaal niet inzitten.
2. Ongeduld, waardoor je efficientere software zou schrijven.
Het schrijven van efficiente software vereist juist een behoorlijke
hoeveelheid doorzettingsvermogen. Ongeduldige programmeurs zullen juist het
mes in het varken laten steken, en er gewoon dikkere hardware tegenaan gooien.
Todat dat opeens niet meer kan - en dan is het altijd de schuld van iemand
anders.
3. Grootheidswaanzin leidt helemaal niet tot betere code omdat je een
kwalitatief hoogwaardig product zou willen afleveren, maar juist tot
brakke code omdat je in je hoogmoed aanneemt dat wat *jij* bakt ongetwijfeld
het neusje van de zalm is. Het leidt er ook toe dat je een taal die aan
elkaar hangt van inconsistenties en rommeligheid als "af" beschouwt..
Dus nee, ik herken me er absoluut niet in - ik denk dat het op zekere hoogte
tekenend is dat het in de Perl community blijkbaar *wel* herkend wordt...

De echte waarheid is dat er veel soorten programmeurs zijn. Jij bent
vast een prima programmeur, maar het is een zegen dat er ook *andere*
programmeurs zijn...

Neem mij bijvoorbeeld. Als hard-core programmeur stel ik waarschijnlijk
weinig voor, maar ik maak dingen waar die hard-cores nooit op gekomen
zouden zijn.

X.

John Bokma

2010-01-01 22:48:18 UTC