🚀 go-pugleaf

Philip Paeps <philip@paeps.cx> wrote:
> kan natuurlijk (als gevorderde programmeur) ergens in een obscuur hoekje van
> de IDE die dingen raadplegen, maar als beginnende programmeur vormen ze een
> slechte gewoonte: 'h�, dat spul gaat mijn venstertjes voor mij tekenen!
> Joepie!  Ikke geen last van'.  Zo krijg je dan buffer overflows en andere
> onwenselijke neveneffecten.  Dan kan je je uren suf zoeken in je eigen code,
> en niets vinden, als er bij de IDE-generatie van de venster-code iets is
> misgelopen.

Wat een onzin. Buffer overflows zijn een issue in code die (meestal) niets met
venstertjes te maken heeft. De twee meest voor de hand liggende slachtoffers
van buffer overflows (bind & sendmail) zijn niet met een IDE gemaakt.

Natuurlijk is het altijd mogelijk dat IDE gegeneerde code een bug heeft.
Maar een library kan dat evengoed hebben, je compiler ook, ja zelfs je chip
kan een bug hebben. Op zich heeft dat helemaal niets met IDEs te maken.

> Verder komt de IDE ook vaak met zijn eigen compiler, vaak zijn deze compilers
> ook niet volledig ANSI compliant, of 'meer dan' ANSI compliant (vertaal: ze
> zijn niet conform de standaard).  Dan krijg je bijvoorbeeld niet-zo-grappige
> situaties, en kweek je weer maar eens slechte gewoontes [ik denk aan void main
> (void) { }].

Als void main() je grootste bekommernis is kan ik je geruststellen : 
Visual Studio genereert een mooie int main(int argc, char* argv[]).

Wat betreft niet compliant ANSI compilers : dit is uiteraard voornamelijk een
'probleem' met C++. Ook dat staat orthogonaal op de IDE's. Bijna iedere C++
IDE gebruikt een standalone 'externe' compiler. In ieder geval Visual Studio
en kdevelop. Het feit dat MSC++ bv NULL weergeeft bij een mislukt new
ipv een bad_alloc te throwen heb je dus zowel bij de IDE als op de command
line.

Tenslotte kan ik nog ter verdediging voeren dat bad_alloc throwen slechts een
latere toevoeging aan de standaard was. De gewone manier van doen was
NULL terug te geven. Op die eerste veronderstelling is de compiler van
MS geschreven en op ook een heleboel code. Als daarna het standardisatie
comite besluit om die ge-eikte regel te veranderen, zit MS met een probleem.
Ofwel niet compliant zijn, ofwel compliant zijn en een enorme (al
bestaande) codebase buggy maken. Ik kies voor het eerste.

Eenzelfde kan trouwens gezegd worden over het for (int...) probleem.
En dan hebben we de twee problemen gehad waar zowat 99% van de C++
programmeurs mee te maken hebben denk ik. De rest zijn problemen
die je als beginner gewoon niet tegenkomt. En als verder gevorderde
is het een minimum dat je weet hoe je professioneel moet omgaan met
de gebreken van een compiler (van iedere compiler).

> Je kan tegenwoordig veel automatiseren (ik programmeer de meest waanzinnige
> automatie dingen), maar het programmeren zelf *mag* je niet automatiseren,
> want dan zit je met het kip en ei probleem.  Zelf-schrijvende software mag dan
> interessant zijn, maar iemand moet de software schrijven om zelf-schrijvende
> software te schrijven, en als jij die software gaat gebruiken om
> zelf-schrijvende programma's te (laten?) schrijven, zit je vast aan de
> mogelijke gebreken van de originele schrijver ...

Met die redenering hadden we ook nooit aan C compilers moeten beginnen want
wie gaat er dan de compilers schrijven als iederen C gebruikt en niemand
nog assembler kent?

Je begrijpt zelf wel dat je redenering ridikuul is.

En nogmaals : een IDE geschiedenis verhindert niet dat je later perfect leert
omgaan met make/...

Vraagje : wat was jou allereerste programmeer ervaring?

>   When in doubt, don't muble, overexpose ... then mumble.

Volgens mij wordt het tijd jij aan het mumblen begint. De overexposure van
je bevooroordeelde IDE denken hebben we nu wel gehad.

cu bart

-- 
http://www.irule.be/bvh/