🚀 go-pugleaf

johan.vervloet@gmail.com <johan.vervloet@gmail.com> wrote:
> Mag ik jullie mening eens vragen over volgende stelling:
>
> Wat ik zeker wil aanhalen is van *NOOIT* administratieve (LOB) applicaties
> te ontwikkelen in C++, ook al is dat in een bepaalde open source niche de
> gewoonte. De drempel voor C++ is gewoon erg hoog, er kunnen veel te veel
> fouten gemaakt worden, resource handeling is erg intensief, C++ is _niet_
> RAD,... enz

Vertaling: Je vindt C++ ongeschikt omdat C++ developers met de juiste en/of
voldoende ervaring te duur zijn?

 - Philip

-- 
Philip Paeps                              Please don't email any replies
philip@paeps.cx                               I follow the newsgroup.

  Rincewind had always been happy to think of himself as a racist.
  The One Hundred Meters, the Mile, the Marathon -- he'd run them
  all.
  	-- (Terry Pratchett, The Last Continent)

Voor alle duidelijkheid: de stelling strookt niet met mijn persoonlijke
mening.

Philip Paeps wrote:
> Vertaling: Je vindt C++ ongeschikt omdat C++ developers met de juiste en/of
> voldoende ervaring te duur zijn?
> 
>  - Philip
> 


Slechte vertaling vind ik.
Het is niet omdat iemand de juiste kennis en ervaring bezit om deftig 
programma's te maken in c++, dat deze taal dan ook aangewezen valt om 
daarin bepaalde types software te maken.
Hoe goed iemand ook programmeert, fouten worden altijd gemaakt.

Het lijkt me dus voor administratieve programma's verstandiger om een 
taal te kiezen die garbage collection doet, zodat de programmeur daar al 
niet aan moet denken, en daar ook al geen fouten mee kan maken.

Persoonlijk geef ik de voorkeur aan een taal als c# of java voor 
niet-rekenintensieve programma's.

Johan schreef:

> Wat ik zeker wil aanhalen is van *NOOIT* administratieve (LOB)
> applicaties te ontwikkelen in C++, ook al is dat in een bepaalde
> open source niche de gewoonte.

Een stelling waar ik 100% mee akkoord ga.

The right tool for the right job.

Steven

- - -

Johan schreef:

> Voor alle duidelijkheid: de stelling strookt niet met mijn persoonlijke
> mening.

Nee?

Voor een administratief pakket wil ik me focussen op de kern van het 
probleem zonder veel rekening te moeten houden met de mogelijk valkuilen van 
de gebruikte taal. En in C++ zijn die talrijker dan bv Java.

De stelling verder doorgetrokken: ga jij een administratief pakket maken in 
assembler?

Steven

- - -

Steven Spits <nospam@company.com> wrote:
> Johan schreef:
> > [C++ ongeschikt voor administratieve software]
> > Voor alle duidelijkheid: de stelling strookt niet met mijn persoonlijke
> > mening.
>
> Nee?

Ook niet met de mijne -- maar daar kijk je waarschijnlijk niet van op. :-)

> Voor een administratief pakket wil ik me focussen op de kern van het
> probleem

Je focussen op de kern van het probleem, lijkt me van toepassing in het even
waar je software voor schrijft.  Verschillende talen maken dat focussen in
meer of mindere zin "eenvoudiger", maar of ze daardoor (alleen) beter geschikt
zijn dan andere talen, vind ik wat zwakjes gesteld.

> zonder veel rekening te moeten houden met de mogelijk valkuilen van de
> gebruikte taal. En in C++ zijn die talrijker dan bv Java.

Dat hangt sterk af van wat precies de toepassing moet doen.  Het aantal
'valkuilen' dat een taal heeft, hangt ook meer af van de developer dan van de
taal zelf.

> De stelling verder doorgetrokken: ga jij een administratief pakket maken in
> assembler?

Ik ga geen administratief pakket maken. ;-)  Voor kritische toepassingen zou
ik echter steeds voor een native taal gaan dan voor een "interpreted" of
"managed" taal (oppassen dat ik het geen "scripttaal" noem, of ik krijg John
op mijn ketel ;-)) -- one less thing that can go wrong (at run/deployment
time).

 - Philip

-- 
Philip Paeps                              Please don't email any replies
philip@paeps.cx                               I follow the newsgroup.

  Some people manage by the book, even though they
  don't know who wrote the book or even what book.

wem <wim.robijn@telenet.be> wrote:
> Philip Paeps wrote:
> > Vertaling: Je vindt C++ ongeschikt omdat C++ developers met de juiste
> > en/of voldoende ervaring te duur zijn?
>
> Slechte vertaling vind ik.

Het is een interpretatie.

> Het is niet omdat iemand de juiste kennis en ervaring bezit om deftig
> programma's te maken in c++, dat deze taal dan ook aangewezen valt om daarin
> bepaalde types software te maken.  Hoe goed iemand ook programmeert, fouten
> worden altijd gemaakt.

Sure, daarom heb je unit testing, coverage testing, code review, interne
testing, externe testing, enz...

> Het lijkt me dus voor administratieve programma's verstandiger om een taal
> te kiezen die garbage collection doet, zodat de programmeur daar al niet aan
> moet denken, en daar ook al geen fouten mee kan maken.

Garbage collection is ��n van de taken van de developer.  Als er garbage in je
applicatie rondslingert, is er iets fundamenteel fout aan de hand.  Het is
gewoon ��n van de dingen waar je over na moet denken als je ontwerpt en code.
In een goed doordachte en goed gestructureerde applicatie heb je geen garbage.

 - Philip

-- 
Philip Paeps                              Please don't email any replies
philip@paeps.cx                               I follow the newsgroup.

  Any technical problem can be overcome given enough
  time and money.

"wem" <wim.robijn@telenet.be> wrote in message 
news:MUH3g.392551$rL2.10989599@phobos.telenet-ops.be...

Oh leuk, flamebait! :-)

> Het is niet omdat iemand de juiste kennis en ervaring bezit om deftig 
> programma's te maken in c++, dat deze taal dan ook aangewezen valt om 
> daarin bepaalde types software te maken.
> Hoe goed iemand ook programmeert, fouten worden altijd gemaakt.
Het hangt toch 95% af van waar je als programmeur ervaring in hebt. Mijn 
laatste C++ memory leak is _heel_ lang geleden (templates en smart pointers 
halen een hoop problemen weg, en daarnaast goed gebruik van de stack en RAII 
voor de rest van de problemen - Access violations zijn een groter probleem, 
want zelfs met de STL kun je jezelf daarmee nog redelijk snel in de vingers 
snijden als je een iterator misbruikt.

Ik zou meer fouten maken in Java dan C++, ook al heb ik garbagecollectie, 
want puur het feit dat ik iets op de stack plaats betekent niet dat het ook 
automatisch weg is na het einde van de functie: references kunnen op elk 
moment ontsnappen en je moet altijd opletten als je iets by reference (dat 
is toch de enige manier in java?) aan een functie doorgeeft: die kan zomaar 
een reference nemen naar je data en ga dan maar eens het probleem zoeken als 
het geheugengebruik oploopt ondanks dat er formeel geen memory leak is. In 
C++ is de lifetime van objecten een stuk expliciter, en hoef ik me geen 
zorgen te maken over 'finalizatie'.

Nou zal een ervaren Java programmeur roepen dat dat allemaal niet zo'n 
probleem is en dat ik gewoon de taal niet goed begrijp of verkeerd gebruik. 
Precies wat ik zou zeggen over de meeste anti-C++ argumenten :)

> Het lijkt me dus voor administratieve programma's verstandiger om een taal 
> te kiezen die garbage collection doet, zodat de programmeur daar al niet 
> aan moet denken, en daar ook al geen fouten mee kan maken.
>
> Persoonlijk geef ik de voorkeur aan een taal als c# of java voor 
> niet-rekenintensieve programma's.
En precies, dat is persoonlijk. In de taal die je goed kent maak je minder 
fouten dan in talen die je slecht kent. De kwaliteiten en de uitgebreidheid 
van de taal bepalen wel mede hoe lang het duurt voor je een taal goed kent 
(maar in een taal als C++ duurt het misschien langer voordat je hem echt 
onder de knie hebt, je krijgt er imho ook veel meer voor terug) 

Philip Paeps <philip+usenet@paeps.cx> wrote:

> Steven Spits <nospam@company.com> wrote:

[ .. ]

>> De stelling verder doorgetrokken: ga jij een administratief pakket
>> maken in assembler?
> 
> Ik ga geen administratief pakket maken. ;-)  Voor kritische
> toepassingen zou ik echter steeds voor een native taal gaan dan voor
> een "interpreted" of "managed" taal (oppassen dat ik het geen
> "scripttaal" noem, of ik krijg John op mijn ketel ;-)) -- one less
> thing that can go wrong (at run/deployment time).

In een grijs verleden was er een bedrijf dat vzviw een compleet DTP pakket 
in assembly had geschreven voor de Acorn Archimedes. Het kan wel, maar het 
vergt mensen met verstand van zaken, en wellicht een soort macro taaltje 
(De ZX Spectrum had ooit een assembler met een soort Forth er boven op).

Voordeel - rap en compact (900K of zo)
Nadeel - het knalde er wel eens uit met een vage fout.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"John Bokma" schreef:

> Voordeel - rap en compact (900K of zo)
> Nadeel - het knalde er wel eens uit met een vage fout.

Nadeel - inmens duur aan loonkost.

Steven

- - -

"Philip Paeps" schreef:

> Ook niet met de mijne -- maar daar kijk je waarschijnlijk niet van op. :-)

Nee, ik vroeg me zelfs al af waar je bleef.

Ik ben een kattenmens, jij hebt thuis wel ��n of andere hond rondlopen 
vermoed ik?

> Je focussen op de kern van het probleem, lijkt me van toepassing in het 
> even
> waar je software voor schrijft.  Verschillende talen maken dat focussen in
> meer of mindere zin "eenvoudiger", maar of ze daardoor (alleen) beter 
> geschikt
> zijn dan andere talen, vind ik wat zwakjes gesteld.

Hoe meer je je kan focussen op de kern van het probleem, hoe robuster je 
software wordt. Wat je gaat maken bepaalt voor een stuk waarin je het gaat 
maken.

> Dat hangt sterk af van wat precies de toepassing moet doen.  Het aantal
> 'valkuilen' dat een taal heeft, hangt ook meer af van de developer dan van 
> de
> taal zelf.

HRM is het zoeken van de gulden middenweg. Je hebt nooit een team van 
perfecte programmeurs. Dus hoe minder mogelijke valkuilen, hoe beter.

> Ik ga geen administratief pakket maken. ;-)

Zeg nooit nooit...

> Voor kritische toepassingen zou ik echter steeds voor een native taal gaan
> dan voor een "interpreted" of "managed" taal.

Ik zie niet in waarom niet. Dat heeft ook z'n voordelen.

Steven

- - -

Steven Spits <nospam@company.com> wrote:
> Philip Paeps schreef:
> > Ook niet met de mijne -- maar daar kijk je waarschijnlijk niet van op. :-)
>
> Nee, ik vroeg me zelfs al af waar je bleef.

 :-)

> Ik ben een kattenmens, jij hebt thuis wel ��n of andere hond rondlopen
> vermoed ik?

Ik heb in theorie twee katten.  In de praktijk beschouwen een stuk of vier
katten mij als hun huisdier.  Allemaal een kwestie van perspectief, uiteraard.
Maar aan honden doe ik in ieder geval niet mee.

 - Philip

-- 
Philip Paeps                              Please don't email any replies
philip@paeps.cx                               I follow the newsgroup.

  The chance of a piece of bread falling with the buttered
  side down is directly proportional to the cost of the
  carpet.

"Philip Paeps" schreef:

> Ik heb in theorie twee katten.  In de praktijk beschouwen een stuk of vier
> katten mij als hun huisdier.  Allemaal een kwestie van perspectief, 
> uiteraard.
> Maar aan honden doe ik in ieder geval niet mee.

Mijn god, hoe klein de doorsnede van onze werelden ook mag zijn, ze bestaat 
wel degelijk! :-)

Zelf ben ik het huisdier van ��n kat, Artiglio genaamd. Die naam is 
overigens niet zomaar gekozen!

Steven

- - -

Philip Paeps wrote:
> Sure, daarom heb je unit testing, coverage testing, code review, interne
> testing, externe testing, enz...
> 

Die helpen allen zeker bij het ontdekken van fouten, maar helpen niet 
bij het voorkomen van fouten.
Elke verantwoordelijkheid die de computer dus van de programeur kan 
overnemen, is iets waar minder fouten bij gemaakt kan worden, en daar 
draait het hier toch om, niet?

> Garbage collection is ��n van de taken van de developer.  Als er garbage in je
> applicatie rondslingert, is er iets fundamenteel fout aan de hand.  Het is
> gewoon ��n van de dingen waar je over na moet denken als je ontwerpt en code.
> In een goed doordachte en goed gestructureerde applicatie heb je geen garbage.
> 

Waarom is garbage collection een van de taken van de developer?  Ik zie 
niet in waarom dat zo moet zijn, integendeel.
In sommige gevallen zal de developer inderdaad beter dan de VM weten 
wanneer iets al vrijgegeven kan worden, maar in vele gevallen, bv. in 
administratieve programma's, lijkt me de overhead zo minimaal, dat er 
hierdoor geen problemen ontstaan.

En als je bij je design dus ook al niet meer aan garbage collection moet 
denken, heb je weer wat denkvermorgen meer vrij om aan het echte design 
te werken.

Maar als je een goed design maakt, zou garbage collection inderdaad geen 
probleem mogen vormen.

Arnold Hendriks wrote:
> Het hangt toch 95% af van waar je als programmeur ervaring in hebt. Mijn 
> laatste C++ memory leak is _heel_ lang geleden (templates en smart pointers 
> halen een hoop problemen weg, en daarnaast goed gebruik van de stack en RAII 
> voor de rest van de problemen - Access violations zijn een groter probleem, 
> want zelfs met de STL kun je jezelf daarmee nog redelijk snel in de vingers 
> snijden als je een iterator misbruikt.
> 
> Ik zou meer fouten maken in Java dan C++, ook al heb ik garbagecollectie, 
> want puur het feit dat ik iets op de stack plaats betekent niet dat het ook 
> automatisch weg is na het einde van de functie: references kunnen op elk 
> moment ontsnappen en je moet altijd opletten als je iets by reference (dat 
> is toch de enige manier in java?) aan een functie doorgeeft: die kan zomaar 
> een reference nemen naar je data en ga dan maar eens het probleem zoeken als 
> het geheugengebruik oploopt ondanks dat er formeel geen memory leak is. In 
> C++ is de lifetime van objecten een stuk expliciter, en hoef ik me geen 
> zorgen te maken over 'finalizatie'.
> 
> Nou zal een ervaren Java programmeur roepen dat dat allemaal niet zo'n 
> probleem is en dat ik gewoon de taal niet goed begrijp of verkeerd gebruik. 
> Precies wat ik zou zeggen over de meeste anti-C++ argumenten :)

Veel hangt inderdaad af van de ervaring van de mens die het maakt.
Maar neem even iemand die begint met programmeren, en dus nog in geen 
taal ervaring heeft, en deze administratieve programma's wilt maken.
Is het dan niet "beter" om deze niet met de lasten van zelf je geheugen 
op te ruimen lastig te vallen?
Uiteraard is een goed inzicht in het gebruik van het geheugen belangrijk 
bij het maken van programma's, maar om daar elke keer bij het 
programmeren met je neus op gedrukt te moeten worden???


> En precies, dat is persoonlijk. In de taal die je goed kent maak je minder 
> fouten dan in talen die je slecht kent. De kwaliteiten en de uitgebreidheid 
> van de taal bepalen wel mede hoe lang het duurt voor je een taal goed kent 
> (maar in een taal als C++ duurt het misschien langer voordat je hem echt 
> onder de knie hebt, je krijgt er imho ook veel meer voor terug) 
> 

Toen ik een klein jaar geleden aan mijn jaarproject begon had ik geen 
ervaring in C#, en wel al wat in c++.
Toch hebben we voor C# gekozen, en ik betreur deze beslissing echt niet, 
integendeel.  De extra's die c++ bood waren dan ook niet nodig, en enkel 
extra ballast.
In uitbreiding van "use the right tool for the right job", vind ik dus 
ook dat het volgende geldt: "use the right language for the right job".

"Steven Spits" <nospam@company.com> wrote:

> "John Bokma" schreef:
> 
>> Voordeel - rap en compact (900K of zo)
>> Nadeel - het knalde er wel eens uit met een vage fout.
> 
> Nadeel - inmens duur aan loonkost.

Hoe hoog inmens is hangt af van wie er werkt. Ik gok dat het ontwikkelteam 
extreem goed in assembly was. Plus dat ik gok dat ze nogal wat 
codegeneratie gebruikte.

Plus dat er ontwikkelt moest worden voor machines met minimaal 1M aan 
geheugen. (Die 900K was geloof ik de complete installatie, weet niet meer 
of het ook echt op een 1M machine werkte, andere machines hadden 2M of 
4M).

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"Steven Spits" <nospam@company.com> wrote:

> "Philip Paeps" schreef:
> 
>> Ik heb in theorie twee katten.  In de praktijk beschouwen een stuk of
>> vier katten mij als hun huisdier.  Allemaal een kwestie van
>> perspectief, uiteraard.
>> Maar aan honden doe ik in ieder geval niet mee.
> 
> Mijn god, hoe klein de doorsnede van onze werelden ook mag zijn, ze
> bestaat wel degelijk! :-)

Ik vind honden ook niks :-D En dan val je hier wel een beetje uit de toon 
:-D

> Zelf ben ik het huisdier van ��n kat, Artiglio genaamd. Die naam is 
> overigens niet zomaar gekozen!

Ik had er 2, nu ff geen, omdat er gewoon geen ruimte voor is. Maar goed, 
dat compenseer ik weer met echt vreemde beesten :-p

<http://toxicice.com/images/r0303875.jpg>

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

wem <wim.robijn@telenet.be> wrote:
> Philip Paeps wrote:

> Die helpen allen zeker bij het ontdekken van fouten, maar helpen niet 
> bij het voorkomen van fouten.
> Elke verantwoordelijkheid die de computer dus van de programeur kan 
> overnemen, is iets waar minder fouten bij gemaakt kan worden, en daar 
> draait het hier toch om, niet?

Ik geloof daar niet zo in. 

>> Garbage collection is ��n van de taken van de developer.  Als er
>> garbage in je applicatie rondslingert, is er iets fundamenteel fout
>> aan de hand.  Het is gewoon ��n van de dingen waar je over na moet
>> denken als je ontwerpt en code. In een goed doordachte en goed
>> gestructureerde applicatie heb je geen garbage. 
> 
> Waarom is garbage collection een van de taken van de developer?  Ik
> zie niet in waarom dat zo moet zijn, integendeel.

Ben het met beiden eens: in een goed doordachte applicatie zou 
geheugenlekken niet op mogen treden. Het rotte is dat ook met garbage 
collectie het mogelijk is (en soms kan je met dingen als een circulaire 
lijst ook jezelf in de voet schieten).

Het is dus niet zo dat een techniek een domme programmeur kan beschermen, 
die domme programmeur vind wel iets anders om om zeep te helpen. En anders 
helpen echte programmeurs (TM) 'm daar wel bij, want die voelen zich 
gekort, en roepen dan om technieken als weak references. Dus niet 1 maar 2 
pistolen voor de domme programmeur.

> Maar als je een goed design maakt, zou garbage collection inderdaad
> geen probleem mogen vormen.

In de praktijk komt dat dus wel voor.

Een programmeur beschermen doet mij sinds kort denken aan een van de 
laatste afleveringen van Lost (1e seizoen), waar een scheikunde 
(natuurkunde) leraar een hele preek houd over de inmense gevaren van 
zwetende dynamiet, en aan het einde eventjes met zijn hand gebaard voor de 
extra nadruk.

Nu, die nadruk was er... oorverdovend.


Hey Jack, I think you got a piece of Artz on you. (classic)

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

wem <wim.robijn@telenet.be> wrote:
>  Arnold Hendriks wrote:

[ .. ]

> Veel hangt inderdaad af van de ervaring van de mens die het maakt.
> Maar neem even iemand die begint met programmeren, en dus nog in geen 
> taal ervaring heeft, en deze administratieve programma's wilt maken.
> Is het dan niet "beter" om deze niet met de lasten van zelf je
> geheugen op te ruimen lastig te vallen?

Die persoon wil ik *zeker* lastig vallen met geheugen, pointers 
(references), en hoe gc *werkt*. Om te voorkomen dat zo iemand een 
applicatie in elkaar zet die vreselijk slecht met geheugen om gaat.

Met gc kan je geheugen hergebruiken, of eerder los laten. Dingen om te 
weten.

> Uiteraard is een goed inzicht in het gebruik van het geheugen
> belangrijk bij het maken van programma's, maar om daar elke keer bij
> het programmeren met je neus op gedrukt te moeten worden???

Het is niet anders. Ditto met andere resources. Als alles maar in een 
zwart doosje om de hoek gebeurd gaan mensen zelf verzinnen hoe dat doosje 
werkt. Te veel mensen programmeren trail and error, en gokken hoe iets 
werkt in plaats van de documentatie door te lezen.

>> En precies, dat is persoonlijk. In de taal die je goed kent maak je
>> minder fouten dan in talen die je slecht kent. De kwaliteiten en de
>> uitgebreidheid van de taal bepalen wel mede hoe lang het duurt voor
>> je een taal goed kent (maar in een taal als C++ duurt het misschien
>> langer voordat je hem echt onder de knie hebt, je krijgt er imho ook
>> veel meer voor terug) 

Kan het niet laten:
http://www.norvig.com/21-days.html

> In uitbreiding van "use the right tool for the right job", vind ik dus
> ook dat het volgende geldt: "use the right language for the right
> job". 

Als je een language gewoon ook als een tool ziet, ben je er.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"John Bokma" <john@castleamber.com> wrote in message 
news:Xns97B27EA80B3Ccastleamber@130.133.1.4...
>>  Arnold Hendriks wrote:
>>> En precies, dat is persoonlijk. In de taal die je goed kent maak je
>>> minder fouten dan in talen die je slecht kent. De kwaliteiten en de
>>> uitgebreidheid van de taal bepalen wel mede hoe lang het duurt voor
>>> je een taal goed kent (maar in een taal als C++ duurt het misschien
>>> langer voordat je hem echt onder de knie hebt, je krijgt er imho ook
>>> veel meer voor terug)
>
> Kan het niet laten:
> http://www.norvig.com/21-days.html
Die Alan Perlis quote is leuk.

In '97, toen ik een jaartje Informatica deed, zat in het curriculum van de 
universiteit twente het vak functioneel programmeren, met Miranda. Hoeveel 
programmeerervaring je ook dacht te hebben met Basic, Pascal en C (en dacht 
te denken: ik weet het allemaal wel), een functionele taal is een 
behoorlijke eye-opener: het kan ook echt totaal anders.

Dat vak hebben ze inmiddels geschrapt. En dat is jammer, want dan missen een 
hoop mensen toch wat horizonverbreding: men denkt nu weer dat elke taal 
praktisch hetzelfde is met slechts een ander syntax-sausje. Waardoor je 
toch, naar mijn mening, een hoop creativiteit verliest betreffende op 
hoeveel verschillende manieren je een probleem aan kunt pakken. 

"Arnold Hendriks" <a.hendriks@student.utwente.nl> wrote:

> "John Bokma" <john@castleamber.com> wrote in message 
> news:Xns97B27EA80B3Ccastleamber@130.133.1.4...
>>>  Arnold Hendriks wrote:
>>>> En precies, dat is persoonlijk. In de taal die je goed kent maak je
>>>> minder fouten dan in talen die je slecht kent. De kwaliteiten en de
>>>> uitgebreidheid van de taal bepalen wel mede hoe lang het duurt voor
>>>> je een taal goed kent (maar in een taal als C++ duurt het misschien
>>>> langer voordat je hem echt onder de knie hebt, je krijgt er imho
>>>> ook veel meer voor terug)
>>
>> Kan het niet laten:
>> http://www.norvig.com/21-days.html
> Die Alan Perlis quote is leuk.
> 
> In '97, toen ik een jaartje Informatica deed, zat in het curriculum
> van de universiteit twente het vak functioneel programmeren, met
> Miranda. Hoeveel programmeerervaring je ook dacht te hebben met Basic,
> Pascal en C (en dacht te denken: ik weet het allemaal wel), een
> functionele taal is een behoorlijke eye-opener: het kan ook echt
> totaal anders.

Yup, zeker (ook Miranda gehad, UU). Ik weet nog goed dat sommige 
klasgenoten er gewoon niet mee overweg konden, terwijl het een extreem 
natuurlijke notatie is (voor mij dan). Ikzelf had weer moeite met Prolog, 
wellicht ook omdat ik gewoon geen interesse er in had op dat moment.

> Dat vak hebben ze inmiddels geschrapt. En dat is jammer, want dan
> missen een hoop mensen toch wat horizonverbreding: men denkt nu weer
> dat elke taal praktisch hetzelfde is met slechts een ander
> syntax-sausje.

Yup. Ik hoor nogal eens: Perl? Waarom doe je geen PHP, is toch hetzelfde?
Of Java? C# leer je dan in een week. Ik weet beter, gelukkig :-D.

> Waardoor je toch, naar mijn mening, een hoop
> creativiteit verliest betreffende op hoeveel verschillende manieren je
> een probleem aan kunt pakken. 

Ik heb vandaag Higher-Order Perl [1] ontvangen (gekregen in ruil voor hulp 
met (Perl) huiswerk :-p). Dus ja, eens.

[1] http://www.amazon.com/exec/obidos/tg/detail/-/1558607013/

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Op Thu, 27 Apr 2006 10:44:28 +0200, schreef Steven Spits:

> "John Bokma" schreef:
> 
>> Voordeel - rap en compact (900K of zo)
>> Nadeel - het knalde er wel eens uit met een vage fout.
> 
> Nadeel - inmens duur aan loonkost.

Veel van die assembler programma's indertijd werden door een klein team van
enkele mensen gemaakt in een paar maanden.  Lijkt me een stuk goedkoper
dan 6 jaar lang honderden C++ developers aan Vista te laten prutsen...  ;-)


-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

"JanC" <usenet@janc.invalid> wrote:

> Op Thu, 27 Apr 2006 10:44:28 +0200, schreef Steven Spits:
> 
>> "John Bokma" schreef:
>> 
>>> Voordeel - rap en compact (900K of zo)
>>> Nadeel - het knalde er wel eens uit met een vage fout.
>> 
>> Nadeel - inmens duur aan loonkost.
> 
> Veel van die assembler programma's indertijd werden door een klein
> team van enkele mensen gemaakt in een paar maanden.  Lijkt me een stuk
> goedkoper dan 6 jaar lang honderden C++ developers aan Vista te laten
> prutsen...  ;-) 

Veel 1 persoons kajaks worden gemaakt door 1 of 2 personen. Lijkt mij een 
stuk goedkoper dan een Titanic bouwen (en nog eens laten zinken ook).

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

wem wrote:
> Arnold Hendriks wrote:
> 
> Toen ik een klein jaar geleden aan mijn jaarproject begon had ik geen 
> ervaring in C#, en wel al wat in c++.
> Toch hebben we voor C# gekozen, en ik betreur deze beslissing echt niet, 
> integendeel.  De extra's die c++ bood waren dan ook niet nodig, en enkel 
> extra ballast.
> In uitbreiding van "use the right tool for the right job", vind ik dus 
> ook dat het volgende geldt: "use the right language for the right job".


Use the right person for the right language.

Vele bedrijven die van Cobol overgeschakeld zijn naar C en/of C++, 
hebben hun programmeurs een herscholing van enkele uurtjes gegeven.
En het zijn die bedrijven die nu hun gal uitspuwen over C en/of C++.

--
  Kristoffel