🚀 go-pugleaf

> Het probleem is niet dat het van Microsoft is, maar dat je vastzit aan ��n
> platform, en regelmatig ook aan ��n versie van het platform.

Als dat je enige (of grootste) probleem is met VB, dan heb ik goed nieuws
voor
je aangezien VB.NET code momenteel draait op Windows, Linux en FreeBSD
(ja, ik weet het, Linux en FreeBSD ports staan nog in hun kinderschoenen,
maar dat is het punt niet; het punt is dat het corss-platform is).

>  Als je een
> programma schrijft dat overwegend Windows API calls maakt, zal daar veel
niet
> van werken op een andere versie van Windows waarvoor je het schrijft, en
dan
> mag je met elke nieuwe Windows versie je programma aanpassen.

Das de eerste keer dat ik daarvan hoor... Als je je beperkt tot de Windows95
API
functies, dan draaien je applicaties perfect op elke 32-bit Windows. Als je
dan toch
een nieuwere API functie wil gebruiken schrijf je daar vlug een kleine
wrapper voor
die ff de windows versie controleert.

> De 'components'
> en 'libraries' van Microsoft zijn ook niet consistent tussen software
versies.

Mja... misschien is het daarom dat ze helemaal opnieuw begonnen zijn met
.NET
(en aangezien de CLR nu beheert wordt door het ECMA, zouden de volgende
versies
in principe consistent moeten zijn met de vorige).

> Ik ben nu voor mijn werk een Windows programma aan't ontwikkelen [tegen
mijn
> zin, ik hou me normaal bezig met het schrijven van automatisatie dingen
onder
> un*x] om data uit een databaseserver te halen en in Excel te gooien.  Nu
> zitten we hier met twee versies van Excel: Excel 2000 en Excel 97.  Ik
schrijf
> natuurlijk in C++, maar heb toch al een lijstje pre-processor macro's om
'u'
> tegen te zeggen, gewoon omdat de Excel 2000 classes niet proper praten met
> Excel 97.  ...dat even terzijde...

Microsofts drang om mensen te laten upgraden naar hun nieuwste software
is inderdaad zeer goed zichtbaar in de Office paketten. Nu ja, als ik in hun
schoenen
stond zou ik waarschijnlijk net hetzelfde doen (niet omdat ik mensen graag h
oofdpijn
bezorg, maar omdat dat commercieel gezien het meest rendabel is).

> > Het feit dat je een programma "opnieuw" moet maken wijst erop dat je
> > "slecht" geprogrammeerd hebt.

De oudere BASIC versies boden je niet veel hulpmiddelen aan om goede code
te schrijven. De hoogste vorm van abstractie was een methode :(

> Niet noodzakelijk.  Als jij je programma linkt met een third-party
library, en
> een nieuwere versie van die library is niet backward-compatible, dan heb
je
> een probleem, en dat probleem is inherent aan Windows, denk ik, met de
> DLL-hel.

DLL hel is gelukkig opgelost in .NET.

> Elke programmeur kan een DLL in het systeem steken, en een 'system
> DLL' overschrijven zonder dat hij rekening houdt met de programma's die
zich
> al baseren op die DLL.

... behalve in Windows2000 en hoger.

>  Onder un*x kan je ook shared libraries overwriten,
> maar men doet het gewoon niet. ;-)

Als diezelfde unix goodwill ook bij de windows programmeurs bestond, dan zou
DLL hell nooit een probleem geweest zijn :)
Het probleem denk ik is dat de meeste programmeurs de standaard instellingen
van hun setup programma zomaar overnemen. Als die standaardinstellingen
dan zijn: 'alle DLLs in de Win\Sys zetten en overwriten als die daar al
bestaat'
dan kan je na een tijdje idd problemen verwachten.

> Ik kan je verzekeren dat het
> geen lolletje is.  De taal laat je gewoon toe -- moedigt je zelfs aan --
om
> vieze code te schrijven.  Daar kan ik niet mee om.

Nah... de drie talen bij uitstek om vieze code in te schrijven zijn toch wel
C, C++
en Perl (ik denk dan zo meteen aan
http://www.thinkgeek.com/stuff/apparel/321a.shtml
en http://www.thinkgeek.com/stuff/apparel/31fe.shtml).

> De vraag is of die 'mooie dingen' ook wel nuttig zijn.  E�n van mijn
leraars
> <SNIP>
> richting (het systeem is je standaard happy editor).

Het is evident dat een VB programma dat enkel 'Hello World' zegt compleet
nutteloos
is, maar zo'n programmas kan je in elke taal schrijven (behalve
lambda-calculus
misschien, nuja).
Momenteel is VB nog altijd de meest gebruikte taal voor administratieve
toepassingen,
dus neem VB weg en de economie stort in elkaar (hetzelfde geldt voor sommige
andere
talen zoals C/C++ en COBOL).

> Als je automatisatietoepassingen moet schrijven die op meerdere platformen
> werken, en ook in low-memory situaties ga je met VB niet ver komen.

Daar is VB ook nooit voor gemaakt. Hier zijn enkele dingen waar VB *niet*
voor gemaakt is:
 - drivers
 - low memory programs
 - spelletjes (dan bedoel ik niet 'MineSweeper', maar eerder 'Half-Life' ed)
 - number crunching
 - multi-platform software
 - ongetwijfeld nog enkele dingen...

Waarvoor is VB dan wel geschikt? Snelle ontwikkeling van
bedrijfstoepassingen.

Het is evident dat, als je twee talen met elkaar wil vergelijken, dat je dan
niet hetgeen
moet vergelijken wat de ene taal niet heeft en de andere wel. Als je nu VB
en C zou
vergelijken op de dingen die ze beide kunnen (bijv. het ontwikkelen van
administratieve
toepassingen) dan zal je merken dat VB hier veel beter scoort dan C,
aangezien de sterke
punten van C (klein, snel) eigenlijk niet veel belang hebben in dit type van
toepassingen
en de sterke punten van VB (RAD) net wel veel belang hebben.

> Als jij een VB programma zou krijgen, geschreven in 1984, of maar een
stukje
> van zo'n programma, denk ik dat je heel wat meer werk zou hebben om het te
> laten werken onder meer moderne systemen...

Waarschijnlijk... het is jammer dat VB nooit gestandariseerd is.


Mvg,
Pieter Philippaerts