🚀 go-pugleaf

Frans Bouma <perseus@xs4all.nl> wrote:
>     neee. Het is pas een nadeel als je er nadelige zaken van ondervindt.
>     sommigen vinden het niet hebben van een auto een voordeel, anderen
>     vinden dat een nadeel. Het is voor diegene die het voordelig vindt om
>     GEEN auto te hebben juist GEEN nadeel. 

Dat is een valse vergelijking. Ik heb geen auto. Ik vind dat inderdaad
een voordeel. Ik vind dat echter geen voordeel om het loutere feit dat
ik geen auto heb, maar omdat ik er dan geen geld aan hoef uit te geven.
Als ik morgen in een tombola het gratis gebruiksrecht op een auto win
die ik niet mag verkopen, dan doe ik met die tombolaprijs geen verlies.

Overdraagbaarheid naar andere platformen is een goede zaak, waar je
niet 'voor hoeft te betalen' zoals met de auto.

Een juiste vergelijk is deze. In de makro zie je twee hifiketens staan.
Volstrekt identiek, dezelfde prijs en alles. De ene heeft alleen tweemaal
beter geluid dan de andere. De meerderheid van de mensen zijn echter
stokdoof zodat voor hun de tweemaal slechtere geluid geen nadeel is,
ze horen het toch niet. Dat neemt echter niet weg dat de stereoketen
met beter geluid een voorbeeld blijft hebben.

Nog iets anders : stel morgen brengt Microsoft VB voor linux op de markt.
Vind je dat dan geen voordeel in het algemeen, zelfs al heb jij 
persoonlijk geen klanten die software willen draaien op linux?

>> Is dat zo? Zijn er dan echt mensen die bewust kiezen om een programma
>> te schrijven dat slechts heel moeilijk overgedragen kan worden naar
>> een ander platform? Zijn er mensen die VB verkiezen boven pakweg C++
>> omdat ze zeggen : C++ programma's hebben nog een kans op een ander
>> platform te draaien, maar met VB lopen we dat risico gelukkig niet?
>     ik heb bewust voor win32 gekozen ja. ik heb ook bewust voor VB gekozen

Het gaat er niet om voor _wat_ je gekomen hebt, maar _waarom_ je daarvoor
gekozen hebt. 

>     voor bepaalde zaken (ADO/database gerelateerde spullen). Ik heb
>     ook bewust NIET voor portabiliteitszaken gekozen. De reden voor al dit

Dat is echter iets totaal anders dan kiezen voor een platform omdat het
NIET portable was.

>     alles is dat ik het niet nuttig vindt om software te gaan maken voor een
>     ander platform dan win32, omdat a) mijn klanten daar niet mee werken 
>     b) het veel extra tijd en moeite kost om me daarin te specialiseren wat
>     resulteert in een vervlakking van de specialistische kennis die ik nu heb
>     wat resulteert in een meer allround-ik-weet-het-net-niet kennis en daar
>     pas ik voor c) ik vind (eigen mening) dat win32 platformen mbt ontwikkeltools
>     en ontwikkelmogelijkheden ver voor lopen op equivalenten. Ook vind ik
>     (eigen mening) dat bv win2000 ver voor loopt op unices omdat de filosofie
>     achter het OS en de software basis die het heeft mij veel meer aanspreken dan
>     de big iron filosofie van bv sun. 

Reden a) b) c) hebben dus inderdaad niets van doen met het portable zijn
an sich maar met heel andere zaken.

>     wat je verder niet snapt is dat er situaties zijn waarbij C++ echt niet
>     de juiste weg is (sterker, ik ken mensen die vervloeken C++ en alleen maar
>     java willen programmeren) en VB je veel meer helpt. Door dan de ogen

Dat snap ik inderdaad niet. Er zijn zeker situaties waarin C++ niet de
juiste weg is, maar die noem jij net niet op. De effort die in Java is
gestoken is imho weggegooide effort.

Waar het om gaat over VB helpen, daar ga je dus nogmaals vlotjes voorbij
aan het verschil tussen de taal en de implementatie. Niet moeilijk als
je enkel VB kent waar daar is de implementatie de taal. Maar ook daar :
dat is geen exclusiviteit. Het is perfect mogelijk een IDE te maken rond
C++ die je evenveel helpt als rond VB.

>     te sluiten en te zeggen "dat is microsoft, dat pint je vast op 1 platform,
>     dat is een slechte taal want geen goed idioom" en dan VB links te laten
>     liggen lijkt me een zwaktebod en geeft IMHO eerder aan dat je ook niet

Sorry maar ook dat is een valse redenering. Jij veroordeelt mij enkel
en alleen maar op het feit dat ik durf een kwalitatieve uitspraak te
doen. Je gaat niet in op de inhoud en mijn argumentatie maar enkel
op het feit dat ik inderdaad het een beter dan het ander vindt.
Dat noem jij dan een zwaktebod. Dat is onzinnig want dat zou betekenen
dat niemand nog een uitspraak kan doen over wat beter is dan iets
anders zonder door jou van zwaktebod beschuldigd te kunnen worden.

>     Tuurlijk, als je software maakt die portable MOET zijn omdat de DOELGROEP
>     (ja, je weet wel, de mensen die de software gaan GEBRUIKEN) dat verlangt,
>     dan is VB of win32 specifieke talen geen optie, althans niet voor zaken
>     die werkelijk portable moeten zijn. Maar "choose the right tool for the
>     job" impliceert dat automatisch.

Het enige wat je hier poneert is een argument VOOR C++. Nergens doe je
moeite om VB te verdedigen.

>> Volgens mij kiezen mensen om heel andere reden voor VB en zijn
>> ze zich ofwel niet bewust van de beperking of weegt die beperking
>> niet op tegen de voordelen die ze denken op een ander vlak te
>> krijgen (zoals bij jou het geval is).
>     hoezo? onderzoek gedaan? of persoonlijk intuitie? Waarom zou
>     iemand voor VB kiezen als hij op uni/hbo alleen maar C/C++/java
>     krijgt onderwezen. Omdat de manager het zegt? omdat de doos er
>     zo glimmend en kleurrijk uitzag?

Weetikveel. Ik vind het alleen logisch dat mensen het niet zo is dat
mensen VOOR VB gaan kiezen omdat ze redeneren : VB is NIET portable,
dus dat gaan we gebruiken. Volgens mij kiezen ze andere redenen.

>> > Hierbij is het mij juist opgevallen dat met name C++ programmeurs (en zeker
>> > die met een C achtergrond) nogal eens 'slim' willen programmeren (x== (++V=
>>                                                                     ^^^^^^^^
>> > Zv--) + (-- -Cv += Jv++)) terwijl VB en Delphi ontwikkelaars meer aandachtp
>>   ^^^^^^ ^^^^ ^^^^^^^^^^^^ 
>> Waarom heb ik zo het gevoel dat je dit uit je duim zuigt? Natuurlijk,
>> er worden dingen gebruikt door C/C++ programmeurs die _daar_op_lijken_.
>> Die voor een buitenstaander die niet met het idioom bekend is
>> misschien even 'ingewikkeld' en 'overstaanbaar' lijken, maar dat niet
>> zijn.
>     waarom lijken dingen in VB jou dan wel raar terwijl ze dat OOK niet
>     zijn?

Duh? Waar heb ik gesteld dat de dingen raar zijn in VB? Integendeel,
ik kom het dagelijks tegen en iedere week moet ik er wel iets in schrijven.

>     Verder geef ik Ben gelijk met de bovenstaande constructie. Tuurlijk is
>     het een voorbeeld, maar ik kom veel C++ code tegen vol met templates
>     en operator overloads terwijl dit totaal niet nodig is. Voor iemand

Dat is irrelevant. Mijn stelling is dat de bovenstaande codesnippet 
uit Ben zijn duim komt en onverstaanbaar is, ook voor C++ experts,
_omdat_ ze juist uit zijn duim is gezogen. Mijn stelling is dat C++
experts code die _niet_ uit de duim is gezogen wel kunnen begrijpen.

>     die niet 2 jaar van zn leven heeft gespendeerd om C++ tot in de puntjes
>     te beheersen is het onleesbaar, terwijl er makkelijkere constructies zijn
>     om het te doen. 

Ja, daar heb je gelijk. Een volledige C++ programmeur worden vergt een 
aanzienlijke
investering in tijd en moeite. Eens je dat bent heb je geen moeite met
template code en weet je perfect waar je operators wil overloaden en
waar niet, _EN_ kan je zelfs nog met code overweg die geschreven door
iemand die minder begrip had en slechtere keuzes heeft gemaakt over
wat waar gebruiken.

C++ vergt meer van de programmeur dan VB. Net zoals een radio uit
de jaren 30 minder kennis vraagt van de amateur electronicus dan 
een de laatste nieuwe high end tuner component.

Los daarvan, ben ik er zeker van dat het mogelijk is een subset te nemen
van C++, die even krachtig is als VB en die even eenvoudig aan te
leren  en te gebruiken is. Dat is een persoonlijk aanvoelen, maar
gelukkig een aanvoelen dat gedeeld wordt door heel wat andere
experts.

>     Ik kwalificeer code als:
>     if(foo(x--))
>         bar(y++);
>     als bagger. En ja ik ben bijna klaar met mn 30.000 regels tellende C/C++
>     library voor opengl programma's, dus ik programmeer echt wel eens in
>     C/C++. Dat jij het bovenstaande wellicht efficient vindt, zal best, 
>     ik vind het onleesbaar. 

Persoonlijk zou ik zoiets ook niet schrijven, maar ik begrijp totaal
niet wat jij daar onleesbaar aan vindt. Het enige wat ik onleesbaar
vindt is foo en bar en het feit dat er geen context gegeven is
voor deze twee regels. Al de rest is perfect duidelijk. 
Kan jij mij eens uitleggen wat hier nu zo onleesbaar aan is?

Ik weet het al : volgens mij heb jij dat stuk code neergeschreven
zonder aan een echt probleem te denken dat iemand zou willen oplossen.
Je hebt gewoon hetzelfde als de eerste poster gedaan, alleen minder
duidelijk, je hebt de zaak plausibeler gemaakt. Of aan welk probleem
heb je dan wel gedacht?

Persoonlijk vind ik bijvoorbeeld

a = a+m((i*xm)+j)*n(((i+ii)*xm)+i+j)

bijvoorbeeld erger en dat is wel _echte_ code, waar ik specifiek aan 
een probleem heb gedacht en dan een regel uit de oplossing daarvan
heb gegeven (het gaat hier om de convolutie van twee matrixen).

O ja : en het bovenstaande is geldige VB (en C++) code.

>     Dat is niet erg, echter de kwaliteit van de TAAL af laten hangen van
>     wat onverlaten er mee bouwen vind ik wel erg. En dat is precies wat
>     hier gebeurd: VB wordt door de mangel gehaald met argumenten die echt
>     kant noch wal raken in veel gevallen, resulterend in gebrabbel over
>     taalkwaliteit die terug te herleiden is aan de kwaliteit van de 
>     programmeur niet de taal. 

Sorry, maar dat heb je in mijn post verkeerd gelezen. Ik maak een
verdediging van iemand die C++ aanvalt op basis van wat een onverlaat
in C++ zou kunnen schrijven. Zelf heb ik VB nooit aangevallen op basis
van wat onverlaten er in kunnen schrijven. Ik val VB aan op basis
van wat men er _niet_ in kan schrijven.

>     ik zou bv het bovenstaande opschrijven als:

>         x--;
>         if(foo(x))
>         {
>             y++;
>             bar(y);
>         }

Persoonlijk vind ik dat je weinig gewonnen hebt. Maar dat is een
oordeel van wat leesbaar en schoon is, en heeft an sich niets met
de voor- of nadelen van een taal te maken.

>     o gottegod, allerlei optimalisaties weggehaald, extra regels code 
>     toegevoegd... ja inderdaad. Nu kan er nl. commentaar bij, staan er
>     goede brackets om de true clause van de if en worden variabelen
>     op hun eigen regels bewerkt. 2 stukken code van dezelfde taal.
>     Wel van verschillende kwaliteit, ik laat in het midden welke de
>     beste kwaliteit bevat. Dat is immers relatief. Zo is het

Ongetwijfeld, maar dat had je moeten zeggen op de kerel die _mij_
confronteerde met een stukje code dat zogezegde onverlaten in C++
zouden kunnen schrijven.

Zijn we het erover eens dat het criterium is : welke goede code kan
ik in taal X schrijven eerder dan welke slechte code kan ik in
taal X schrijven?

cu bart