🚀 go-pugleaf

"Niels Basjes" <Dont@mail.me.nl> wrote in message news:59lu5tcpsbp7oopd87p5n9ho5uu3fdr8r7@4ax.com...
> The life form known as "Bert Rozenberg" <sysop@ringtwice.com> wrote:
> >al of niet met VB. 
> 
> Ik classificeer de meeste commerciele code die ik onder ogen krijg tot
> prutswerk, en dan kijk ik niet naar de taal maar de manier van coderen en
> de onderhoudbaarheid van die code. Dat laatste kun je namelijk wel vergeten
> als je "incrementeel prototypend" werkt.

    wat weet jij van de doelstellingen van die commerciele code? veel of 
    weinig? welke doelen waren belangrijk? en zijn dat dezelfde doelen
    als die jij ziet als belangrijk? alleen indien 'ja' kun je de code
    kwalificeren als 'goed' of 'slecht' omdat je kunt zien of ze de
    doelen die belangrijk waren hebben gehaald met deze code of niet.

    In elke andere situatie kun je dat botweg niet, omdat je je EIGEN belangen
    en doelen als 'belangrijk' stelt en tegen DIE belangen en doelen de
    code houdt. Ja dan kan het wel eens raar aflopen met die code.

    Incrementeel prototypen is een methode, net zoals evolutionaire software
    ontwikkeling dat is, of OOP. Je vergeet dat veel mensen maar denken
    dat een stuk software ALTIJD voor eeuwig bestaan moet blijven. Als
    een bedrijf een oplossing nodig heeft voor de communicatie tussen 3
    legacy systemen, dan hebben ze die oplossing, wanneer die legacy systemen
    verdwijnen NIET meer nodig. Als dat gepland staat over 2 jaar, dan is je
    software hooguit van belang voor 2 jaar. Ga je het dan opzetten zodat
    het tot in den treure kan worden aangepast? denk het niet. is nl. verspilde
    moeite. Hetzelfde met software voor veel kantoorautomatisering. op DIT
    moment wil de klant dit en dit geautomatiseerd zien, maar wellicht is over
    5 jaar alles wel outsourced on line. Is je huidige range van software DAN
    nog inzetbaar? 10 tegen 1 van niet. Tuurlijk de logica wel, maar als je
    nu aan een fat-client omgeving werkt is dat DAN niet nuttig meer.
    Je kunt daarmee rekening houden in je software. Immers: erg veel ontwikkelen
    kost erg veel tijd en dus geld. Terwijl je dat wellicht NOOIT terugverdient.
    want als een programma een ton meer kost omdat het dan uitbreidbaar is
    in geval van [insert reason here], weet die klant dan dat hij iig
    MEER dan die ton terugverdient OMDAT het flexibel is? nee. Wellicht is
    hij die ton gewoon kwijt. Of kosten aanpassingen in de toekomst maar
    10.000,-. Schiet hij er wel 90.000,- bij in.

    Vanuit de schoonheid van het vak, ja dan heb je gelijk. Alleen dat
    is lang niet altijd de belangrijkste factor. Wellicht wel in spullen
    die je zelf ontwikkelt en online zet, maar niet in commerciele
    producten. Je gaat hieraan voorbij IMHO en dat is jammer.

> >Het tegenovergestelde is namelijk
> >waar: doordat je met VB minder tijd kwijt bent met het inkloppen van
> >cryptische code, blijft er meer tijd over om meer na te denken over wat je
> >maakt.
> 
> Als je eerst nadenkt over _wat_ je gaat maken dan maakt de taal niet meer
> uit. Ik ben zelf een C++ adept en maak het de hoogste prioriteit dat mijn
> code 1) echt eerst ontworpen is en 2) goed portable is naar vele platforms
> en dat je dus zonder al te veel effort van OS kan switchen, van Linux naar
> Windows naar Solaris en weer terug. Als je voor VB kiest dat je gedwongen
> bent om op Windows te blijven werken.

    nou EN. Dat is voor jou van belang, niet voor mij. Verder is punt 1)
    altijd belangrijk maar 2) niet altijd. 

    kies de taal die je in een bepaalde situatie voordeel oplevert. als dat
    in 1 project EN T-SQL is EN VB EN VBScript EN XSLT EN C++ dan doe je dat,
    dan kies je niet _ALLEEN_ maar voor C++. De taal is te allen tijd
    ondergeschikt aan wat je gaat maken zoals je zegt, dus VB kan een zeer
    goede oplossing zijn, evenals C++. Of APL of ADA of Delphi of Perl.
    
> >Ontwikkelen van software doe je niet met de computer, maar in je hoofd of op
> >een stuk papier. De computer gebruik je uitsluitend om de uitgedokterde
> >structuren en algoritmes in te kloppen, en daar heb je met VB- of
> >Powerbuilder-achtige programmeeromgevingen weinig tijd voor nodig. 
> 
> Is zo'n algorithme dat efficient ? Is het portable naar andere systeem
> architecturen ? Of ben je alleen een GUI aan het bouwen ?

    Niels, hou eens op met dat gedram over portabiliteit naar andere platforms.
    90% van de desktops draait windows. Als je client oriented software maakt
    en je gebruikt geen webinterface kom je vrij snel op windows uit. als al
    je klanten windows gebruiken omdat ze ook office gebruiken dan is portabiliteit
    een non-issue. dat dat voor jou wel belangrijk is vind ik fijn voor je maar
    leef je aub eens in in de situatie van een ander. Er zijn veel ontwikkelaars
    die _NOOIT_ een ander OS zien dan windows systemen. Die waarschijnlijk
    nog nooit een AS/400 hebben gezien of alleen op uni/hbo op unix hebben
    gewerkt. Denk je nu werkelijk dat die mensen met portabiliteit als een
    van hun hoofdmotieven rondlopen? nee natuurlijk niet. Als je mbv COM+/
    ADO/SQLserver zeer solide systemen maakt, waarom moet je dan overstappen
    naar een equivalent, omdat het toevallig portable is? en wat als je daar
    nooit mee te maken krijgt? 

> >In de
> >praktijk levert dit vaak betere programma's op dan de software van die
> >programmeurs die zoveel tijd nodig hebben met het inkloppen van de code dat
> >ze geen tijd hebben om het e.e.a. goed te overdenken.
> 
> De meeste VB/Deplhi/J-Builder/etc. programmeurs zijn die personendie zo
> lekker incrementeel prototypend werken. ..... onderhoudbaar ? Nee, maar het
> is wel lekker snel klaar.

    Lekkere visie heb jij Niels. Omdat je zelf met C++ werkt vind je jezelf
    een hele guru? plaats je jezelf boven het klootjesvolk wat maar wat 
    aankloot in IDE's die al het werk voor je doen?

    Waar baseer je je bovenstaande trollopmerking op, Niels? op eigen
    gedegen onderzoek? Waaruit ook bleek hoe GOED C++ programmeurs zijn?
    
    Als ik jouw teksten zo lees, kan ik me niet aan de indruk onttrekken
    dat je EN vol zit met vooroordelen over mensen die je niet kent EN
    jezelf een kwaliteitspluim dient te geven om maar kwalitatief goed over
    te komen EN je niet doorhebt dat een 'goede' programmeur niet afhangt
    hoe veel hij onderhoudbaarheid inpast in zn programmatuur maar hoe
    goed hij wat hij moet maken ook maakt, dwz hoe goed de opgeleverde
    spullen de problemen oplossen waar ze als oplossing voor gebouwd zijn.

    FB