computerproblemen bij de Nederlandse politie.

[user]

Hoe zit het met gebruik openbron applicaties??
(of eigen apps in een open bron systeem?)

In Frankrijk gebruikt men linux bij de politie.

die 341 computerspecialisten worden wel goed betaald? :
http://www.elsevier.nl/web/Nieuws/Nederland/255471/Ictmanagers-politie-ver-boven-Balkenendenorm.htm

"Uit documenten blijkt dat interim-manager Hans Kamphuis maximaal 376.000
euro krijgt.

Kamphuis is afgelopen zomer voor een jaar aangesteld als algemeen directeur
bij de Voorziening Tot Samenwerking Politie Nederland. Deze organisatie
regelt onder meer de computersystemen voor de politie. Er werken ook 375
ingehuurde specialisten die gemiddeld ruim 201.000 euro declareren."

Volgens mij kan een computerspecialist aan de overheid (belgie) nauwelijks
meer dan 50.000 euro declareren...


http://www.google.be/search?q=politie+computerproblemen&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a

[Martijn van Buul]

Post by user
Hoe zit het met gebruik openbron applicaties??
(of eigen apps in een open bron systeem?)

De relevantie ontgaat mij ten ene male. Heb je het nou over de storing, of
over het informatiesysteem dat niet aansluit bij de praktijk? Beiden staan
volslagen los van het feit of er open source (rot op met je kromme vertalingen)
is gebruikt of niet.

Post by user
http://www.google.be/search?q=politie+computerproblemen&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a

Sukkelaar.

[Sabayon User]

Post by user
"Uit documenten blijkt dat interim-manager Hans Kamphuis maximaal
376.000 euro krijgt.
Kamphuis is afgelopen zomer voor een jaar aangesteld als algemeen
directeur bij de Voorziening Tot Samenwerking Politie Nederland. Deze
organisatie regelt onder meer de computersystemen voor de politie. Er
werken ook 375 ingehuurde specialisten die gemiddeld ruim 201.000 euro
declareren."
Volgens mij kan een computerspecialist aan de overheid (belgie)
nauwelijks meer dan 50.000 euro declareren...

Zijn externen.
Zijn dat bruto of netto franken?

In Nederland mogen overheidsdienaren niet meer dat de minister-president
verdienen (ongeveer 250.000 bruto).

Overheid en ICT blijft een drama, daarom nee tegen het stasi kastje
(kilometerheffing).

[Martijn van Buul]

Post by Sabayon User
stasi kastje

Sukkelaar.

[Den Voldere]

Hoi,

Post by user
Hoe zit het met gebruik openbron applicaties??
(of eigen apps in een open bron systeem?)

Want ?

anyhoe: dit wordt blijkbaar (deels ?) gedaan door de vtspn,
en ik zie daar enkel 1 vacature voor unix/oracle. Als ik wat
door de site 'blader' zie ik enkel UNIX en windows staan,
dus ik vermoed dat er geen opensource in gebruik in de zin
waar deze groep ooit voor gecreerd is ;-)

R

[Lolo]

Post by user
Hoe zit het met gebruik openbron applicaties??
(of eigen apps in een open bron systeem?)

Nou ik ben eigenlijk heel benieuwd zijn wat er nou echt aan de hand is?
Netwerkproblemen is een noemer die ik gehoord heb. Dat is een goede dat
zeg ik ook altijd als er iets met het systeem waar je aan werkt aan de
hand is, zeg maar dat het netwerkproblemen zijn, grappend welliswaar.

Het zal toch geen Java applicatie zijn?

Louis

[Rob]

Post by Lolo

Post by user
Hoe zit het met gebruik openbron applicaties??
(of eigen apps in een open bron systeem?)

Nou ik ben eigenlijk heel benieuwd zijn wat er nou echt aan de hand is?
Netwerkproblemen is een noemer die ik gehoord heb. Dat is een goede dat
zeg ik ook altijd als er iets met het systeem waar je aan werkt aan de
hand is, zeg maar dat het netwerkproblemen zijn, grappend welliswaar.

Ik las ergens dat ze een aantal regio's samengevoegd hebben en daartoe
een aantal Windows Active Directory domeinen samengevoegd hebben.

De hypothese is dat dit er mee te maken zou hebben. Maar of dat zo is
daar heb ik geen flauw idee van. Men is er zelf kennelijk ook nog niet
uit.

[Lolo]

Post by Rob

Post by Lolo

Post by user
Hoe zit het met gebruik openbron applicaties??
(of eigen apps in een open bron systeem?)

Nou ik ben eigenlijk heel benieuwd zijn wat er nou echt aan de hand is?
Netwerkproblemen is een noemer die ik gehoord heb. Dat is een goede dat
zeg ik ook altijd als er iets met het systeem waar je aan werkt aan de
hand is, zeg maar dat het netwerkproblemen zijn, grappend welliswaar.

Ik las ergens dat ze een aantal regio's samengevoegd hebben en daartoe
een aantal Windows Active Directory domeinen samengevoegd hebben.
De hypothese is dat dit er mee te maken zou hebben. Maar of dat zo is
daar heb ik geen flauw idee van. Men is er zelf kennelijk ook nog niet
uit.

Inmiddels las ik dat het opgelost is, men was bij het overstappen naar
een nieuw systeem wat software vergeten te installeren, althans dat las
ik. Misschien heeft dat wel te maken met die Windows Active Directory
die jij hier noemt. Het hangt vaak ook van lulligheid aan elkaar als
systemen niet doen.

Louis

[Rob]

Post by Lolo

Post by Rob

Post by Lolo

Post by user
Hoe zit het met gebruik openbron applicaties??
(of eigen apps in een open bron systeem?)

Nou ik ben eigenlijk heel benieuwd zijn wat er nou echt aan de hand is?
Netwerkproblemen is een noemer die ik gehoord heb. Dat is een goede dat
zeg ik ook altijd als er iets met het systeem waar je aan werkt aan de
hand is, zeg maar dat het netwerkproblemen zijn, grappend welliswaar.

Ik las ergens dat ze een aantal regio's samengevoegd hebben en daartoe
een aantal Windows Active Directory domeinen samengevoegd hebben.
De hypothese is dat dit er mee te maken zou hebben. Maar of dat zo is
daar heb ik geen flauw idee van. Men is er zelf kennelijk ook nog niet
uit.

Inmiddels las ik dat het opgelost is, men was bij het overstappen naar
een nieuw systeem wat software vergeten te installeren, althans dat las
ik. Misschien heeft dat wel te maken met die Windows Active Directory
die jij hier noemt. Het hangt vaak ook van lulligheid aan elkaar als
systemen niet doen.

Nee achteraf bleek het probleem in een Unix systeem te zitten.
Ze gebruiken daar de systemen die vroeger door Digital Equipment
ontwikkeld zijn (OSF/1 is dat geloof ik) en die later door Compaq en
daarna weer door HP zijn overgekocht. Op de Alpha processor.
Daar draait kennelijk de applicatie op.

(de gebruiker kijkt nog steeds naar een character mode scherm; ik weet
niet of het VT-320 emulatie is of dat er ook aan de Windows kant een
slimmer frontend draait wat toch minstens de locale echo doet)

[jaap]

Post by Lolo

Post by user
Hoe zit het met gebruik openbron applicaties??
(of eigen apps in een open bron systeem?)

Nou ik ben eigenlijk heel benieuwd zijn wat er nou echt aan de hand is?
Netwerkproblemen is een noemer die ik gehoord heb. Dat is een goede dat
zeg ik ook altijd als er iets met het systeem waar je aan werkt aan de
hand is, zeg maar dat het netwerkproblemen zijn, grappend welliswaar.
Het zal toch geen Java applicatie zijn?
Louis

Wat is er mis met Java?
Het kan in elke taal geschreven zijn, helaas kent elke taal z'n broddelaars.

Jaap

[Den Voldere]

Hoi,

Post by jaap
Wat is er mis met Java?
Het kan in elke taal geschreven zijn, helaas kent elke taal z'n broddelaars.

Aan dat laatste moest ik ook denken toen mijn CWI
inschrijfdame zich verontschuldigde. Het duurde zolang toen
ze mijn al eerder verstuurde CV opzocht.

Ik vraag me echt af waarom je die applicatie (soort webmail
omgeving met agenda ed, ik mocht meekijken op het scherm) in
een cross-platform taal moet schrijven als je *overal* op
alle CWI werkstations toch windows xp hebt draaien... Ik ben
uiteraard niet bij die ene vergadering geweest waarin Java
is besloten, ik had wel eens willen weten wat nu de
beweegredenen geweest zijn.

Anyhoe: mijn advies is doorgaans php voor een webapplicatie,
evt opgedirkt met javascript als het niet anders kan
enerzijds, anderzijds om blijkbaar een hele meute HBO
informatici tevreden te houden. En natuurlijk mijn uurtje
lynx om te beoordelen of je nog redelijkerwijs je doel kan
bereiken.

Nee, er is niets mis met java, ik vind alleen dat de uitkomsten
van alle java-projecten die ik gezien heb traag. Daar zit vast
een gemene deler achter.

R

[unknown]

Post by Den Voldere
Hoi,

Post by jaap
Wat is er mis met Java?
Het kan in elke taal geschreven zijn, helaas kent elke taal z'n broddelaars.

Aan dat laatste moest ik ook denken toen mijn CWI
inschrijfdame zich verontschuldigde. Het duurde zolang toen
ze mijn al eerder verstuurde CV opzocht.

:) Altijd zelf een hardcopy meenemen.

Post by Den Voldere
Ik vraag me echt af waarom je die applicatie (soort webmail
omgeving met agenda ed, ik mocht meekijken op het scherm) in
een cross-platform taal moet schrijven als je *overal* op
alle CWI werkstations toch windows xp hebt draaien... Ik ben
uiteraard niet bij die ene vergadering geweest waarin Java
is besloten, ik had wel eens willen weten wat nu de
beweegredenen geweest zijn.

Ik hoop dat er goede redenen zijn, want een taal kiezen om de taal is
nooit erg slim.

Post by Den Voldere
Anyhoe: mijn advies is doorgaans php voor een webapplicatie,
evt opgedirkt met javascript als het niet anders kan
enerzijds, anderzijds om blijkbaar een hele meute HBO
informatici tevreden te houden. En natuurlijk mijn uurtje
lynx om te beoordelen of je nog redelijkerwijs je doel kan
bereiken.

Voor web-applicaties (intranet) gebruiken wij steeds meer JavaScript, en
erbij de opmerking dat alleen Firefox ondersteunt wordt. Is
crossplatform en je bent het reloaden en back-forward kwijt. Natuurlijk
zijn er ook veel nadelen. JavaScript/PHP/HTML is een tikkie anders
ontwikkelen dan in C#.NET of Java of Mono of native.

Post by Den Voldere
Nee, er is niets mis met java, ik vind alleen dat de uitkomsten
van alle java-projecten die ik gezien heb traag. Daar zit vast
een gemene deler achter.

Traag ten opzichte waarvan? Zelf heb ik de ervaring, dat Java steeds
beter gaat werken. Projecten als Eclipse en Netbeans lopen niet veel
trager dan hun native (of .NET) neven en nichten. Veel verschil heb ik
gemerkt bij de JVM die je gebruikt. De GNU versie is wezenlijk slechter
dan de SUN versie.

Zelf net bezig met een Java project[1], en daarbij is cross-platformheid
een eis. En bleek ook te werken. Zonder problemen een 'gewone gebruiker'
ermee aan de gang gekregen.

Bart

[Martijn van Buul]

Projecten als Eclipse en Netbeans lopen niet veel trager dan hun native (of
.NET) neven en nichten.

Grapjurk. Op moderne hardware, ja, maar op het moment dat je eens met wat
minder bent toebedeeld merk je weer hoe traag het allemaal niet is.

Zelf net bezig met een Java project[1], en daarbij is cross-platformheid
een eis.

Java is niet cross-platform. Java is *een* platform, waarvoor verschillende
implementaties van een emulator beschikbaar zijn, die zich uiteraard overal
anders gedragen.

Mijn C64 is net zo cross-platform als java. Ook voor een C64 zijn er op vrij
veel platformen emulatoren beschikbaar.

[unknown]

Post by Martijn van Buul

Projecten als Eclipse en Netbeans lopen niet veel trager dan hun native (of
.NET) neven en nichten.

Grapjurk. Op moderne hardware, ja, maar op het moment dat je eens met wat
minder bent toebedeeld merk je weer hoe traag het allemaal niet is.

Mee eens. Maar er is steeds meer moderne hardware beschikbaar. En native
is per definitie sneller, maar soms is meer hardware ertegen gooien een
beter oplossing.

Post by Martijn van Buul

Zelf net bezig met een Java project[1], en daarbij is cross-platformheid
een eis.

Java is niet cross-platform. Java is *een* platform, waarvoor verschillende
implementaties van een emulator beschikbaar zijn, die zich uiteraard overal
anders gedragen.

Okee. Slak, zout. Wat is dan wel cross-platform?

Bart

[Martijn van Buul]

Mee eens. Maar er is steeds meer moderne hardware beschikbaar. En native is
per definitie sneller, maar soms is meer hardware ertegen gooien een beter
oplossing.

Waarom gaat die vlieger dan alleen op voor Java? Overigens: Wordt het zo
ondertussen niet eens tijd dat we ook de CO2-uitstoot van IT-oplossingen
gaan meten? >:)

Okee. Slak, zout. Wat is dan wel cross-platform?

Niets. Maar als Java cross-platform is, dan is een willekeurige scriptingtaal
het ook. Lua kan ook z'n bytecode exporteren en op een ander platform weer
inlezen, dus ik zie het grote verschil niet.

[unknown]

Post by Martijn van Buul

Mee eens. Maar er is steeds meer moderne hardware beschikbaar. En native is
per definitie sneller, maar soms is meer hardware ertegen gooien een beter
oplossing.

Waarom gaat die vlieger dan alleen op voor Java?

Dat gaat zeker niet alleen voor Java op.

Post by Martijn van Buul
Overigens: Wordt het zo
ondertussen niet eens tijd dat we ook de CO2-uitstoot van IT-oplossingen
gaan meten? >:)

Doen ze dat niet al? Ik zie af en toe reclames voor 'green computing'.

Post by Martijn van Buul

Okee. Slak, zout. Wat is dan wel cross-platform?

Niets. Maar als Java cross-platform is, dan is een willekeurige scriptingtaal
het ook. Lua kan ook z'n bytecode exporteren en op een ander platform weer
inlezen, dus ik zie het grote verschil niet.

Strict gezien heb je gelijk inderdaad. Maar bij Java 'werkt' het. Ik heb
vandaag nog met Mono/Gtk#/.NET zitten spelen en ik kreeg mijn op
Linux/Monodevelop gemaakte programmaatje niet onder Windows aan de
praat. Een programma onder Netbeans ook gemaakt, en die werd door een
'gewone' gebruiker zonder meer opgestart en gebruikt.

Bart

[Bozweb]

On Sun, 31 Jan 2010 11:40:33 +0000 (UTC), Martijn van Buul

Post by Martijn van Buul

Projecten als Eclipse en Netbeans lopen niet veel trager dan hun native (of
.NET) neven en nichten.

Grapjurk. Op moderne hardware, ja, maar op het moment dat je eens met wat
minder bent toebedeeld merk je weer hoe traag het allemaal niet is.

Zelf net bezig met een Java project[1], en daarbij is cross-platformheid
een eis.

Java is niet cross-platform. Java is *een* platform, waarvoor verschillende
implementaties van een emulator beschikbaar zijn, die zich uiteraard overal
anders gedragen.
Mijn C64 is net zo cross-platform als java. Ook voor een C64 zijn er op vrij
veel platformen emulatoren beschikbaar.

Gebruiken ze bij de plietsie geen citrix dan?
http://www.citrix.com/lang/English/home.asp

Kunnen ze in het plietsiehok ook niks vernachelen op de comp.

[Rob]

Post by unknown
Traag ten opzichte waarvan? Zelf heb ik de ervaring, dat Java steeds
beter gaat werken. Projecten als Eclipse en Netbeans lopen niet veel
trager dan hun native (of .NET) neven en nichten.

Je bedoelt waarschijnlijk: ik heb steeds een nieuwe computer gekregen
en op de computer die ik tegenwoordig gebruik werkt het best wel redelijk.

De mensen die nog een 5 jaar oude computer hebben die maken dat echter
niet mee. Voor hen blijft Java traag.

Met name het opstarten duurt zelfs op een moderne computer nog lang.
Behalve misschien als je ingesteld hebt dat ie het al bij booten moet
inladen. Dat is een feature die alle softwarebouwers die te trage
software ontwikkeld hebben in hun pakket bouwen, en als je daar maar
in mee blijft gaan dan wordt het booten weer traag en staat de hele
machine vol ongebruikte crap zodat er niks meer overblijft voor het
werk waar je mee bezig bent. Dat zie ik niet zo zitten.

[unknown]

Post by Rob

Post by unknown
Traag ten opzichte waarvan? Zelf heb ik de ervaring, dat Java steeds
beter gaat werken. Projecten als Eclipse en Netbeans lopen niet veel
trager dan hun native (of .NET) neven en nichten.

Je bedoelt waarschijnlijk: ik heb steeds een nieuwe computer gekregen
en op de computer die ik tegenwoordig gebruik werkt het best wel redelijk.

Dat niet alleen. De *nieuwe* Java apps op *nieuwe* hardware is sneller
dan *oude* Java software op *oude* hardware. Per saldo is de zaak dus
sneller. En waar het ook aan moge liggen (hardware wordt sneller sneller
dan software ofzo), interesseert me niet zo.

Ik wil niet klinken als een Java-evangelist, dat ben ik geenszins, maar
het wordt meer een optie voor write-once-execute-anywhere dan voorheen.
En dat vind ik persoonlijk wel een voordeel.

Goede andere cross-platform oplossingen zijn er volgens mij niet. Die
ook nog een korte ontwikkeltijd hebben.

Post by Rob
De mensen die nog een 5 jaar oude computer hebben die maken dat echter
niet mee. Voor hen blijft Java traag.

Ja. En een VHS band wordt ook niet beter.

Je punt?

Post by Rob
Met name het opstarten duurt zelfs op een moderne computer nog lang.

Het opstarten waarvan? De JVM? De software daarna?

Bart

[Rob]

Post by unknown

Post by Rob
De mensen die nog een 5 jaar oude computer hebben die maken dat echter
niet mee. Voor hen blijft Java traag.

Ja. En een VHS band wordt ook niet beter.
Je punt?

Je zegt dat Java beter wordt maar dat is hooguit gedeeltelijk zo, het
belangrijkste is dat computers beter worden en dat je daar wel een stuk
van kunt verspillen aan het gebruik van Java.

Maar je moet daar altijd mee uitkijken want als je als ontwikkelaar een
snelle machine hebt dan kun je best wel iets bouwen wat voor de gebruiker
hardstikke traag aanvoelt. Zie dat CWI voorbeeld.
De computers van gebruikers zijn vaak minder gespecificeerd dan die van
ontwikkelaars. Een slechte beslissing, want daardoor ziet de ontwikkelaar
niet wat ie fout doet.

Post by unknown

Post by Rob
Met name het opstarten duurt zelfs op een moderne computer nog lang.

Het opstarten waarvan? De JVM? De software daarna?

Weet ik niet. Interesseert me ook niet. Het opstarten van iets wat
intern met Java werkt duurt lang.

[unknown]

Post by Rob
Je zegt dat Java beter wordt maar dat is hooguit gedeeltelijk zo, het
belangrijkste is dat computers beter worden en dat je daar wel een stuk
van kunt verspillen aan het gebruik van Java.

Okee. Java als technologie wordt bruikbaarder door beter geworden
hardware. Net als Web 2.0, 3D effecten op je desktop, virtualisatie,
etcetera.

Post by Rob
Maar je moet daar altijd mee uitkijken want als je als ontwikkelaar een
snelle machine hebt dan kun je best wel iets bouwen wat voor de gebruiker
hardstikke traag aanvoelt. Zie dat CWI voorbeeld.
De computers van gebruikers zijn vaak minder gespecificeerd dan die van
ontwikkelaars. Een slechte beslissing, want daardoor ziet de ontwikkelaar
niet wat ie fout doet.

Je moet als ontwikkelaar natuurlijk wel rekening houden met je publiek.
En daarbij dus ook de hardware waar je project op moet gaan draaien.

Post by Rob

Post by unknown
Het opstarten waarvan? De JVM? De software daarna?

Weet ik niet. Interesseert me ook niet. Het opstarten van iets wat
intern met Java werkt duurt lang.

En hoop andere dingen ook. Er is gewoon een hoop bloat tegenwoordig in
software. Maar ik begrijp je punt.

Bart

[Martijn van Buul]

Post by unknown
Dat niet alleen. De *nieuwe* Java apps op *nieuwe* hardware is sneller
dan *oude* Java software op *oude* hardware.

Je bedoelt: Ze laten steken vallen bij Sun?

Post by unknown
Ik wil niet klinken als een Java-evangelist, dat ben ik geenszins, maar
het wordt meer een optie voor write-once-execute-anywhere dan voorheen.

Juist niet. Write once? Misschien. Execute anywhere? Helemaal niet; alleen
als je je minimum systeemeisen minimaal even hoog stelt als jouw
ontwikkelplatform.

Post by unknown
En dat vind ik persoonlijk wel een voordeel.
Goede andere cross-platform oplossingen zijn er volgens mij niet. Die
ook nog een korte ontwikkeltijd hebben.

Post by Rob
De mensen die nog een 5 jaar oude computer hebben die maken dat echter
niet mee. Voor hen blijft Java traag.

Ja. En een VHS band wordt ook niet beter.

Tsja, de arrogantie van de applicatieprogrammeur druipt er weer vanaf. En maar
kankeren op Microsoft als die toevallig hetzelfde doen...

Post by unknown
Je punt?

Mwah. Mijn persoonlijke opvatting over java, zonder dat mensen zich
aangesproken moeten voelen door het bijzonder negatieve karma dat er in
doorklinkt:

1) Java is C++ voor kneuzen, waarin alle moeilijke onderwerpen (multiple
inheritance, pointers, ownership) onder het tafelkleed zijn gemoffeld
en vervangen door contrapties die weer hun eigen probleempjes met zich
meebrengen (Autoboxing!), waardoor het netto rendement behoorlijk
nihil is.
2) Java is geschreven door mensen die denken dat 3 platformpjes (Linux-i386,
windows-i386 en Solaris..) "crossplatform" is.
3) Java gebruikt een "en anders verkoop je toch gewoon de boot"-aanpak wat
betreft performance: Alle performanceproblemen kun je oplossen met meer
hardware, en wie het daar niet mee eens is die liegt (Zie John Bokma..)

Dus nee, voor mij is Java een belabberde oplossing voor een probleem dat
ze nota bene zelf bedacht hebben.

Post by unknown

Post by Rob
Met name het opstarten duurt zelfs op een moderne computer nog lang.

Het opstarten waarvan? De JVM? De software daarna?

Om even iemand te parafraseren: Dat kan me niet schelen.

[unknown]

Post by Martijn van Buul

Post by unknown
Dat niet alleen. De *nieuwe* Java apps op *nieuwe* hardware is sneller
dan *oude* Java software op *oude* hardware.

Je bedoelt: Ze laten steken vallen bij Sun?

Ik weet niet wat je hier bedoelt.

Post by Martijn van Buul

Post by unknown
Ik wil niet klinken als een Java-evangelist, dat ben ik geenszins, maar
het wordt meer een optie voor write-once-execute-anywhere dan voorheen.

Juist niet. Write once? Misschien. Execute anywhere? Helemaal niet; alleen
als je je minimum systeemeisen minimaal even hoog stelt als jouw
ontwikkelplatform.

Ja inderdaad. Er zijn nog wel wat grenzen. Het is geen crossplatform in
de zin dat ook mijn Nokia telefoon en pentium 2 servertje ermee overweg
kunnnen.

Post by Martijn van Buul

Post by unknown

Post by Rob
De mensen die nog een 5 jaar oude computer hebben die maken dat echter
niet mee. Voor hen blijft Java traag.

Ja. En een VHS band wordt ook niet beter.

Tsja, de arrogantie van de applicatieprogrammeur druipt er weer vanaf. En maar
kankeren op Microsoft als die toevallig hetzelfde doen...

Mij hoor je niet kankeren hoor. En ik zou het geen arrogantie noemen.
Het is een andere manier van de zaken bekijken. Jij komt (CMIIW) uit de
embedded hoek, en dan heb je heel andere eisen en problemen. Om een
pragmatisch applicatieprogrammeur (er *is* nu eenmaal heel veel zware
hardware voorhanden) meteen 'arrogant' te noemen vind ik erg ver gaan.

Post by Martijn van Buul

Post by unknown
Je punt?

Mwah. Mijn persoonlijke opvatting over java, zonder dat mensen zich
aangesproken moeten voelen door het bijzonder negatieve karma dat er in
1) Java is C++ voor kneuzen, waarin alle moeilijke onderwerpen (multiple
inheritance, pointers, ownership) onder het tafelkleed zijn gemoffeld
en vervangen door contrapties die weer hun eigen probleempjes met zich
meebrengen (Autoboxing!), waardoor het netto rendement behoorlijk
nihil is.
2) Java is geschreven door mensen die denken dat 3 platformpjes (Linux-i386,
windows-i386 en Solaris..) "crossplatform" is.
3) Java gebruikt een "en anders verkoop je toch gewoon de boot"-aanpak wat
betreft performance: Alle performanceproblemen kun je oplossen met meer
hardware, en wie het daar niet mee eens is die liegt (Zie John Bokma..)

Okee. Maar ik heb in Java wel snel een applicatie geschreven die doet
wat ik wil. En hij voldoet ook nog aan de eisen dat het onder Windows,
Linux en Mac OSX draait (één van de eisen). Er zijn vast andere
mogelijkheden om dat voor elkaar te krijgen, maar dan was ik langer
bezig geweest (want al bekend met Java) en was het waarschijnlijk
buggier geweest. En dat zal dan wel komen door mijn tekortkomingen als
programmeur, maar ik heb nu een tool waar ik iets aan heb.

Post by Martijn van Buul
Dus nee, voor mij is Java een belabberde oplossing voor een probleem dat
ze nota bene zelf bedacht hebben.

Volgens jou is er dus geen crossplatform en Java is C++ voor kneuzen.
Heb je een andere oplossing? Of betoog je dat er geen
'write-once-run-anywhere' oplossing bestaat?

Bart

[Martijn van Buul]

Post by unknown

Post by Martijn van Buul

Post by unknown
Dat niet alleen. De *nieuwe* Java apps op *nieuwe* hardware is sneller
dan *oude* Java software op *oude* hardware.

Je bedoelt: Ze laten steken vallen bij Sun?

Ik weet niet wat je hier bedoelt.

Dat ze zich moeten schamen aangezien ze zich niet aan de wet van Wirth[1]
houden..

Post by unknown

Post by Martijn van Buul
Tsja, de arrogantie van de applicatieprogrammeur druipt er weer vanaf. En
maar kankeren op Microsoft als die toevallig hetzelfde doen...

Mij hoor je niet kankeren hoor. En ik zou het geen arrogantie noemen.

Maar dat is het wel. Alle (goedbedoelde) wetjes en regeltjes en
vuistregels die in het programmeurswereldje rondzwerven stammen uit
het applicatiedomein, waar performance van ondergeschikt belang is.

De arrogantie schuilt niet in de aanname dat vettere hardware alles
oplost, maar in de aanname dat dit voor andere mensen *dus* ook geldt.

Post by unknown
Het is een andere manier van de zaken bekijken. Jij komt (CMIIW) uit de
embedded hoek,

Ik heb het geluk dat mijn werk een heel breed spectrum omgat. Vandaag was ik
applicatie-programmeur en zit ik dialogs te implementeren, gisteren heb ik
algoritmes zitten prototypen in een scriptingtaaltje, morgen ben ik Operating
System-programmeur en ga ik me bezighouden met hoe taken te paralleliseren over
meerdere processoren, vorige week was ik voornamelijk bezig geweest met
wiskunde en OpenGL. Wat ik *komende* week ga doen weet ik nog niet zeker.

Post by unknown
en dan heb je heel andere eisen en problemen. Om een
pragmatisch applicatieprogrammeur (er *is* nu eenmaal heel veel zware
hardware voorhanden) meteen 'arrogant' te noemen vind ik erg ver gaan.

De hardware waar ik op werk is niet veel minder zwaar dan de gemiddelde
PC. Waar ik echter steeds meer tegenaanloop is de gedachte dat volgend
jaar toch alle CPU's 2x zo snel zijn. Dat is absoluut niet het geval; cores
zijn eigenlijk de laatste tijd helemaal niet zo heel veel sneller geworden, er
heeft alleen een verbreding plaatsgevonden. Was je een paar jaar nog
helemaal het mannetje met een hyperthreading CPU, tegenwoordig is quad core
bijna de onderkant van de markt.

Voor een willekeurige applicatieprogrammeur is een quadcore vast 4x zo
snel als een single core - maar voor de rest van de wereld niet. Voor mij
betekent een quadcore dat ik welliswaar 4x zoveel werk verzet krijg, maar
dat mijn taken *ook* 4x zo lang duren, en dat mijn deadlines dat over het
algemeen niet toelaten. Vettere hardware lost dus nog lang niet altijd
alles op; het is voorgekomen dat we bewust dual-core CPU's hebben toegepast
omdat die *per core* nou eenmaal meer wek verzetten.

Tegelijkertijd worden programmeurs steeds lakser, en java is daar heus
niet het enige mee. Op comp.lang.c++ zijn ze het spoor vaak ook volslagen
bijster door een losse integer en een complexe klasse vrolijk op een hoop
te gooien enkel en alleen omdat het kan, en omdat je dan gebruik kunt
maken van standaard templates. Dat de performance om te huilen is maakt
niet uit. De compiler lost toch alles voor je op? Nou dan.

Het erge is dat de meeste het niet eens in de gaten hebben, en iedere
vorm van commentaar per definitie wegwimpelen met het standaard "maar
ontwikkeltijd is ook duur!" argument - alsof dat altijd zou opgaan.

Post by unknown
Heb je een andere oplossing? Of betoog je dat er geen
'write-once-run-anywhere' oplossing bestaat?

Inderdaad. Er *is* geen one-size-fits-all.

[1] http://en.wikipedia.org/wiki/Wirth%27s_law

[Lolo]

Post by jaap
Wat is er mis met Java?
Het kan in elke taal geschreven zijn, helaas kent elke taal z'n broddelaars.

Nou niet echt kwaads behoudens dat het misschien wat traag is en ik mag
graag zeggen het is een porsche voort laten trekken door een paard en
wagen (en het neemt ook de hele weg in gebruik!) maar ik kan me goed
voorstellen dat het prima voldoet en je hebt voor de rest natuurlijk
gelijk, hetis maar wat je ermee doet.

Louis

[John Bokma]

Post by Lolo

Post by jaap
Wat is er mis met Java?
Het kan in elke taal geschreven zijn, helaas kent elke taal z'n broddelaars.

Nou niet echt kwaads behoudens dat het misschien wat traag is

14 jaar terug misschien, maar de meeste mensen die het nu traag vinden
praten over ervaring van 10+ jaar terug *of* kunnen niet in Java
programmeren (of gebruiken software die gemaakt is door programmeurs die
niet handig zijn in Java).

Post by Lolo
mag graag zeggen het is een porsche voort laten trekken door een paard
en wagen (en het neemt ook de hele weg in gebruik!) maar ik kan me

Beter dan een porsche elke 100 meter in de sloot laten rijden, waardoor
die overloopt.

[Lolo]

Post by John Bokma

Post by Lolo

Post by jaap
Wat is er mis met Java?
Het kan in elke taal geschreven zijn, helaas kent elke taal z'n broddelaars.

Nou niet echt kwaads behoudens dat het misschien wat traag is

14 jaar terug misschien, maar de meeste mensen die het nu traag vinden
praten over ervaring van 10+ jaar terug *of* kunnen niet in Java
programmeren (of gebruiken software die gemaakt is door programmeurs die
niet handig zijn in Java).

Dat is ook zo en zie ook gewoon goede java apps, die goed draaien. Maar
het blijf voor mij iets hebben dat je er wat tussengooit en mijn gevoel
zegt dat je dan inlevert maar misschien is het wel heel anders.

Post by John Bokma

Post by Lolo
mag graag zeggen het is een porsche voort laten trekken door een paard
en wagen (en het neemt ook de hele weg in gebruik!) maar ik kan me

Beter dan een porsche elke 100 meter in de sloot laten rijden, waardoor
die overloopt.

Dat vind ik een tikje overschat, je kop erbij houden moet je toch.

Louis

[John Bokma]

Post by Lolo

Post by John Bokma

Post by Lolo

Post by jaap
Wat is er mis met Java?
Het kan in elke taal geschreven zijn, helaas kent elke taal z'n broddelaars.

Nou niet echt kwaads behoudens dat het misschien wat traag is

14 jaar terug misschien, maar de meeste mensen die het nu traag vinden
praten over ervaring van 10+ jaar terug *of* kunnen niet in Java
programmeren (of gebruiken software die gemaakt is door programmeurs die
niet handig zijn in Java).

Dat is ook zo en zie ook gewoon goede java apps, die goed
draaien. Maar het blijf voor mij iets hebben dat je er wat tussengooit
en mijn gevoel zegt dat je dan inlevert maar misschien is het wel heel
anders.

Wat jaap al min of meer probeerde uit te leggen: moderne
"geinterpreteerde" talen werken met een virtuele machine die een JIT
heeft. Blokken instructies voor de virtuele machine kunnen naar native
code omgezet worden. Dit kan tijdens de loop van het programma gebeuren,
waardoor allerlei optimalisaties nog kunnen plaatsvinden, zie ook
http://en.wikipedia.org/wiki/Just-in-time_compilation.

Java code hoeft zeker al een hele tijd niet meer traag te draaien, en
zeker bij normale GUI applicaties zou je geen verschil mogen merken
tussen C/C++/Java.

Post by Lolo

Post by John Bokma

Post by Lolo
mag graag zeggen het is een porsche voort laten trekken door een paard
en wagen (en het neemt ook de hele weg in gebruik!) maar ik kan me

Beter dan een porsche elke 100 meter in de sloot laten rijden, waardoor
die overloopt.

Dat vind ik een tikje overschat, je kop erbij houden moet je toch.

Toch staat C en C++ er om bekend enorm last te hebben van
geheugenallocatie missers. Negen van de tien keer als ik een security
update voorbij zie komen in Ubuntu betreft het
buffer-overflow(s). Uiteraard ligt dat ook aan de programmeur. De vraag
is: wat is kwalijker, een programma dat langzamer draait, of een
programma dat hier en daar een buffer-overflow heeft.

[Rob]

Post by John Bokma
Java code hoeft zeker al een hele tijd niet meer traag te draaien, en
zeker bij normale GUI applicaties zou je geen verschil mogen merken
tussen C/C++/Java.

Dit verhaal lees je altijd weer, maar het is in tegenspraak met wat
er gebeurt als ik per ongeluk op een pagina in de webbrowser land waar
ze nog Java gebruiken. Dan gebeurt er eerst een paar seconden niks,
wat me laat denken dat de boel hangt. Dan valt het op dat de machine
keihard bezig is en even later verschijnt er in de traybar het bekende
rokende kopje koffie dat alles verklaart.

Als het een tijdje gedraaid heeft dan wordt het wel steeds sneller, maar
het is deze negatieve ervaring die het beeld bepaalt.

[unknown]

Post by John Bokma
Java code hoeft zeker al een hele tijd niet meer traag te draaien, en
zeker bij normale GUI applicaties zou je geen verschil mogen merken
tussen C/C++/Java.

Dit verhaal lees je altijd weer, maar het is in tegenspraak met wat er
gebeurt als ik per ongeluk op een pagina in de webbrowser land waar ze
nog Java gebruiken.

Je weet dat je Java ook zonder browser kunt gebruiken? Java als taal voor
webpaginafunctionaliteiten heeft nooit voldaan (maar was, destijds, de
enige manier om zaken werkend te krijgen die tegenwoordig middels
JS/CSS/SVG/Canvas geregeld kunnen worden), maar Java is niet beperkt tot
het schrijven van applets.

[Lolo]

Post by John Bokma

Post by Lolo
Dat is ook zo en zie ook gewoon goede java apps, die goed
draaien. Maar het blijf voor mij iets hebben dat je er wat tussengooit
en mijn gevoel zegt dat je dan inlevert maar misschien is het wel heel
anders.

Wat jaap al min of meer probeerde uit te leggen: moderne
"geinterpreteerde" talen werken met een virtuele machine die een JIT
heeft. Blokken instructies voor de virtuele machine kunnen naar native
code omgezet worden. Dit kan tijdens de loop van het programma gebeuren,
waardoor allerlei optimalisaties nog kunnen plaatsvinden, zie ook
http://en.wikipedia.org/wiki/Just-in-time_compilation.

Dat is me ook wat, ja dat is inderdaad heel voor de hand liggend nu ik
het zo lees en het is logisch. Ik ben niet bij. Maar betekent dat ook al
die applicaties die onder Websphere draaien hier ook allemaal gebruik
van maken of is dat weer wat anders? Ik neem aan dat nog wel blijft
gelden dat als je optimaal gebruik wilt maken van de hardware dat C/C++
wel de voor de hand liggende optie is?

Post by John Bokma
Java code hoeft zeker al een hele tijd niet meer traag te draaien, en
zeker bij normale GUI applicaties zou je geen verschil mogen merken
tussen C/C++/Java.

Ik ga meteen weer een keer open-office eens ophalen. Dat programma daar
heb ik ook de associatie niet te snel zoals bijvoorbeeld Word dat weer
wel is. Ik ben benieuwd.

Post by John Bokma

Post by Lolo
Dat vind ik een tikje overschat, je kop erbij houden moet je toch.

Toch staat C en C++ er om bekend enorm last te hebben van
geheugenallocatie missers. Negen van de tien keer als ik een security
update voorbij zie komen in Ubuntu betreft het
buffer-overflow(s). Uiteraard ligt dat ook aan de programmeur. De vraag
is: wat is kwalijker, een programma dat langzamer draait, of een
programma dat hier en daar een buffer-overflow heeft.

In het ene geval ben je snel klaar in het andere geval moet je eerst een
tijdje ergeren.

Louis

[John Bokma]

Post by Lolo

Post by John Bokma

Post by Lolo
Dat is ook zo en zie ook gewoon goede java apps, die goed
draaien. Maar het blijf voor mij iets hebben dat je er wat tussengooit
en mijn gevoel zegt dat je dan inlevert maar misschien is het wel heel
anders.

Wat jaap al min of meer probeerde uit te leggen: moderne
"geinterpreteerde" talen werken met een virtuele machine die een JIT
heeft. Blokken instructies voor de virtuele machine kunnen naar native
code omgezet worden. Dit kan tijdens de loop van het programma gebeuren,
waardoor allerlei optimalisaties nog kunnen plaatsvinden, zie ook
http://en.wikipedia.org/wiki/Just-in-time_compilation.

Dat is me ook wat, ja dat is inderdaad heel voor de hand liggend nu ik
het zo lees en het is logisch. Ik ben niet bij. Maar betekent dat ook
al die applicaties die onder Websphere draaien hier ook allemaal
gebruik van maken of is dat weer wat anders? Ik neem aan dat nog wel
blijft gelden dat als je optimaal gebruik wilt maken van de hardware
dat C/C++ wel de voor de hand liggende optie is?

Dat hangt er van af wat je precies wilt doen: een VM kan run time
analyze van de code doen, en die dus /tijdens het draaien/
optimaliseren. Dat is iets wat met C/C++ niet kan, tenzij je dat zelf er
in gaat zitten bakken... (dus een C/C++ compiler die je code opnieuw kan
compileren, gedreven door code dat een analyse heeft gemaakt van je
lopend programma...)

http://paulbuchheit.blogspot.com/2007/06/java-is-faster-than-c.html
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Post by Lolo

Post by John Bokma
Java code hoeft zeker al een hele tijd niet meer traag te draaien, en
zeker bij normale GUI applicaties zou je geen verschil mogen merken
tussen C/C++/Java.

Ik ga meteen weer een keer open-office eens ophalen. Dat programma
daar heb ik ook de associatie niet te snel zoals bijvoorbeeld Word dat
weer wel is. Ik ben benieuwd.

Ik kan mij vergissen maar ik weet vrij zeker dat OOo alleen voor
bepaalde dingen Java gebruikt.

Post by Lolo

Post by John Bokma

Post by Lolo
Dat vind ik een tikje overschat, je kop erbij houden moet je toch.

Toch staat C en C++ er om bekend enorm last te hebben van
geheugenallocatie missers. Negen van de tien keer als ik een security
update voorbij zie komen in Ubuntu betreft het
buffer-overflow(s). Uiteraard ligt dat ook aan de programmeur. De vraag
is: wat is kwalijker, een programma dat langzamer draait, of een
programma dat hier en daar een buffer-overflow heeft.

In het ene geval ben je snel klaar in het andere geval moet je eerst
een tijdje ergeren.

Tja, ik heb liever dat het ietjes langzamer draait, dan dat ik opnieuw
moet beginnen omdat het programma er uit knalt, of stiekem foute
resultaten geeft. Bij goede programmeurs zal het niet uitmaken, maar
helaas zijn die lastig te vinden. Maar laat je zeker niet wijsmaken dat
Java per definitie traag is (en niet dat het altijd beter is ;-) ).

[Martijn van Buul]

Post by John Bokma
http://paulbuchheit.blogspot.com/2007/06/java-is-faster-than-c.html

Slechte benchmark, aangezien hier voornamelijk IO wordt getest, het het
aanroepen van fputs() met *een* los karakter niet getuigt van clue. Hetzelfde
geldt overigens ook voor de Java code.

Post by John Bokma
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Berg losse claims (404, hoe prettig), en een hele berg onzin. Wie roept dat
mensen die niet hopeloos verliefd zijn op Java dom volk is dat minimaal 10 jaar
achterloopt moet zelf niet met "bewijs" uit 1993 aan komen zetten. Bovendien
gebruiken zel allemaal GCC als benchmark - terwijl gcc nou niet bekend staat om
zijn efficiente code. En om het af te maken: Uit jouw URL:

" Again Java is competitive with (actually slighty faster than) several C++
compilers including Visual C++ in the majority of the benchmarks. "

Uit het artikel waar dit uit zou volgen

(http://www.osnews.com/story/5602/Nine_Language_Performance_Round-up_Benchmarking_Math_File_I_O/page3/)


Als ik dan Java 1.4.2 vergelijk met Visual C++, dan kom ik tot de conclusie
dat Java sneller is _in 2 van de 5 tests_, en dat de totale tijd van java
zelfs *een factor twee hoger ligt*.

Hoe je dit vervolgens kunt vertalen naar "Java is actually slightly faster
than several compilers including Visual C++ in the majority of the benchmarks"
zonder 's nachts wakker te liggen van wroeging ontgaat mij.

Post by John Bokma
Tja, ik heb liever dat het ietjes langzamer draait, dan dat ik opnieuw
moet beginnen omdat het programma er uit knalt

Waarom crasht Eclipse dan om de haverklap? Rotte code crasht - in welke
taal dan ook. Mensen die beweren dat welke programmeertaal dan ook
programmeerfouten voorkomt *en oplost* weten niet waar ze het over hebben.

[Martijn Lievaart]

Post by Martijn van Buul
Rotte code crasht - in welke
taal dan ook. Mensen die beweren dat welke programmeertaal dan ook
programmeerfouten voorkomt *en oplost* weten niet waar ze het over hebben.

Aaaaaaaamen!

:-)

M4

[jaap]

Post by Martijn Lievaart

Post by Martijn van Buul
Rotte code crasht - in welke
taal dan ook. Mensen die beweren dat welke programmeertaal dan ook
programmeerfouten voorkomt *en oplost* weten niet waar ze het over hebben.

Aaaaaaaamen!

Halleluja!
Ik geef toch de voorkeur aan de talen die strongly typed zijn en waar
data hiding mogelijk is. Dat zorgt dat ik minder fouten kan maken.
Pointers mogen mooie dingen zijn, maar geef mij maar een taal waar ze
verborgen zijn en waar een garbage collector mijn rommel opruimt.

Verder zweer ik bij test driven development. Als er geen test is die
faalt, heeft het geen zin om code te schrijven. Heerlijk. Nu weet ik
wanneer een programma af is: er falen geen testen meer.
Vindt een gebruiker een fout, jawel, dat blijft gebeuren, dan wordt die
fout eerst in een test gesimuleerd en dan pas opgelost: deze fout zal
niet nog eens optreden.

Naast een goede taal is dus ook een goede aanpak essentieel. Blijft
enkel nog de discussie wat *goed* is.

Jaap

[Rob]

Post by jaap

Post by Martijn Lievaart

Post by Martijn van Buul
Rotte code crasht - in welke
taal dan ook. Mensen die beweren dat welke programmeertaal dan ook
programmeerfouten voorkomt *en oplost* weten niet waar ze het over hebben.

Aaaaaaaamen!

Halleluja!
Ik geef toch de voorkeur aan de talen die strongly typed zijn en waar
data hiding mogelijk is. Dat zorgt dat ik minder fouten kan maken.
Pointers mogen mooie dingen zijn, maar geef mij maar een taal waar ze
verborgen zijn en waar een garbage collector mijn rommel opruimt.
Verder zweer ik bij test driven development. Als er geen test is die
faalt, heeft het geen zin om code te schrijven. Heerlijk. Nu weet ik
wanneer een programma af is: er falen geen testen meer.

Hier zie ik twee uitgangspunten in software ontwikkeling die ik totaal
verafschuw.

Het resultaat van deze manier van ontwikkelen is een programma wat doet
wat er in de folder staat, en meteen instort zodra je iets probeert wat
de maker niet bedacht had. Dat is immers niet getest, en dus werkt het
ook niet.

[jaap]

Post by Rob

Post by jaap
Ik geef toch de voorkeur aan de talen die strongly typed zijn en waar
data hiding mogelijk is. Dat zorgt dat ik minder fouten kan maken.
Pointers mogen mooie dingen zijn, maar geef mij maar een taal waar ze
verborgen zijn en waar een garbage collector mijn rommel opruimt.
Verder zweer ik bij test driven development. Als er geen test is die
faalt, heeft het geen zin om code te schrijven. Heerlijk. Nu weet ik
wanneer een programma af is: er falen geen testen meer.

Hier zie ik twee uitgangspunten in software ontwikkeling die ik totaal
verafschuw.
Het resultaat van deze manier van ontwikkelen is een programma wat doet
wat er in de folder staat, en meteen instort zodra je iets probeert wat
de maker niet bedacht had. Dat is immers niet getest, en dus werkt het
ook niet.

Ik ben het eens met "wat niet getest is ook niet werkt". Dus zorg ik dat
zo veel mogelijk getest is (alles is onmogelijk).
Ik ga met de specificaties aan de gang. Daar maak ik testcases voor en
wat ik niet snap of onduidelijk is vraag ik na. Zo zouden voor alle
specs testen moeten zijn. Het voordeel van een test maken is dat je al
erg goed moet weten *wat* je moet maken, het *hoe* komt wel. Mijn
ervaring is dat je beter contact hebt met de klant en betere software
oplevert die prima te onderhouden is.
Als ik iets wijzig draai ik altijd alle testen.

Jaap

[Rob]

Post by jaap

Post by Rob

Post by jaap
Ik geef toch de voorkeur aan de talen die strongly typed zijn en waar
data hiding mogelijk is. Dat zorgt dat ik minder fouten kan maken.
Pointers mogen mooie dingen zijn, maar geef mij maar een taal waar ze
verborgen zijn en waar een garbage collector mijn rommel opruimt.
Verder zweer ik bij test driven development. Als er geen test is die
faalt, heeft het geen zin om code te schrijven. Heerlijk. Nu weet ik
wanneer een programma af is: er falen geen testen meer.

Hier zie ik twee uitgangspunten in software ontwikkeling die ik totaal
verafschuw.
Het resultaat van deze manier van ontwikkelen is een programma wat doet
wat er in de folder staat, en meteen instort zodra je iets probeert wat
de maker niet bedacht had. Dat is immers niet getest, en dus werkt het
ook niet.

Ik ben het eens met "wat niet getest is ook niet werkt". Dus zorg ik dat
zo veel mogelijk getest is (alles is onmogelijk).
Ik ga met de specificaties aan de gang. Daar maak ik testcases voor en
wat ik niet snap of onduidelijk is vraag ik na. Zo zouden voor alle
specs testen moeten zijn. Het voordeel van een test maken is dat je al
erg goed moet weten *wat* je moet maken, het *hoe* komt wel. Mijn
ervaring is dat je beter contact hebt met de klant en betere software
oplevert die prima te onderhouden is.
Als ik iets wijzig draai ik altijd alle testen.

Het probleem is dat je met testen nooit kunt aantonen dat een programma
goed is. Met testen kun je alleen aantonen dat het fout is.
Daarom is het geen goede aanpak om een programma foutvrij te maken door
het uitvoeren van steeds meer testen. Je blijft dan altijd achter de
feiten aanhollen.

De goede aanpak is het gebruik van algorithmes waarvan je kunt aantonen
dat ze goed zijn.

[jaap]

Post by Rob
Het probleem is dat je met testen nooit kunt aantonen dat een programma
goed is. Met testen kun je alleen aantonen dat het fout is.
Daarom is het geen goede aanpak om een programma foutvrij te maken door
het uitvoeren van steeds meer testen. Je blijft dan altijd achter de
feiten aanhollen.
De goede aanpak is het gebruik van algorithmes waarvan je kunt aantonen
dat ze goed zijn.

Daar ben ik het helemaal mee eens. Helaas valt het mij altijd tegen hoe
lastig dat is.

Jaap

[Rob]

Post by jaap

Post by Rob
Het probleem is dat je met testen nooit kunt aantonen dat een programma
goed is. Met testen kun je alleen aantonen dat het fout is.
Daarom is het geen goede aanpak om een programma foutvrij te maken door
het uitvoeren van steeds meer testen. Je blijft dan altijd achter de
feiten aanhollen.
De goede aanpak is het gebruik van algorithmes waarvan je kunt aantonen
dat ze goed zijn.

Daar ben ik het helemaal mee eens. Helaas valt het mij altijd tegen hoe
lastig dat is.

Ja goed programmeren is inderdaad een stuk lastiger dan "net zo lang
friemelen tot de test goed gaat". Daar heb je helemaal gelijk in.

[Martijn Lievaart]

Post by Rob

Post by jaap

Post by Martijn Lievaart

Post by Martijn van Buul
Rotte code crasht - in welke
taal dan ook. Mensen die beweren dat welke programmeertaal dan ook
programmeerfouten voorkomt *en oplost* weten niet waar ze het over hebben.

Aaaaaaaamen!

Halleluja!
Ik geef toch de voorkeur aan de talen die strongly typed zijn en waar
data hiding mogelijk is. Dat zorgt dat ik minder fouten kan maken.
Pointers mogen mooie dingen zijn, maar geef mij maar een taal waar ze
verborgen zijn en waar een garbage collector mijn rommel opruimt.
Verder zweer ik bij test driven development. Als er geen test is die
faalt, heeft het geen zin om code te schrijven. Heerlijk. Nu weet ik
wanneer een programma af is: er falen geen testen meer.

Hier zie ik twee uitgangspunten in software ontwikkeling die ik totaal
verafschuw.
Het resultaat van deze manier van ontwikkelen is een programma wat doet
wat er in de folder staat, en meteen instort zodra je iets probeert wat
de maker niet bedacht had. Dat is immers niet getest, en dus werkt het
ook niet.

Bovenstaande is een manier van software ontwikkelen -- en in mijn ogen
een hele goede -- maar staat andere manieren van testen niet in de weg.

Dat betekent dus niet dat er geen integratie testen, systeem testen en
acceptatie testen moeten plaatsvinden. En mischien nog wel eerder testen.
En minimaal het acceptatie testen moet door de gebruiker gebeuren.

M4

[Rob]

Post by Martijn Lievaart

Post by Rob

Post by jaap

Post by Martijn Lievaart

Post by Martijn van Buul
Rotte code crasht - in welke
taal dan ook. Mensen die beweren dat welke programmeertaal dan ook
programmeerfouten voorkomt *en oplost* weten niet waar ze het over hebben.

Aaaaaaaamen!

Halleluja!
Ik geef toch de voorkeur aan de talen die strongly typed zijn en waar
data hiding mogelijk is. Dat zorgt dat ik minder fouten kan maken.
Pointers mogen mooie dingen zijn, maar geef mij maar een taal waar ze
verborgen zijn en waar een garbage collector mijn rommel opruimt.
Verder zweer ik bij test driven development. Als er geen test is die
faalt, heeft het geen zin om code te schrijven. Heerlijk. Nu weet ik
wanneer een programma af is: er falen geen testen meer.

Hier zie ik twee uitgangspunten in software ontwikkeling die ik totaal
verafschuw.
Het resultaat van deze manier van ontwikkelen is een programma wat doet
wat er in de folder staat, en meteen instort zodra je iets probeert wat
de maker niet bedacht had. Dat is immers niet getest, en dus werkt het
ook niet.

Bovenstaande is een manier van software ontwikkelen -- en in mijn ogen
een hele goede -- maar staat andere manieren van testen niet in de weg.
Dat betekent dus niet dat er geen integratie testen, systeem testen en
acceptatie testen moeten plaatsvinden. En mischien nog wel eerder testen.
En minimaal het acceptatie testen moet door de gebruiker gebeuren.

Wat er niet goed aan is, IMHO, is het betrekken van testen in de development.
"test driven development", brrr...

Naar mijn mening moet een programma ontwikkeld worden op basis van
specificaties en goed uitgedachte algorithmes, en kan een test hooguit
dienen als een geruststelling dat het resultaat inderdaad voldoet aan
een aantal basiseisen.
Met testen kun je NOOIT aantonen dat een programma goed is. Je kunt er
alleen mee aantonen dat het NIET goed is. Dus "het programma voert alle
testen goed uit" zegt weinig of niks over het aantal bugs dat er nog in
zit.
Het lijkt me dan ook helemaal fout om al je tijdens de ontwikkeling op
testen te orienteren.

Maar ik ben van de oude stempel. Ik ben niet opgegroeid met "integrated
development environments" die aanmoedigen om steeds iets te veranderen
en dan weer op "compile and run" te klikken om te zien hoe het nu weer
uitpakt. Ik ben gewend om kritisch te kijken naar een stuk code, een
tekeningetje te maken van de datastructuren, en goed op te letten of allerlei
grensgevallen goed worden afgehandeld door de code. Niet door deze te
runnen maar door er goed naar te kijken.
Daarom ben ik ook niet zo bang voor een taal waarin je zelf verantwoordelijk
bent voor memorymanagement. Ik weet maar al te goed dat je daarin fouten
kunt maken die je door testen niet zo snel vindt, en daarom snap ik ook
best dat "test driven" programmeurs er een hekel aan hebben, maar dat
is gewoon niet mijn stijl van werken.

[Martijn Lievaart]

Post by Rob

Post by Martijn Lievaart
Bovenstaande is een manier van software ontwikkelen -- en in mijn ogen
een hele goede -- maar staat andere manieren van testen niet in de weg.
Dat betekent dus niet dat er geen integratie testen, systeem testen en
acceptatie testen moeten plaatsvinden. En mischien nog wel eerder
testen. En minimaal het acceptatie testen moet door de gebruiker
gebeuren.

Wat er niet goed aan is, IMHO, is het betrekken van testen in de
development. "test driven development", brrr...

Het is geen test driven development. Dat is jouw interpretatie.

Post by Rob
Naar mijn mening moet een programma ontwikkeld worden op basis van
specificaties en goed uitgedachte algorithmes, en kan een test hooguit
dienen als een geruststelling dat het resultaat inderdaad voldoet aan
een aantal basiseisen.

Klopt helemaal.

Post by Rob
Met testen kun je NOOIT aantonen dat een programma goed is. Je kunt er
alleen mee aantonen dat het NIET goed is. Dus "het programma voert alle
testen goed uit" zegt weinig of niks over het aantal bugs dat er nog in
zit.

Klopt helemaal.

Post by Rob
Het lijkt me dan ook helemaal fout om al je tijdens de ontwikkeling op
testen te orienteren.

Helemaal niet mee eens. Sterker, er zijn scholen die zeggen dat je begint
met het maken van je testen.

Post by Rob
Maar ik ben van de oude stempel. Ik ben niet opgegroeid met "integrated
development environments" die aanmoedigen om steeds iets te veranderen
en dan weer op "compile and run" te klikken om te zien hoe het nu weer

Dat is jouw implicatie, nee sterker, insinuatie. Zo werkt professionele
software ontwikkeling niet. Je kunt wel iteratief ontwikkelen maar dat is
een stuk gestructureerder. En af en toe moet je refactoreren en dan kan
bovenstaande methode wel goed zijn, maar dan wel met goede testen om te
kijken of de code die je veranderd hebt zich nog hetzelfde gedraagt.

Post by Rob
uitpakt. Ik ben gewend om kritisch te kijken naar een stuk code, een
tekeningetje te maken van de datastructuren, en goed op te letten of
allerlei grensgevallen goed worden afgehandeld door de code. Niet door

Absoluut.

Post by Rob
deze te runnen maar door er goed naar te kijken. Daarom ben ik ook niet
zo bang voor een taal waarin je zelf verantwoordelijk bent voor
memorymanagement. Ik weet maar al te goed dat je daarin fouten kunt
maken die je door testen niet zo snel vindt, en daarom snap ik ook best
dat "test driven" programmeurs er een hekel aan hebben, maar dat is
gewoon niet mijn stijl van werken.

Nee, je snapt het nog steeds niet. Je ontwikkeld gewoon op de manier
zoals jij werkt. Alleen schrijf je tegelijk testen voor wat je
ontwikkeld. Dat is extra werk, maar het betaalt zich terug. Om jouw
voorbeeld van memory management te pakken, dat is juist een hele mooie.
Goede class/unit/whatever testen focussen juist op dit soort aspecten
waardoor fouten hierin sneller opgemerkt worden. Dergelijke testen zijn
echter nooit een vervanging van goed ontwerp en zorgvuldig programmeren.

Een ander voordeel is dat refactoren een stuk makkelijker wordt. En de
programmeur die nooit stukken code hoeft te refactoren bestaan, maar ik
heb ze nog nooit ontmoet. Voor de meer menselijke programmeurs is het
zaak om waarborgen over de kwaliteit van je code te kunnen geven.


M4

[Rob]

Post by Martijn Lievaart

Post by Rob
Het lijkt me dan ook helemaal fout om al je tijdens de ontwikkeling op
testen te orienteren.

Helemaal niet mee eens. Sterker, er zijn scholen die zeggen dat je begint
met het maken van je testen.

Ja dat zou kunnen, maar met die scholen ben ik het dus niet eens.
Het van te voren maken van testen zou alleen maar mogen als dit gebeurt
door iemand anders dan degene die de software ontwikkelt, en deze ontwikkelaar
pas inzicht in deze testen krijgt als hij in de testfase is aangeland.
Anders is er een veel te groot risico dat het goed functioneren van het
programma gelijk gesteld wordt aan het goed doorlopen van de testen.

Maar dat is mijn mening. Kan best zijn dat jij of scholen het daar
niet mee eens zijn hoor.

Post by Martijn Lievaart

Post by Rob
Maar ik ben van de oude stempel. Ik ben niet opgegroeid met "integrated
development environments" die aanmoedigen om steeds iets te veranderen
en dan weer op "compile and run" te klikken om te zien hoe het nu weer

Dat is jouw implicatie, nee sterker, insinuatie. Zo werkt professionele
software ontwikkeling niet. Je kunt wel iteratief ontwikkelen maar dat is
een stuk gestructureerder.

Ik snap best dat er een soort imaginaire "professionele software
ontwikkeling" bestaat en dat iedere programmeur stelt dat ie volgens die
methoden werkt, maar ik bekijk het meer vanuit het gezichtspunt van iemand
die zelf ooit aardig wat software ontwikkeld heeft, daarbij hoge eisen
aan kwaliteit stelde, en nu meer bezig is met het oplossen van problemen
die op de een of andere manier in software zitten die door anderen
ontwikkeld is.
Ik constateer daarbij dat er problemen zitten in aangeleverde stukken code
die ik kan verklaren uit de manier van ontwikkelen (net zo lang klooien
tot het werkt) en testen (net zo lang de van te voren vastgestelde testen
draaien tot ze allemaal goed gaan). De praktijk brengt dan problemen aan
het licht die in de testen niet afgedekt werden, en waarvan ik als
programmeur van de oude stempel verbaasd ben dat ze er ueberhaupt in zitten.
Ook zijn er vaak complexe workarounds geprogrammeerd voor problemen die
niet goed begrepen zijn, waardoor er in de praktijk nog steeds problemen
optreden.

Dat is niet bedoeld als aanval op jou of de kwaliteit van jouw werk, maar
alleen een constatering die ik wel eens doe in mijn dagelijks werk.

[Martijn Lievaart]

Post by Martijn Lievaart

Post by Rob
Het lijkt me dan ook helemaal fout om al je tijdens de ontwikkeling op
testen te orienteren.

Helemaal niet mee eens. Sterker, er zijn scholen die zeggen dat je
begint met het maken van je testen.

Ja dat zou kunnen, maar met die scholen ben ik het dus niet eens. Het
van te voren maken van testen zou alleen maar mogen als dit gebeurt door
iemand anders dan degene die de software ontwikkelt, en deze
ontwikkelaar pas inzicht in deze testen krijgt als hij in de testfase is
aangeland. Anders is er een veel te groot risico dat het goed
functioneren van het programma gelijk gesteld wordt aan het goed
doorlopen van de testen.
Maar dat is mijn mening. Kan best zijn dat jij of scholen het daar niet
mee eens zijn hoor.

Hier sla je de spijker precies op de kop wat mij betreft, bovenstaande
beschrijving is precies wat ik bedoel. Ik haal het erbij om het belang
van tijdig tests ontwikkelen aan te geven. Zowel op project nivo als op
programmeurs nivo.

Ik snap best dat er een soort imaginaire "professionele software
ontwikkeling" bestaat en dat iedere programmeur stelt dat ie volgens die
methoden werkt, maar ik bekijk het meer vanuit het gezichtspunt van
iemand die zelf ooit aardig wat software ontwikkeld heeft, daarbij hoge
eisen aan kwaliteit stelde, en nu meer bezig is met het oplossen van
problemen die op de een of andere manier in software zitten die door
anderen ontwikkeld is.

Nod. Precies.

Ik constateer daarbij dat er problemen zitten in aangeleverde stukken
code die ik kan verklaren uit de manier van ontwikkelen (net zo lang
klooien tot het werkt) en testen (net zo lang de van te voren

Klooeien totdat het werkt is helaas te vaak de norm, ik zie het te vaak
om me heen. Als ik er vervolgens een slag overheen haal, haal ik er een
millioen problemen uit. Dit is DE manier om software te maken die heel
erg lelijk breekt als er iets fout gaat en/of tegen een boundery
condition aanloopt en daardoor meer schade veroorzaakt dan nodig is.

Klooien totdat het werkt is overigens bij sommige tools de enige manier
(ik werk nu helaas ook in Access VB 2003 en daar is dat vaak de enige
methode bij gebrek aan (kloppende) documentatie). Maar dat is niet hoe ik
wil werken.

vastgestelde testen draaien tot ze allemaal goed gaan). De praktijk

Dat betekend dat de testen niet gemaakt zijn om goede software te maken,
maar om de software door de testen te krijgen. Als de reden is dat dit de
specifficaties van de klant zijn, is het nog enigzins te verdedigen,
hoewel ik ervan gruwel. Als dat niet eens de reden is, is men gewoon stom
bezig en had men zich de moeite kunnen besparen.

brengt dan problemen aan het licht die in de testen niet afgedekt
werden, en waarvan ik als programmeur van de oude stempel verbaasd ben
dat ze er ueberhaupt in zitten. Ook zijn er vaak complexe workarounds
geprogrammeerd voor problemen die niet goed begrepen zijn, waardoor er
in de praktijk nog steeds problemen optreden.

Autch. Yup, bekend. Of nieuwe functionaliteit die er in geperst is waar
het eigenlijk niet past en er een rewrite had moeten plaatsvinden, die
zie je ook vaak.

Dat is niet bedoeld als aanval op jou of de kwaliteit van jouw werk,
maar alleen een constatering die ik wel eens doe in mijn dagelijks werk.

Ik geloof dat we het redelijk eens zijn hoor, alleen wil ik erop wijzen
dat er ook een methode bestaat die begint met de unit testen te
schrijven, en daarna vind de ontwikkeling van de unit plaats op de
gebruikelijke manier. Door goede unit testen vooraf te schrijven, wordt
de kwaliteit van de software een stuk hoger, worden bugs vaker en eerder
gevonden. Dit in tegenstelling tot wat jij hierboven schetst, waar ik ook
van gruwel.

M4

[Martijn van Buul]

jaap (***@meel.homelinux.net) schreef:
erborgen zijn en waar een garbage collector mijn rommel opruimt.

Post by jaap
Verder zweer ik bij test driven development. Als er geen test is die
faalt, heeft het geen zin om code te schrijven. Heerlijk. Nu weet ik
wanneer een programma af is: er falen geen testen meer.

Het probleem is dat dit een beetje afhankelijk is van het domein waarin
je bezig bent. Soms is er geen harde grens tussen "goed" en "fout", en zijn
er meerdere verdedigbare antwoorden - zeker aangezien de eindklant vaak ook
niet zo heel consequent is in zijn eisen, en is de 'prijs' van een fout
niet altijd even eenvoudig te bepalen.

Een ander probleem is dat het schrijven van tests best ingewikkeld is; en
misschien beter door iemand anders kan gebeuren dan de programmeur. Ik probeer
mijn deelproblemen zoveel mogelijk te testen, maar er zijn altijd wel rand-
gevallen waar ik niet aan heb gedacht. Als ik mijn eigen tests schrijf, komen
ze dus ook niet voor in de tests, en houdt de code er alsnog geen rekening
mee. Als iemand anders die tests had geschreven voorkom je dat een beetje,
maar daarvoor heb je wel een team van de goede grootte en samenstelling
nodig.

Tenslotte kan niet alles even snel getest worden. Ik schrijf software voor
sorteer- machines, die wel eens lomp groot kunnen zijn en hele hallen vullen.
Delen daarvan krijg ik best getest en gesimuleerd, maar *het geheel* kan alleen
maar getest worden op de uiteindelijke machine - want daar komen al je
deelsystemen pas echt bij elkaar. Alleen heb ik niet zo'n machine in mijn
achtertuin staan. Ik heb niet eens een achtertuin..

[Jos]

Is men er nu al achter wat de oorzaak van dit alles is?
Kom namelijk net deze link tegen:
http://www.politie-nederland.nl/index.php/nieuws-berichten/28-isc-npi-cip-dmd/2983-politie-kiest-voor-open-source

De poltie gaat gebruikmaken van Red Hat Enterprise Linux 5 (RHEL 5) en
Red Hat Network (RHN) Satellite Server. De software zal worden gebruikt
in 7 rekencentra die de politie in Nederland heeft laten bouwen.

Ik mag toch hopen dat dit avontuur niet de aanleiding is tot de huidige
situatie......

[Bas Janssen]

Post by Jos
Is men er nu al achter wat de oorzaak van dit alles is?
http://www.politie-nederland.nl/index.php/nieuws-berichten/28-isc-npi-cip-dmd/2983-politie-kiest-voor-open-source
De poltie gaat gebruikmaken van Red Hat Enterprise Linux 5 (RHEL 5) en
Red Hat Network (RHN) Satellite Server. De software zal worden gebruikt
in 7 rekencentra die de politie in Nederland heeft laten bouwen.
Ik mag toch hopen dat dit avontuur niet de aanleiding is tot de huidige
situatie......

Nee, het had vooral te maken met een aantal windhoos servers die een
bepaalde 'service pack' niet hadden gehad, of er niet mee overweg konden..

Zie o.a. ook de berichtgeving op webwereld:

http://webwereld.nl/nieuws/65040/politie--netwerkstoring-duurt-nog-weken.html#source=news_overview

"We zijn optimistisch, dit duurt nog enkele weken." ....

jaja, overheid en IT....

[Rob]

Post by Bas Janssen
Nee, het had vooral te maken met een aantal windhoos servers die een
bepaalde 'service pack' niet hadden gehad, of er niet mee overweg konden..

Ik heb elders gelezen dat het Unix servers waren.
Maakt dat het een ander verhaal?

[Bas Janssen]

Post by Rob

Post by Bas Janssen
Nee, het had vooral te maken met een aantal windhoos servers die een
bepaalde 'service pack' niet hadden gehad, of er niet mee overweg konden..

Ik heb elders gelezen dat het Unix servers waren.
Maakt dat het een ander verhaal?

Deze post hoort misschien in een andere nieuwsgroep, maar vooruit:

Er zijn op dit moment 2 grote problemen qua ict bij de politie, die her
en der in de media flink door elkaar heen gegooid worden.

* Netwerk problemen / crisis voor een aantal korpsen (Friesland,
Groningen, Drenthe, IJsselland, Noord- en Oost-Gelderland, Gelderland
Midden, Gelderland Zuid en Twente)

http://www.politie.nl/ijsselland/nieuws/100129oorzaakcomputerprobleemnoordoostelijkepolitiekorpsengevonden.asp


* Veel problemen met het nieuwe aangifte systeem 'BVH'
(Basisvoorziening Handhaving). Dit probleem loopt als sinds de invoer in
maart 09.

http://www.computable.nl/artikel/ict_topics/crm/2911174/2333360/nieuw-ictsysteem-brengt-agenten-in-gevaar.html
http://webwereld.nl/nieuws/64930/politie-geeft-miljoenen-uit-om-ict-te-redden.html

Of het op windows of *nix draait maakt me eigenlijk geen donder uit...
(het is overigens een gemixte omgeving...)

Waar ik me wel druk om maak is dat ICT managers bij de politie kennelijk
dikke 2ton+ salarissen krijgen uitgekeerd voor een enorme wanprestatie....

http://webwereld.nl/nieuws/64832/ict-managers-politie-ver-boven-balkenende-norm.html

En ja, de politiek grijpt in(*), terwijl het eigenlijk al te laat is. De
'gewone' agent kan zijn werk inmiddels bijna niet meer normaal doen....

(*)
http://webwereld.nl/nieuws/65004/ict-bedrijf-politie-onder-curatele-gesteld---update.html

[Rob]

Post by Bas Janssen
Of het op windows of *nix draait maakt me eigenlijk geen donder uit...
(het is overigens een gemixte omgeving...)

Nee maar als er tendentieus Windhoos staat dan blijkt daar wel een
bepaalde waardering uit.

[Martijn van Buul]

Post by John Bokma
14 jaar terug misschien, maar de meeste mensen die het nu traag vinden
praten over ervaring van 10+ jaar terug *of* kunnen niet in Java
programmeren (of gebruiken software die gemaakt is door programmeurs die
niet handig zijn in Java).

Mwah, misschien zijn er nog mensen die zich met iets anders bezig houden dan
het schrijven van de zoveelste notepad-kloon, een ander nietszeggend stuk
desktopapplicatie, de zoveelste databasetoepassing of de zoveelste
webpage backend.

Dat jij dat verschil niet kunt maken is *jouw* probleem, niet het mijne.

[jaap]

Post by Lolo

Post by jaap
Wat is er mis met Java?
Het kan in elke taal geschreven zijn, helaas kent elke taal z'n broddelaars.

Nou niet echt kwaads behoudens dat het misschien wat traag is en ik mag
graag zeggen het is een porsche voort laten trekken door een paard en
wagen (en het neemt ook de hele weg in gebruik!) maar ik kan me goed
voorstellen dat het prima voldoet en je hebt voor de rest natuurlijk
gelijk, het is maar wat je ermee doet.
Louis

Traag? Het draait in een Virtual Machine! Waar een C compiler maar moet
gokken hoe de machine is waar het op draait, weet de VM het precies en
zal er dus prima voor kunnen optimaliseren. Het is niet voor niets dat
er talloze talen zijn die op de Java Virtual Machine draaien.

Jaap

[Lolo]

Post by jaap

Post by Lolo

Post by jaap
Wat is er mis met Java?
Het kan in elke taal geschreven zijn, helaas kent elke taal z'n broddelaars.

Nou niet echt kwaads behoudens dat het misschien wat traag is en ik
mag graag zeggen het is een porsche voort laten trekken door een paard
en wagen (en het neemt ook de hele weg in gebruik!) maar ik kan me
goed voorstellen dat het prima voldoet en je hebt voor de rest
natuurlijk gelijk, het is maar wat je ermee doet.
Louis

Traag? Het draait in een Virtual Machine! Waar een C compiler maar moet
gokken hoe de machine is waar het op draait, weet de VM het precies en
zal er dus prima voor kunnen optimaliseren. Het is niet voor niets dat
er talloze talen zijn die op de Java Virtual Machine draaien.

Is dat zo? Ik dacht dat een C-compiler altijd voor een bepaalt platform
is gemaakt en als het even meezit het een zo goed mogelijke vertaling
maakt. Maar zoals gezegd, ik denk dat het prima kan voldoen en vast
mooie zaken te bieden heeft.

Louis

[John Bokma]

[Java]

Post by Lolo

Post by jaap
Traag? Het draait in een Virtual Machine! Waar een C compiler maar
moet gokken hoe de machine is waar het op draait, weet de VM het
precies en zal er dus prima voor kunnen optimaliseren. Het is niet
voor niets dat er talloze talen zijn die op de Java Virtual Machine
draaien.

Is dat zo?

Ongeveer: in tegenstelling tot, bijvoorbeeld een C-compiler, kan bij Java
e.d. optimalisaties *tijdens het draaien* van het programma gedaan
worden.

Een voorbeeld wat ik even snel kon vinden:
http://www.smallshire.org.uk/sufficientlysmall/2009/05/22/ironpython-2-0-and-jython-2-5-performance-compared-to-python-2-5/

Dit vergelijkt CPython (geschreven in C) met Jython (geschreven in Java)
en IronPython (.NET).

In de grafieken kan je zien dat bij een bepaalde afmeting en hoger van
de binary tree Jython beter presenteerd dan CPython. Zelfs al is het
appels en peren, zoals een reaktie beweerd, het laat zien dat een Java
implementatie van Python /sneller kan zijn/ dan een C implementatie. Of
dat aan het snugger zijn van de programmeurs ligt of aan Java, doet er
wat mij betreft niet zo toe. Het laat mooi zien dat je niet zomaar kan
zeggen: dit is geschreven in C dus per definitie sneller dan als het in
Java was geschreven.

Zie:
http://www.smallshire.org.uk/sufficientlysmall/2009/05/22/ironpython-hammers-cpython-when-not-mutating-class-attributes/

voor een vergelijking met iets aangepaste Python code.

[Martijn van Buul]

Of dat aan het snugger zijn van de programmeurs ligt of aan Java, doet er wat
dit is geschreven in C dus per definitie sneller dan als het in Java was
geschreven.

Maar dat zegt dan ook niemand. Wat mensen zeggen is "Alles wat in Java is
geschreven *kan sneller in een andere taal*"

[Hans W]

Post by Lolo

Post by user
Hoe zit het met gebruik openbron applicaties??
(of eigen apps in een open bron systeem?)

Nou ik ben eigenlijk heel benieuwd zijn wat er nou echt aan de hand is?
Netwerkproblemen is een noemer die ik gehoord heb. Dat is een goede dat
zeg ik ook altijd als er iets met het systeem waar je aan werkt aan de
hand is, zeg maar dat het netwerkproblemen zijn, grappend welliswaar.
Het zal toch geen Java applicatie zijn?

Er stond/staat een nameserver op een ander ipnummer en
die vergeten unix doos hebben ze niet aangepast?

Hans