[alg] hoe lief moet je zijn?

[joepP]

Janoz schreef op 03 juni 2004 @ 12:08:
[...]

Je mist mijn punt. Dat ging namelijk vooral om de eerste zin. Je irriteerd je aan het feit dat java je dwingt rekening te houden met mogenlijk op kunnen tredende fouten en dat het hierdoor slordig programeren in de hand werkt. Die uitspraakt vind ik nogal tegenstrijdig.

Je mist mijn punt

Veel beginners schrijven in Java niets anders dan lege try-catch blokken. Dat is een feit, ga maar eens bij een gemiddelde opleiding kijken wat studenten weten te produceren. Als het niet verplicht zou zijn, was er ook geen lege try-catch gekomen, en wat de fout inclusief stacktrace gewoon tevoorschijn gekomen.

Het probleem is dus dat je mensen die niet goed programmeren uitnodigd tot het maken van fouten die een expert toch al niet zal maken. Dat heet: de plank volledig misslaan.

[bigbeng]

joepP schreef op 03 juni 2004 @ 12:13:
[...]

Je mist mijn punt

Veel beginners schrijven in Java niets anders dan lege try-catch blokken. Dat is een feit, ga maar eens bij een gemiddelde opleiding kijken wat studenten weten te produceren. Als het niet verplicht zou zijn, was er ook geen lege try-catch gekomen, en wat de fout inclusief stacktrace gewoon tevoorschijn gekomen.

Het probleem is dus dat je mensen die niet goed programmeren uitnodigd tot het maken van fouten die een expert toch al niet zal maken. Dat heet: de plank volledig misslaan.

Heb je wel eens gezien wat de beginnende VB programmeur produceert? Dan schieten de tranen je in de ogen. Ik denk dat het werkelijke probleem wat jij aankaart niet bij de beginneling of bij Java ligt maar bij het niveau van de leraar. Ik volg momenteel een HBO opleiding Informatica, omdat autodidact in deze tijd op je CV niet veel hout snijdt, en daar moet telkens bijna huilen (ben wel een vent hoor ) als ik zie wat voor leraren er basis programmeren mogen geven.

edit:

Sorry voor het off-topic gaan, maar deze reactie kon ik mijzelf niet onthouden

[ Voor 5% gewijzigd door bigbeng op 03-06-2004 12:20 ]

[Soultaker]

Janoz schreef op 03 juni 2004 @ 12:08:
Je irriteerd je

offtopic:
En hier kan ik me dus dubbel aan ergeren.

[.oisyn]

bigbeng schreef op 03 juni 2004 @ 09:51:
Het kost je om precies te zijn 4 regels code extra, nl de try, de catch en de twee sluitaccolades van beide.

Je vergeet er even bij te zeggen dat dat per statement is, anders heb je er nog niets aan. Toegegeven, exceptions hoor je meestal te vangen, en nou is een IllegalArgumentException toevallig een RuntimeException die je niet per se hoeft af te vangen, maar het is echt een ramp om de hele tijd try/catch statements te moeten schrijven, terwijl het enige wat je wilt is dat ie gewoon klapt in je debugger. Daarom ben ik ook voor asserts, en exceptions alleen in de daadwerkelijk uitzonderlijke gevallen.

Ook wil ik even reageren op de mensen die iets zeggen over dat Exceptions een negatief effect hebben op performance, omdat er veel dubbelgecheckt wordt enzo.

Nou nee, het is meer het stack unwinding wat een exception relatief duur maakt

Performance is sowieso niet iets waar een compiled code interpreter als de JVM voor bedoeld is, hoewel je natuurlijk best nog wat aan je code kunt twieken om het beter te laten performen, zul je met native code (lees assembly of machinetaal) altijd betere performance halen. Helaas kost het kloppen van de code dan wel wat extra uurtjes, zeker als je meerdere hardware platforms wilt ondersteunen.

Beetje raar om de vergelijking met asm te trekken en alle native 3rd generation talen maar achterwege te laten. En voor asm gaat dat wat je zegt idd wel op, maar het is echt onzin om te stellen dat in java productiever gewerkt kan worden dan in een native taal. Persoonlijk ben ik in C++ 10x zo productief dan in java, wat vooral te maken heeft met deterministic finalization, operator overloading, templates en het simpele feit dat er niet echt een verschil zit tussen primitieven en objecten (je kunt ze beide zowel op de stack als op de heap aanmaken)

En ik heb persoonlijk het vermoeden dat de simpele try catch structuur zoals ik hierboven beschrijf door de compiler nog wel geoptimaliseerd wordt.

Er valt weinig aan te optimaliseren, het is meer een runtime iets.

Zoijar schreef op 03 juni 2004 @ 11:27:
Bij 'verwijderingen' of 'opruimen' moet je altijd lief zijn. Simpelweg omdat het nogal wat problemen kan geven als een destructor exceptions gooit. Het maakt het ook makkelijker om gewoon altijd iets te verwijderen aan het einde, dan hoef je niet steeds van die checks in te bouwen overal.

bv. dit:

C++:

void foo() {
   Connection a, b;

   try {
      a.open();
      b.open();
   } catch (...) {
      a.close();
      b.close();
      throw;
   }
}

Maakt het wat makkelijker dan dat je eerst weer moet gaan kijken of a en b wel closed kunnen worden.

Die close is trouwens typisch iets wat ik in de destructor zou doen van Connection, waardoor die hele try/catch overbodig wordt. Maar ik begrijp dat je op die manier niet je punt kan maken

[bigbeng]

.oisyn schreef op 03 juni 2004 @ 15:21:

Beetje raar om de vergelijking met asm te trekken en alle native 3rd generation talen maar achterwege te laten. En voor asm gaat dat wat je zegt idd wel op, maar het is echt onzin om te stellen dat in java productiever gewerkt kan worden dan in een native taal. Persoonlijk ben ik in C++ 10x zo productief dan in java, wat vooral te maken heeft met deterministic finalization, operator overloading, templates en het simpele feit dat er niet echt een verschil zit tussen primitieven en objecten (je kunt ze beide zowel op de stack als op de heap aanmaken)

Ik greep naar assembler om zo dicht mogelijk bij de machine te gaan staan wat performance betreft. Ik ben met je eens dat c++ en c heel efficiente compilers per platform hebben en dus (bijna) net zo goed kunnen performen als asm. Ik heb erover gedacht om c/c++ te gebruiken in mn voorbeeld maar besloten om iets verder door te slaan. Maar goed, je maakt mn punt voornamelijk sterker, ik probeerde vooral aan te geven dat als je echte performance wilt, dat je dan dus niet naar een geinterpreteerde taal moet grijpen (VB6 en eerder, of Java dus).

edit:

ik besef dat Java ook gecompileerd wordt, maar het gecompileerde wordt vervolgens geinterpreteerd door de JVM. Dus geen flamewar AUB

[ Voor 6% gewijzigd door bigbeng op 03-06-2004 15:35 ]

[MaxxRide]

Eigenlijk is deze discussie hier niet echt op zijn plaats maar toch wil ik ehm er even ingooien (is wel lichtelijk verwant namelijk). Er bestaan JIT compilers die op het laatste moment de JAVA bytecode omzetten in een platform afhankelijke (machine-) taal. Stel deze JIT kunnen net zo efficient compilen als een C++ compiler (wat niet ondenkbaar is). Wat is dan nog het bezwaar qua performance om een taal als JAVA te gebruiken?

Na aanleiding van MOD request; deze discussie maar niet voeren. Zal eens in de zoekfunctie op zoek gaan naar interessante stukken hierover.

[ Voor 15% gewijzigd door MaxxRide op 03-06-2004 16:28 ]

[Janoz]

Laten we het ontopic houden en hier geen discussie starten over VM vs native

[ATS]

In het geval van het voorbeeld zou ik het "afvangen" door gewoon het geschikte datatype te gebruiken: unsigned int. In veel gevallen gebruik ik trouwens ook "custom datatypes" (classes) die gewoon niet ongeldig kunnen worden. Zo gebruik ik in een project waaraan ik nu bezig ben objecten als "Speed" en "Altitude".