[Alg] Kwaliteiten van een goeie programmeur

[Soultaker]

Op vrijdag 31 mei 2002 13:30 schreef mietje het volgende:
Dit kunnen de standaard texteditors op een *NIX systeem al, daar heb je geen IDE voor nodig. Zowel vi(m) als emacs kunnen wat je hierboven opnoemt (en nog veel meer).

Pff, in vi kan ik niet eens klikken! Waar is de menubalk? Functietoetsen? Debugging environment? Data display? Link met (API/taal) documentatie?

Wie denk dat vi een volwaardig alternatief vormt voor een IDE heeft nooit met een goede IDE gewerkt. Ik wil benadrukken dat een IDE niet voor elk doel geschikt is, maar in veelvoorkomende gevallen biedt een IDE de programmeur zoveel ondersteuning dat 'ie z'n werk in minder tijd (en met minder moeite) kan uitvoeren.

[TheDane]

Op vrijdag 31 mei 2002 10:35 schreef Soultaker het volgende:

[..]

Dat is natuurlijk maar een gedeeltelijke waarheid. Jou bewering klopt wel, maar dat wil niet zeggen dat je, door in een IDE te werken, geen ervaring op kan doen of geen begrip van programmeren kan hebben. Ik durf te beweren dat het in principe niet uitmaakt, hoewel door de bank genomen de programmeurs die met een shell werken waarschijnlijk betere programmeurs zijn.
[..]

heb je helemaal gelijk in; ik breng 't wat ongenuanceerder

maar 't toeval wil dat bij 't bedrijf waar ik werk in in principe geen enkel tool wordt gebruikt. we werken met oracle 8i, php en pl/sql en alles wordt met de hand gemaakt, geconfigureerd etc

hierdoor weten we wel precies wat er aan de hand is, en bijvoorbeeld het tweaken van een applicatie; het zoeken van errors, het optimaliseren van de database performance gebeurt gewoon vanaf de prompt.

we hadden laatst een sollicitant die een ZEER indrukwekkend cv had, qua programmeerervaring, gebruik van methodes, protocollen etc. Maar toen we hem nu vroegen wat er nou eigenlijk echt gebeurde .. daar kon ie geen antwoord op geven. Met tools kon ie alles, maar een simpele database corruptie fixen was voor hem totaal onmogelijk; wist nog niet eens dat je corrupties kon fixen

Wat ik dus wil zeggen: doordat we heel dicht bij de code zitten, weten we precies waar we mee bezig zijn, en wat de consequenties ervan zijn. het duurt dan wel langer voordat we concreet resultaat hebben/zien (met sql forms tooltje gewoon lekker een formulier bij elkaar slepen vanuit het database model (of iets dergelijks; geen bal verstand van) gaat supersnel, en wij zitten bij wijze van spreken een dag code te kloppen voordat we iets kunnen laten zien.

maargoed, voor beide methodes is wat te zeggen i presume

[whoami]

Op vrijdag 31 mei 2002 13:49 schreef TheDane het volgende:

we hadden laatst een sollicitant die een ZEER indrukwekkend cv had, qua programmeerervaring, gebruik van methodes, protocollen etc. Maar toen we hem nu vroegen wat er nou eigenlijk echt gebeurde .. daar kon ie geen antwoord op geven. Met tools kon ie alles, maar een simpele database corruptie fixen was voor hem totaal onmogelijk; wist nog niet eens dat je corrupties kon fixen

Dus, hebben jullie hem niet aangenomen? Indien dit zo is, zonde misschien. Zo'n dingen vallen te leren en zijn ook interessant voor die sollicitant.

[Nielsz]

Op vrijdag 31 mei 2002 13:49 schreef TheDane het volgende:

Tja, de vraag is of 'jouw' methode beter is als die bij andere bedrijven. Want jullie kunnen nu bugs oplossen in 1 dag ipv 2. Maar jullie doen er wel 3 dagen langer over om het product af te hebben. Dus in totaal zijn jullie een stuk trager. Lijkt me ook niet optimaal.

[Soultaker]

Op vrijdag 31 mei 2002 13:49 schreef TheDane het volgende:
hierdoor weten we wel precies wat er aan de hand is, en bijvoorbeeld het tweaken van een applicatie; het zoeken van errors, het optimaliseren van de database performance gebeurt gewoon vanaf de prompt.

Klopt, dat zie je vaak, en dat brengt vaak veel voordelen met zich mee. Daar ben ik het en sich wel mee eens.

we hadden laatst een sollicitant die een ZEER indrukwekkend cv had, qua programmeerervaring, gebruik van methodes, protocollen etc. Maar toen we hem nu vroegen wat er nou eigenlijk echt gebeurde .. daar kon ie geen antwoord op geven.

De vraag is of dit zo slecht is. Natuurlijk zijn er mensen die niet weten wat er intern gebeurd en tegelijkertijd rampzalige code schrijven, maar als je gewoon een goed begrip hebt van hoe interfacs (API's e.d.) benaderd dienen te worden en in staat bent naar specificaties te werken, kun je zeker goede programma's schrijven. Een sterk punt van OO-programmeren (en andere methoden voor het programmeren van complexe systemen) is nu juist dat je de implementatie niet hoeft te kennen om een component te kunnen gebruiken. Door juist niet te kijken wat er intern gebeurd, kun je er voor zorgen dat je implementatieonafhankelijke code schrijft.

Wanneer je bugs moet vinden, fouten moet herstellen of moet optimaliseren, ben je met deze filosofie sterk in het nadeel. Je hebt de kennis van de implementatie dan immers nodig. Dat betekent echter niet dat voor het programmeerwerk zelf de abstracte aanpak zeer geschikt is.

maargoed, voor beide methodes is wat te zeggen i presume

Dat ben ik dan wel weer met je eens.

[Anoniem: 13700]

Op vrijdag 31 mei 2002 13:35 schreef Soultaker het volgende:
Pff, in vi kan ik niet eens klikken! Waar is de menubalk? Functietoetsen? Debugging environment? Data display? Link met (API/taal) documentatie?

* Anoniem: 13700 zucht, dan maar verder offtopic

Klikken is nu juist wat een IDE (en een GUI) langzaam maakt. Telkens als ik een hand van m'n keyboard moet nemen om de muis te grijpen verlies ik tijd. Menubalk: idem dito, je bindt keys, en een keystroke gaat nog altijd sneller dan menunavigatie. Je kunt perfect een debugger starten via vi, of contextgevoelig een man/info page oproepen. De *NIX editors, en met name vi, zijn gemaakt om zo snel mogelijk te kunnen werken.

Wie denk dat vi een volwaardig alternatief vormt voor een IDE heeft nooit met een goede IDE gewerkt.

Het lijkt er meer op dat jij nog geen 5% van de features van de *NIX standaard editors kent.

[TheDane]

Op vrijdag 31 mei 2002 13:54 schreef Nielsz het volgende:

[..]

Tja, de vraag is of 'jouw' methode beter is als die bij andere bedrijven. Want jullie kunnen nu bugs oplossen in 1 dag ipv 2. Maar jullie doen er wel 3 dagen langer over om het product af te hebben. Dus in totaal zijn jullie een stuk trager. Lijkt me ook niet optimaal.

heb je op zich wel gelijk in. maar ik zeg ook niet dat 'mijn' methode beter is en als je eenmaal een x aantal componenten klaarhebt, die je maar in je nieuwe code hoeft in te bakken, dan ben je opzich ook best snel klaar.

Maar per saldo, als je over een heel jaar, met veel verschillende projecten, bekijkt, dan zou een 'toolfreak' (sorry voor de uberfoute woordkeuze) waarschijnlijk wel efficienter werken ja, maar da's een afweging natuurlijk, wij/ik vind 't belangrijk om ook te begrijpen waar ik mee bezig ben .. en als dat als keerzijde heeft dat ik er langer over doe .. helaas. maar dat heeft dan weer als keerzijde dat ik problemen sneller zie, en ook stukken sneller kan fixen.

dusja, ellek voordeel heb z'n nadeel

[Alarmnummer]

Op vrijdag 31 mei 2002 13:49 schreef TheDane het volgende:

[..]

heb je helemaal gelijk in; ik breng 't wat ongenuanceerder

maar 't toeval wil dat bij 't bedrijf waar ik werk in in principe geen enkel tool wordt gebruikt. we werken met oracle 8i, php en pl/sql en alles wordt met de hand gemaakt, geconfigureerd etc

hierdoor weten we wel precies wat er aan de hand is, en bijvoorbeeld het tweaken van een applicatie; het zoeken van errors, het optimaliseren van de database performance gebeurt gewoon vanaf de prompt.

we hadden laatst een sollicitant die een ZEER indrukwekkend cv had, qua programmeerervaring, gebruik van methodes, protocollen etc. Maar toen we hem nu vroegen wat er nou eigenlijk echt gebeurde .. daar kon ie geen antwoord op geven. Met tools kon ie alles, maar een simpele database corruptie fixen was voor hem totaal onmogelijk; wist nog niet eens dat je corrupties kon fixen

Wat ik dus wil zeggen: doordat we heel dicht bij de code zitten, weten we precies waar we mee bezig zijn, en wat de consequenties ervan zijn. het duurt dan wel langer voordat we concreet resultaat hebben/zien (met sql forms tooltje gewoon lekker een formulier bij elkaar slepen vanuit het database model (of iets dergelijks; geen bal verstand van) gaat supersnel, en wij zitten bij wijze van spreken een dag code te kloppen voordat we iets kunnen laten zien.

maargoed, voor beide methodes is wat te zeggen i presume

Er bestaat ook een gulden middenweg. Ik gebruik IDEA als IDE voor Java en dat werkt echt super. Er zit dus geen wizzards in zoals in jbuilder (hou ik zelf ook niet van), maar het werkt echt super handig. Je hebt hele goeie refactor mogelijkheden (geaumomatiseerd transformeren van stukken code), code completion, auto imports, syntax checking, inzich in code door extra text coloring (member variablen paars, ongebruikte variablen/methodes grijs). Ik zou niet meer zonder willen werken.

Ik ben het dus zeker niet met je eens dat je in een zo kaal mogelijke omgeving moet zitten om veel inzicht in je code te blijven houden.

link: http://www.intellij.com/idea/overview.jsp

[Bananenplant]

hmm... hoe word je een goede programmeur?

ik heb als het goed is straks m'n propedeuse WO informatica, en ik heb als het om manieren van denken gaat best wel wat geleerd dit jaar.

over algoritmen en dat analyse van problemen vaak efficiency kan winnen.

en bij inleiding object oriented programming hoe je een model maakt en uitprogrammeert etc.

ik heb ook gemerkt dat mensen die menen dat wiskunde en programmeren niks met elkaar te maken hebben fout zitten.

ik ben nu bezig mezelf sql, php te leren. eerst een model maken, daarna implementeren. gestructureerd deze keer, in tegen stelling tot de bloated code qbasic die ik in klas 2 maakte.

documenteren hou ik niet zo van eigenlijk. maar zulke grote programma's maak ik ook nog niet....

[drm]

mietje:
Het lijkt er meer op dat jij nog geen 5% van de features van de *NIX standaard editors kent.

pico roelt !!

[TheDane]

Op vrijdag 31 mei 2002 14:47 schreef drm het volgende:

[..]

pico roelt !!

geef mij maar vi

of liever nog vim

[Bananenplant]

vind emacs wel fijn. wel frustrerend dat de keycombo's niet in windowsprogramma's werken.

ctrl-e, ctrl-a, ctrl-k werken wel in de meeste X-programma's, nl.

[TheDane]

Op vrijdag 31 mei 2002 14:41 schreef Alarmnummer het volgende:

[..]

Er bestaat ook een gulden middenweg. Ik gebruik IDEA als IDE voor Java en dat werkt echt super. Er zit dus geen wizzards in zoals in jbuilder (hou ik zelf ook niet van), maar het werkt echt super handig. Je hebt hele goeie refactor mogelijkheden (geaumomatiseerd transformeren van stukken code) in. Code completion, auto import, syntax checking. Ik zou niet meer zonder willen werken.

Ik ben het dus zeker niet met je eens dat je in een zo kaal mogelijke omgeving moet zitten om veel inzicht in je code te blijven houden.

link: http://www.intellij.com/idea/overview.jsp

ik ken maar een kwart van die termen

( en weet totaal nul komma nul van java )

Ik heb me sinds borland pascal (een jaar of 7 geleden) niet meer beziggehouden met IDE's, ben er van overtuigd dat er hele goeie IDE's zijn, die 't werk stuk voor stuk een stuk efficienter maken, maar ik voel me d'r persoonlijk niet prettig bij,

ik gruwel al van zoiets als editplus, terwijl 't alleen maar makkelijker en overzichtelijker werkt (schijnbaar)

ieder z'n voorkeur

[Alarmnummer]

Om maar weer even ontopic te komen:

wat maakt een goeie programmeur goed..

hmmz...

1) technisch inzicht, goed abstractie vermogen. Als je dit niet hebt dan houd het allemaal op.
2) doorzettings vermogen.
3) plezier in wat je doet.
4) inzien dat jij niet altijd de beste oplossing hebt
5) open staan voor nieuwe ideeen ipv vast roesten in een bepaalde denk wereld.

[Anoniem: 7195]

Op vrijdag 31 mei 2002 00:01 schreef TheDane het volgende:
[..]
onder een shell werken brengt je veel dichter bij de code waaraan je zit te prutsen.
met andere woorden: je bgrijpt veel beter waar je mee bezig bent; ergo je verstaat je vak beter. ergo je bent een betere programmeur

Wat een onnozel gebazel. Je moet werken met de tool die je het meeste resultaat oplevert. En als dat een codegenerator is, dan ben je slimmer die te gebruiken dan in een of andere kut-ascii editor met een 80x23 schermpje ellenlange lappen onoverzichtelijke bagger te tikken zonder enige hulp.

[TheDane]

Op vrijdag 31 mei 2002 15:46 schreef Otis het volgende:

[..]

Wat een onnozel gebazel. Je moet werken met de tool die je het meeste resultaat oplevert. En als dat een codegenerator is, dan ben je slimmer die te gebruiken dan in een of andere kut-ascii editor met een 80x23 schermpje ellenlange lappen onoverzichtelijke bagger te tikken zonder enige hulp.

heb jij uitleg hiervan in mijn latere posts gelezen ?

goezo

[Anoniem: 7195]

Op vrijdag 31 mei 2002 16:12 schreef TheDane het volgende:

[..]

heb jij uitleg hiervan in mijn latere posts gelezen ?

goezo

Iedereen die roept dat een shell ook maar iets beter is dan wat dan ook snapt het niet. Iedere uitleg daarvan helpt dan niet.

Uberhaupt over tools praten in het kader van 'goede programmeur' is onzin, dan begrijp je het begrip 'programmeren' niet.

[Anoniem: 7195]

Op vrijdag 31 mei 2002 13:49 schreef TheDane het volgende:
[..]
maar 't toeval wil dat bij 't bedrijf waar ik werk in in principe geen enkel tool wordt gebruikt. we werken met oracle 8i, php en pl/sql en alles wordt met de hand gemaakt, geconfigureerd etc

NIH in full effect!

hierdoor weten we wel precies wat er aan de hand is, en bijvoorbeeld het tweaken van een applicatie; het zoeken van errors, het optimaliseren van de database performance gebeurt gewoon vanaf de prompt.

En omdat je alles zelf maakt, moet je ook alles zelf testen en debuggen en uitontwikkelen nog voordat je met je eigenlijke werk kunt beginnen! Je concurrent pakt een pak tools van de plank, en begint meteen met wat hij wil bouwen, nl. wat de klant wil. Jullie moeten eerst jullie tools uitontwikkelen totdat ze productiviteit opleveren. Allemaal zonde van de tijd.

we hadden laatst een sollicitant die een ZEER indrukwekkend cv had, qua programmeerervaring, gebruik van methodes, protocollen etc. Maar toen we hem nu vroegen wat er nou eigenlijk echt gebeurde .. daar kon ie geen antwoord op geven. Met tools kon ie alles, maar een simpele database corruptie fixen was voor hem totaal onmogelijk; wist nog niet eens dat je corrupties kon fixen

Nou, die persoon mag blij zijn dat hij niet bij jullie is komen werken. No offence, maar een programmeur bouwt software en een systeembeheerder beheert systemen, een DBA beheert de database(s). Wellicht had die persoon met wat docs in de hand het allemaal snel opgelost. Nu wijs je hem af omdat hij die onnozele kennis niet bij zich heeft, die hij als programmeur helemaal niet HOEFT te hebben, want een goed bedrijf heeft iemand in dienst die dat oplost, die systemen beheert en de daarop draaiende databases, webserver software etc. Anders verlies je nl. kostbare productiviteit aan de developerkant, dat geld kost maar ook zeer frustrerend is voor de programmeurs.

Wat ik dus wil zeggen: doordat we heel dicht bij de code zitten, weten we precies waar we mee bezig zijn, en wat de consequenties ervan zijn.

Iemand die in Visual Studio.NET in C# een programma schrijft zit niet 'dicht bij de code' ? Wat zit die persoon dan? er ver vanaf? Weet die persoon NIET wat er gebeurt? Ik denk dat die persoon volledig weet wat er gebeurt. Anders kan die persoon nl. niet een programma bouwen. Die persoon gebruikt een off-the-shelf api en een serie off-the-shelf tools en is vanaf minuut 1 productief. IEDERE regel code die hij intikt bouwt mee aan hetgeen hij moet bouwen ipv dat deze is bedoeld voor tools die er al hadden moeten zijn.

De bekrompenheid druipt van je posting af. Als ik een tip mag geven: open je ogen en kijk om je heen en ga nadenken over wat er WERKELIJK telt bij het bouwen van software. Not Invented Here syndrome is een verschijnsel dat NIET telt bij het bouwen van software, het zorgt eerder voor afbreuk.

het duurt dan wel langer voordat we concreet resultaat hebben/zien (met sql forms tooltje gewoon lekker een formulier bij elkaar slepen vanuit het database model (of iets dergelijks; geen bal verstand van) gaat supersnel, en wij zitten bij wijze van spreken een dag code te kloppen voordat we iets kunnen laten zien.

Maar het eindresultaat van die off-the-shelf tools is beter dan jouw code. Weet je waarom? Omdat die off-the-shelf tools werken. Je kan verwachten wat het resultaat is. Al waar je op moet letten is of je ze correct bedient en dan is in theorie je resultaat foutloos. Jij moet allereerst je tools bugfree zien te krijgen en dan nog eens de bediening ervan foutloos doen (via code of handmatig). Dubbel traject, dubbele kans op fouten.

maargoed, voor beide methodes is wat te zeggen i presume

Nee. Er is maar 1 weg naar succes in de software wereld: voortbouwen op gestabiliseerde kennis en kunde. Zelf alles willen doen is de grootst mogelijke domme blunder die je kunt begaan. ZEKER als er bakken met tools beschikbaar zijn maar je per se kiest voor 'zelf doen', het Not Invented Here syndrome.

[Soultaker]

Op vrijdag 31 mei 2002 16:23 schreef Otis het volgende:
Iedereen die roept dat een shell ook maar iets beter is dan wat dan ook snapt het niet. Iedere uitleg daarvan helpt dan niet.

En bedankt voor de genuanceerde uitspraak. Als ik zeg dat een beter shell is dan niets, dan snap ik het niet? Als je het met TheDane's redenatie niet eens hebt, val 'm dan aan op zijn aannames en argumenten. Hier hebben we niets aan.

Uberhaupt over tools praten in het kader van 'goede programmeur' is onzin, dan begrijp je het begrip 'programmeren' niet.

Jij wel dan? Volgens mij is er geen vaste definitie van wat wel en niet programmeren is.

[Nielsz]

Op vrijdag 31 mei 2002 16:38 schreef Otis het volgende:
Nee. Er is maar 1 weg naar succes in de software wereld: voortbouwen op gestabiliseerde kennis en kunde. Zelf alles willen doen is de grootst mogelijke domme blunder die je kunt begaan. ZEKER als er bakken met tools beschikbaar zijn maar je per se kiest voor 'zelf doen', het Not Invented Here syndrome.

Echt waanzinnig offtopic:

The knights who say NIH!
Nu snap ik 'm

[Anoniem: 7195]

Op vrijdag 31 mei 2002 16:40 schreef Soultaker het volgende:
[..]
En bedankt voor de genuanceerde uitspraak. Als ik zeg dat een beter shell is dan niets, dan snap ik het niet? Als je het met TheDane's redenatie niet eens hebt, val 'm dan aan op zijn aannames en argumenten. Hier hebben we niets aan.

Beter dan niets voor wat? Je dorst lessen? Vervoer? Zie je hoe dom het is om uberhaupt over tools te praten mbt het begrip 'goede programmeur' ? Ik gebruik een shell alleen voor af en toe een commandootje te executeren. (dir /b /s *.asp | findstr /f:/ "bla" bijvoorbeeld) Maw: de effectiviteit van een tool is relatief aan het doel, de omgeving, de bediener en de kwaliteit van de alternatieven. Programmeren is echter een abstract begrip en staat los van welke taal/tool dan ook (programmeertaal is ook een tool btw)

[..]
Jij wel dan? Volgens mij is er geen vaste definitie van wat wel en niet programmeren is.

Jawel, die staat gewoon inde vandale:

pro·gram·Žme·ren (ov.ww.)

1 [ook abs.] (computeropdrachten) vaststellen in een gecodeerde taal
2 een programma opstellen van
3 (een computer) laden met een programma

[Anoniem: 49376]

Anders bouw je gewoon ff alles van scratch. Onzin

Ik vind gewoon dat je een bepaalde kennis moet hebben van het systeem waar je op bouwt. Of het nou unix is of winhoos. Ik bouw al jaren Db appl op windows 2000 en SQL. Mijn kennis wordt steeds groter op het gebied van proggen maar ook op een stuk systeembeheer. De meest programmeurs willen alleen de software kant kennen. Lang leve het OSI model. Als je die kent, ken je het systeem, en dan pas kan je kinky dingen bouwen.

Of je nou tools gebruikt of niet. Je hoeft niet het wiel opnieuw uit te vinden. Aan zulke dingen zijn bedrijven failliet gegaan of ze gaan heel slecht. Je pakt toch gewoon de taal die jouw het meeste bied!

[TheDane]

Op vrijdag 31 mei 2002 16:38 schreef Otis het volgende:

[..]

NIH in full effect!
[..]

En omdat je alles zelf maakt, moet je ook alles zelf testen en debuggen en uitontwikkelen nog voordat je met je eigenlijke werk kunt beginnen! Je concurrent pakt een pak tools van de plank, en begint meteen met wat hij wil bouwen, nl. wat de klant wil. Jullie moeten eerst jullie tools uitontwikkelen totdat ze productiviteit opleveren. Allemaal zonde van de tijd.
[..]

Nou, die persoon mag blij zijn dat hij niet bij jullie is komen werken. No offence, maar een programmeur bouwt software en een systeembeheerder beheert systemen, een DBA beheert de database(s). Wellicht had die persoon met wat docs in de hand het allemaal snel opgelost. Nu wijs je hem af omdat hij die onnozele kennis niet bij zich heeft, die hij als programmeur helemaal niet HOEFT te hebben, want een goed bedrijf heeft iemand in dienst die dat oplost, die systemen beheert en de daarop draaiende databases, webserver software etc. Anders verlies je nl. kostbare productiviteit aan de developerkant, dat geld kost maar ook zeer frustrerend is voor de programmeurs.
[..]

Iemand die in Visual Studio.NET in C# een programma schrijft zit niet 'dicht bij de code' ? Wat zit die persoon dan? er ver vanaf? Weet die persoon NIET wat er gebeurt? Ik denk dat die persoon volledig weet wat er gebeurt. Anders kan die persoon nl. niet een programma bouwen. Die persoon gebruikt een off-the-shelf api en een serie off-the-shelf tools en is vanaf minuut 1 productief. IEDERE regel code die hij intikt bouwt mee aan hetgeen hij moet bouwen ipv dat deze is bedoeld voor tools die er al hadden moeten zijn.

De bekrompenheid druipt van je posting af. Als ik een tip mag geven: open je ogen en kijk om je heen en ga nadenken over wat er WERKELIJK telt bij het bouwen van software. Not Invented Here syndrome is een verschijnsel dat NIET telt bij het bouwen van software, het zorgt eerder voor afbreuk.
[..]

Maar het eindresultaat van die off-the-shelf tools is beter dan jouw code. Weet je waarom? Omdat die off-the-shelf tools werken. Je kan verwachten wat het resultaat is. Al waar je op moet letten is of je ze correct bedient en dan is in theorie je resultaat foutloos. Jij moet allereerst je tools bugfree zien te krijgen en dan nog eens de bediening ervan foutloos doen (via code of handmatig). Dubbel traject, dubbele kans op fouten.
[..]

Nee. Er is maar 1 weg naar succes in de software wereld: voortbouwen op gestabiliseerde kennis en kunde. Zelf alles willen doen is de grootst mogelijke domme blunder die je kunt begaan. ZEKER als er bakken met tools beschikbaar zijn maar je per se kiest voor 'zelf doen', het Not Invented Here syndrome.

fijne post, maar met je laatste paragraaf kukelt het hele zaakje natuurlijk wel genadelijk in elkaar: voortbouwen op bestaande dingen is leuk, maar al het gezeik waar bijvoorbeeld microsoft / windows nu mee zit, is het gevolg van een fout begin. backwards compatibility, vastzitten aan een gedachtengoed dat tig jaar geleden state of the art was ,.

enzovoort enzovoort,.
allemaal leuk en aardig dus, maar dan kies ik er liever voor om m'n zaakjes nog wel een keer opnieuw uit te vinden. en dan WEL goed.

overigens: jij hebt 't over bedrijven die een aparte systeembeheerder / dba etc werk kunnen bieden. d'r zijn genoeg kleine bedrijven waarbij zo'n functie niet dagvullend is, dus ga je je met meer dingen bezighouden.


maar iemand die met tooltjes kan werken, kan ongetwijfeld goed werk afleveren, en zoals je zelf al zegt: in theorie foutloos. maarja, d'r zijn altijd wel zaken waar geen rekening mee gehouden is; bijvoorbeeld een corrupte database,.

ik heb inmiddels 't gros van de foutmeldingen wel meegemaakt, en daar ben ik blij om! Met tools leren werken kan iedereen; begrijpen hoe het tool werkt niet ..

maargoed, we gaan nu wel erg ver offtopic, dussuh,
/off

[Anoniem: 7195]

Op vrijdag 31 mei 2002 17:01 schreef TheDane het volgende:
[..]
fijne post, maar met je laatste paragraaf kukelt het hele zaakje natuurlijk wel genadelijk in elkaar: voortbouwen op bestaande dingen is leuk, maar al het gezeik waar bijvoorbeeld microsoft / windows nu mee zit, is het gevolg van een fout begin. backwards compatibility, vastzitten aan een gedachtengoed dat tig jaar geleden state of the art was ,.

Nee, je snapt het niet. Gebruik de tools die voorhanden zijn en focus op de dingen die je moet maken, alleen DAN kom je vooruit.

Je gelul over windows/microsoft snap ik niet, wat is daar fout aan? Is het unix systeem geen fout begin geweest?

.NET bijvoorbeeld geeft aan dat een flexibele instelling mbt tools/talen en een abstracte kijk op programmeren je als developer veel sneller ergens brengt dan het halsstarrige dreinen dat je alles zelf wilt bouwen: zodra jouw platform out-dated is ben je het haasje en moet je voor een nieuw platform ALLE tools weer opnieuw maken. Iemand die off-the-shelf spul gebruikt past zn denken toe in een ander raamwerk maar komt binnen no-time tot goed resultaat, immers de tools werken al, hij hoeft alleen ze maar te gebruiken.

enzovoort enzovoort,.
allemaal leuk en aardig dus, maar dan kies ik er liever voor om m'n zaakjes nog wel een keer opnieuw uit te vinden. en dan WEL goed.

*gaap*. Dus jij koopt ook een stuk ijzer en gaat daar eerst een hamer van bakken voordat je gaat timmeren? Of is dat ineens anders?

overigens: jij hebt 't over bedrijven die een aparte systeembeheerder / dba etc werk kunnen bieden. d'r zijn genoeg kleine bedrijven waarbij zo'n functie niet dagvullend is, dus ga je je met meer dingen bezighouden.

Dat boeit toch niet? Je wijst dan toch iemand aan in de organisatie die dat regelt? En aangezien deze persoon nieuw was, hebben jullie al zo'n persoon intern. (als het goed is).

maar iemand die met tooltjes kan werken, kan ongetwijfeld goed werk afleveren, en zoals je zelf al zegt: in theorie foutloos. maarja, d'r zijn altijd wel zaken waar geen rekening mee gehouden is; bijvoorbeeld een corrupte database,.

Je snapt het werkelijk niet he. Als een developer met een corrupte database wordt geconfronteerd (wat je daar onder ook moge verstaan, ik neem aan dat je niet bedoeld een corrupte mempage table of corrupte pages in de storage), kan hij documentatie pakken en het proberen op te lossen of een daarvoor aangewezen persoon inzetten.

Iemand die met tools werkt en daarmee resultaat bereikt is productief en dus nuttig bezig. Iemand die eerst zn eigen development omgeving moet programmeren voordat hij productief kan zijn, gaat maar in de hobbykamer spelen, want dat wordt niet wat: tools zijn er niet voor niets. Gebruik ze. En doet een tool iets voor 99% en je hebt net die ene 1% nodig, kijk dan naar een andere tool of bouw een additional tool die die ene 1% aanvult, ipv een tool te bouwen die 100% op zich neemt.

Dit topic gaat over 'goede programmeur'. Ik vind dat wanneer je NIET inziet dat productiviteit in de breedste zin van het woord (dus gelet op alle gestelde randvoorwaarden) key is, je geen goede programmeur bent en zeker niet goed wordt geleid/gestuurd: een manager van een bedrijf dat zn developmentteam opzadelt met het opnieuw bouwen van tools die je zo kunt downloaden of kunt kopen voor een habbekrats, leidt niet maar remt.

ik heb inmiddels 't gros van de foutmeldingen wel meegemaakt, en daar ben ik blij om! Met tools leren werken kan iedereen; begrijpen hoe het tool werkt niet ..

Oh, dus jij bent er zoeen die vindt dat je pas goede software kunt schrijven als je weet hoe de compiler werkt? Software bouwen is abstract. Of schrijf jij alles in assembler, want dat staat het dichtst bij de code gebruikt door de processor en kun je tenminste goed bepalen hoe het geheel wordt geoptimaliseerd ? Als voor jouw werk een generator wordt gebouwd, die code kan genereren die jij anders met de hand inklopt, waarom zou men die niet gebruiken? Genereren die hap, handmatig wat tweaken en klaar. Of minder radicaal: een 4GL omgeving voor je 3GL werk: puur simpele statements ingeven die de functionaliteit verwoorden die je moet implementeren: een abstractieniveauverhoging die de softwarebouwer alleen maar helpt: het werk ontdoen van randverschijnselen en de developer puur laten focussen op hetgeen gedaan moet worden. Juist DIE keuze maken als developer is de enige correcte en geeft aan dat de developer JUIST weet waar hij mee bezig is. Die keuze bewust NIET maken laat zien dat de developer juist NIET snapt waar hij mee bezig is en programmeren verwart met het werk dat de 4GL compiler / 3GL generator ook doet.

maargoed, we gaan nu wel erg ver offtopic, dussuh,

Nee, het is juist on topic, want dit is de kern van de zaak.

[mbravenboer]

Het blijft wel een terugkerend verhaal hoe je productiviteit het beste kunt vergroten.

Productiviteit staat denk ik voor een groot deel gelijk aan abstractie en beheersing van complexiteit. Ik praat daarom maar even over abstractie ipv productiviteit omdat bij productiviteit snel andere randzaken betrokken kunnen worden. De kern van de zaak voor de lange termijn is echter abstractie.

Otis omschrijft abstractie graag in termen van code-generators, tools, visueel werken. Zoals we al in een eerdere discussie over abstractie hebben gezien ben ik het daar niet mee eens. Althans: tools en code-generatie zijn belangrijk, maar het gaat niet om de tools, maar om de input van de tools.

De effectiviteit van een taal hangt daarom vooral af van de vorm van de input. In hoeverre:

1. abstraheert deze? Lift het de kijk op de zaak op een hoger niveau?
2. zijn de input mogelijkheden niet te specifiek voor een bepaald probleem?

Ik zelf geloof dat visueel werken, interactieve tools en ad-hoc code generatoren niet veel toevoegen omdat ze voornamelijk op punt (2) op dit moment vaak zeer gebrekkig zijn.

Het gaat namelijk in heel de informatica om het specificeren van een situatie.

Als voorbeeld: bij imperatief programmeren is de afstand tot een specificatie vaak erg groot. Je moet in je hoofd tijdens het programmeren de specificatie omzetten in een implementatie: je geeft aan hoe iets moet gebeuren waarvan in de specificatie beschreven staat wat er moet gebeuren.

Bij talen als SQL zie je een duidelijke abstractie: je geeft op een hele prettig manier aan wat er moet gebeuren en abstraheert daarbij werkelijk enorm van de concrete implementatie: hoe moet de query of update uitgevoerd worden. SQL is dus duidelijk een taal die een stuk dichter bij een specificatie staat. Dit wordt ook weleens declaratief genoemd, maar dat vind ik eigenlijk geen prettige term.

Ik zie erg veel toekomst voor specificerende talen. Dit kan twee kanten opgaan:

1. Talen die zich richten op een algemeen toepassingsgebied. Ze zijn dus niet domein-specifiek. Deze groep van talen zal echter meer bieden tov de huidige imperatieve talen omdat de implementatie niet direct gericht is op de architectuur van een moderne computer zoals je in alle imperatieve talen ziet. Ze bieden dus een hele eigen manier van uitdrukking zonder dat ze daarbij rekening houden met de architectuur van een computer. Bekende voorbeelden zijn functionele talen (Haskell, Clean) maar bijvoorbeeld ook transformatie-talen als XSLT (wat gericht is op een bepaald type operatie, maar niet op een bepaald applicatie domein) en Stratego.

2. Talen die zich richten op een bepaald domein. Dit worden ook wel domein specifieke talen genoemd (DSL). De grens met de talen in punt (1) is niet altijd even duidelijk, maar je kunt het vaak wel aanvoelen. DSLs zijn gericht op een bepaald domein en zorgen dat jij voor dat domein heel prettig kunt beschrijven (specificeren) wat jouw situatie is. De specificatie in een DSL gaat vaak erg richting een soort data: je schetst een situatie.

Persoonlijk denk ik dat de talen in categorie (1) toch ooit nog eens belangrijk gaan worden. XSLT is een treffend voorbeeld en eigenlijk de eerste declaratieve taal die door de 'gewone man' echt algemeen gebruikt wordt. In de toekomst zullen er meer van zulke talen doorbreken.

De talen in categorie (1) zullen altijd taal-georienteerd blijven. Tools voor deze categorie zijn in feite compilers of eenvoudigere transformaties die een taal omzetten naar een implementatie in termen van een computer-architectuur: ze voegen een hoe toe voor een uitvoer op een computer.

De talen in categorie (2) zouden wellicht eerder richting visueel werken kunnen gaan, maar toch geloof ik het zelfs daar niet echt. Specificeren in een taal is qua uitdrukkingskracht op dit moment volledig superieur aan specificeren via visualisatie en interactie. Bij interactie met een visuele omgeving moet de visuele omgeving namelijk behoorlijk geavanceerd in elkaar zitten en rekening kunnen houden met allerlei typen van gebruik en combinaties daarvan. Het ontwerpen van zo'n visuele omgeving (waarin je dus echt visueel programmeert, ik heb het niet over een feature rijke editor) is enorm lastig (wat natuurlijk niet per definitie betekent dat het nooit goed gedaan zal worden).

Ik moest van week een tooltje schrijven wat een vrij lastige bewerking op een XML-achtig document uitvoerde. Deze bewerking was ik eerst aan het implementeren in Java, maar om 2 redenen was ik dit na een regel of 200 zat: (1) ik moest een aantal aannames maken die ik niet wilde maken in 200 regels Java code. (2) ik besefte dat ik veel beter een krachtige transformatie-taal kon gebruiken. Ik heb toen de code weggeflikkerd en de hele zaken compact gespecificeerd in ongeveer 10 regels Stratego code. Resultaat: de code was inzichtelijk, aannames waren compact beschrijven en de correctheid van de code is eenvoudig in te zien. Bij 200 regels Java/C# code is dat gegarandeerd een stukje lastiger .

In de toekomst zou je steeds meer talen moeten kunnen pakken waarin je je probleem compact kunt specificeren. Deze talen moeten gerealiseerd worden met tools, de tools zijn daarbij een noodzakelijk iets: het gaat niet om de tools, maar om het niveau waarop je over je probleem kunt praten en op welke manier je het dus kunt specificeren.

Tot zover dit verhaaltje over abstractie, tools, visueel werken, talen en de toekomst .

Als je reageert vanuit een pro-tool visie: merk op dat ik niets tegen tools zeg, maar dat het naar mijn mening duidelijk om de input-mogelijkheden van een tool gaat.

[Anoniem: 7195]

Op vrijdag 31 mei 2002 18:29 schreef mbravenboer het volgende:
Otis omschrijft abstractie graag in termen van code-generators, tools, visueel werken. Zoals we al in een eerdere discussie over abstractie hebben gezien ben ik het daar niet mee eens. Althans: tools en code-generatie zijn belangrijk, maar het gaat niet om de tools, maar om de input van de tools.

Erm, nee, dat doe ik juist niet. Ik omschrijf abstractie in het geheel niet in termen van tools etc., ik gebruik voorbeelden van tools als metafoor/middel om aan te geven dat abstractie van hetgeen men mee bezig is juist hetgeen hier bediscussieerd moet worden en verder totaal niets. Je kunt nl. wel praten over abstractie maar veel mensen kunnen daar al snel geen touw meer aan vast knopen. Een metafoor als 4GL <-> 3GL is al veel tastbaarder. Ik bedoel echter wel degelijk de abstractie, of het begrip abstractie in de context softwarebouw/engineering, en niet '4GL' of '3GL', dat is slechts het middel om iets duidelijk te maken.

Als je verder had gekeken, schoffeer ik het begrip 'tool' en 'taal' (wat ik gelijk stel aan 'tool') in deze discussie want ze zijn totaal niet belangrijk: het zijn middelen om te bereiken wat je wilt/moet bereiken en verder niets. Denken in tools is in mijn ogen dan ook bekrompen en past alleen maar bij een hobbykamer of bij fetisjistenmeetings met gelijk gestemden.

De effectiviteit van een taal hangt daarom vooral af van de vorm van de input. In hoeverre:
1. abstraheert deze? Lift het de kijk op de zaak op een hoger niveau?

Abstraheren is afleiden. , je bedoelt: in hoeverre maakt de taal de materie abstract voor de gebruiker?

2. zijn de input mogelijkheden niet te specifiek voor een bepaald probleem?
Ik zelf geloof dat visueel werken, interactieve tools en ad-hoc code generatoren niet veel toevoegen omdat ze voornamelijk op punt (2) op dit moment vaak zeer gebrekkig zijn.

De uitvoering van een idee is nooit de scherprechter voor de kwaliteit van een idee. Nooit vergeten.

Het gaat namelijk in heel de informatica om het specificeren van een situatie.

Onder andere ja. Maar niet alleen het specificeren van een situatie, maar ook het specificeren van het waarom van die situatie, het bereiken van die situatie en de gevolgen van die situatie. (ik neem aan dat je met 'situatie' bedoelt, de gewenste state na analyse van een zekere problematiek)

Als voorbeeld: bij imperatief programmeren is de afstand tot een specificatie vaak erg groot. Je moet in je hoofd tijdens het programmeren de specificatie omzetten in een implementatie: je geeft aan hoe iets moet gebeuren waarvan in de specificatie beschreven staat wat er moet gebeuren.

Maar in feite ben je handmatig aan het uitvoeren wat een 4GL compiler genereert voor een 3GL (voorbeeld). Je zou dus kunnen stellen, dat wanneer je een 4GL compiler hebt voor een zekere 3GL, je programmeren OF opnieuw moet definieren, vanuit de POV van de 3GL developer, OF je programmeren uberhaupt als abstract begrip moet definieren ZONDER te letten op talen/tools, en dus moet gaan praten over de specificatie WAT gebouwd moet worden, of beter: het opstellen van die specificatie(s) met inbegrip van de nevenwerkzaamheden daarbij (ontwerpbeslissingen nemen/analyses etc).

[de toekomst volgens mbravenboer]
In de toekomst zou je steeds meer talen moeten kunnen pakken waarin je je probleem compact kunt specificeren. Deze talen moeten gerealiseerd worden met tools, de tools zijn daarbij een noodzakelijk iets: het gaat niet om de tools, maar om het niveau waarop je over je probleem kunt praten en op welke manier je het dus kunt specificeren.

De taal is ook een tool. Immers: hij is net zo inwisselbaar als een tool. t.a.t. is een taal niets anders dan een tussenvorm tussen ontwerp/ideeen enerzijds en lowlevel implementatie in opcodes anderzijds. En als je een tussenvorm hebt tussen 2 uitersten, kun je altijd een andere tussenvorm definieren die dichter bij een van beide uitersten staat. Hoe dichter bij de ontwerp/ideeen kant, hoe abstracter. Door de tool 'abstractievergroting' krijg je een taal op abstractieniveau n+1 die je als tool kunt zien van de taal op abstractieniveau n.

Op dit moment zijn programmeertalen een noodzakelijk iets. In theorie zijn ze niet nodig: als je in een zekere vorm je ontwerp kunt weergeven zodat het ook door computers kan worden gelezen heb je geen programmeertalen meer nodig. Iedere vorm van programmeertaal is dus in feite het invullen van het gebrek aan die feature. Het handmatig inbeitelen van ellenlange lappen cryptische programmateksten is een gevolg van het gebrek aan een taal/tool op een abstractieniveau hoger dan het abstractieniveau waar de taal/tool van de cryptische programmateksten op is gesitueerd.

Ik geloof stellig dat over een veelvoud van jaren de mensheid een zeker abstractieniveau zal bereiken in 'programmeertalen' dat men werkelijk daarmee automatisch programmeertalen overbodig maakt. Tot die tijd zijn beitelaars nodig en eigenlijk nog meer mensen die de abstractieniveaus van hedendaagse talen/tools opwerken naar een hoger level zodat noeste beitelaars steeds minder en minder nodig zullen zijn.

Als je reageert vanuit een pro-tool visie: merk op dat ik niets tegen tools zeg, maar dat het naar mijn mening duidelijk om de input-mogelijkheden van een tool gaat.

It's software, thus it solves a problem. Solve the cause of the problem and kill the need for the software.

[mbravenboer]

het zijn middelen om te bereiken wat je wilt/moet bereiken en verder niets. Denken in tools is in mijn ogen dan ook bekrompen en past alleen maar bij een hobbykamer of bij fetisjistenmeetings met gelijk gestemden.

Er is best wel een reden om te kicken op een tool of een taal. Je bent geen fan van een tool omdat je het tool zo mooi vind, maar omdat het iets moois doet. Het stelt jezelf in staat om te abstraheren en je prettiger en compacter uit te kunnen drukken. Denken in tools als oplossingen is daarom niet bekrompen, zolang je de tools maar wel als middel blijft zien.

Abstraheren is afleiden. je bedoelt: in hoeverre maakt de taal de materie abstract voor de gebruiker?

Nee hoor, ik bedoel precies wat ik zeg . Ik bedoel uiteraard niet abstraheren van het probleem, maar het abstraheren in de implementatie: in hoeverre biedt het tool een kijk op de zaak die niet belandt in een overzichtelijke lap zooi die zich met irrelevante details bezig houdt (zoals in imperatieve implementaties).

De taal is ook een tool

Mwah, daar ben ik het niet mee eens. Een programmeertaal is een methode om een computer te instrueren om bepaalde operaties uit te voeren. De taal is echter geen uitvoering: je kunt in de taal slechts de situatie specificeren. Zelfs in een imperatieve taal ben je aan het specificeren: je specificeert in het model van een computer wat er gedaan moet worden. In een functionele taal specificeer je wat er moet gebeuren met behulp van vele functies en in XSLT specificeer je wat er moet gebeuren door middel van templates die toegepast kunnen worden op bepaalde paden in een boom.

Je kunt je probleem op allerlei methoden specificeren, maar voor alle specificaties gebruik je een taal. Je kunt gerust een andere taal gebruiken, dan specificeer je de situatie gewoon in een andere model.

Formele freaks specificeren hun probleem bijvoorbeeld graag in formele definities, wannabee wiskundige informatici specificeren hun probleem graag in termen functies en hobbyisten die server-side applicaties bouwen specificeren hun probleem in PHP. Dat daarvoor wellicht nog andere vormen van specificaties hebben plaats gevonden staat los van het feit dat je nog steeds aan het specificeren bent.

Een tool is iets heel anders: in een tool specificeer je niets. Een tool geef je een input en het tool gaat aan de hand van die input iets voor jou genereren of doen. Uitvoering van specificaties vindt dus plaats in tools. Een compiler is ook slechts een uitvoering van een specificatie. Een compiler zet de specificatie in een bepaalde input-taal namelijk om naar een bepaalde andere vorm. Een compiler zelf kan je echter niet inrichten voor een bepaalde situatie.

Op dit moment zijn programmeertalen een noodzakelijk iets. In theorie zijn ze niet nodig: als je in een zekere vorm je ontwerp kunt weergeven zodat het ook door computers kan worden gelezen heb je geen programmeertalen meer nodig. Iedere vorm van programmeertaal is dus in feite het invullen van het gebrek aan die feature.

Je ziet het begrip 'taal' denk ik te beperkt. Je kunt in een taal iets specificeren. Ook een ontwerp is in feite geschreven in een taal. Dat je bij het samenstellen van een UML echter niets intikt, is slechts omdat er een tool is die een visuele manier biedt waarop jij je probleem kunt specificeren.

De tekst-gerichte input is ook slechts 1 manier van input. Je kunt gerust zeggen dat visuele ontwikkeling naar jouw mening een betere of makkelijkere manier is om iets te specificeren in een taal, maar daarmee zeg je dus niet dat de taal onzinnig is. Talen zijn een feit waar je niet omheen kunt en ook niet wilt. De syntaxtische vorm kan je wellicht niet aanstaan, maar dat is een detail.

Overigens vind ik dus wel dat de syntaxtische vorm meer toekomst heeft dan de visuele vorm, maar goed... Dat is een hele lastige discussie ;-) .

Het handmatig inbeitelen van ellenlange lappen cryptische programmateksten is een gevolg van het gebrek aan een taal/tool op een abstractieniveau hoger dan het abstractieniveau waar de taal/tool van de cryptische programmateksten op is gesitueerd.

Helaas associeer jij het handmatig inbeitelen van ellenlange lappen cryptische programmateksten met het fenomeen 'taal'. Dat is dus onjuist. Om jezelf even te citeren:

De uitvoering van een idee is nooit de scherprechter voor de kwaliteit van een idee. Nooit vergeten.

Kijk eens naar SQL, XPath, Haskell, Stratego of 1 van de vele, vele domein specifieke talen. Kijk eens naar generatoren van relationeel-OO mappings, kijk eens naar XML data-binding specificaties: het zijn allemaal talen die je in staat stellen om de specificatie op een compacte en duidelijke manier aan te geven. Ook dit zijn talen en dit zijn dus de ideeen die naar mijn mening de toekomst hebben: talen die je voor een bepaald domein in staat stellen om prettig te specificeren wat de situatie is.

[TheDane]

Op vrijdag 31 mei 2002 17:42 schreef Otis het volgende:

[..]

Nee, je snapt het niet. Gebruik de tools die voorhanden zijn en focus op de dingen die je moet maken, alleen DAN kom je vooruit.

Je gelul over windows/microsoft snap ik niet, wat is daar fout aan? Is het unix systeem geen fout begin geweest?

.NET bijvoorbeeld geeft aan dat een flexibele instelling mbt tools/talen en een abstracte kijk op programmeren je als developer veel sneller ergens brengt dan het halsstarrige dreinen dat je alles zelf wilt bouwen: zodra jouw platform out-dated is ben je het haasje en moet je voor een nieuw platform ALLE tools weer opnieuw maken. Iemand die off-the-shelf spul gebruikt past zn denken toe in een ander raamwerk maar komt binnen no-time tot goed resultaat, immers de tools werken al, hij hoeft alleen ze maar te gebruiken.
[..]

*gaap*. Dus jij koopt ook een stuk ijzer en gaat daar eerst een hamer van bakken voordat je gaat timmeren? Of is dat ineens anders?
[..]

Dat boeit toch niet? Je wijst dan toch iemand aan in de organisatie die dat regelt? En aangezien deze persoon nieuw was, hebben jullie al zo'n persoon intern. (als het goed is).
[..]

Je snapt het werkelijk niet he. Als een developer met een corrupte database wordt geconfronteerd (wat je daar onder ook moge verstaan, ik neem aan dat je niet bedoeld een corrupte mempage table of corrupte pages in de storage), kan hij documentatie pakken en het proberen op te lossen of een daarvoor aangewezen persoon inzetten.

Iemand die met tools werkt en daarmee resultaat bereikt is productief en dus nuttig bezig. Iemand die eerst zn eigen development omgeving moet programmeren voordat hij productief kan zijn, gaat maar in de hobbykamer spelen, want dat wordt niet wat: tools zijn er niet voor niets. Gebruik ze. En doet een tool iets voor 99% en je hebt net die ene 1% nodig, kijk dan naar een andere tool of bouw een additional tool die die ene 1% aanvult, ipv een tool te bouwen die 100% op zich neemt.

Dit topic gaat over 'goede programmeur'. Ik vind dat wanneer je NIET inziet dat productiviteit in de breedste zin van het woord (dus gelet op alle gestelde randvoorwaarden) key is, je geen goede programmeur bent en zeker niet goed wordt geleid/gestuurd: een manager van een bedrijf dat zn developmentteam opzadelt met het opnieuw bouwen van tools die je zo kunt downloaden of kunt kopen voor een habbekrats, leidt niet maar remt.
[..]

Oh, dus jij bent er zoeen die vindt dat je pas goede software kunt schrijven als je weet hoe de compiler werkt? Software bouwen is abstract. Of schrijf jij alles in assembler, want dat staat het dichtst bij de code gebruikt door de processor en kun je tenminste goed bepalen hoe het geheel wordt geoptimaliseerd ? Als voor jouw werk een generator wordt gebouwd, die code kan genereren die jij anders met de hand inklopt, waarom zou men die niet gebruiken? Genereren die hap, handmatig wat tweaken en klaar. Of minder radicaal: een 4GL omgeving voor je 3GL werk: puur simpele statements ingeven die de functionaliteit verwoorden die je moet implementeren: een abstractieniveauverhoging die de softwarebouwer alleen maar helpt: het werk ontdoen van randverschijnselen en de developer puur laten focussen op hetgeen gedaan moet worden. Juist DIE keuze maken als developer is de enige correcte en geeft aan dat de developer JUIST weet waar hij mee bezig is. Die keuze bewust NIET maken laat zien dat de developer juist NIET snapt waar hij mee bezig is en programmeren verwart met het werk dat de 4GL compiler / 3GL generator ook doet.
[..]

Nee, het is juist on topic, want dit is de kern van de zaak.

/bla
fijn jij wint

sjonge jonge, waar gaat dit nog over

lees ff mijn eerste post , die WEL ontopic was, en reageer daar op ofzo

overigens:

de manier van werken verschilt per organisatie.

een nieuweling die alles van werken met tools weet, maar niets van de onderliggende aspecten just does not fit in, want dan zouden we de hele bedrijfscultuur aan zijn manier van werken aan moeten passen, met alle gevolgen van dien.

vast niet de bedoeling.

en jij overschat 't bedrijf waar ik werk

[Anoniem: 27915]

Leuk topic. .

Mijn bijdrage: een goede programmeur staat boven zijn code en snapt dus waar hij mee bezig is.

Dat is alles ja. En dat is het moeilijkste wat er is.

Daarnaast zijn er specifieke eisen die een programma goed maken, zoals een cleane opbouw (code design) qua classes, functions per class, etc., efficiente code (zo weinig mogelijk code duplicaten, zoveel mogelijk een classed design dus), het liefst enigzins geoptimaliseerd voor minder perfecte hardware. Maar het allerbelangrijkste is dat een programmeur verder kijkt dan zijn eigen systeem, dat hij dus overzicht houdt en weet waar hij mee bezig is. En dan kom je al snel weer terug bij mijn eerste punt.

[Kappie]

Een goede programmeur is iemand die de problemen van een gebruiker kan omzetten in een goed werkend programma.

Meeste programmeurs kunnen dit technisch gezien wel aan. De moeilijkheid met programmeren is het zo dat de gebruiker er goed mee kan omgaan.

[Sponz]

Op vrijdag 31 mei 2002 22:07 schreef beelzebubu het volgende:
Leuk topic. .

Mijn bijdrage: een goede programmeur staat boven zijn code en snapt dus waar hij mee bezig is.

Dat is alles ja. En dat is het moeilijkste wat er is.

Gelul. Elke programmeur die iets maakt dat werkt snapt z'n code wel.

Verder ontbreekt in de discussie aan een referentie kader. Wat is slecht, wat is goed, wat is goed genoeg, wat is uitstekend?

* Sponz is goed genoeg voor een aardig salaris

Beheersing van tools, editors of IDE's geeft aan of iemand handig is, niet of ie kan programmeren. Dat zijn vaardigheden die makkelijk te leren zijn.

[whoami]

Nu, ik had bij het starten van dit topic niet alleen technische vaardigheden enzo in gedachten maar ook eerder persoonlijke/sociale vaardigheden.

Qua overtuigingskracht, communicatie, ed...

[Anoniem: 3057]

Op vrijdag 31 mei 2002 22:16 schreef Kappie het volgende:
Een goede programmeur is iemand die de problemen van een gebruiker kan omzetten in een goed werkend programma.

Meeste programmeurs kunnen dit technisch gezien wel aan. De moeilijkheid met programmeren is het zo dat de gebruiker er goed mee kan omgaan.

De grote vraag is: is het bepalen van hoe het programma door de klant makkelijk is om te gebruiken een taak voor een programmeur? Ik vind van niet. Dat is de taak van een functioneel ontwerper, of misschien in een nog eerder stadium van een consultant.

Natuurlijk kan het zijn dat 1 persoon meerdere rollen heeft binnen een project, maar de rol van functioneel ontwerper is heel anders dan die van een programmeur.

Ik vind bijvoorbeeld ook niet dat een goede functioneel ontwerper een goede programmeur moet zijn, hoewel ik wel vind dat hij de concepten van programmeren moet begrijpen, liefst zelf wat ervaring ermee hebben.

[Anoniem: 27915]

Op zaterdag 01 juni 2002 01:20 schreef Sponz het volgende:
Gelul. Elke programmeur die iets maakt dat werkt snapt z'n code wel.

Dat is pas gelul. Zo ongeveer alle mensen die ik ken (note: ik ben geen professioneel programmeur en programmeren is op de farmacie opleiding slechts als bijvak te doen) die klooien maar wat aan. Ze hebben geen idee waar ze mee bezig zijn, ze schrijven wat code en ze verwachten dat het werkt.

Boven je code staan betekent dat je het design snapt. Dat je dus exact kan dromen, van detail (functie, variabele) tot aan het volledige applicatiedesign, wat het nut daarvan is, wat het doet en waarom het op die manier gaat en niet anders. Dan snap je waar je mee bezig bent - dat maakt een goede programmeur imo.

* Sponz is goed genoeg voor een aardig salaris

Uit ervaring zeg ik dat dat helemaal niks zegt.

[jopiek]

ik ben bij een Software Engineer en geen ordinaire programmeur te zijn
die lui kibbelen mij teveel

[Anoniem: 3057]

Op zaterdag 01 juni 2002 10:29 schreef jopiek het volgende:
ik ben bij een Software Engineer en geen ordinaire programmeur te zijn
die lui kibbelen mij teveel

* Anoniem: 3057 rotflmao ....
Programmeur A: "Ik heb gelijk."
Programmeur B: "Nee, ikkeh!"
Programmeur A: "Nietus, ik weet het beter!"
SoftwareEngineer: "Joh, weetje, geef mij maar een bom met duiten en zeg wat je wil, dan maak ik het wel terwijl zij het uitvechten."

Tja, voor pragmatisme valt ook wel iets te zeggen als een kwaliteir voor een programmeur / software engineer.

[odysseus]

Naar mijn idee - en dan ben ik het denk ik met beelzebubu eens - is de kwaliteit van een programmeur niet af te meten aan zijn kennis van specifieke API's en dergelijke, maar veel meer aan zijn vermogen om een probleem te analyseren, in stukken op te delen en op elk onderdeel een antwoord te vinden op zo'n manier dat al die losse delen het grote probleem oplossen. Op welke manier je het daarna naar echte code vertaalt (welke taal, met welke tools) is dan meer een kwestie van smaak en van omstandigheden.

Zelf programmeer ik het een en ander als hobby, maar heel serieus is dat niet. Dat doe ik graag met XEmacs, al doe ik kleine perl-scripts ook nog wel in vi. KDevelop ken ik ook redelijk (ik ken ook een aantal van de ontwikkelaars ervan) en ook dat werkt niet slecht. Het is naar mijn idee onzinnig om te stellen dat je met een console veel minder zou kunnen doen dan binnen een GUI. Het bouwen van een GUI is logischerwijs wat lastig, maar gewone code schrijven doe ik liever op mijn 132x60 console dan in een editor. De console heeft ook heeft ook dingen als ctags, syntax highlighting en de mogelijkheid om naar definities en documentatie te springen, al zal het dan door op een toets te drukken zijn in plaats van door te klikken. Daarnaast biedt de console het voordeel van de flexibiliteit: je kunt door het aaneenschakelen van een aantal kleine tools veel meer dingen doen dan door het gebruik van een stel functies uit één groot programma. De GUI-variant van 'ls -hdl `find / -name .cpp` | awk '{print $5 $9}' | less' is vast ook wel te bedenken maar kost waarschijnlijk aanmerkelijk meer tijd. Om nog maar niet te beginnen over het gebruik van korte sed-scriptjes die het leven aanzienlijk vergemakkelijken...dergelijke mogelijkheden biedt een grafische omgeving in de meeste gevallen niet. Wel eens geprobeerd om een programma te schrijven en daarna één van je core-classes een andere naam te geven? Zonder een recursieve sed-functie zou ik er niet graag aan beginnen, alleen de gedachte al dat ik alle bestanden handmatig zou moeten gaan wijzigen...en mocht een GUI dat ook kunnen, dan kun je weer een net iets ander probleem verzinnen waar dan weer geen grafisch antwoord op is.

* odysseus merkt op dat KVim en misschien binnenkort ook wel KXEmacs (!) het er wel een stuk beter op zouden kunnen maken, maar de eerste bestaat pas net en de tweede nog helemaal niet, dus daar heb ik nog niet mee kunnen spelen .

[Anoniem: 3057]

Op zondag 02 juni 2002 16:03 schreef odysseus het volgende:
Naar mijn idee - en dan ben ik het denk ik met beelzebubu eens - is de kwaliteit van een programmeur niet af te meten aan zijn kennis van specifieke API's en dergelijke, maar veel meer aan zijn vermogen om een probleem te analyseren, in stukken op te delen en op elk onderdeel een antwoord te vinden op zo'n manier dat al die losse delen het grote probleem oplossen. Op welke manier je het daarna naar echte code vertaalt (welke taal, met welke tools) is dan meer een kwestie van smaak en van omstandigheden.
[...]

Is waar, maar vaak zal blijken dat ervaring met veel gebruikte talen / omgevingen / API's /etc., zoals SQL, XML, LDAP, e.d., je wel tot een beter programmeur maken, omdat je al geleerd hebt wat de valkuilen zijn, etc.

Als je die kennis nog niet hebt, en je moet in een project iets toepassen wat je nog nooit gedaan hebt, kost dat veel meer tijd en is de kwaliteit over het algemeen minder. Daarom is het zeker aan te raden kennis te hebben van veel gebruikte zaken.

[Soultaker]

Waarschuwing! (Deels) off-topic!

Op vrijdag 31 mei 2002 19:20 schreef Otis het volgende:
Abstraheren is afleiden.

Abstraheren is het terugbrengen van een model bestaande uit implementatiespecifieke componenten tot een model bestaande uit algemeen toepasbare componenten en begrippen.

Afleiding is deductie, hoewel ik zelf liever afleiden zeg dan deduceren (waarom moeilijk doen, als de termen equivalent zijn).

Elke goede programmeer begint het ontwerp van zijn applicaties met een abstract model en werkt dat steeds verder uit, totdat er genoeg implementatiedetails bekend zijn om de applicatie te implementeren.

Het voordeel talen die abstracte invoer toestaan, (zoals 4th level languages en declaratieve programmeertalen) is natuurlijk dat de programmeur zich het ontwerp op implementatienivo kan besparen. Dat scheelt tijd en moeite, maar gaat vaak ten koste van de uiteindelijke prestaties van de applicatie. In veel talen van hoog nivo valt code wel te optimaliseren, maar dan is de programmeur natuurlijk weer op een laag nivo bezig.

[Bananenplant]

is bottom-up werken niet de beste manier? dat zegt mijn intuïtie mij. hoewel ik een dbase-applicatie top-down aan het maken ben...

en over gebruik van andermans dingen: wat ga je doen als de programmeur daarvan met pensioen gaat? ik geloof dat ten tijde van y2k er ook een boel stokouwe software doorgespit moest worden waarbij dat het geval was...

trouwens, ik heb wel eens recursief gedroomd

maar als je een procedure van iemand anders pakt waarvan je pre- en post-condities weet lijkt het me niet dat je ineens minder slim bent dan wanneer je die procedure zelf gemaakt had.