[.NET] Bertrand Meyer over language-interop

[mbravenboer]

(dit had ik eerst elders gepost, maar een discussie hier trekt misschien wat meer .NET kenners aan (Otis bijvoorbeeld ) die kunnen bijdragen aan de discussie).

Hier een heel goed stukje van Chris Rathman op Lambda the Ultimate.

Het is een reactie op dit verhaal van Bertrand 'Eiffel' Meyer.

<?human-reader lees eerst beide stukken voor je verder gaat?>

Ik ben het niet vaak zo met iemand eens als met dit stukje van Chris . Overigens heeft Bertrand natuurlijk ook gelijk dat het om de mapping gaat (wat natuurlijk bij elke taal en in elke compiler zo is), maar het is de vraag of dit nu echt een argument is voor de multi-language capaciteiten van .NET versus andere systemen als Java imho.

Stratego kunnen we ook compileren naar Java, Haskell kan gecompileerd worden naar Java. Alles kan gecompileerd worden naar Java, maar het is de vraag of het resultaat van de mapping acceptabel is.

Dit is in ieder geval een onzinnige, niet onderbouwde statement imho:

What does it take to support several programming languages within one environment? .NET, which has taken language interoperability to new heights

.NET heeft wellicht een van de beste omgevingen geboden waarin language interop vrij eenvoudig te realiseren is, maar het is zeker geen kwestie van revolutionair werk. De praktische samenstelling en presentatie van de tools en het platform zorgen voor 'new heights', niet de technologie.

Microsoft's .NET breaks this lock

Volgens mij hebben standaarden voor stack-frame layouts dit slot doorbroken, maar goed...

Dit is helemaal schandalig:

Everyone will benefit, even the Java community: Now that there's competition again, new constructs are--surprise!--again being considered for Java; one hears noises, for example, about Sun finally introducing genericity sometime in the current millennium. Such are the virtues of openness and competition.

De preface van de Java Language Specifcation 1.0 uit 1996 sprak al over generics voorstellen toen Microsoft nog in de verste verte geen idee van .NET had (MS Windows 95 was net uit ) en de eerste GJ compiler was al goed bruikbaar voordat er ook maar 1 regel code van .NET was geimplementeerd. Generics zijn in de verste verte geen reactie op NET.

What is new is that the object model, as we've seen in detail, retains high-level structures such as classes and inheritance that have direct equivalents in source programs written in modern programming languages, especially object-oriented ones.

Hum, what's new? Java Bytecode doet exact hetzelfde.

But it's definitely incorrect if we consider the entire set of .NET language players. The case of non-OO languages is the most obvious: Right from the initial announcements, .NET has included languages like APL and Fortran, which no one would accuse of being object oriented.

Ok, maar ze moeten zich wel aanpassen aan het OO-target met alle gevolgen van dien. Wat is nieuw tov Java? Meer instructies en een wat uigebreider object-model, das alles. Fijn voor language-interop? Ja. Een wereldschok op dit gebied? Mwah.

Managed C++ is very close to C#, in spite of what the default Microsoft descriptions would have you believe.

The signal to C++ developers is hard to miss: The .NET designers don't think too highly of the C++ object model and expect you to move to the modern world as they see it.

Tjonge, jonge hoe blind kan je zijn? C++ is niet aangepast om Microsoft het object-model van C# superieur vond aan dat van C++. C++ zou nooit goed in .NET passen (prettig aanvoelen) als het niet aangepast was.

Mijn indruk van Bertrand is met dit stuk wel drastisch slechter geworden.

[Jrz]

Ik heb mjion eigen meningen ove Java/JVM vs C#/.NET

Maar die komen aardig overheen met wat jij schrijft...

[Verwijderd]

Mbravenboer: val niet voor goedkope marketing retoriek en zealotisme . Als iemand .NET's taleninteroperabiliteit () geweldig vindt en met de voordelen in zn hand een stuk schrijft (Meyer) en daar een reactie op komt van mensen die alleen de nadelen zien... tja, film at 11. Ik vind .NET heel gaaf, maar niet om de taleninteroperabiliteit. Wat ik wel vind is dat het wel erg meehelpt voor het succes: mensen die VB.net programmeren kunnen dezelfde api gebruiken, dezelfde functionaliteit en tools. DAT is wat het zo gaaf maakt. Puristisch zemelen wat wel / niet correct is is IMHO zo'n tijdverspilling: het is ten eerste al moeilijk te definieren wat 'correct' inhoudt (want daar zijn de meningen al over verdeeld) en al helemaal OF een techniek dan aan die definitie voldoet en als dat NIET zo is, wat ga je dan doen? Oeverloos zeuren dat het niet 'correct' is? Lijkt me productief

.NET is een platform en hoe je dat gebruikt zal voor iedereen verschillend zijn. Ik begrijp niet waar Chris Rathman de tijd vandaan haalt uberhaupt te gaan reageren op een stuk van een of andere taalontwerper. Die tijd kun je ook goed gebruiken voor het bouwen van goede software.

note: ik vind bv C++ een van de meest verschrikkelijke talen op aarde. Degene die templates heeft verzonnen moet accuut elk contact met computers worden verboden en verplicht worden boeken over leesbare code te lezen. Belangrijk? Nee, want miljoenen developers dwepen met Straustrupp's taal.

[Verwijderd]

Op donderdag 09 mei 2002 10:32 schreef mbravenboer het volgende:
Hier een heel goed stukje van Chris Rathman op Lambda the Ultimate.

Persoonlijk vind ik dit niet echt overtuigend, die Chris heeft wel gelijk, maar ik ben eerder door jou, dan door hem overtuigd

Stratego kunnen we ook compileren naar Java, Haskell kan gecompileerd worden naar Java. Alles kan gecompileerd worden naar Java, maar het is de vraag of het resultaat van de mapping acceptabel is.

Klopt, maar is het niet zo dat .Net door de met opzet generieke CLR een betere basis vormt?
Java bytecode is van het begin af aan er op gericht om Java source te representeren. Als je nu bv. Haskell naar Java bytecode compileerd moet je heel veel consesies doen. Het komt er eigenlijk op neer dat je je Haskell naar Java omschrijft, en dat compileerd.
Ik kan me voorstellen (maar zeker weten doe ik het niet) dat de CLR al veel generieker van opzet is, en zo dus ook minder eisen stelt aan de taal, waardoor een betere mapping mogelijk is. En dat zou dan de kwaliteit van het resultaat kunnen vergroten.

De preface van de Java Language Specifcation 1.0 uit 1996 sprak al over generics voorstellen toen Microsoft nog in de verste verte geen idee van .NET had (MS Windows 95 was net uit ) en de eerste GJ compiler was al goed bruikbaar voordat er ook maar 1 regel code van .NET was geimplementeerd. Generics zijn in de verste verte geen reactie op NET.

Wie aan Java generics komt, komt aan mbravenboer . Maar wat wel gezegd moet worden is dat het in Java eeuwen duurt voordat generics eindelijk in een echte versie komen (om je eigen quote te gebruiken, nu al 6 jaar!). Wat ik van .Net begreep, is dat ze nu al serieuze plannen hadden om het in versie 2.0 te integreren (wanneer die dan ook mogen uitkomen).
Door al dat getreuzel van Java lok je zulke uitspraken ook uit...

[mbravenboer]

Otis: val niet voor goedkope marketing retoriek en zealotisme .

Hum, als je die indruk hebt, moet ik toch maar eens wat tijd gaan besteden aan zelf-onderzoek .

Als iemand .NET's taleninteroperabiliteit ()

t21t .

geweldig vindt en met de voordelen in zn hand een stuk schrijft (Meyer) en daar een reactie op komt van mensen die alleen de nadelen zien... [/quote]
Nou ja, mijn probleem is dat Bertrand een gerespecteerd figuur is en zelfs adjunct professor. Van zo iemand verwacht ik een objectieve kijk op de zaak en de capaciteit om een evenwichtige analyse te geven van de situatie. Wat dit stuk ook is, hier voldoet het in de verste verte niet aan. Als Bertrand hier al niet toe in staat is, is het triest gesteld met de wereld, maar dat wisten we eigenlijk al....

Het is prima om een stuk te schrijven over de language interop van .NET, maar beschrijf dan ook de echte voordelen (de aangename omgeving, uitgebreider object-model) en doe niet net alsof .NET op dit punt een technologische doorbraak is qua mogelijkheden.

Ik vind .NET heel gaaf, maar niet om de taleninteroperabiliteit.

Shit, daar gaat de discussie .

Puristisch zemelen wat wel / niet correct is is IMHO zo'n tijdverspilling: het is ten eerste al moeilijk te definieren wat 'correct' inhoudt (want daar zijn de meningen al over verdeeld) en al helemaal OF een techniek dan aan die definitie voldoet en als dat NIET zo is, wat ga je dan doen? Oeverloos zeuren dat het niet 'correct' is? Lijkt me productief

Mwah, daar ben ik het toch niet mee eens. Het is belangrijk om te analyseren wat er nu goed is aan .NET en waardoor dat wordt veroorzaakt in vergelijking met bijvoorbeeld Java. Het doel hiervan is niet zozeer om .NET of Java als het betere platform naar voren te schuiven (want dat zou pas echt een onzinnige bezigheid zijn), maar om te helpen bij toekomstige ontwikkelingen met als doel om het wellicht nog beter te doen .

.NET is een platform en hoe je dat gebruikt zal voor iedereen verschillend zijn. Ik begrijp niet waar Chris Rathman de tijd vandaan haalt uberhaupt te gaan reageren op een stuk van een of andere taalontwerper. Die tijd kun je ook goed gebruiken voor het bouwen van goede software.

Mwah, een beetje meta-discussie kan absoluut geen kwaad. Als je alleen maar software wilt produceren: prima, dan kan je je tijd beter besteden. Hele horden mensen zijn echter ook bezig met het analyseren van het vakgebied en dat is toch echt erg belangrijk. Als dit niet zou gebeuren, zouden conferenties erg stil zijn en tijdschriften erg leeg...

Wat zal je mijn post zinloos vinden .

Dit lijkt na 3 posts meer op een discussie over meta-discussies... .

Degene die templates heeft verzonnen moet accuut elk contact met computers worden verboden en verplicht worden boeken over leesbare code te lezen.

Hehe . Om toch nog even een poging tot het opstarten van een discussie te doen: wat vind je dan van Java/C# Generics (geparameterizeerde typen)?

[mbravenboer]

KoenM: Persoonlijk vind ik dit niet echt overtuigend, die Chris heeft wel gelijk, maar ik ben eerder door jou, dan door hem overtuigd

Laten we het er maar op houden dat Chris subtiel tracht te blijven .

Java bytecode is van het begin af aan er op gericht om Java source te representeren. Als je nu bv. Haskell naar Java bytecode compileerd moet je heel veel consesies doen. Het komt er eigenlijk op neer dat je je Haskell naar Java omschrijft, en dat compileerd.

Dat je veel consessies moet doen is volledig juist, maar dat is ook juist de kern van m'n stukje . In tegenstelling tot wat veel mensen denken is het model .NET namelijk niet enorm veel anders dan dat van Java. Het enige echt grote verschil is een veel grotere instructie-set, value-types en ref-parameters. De 'versyntaxing' van dit model is exact C#. Compilatie naar .NET kan je je dus voorstellen als compilatie naar C#, net als je compilatie naar Java Bytecode kan voorstellen als compilatie naar Java. De uitgebreidheid van C#/.NET IL Dat is zeker een aanwinst voor language-interop, maar feit is wel dat alles zich moet uitdrukken in het object-model van .NET.

De discussie zou dus moeten gaan over de vraag in hoeverre dit model verschilt van het model van Java. Daarbij kan je tot de conclusie komen dat value-types en ref-parameters serieuze performance-voordelen hebben bij het compileer van exotischere talen naar .NET IL tov Java.

Dat er een mapping mogelijk is, is theoretisch heel leuk, maar het succes van het verhaal hangt toch echt af van het resultaat van deze mapping.

Maar wat wel gezegd moet worden is dat het in Java eeuwen duurt voordat generics eindelijk in een echte versie komen (om je eigen quote te gebruiken, nu al 6 jaar!).

Dat is waar, het heeft zeker een aardig tijdje geduurd, maar vergeet daarbij niet dat er vrijwel geen ervaring is met geparameterizeerde typen in veel gebruikte talen. Dit is eigenlijk best nieuw en er moest behoorlijk wat onderzoek gedaan worden naar de runtime-gevolgen hiervan. Het is nooit goed als JSR's volkomen nieuwe terreinen gaan aanpakken, zonder dat er goed bekeken is wat de alternatieven zijn.

Wat ik van .Net begreep, is dat ze nu al serieuze plannen hadden om het in versie 2.0 te integreren (wanneer die dan ook mogen uitkomen).

Klopt. Ik vind het eigenlijk ook erg jammer en onbegrijpelijk dat ze dit niet gelijk opgenomen hebben. Het vereist een uitbreiding van het object-model (Generics worden doorgevoerd tot in de kern van .NET en is dus geen syntaxtische suiker) en een behoorlijke aanpassing van de API. Doodzonde dat dit niet gelijk is doorgevoerd, want ze krijgen nu op kleinere schaal (vanwege de recentheid van .NET) exact dezelfde problemen als Java heeft met de introductie van Generics.

Door al dat getreuzel van Java lok je zulke uitspraken ook uit...

Ach, Bertrand had veel betere voorbeelden kunnen noemen als attributen, auto-boxing, const en enums... Beetje dom om generics erbij te halen....

[Verwijderd]

Op donderdag 09 mei 2002 11:03 schreef mbravenboer het volgende:
Nou ja, mijn probleem is dat Bertrand een gerespecteerd figuur is en zelfs adjunct professor. Van zo iemand verwacht ik een objectieve kijk op de zaak en de capaciteit om een evenwichtige analyse te geven van de situatie. Wat dit stuk ook is, hier voldoet het in de verste verte niet aan. Als Bertrand hier al niet toe in staat is, is het triest gesteld met de wereld, maar dat wisten we eigenlijk al....

Waarom? Iedereen heeft belangen. Als Bertrand het had gepubliceerd als wetenschappelijke publicatie, dan had je meer dan gelijk gehad. Maar een column achtige publicatie mag van mij vol staan van de eigen mening van de publicist. Ik deel je kritiek op de punten die je aanhaalt ook niet. Hij omschrijft .NET niet als revolutie en volgens mij lees je meer in de woorden dan dat er staat. Het punt is ook dat wat voor jou als goed argument wordt ervaren, voor anderen irrelevant is. Dat zie je bij politieke discussies en ook bij dit soort discussies. De note die ik heb toegevoegd aan mn posting staat er dan ook niet voor niks: iedereen die templates e.d. geweldig vindt en al die redenen die daarvoor gegeven worden... ik vind het lariekoek. Nu is die mening van mij totaal irrelevant maar het geeft hopelijk aan dat wat de een kan roepen voor de ander onzin blijkt te zijn.

Het is prima om een stuk te schrijven over de language interop van .NET, maar beschrijf dan ook de echte voordelen (de aangename omgeving, uitgebreider object-model) en doe niet net alsof .NET op dit punt een technologische doorbraak is qua mogelijkheden.

Ik vind .NET wel een doorbraak qua mogelijkheden, want het biedt talenbouwers een platform om hun taal meteen te koppelen aan een rijke API en objectmodel. Ik zie die mogelijkheid ECHT NIET in bv het javakamp: er is geen toegankelijke SDK voor java, zodat je bv VB kunt omschrijven in rules zodat je VB kunt compileren naar java bytecode en de java API kunt gebruiken in VB.

Mwah, daar ben ik het toch niet mee eens. Het is belangrijk om te analyseren wat er nu goed is aan .NET en waardoor dat wordt veroorzaakt in vergelijking met bijvoorbeeld Java.

Goed voor de marketeers bij Sun ja Ik wil je wel een lijstje geven:

- EXTREEM goede documentatie (java documentatie sux ass, al sinds 1995)
- Object model is zeer uitgebreid. Elke dag ontdek je weer wat nieuws. (gister ontdekte ik bv de WMI interfaces. waanzinnig werkelijk)
- .NET is van top to bottom aanwezig, je hoeft je platform niet te verlaten. ERG sterk punt: je bouwt zowel je gui support code in bv webpages in dezelfde type omgeving als de low level transaction code. Je debugt je complete applicatie in 1 debugger, ongeacht machine, ongeacht taal. ERG sterk punt. (java heeft dit ook wel, maar minder. jsp pages zijn geen pure java, plus jsp pages zijn echt geen partij voor asp.net)
- ASP.NET. DE killer feature voor .net. No offence, maar java is een schreeuwende kleuter vergeleken bij dit volwassen platform
- Attributed programming.
- de voordelen van C# t.o.v. java. Hoe klein ook, ze zijn er wel, bv indexers.
- De volgende SQLServer versie ondersteunt native de CLR voor stored procs/triggers.

Lijkt me voldoende voor nu .

Het doel hiervan is niet zozeer om .NET of Java als het betere platform naar voren te schuiven (want dat zou pas echt een onzinnige bezigheid zijn), maar om te helpen bij toekomstige ontwikkelingen met als doel om het wellicht nog beter te doen .

Sun heeft het jaren geleden al verloren. Ik wil als professional niet afgezeken worden door een lelijke vent als McNealy. In 1995 ben ik begonnen met Java, maar op windows ben ik altijd achtergesteld door Sun. Ik was erg blij met J++, zodat ik com objects kon maken die simpel waren te programmeren ala VB maar toch naar native code werden gecompileerd ala C++. Dit werd me afgenomen door dezelfde Sun om een marketingissue. Moet ik me dan als professional nog bezig gaan houden met dat bedrijf? Ik kijk wel uit. Sinds 1995 snappen ze bij Sun nog steeds niet hoe je documentatie presenteert aan je developers, wat werkelijk belangrijk is voor productiviteit en dat een developer van software niet is geinteresseerd in hardware van Sun of welke fabrikant ook en al HELEMAAL NIET in het moddergooien van kleine kinderen als Ellison en McNealy. De taal java is leuk, het platform java een zeer mislukt marketingproject om Windows van de desktop te krijgen en het bedrijf Sun een trieste moloch waar ik geen zaken mee wil doen. Ergo: met .Net alive and kicking is er geen reden meer om uberhaupt nog na te denken over Sun, tenzij .net schromelijk faalt. Tot nu toe heeft zich dat geen 1 keer voorgedaan alhier, in tegendeel. Sun heeft deze slag verloren met dubbele cijfers en HOE de door hun betaalde publicisten en trekpoppen ook roepen dat wat Sun maakt duizendmaal meer geweldig is dan de stront uit Redmond... het is gepiep van een blindgeslagen bokser. Sun leert niet van haar fouten en zal dat ook niet doen, gezien haar trackrecord. Wel jammer, want veel developers zijn afhankelijk van Sun en sommige aspecten van wat ze maken is best wel aardig bedacht.

[..]
Mwah, een beetje meta-discussie kan absoluut geen kwaad. Als je alleen maar software wilt produceren: prima, dan kan je je tijd beter besteden. Hele horden mensen zijn echter ook bezig met het analyseren van het vakgebied en dat is toch echt erg belangrijk. Als dit niet zou gebeuren, zouden conferenties erg stil zijn en tijdschriften erg leeg...

Analyseren van technologie die is gelimiteerd door restricties die van marketing en management afkomstig zijn lijkt me vrij zinloos hoor

Hehe . Om toch nog even een poging tot het opstarten van een discussie te doen: wat vind je dan van Java/C# Generics (geparameterizeerde typen)?

Die hadden in de 1e versie van C# gemoeten, maar ik mis ze geen dag hoor, ik moest opzoeken wat het was Als C-geschoolde inf ingenieur, ben ik wel erger gewend, dus elke feature die het leven makkelijker maakt is een zegen, en als ze 1 hebben weggelaten, dan zeg ik: dat had er in gemoeten, maar echt missen zal ik het niet nu, ik weet nl. niet wat ik mis.

Ik kan me overigens wel voorstellen dat ze al vrij vroeg een beslissing hebben genomen omtrent deze feature en op basis van ontwikkeltijd hebben gezegd: dat doen we later, omdat java het ook niet heeft (en men er dus niet aan is gewend, men weet niet wat er mist). Soms loop ik wel tegen dingen aan dat ik denk: er had meer in gezeten. Echter dit is meer op het vlak van functionaliteit in bepaalde classes en niet zozeer taaltechnische zaken. Ja 1 ding vind ik verschrikkelijk: de 'break' in een C# case statement. je moet hem plaatsen maar falltrough bestaat niet in die taal. Het is dus een overbodig statement. Een C# designer zei toen: 'het is toegevoegd om mensen die C++ en C# doorelkaar programmeren tegemoet te komen'. Ziehier een nadeel van taleninteroperabiliteit

[Scare360]

amen Otis, alles is gezegd en dan kom ik weer aan kakken. .NET is voor mij de verademing die ik ondertussen wel nodig had. Java is voor mij persoonlijk geen optie, veel tijd aan besteed en relatief weinig rendement uit gehaald tot nu toe.

.NET is voor mij persoonlijk gewoon een samenraapsel van al wat HOT is. Ongetwijfeld zal er naarmate het gebruiksaantal toeneemt ook de NOT aan DotNet/DotNot belicht gaan worden.

Voor mij:

-documentatie online
-C# welke een zwaar roelerende taal is
-cross p (die VB'ers hier ook tevreden houden)
-boeken, newsgroups...aanhang
-ASP.NET met zijn webservices
-integratie met SQL Server/MS Windows (MSMQ, MTS)
-online recources
-VS.NET welke naar mijn mening alle maar dan ook alle soortgelijke pakketten kont schopt.

.NET / .NOT wie zal het zeggen, mijn eerste ervaringen zijn goed/uitstekend te noemen. De l-interop lijkt uitstekend toe te passen in de productie... GUI -> VB.NET en core/components in C#, algols in C++ managed (makes the world go round).

[mbravenboer]

Otis: Waarom? Iedereen heeft belangen. Als Bertrand het had gepubliceerd als wetenschappelijke publicatie, dan had je meer dan gelijk gehad. Maar een column achtige publicatie mag van mij vol staan van de eigen mening van de publicist.

Mening ok, maar zorg dan wel dat die onderbouwd is en niet bestaat uit wat kreten die echt totaal geen recht doen aan de werkelijkheid. Je verwacht van een politie-agent toch ook dat hij zich als een voorbeeld gedraagd buiten zijn dienst?

Ik zie die mogelijkheid ECHT NIET in bv het javakamp: er is geen toegankelijke SDK voor java, zodat je bv VB kunt omschrijven in rules zodat je VB kunt compileren naar java bytecode en de java API kunt gebruiken in VB.

Ik moet zeker toegeven dat er goede compiler-frameworks zouden moeten zijn en helaas is iedereen daardoor een beetje voor zichzelf aan het klooien geweest. Wel zijn er Java assemblers, pretty-printers, grammatica's enzovoorts beschikbaar. Daarmee kan je best aan de slag als je Java wilt targetten. Sterker nog, ik ben er zelf mee bezig en het werkt prima. Een API en een object-model is er uiteraard wel, maar er is geen scheiding tussen de intermediate representation en de taal, die er bij .NET wel is.

EXTREEM goede documentatie (java documentatie sux ass, al sinds 1995)

Hum Ik vind de API documentatie best aardig en Javadoc is niet voor niets in XML vorm overgenomen in C#.

Over het algemeen denk ik dat in een meta-discussie de praktische problemen (hoe belangrijk ze in de praktijk ook zullen zijn) niet erg relevant zijn. De feitelijke verschillen in architectuur en aanpak van bijvoorbeeld de intermediate representations, daar gaat het om...

Object model is zeer uitgebreid. Elke dag ontdek je weer wat nieuws. (gister ontdekte ik bv de WMI interfaces. waanzinnig werkelijk)

Hum ik heb minder praktische ervaring dan jou met .NET en zie ff niet wat de WMI interfaces met het object-model te maken hebben... Voor zover ik weet is het toch 'gewoon' een API? Kan ik dus helaas niet op ingaan.

java heeft dit ook wel, maar minder. jsp pages zijn geen pure java, plus jsp pages zijn echt geen partij voor asp.net

Mwah, pak dan Servlets als je een vergelijking wilt maken. JSP's heb ik altijd onzinnig gevonden.

ASP.NET. DE killer feature voor .net. No offence, maar java is een schreeuwende kleuter vergeleken bij dit volwassen platform

Hum, nou ja... laat ik hier maar niet op ingaan . Voorlopig is Java nog de reus op de server-side en ASP .NET de kleuter . Als je een vergelijking wilt gaan maken moet je servlets erbij pakken en de producten van 3e partijen zoals Apache. Als je Java dan als kleuter durft te betitelen moet je denk ik toch nog even iets verder rondkijken...

Attributed programming.

Dat is zeker een een positief punt en ook iets wat je in elke moderne taal terug zult gaan zien. Op voorstel van BEA is er trouwens een JSR om meta tags in Java op te nemen, wat erger naloperig klinkt en dat ook zeker is .

de voordelen van C# t.o.v. java. Hoe klein ook, ze zijn er wel, bv indexers.

C# bevat inderdaad veel toestanden als delegates, indexers, properties en dergelijke, maar ook dat zijn punten waar de meningen nogal over verdeeld zijn uiteraard...

Lijkt me voldoende voor nu

Mwah, je draagt toch vooral praktische tools aan waar Microsoft natuurlijk erg goed in is. Dat ze door deze aanpak .NET erg positief en productief kunnen maken moet denk ik niet zorgen voor een ophemeling van een platform die een discussie over de daadwerkelijke architectuur in de weg kan staan...

Ik wil als professional niet afgezeken worden door een lelijke vent als McNealy.

Net of Bill Gates zo'n hunk is .

[COM]Dit werd me afgenomen door dezelfde Sun om een marketingissue. Moet ik me dan als professional nog bezig gaan houden met dat bedrijf?

Nou ja, het dat jij daar niet blij van bent geworden begrijp ik volledig, maar het is natuurlijk ook wel zo dat Microsoft deze integratie ook via een manier had kunnen realiseren die wel in de ideeen van de JVM paste. Tegen native libraries heeft Sun helemaal niets. Dat Microsoft zelfs essentiele onderdelen heeft weggelaten geeft denk ik toch aan dat ze bewust bezig waren om het Java Platform naar hun Windows hand te zetten. De andere rant over Sun laat ik maar zitten want dat is toch een zinloze discussie die ik weer niet boeiend vind.

Ja 1 ding vind ik verschrikkelijk: de 'break' in een C# case statement. je moet hem plaatsen maar falltrough bestaat niet in die taal. Het is dus een overbodig statement. Een C# designer zei toen: 'het is toegevoegd om mensen die C++ en C# doorelkaar programmeren tegemoet te komen'. Ziehier een nadeel van taleninteroperabiliteit

Hum, das inderdaad een minder punt ja . Sowieso mag die case-statement weleens gemoderniseerd worden want hij wordt van taal tot taal toch niet echt op een innovatieve manier overgenomen .

[mbravenboer]

paulgielens: amen Otis, alles is gezegd en dan kom ik weer aan kakken. .NET is voor mij de verademing die ik ondertussen wel nodig had. Java is voor mij persoonlijk geen optie, veel tijd aan besteed en relatief weinig rendement uit gehaald tot nu toe.

Tja, ik kan toch echt geen overtuigende argumenten vinden om amen op de post van Otis te zeggen . Java integreert zondermeer voor geen meter, maar dat is het probleem en niet al dan niet inferieure technologie. Het echte probleem is niet alleen op Sun af te schuiven, alhoewel ze het zeker beter hadden kunnen doen.

Docs zijn online te vinden (API docs en tutorials) er is een gigantische hoeveelheid websites met artikelen enzovoorts.

Ik denk dat we gewoon moeten concluderen dat mensen altijd het platform waarin ze het beste thuis zijn ook gelijk als makkelijkste ervaren. Dat de andere platformen naar hun mening slechter zijn is wellicht voor een groot deel niet zozeer de schuld van die platformen, maar van het geringere overzicht. Zulke benaderingen staan een echte discussie over de technologische verschillen erg in de weg, hoe praktisch van belang de aangedragen verschillen ook zijn.

[Verwijderd]

Ehhm, volgens mij komt hier nu een Java vs C# discussie op gang en dat was volgens mij niet helemaal de bedoeling als ik naar de topic titel kijk.
Om het dan weer een beetje ontopic te krijgen:
Dat hele language interop gebeuren is sowieso een interessante ontwikkeling (puur theoretisch gezien), hoewel je op dit moment nog een beetje kan twijfelen over de praktische waarde als blijkt dat je de verschillende talen eigenlijk zover moet gaan aanpassen zodat ze goed op C# te mappen zijn.
Wat ik trouwens wel erg grappig vindt is dat je vaak als pluspunt leest van language interop dat je nu dus gewoon een handige taal kunt zoeken die goed bij het (deel)probleem past dat je wilt oplossen. In de praktijk echter zijn de grote verschillen tussen talen als C#, C++, Java, Eiffel, Cobol, VB etc vaak alleen syntactisch en zijn ze eigenlijk allemaal min of meer even (on)geschikt voor het oplossen van problemen. Een talen als Stratego of haskell zijn daarop een positieve uitzondering, maar deze worden in de praktijk eigenlijk nauwelijks gebruikt hoewel dat natuurlijk best zou kunnen veranderen.

Ik denk dan ook dat het belangrijkste argument voor mensen om interop te willen gebruiken is dat veel mensen (zeker als ze wat ouder worden) steeds minder energie krijgen voor het leren van een nieuwe taal en dus op een gegeven moment afhaken als er nieuwe talen zoals Java of C# geintroduceert worden. Die hele taal interop zorgt ervoor dat je binnen een bedrijf ook die mensen kunt blijven inzetten bij nieuwe projecten hoewel de praktijk nog moet uitwijzen hoe handig het is als een bepaald programma in tig verschillende talen is geschreven terwijl het ook gewoon in 1 taal had gekund.

Verder is het gebruik van libraries die in een andere taal geschreven zijn, natuurlijk erg leuk, maar ook hierbij denk ik dat dit in de praktijk niet heel erg veel gebruikt zal worden. Tuurlijk heb je dat standaard voorbeeld van grote banken die miljoenen regels cobol code hebben liggen en voor hun zal het ongetwijfeld handig zijn, maar ik denk dat eigenlijk verreweg de meeste code libraries een erg korte levensduur hebben, gewoonweg omdat platformen, eisen, algoritmes,etc,etc snel veranderen, waardoor dit soort libraries toch regelmatig opnieuw geschreven moeten worden dus dan kan hiervoor ook meteen een andere taal gekozen worden.

Al met al vind ik het zeker een zeer interessante ontwikkeling die de moeite waard is om meer onderzoek naar te doen, maar op dit moment is het praktisch nut in veel gevallen nog niet zo groot.

[Verwijderd]

Hmm, nou blijft het wel weer opeens heel erg stil hier nu ik die Java vs C# zo heb afgebroken...nou ok, dan mogen jullie nu weer doorgaan, is er tenminste nog iets interessants te lezen hier

[Orphix]

Op donderdag 09 mei 2002 17:45 schreef hondass50 het volgende:
Hmm, nou blijft het wel weer opeens heel erg stil hier nu ik die Java vs C# zo heb afgebroken...nou ok, dan mogen jullie nu weer doorgaan, is er tenminste nog iets interessants te lezen hier

+ het is lekker weer buiten

[mbravenboer]

Het is een beetje het probleem dat de mensen die deelnemen aan de discussie elkaar mening wel weten .

hondass50: Ehhm, volgens mij komt hier nu een Java vs C# discussie op gang en dat was volgens mij niet helemaal de bedoeling als ik naar de topic titel kijk.

Gedeeltelijk niet, maar gedeeltelijk ook wel . Het topic was bedoeld om het artikel van Bertrand Meyer te bespreken, waar ik nogal wat kritiek op had. Mijn kritiek gaat vooral over mijn gedachte dat .NET qua languuage interop niet zoveel toevoegd als wel wordt beweerd en in dit geval zeker door Bertrand, die al vaker hele enthousiaste stukken over .NET heeft geschreven...

Als je dus gaat bekijken hoe de vork nu precies in de steel steekt, kom je eigenlijk uit op een vergelijking van het object-model en de instructie-set van beide platformen. Omdat C# en Java voor beide platformen de versyntaxing van deze instructie-set zijn, praat het makkelijk om dan maar gewoon C# en Java te vergelijken. Ik vind dat er beseft moet worden dat compilatie naar .NET gelijk staat een het definieren van een mapping naar C# en dat compilatie naar het Java Platform gelijk staat aan het definieren van een mapping naar Java.

Om het dan weer een beetje ontopic te krijgen:
Dat hele language interop gebeuren is sowieso een interessante ontwikkeling (puur theoretisch gezien), hoewel je op dit moment nog een beetje kan twijfelen over de praktische waarde als blijkt dat je de verschillende talen eigenlijk zover moet gaan aanpassen zodat ze goed op C# te mappen zijn.

Kijk, die syntaxtische varianten als VB .NET vind ik allemaal prima. Dat heeft uiteraard zo zijn doelgroep en dat VB .NET en C# aardig kunnen samenwerken staat vast. Dit moet echter niet gebruikt worden als een bewijs dat .NET taal-onafhankelijk is. Beide talen zijn op abstract-syntax-tree niveau vrijwel equivalent en je ze vormen daarom eigenlijk een 1 op 1 mapping. Bij een echte compilatie vindt over het algemeen een code 'explosie' of soms ook een 'implosie' plaats. Dat is hier absoluut niet het geval. Echt bewijs van succesvolle samenwerking onstaat pas als je talen in het OO paradigma met een anders object-model gaat compileren naar .NET en deze samenwerking goed verloopt of als je zelfs talen neemt uit een heel ander paradigma zoals bijvoorbeeld Haskell. Het is alleen sterk de vraag of .NET dan nog steeds zo revolutionair is. Functies geschreven in andere talen kunnen we allang aanroepen via de standaard stack-frame layouts, maar dat verloopt altijd niet even vloeiend. Ook bij .NET verloopt het nog steeds niet vloeiend. Code in bijvoorbeeld declaratieve talen zal altijd uitgedrukt moet worden in object-georienteerde termen en het echte samenwerkings-werk vind dus daar plaats en niet zozeer in de .NET architectuur. Hetzelfde zou je kunnen doen voor het Java Platform, zei het dat je daar nog meer problemen krijgt omdat het object-model daar een stuk minimalistischer is (waarbij de verschillen volgen uit de verschillen tussen Java en C#).

Ik denk dan ook dat het belangrijkste argument voor mensen om interop te willen gebruiken is dat veel mensen (zeker als ze wat ouder worden) steeds minder energie krijgen voor het leren van een nieuwe taal en dus op een gegeven moment afhaken als er nieuwe talen zoals Java of C# geintroduceert worden.

Tja, als dat echt een hoofdreden is vraag ik me af of VB .NET dan zo'n succesvol idee zal zijn... Ook hiervoor moet je toch echt wel even in de materie duiken. Het voelt natuurlijk wel vertrouwder aan dan C# tov VB, maar dat vertrouwde gevoel is denk ik niet helemaal terecht.

[Verwijderd]

Sun heeft het verprutst door vast te houden aan Java == taal + platform. MS heeft gesteld: Java == taal. Vandaar de lawsuit, vandaar de ellende met J++ en de JVM's en vandaar ook C#.

Met de java documentatie bedoel ik de SDK documentatie. Die staat in geen verhouding met de .NET SDK documentatie.

Deze discussie vind ik dan ook verder niet zo boeiend, want het wordt dan meer nitpicking welke detailfrutsel beter is dan de andere, en op het totaalplaatje is dat verre van interessant: wat boeit is wat een developer productief maakt en wat de developer in staat stelt de specs te halen die moeten worden gehaald op een zo'n goed/beter/best mogelijke manier. .NET slaagt daar goed in. Heel goed zelfs. De SDK is nl. 1 install en je kunt meteen alle apps bouwen die je wilt: van asp.net tot windows services, windows applicaties die er uit zien en aanvoelen als windows applicaties etc. Sun's Java SDK lukt dat niet. Bij lange na niet. Als windows developer moet je je aanpassen aan een platform en zn nukken die niet windows-like zijn. Dat werkt niet.

Java kan dan op academisch niveau superieur zijn, (wat ik overigens zeer betwijfel, het is tenslotte een Bill Joy product), in de praktijk heb je daar geen reet aan. Het wordt nu nog veel gebruikt, maar dat is maar een kwestie van tijd. En dan nog: op het windowsplatform hoef je niet naar java. (dat hoefde al niet, maar nu helemaal niet meer). Je spreekt wel over servlets bv, maar daarmee kom je er niet: in .NET maak je de complete app op 1 platform, of dat nu webpages, een webservice, een windows service, een object dll is... maakt niet uit. Essentieel onderdeel. Je haalt een soortgelijke functionaliteit indien apache native java ondersteunt, of je je webservices/applicaties totaal in bv oracle appserver laat draaien.

Dus een ge-rant tussen een taaldeveloper en een persoon die het daar niet mee eens is... leuke bladvulling maar nutteloos voor iemand die met de platforms moet werken, en IMHO ook voor diegenen die keuzes moeten maken welk platform beter is voor hun project.

Ik klink nu wellicht als een prototype HBO-er, forgive me

edit:

Ik begrijp best dat je wilt praten over wat men beter/minder vindt aan Java vs .NET, maar je vergeet dat beide talen/platforms maar 1 doel dienen: als tool/bouwsteen te worden gebruikt door een developer voor het bouwen van software. Je kunt dan op academisch niveau die platforms benaderen (en dat zou ik dan niet aan de hand van een column + tegenrant doen, maar een analyse van beide platforms) maar dat gaat totaal voorbij aan het enige dat belangrijk is: voldoen ze aan de verwachtingen die gesteld worden aan deze tool/taal zodat ze voor het doel kunnen worden gebruikt waar ze voor zijn gebouwd/bedacht? Dat is nl. het ENIGE dat telt. Een academische discussie verzandt namelijk vrij snel, je theorema wordt al snel veel te smal, want je kunt wel gaan oordelen over goede/slechte zaken in bv .NET/Java op een academisch niveau, maar dat is alleen van waarde als je dat in perspectief plaatst van andere talen/platforms.

[mbravenboer]

Otis: Sun heeft het verprutst door vast te houden aan Java == taal + platform. MS heeft gesteld: Java == taal.

Java als taal zo heel leuk zijn geweest voor de taal. Microsoft had dan wellicht C# niet ontwikkeld en Java was misschien wel de voorkeur-taal geworden voor ontwikkeling voor het MS Windows Platform, zoals C# dat nu gaat worden imho. Microsoft zou echter ook volledig aan de haal zijn gegaan met het platform waar Java voor bedoeld was. Zelfs toen ze nog van plan waren om Java in een vrij JVM-achtige omgeving te laten draaien (wat later vast bijgesteld zou zijn) hebben ze een draai aan Java gegeven waardoor het geeneens in andere JVMs op hetzelfde MS Windows kon draaien.

Op zich allemaal geen probleem als je je hart verkocht hebt aan de taal Java. Wat wel een probleem is: Java is slechts een onderdeel van de bredere visie die Sun met het Java Platform heeft gehad: verifieerbare bytecode, downloadbare code, platform-onafhankelijkheid en grote veiligheid. Deze complete visie zag je in het begin gerealiseerd met applets en binnenkort zal je dit steeds meer met Java Web Start zien.

Deze doelstellingen zouden nooit gehaald zijn als Sun Microsoft aan de haal had laten gaan met Java. Dat kan je voor het doordringen van de taal Java jammer vinden, maar aan de andere kant kan je ook redeneren dat Microsoft ook had kunnen besluiten om alles via native libraries te regelen en gewoon verrot goede JVMs te gaan bouwen die integreren in het OS zoals dat nu op Mac OS X gerealiseerd is. Petje af voor Apple.

Deze discussie vind ik dan ook verder niet zo boeiend, want het wordt dan meer nitpicking welke detailfrutsel beter is dan de andere, en op het totaalplaatje is dat verre van interessant: wat boeit is wat een developer productief maakt en wat de developer in staat stelt de specs te halen die moeten worden gehaald op een zo'n goed/beter/best mogelijke manier.

Mwah, dat vind []i]jij[/i] het punt waar het om draait vanuit jouw perspectief als ontwikkelaar. Dat wil niet zeggen dat dit ook het punt is waar het om draat en zeker niet dat ik dat ook maar het punt moet vinden waar het om draait .

Uiteraard draait wel alles om productiviteit. Alle verbeteringen die doorgevoerd worden in de informatica moeten als doel hebben om betere software te schrijven en de ontwikkelaar daarbij van zo goed mogelijke abstractie-lagen te voorzien.

Concrete tools die makkelijk te gebruiken en te installeren zijn, zijn daarbij erg belangrijk voor het heden, maar het grotere plaatje draait niet om tools denk ik. Het grotere plaatje waar je in de toekomst naar toe moet gaan werken zijn nieuwe ideeen om je goed, compact en correct uit te kunnen drukken. Tools die bijvoorbeeld code genereren zijn fantastisch, maar het zijn work-arounds voor een gebrek aan compacte uitdrukking in een geschikt formalisme.

Als windows developer moet je je aanpassen aan een platform en zn nukken die niet windows-like zijn. Dat werkt niet.

Tja, als je wilt dat een applicatie ook ergens anders gaat draaien (wat jij niet wilt, dat weet ik ) dan kan je niet uitgaan van een platform wat volledig aanvoelt als Microsoft Windows. Dat .NET dit beter lijkt te doen is niet de verdienste van uitmuntende technologie: de kijk op een platform die MS Windows biedt wordt simpelweg 'gestandaardiseerd' (libraries zijn niet gestandaardiseerd) en geport naar andere platformen.

Java kan dan op academisch niveau superieur zijn

Dat heb jij mij dat nooit horen zeggen... Ik zou niet weten wat Java theoretisch superieur zou maken aan .NET. Ik probeer in mijn topics slechts de claims van .NET te analyseren en tegenover hetgene te plaatsen wat het Java Platform biedt. Als het Java Platform superieur zou zijn, had ik iedereen daar al van overtuigd .

wat ik overigens zeer betwijfel, het is tenslotte een Bill Joy product

Dat je jouw persoonlijke problemen met bepaalde personen in je reacties opneemt, verhoogt de kwaliteit van deze reacties niet echt .

Het wordt nu nog veel gebruikt, maar dat is maar een kwestie van tijd.

Ik ben bang dat ik je op dit punt toch teleurgesteld zal terug zien in de toekomst . Het grote aantal projecten mbt tot nieuwe technologie wat geimplementeerd wordt in Java zal een enorme drijfveer worden. Het werk van Apache, andere open-source projecten en academische projecten (die vaak in Java worden gerealiseerd) biedt een stevige basis voor het voortbestaan van Java. Sowieso is de ongeevenaarde platform-onafhankelijkheid alleen al een waarborg voor dit voortbestaan. .NET zal veruit de betere optie zijn als je je volledig op het MS Windows platform wilt richten en dat zal je dus ook terugvinden in de cijfers voor dat platform.

Je spreekt wel over servlets bv, maar daarmee kom je er niet: in .NET maak je de complete app op 1 platform, of dat nu webpages, een webservice, een windows service, een object dll is... maakt niet uit. Essentieel onderdeel. Je haalt een soortgelijke functionaliteit indien apache native java ondersteunt, of je je webservices/applicaties totaal in bv oracle appserver laat draaien.

Tools, tools, tools. Allemaal heel leuk, maar je vergeet dat mensen die eenmaal kennis van zaken hebben hier geen enkel probleem mee hebben. Inderdaad: Java Servlets zijn minder toegankelijk en de instap naar .NET webpages/services is fenomenaal. Dat betekent echter niet dat je Servlets maar af moet schrijven. Java is groot geworden op de server-side waar tools en installaties geen probleem zijn omdat daar mensen met kennis van zaken rondlopen.

Jij ziet .NET met alle tools als 1 platform en zegt dat dit platform je dus in staat stelt om eenvoudig van alles te schrijven. Bij Java is de JVM met de taal en de libraries het platform. 3e partijen schrijven hier tools voor die je kan gebruiken en die naar jouw gevoel geen deel uit maken van het platform. Servlets draaien echter gewoon op het Java Platform. Niets bijzonders.

Ik klink nu wellicht als een prototype HBO-er, forgive me

Ach, je klinkt tool-georienteerd . Dat begrijp ik best, maar tools vind ik persoonlijk een stuk minder boeiend, hoe belangrijk ze in de praktijk ook zijn. Je denkt vanwege je werk erg in het heden en de naaste toekomst. Ik heb meer de neiging om voordat een platform op de markt is al te gaan bedenken hoe het beter zou kunnen .

Je kunt dan op academisch niveau die platforms benaderen (en dat zou ik dan niet aan de hand van een column + tegenrant doen, maar een analyse van beide platforms)

Mwah, er zijn vele boeiende artikelen geschrijven die de beide platformen vergelijken zonder daarbij aandacht te besteden aan de libraries en de tools. Het gaat dan dus om het object-model, de instructie-set, de architectuur enzovoorts. Dat zijn hele leuke verhalen en ik heb ze hier ook vaak gepost. Bertrand zou er alleen goed aan doen om zijn columns ook iets meer aandacht te besteden aan een juist overzicht.

Ook hij heeft een verantwoordelijkheid. Veel mensen die zijn verhaaltjes lezen kunnen niet beoordelen in hoeverre hij praat uit enthousiasme over .NET of in hoeverre wat hij zegt op feitelijke analyses is gebaseerd. Lezers schenken hem hun vertrouwen om zich voor te laten lichten door hem. Ik heb over zulke verantwoordelijkheden gisteren in het XSLT topic iets gezegd en vind ook in dit geval dat het erg fout gaat.

[Verwijderd]

Ik ga in op een gedeelte, wat imho de gehele lading dekt.

Op vrijdag 10 mei 2002 15:03 schreef mbravenboer het volgende:
Op zich allemaal geen probleem als je je hart verkocht hebt aan de taal Java. Wat wel een probleem is: Java is slechts een onderdeel van de bredere visie die Sun met het Java Platform heeft gehad: verifieerbare bytecode, downloadbare code, platform-onafhankelijkheid en grote veiligheid. Deze complete visie zag je in het begin gerealiseerd met applets en binnenkort zal je dit steeds meer met Java Web Start zien.

1995 kwam Java op de markt, dat is 7 jaar geleden. Als je nu nog steeds je visie niet hebt gerealiseerd, dan ben je behoorlijk traag in het uitrollen ervan. Hoe kun je dan verwachten van developers dat ze, wanneer ze die visie willen implementeren in hun applicaties, blijven wachten totdat Sun klaar is ermee? Dat kun je niet. Op papier is het wellicht een topplan geweest, in de praktijk kwam er niets van terecht, behalve losse onderdelen. In het kader van 'hoe kan het beter': developers geven wat ze nodig hebben. Java schiet daarin tekort.

Dit is een essentieel punt: op academisch niveau kun je debatteren over 'hoe moet het beter', maar als dat in de praktijk niet wordt gehaald, ben je nergens. Het blijft een gebruiksvoorwerp.

[..]
Mwah, dat vind []i]jij[/i] het punt waar het om draait vanuit jouw perspectief als ontwikkelaar. Dat wil niet zeggen dat dit ook het punt is waar het om draat en zeker niet dat ik dat ook maar het punt moet vinden waar het om draait .

Een tool/taal/platform is er niet voor de musea. Dat is er om het te gebruiken (in allerlei vormen). 'Hoe moet het beter', kan dan imho ook alleen maar dat doel dienen, of een onderzoek dat als resultaat moet hebben een algehele definitie ter ondersteuning van 'hoe moet het beter' op een meer abstract vlak binnen software development. Maar indirect komt dat laatste weer terug in de vorm van het eerste.

Uiteraard draait wel alles om productiviteit. Alle verbeteringen die doorgevoerd worden in de informatica moeten als doel hebben om betere software te schrijven en de ontwikkelaar daarbij van zo goed mogelijke abstractie-lagen te voorzien.

M.a.w.: dingen waar je wat aan hebt als developer. De praktijk en hoe je de voorwerpen gebruikt in de praktijk zijn essentieel in deze discussie. Sterker: het enige raamwerk waarbinnen de discussie levensvatbaar is.

Concrete tools die makkelijk te gebruiken en te installeren zijn, zijn daarbij erg belangrijk voor het heden, maar het grotere plaatje draait niet om tools denk ik. Het grotere plaatje waar je in de toekomst naar toe moet gaan werken zijn nieuwe ideeen om je goed, compact en correct uit te kunnen drukken. Tools die bijvoorbeeld code genereren zijn fantastisch, maar het zijn work-arounds voor een gebrek aan compacte uitdrukking in een geschikt formalisme.

Dat heeft geen moer met de discussie die je opstarte te maken. De discussie die je hierboven beschrijft zou de metadiscussie moeten zijn en in DIE discussie zou je .NET en bv Java kunnen toetsen aan een conclusie uit die discussie en DAN concluderen: wel/niet revolutionair, wel/niet op de goede weg of algemener: ligt wel/niet in de lijn van deze conclusie. Nu draai je het om en wil je een superclass als subclass van een subclass van de superclass definieren

[..]
Ik ben bang dat ik je op dit punt toch teleurgesteld zal terug zien in de toekomst . Het grote aantal projecten mbt tot nieuwe technologie wat geimplementeerd wordt in Java zal een enorme drijfveer worden. Het werk van Apache, andere open-source projecten en academische projecten (die vaak in Java worden gerealiseerd) biedt een stevige basis voor het voortbestaan van Java.

Ik zeg ook niet dat het irrelevant wordt, C is ook nog altijd niet een irrelevante taal, in tegendeel. Wat ik echter vrees voor Java is dat voor .NET er talen komen die met een nog ruimere expressiekracht hetzelfde platform targetten, waardoor Java een 'bewerkelijke' taal wordt. En daarmee opschuift naar de nichemarkt. Java heeft nu zoveel aanhang omdat het de enige fatsoenlijke OO taal is op Unix gebied met een fatsoenlijke API. Zodra bv Mono klaar is, is dat niet meer zo. Maar op zich is dat de issue niet eens: een taal is een tool, niet een onderwerp. Je zult dus de taal niet centraal moeten stellen voor de toekomst, want zodra iemand een tool verzint die superieur is aan de jouwe ben je weg. Talen hebben de leuke eigenschap dat waarin ze worden gebruikt op zichzelf weer een tool is, waardoor je een useability chain krijgt: hoe expressiever de tool die de taal als tool gebruikt, hoe expressiever de taal zelf. Wat voor .NET geldt kan ook voor Java gelden, echter de lijn van taalgebruikende tools en taalondersteunende tools is voor .NET nu al zoveel verder dan de equivalenten voor Java (Visual Studio.NET makes the difference) dat ik niet echt snap waarom mensen nog lopen te krassen in Java vanuit editors als Emacs, terwijl er superieure omgevingen zijn die veel werk uit handen nemen (en op hun beurt de developer weer in staat stellen de tool gemakkelijk uit te breiden waardoor je een soort uitbreiding van je taal krijgt middels de taalgebruikende en taalondersteunende tool.

Het is dan ook dit laatste waarom MS hungarian coding heeft afgezworen: de tools voegen zoveel toe dat hungarian coding niet nodig is. Het is dus al niet meer los van elkaar te zien.

Sowieso is de ongeevenaarde platform-onafhankelijkheid alleen al een waarborg voor dit voortbestaan.

Dat niveau van platformonafhankelijkheid bestaat ook in de C++ en C wereld. In de praktijk echter is die er niet. Het paradigma is ook heel anders: Services based remote computing vereist geen platform onafhankelijkheid. Je gebruikt functionaliteit, ongeacht het platform waar de service die je gebruikt op draait. Platformonafhankelijkheid verwordt op die manier tot een niet-relevant zijnde eigenschap. Sun weet dat ook, het positioneert Java allang niet meer met die eigenschap.

.NET zal veruit de betere optie zijn als je je volledig op het MS Windows platform wilt richten en dat zal je dus ook terugvinden in de cijfers voor dat platform.

Maar dat is toch het enige dat telt? Of zie ik het verkeerd? Ik heb met .NET 1 API voor ALLE functionaliteit die ik wens en waar ik uberhaupt van kan dromen dat ik die nodig heb. Alle. Ik hoef geen externe api's aan te roepen om bv systeemzaken te regelen, zit er allemaal in. Een api/platform als Java verliest het dus altijd op pure functionaliteit. Een Windows 2000 + .NET wint het op functionaliteit voor de developer altijd van een Linux / Solaris + Java oplossing. Meer telt er niet: men kiest de juiste tool voor het werk dat er gedaan moet worden. En een tool IS het, een programmeertaal. Je moet er niet meer van maken. Ga je dat wel doen, dan krijg je mn "Maar tekst typen om commando's in te geven is omslachtig" om de oren . Textbased talen zijn sowieso inferieur. Logische systemen zoals Biztalk server 2000 implementeert oftewel, visueel je business logic definieren opdat je gedigitaliseerde informatiestromen langs de juiste banen worden geleid en de juiste bewerkingen plaatsvinden. Dat is overzichtelijk voor een visueel ingesteld wezen als de mens. Textbased talen die eerst door de mens, al lezende, moeten worden geinterpreteerd zijn daaraan echt ondergeschikt.

Je vervalt dus tot het bediscussieren van het praktisch nut van je tot voorbeeld gestelde taal. Welnu, dat is makkelijk: kijk naar het praktisch nut, en analyseer knelpunten MBT (!) dat praktische nut. In een groter, algemener plaatje, bv HOE ziet de ideale softwaredevelopment omgeving er uit, praat je EERST over algemene zaken als: visueel vs textbased, component based vs library based etc., en daarna pas over details als wat is beter in java dan in de CLR , if ever.

[..]
Tools, tools, tools. Allemaal heel leuk, maar je vergeet dat mensen die eenmaal kennis van zaken hebben hier geen enkel probleem mee hebben. Inderdaad: Java Servlets zijn minder toegankelijk en de instap naar .NET webpages/services is fenomenaal. Dat betekent echter niet dat je Servlets maar af moet schrijven. Java is groot geworden op de server-side waar tools en installaties geen probleem zijn omdat daar mensen met kennis van zaken rondlopen.

Onzin. Zodra je een leercurve hebt, schiet je tool te kort. Computers zijn er ter ondersteuning van taken, of ter vervanging van taken, die de mens wil doen. De computer en de daarop draaiende software, dient dus een doel, namelijk als hulpmiddel dienen voor de mens. Zodra je een leercurve hebt voor het gebruik van dat hulpmiddel, verwordt het gebruik van dat hulpmiddel, het toetsen van de geleerde materie tegen de gevraagde materie van het hulpmiddel. Faalt de mens in die toets, is de bediening/gebruik van het hulpmiddel aan beperkingen onderhevig. En dat kan nooit de bedoeling zijn van een hulpmiddel! Immers, de mens die het hulpmiddel bedient doet dat om een zekere taak te volbrengen, die staat los van het hulpmiddel.

Een taal en platform zijn tools, hulpmiddelen. Heb je een stijle leercurve nodig om je gemaakte software draaiend te krijgen op een zekere server, dan mis je als toolleverancier een essentieel onderdeel van het antwoord op de vraag 'waarom is er uberhaupt een computer'.

Voor de details van 'java' of 'C#' heeft het vraagstuk 'deployment' bv geen betekenis, maar voor het NUT van Java of C# is het essentieel. Wat heeft een developer aan een in C# geschreven programma als niemand het kan gebruiken tenzij eerst een fikse leercurve wordt doorlopen? Niets!

Jij ziet .NET met alle tools als 1 platform en zegt dat dit platform je dus in staat stelt om eenvoudig van alles te schrijven. Bij Java is de JVM met de taal en de libraries het platform. 3e partijen schrijven hier tools voor die je kan gebruiken en die naar jouw gevoel geen deel uit maken van het platform. Servlets draaien echter gewoon op het Java Platform. Niets bijzonders.

Nee, ik kijk alleen naar functionaliteit. Wat biedt een platform mij? Helpt het me bij mn taak? Zo nee, dan is het een onpraktisch hulpmiddel en ga ik op zoek naar een vervanger. Dat is de essentie van software development! In de IT is al 20 jaar lang een blindheid heer en meester waar ik, wanneer ik er aan denk, gewoon niet over uit kan: Als het easy te gebruiken is, is het voor dummies.

Als ik Linux met Java wil gaan gebruiken, en ik ken java, ben ik nergens. Ik kan in Java wel wat programmeren, maar ik heb essentiele kennis van het OS nodig. Nu heb ik dat wel, maar veel developers niet. Die willen daar terecht niet mee bezig zijn, dat kost veel te veel tijd. De windows + .NET tandem heeft dat veel minder (maar is er ook nog lang niet). Java is niet 1 platform met daarin ALLE functionaliteit om compleet Linux te beheren, de configureren en applicaties op te draaien. Ik ben als developer aangewezen een hele santemekraam aan tools, libs, etc. Kan ik vanuit Java apache configureren? Ik betwijfel het. (ja je kunt een textfiletje editen... maar niet via een object met properties en methods). Ik moet dus kennis hebben van de configfileformat van apache. Lekker belangrijk, maar die kennis wil ik niet en HOEF ik ook niet, op windows hoef ik geen configfilekennis van de Metabase van IIS te hebben om daar compleet via .net alles mee te doen.

_DAT_ is het essentiele punt. Daar scoort .NET en faalt Java: als developer heb je veel meer functionaliteit binnen handbereik bij .NET dan bij Java. No offence, maar dat is DE key naar succes in software development.

[..]
Ach, je klinkt tool-georienteerd . Dat begrijp ik best, maar tools vind ik persoonlijk een stuk minder boeiend, hoe belangrijk ze in de praktijk ook zijn. Je denkt vanwege je werk erg in het heden en de naaste toekomst. Ik heb meer de neiging om voordat een platform op de markt is al te gaan bedenken hoe het beter zou kunnen .

Een taal is ook een tool. En een tool die de taal weer ondersteunt voegt iets toe aan de taal, namelijk expressiekracht, een essentieel onderdeel van elke taal. Als je wilt analyseren of een platform beter kan, moet je eerst definieren wat het ultieme is, zodat je kunt toetsen of het platform er aan voldoet of niet en wat er aan schort. Maar zolang je talen niet als tools ziet kom je IMHO geen steek verder. Want zeg nou zelf: visueel designen van functionaliteit is superieur aan het textueel verwoorden van diezelfde functionaliteit: readability. De mens KAN geen programmateksten interpreteren, tenzij de taal die gebruikt is gelijk staat aan natuurlijke taal en dan nog zie je misinterpretaties.

Dus, op basis van welke ultieme situatie-conclusie moet er worden getoetst of Java of .NET voldoen daaraan en hoe verbeteringen kunnen worden aangebracht en op welk gebied ?

[mbravenboer]

Pfff wat een verhaal . Ik ga niet overal op in, want dan wordt dat weer een nog langer verhaal terwijl onze meningsverschillen wel duidelijk zijn...

1995 kwam Java op de markt, dat is 7 jaar geleden. Als je nu nog steeds je visie niet hebt gerealiseerd, dan ben je behoorlijk traag in het uitrollen ervan. Hoe kun je dan verwachten van developers dat ze, wanneer ze die visie willen implementeren in hun applicaties, blijven wachten totdat Sun klaar is ermee?

Nou ja, ik wil je niet teleurstellen maar ik denk dat de visie toch wel gerealiseerd is (met zijn mankementen). Ik implementeer thuis al mijn projecten op Linux, waarbij ik gebruik maak van databases, XML, Relax NG, GUIs in Swing enzovoorts. De meeste klanten werken uiteraard op een MS Windows desktop en dat vormt dus geen enkel probleem.

Applets waren op zich best een aardig idee, maar de plugin is in verhouding tot de browser veel te groot. Alleen als Microsoft in staat was geweest om steeds recente versies van Java in IE mee te leveren was dat een succes geworden. Java applets vormen op Mac OS X in ieder geval geen enkel probleem meer. Integratie is hier het toverwoord. Vandaar ook dat Java desktop applicaties op dit moment alleen serieus gebruikt worden op intranets, waar het systeembeheer (met kennis van zaken) zorgt voor de aanwezigheid van J2RE.

Java Web Start is een heel aardig idee voor deployment van serieuzere applicaties. Het probleem van Java Web Start is dat het pas goed tot zijn recht gaat komen als het al is geinstalleerd: via Java Web Start kan je netjes de benodigde versie van de JVM regelen.

Ik vermoed (weet ik natuurlijk niet zeker) dat jouw mening over het Java Platform ook een beetje wordt veroorzaakt door het simpele feit dat je je er al een tijdje vanaf hebt gekeerd. Java is pas groot geworden sinds Java 2 en de vele prachtige libraries die bijvoorbeeld binnen het JCP zijn ontwikkeld. Jouw beeld van Java komt wellicht niet helemaal overeen met de huidige stand van zaken. Als je alleen maar eens naar de vrachten slides van JavaOne gaat kijken, zal je zien dat er erg veel interessante ontwikkelingen zijn, van Sun zelf, maar vooral van vele andere bedrijven.

[mbravenboer]

Een tool/taal/platform is er niet voor de musea. Dat is er om het te gebruiken (in allerlei vormen). 'Hoe moet het beter', kan dan imho ook alleen maar dat doel dienen, of een onderzoek dat als resultaat moet hebben een algehele definitie ter ondersteuning van 'hoe moet het beter' op een meer abstract vlak binnen software development. Maar indirect komt dat laatste weer terug in de vorm van het eerste.

Inderdaad en dat merkte ik ook op in mijn latere stukje over productiviteit. In de beoordeling van mogelijkheden van een platform zou het echter niet moeten draaien rond een makkelijke installatie van een web-server een fantastische alles in 1 IDE en dergelijke. De potentie van een taal/platform ontstaat naar mijn mening allereerst door de taal, de architectuur van het platform. Daarna is het voor praktische realisatie van deze potentie van groot belang om de tools netjes op orde te hebben.

Dat heeft geen moer met de discussie die je opstarte te maken.

Zeker niet, maar heeft dit hele topic iets te maken met de discussie die ik opstarte? . Ik vond dit passen in de richting waar de discussie heen ging, maar zal er dan maar niet op in gaan.

[mbravenboer]

Wat ik echter vrees voor Java is dat voor .NET er talen komen die met een nog ruimere expressiekracht hetzelfde platform targetten, waardoor Java een 'bewerkelijke' taal wordt.

En daar komen we dus op het originele onderwerp . Ik zie talen als C# en VB .NET niet direct als talen met essentieel ruimere expressiekracht, dus ik ga er maar even vanuit dat je doelt op een mogelijke opkomst van declaratieve talen zoals bijvoorbeeld functionele-talen, transformatie-talen, logische talen en dergelijke. Het essentiele punt van de hele discussie over de multi-language mogelijkheden van .NET is dat het naar mijn mening niet essentieel meer biedt dan het Java Platform. Er zijn zeker enkele constructies die voor een betere performance zullen zorgen, maar daarbuiten is er weinig nieuws onder de zon, behalve dat het platform ook gepresenteert wordt als multi-language.

Er zijn op dit moment al aardig wat taaltjes die naar de JVM compileren (inderdaad, geen van alle echt breed geaccepteerd) en alle talen die naar .NET IL gaan compileren zullen denk ik ook naar Java Bytecode gecompileerd gaan worden. Compilerbouwers laten zich niet alleen voorlichten door de presentatie van een platform, die kunnen zelf de mogelijkheden wel beoordelen.

Als je dus ziet dat de talen die al naar de JVM gecompileerd zijn niet echt geaccepteerd zijn (om wat voor reden dan ook) kan je je afvragen of dit wel een succesvol verhaal voor .NET zal zijn (helaas). Als dat zo blijkt te zijn, moet er uitgezocht worden waarom het op beide platformen geen succes verhaal is (waar ik zo wel mijn ideeen over heb).

Zodra bv Mono klaar is, is dat niet meer zo.

Je zegt het goed: zodra . Mono vind ik een goed innitiatief, maar voorlopig vrijwel volledig kansloos in de huidige opzet imho. Ik heb het daar al vaak over gehad, dus dat zal verder wel duidelijk zijn.

[mbravenboer]

Maar op zich is dat de issue niet eens: een taal is een tool, niet een onderwerp. Je zult dus de taal niet centraal moeten stellen voor de toekomst, want zodra iemand een tool verzint die superieur is aan de jouwe ben je weg.

Mwah... niet mee eens: een taal stelt jou in de gelegenheid om een probleem op een bepaalde manier uit te drukken. Een tool-set om deze taal heen zorgt ervoor dat dit ook daadwerkelijk gebruikt kan worden op een ander niveau. 'Tools' zijn heel efficient, zeker tools die genereren, maar de input van deze tool is vrijwel altijd een taal, die vaak steeds specificerender zal zijn (denk aan de grammatica's van parser-generators). Talen zijn denk ik de krachtigste manier om je uit te drukken en zullen daarom altijd een centrale rol blijven spelen als de input en output van tools.

Ik geloof dus niet in magische tools die ineens een probleem voor je oplossen. Wel geloof ik in tools die irrelevante details voor je verbergen en je dus meestal meer specificerend (delcaratief) bezig laten zijn. Dit is echter geen magische tool, maar gewoon een generatie/compilatie/transformatie proces van taal x naar taal y.

dat ik niet echt snap waarom mensen nog lopen te krassen in Java vanuit editors als Emacs, terwijl er superieure omgevingen zijn die veel werk uit handen nemen.

IDE discussies zijn zeer boeiend, maar als ik daar ook nog op in ga, wordt dit helemaal een prut-topic .

Services based remote computing

.

Je gebruikt functionaliteit, ongeacht het platform waar de service die je gebruikt op draait. Platformonafhankelijkheid verwordt op die manier tot een niet-relevant zijnde eigenschap.

Je gaat er voor het gemak even aan voorbij dat de service ook nog op een platform moet draaien. Als je ziet dat server-side ontwikkeling op dit moment de voortduwer van Java is en dat ook hier voor de gebruiker het echte platform irrelevant is, belooft dat kennelijk een gouden toekomst van platform-onafhankelijkheid. Als .NET dat gaat bieden (via Mono of andere projecten) is dat fantastisch, maar Java biedt het al enkele jaren en zal het dus sowieso doen.

Sun weet dat ook, het positioneert Java allang niet meer met die eigenschap.

Mwah, ik weet niet waar jij dat uit afleidt, maar dat heb ik in ieder geval nog niet opgemaakt uit de uitlatingen van Sun.

Maar dat is toch het enige dat telt? Of zie ik het verkeerd?

Tja, dat voor jou MS Windows het enige platform is wat telt, moet je zelf weten. Zelf denk ik dat andere platformen ook relevant zijn.

Een Windows 2000 + .NET wint het op functionaliteit voor de developer altijd van een Linux / Solaris + Java oplossing.

Mwah, als je echt specifieke functionaliteit van een platform nodig hebt is Java als snel geen goede optie meer omdat JNI nu ook niet bepaald het einde is. Voor vrachten applicaties voldoet de standaard omgeving die Java via de library biedt uitstekend en .NET biedt op dat punt niet veel meer. Dat jij het MS Windows platform helemaal fantastisch vindt en dat jij deze functionaliteit via .NET kan beanderen betekent niet dat iedereen dat vindt of dat iedereen deze functionaliteit moet benaderen.

Textbased talen zijn sowieso inferieur. Logische systemen zoals Biztalk server 2000 implementeert oftewel, visueel je business logic definieren opdat je gedigitaliseerde informatiestromen langs de juiste banen worden geleid en de juiste bewerkingen plaatsvinden. Dat is overzichtelijk voor een visueel ingesteld wezen als de mens. Textbased talen die eerst door de mens, al lezende, moeten worden geinterpreteerd zijn daaraan echt ondergeschikt.

. Het zal je duidelijk zijn dat ik het hier absoluut niet mee eens ben. Het onderzoek naar nieuwe talen toont in ieder geval aan dat de grote meerderheid van de onderzoekers het hiermee eens is. Visuele versus taal gebaseerd omgevingen is echter ook weer een discussie apart, dus ook hier ga ik maar even niet op in om een explosie van discussies in 1 topic te voorkomen.

In de IT is al 20 jaar lang een blindheid heer en meester waar ik, wanneer ik er aan denk, gewoon niet over uit kan: Als het easy te gebruiken is, is het voor dummies.

Ik denk dat daar wel een redenering achter zit. Eenvoudige omgeving zijn op dit moment nog vaak omgevingen waarbij visueel wordt gewerkt. Deze omgevingen kenmerken zich op dit moment nog door een focus op een zeer specifieke toepassing met weinig nieuwe mogelijkheden of uitdrukkingskracht. Wil je iets nieuws? Nieuw visueel tool. Nieuwe wizard.

Talen zijn een manier om je uit te drukken, niet geevenaard in uitdrukkingsmogelijkheden imho. Als je een probleem wilt implementeren moet je dit uitdrukken. Liefst uiteraard op een zo duidelijk en compact mogelijke manier.

Er zijn ook meer dan genoeg omgevingen die makkelijk zijn en ik niet zou willen beperken tot gebruik door dummies . Neem bijvoorbeeld eens Relax NG versus W3C's XML Schema. Als iets niet voor dummies is, is het XML Schema wel. Ingewikkelde zooi. Relax NG is eenvoudig en makkelijk te leren en te gebruiken. Toch zou ik Relax NG niet durven afkraken omdat het een uitermate krachtige taal is waarvan is bewezen dat het een grotere klasse van XML documenten kan beschrijven dan W3C's XML Schema. Easy & Cool kan dus best samengaan.

Als ik Linux met Java wil gaan gebruiken, en ik ken java, ben ik nergens. Ik kan in Java wel wat programmeren, maar ik heb essentiele kennis van het OS nodig.

Dat vind ik dus echt een onzinnige redenering. Het platform is irrelevant als je met Java wilt programmeren. Je kunt al je Java kennis dus inzetten op alle platformen. Dat je een platform moet kennen om een beetje files op te kunnen slaan, compileren en dergelijke spreekt voor zich en dat geldt dus ook voor MS Windows.

Overigens zijn er ook tools die ook op dit punt nog abstraheren. Ant is een platform-onafhankelijk build-tooltje wat uitermate populair is in de Java wereld. Build-files werken op beide platformen en je kan je Ant gebaseerd project dus zo van een MS Windows op een Linux machine overzetten zonder problemen.

Java is niet 1 platform met daarin ALLE functionaliteit om compleet Linux te beheren, de configureren en applicaties op te draaien. Ik ben als developer aangewezen een hele santemekraam aan tools, libs, etc. Kan ik vanuit Java apache configureren?

Sorry hoor, maar dat is dus pas echt irrelevant. Denk je nu echt dat elke developer van server-side Java applicaties kennis heeft van alle mogelijke configuraties van webservers of servlet-containers? Dat is juist irrelevant in een organisatie. Experts moeten zich bezig houden met deployment en configuratie van web-applicaties.

Overigens staat het hele Linux verhaal natuurlijk in principe los van Apache. Ik moet niet op Linux ontwikkelen omdat ik Apache dan moet leren configureren .

Lekker belangrijk, maar die kennis wil ik niet en HOEF ik ook niet

Daar zijn we het dus over eens .

Want zeg nou zelf: visueel designen van functionaliteit is superieur aan het textueel verwoorden van diezelfde functionaliteit: readability. De mens KAN geen programmateksten interpreteren, tenzij de taal die gebruikt is gelijk staat aan natuurlijke taal en dan nog zie je misinterpretaties.

We zien geloof ik een wat andere toekomst, want jij lijkt ervan overtuigd dat ik wel moet toegeven dat visueel werken superieur is ten opzichte van talen .

Visueel werken is totaal ondergeschikt aan werken via talen . Als jij visueel wilt werken, waarom praat je dan niet via plaatjes? Als je een appel wilt bij de groenteboer laat je gewoon een plaatje zien of teken je ff een appel.. (ok, beetje onzinnige vergelijking ). Talen zijn imho op dit moment niet te evenaren in uitdrukkingskracht en zullen dat nog lang blijven. Visualisatie moet je denk ik los zien van uitdrukkings-mogelijkheden. Tools die code visualiseren zullen zeker een belangrijke rol gaan spelen.

[Verwijderd]

Als je natuurlijke taal tussen mensen gelijk ziet aan instructietalen voor het schrijven van programmatexten, en niet snapt dat buiten de Java API je je echt in bochten moet wringen met specifieke OS kennis in de hand om iets te bereiken, dan heb je mn betoog niet begrepen.

Je gaat helemaal voorbij aan het feit wat ik wil benadrukken mbt de discussie beter/best. Wel een enorme sof posting dit, maar alles wat ik wilde zeggen heb ik al gezegd, nogmaals: probeer te begrijpen wat ik bedoel. Dat is de kern van hoe een ontwikkelaar tegen software bouwen aankijkt en wat de KERN is van software, computers en de plaats van die 2 in onze samenleving. IEDERE tool en IEDERE taal die ik zie die niet in staat is intuitief de user te leiden om de taak te volbrengen waar de taal/tool voor is, schiet te kort.

Verder stoort het me mateloos dat je een beter/slechter analyse discussie opstart maar wanneer er een beter/slechter analyse terugkomt dat totaal niet matcht met wat je voor ogen stond. Jij weet net zo goed als ik dat je op een hoger niveau alleen kunt discussieren over onderwerpen als je de randvoorwaarden hebt gedefinieerd. Kennelijk komt jouw 'beter/slechter' definiering totaal niet overeen met de mijne, want we praten totaal langs elkaar heen.

Ook precies de reden waarom ik in mn 3e jaar naar het HBO ben teruggegaan: de discussies op een universiteit zijn soms interessant, maar veelal overbodig gebazel (no offence, nofi, algemene opmerking) zonder realiteitsbesef.

Voorbeeld?
De discussie wat het beste platform zou kunnen zijn, in het kader van 'multi-language, multi-platform, multi-application-paradigm' is MATELOOS interessant.
Deze discussie echter is niet die discussie, terwijl ik het gevoel krijg dat je juist wel DIE discussie wilt voeren. Nu krijg ik de indruk dat je .NET en Java wilt toetsen aan een zekere, niet uitgesproken lijst beter/slechter properties, die juist uit de discussie die ik hierboven noemde moet resulteren, maar die is nog niet gevoerd (althans niet hier). Beter/slechter krijgt dus voor iedere lezer een andere betekenis.

Ik snap best dat vanuit jouw specialisatie de discussie omtrent MSIL / Javabytecode en in hoeverre deze geschikt zijn voor andere talen, mateloos interessant is, maar ik denk dat je dan je discussie iets anders had moeten starten, want ik kreeg iig niet de indruk dat je daarover wilde praten.

De afgelopen jaren heb ik veel nagedacht over automatisering als geheel, wat de kern nu precies is, en hoe computers daarin een rol kunnen spelen (klinkt niet logisch, is het wel ) en kwam tot de conclusie dat details omtrent technieken niet interessant zijn. Ja, ze zijn interessant voor mensen die direct betrokken zijn bij de producten en waarbij detail A een levenswerk is, bij wijze van spreken. Wat telt is functionaliteit. Functionaliteit in de ruimste zin van het woord, dus ook: hoe biedt het de developer/software designer ruimte om expressiever om te gaan met de functionaliteit opdat de te bouwen functionaliteit sneller/beter wordt gerealiseerd.

Ik heb dus kennelijk de discussie verkeerd begrepen en veel tijd gestoken in een erg lang verhaal dat achteraf gezien IMHO dus niet op de discussie sloeg. Naja, volgende keer beter.

[mbravenboer]

Otis: en niet snapt dat buiten de Java API je je echt in bochten moet wringen met specifieke OS kennis in de hand om iets te bereiken, dan heb je mn betoog niet begrepen.

Tja, ik heb net duidelijk gezegd dat de behoeftes per applicatie verschillen en dat de Java API naar mijn mening voor normale applicaties veelal ruim voldoet. OS specifieke kennis heb je maar in een beperkte klasse van applicaties nodig.

Verder stoort het me mateloos dat je een beter/slechter analyse discussie opstart maar wanneer er een beter/slechter analyse terugkomt dat totaal niet matcht met wat je voor ogen stond.

Ik vind dat je zo helemaal geen beter/slechter discussie kunt voeren. Het topic is begonnen met een column van Bertrand die wat onrelativerend aan het bazelen was. Ik probeerde een discussie over de veschillen in architectuur te starten tussen Java en .NET. Dat gaat dus vooral over de intermediate representations: de instructie-set van Java Bytecode en .NET IL. Ik heb hier echter nog maar weinig zinvols over horen zeggen en de hele discussie is gestrand in een discussie over de tools rond het platform, wat absoluut irrelevant is als je het over de language-interop wilt hebben.

maar veelal overbodig gebazel (no offence, nofi, algemene opmerking) zonder realiteitsbesef.

Tja, pijnlijk feit is dan toch wel dat de interessante ontwikkelingen toch voortkomen uit onderzoek op universiteiten of onderzoeks-afdelingen van bedrijven. Ik ben druk bezig met het bouwen van compilers met behulp van programma-transformaties wat een fantastisch paradigma gaat worden. De universiteit is de kweekvijver voor zulk soort materiaal. Als je alleen applicaties wilt ontwikkelen in een commerciele omgeving, is de universiteit inderdaad voor een groot deel tijdsverspilling.

terwijl ik het gevoel krijg dat je juist wel DIE discussie wilt voeren.

Inderdaad! Maar dus wel aan de hand van gedachten over IL, Java Bytecode, beschikbare instructies en de samenwerking tussen talen. Niet op basis van tools, tools en IDE's.. Ik ben niet begonnen met een discussie over OS'en, documentatie, IDE's, visueel programmeren en dergelijke. Stuk voor stuk leuke onderwerpen, maar wel off-topic helaas.

Ik snap best dat vanuit jouw specialisatie de discussie omtrent MSIL / Javabytecode en in hoeverre deze geschikt zijn voor andere talen, mateloos interessant is, maar ik denk dat je dan je discussie iets anders had moeten starten, want ik kreeg iig niet de indruk dat je daarover wilde praten.

Hum, ik heb inderdaad wat algemenere opmerkingen gemaakt in mijn eerste post die deze discussie niet ten goede zijn gekomen. Het was meer een anti Bertrand post dan de start van een goede discussie .

De afgelopen jaren heb ik veel nagedacht over automatisering als geheel, wat de kern nu precies is, en hoe computers daarin een rol kunnen spelen (klinkt niet logisch, is het wel ) en kwam tot de conclusie dat details omtrent technieken niet interessant zijn. Ja, ze zijn interessant voor mensen die direct betrokken zijn bij de producten en waarbij detail A een levenswerk is, bij wijze van spreken. Wat telt is functionaliteit. Functionaliteit in de ruimste zin van het woord, dus ook: hoe biedt het de developer/software designer ruimte om expressiever om te gaan met de functionaliteit opdat de te bouwen functionaliteit sneller/beter wordt gerealiseerd.

Als ik dit stukje lees wil je kennelijk visionair bezig zijn . Ik zou zeggen: verbeter dan de academische wereld als die zo slecht bezig is .

Verder is de discussie sowieso niet erg zinvol hier denk ik bij nader inzien... Om hier goed over te praten moet je eigenlijk enkele talen naar beide platformen hebben gecompileerd (wat ik nog niet heb gedaan btw ) en de instructie-sets op je duimpje kennen. Hier verzeild het al snel in een discussie van gebruikers platformen die positieve en negatieve ervaringen met tools en talen uitwisselen... Verkeerde plaats dus ...

[Verwijderd]

Waarom verkeerde plaats? ik denk eerder: verkeerd materiaal waarmee je gestart bent. Een discussie omtrent de 3 punten die ik noemde, hoeft niet meteen (ik hoop eigenlijk nooit) te verzanden in details omtrent MSIL etc, want dat is eerder het toetsen van bestaande technieken aan hetgeen je hebt gesteld als randvoorwaarden voor je 'best platform for multi-language/multi-platform/multi-paradigm'.

Vanuit een talendesigner kan ik me voorstellen dat er wellicht verschrikkelijke fouten in de MSIL implementatie zitten die design van talen sterk beknot (ik noem maar iets). Voor een developer echter is dit zo mateloos irrelevant Maar, en dat is ook denk ik het punt een beetje van de miscommunicatie, IMHO is die interpretatie door de developer van de problematiek van de talendesigner wel degelijk belangrijk voor diezelfde talendesigner. Net zo goed dat de MOTIVATIE van de talendesigner weer belangrijk is voor de developer. Dat mis ik wel een beetje: ik krijg sterk de indruk dat de 'eindgebruikers' van platforms ook echt als eindgebruikers worden gezien door talendesigners op universiteiten. Je haakt nu ook af terwijl dat dus imho niet nodig is, sterker als ik talendesigner was, zou ik JUIST willen weten wat NODIG is voor softwaredevelopment, ipv te gaan kijken naar puur technologische ontwikkeling, zonder daarbij ooit de vraag te stellen of het uberhaupt zal leiden tot praktisch nut (ok, het is niet altijd gezond om praktisch nut bij je onderzoek te betrekken, maar het gaat hier zo direct om gebruiksvoorwerpen die worden ontwikkeld op universiteiten, dat je daar ook toch wel die vraag mag stellen: "is dit praktisch nuttig of niet?")

[Scare360]

Op donderdag 09 mei 2002 12:29 schreef mbravenboer het volgende:
Ik denk dat we gewoon moeten concluderen dat mensen altijd het platform waarin ze het beste thuis zijn ook gelijk als makkelijkste ervaren. Dat de andere platformen naar hun mening slechter zijn is wellicht voor een groot deel niet zozeer de schuld van die platformen, maar van het geringere overzicht. Zulke benaderingen staan een echte discussie over de technologische verschillen erg in de weg, hoe praktisch van belang de aangedragen verschillen ook zijn.

Uhm Unix en toch voor C#/.NET gekozen... jouw stelling gaat voor mij "persoonlijk" niet op. Ik heb een behoorlijke investering in Java gedaan kwa tijd en moeite. Conclusie "NEE" voor mij geen Java. C/C++ genieten dan mijn voorkeur. Ik kan absoluut niet mee met de discussie aangezien ik gewoonweg te weinig bagage heb om me hier in te mengen. Feit blijft dat C# erg goed bevalt...en volgens mij bevalt het jouw ook wel mbravenboer. De meeste post van je zijn toch vrij positief tov .NET/C#. Of ben ik nu helemaal het spoor bijster?

[mbravenboer]

Otis: IMHO is die interpretatie door de developer van de problematiek van de talendesigner wel degelijk belangrijk voor diezelfde talendesigner.

Daar heb je inderdaad wel een goed punt van kritiek denk ik. Dit is iets wat ik ook wel mis. De heren onderzoekers zouden op GoT moeten zitten .

[mbravenboer]

paulgielens: Feit blijft dat C# erg goed bevalt...en volgens mij bevalt het jouw ook wel mbravenboer. De meeste post van je zijn toch vrij positief tov .NET/C#. Of ben ik nu helemaal het spoor bijster?

Zeker, dat klopt helemaal. .NET met z'n libraries, opzet en C#. vind ik een zegen voor de ontwikkeling voor het Microsoft Windows platform .

Ik wil wel de claims die gemaakt worden bespreken over bijvoorbeeld de language-interop bespreken en eventueel bestrijden .

[Verwijderd]

Op donderdag 09 mei 2002 10:32 schreef mbravenboer het volgende:
Tjonge, jonge hoe blind kan je zijn?

Hoezo? Kennelijk vond Microsoft dingen als multiple inheritance te minderwaardig om in .NET te stoppen.

C++ is niet aangepast om Microsoft het object-model van C# superieur vond aan dat van C++. C++ zou nooit goed in .NET passen (prettig aanvoelen) als het niet aangepast was.

De vraag is: waarom hebben ze .NET zo ontworpen? Aannemend dat Microsoft bij het ontwerpen van .NET (en C#) ook C++ in het achterhoofd heeft gehouden kunnen we dan toch concluderen dat ze dit model superieur vinden aan dat van C++?

Ik maak me af en toe best zorgen over de toekomst van C++ op het .NET platform..

[mbravenboer]

Sneechy: Hoezo? Kennelijk vond Microsoft dingen als multiple inheritance te minderwaardig om in .NET te stoppen.

Ik bedoelde dat Microsoft graag C++ exact over had genomen in .NET als dat mogelijk was geweest. Dat is echter niet mogelijk omdat bijvoorbeeld multiple inheritance niet ondersteund wordt, maar dat is maar 1 van de vele punten.

De vraag is: waarom hebben ze .NET zo ontworpen? Aannemend dat Microsoft bij het ontwerpen van .NET (en C#) ook C++ in het achterhoofd heeft gehouden kunnen we dan toch concluderen dat ze dit model superieur vinden aan dat van C++?

Superieur is denk ik niet het goede woord. C++ past op de klassieke wijze denk ik niet binnen bepaalde doelstelling van .NET...

Ik kan natuurlijk niet in de brein kijken van de mensen bij Microsoft en heb over de keuzen van C++ in de .NET 'variant' ook maar weinig gelezen. Er is hier sowieso niet veel aandacht voor bedenk ik me nu...

Ik maak me af en toe best zorgen over de toekomst van C++ op het .NET platform..

Dat geloof ik graag, want voor de echte C++ zie ik eigenlijk maar weinig toekomst in .NET...

Het grote probleem van een feature-rijke intermediate language is behalve veiligheid bijvoorbeeld ook dat alle talen die deze intermediate language targetten eigenlijk ook deze features moeten hebben om goed te passen in het geheel en te kunnen samenwerken met andere talen. Dit speelt vooral als je het over talen binnen hetzelfde paradigma hebt, omdat je dan vrijwel vlekkeloze samenwerking verwacht. Voor echte conceptueel andere talen is dat minder relevant...

[Verwijderd]

Op zaterdag 11 mei 2002 14:51 schreef Sneechy het volgende:
[..]
Hoezo? Kennelijk vond Microsoft dingen als multiple inheritance te minderwaardig om in .NET te stoppen.

Minderwaardig zou ik het niet noemen, maar multiple-inheritance is niet nodig en voegt een inmense complexiteit toe aan de JIT en aan de compilers.

[..]
De vraag is: waarom hebben ze .NET zo ontworpen? Aannemend dat Microsoft bij het ontwerpen van .NET (en C#) ook C++ in het achterhoofd heeft gehouden kunnen we dan toch concluderen dat ze dit model superieur vinden aan dat van C++?

C++ is alleen in complexiteit superieur, dus daar zijn we snel mee klaar.

Serieus: als je een OO runtime ontwerpt, kies je een paradigma dat voldoet. Semantisch is single inheritance voldoende: iedere derived class specialiseert zn parent. Het enige dat multiple inheritance toevoegt hieraan is dat die specialisatie ook kan worden betrokken van een class. Echter implementatie-technisch is dit een complex geheel, zeker wanneer je spreekt over een OO api. Ik kan zo 1 2 3 niet het document vinden waar ze (.net team) uitleggen waarom multiple inheritance een foute keuze zou zijn geweest... helaas.

Ik maak me af en toe best zorgen over de toekomst van C++ op het .NET platform..

Je moet wel heel erg veel van templates houden om nog C++ te gebruiken icm .NET (that is: managed code extensions).

[Verwijderd]

Op zaterdag 11 mei 2002 16:18 schreef Otis het volgende:
Serieus: als je een OO runtime ontwerpt, kies je een paradigma dat voldoet. Semantisch is single inheritance voldoende: iedere derived class specialiseert zn parent. Het enige dat multiple inheritance toevoegt hieraan is dat die specialisatie ook kan worden betrokken van een class.

Als ik class hiërarchieën voor OO systemen verzin komen er in deze hiërarchieën af en toe 'automatisch' multiple inheritance relaties voor; ze zijn voor mij compleet logisch en 'natuurlijk' in de context van het OO paradigma.

Als ik programmeer in een taal zonder MI en zo'n situatie tegenkom voel ik me snel beperkt; het voelt dan heel onnatuurlijk aan om met een of andere omweg (interfaces ) het gewenste effect te benaderen.

Microsoft denkt hier klaarblijkelijk fundamenteel anders over, anders hadden ze zo'n basisconcept echt wel in C# en .NET ingebakken. Ik denk niet dat die complexiteit (die me overigens wel mee lijkt vallen) dan een rol zou spelen.