Java: Is het nou echt zo handig

[Verwijderd]

Ik heb me er nooit zo in verdiept onder het motto: Het is geinterpreteerd, langzaam, afhankelijk van grote bedrijven, en ik vind het dus nutteloos.

Ik heb zelf zoiets van: als ik een proggie voor windows heb geschreven en ik wil het naar linux of mac porten dan verander ik de boel wel.

Ik vertrouw java dus niet zo.
Dit komt denk ik vooral doordat ik niet graag afhankelijk ben van grote bedrijven als Sun, Borland, Microsoft, en dus liever in programeertalen werk waar diverse compilers van in omloop zijn.

Mijn vraag aan jullie: Wat vinden jullie drvan?

[Verwijderd]

Ik heb zelf ook niet echt veel ervaring met java, dus daarover nog geen mening Ga vanaf september mee beginnen.

Ik denk dat ik nu C(++) zou pakken om ervoor te zorgen dat het onder windows en linux werkt. Met die SDL moet het ook nog wel lukken om grafisch iets netjes in elkaar te zetten.

[mbravenboer]

RRazoRR: Ik heb me er nooit zo in verdiept onder het motto

Hoe kan je nu oordelen als je je er nog nooit in verdiept heb? Bestuur alle gerelateerde zaken eerst, en probeer dan een mening te vormen.

Het is geinterpreteerd

Fout: 'Hotspots' worden just in time naar native code gecompileerd. Hierdoor kunnen onderdelen van de code die intensief worden gebruikt heel efficient uitgevoerd worden. Bovendien kunnen er door de runtime compilatie optimalisaties uitgevoerd worden die bij een statische compile time niet mogelijk waren geweest.

langzaam

Fout: Swing GUIs zijn niet responsief en AWT is beperkt, maar de GUI afdeling is gelukkig niet de enige vertegenwoordiger van Java. SWT van Eclipse doet het trouwens al een stuk beter, maar het argument gaat verder: kijk eens naar 'normae' Java code in een recente JVM. Kijk eens naar server-side applicaties in een servlet-container. Servlets zijn uitermate populair, denk je dat de server-side ontwikkeling zou kiezen voor een 'langzame' omgeving?

afhankelijk van grote bedrijven

Wat niet?

Als we het over JVMs hebben worden die op dit moment nog voornamelijk door Sun en IBM ontwikkelt, maar er zijn ook wel degelijk free-software initiatieven. Op library gebied ligt het heel anders: eigenlijk vrijwel al het interessante materiaal komt van Apache, een organisatie die juist afhankelijkheid van 1 bedrijf tracht te voorkomen.

en ik vind het dus nutteloos.

Dat mag je zelf weten .

Ik heb zelf zoiets van: als ik een proggie voor windows heb geschreven en ik wil het naar linux of mac porten dan verander ik de boel wel.

Java is voor GUI ontwikkeling op dit moment absoluut niet interessant en dat is een groot falen. Vergeet echter niet dat er meer is dan de applicaties die de gemiddelde computeraar ziet.

Dit komt denk ik vooral doordat ik niet graag afhankelijk ben van grote bedrijven als Sun, Borland, Microsoft, en dus liever in programeertalen werk waar diverse compilers van in omloop zijn.

Er zijn voor Java vele intiatieven: gcj timmert behoorlijk aan de weg, JET doet het goed, er zijn alternatieve JVM implementaties (die wel zwaar achterlopen).

Belangrijker vind ik echter de toekomst. Runtimes vormen een groot risico voor oude software omdat je altijd een runtime nodig zult hebben om je software te kunnen draaien. Dit is een grote beperking, maar ik heb er vertrouwen in. Waarom? Allereerst omdat Java zo belangrijk is geworden, dat anderen door zullen gaan als Sun stopt. Het wegvallen van Java zou echt een ramp zijn en dat zal dus kost wat kost voorkomen worden. Hoopgevend is met name dat Sun heeft aangegeven dat Java volledig open-source zal worden (vrijer dan de huidige licentie) als het niet meer rendabel zal zijn om incompatible varianten van het Java Platform uit te brengen. Die tijd is naar mijn mening aangebroken met de komst van Microsoft .NET en ik denk dat deze grote wijziging daarom binnen 1 a 2 jaar doorgevoerd zal gaan worden.

De kracht van Java ligt niet alleen in de platform-onafhankelijkheid, maar vooral ook in de eenvoud en compactheid van zowel de taal als de library. Zoals elke omgeving begint nu ook Java wel vervuiling te vertonen, maar ik vertrouw erop dat dit kundig opgeruimd zal worden zodra er besloten wordt om niet meer backwards compatible te zijn.

Overigens valt er ook zeker veel kritiek op het Java Platform te leveren. We praten hier echter al een paar jaar over Java, dus daarvoor kan de search worden geraadpleegd .

[Orphix]

Ik zal er niet zo diep op ingaan omdat ik niet veel ervaring heb met Java en al helemaal niet de advocacy kan voeren maar ik wou toch even ge beeld iets veranderen.

Op maandag 01 juli 2002 23:51 schreef RRazoRR het volgende:
Ik heb me er nooit zo in verdiept onder het motto: Het is geinterpreteerd, langzaam, afhankelijk van grote bedrijven, en ik vind het dus nutteloos.

Geinterpreteerd is ten deelse waard, java wordt gecompileerd naar een intermediate taal. Deze taal kan relatief erg snel worden uitgevoerd. Een echte geinterpreteerde taal zoals PHP is daarom veel langzamer.

Langzaam valt wel mee, 1 van de grote nadelen van Java is dat de GUI niet snel is en dit uit zich duidelijk in iets visueel waardoor velen al zeggen 'is niet snel'. Number crunching (gewone berekeningen) kan door Java wel snel worden uitgevoerd. De performance is niet te vergelijken met bv C/C++, maar bedenk maar eens in hoeveel gevallen je deze performance ECHT wilt hebben.

Afhankelijke van grote bedrijven vind ik geen probleem? Als Sun een goede taal aflevert heb ik daar geen problemen mee, evenmin als Microsoft (C#) dat doet.

Ik heb zelf zoiets van: als ik een proggie voor windows heb geschreven en ik wil het naar linux of mac porten dan verander ik de boel wel.

Tja over de zin en onzin van cross-platform is iets waar je de laatste tijd wel meer over hoort. Voor server-side schijnt het toch makkelijk te zijn dat java-code zowel op sun servers als linux servers kan draaien.
De desktop-kant is iets heel anders en de moeite die geinvesteerd wordt en de opofferingen die je moet maken om de portability te handhaven kan dan in je nadeel gaan werken. Dit komt natuurlijk omdat je met een windows-versie al 95% van de gebruikers hebt.

Verder wil ik opmerken dat je Java moet zien als een moderne taal waarbij vervelende eigenschappen van 'oude' talen als C uit zijn gehaald. In Java wordt je vaak gedwongen via bepaalde designs te werken waardoor uiteindelijk vaak je programma eleganter in elkaar zit. Ik vind dit persoonlijk een groot voordeel van Java.

Helaas is voor mij dit voordeel een beetje weggevallen met de komst van C#, maar dat is weer een andere discussie

[edit]
shit en toch heeft mbravenboer een nog langere tekst

[mbravenboer]

Orphix: shit en toch heeft mbravenboer een nog langere tekst

Ik had veel quotes .

Geinterpreteerd is ten deelse waard, java wordt gecompileerd naar een intermediate taal. Deze taal kan relatief erg snel worden uitgevoerd. Een echte geinterpreteerde taal zoals PHP is daarom veel langzamer.

Niet om je echt te corrigeren, maar om het ff helemaal duidelijk te maken: Java wordt gecompileerd naar Java Bytecode, wat inderdaad een soort intermediate language is. Deze Java Bytecode ligt echter wel erg dicht bij Java en is eigenlijk meer een soort 'gevalideerde en getypecheckte' Java code. Hierdoor kan het inderdaad wel een stuk sneller geladen/geinterpreteerd worden omdat alle code niet meer geanalyseerd hoeft te worden, zoals bij scripting talen het geval is.

At runtime kan deze intermediate language echter weer gecompileerd worden naar native code en dat levert pas echte flinke snelheidswinst op. Deze Just In Time (JIT) compilatie wordt tegenwoordig gedaan door de Hotspot compiler die hele goede optimalisaties kan uitvoeren op de plekken waar dit het hardste nodig is. Tijdens de laatste JavaOne conferentie waren er wat leuke presentaties over deze compiler (er zijn eigenlijk zelfs verschillende varianten voor: client en server). De slides kan je online vinden en gratis downloaden dit jaar.

Verder kan ik me wel vinden in je tekst .

[ACM]

Op dinsdag 02 juli 2002 00:16 schreef Orphix het volgende:
Een echte geinterpreteerde taal zoals PHP is daarom veel langzamer.

php wordt ook eerst 'just-in-time' gecompileerd bij mijn weten

Echt geinterpreteerde talen zijn er niet zoveel meer volgens mij, misschien bashscripting nog?

[edit]
shit en toch heeft mbravenboer een nog langere tekst

Doet ie altijd

Op dinsdag 02 juli 2002 00:25 schreef mbravenboer het volgende:
Niet om je echt te corrigeren, maar om het ff helemaal duidelijk te maken: Java wordt gecompileerd naar Java Bytecode, wat inderdaad een soort intermediate language is. Deze Java Bytecode ligt echter wel erg dicht bij Java en is eigenlijk meer een soort 'gevalideerde en getypecheckte' Java code. Hierdoor kan het inderdaad wel een stuk sneller geladen/geinterpreteerd worden omdat alle code niet meer geanalyseerd hoeft te worden, zoals bij scripting talen het geval is.

Om de al door Orphix aangehaalde php-analogie dan maar door te trekken, net als de ZendEncoder doet

[Orphix]

Op dinsdag 02 juli 2002 00:27 schreef ACM het volgende:
php wordt ook eerst 'just-in-time' gecompileerd bij mijn weten

Hmm misschien toch maar eens een benchmarkje doen

[mbravenboer]

ACM: php wordt ook eerst 'just-in-time' gecompileerd bij mijn weten

Echt geinterpreteerde talen zijn er niet zoveel meer volgens mij, misschien bashscripting nog?

Ik denk dat hij eigenlijk vooral doelde op het parsen en analyseren van de code. Java Bytecode leest natuurlijk een stuk makkelijker in dan Java code omdat er geen onduidelijkheid meer is over de betekenis van stukjes code. Voor PHP moet op dit gebied nog een heleboel gebeuren, maar voor Java is het resultaat van deze analyse al opgeslagen in de Java Bytecode. Ook is de code al getype-checkt.

[elnino]

Op dinsdag 02 juli 2002 00:31 schreef mbravenboer het volgende:
Ik denk dat hij eigenlijk vooral doelde op het parsen en analyseren van de code. Java Bytecode leest natuurlijk een stuk makkelijker in dan Java code omdat er geen onduidelijkheid meer is over de betekenis van stukjes code. Voor PHP moet op dit gebied nog een heleboel gebeuren, maar voor Java is het resultaat van deze analyse al opgeslagen in de Java Bytecode. Ook is de code al getype-checkt.

Volgens mij, maar ik weet dit niet zeker, is het zo dat PHP de eerste keer dat je een script uitvoert, het als het ware 'compileert', zodat het de volgende keren sneller gaat. Als je iets in je script verandert, dan wordt het weer opnieuw gedaan. Maar Java Bytecode blíjft natuurlijk iets sneller daarin en normale machinetaal is nog sneller.

Op maandag 01 juli 2002 23:51 schreef RRazoRR het volgende:
Ik heb zelf zoiets van: als ik een proggie voor windows heb geschreven en ik wil het naar linux of mac porten dan verander ik de boel wel.

Mwoah... dat porten kost soms anders nog best veel tijd. En in Java heb je direct een goede omgeving om in te ontwikkelen (object-geöriënteerd en dat soort zaken). Ik heb zelf een multi-bootsysteem met zowel Windows als GNU/Linux. Als ik dan iets in Windows maak, wil ik het graag in GNU/Linux kunnen draaien en andersom.

[mbravenboer]

ACM: Om de al door Orphix aangehaalde php-analogie dan maar door te trekken, net als de ZendEncoder doet

Ik weet niet precies wat die allemaal voor werk van de runtime afsnoept, maar ik kan me bij de vergelijking wel iets voorstellen .

[ACM]

Op dinsdag 02 juli 2002 00:36 schreef elnino het volgende:
Volgens mij, maar ik weet dit niet zeker, is het zo dat PHP de eerste keer dat je een script uitvoert, het als het ware 'compileert', zodat het de volgende keren sneller gaat. Als je iets in je script verandert, dan wordt het weer opnieuw gedaan.

Nee, dat is wat de cache/accelerators doen (apc cache, zend accelerator).

Wat de zendencoder doet is redelijk vergelijkbaar met de bytecode encoding van java, behalve natuurlijk dat de zendencoded output niet te lezen is en de byteencoded data nog best leesbaar is.

Op dinsdag 02 juli 2002 00:28 schreef Orphix het volgende:
Hmm misschien toch maar eens een benchmarkje doen

Pas maar op

Nadeel is dat je niet zo makkelijk puur php vs puur java kan testen. Maar een zendencoded file vs een '.class' is natuurlijk best wel es grappig om te testen.

Op dinsdag 02 juli 2002 00:36 schreef mbravenboer het volgende:
Ik weet niet precies wat die allemaal voor werk van de runtime afsnoept, maar ik kan me bij de vergelijking wel iets voorstellen .

Ik zie het iig zo, zal niet helemaal zijn hoe het in de werkelijkheid gaat maar dat doet er niet zo toe:
1. php wordt geparsed, foutjes opgesomt/opgelost/etc
2. php wordt gecompileerd
3. php wordt zendoptimised als die optimiser er is
4. php wordt uitgevoerd door de engine

De zendencoder doet stappen 1 t/m 3.5 voor je (de optimiser moet nog even aan het werk om de zendencoded data naar uitvoerbare code om te werken, maar de optimalisaties en parsing is al gedaan).

[Orphix]

Op dinsdag 02 juli 2002 01:34 schreef ACM het volgende:

Nee, dat is wat de cache/accelerators doen (apc cache, zend accelerator).

Wat de zendencoder doet is redelijk vergelijkbaar met de bytecode encoding van java, behalve natuurlijk dat de zendencoded output niet te lezen is en de byteencoded data nog best leesbaar is.

Ik las hier toch iets anders.

Wanneer PHP als CGI gedraaid wordt kan dat natuurlijk niet (ga ik van uit), maar het zou best kunnen dat PHP als module het wel zo aanpakt.

Die FAQ is natuurlijk ook een bron van niks, ik zou hier wel iets 'officieels' van willen lezen eigenlijk maar ik kan zo snel niks vinden op php.net

[Soultaker]

Op dinsdag 02 juli 2002 01:37 schreef Orphix het volgende:
Ik las hier toch iets anders.

Lekker samenhangend verhaal is dat:

PHP 4.0 will also allow for the caching of compiled code.

PHP does not allow for the caching of code between requests.

Ja, wat is dat nou?

Maar om een lang verhaal kort te maken: PHP compileert naar bytecode die vervolgens uitgevoerd wordt in een soort virtual machine achtig ding. Die code leent zich dus voor caching, lijkt me, mits de PHP module actief blijft tussen requests door.

Tenzij ik me ontzettend vergis, doet PHP niet aan JIT-compiling. De PHP code is geheel in C geschreven en JIT-compilatie is niet portable. Ik kan me ook niet herinneren hier ooit iets van gezien/gehoord te hebben.

[unclero]

Ikzelf heb nix tegen vm talen (C#, Parrot etc). Maar Java, tja, dat wil je niet. JBuilder eens geprobeerd. Als ik op het 'file' menuutje klikte kon ik even TV gaan kijken, voordat dat menuutje eruit kwam.
Ook maar eens een rij tutors doorgelezen. Toen wou ik wat gaan proberen, krijg ik allerlei vage errors van de java machine.
Dus nee, Java is nix voor mij. Om een amerikaanse collega te quoten:

"Keep Java in your cup and C/C++ in your cpu."

[whoami]

Op dinsdag 02 juli 2002 08:49 schreef unclero het volgende:
JBuilder eens geprobeerd. Als ik op het 'file' menuutje klikte kon ik even TV gaan kijken, voordat dat menuutje eruit kwam.

JBuilder != Java, maar een environment waarmee je in Java kunt programmeren. Als je JBuilder niet goed/traag vind, heb je nog altijd andere IDE's.

Ook maar eens een rij tutors doorgelezen. Toen wou ik wat gaan proberen, krijg ik allerlei vage errors van de java machine.

Tja, iets niet goed ingesteld misschien.


Kortom, de punten die je aanhaalt waarom Java niets voor jou is, heeft eigenlijk niets met de taal Java op zich te maken...

Ik heb zelf even van Java geproefd en het is wel een mooie taal _{maar ik vind C# lekkerder werken}, maar ik vraag me toch af of er echt veel gebruik gemaakt wordt van die platform-onafhankelijkheid op de server-kant.

[Verwijderd]

Op dinsdag 02 juli 2002 08:49 schreef unclero het volgende:
Ikzelf heb nix tegen vm talen (C#, Parrot etc). Maar Java, tja, dat wil je niet. JBuilder eens geprobeerd. Als ik op het 'file' menuutje klikte kon ik even TV gaan kijken, voordat dat menuutje eruit kwam.

Misschien eens tijd je 2Mhz bak te upgraden, nieuwe JDK en nieuwe JBuilder te downloaden? Wil vaak helpen.

[Baron]

Is Java nou echt zo handig?
Ik vind van wel. Zelf ben ik met Java maar wat aan het spelen, dus geen echte serieuze toepassingen.

Maar de kleine progjes die ik heb gemaakt (in Windows) draaien zonder problemen op AS/400 (hmm iSeries). Ook de Agents in Lotus Notes maak ik stilletjesaan in Java.

De snelheid van Java valt overigens heel goed mee. Zeker sinds v.1.4.0. Dit is met de huidige CPU power niet langer meer een nadeel.

Wat wel een nadeel is de hoeveelheid geheugen dat elk Java programma vreet. Hier moeten ze bij Sun toch eens iets aan doen.

[unclero]

Op dinsdag 02 juli 2002 10:16 schreef Zef het volgende:
Misschien eens tijd je 2Mhz bak te upgraden, nieuwe JDK en nieuwe JBuilder te downloaden? Wil vaak helpen.

Nou, ik had JBuilder 5 Ent. en ik heb Delphi 5 Ent. en beiden draaiden op mijn 'dev-bak' een 133iger. En alleen Delphi draait er vloeiend op. En ik ga niet upgraden om per se Java te willen draaien.
Maar goed, ieder zo zijn eigen favo taal.

[Alarmnummer]

Op dinsdag 02 juli 2002 10:26 schreef Baron het volgende:
Wat wel een nadeel is de hoeveelheid geheugen dat elk Java programma vreet. Hier moeten ze bij Sun toch eens iets aan doen.

Vanaf jdk1.5 kunnen verschillende java applicaties 1 vm delen. Dus dan neemt het geheugenverbruik af. Het zou handig trouwens zijn als java gewoon altijd als service op de achtergrond draaide. Trouwens geheugenverbruik van de gui van 1.4 tov 1.3 is wel drastisch afgenomen. Je bent nu een vast basis bedrag kwijt (meestal rond de 25 mb onder win) en daarna kan je een enorme ladin dingen op het scherm zetten zonder dat je extra geheugen kwijt bent.

[jopiek]

Op dinsdag 02 juli 2002 10:29 schreef Alarmnummer het volgende:

[..]

Vanaf jdk1.5 kunnen verschillende java applicaties 1 vm delen. Dus dan neemt het geheugenverbruik af. Het zou handig trouwens zijn als java gewoon altijd als service op de achtergrond draaide. Trouwens geheugenverbruik van de gui van 1.4 tov 1.3 is wel drastisch afgenomen. Je bent nu een vast basis bedrag kwijt (meestal rond de 25 mb onder win) en daarna kan je een enorme ladin dingen op het scherm zetten zonder dat je extra geheugen kwijt bent.

gewoon Delphi of C++ gebruiken, van de rare constructies in Java heb je meer last dan lust en een vuilnisman heeft een goeie programmeur niet nodig (ik ben geen programmeur trouwens maar software engineer)...

Java:
- brakke GUI's
- slechte IDE's
- vage constructies (zoals text.gooimaarineenstring )
- rare oplossingen

alleen zaken zoals remote method invocation en zo zijn in java errug fijn, ook platform-onafhankelijkheid, dit maakt java super voor server-toepassingen.
voor consumenten software is het helemaal niet echt aantrekkelijk om java te gebruiken, sowieso gebruiken die geen rare platformen.

[Alarmnummer]

Op dinsdag 02 juli 2002 10:43 schreef jopiek het volgende:

[..]

gewoon Delphi of C++ gebruiken, van de rare constructies in Java heb je meer last dan lust en een vuilnisman heeft een goeie programmeur niet nodig (ik ben geen programmeur trouwens maar software engineer)...

GC is erug handig. Het scheelt je weer vage memory leaks, en jij kan mij niet wijs maken dat je ze nooit hebt. En het kost je ook extra moeite (die ik niet nodig ben) om het correct in je design te steken. Gc is gewoon handig om te hebben.

Java:
- brakke GUI's

SWT

- slechte IDE's

Dit is nou echt dikke onzin. Met welke IDE`s heb je gewerkt als ik vragen mag? Ik neem aan dat je geen codeguide of IDEA heb geprobeerd. Of anders een UML variant zoals Rational Rose/MX of Together.

- vage constructies (zoals text.gooimaarineenstring )

begrijp je de syntax niet van een oo taal? [quote]
- rare oplossingen
[/quote[
Ik vind dat java erg mooi in elkaar steekt en dat de oplossingen over het algemeen erg goed doordacht zijn.

alleen zaken zoals remote method invocation en zo zijn in java errug fijn, ook platform-onafhankelijkheid, dit maakt java super voor server-toepassingen.

Ben ik met je eens.

voor consumenten software is het helemaal niet echt aantrekkelijk om java te gebruiken, sowieso gebruiken die geen rare platformen.

SWT

[Verwijderd]

Op dinsdag 02 juli 2002 10:43 schreef jopiek het volgende:
[..]
gewoon Delphi of C++ gebruiken, van de rare constructies in Java heb je meer last dan lust en een vuilnisman heeft een goeie programmeur niet nodig (ik ben geen programmeur trouwens maar software engineer)...

Omdat je dan toch een software engineer bent zal ik niet eens serieus op nonsens praat in gaan.

Java:
- brakke GUI's

Mja, niet echt toppers. Maar brak gaat wel erg ver.

- slechte IDE's

IntelliJ IDEA en Eclipse zijn naast de Visual Studio .NET de beste IDEs die je kunt vinden.

- vage constructies (zoals text.gooimaarineenstring )

Dat heet OO en als je niet weet hoe dat werkt betekent het niet dat het vaag of raar is.

- rare oplossingen

</gelul in de ruimte>

edit: Peter was me voor

[jopiek]

bij deze concluderen we maar weer eens dat de strijd tussen Java-lovers en haters overeenkomt met de strijd tussen Windows-lijders en Mac-idioten....



OO heeft ook wel eens nadelen en Java voert af en toe OO veel te ver door waardoor foeilelijke constructies ontstaan... sowieso blijft 't punt van brakke GUI's voor mij heel zwaar wegen aangezien ik me nu specialiseer richting educatieve software waar een goede GUI zeer belangrijk is, discussies over wat een goede GUI is heb ik al eens uitgebreid gevoerd, daar kun je de search voor gebruiken

o.a.:
[topic=204175/1/25]

[Alarmnummer]

Op dinsdag 02 juli 2002 11:00 schreef jopiek het volgende:
OO heeft ook wel eens nadelen en Java voert af en toe OO veel te ver door waardoor foeilelijke constructies ontstaan...

Als je zoveel weet van het oo gebeuren (omdat je er een oordeel over geeft), ben je wel eens bezig geweest met design patterns? Als je niet weet wat het zijn, mag je eigelijk helemaal geen oordeel geven over oo, omdat je dan nog volledig in je oo kinderschoenen staat.

[Bobco]

Op dinsdag 02 juli 2002 11:00 schreef jopiek het volgende:
sowieso blijft 't punt van brakke GUI's voor mij heel zwaar wegen aangezien ik me nu specialiseer richting educatieve software waar een goede GUI zeer belangrijk is, discussies over wat een goede GUI is heb ik al eens uitgebreid gevoerd, daar kun je de search voor gebruiken

Tja, ik zal ook niet beweren dat Swing nu ideaal is voor het bouwen van mooie en snelle GUIs, maar zoals hier al vaker opgemerkt is het sterke punt van Java vooral te vinden aan de server kant. J2EE is echt een fantastische omgeving in te werken IMHO. Nadeel is wel dat je veel keuzes moet maken (gebaseerd op nog meer leeswerk) omdat er zoveel alternatieven zijn voor sommige deelgebieden.

Voor wat betreft cross-platform ontwikkelen zijn mijn ervaringen alleen maar positief. Er wordt hier ontwikkeld op Win NT en productie gedraaid op Solaris. Geen problemen mee gehad. Zelfs de compilatie is probleemloos op beide platformen dankzij het onvolprezen Ant build-tool.

Het is hier al vaker gezegd maar een IDE als IntelliJ is dus echt fantastisch. Veel (intelligente) ondersteuning voor bijvoorbeel refactoring, realtime code analyse waarbij je meteen kunt zien of er fouten dan wel eventueel overbodige dingen in je code staan en nog veel meer...

Ik denk dat de hele discussie over de voor- en nadelen van Java niet zou moeten gaan over 'details' als GUIs en IDEs maar over de sterke en zwakke punten van Java als ontwikkelplatform. Daarbij moet je wel goed in gedachten houden wat je over het algemeen maakt. Wij doen over het algemeen server-applicaties in een heterogene omgeving, waarbij we soms niet van te voren weten op welke hardware/OS combinatie een applicatie moet gaan draaien. Voor ons was daarom de keus voor Java erg gemakkelijk gemaakt.

[jopiek]

Op dinsdag 02 juli 2002 11:06 schreef Alarmnummer het volgende:

[..]

Als je zoveel weet van het oo gebeuren (omdat je er een oordeel over geeft), ben je wel eens bezig geweest met design patterns? Als je niet weet wat het zijn, mag je eigelijk helemaal geen oordeel geven over oo, omdat je dan nog volledig in je oo kinderschoenen staat.

hoe dacht je dat je aan een HTS Informatica diploma (van de opleiding die al een aantal jaar als beste uit de bus komt) kwam zonder iets van design patterns af te weten? Dit laat al wel weer zien dat een aantal Javisten errug dom zijn
sorry voor de flame, maar zulk commentaar vind ik niet errug professioneel overkomen. Als de starter vraagt of java nou echt zo handig is probeer ik daarover mijn mening te geven... de topicstarter vroeg niet "willen alle pro- en con-java freaks hier elkaar ff subjectief afmaken?"
niet errug profession

[whoami]

Op woensdag 03 juli 2002 13:22 schreef jopiek het volgende:

hoe dacht je dat je aan een HTS Informatica diploma (van de opleiding die al een aantal jaar als beste uit de bus komt) kwam zonder iets van design patterns af te weten? Dit laat al wel weer zien dat een aantal Javisten errug dom zijn
sorry voor de flame, maar zulk commentaar vind ik niet errug professioneel overkomen. Als de starter vraagt of java nou echt zo handig is probeer ik daarover mijn mening te geven... de topicstarter vroeg niet "willen alle pro- en con-java freaks hier elkaar ff subjectief afmaken?"
niet errug profession

Het was van jou anders ook niet professioneel om te zeggen dat Java rare constructies gebruikt als die constructies gewoon de OO-manier van werken representeren.

Maar goed, misschien best terug on-topic.

[jopiek]

Op woensdag 03 juli 2002 10:01 schreef Bobco het volgende:

Het is hier al vaker gezegd maar een IDE als IntelliJ is dus echt fantastisch. Veel (intelligente) ondersteuning voor bijvoorbeel refactoring, realtime code analyse waarbij je meteen kunt zien of er fouten dan wel eventueel overbodige dingen in je code staan en nog veel meer...

ik zal eens naar IntelliJ kijken als ik tijd heb, wel aardig voor educatieve doeleinden
ik vind trouwens een goede IDE wel belangrijk. bijv. voor C++ heb je C++ Builder en Visual C++, van de laatste heb ik de .Net versie nog niet gezien, maar iig vond ik de voorgaande versies erg omslachtig, voor mij is het doel:
zo snel mogelijk een goede (ergonomisch en onderwijskundig verantwoorde) GUI in elkaar te 'gooien' en vervolgens de functionaliteit er achter te kunnen zetten, waarbij je dus de meeste tijd kwijt bent met het laatste.
Als de GUI gebruiksvriendelijk maken al een heleboel tijd kost is het voo mij meestal geen optie om het zaakje te gebruiken, vooral voor mijn richting (educatieve software) is een GUI van levensbelang voor het produkt.
Ik weet dat heel veel nerds hier graag alleen met de code bezig zijn en niets om een GUI geven, dat kan prima op servers en zo, maar in mijn richting betekent dat dat het produkt zijn doel voorbijschiet.

In mijn ogen is daarom:
* java prima geschikt voor technische software
* volledig ongeschikt voor consumerprodukten die breed gedragen moeten worden door ook veel digibeten...

Object-georienteerdheid is voor het eerste ook veel belangrijker dan voor het tweede, het is altijd dom om een techniek omwille van die techniek toe te passen zonder dat deze relevante meerwaarde levert
...

[Janoz]

Nou, voor iemand met een HTS-informatica diploma ben je wel redelijk botte statements aan het neerplanten. Dat je bepaalde constructies en oplossingen 'raar' vindt wekt bij mij meer het ID dat het 'oo-kwartje' bij jou nog niet gevallen is. Dit zijn namelijk uitspraken die veel te zien zijn bij mensen die onbewust imperatief proberen te programeren in een OO taal.

mvg Een universitair informaticus (als we toch met credentials gaan smijten)

[tomato]

jopiek: sorry voor de flame, maar zulk commentaar vind ik niet errug professioneel overkomen.

Die flame van jou was erg onprofessioneel.

Als de starter vraagt of java nou echt zo handig is probeer ik daarover mijn mening te geven...

Nee, je geeft een ongefundeerde onwaarheid uit als feit.

Ik heb alleen jouw reacties en die van Alarmnummer gelezen en ik moet zeggen dat jouw eerste reactie ook als erg onprofessioneel over komt als je dat zo zou willen noemen. Die was namelijk doordrenkt van de verkeerde stellingen, zonder argumenten. Ik vind dat niet vervelend, maar de topicstarter wil graag een objectieve en gefundeerde reactie zien.

[jopiek]

Op woensdag 03 juli 2002 13:26 schreef whoami het volgende:

[..]

Het was van jou anders ook niet professioneel om te zeggen dat Java rare constructies gebruikt als die constructies gewoon de OO-manier van werken representeren.

Maar goed, misschien best terug on-topic.

OO is een ander verhaal, OO is niet een manier, maar een verzameling van methodes, hierin bevind zich genoeg ruimte voor verschillen in implementaties, het is weer een tijdje terug dat ik m'n laatste programma in Java schreef (waar ik overigens een ruime voldoende voor had gekregen en welke werkte met allerlei snufjes als RMI etc.), maar af en toe verwachtte dat ding zulke vreselijke constructies dat in mijnogen OO zijn doel volledig voorbijschoot. Bijv. de verschillende implementatie van strings in JBuilder 5 zijn zo onlogisch en een cast is zo omslachtig met zo'n enorme methodenaam (ben ff de exacte situatie en syntax vergeten), dat dat voor mij een reden was om te denken: dit is de laatste keer java...

[whoami]

Op woensdag 03 juli 2002 13:28 schreef jopiek het volgende:

Object-georienteerdheid is voor het eerste ook veel belangrijker dan voor het tweede, het is altijd dom om een techniek omwille van die techniek toe te passen zonder dat deze relevante meerwaarde levert
...

Hoezo? De consument maakt het toch niet uit met welke technieken je product gebouwd is? Hij wil alleen maar dat het programma doet wat het moet doen, dat het goed werkt onder alle omstandigheden. (Dit geldt voor alle programma's).
Als je een programma mbhv bv OO-technieken ontwerpt en maakt (en je doet dat goed), dan biedt OO veel meer voordelen zodat je programma ook beter kan werken.
Trouwens, als je met Delphi ontwikkeld, ben je ook wel wat OO - bezig. Een form in Delphi is nl. een object, net als een button, etc... Het zijn allemaal objecten die geinstantieerd zijn van een class (in die gevallen TForm, TButton).

[jopiek]

Op woensdag 03 juli 2002 13:34 schreef whoami het volgende:

[..]

Hoezo? De consument maakt het toch niet uit met welke technieken je product gebouwd is? Hij wil alleen maar dat het programma doet wat het moet doen, dat het goed werkt onder alle omstandigheden. (Dit geldt voor alle programma's).
Als je een programma mbhv bv OO-technieken ontwerpt en maakt (en je doet dat goed), dan biedt OO veel meer voordelen zodat je programma ook beter kan werken.
Trouwens, als je met Delphi ontwikkeld, ben je ook wel wat OO - bezig. Een form in Delphi is nl. een object, net als een button, etc... Het zijn allemaal objecten die geinstantieerd zijn van een class (in die gevallen TForm, TButton).

sorry maar ik kan het niet laten:
zie o.a. deze url over de nadelen van OO
http://madlab.me.utexas.edu/~yspae/thesis/thesis/node38.html

OO is mooi en je hoeft mij echt niet uit te leggen wat OO is en hoe 't in Delphi is uitgevoerd (delphi kan inmiddels zelfs multiple inheritence, overloading etc.), mijn hele designprocessen voer ik uit m.b.v. UML (wil je 't nog meer OO hebben), maar we moeten uitkijken dat we OO niet als haarlemmerwonderolie gaan zien en denken dat alleen OO de oplossing is, OO is af en toe leuk, maar elk voordeel heeft z'n eigen nadeel, OO ook, ik heb tijdens mijn afstuderen meegemaakt dat collega's zulke idiote beslissingen maakten o.a. omwille van OO, dat zaakjes volledig de mist in gingen omdat ze keurig met oogkleppen opliepen...

[Alarmnummer]

Op woensdag 03 juli 2002 13:22 schreef jopiek het volgende:

[..]

hoe dacht je dat je aan een HTS Informatica diploma (van de opleiding die al een aantal jaar als beste uit de bus komt) kwam zonder iets van design patterns af te weten?

1) design patterns zijn geen standaard onderdeel van de HTS.
2) design pattern beginnen nu pas populair te worden, en misschien dat je het daarom gemist hebt.
3) als HTS dan goed programmeur hoeft niet te gelden. Er komen genoeg minder getalenteerde mensen vandaan, zelfs van jouw opleiding.

Dit laat al wel weer zien dat een aantal Javisten errug dom zijn

ik denk niet dat ik hier commentaar op hoef te geven

sorry voor de flame, maar zulk commentaar vind ik niet errug professioneel overkomen. Als de starter vraagt of java nou echt zo handig is probeer ik daarover mijn mening te geven...

Ik vind jouw commentaar niet bepaald professioneel overkomen.

1)jij geeft totaal geen argumenten bij jouw beweringen
2)de beweringen die je maakt die slaan eigelijk nergens op.
3)je geeft commentaar op iets waarvan je schijnbaar weinig verstand hebt.

En daarom is de topic starter ook totaal niet geholpen met dit soort advies.

niet errug profession

Ik neem aan dat je bedoelt professioneel.

[jopiek]

nog ff een toevoeging, als je volledig voor OO gaat, C# is heb ik uit betrouwbare bronnen gehoord nog veel beter OO dan Java

ik ben trouwens slecht 1 jaar afgestudeerd en Design Patterns is niet iets voor programmeurs maar voor Software Engineers (en helaas, dat ben ik).

[Alarmnummer]

Op woensdag 03 juli 2002 13:41 schreef jopiek het volgende:
nog ff een toevoeging, als je volledig voor OO gaat, C# is heb ik uit betrouwbare pronnen gehoord nog veel beter OO dan Java

Ik vind het leuk dat je dit soort dingen zegt, maar geef dan wel even een paar argumenten. Dan hebben we er allemaal iets aan.

k ben trouwens slecht 1 jaar afgestudeerd en Design Patterns is niet iets voor programmeurs maar voor Software Engineers (en helaas, dat ben ik).

Jij bent een software engineer, of een programmeur?

Maakt op zich niet uit, maar design patterns zijn voor beide partijen erg handig. Je hebt hele low level design patterns, en je hebt grotere (systeem) design patterns.

[jopiek]

Op woensdag 03 juli 2002 13:43 schreef Alarmnummer het volgende:

[..]

Ik vind het leuk dat je dit soort dingen zegt, maar geef dan wel even een paar argumenten. Dan hebben we er allemaal iets aan, want ik wil graag weten waarom dit zo is.

is toch zinloos, ullie Java-apen overtuig je toch niet ik ben gelukkig niet zo aan een taal vastgeroest, ik spring zo over van C++ naad Object Pascal, naar Java (alleen als het moet) of zelfs naar VB (dat heeft mijn voorkeur niet echt, maar soms is er noodzaak voor ivm licenties e.d.)

[whoami]

Op woensdag 03 juli 2002 13:40 schreef jopiek het volgende:

sorry maar ik kan het niet laten:
zie o.a. deze url over de nadelen van OO
http://madlab.me.utexas.edu/~yspae/thesis/thesis/node38.html

Ik vind die nadelen nogal meevallen.
Performance: Computers worden altijd maar krachter. Als je de wet van Moore indachtig bent, dan weet je dat het aantal transistoren in een chip om de 6 maanden verdubbelen.
De eventuele performance kost is niet met het blote oog waarneembaar.
start-up cost: Je moet inderdaad de OO-manier van denken aanleren, maar eens je dat onder de knie hebt is het al aanzienlijk makkelijker.
Trouwens, die start-up cost heb je bij alle nieuwe technologiën, als je dat moet geloven, dan zou iedereen nog met dezelfde technologiën werken als 30 jaar geleden. Momenteel wordt object-oriënted technology trouwens onderwezen in alle zichzelf respecterende informatica-opleidingen.

De argumenten die je hier aandraagt als nadelen van OO vind ik dus zo geen onoverkomelijke nadelen, en de voordelen van OO wegen trouwens meer dan op tegen die 'nadelen'.

[Verwijderd]

Op woensdag 03 juli 2002 13:41 schreef jopiek het volgende:
nog ff een toevoeging, als je volledig voor OO gaat, C# is heb ik uit betrouwbare bronnen gehoord nog veel beter OO dan Java

Da's fijn te horen. Wederom een geweldig beargumenteerde stelling geponeerd, we komen er wel

[whoami]

Op woensdag 03 juli 2002 13:41 schreef jopiek het volgende:
nog ff een toevoeging, als je volledig voor OO gaat, C# is heb ik uit betrouwbare bronnen gehoord nog veel beter OO dan Java

Ik zou zeggen, verdiep je eerst in iets alvorens je daar een mening of geruchten gaat over verspreiden.
C# is niet meer OO dan Java en omgekeerd.

[Verwijderd]

Op woensdag 03 juli 2002 13:46 schreef jopiek het volgende:
[..]
is toch zinloos, ullie Java-apen overtuig je toch niet ik ben gelukkig niet zo aan een taal vastgeroest, ik spring zo over van C++ naad Object Pascal, naar Java (alleen als het moet) of zelfs naar VB (dat heeft mijn voorkeur niet echt, maar soms is er noodzaak voor ivm licenties e.d.)

Wederom fijn te horen. Lekker makkelijk ook Alarmnummer uit te maken voor 'java-aap' terwijl je zelf niet in staat bent te argumenteren. Op de middelbare school leerden we daar ooit een mooie term voor, ben hem helaas vergeten.

[tomato]

Zef: Op de middelbare school leerden we daar ooit een mooie term voor, ben hem helaas vergeten.

Ik meen dat het iets was met zwart en een ketel

_{[edit] Hoewel die hier niet erg verdiend voor Alarmnummer zou zijn imho.}

[Bobco]

Op woensdag 03 juli 2002 13:28 schreef jopiek het volgende:
[..]
ik zal eens naar IntelliJ kijken als ik tijd heb, wel aardig voor educatieve doeleinden
[..]

Als ik jou zo lees dan zal IntelliJ waarschijnlijk ook een teleurstelling voor je zijn. Waar jij volgens mij naar op zoek bent is een GUI-builder en hoop je die in de IDE te vinden. Wat dat betreft kun je beter JBuilder dan IntelliJ gebruiken. In JBuilder kun je vrij snel een GUI in elkaar klikken en slepen. De code die daarvoor gegenereerd wordt is echter niet zo overzichtelijk. Kleine aanpassingen achteraf kunnen dan wat lastiger zijn omdat je eerst de weg moet zoeken in de code die JBuilder heeft gegenereerd.

In mijn ogen is daarom:
* java prima geschikt voor technische software
* volledig ongeschikt voor consumerprodukten die breed gedragen moeten worden door ook veel digibeten...
...

Java zou ook niet mijn eerste keus zijn voor een programma dat bijna alleen maar uit GUI bestaat. Aan de andere kant is er een duidelijke ontwikkeling gaande naar server-based applicaties, een gebied waar Java op dit moment met afstand de beste keus is.

Ik denk dan ook dat je oorspronkelijke vraag niet zo goed was. Het is niet de vraag of Java echt zo handig is, maar of Java wel zo handig is voor het oplossen van een specifiek probleem. Ik denk dat Java een goede oplossing heeft voor een heleboel problemen die spelen aan de serverkant. Clients met GUIs is een ander verhaal.

[Orphix]

Op woensdag 03 juli 2002 13:47 schreef whoami het volgende:
Ik vind die nadelen nogal meevallen.

Inderdaad. In C++ is het zelfs zo dat de compiler zoveel mogelijk statische binding zal toepassen wanneer het daar zeker van is. Classes zonder vtable (geen virtual functions) hebben automatisch geen dynamische binding natuurlijk.
Ik weet eigenlijk niet hoe dit in Java/C# zit maar ik kan me goed voorstellen dat dit ook goed geoptimaliseerd worden.
Verder heb ik de grootte van het programma nooit interessant gevonden. Tegenwoordig overstijgt de ruimte die de data die een programma gebruikt (plaatjes,muziek,database) altijd de grootte van de applicatie zelf. Ook voor mobile devices maakt die 100kb extra niet zoveel meer uit.

[.oisyn]

Op woensdag 03 juli 2002 13:46 schreef jopiek het volgende:

[..]

is toch zinloos, ullie Java-apen overtuig je toch niet ik ben gelukkig niet zo aan een taal vastgeroest, ik spring zo over van C++ naad Object Pascal, naar Java (alleen als het moet) of zelfs naar VB (dat heeft mijn voorkeur niet echt, maar soms is er noodzaak voor ivm licenties e.d.)

zo zo, stoer hoor

^{tot zover deze interessante mededeling}

[raptorix]

idd, en als ie toch zo makkelijk over springt, vraag ik mij af waarom ie dan dit topic start

Beetje dom figuur imo.

[Orphix]

Op woensdag 03 juli 2002 18:05 schreef raptorix het volgende:
idd, en als ie toch zo makkelijk over springt, vraag ik mij af waarom ie dan dit topic start

Beetje dom figuur imo.

jopiek is niet de topic starter.

[raptorix]

Op woensdag 03 juli 2002 18:13 schreef Orphix het volgende:

[..]

jopiek is niet de topic starter.

Klopt

[Soultaker]

Op woensdag 03 juli 2002 14:10 schreef Orphix het volgende:
Inderdaad. In C++ is het zelfs zo dat de compiler zoveel mogelijk statische binding zal toepassen wanneer het daar zeker van is. Classes zonder vtable (geen virtual functions) hebben automatisch geen dynamische binding natuurlijk.

Waarop baseer je dit? Het lijkt me dat de compiler virtuele functies (dynamisch gebonden functies in C++) altijd moet respecteren aangezien de functies die van deze klassen gebruik maken anders niet compatibel zijn met klassen die uit bijvoorbeeld een library geladen worden.

Verder ondersteund in ieder geval x86-assembly een indirect call opcode, waarmee een indirecte ('dynamische') call dus op hardwarenivo uitgevoerd kan worden. In microcode zal het weliswaar nog minder efficient zijn dan een directe call (er blijft een extra fetch stap tussenzitten) maar dit effect is vrijwel te verwaarlozen ten opzichte van de totale (relatief hoge) kosten van een call.

Ik ben het dus met jou en whoami eens dat dynamische binding zeer weinig effect zal hebben op de efficientie van een applicatie, maar ik denk niet dat de compiler daar veel mee te maken heeft.

[Orphix]

Op woensdag 03 juli 2002 19:58 schreef Soultaker het volgende:
Waarop baseer je dit? Het lijkt me dat de compiler virtuele functies (dynamisch gebonden functies in C++) altijd moet respecteren aangezien de functies die van deze klassen gebruik maken anders niet compatibel zijn met klassen die uit bijvoorbeeld een library geladen worden.

Ik quote uit 'De programmeertaal C++' van Bjarne Stroustrup:
Een type met virtuele functies wordt een polymorf type genoemd. Om in C++ polymorf gedrag te krijgen, moeten er virtual functies worden gebruikt en moeten de objecten via pointers of referenties worden benaderd. Als objecten rechtstreeks worden benaderd (dus niet via pointers of referenties), dan weet de compiler het precieze type en dan is run-time-polymorfie dus niet nodig

En verderop

Als bij het aanroepen van een functie de operator :: wordt gebruikt (bijvoorbeeld Manager::print()) dan wordt het virtuele mechanisme niet gebruikt.


Daar doelde ik dus op, zoals in de volgende code:

code:

class Car
{
   virtual void Drive() { ... }
}
class Mercedes : public Car
{
   void Drive()
   {
     Car::Drive(); // <-- Hier statisch (logisch anders recursie)
   }
}

...

Car mercedes;
mercedes.Drive(); // <-- hier wordt ook statisch gelinkt

[Soultaker]

Op woensdag 03 juli 2002 20:19 schreef Orphix een uitleg over statische binding van virtuele functies in C++.

Ah, dat maakt het een heel stuk duidelijker. Ik ging er onterecht vanuit dat je bedoelde dat de compiler entries uit de vtable weg zou laten, wanneer 'm dat zo uit kwam, maar dat kan natuurlijk niet.

De compiler kan inderdaad voor lokaal gedeclareerde objecten statische binding toepassen, evenals wanneer gespecificeerde is welke methode aangeroepen moet worden (wat inderdaad niet meer dan logisch is).

[The - DDD]

Op woensdag 03 juli 2002 13:22 schreef jopiek het volgende:

[..]

hoe dacht je dat je aan een HTS Informatica diploma (van de opleiding die al een aantal jaar als beste uit de bus komt) kwam zonder iets van design patterns af te weten? Dit laat al wel weer zien dat een aantal Javisten errug dom zijn

Grappige is dat heel veel java constructies, zoals het event handling verhaal van Swing, gebaseerd zijn op design patterns. En ik geloof zelfs dat IEDER pattern in het GOF boek in de java API terug te vinden is.

En jongens, laat het duidelijk zijn, veel HTS/HBO informatica leren je niet zozeer iets op technisch gebied, maar meer op gebied van functioneren, ZEGGEN ZE.

Op zich moet ikzelf toegeven dat ik in mijn inmiddels (sinds 2 weken) afgeronde HBO periode nog het meest geleerd heb van zelfstudie en hobby-bobpen.

[Soultaker]

Op woensdag 03 juli 2002 20:29 schreef The - DDD het volgende:
Op zich moet ikzelf toegeven dat ik in mijn inmiddels (sinds 2 weken) afgeronde HBO periode nog het meest geleerd heb van zelfstudie en hobby-bobpen.

Daar leer je altijd het meeste van. De gemiddelde student besteed veel meer tijd aan 'vrije tijd' dan aan studeren, dus als maar een klein deel van die vrije tijd aan hobbyen besteed wordt, gaat dat al snel over de geplande studietijd heen. Daar komt nog bij dat 'studietijd' maar voor een deel op de praktijk gericht is, terwijl in de praktijk ervaring opdoen ook een goede manier van leren is.

[Alarmnummer]

Op woensdag 03 juli 2002 20:29 schreef The - DDD het volgende:

[..]

Grappige is dat heel veel java constructies, zoals het event handling verhaal van Swing, gebaseerd zijn op design patterns. En ik geloof zelfs dat IEDER pattern in het GOF boek in de java API terug te vinden is.

Ik ben het visitor design pattern nog niet tegen gekomen, en dat is naar mijn mening het beste uit het design patterns boek Maar verder tref je inderdaad een enorme lading design patterns aan.

En jongens, laat het duidelijk zijn, veel HTS/HBO informatica leren je niet zozeer iets op technisch gebied, maar meer op gebied van functioneren, ZEGGEN ZE.

Op zich moet ikzelf toegeven dat ik in mijn inmiddels (sinds 2 weken) afgeronde HBO periode nog het meest geleerd heb van zelfstudie en hobby-bobpen.

Ben ik helemaal met je eens, maar je moet wel oppassen dat je opleiding niet te lang gaat duren *moet dit jaar ok maar eens afstuderen, en kan daarna weer verder met de volgende*..

trouwens 90% van mijn kennis komt voort uit zelfstudie, en niet zozeer de HTS.

[Glimi]

Op donderdag 04 juli 2002 00:54 schreef Alarmnummer het volgende:
Ik ben het visitor design pattern nog niet tegen gekomen, en dat is naar mijn mening het beste uit het design patterns boek Maar verder tref je inderdaad een enorme lading design patterns aan.

Man ik ben het begrip "design pattern" nog niet tegengekomen op mijn school (HIO, 3 jaars). De meeste uit mijn klas weten net hoe een stack werkt ( aldus een van mijn klasgenoten: "Oh het is dus gewoon een beschuitblik!" )

[whoami]

Op donderdag 04 juli 2002 00:54 schreef Alarmnummer het volgende:

het design patterns boek Maar verder tref je inderdaad een enorme lading design patterns aan.

Een beetje off-topic van mij, maar over welk boek hebben we het hier dan?
* whoami zou wel een goed boek over design-patterns kunnen gebruiken.

[Alarmnummer]

het boek

Je kan ook gaan voor een java variant.

en hier heb je nog een matige die online staat. Goed voor een eerste indruk, maar verder vind ik hem niet geweldig. Over het algemeen staan dezelfde design patterns in de boeken, dus het maakt niet zoveel uit welke je koopt. Maar naar het boek wordt altijd verwezen vanuit andere boeken.

verder heb ik nu deze ook in huis:
Pattern-Oriented Software Architecture, Volume 1: A System of Patterns
Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects

Ze lezen erg goed weg, en ben op dit moment bezig met het eerste boek om allerlei design patterns die ik al een tijd gebruik nog eens goed door te nemen. Maar ik zou eerst voor het boek gaan.

Trouwens het boek van Doug Lee:
Concurrent Programming in Java(TM): 'Design Principles and Pattern (2nd Edition)' is ook een design patterns aanrader. In dit boek staan ook erg veel design patterns vermeld.

Man ik ben het begrip "design pattern" nog niet tegengekomen op mijn school (HIO, 3 jaars). De meeste uit mijn klas weten net hoe een stack werkt ( aldus een van mijn klasgenoten: "Oh het is dus gewoon een beschuitblik!" )

Sommige mensen bij ons weten bv niet wat backtracking is .

[Xanthus]

Thinking in Patterns in Java van Bruce Eckel
Ik vond het wel een goed boek, maar dat is dan ook het enig design pattern boek wat ik ooit gelezen heb

[jopiek]

Op donderdag 04 juli 2002 11:13 schreef Alarmnummer het volgende:
het boek

Je kan ook gaan voor een java variant.

en hier heb je nog een matige die online staat. Goed voor een eerste indruk, maar verder vind ik hem niet geweldig. Over het algemeen staan dezelfde design patterns in de boeken, dus het maakt niet zoveel uit welke je koopt. Maar naar het boek wordt altijd verwezen vanuit andere boeken.

verder heb ik nu deze ook in huis:
Pattern-Oriented Software Architecture, Volume 1: A System of Patterns
Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects

Ze lezen erg goed weg, en ben op dit moment bezig met het eerste boek om allerlei design patterns die ik al een tijd gebruik nog eens goed door te nemen. Maar ik zou eerst voor het boek gaan.

Trouwens het boek van Doug Lee:
Concurrent Programming in Java(TM): 'Design Principles and Pattern (2nd Edition)' is ook een design patterns aanrader. In dit boek staan ook erg veel design patterns vermeld.
[..]

Sommige mensen bij ons weten bv niet wat backtracking is .

lijkt me wel een erg slechte opleiding dan, dit is het curriculum in leeuwarden:

vakkenlijst

dit zijn toch wel de betere vakken:
http://www.engineering.tem.nhl.nl/vakbs.html?NT=1&DB=engindb&OPL=HI&VakCode=PRC&COLOR=4090a0&BCOLOR=9dc6cd

en

http://www.engineering.tem.nhl.nl/vakbs.html?NT=1&DB=engindb&OPL=HI&VakCode=SEN&COLOR=4090a0&BCOLOR=9dc6cd

komt trouwens niet voor niets jaar in jaar uit een van de allerbeste opleidingen uit de bus...

[Alarmnummer]

Op maandag 15 juli 2002 12:14 schreef jopiek het volgende:

[..]

lijkt me wel een erg slechte opleiding dan, dit is het curriculum in leeuwarden:

Dit ligt niet zo zeer aan de vakken die gegeven worden (back tracking is wel een vast onderdeel van de studie). Maar het gaat meer om hoe het ingeleverd moet worden. Ik heb tegen mijn 'collega' gezegd, ik schrijf de software en wij leveren het in, oke? *het moest met zijn 2en, en ik ben gek op stille partners'. En zo gebeurd het eigelijk vrij vaak.

komt trouwens niet voor niets jaar in jaar uit een van de allerbeste opleidingen uit de bus...

hmmzz.. dit vraagt natuurlijk wel om een eerlijke mening. Ik heb als ik eerlijk ben zeker geen hoge pet op van Leeuwarden. De studenten krijgen naar mijn mening veel te hoge cijfers (we hebben wel eens stagaires gehad). En de stagaires die kunnen niet veel meer dan een beetje in delphi programmeren en een klein beetje java en stellen nog een vraag van 'wat is een dosprompt? (hij kon ook geen linux voor de duidelijkheid)' . Er zullen natuurlijk altijd mensen zijn die behoorlijk wat kunnen, maar ik vind Leeuwarden toch vrij ouderwets en naar mijn ervaring ook triest.

[mbravenboer]

Een goede opleiding is zeker belangrijk, maar als het om kwaliteiten van de afstudeerders gaat, zijn er meer punten die meetellen. Deze kwaliteiten worden vooral bepaald door interesse, eigen initatief, ervaring en motivatie. Als individuen op veel van deze punten scoren kunnen ze ver boven het gemiddelde uitstijgen.

Het belangrijkste van een opleiding vind ik het beiden van een stimulerende leeromgeving. Waarschijnlijk hangt dit echter weer voor een groot deel samen met de kwaliteit van de opleiding. Een stimulerende leeromgeving ontstaat imho vooral door betrokken en gemotiveerde docenten, wat ook zal zorgen voor opleiding van goed niveau....

[roelio]

Op maandag 15 juli 2002 12:28 schreef Alarmnummer het volgende:
Er zullen natuurlijk altijd mensen zijn die behoorlijk wat kunnen, maar ik vind Leeuwarden toch vrij ouderwets en naar mijn ervaring ook triest.

en bedankt
zoals je zelf al zegt, een beetje Informatica student doet ook nog wat aan zelfstudie

Het belangrijkste van een opleiding vind ik het beiden van een stimulerende leeromgeving. Waarschijnlijk hangt dit echter weer voor een groot deel samen met de kwaliteit van de opleiding. Een stimulerende leeromgeving ontstaat imho vooral door betrokken en gemotiveerde docenten, wat ook zal zorgen voor opleiding van goed niveau....

en dat is vaak een groot probleem ...

[Alarmnummer]

Op maandag 15 juli 2002 12:55 schreef limoentje het volgende:
en bedankt
zoals je zelf al zegt, een beetje Informatica student doet ook nog wat aan zelfstudie

precies.

en dat is vaak een groot probleem ...

Ik heb mijn grote stage en mijn afstudeer opdracht gedaan bij de sectie rechtinformatica van de Rijks Universiteit Groningen, en dat is me zeer goed bevallen. Ik heb daar een gigantische uitdaging voorgeschoteld gekregen en ik ben er nu al weer bijna een jaar in dienst. Deze plek heeft me behoorlijk geinspireerd, maar de meeste motivatie vind ik hier wel op GoT/Javahova.

[TheOneLLama]

Op woensdag 03 juli 2002 14:10 schreef Orphix het volgende:
Ook voor mobile devices maakt die 100kb extra niet zoveel meer uit.

Laat ik beginnen met zeggen dat ik het daarmee niet echt mee eens ben . Veel mobiele JAVA devices hebben een *totale* storage van zo'n 100kb, met een limiet die per applicatie nog minder is (tot 15KB zelf). Dat betekend niet dat JAVA ongeschikt is voor dit soort dingen, na obfusication is JAVA behoorlijk code intensive. Natuurlijk moet je wel een beetje slim progammeren (geen final Strings bv.) maar dat moet je als je als je in C(++) bezig bent natuurlijk ook.

JAVA heeft in mijn ogen enorm veel voordelen. Het is niet alleen een erg nette en schone taal, maar er zit ook een enorm goed framework omheen, wat op een erg consistente manier op meerdere profielen wordt doorgevoerd (J2EE, J2SE, J2ME, PJAVA, Embedded JAVA, etc.). Iets wat geen enkele andere taal of omgeving (inclusief C) bied.

Waar ik JAVA nog steeds minder vind is op de desktop, en wat daar meestal voor gebruikt wordt, de AWT/Swing implementatie van SUN (de implentatie van Apple op Mac OS X schijnt stukken beter te zijn, maar hier heb ik zelf geen ervaring mee). Gelukkig schijnen er in 1.4 al enorme verbeteringen op dit gebied, en zijn er initiatieven zoals SWT die een alternatief bieden.