[Alg./.NET] Microsoft verliest vertrouwen in .NET?

zaterdag 12 februari 2005 11:12

-= Tja =-

Arnaud schreef op vrijdag 11 februari 2005 @ 16:57:
MS heeft heel goed gezien wat de zwakke punten van Java zijn (performance

Performance? . java is snel.. Heb jij serieuze cijfers?

1 taal, matige IDE's

Matige ide`s? Sorry.. .NET heeft imho geen IDE die het haalt bij bv IntelliJ Idea. Features die je daar al jaren in ziet beginnen nu heel matig tevoorschijn te komen in .NET IDE`s. .NET loopt qua refactoring en symatische analyse jaren achter. Zelfs de nieuwste versie van VS.NET is nog steeds een joke als het gaat om codeinzichtelijkheid.

, veel moderne "vastgeplakte" uitbreidingen).

Hmm... Sun maakt specificaties en andere bedrijven kunnen implementaties van die specificaties schrijven. Kijk eens hoeveel servlet containers er zijn die allemaal voldoen aan de servlet specificaties. Ik heb zoiets nog niet echt kunnen ontdekken voor .NET.

Mono is het beste voorbeeld dat iedereen met .NET aan de gang mag gaan op elk willekeurig platform. Ook .NET kan dus prima op een monster van een Linux (of Windows)-cluster draaien.

Mono heeft imho absoluut geen kans om te winnen. Het is een leuk knuffelprojectje maar geen serieus alternatief. Als ik onder linux zou moeten draaien zou ik gaan voor een platform waar er veel support en implementaties zijn, en dat is niet mono. Als ik onder windows moet draaien heb ik de keus uit .NET en Java. Mono = geen echt alternatief imho.

Verder zijn we het denk ik aardig eens. De ideëen achter .NET zijn niet nieuw, de uitwerking ervan is erg goed en in de toekomst zal .NET alleen maar groter groeien. Al met al zijn we het dus duidelijk niet eens met de TS.

Hmm tja.. .NET groeien. Ik weet het niet. Java = een extreem groot en door ontwikkeld platform. Qua tools is .NET imho nog lang niet volwassen genoeg.

Ik denk dat we over een jaar of 3 maar eens meer moeten kijken wat het beste alternatief is. Maar op dit moment vind ik .NET qua tools beperkt.

[ Voor 6% gewijzigd door Alarmnummer op 12-02-2005 11:12 ]

Acties:

zaterdag 12 februari 2005 11:23

Johnny schreef op zaterdag 12 februari 2005 @ 10:50:
En Mac OS X en Symbian?

Bij beide systemen is Java veel meer ingeburgerd dan op het Windows platform. En vooral Symbian is sterk in opkomst. Inmiddels kennen veel mensen de term "Java games" al, waardoor Java het imago "leuk en makkelijk" krijgt, zonder dat men weet wat het precies is.

Lekker belangrijk. Een enterprise applicatie draaien op platform X omdat platform X 'leuk en makkelijk' als imago heeft lijkt me uitgesloten.

Men vergeet dat 90+% van de desktop computers op deze aardkloot windows draait en dat het leeuwendeel van de ontwikkelaars op deze planeet ervaring heeft met het ontwikkelen van software voor windows of platforms draaiend op windows. .NET bestaat nog maar 3 jaar publiekelijk, java al meer dan 10 jaar, geen wonder dat het veel gebruikt wordt in de server wereld.

De desktop is voor java totaal oninteressant. In 1994 vond Sun dat de desktop MET java de toekomst was, dat was een domme zet en dat weten ze nu ook. Java is op zn best op de server, dat spelletjes nu in java geschreven zijn, is IMHO alleen maar nadelig voor dat server-is-my-real-home imago.

Matige ide`s? Sorry.. .NET heeft imho geen IDE die het haalt bij bv IntelliJ Idea. Features die je daar al jaren in ziet beginnen nu heel matig tevoorschijn te komen in .NET IDE`s. .NET loopt qua refactoring en symatische analyse jaren achter. Zelfs de nieuwste versie van VS.NET is nog steeds een joke als het gaat om codeinzichtelijkheid.

Nou nou... een grap zou ik het niet willen noemen. Zoals ik hierboven al zei: refactoring is leuk, maar is niet gratis en refactoring add-ins zijn gewoon toe te voegen aan vs.net, maar toegegeven, het was leuk geweest als het er meteen in had gezeten. Wat me wel van het hart moet is dat ik me werkelijk niet voor kan stellen dat de performance van IntelliJ uitmuntend zal zijn bij een inmens project (200.000 regels code of meer), daar analyse van de code OOK in java gebeurt, en tijd kost, en bij wijziging van code dus ook die analyse weer gestart moet worden. Resharper is ook van Jetbrains, en ze passen dezelfde dingen toe op de C# code. Nou... dat zakt behoorlijk door zn hoeven op een gegeven moment. Je maakt mij echt niet wijs dat het in IntelliJ ineens wel supersmooth en zonder slowdowns allemaal kan.

Hmm tja.. .NET groeien. Ik weet het niet. Java = een extreem groot en door ontwikkeld platform. Qua tools is .NET imho nog lang niet volwassen genoeg.
Ik denk dat we over een jaar of 3 maar eens meer moeten kijken wat het beste alternatief is. Maar op dit moment vind ik .NET qua tools beperkt

Ik denk dat dat erg meevalt. Wat een Java programmeur vaak vergeet is dat bij .NET je niet een hele santemekraam aan losse tooltjes en App servers nodig hebt om je applicatie te draaien, die zitten nl. OF in .NET OF in het OS. Bv transaction management. COM+ heeft al die services al ingebouwd, ik heb dus op .NET geen appserver nodig voor al die zaken, dat zit in het OS.

Wat een Java programmeur mist op .NET zijn standaarden zoals EJB. Niet dat iedere javaprogrammeur daar nu warm voor loopt, maar toch, ze zijn er niet op .NET. Dat 'komt met indigo en longhorn'.

[ Voor 47% gewijzigd door EfBe op 12-02-2005 11:21 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

Daventry

EfBe schreef op zaterdag 12 februari 2005 @ 11:12:
[...]

Lekker belangrijk. Een enterprise applicatie draaien op platform X omdat platform X 'leuk en makkelijk' als imago heeft lijkt me uitgesloten.

Men vergeet dat 90+% van de desktop computers op deze aardkloot windows draait en dat het leeuwendeel van de ontwikkelaars op deze planeet ervaring heeft met het ontwikkelen van software voor windows of platforms draaiend op windows. .NET bestaat nog maar 3 jaar publiekelijk, java al meer dan 10 jaar, geen wonder dat het veel gebruikt wordt in de server wereld.

En jij vergeet dat de meeste serieuze servers NIET op Windows draaien en dat als .NET ook een rol wil spelen in de iet of wat meer serieuze business/webapplicatie (we hebben het hier eventjes niet over een forumpje of een gastboek) ze er misschien wel voor willen zorgen dat .NET ook op dingen als een UNIX of linux fatsoenlijk draait.

Vindt MS dat niet belangrijk, en vinden ze het vooral belangrijk dat het ding op Windows goed werkt, zijn ze imho idioot om de rommel naar bytecode te vertalen ipv native code (omdat native code uitraard een stuk sneller is)

Java is op zn best op de server, dat spelletjes nu in java geschreven zijn, is IMHO alleen maar nadelig voor dat server-is-my-real-home imago.

Ik werk dag in dag uit met J2ME (dus spelletjes in JAVA) en begrijp even niet wat daar mis mee is. Qua performance draaien die dingen perfect, de enige problemen die wij tegenkomen zijn brakke implementaties, die aan de telefoon liggen.

Java is een all-round taal ... akkoord, voor de desktop zijn ze misschien niet de beste maar voor mobiele spelletjes is het gewoon een schitterende taal die zijn gelijke op dit moment niet kent (kijk maar eens naar een aantal spelletjes die gemaakt zijn voor de Nokia 60 series ... dan zie je wel dat er knappe dingen mogelijk zijn in JAVA op toestellen met een relatief beperkt aantal resources)

[ Voor 26% gewijzigd door Daventry op 12-02-2005 11:37 ]

zaterdag 12 februari 2005 11:31

Acties:

alienfruit

the alien you never expected

Ik ben zelf erg tevreden over de refactoring capiciteiten van Refactor! van DevExpress,
alleen dit heeft CodeRush nodig. Maar goed dat is in mijn opinie al een verplichtte add-on voor Visual Studio

Trouwens Java compiled toch ook naar bytecode? Zo ook Coldfusion MX 7 (naar Java). Ik zie het probleem ook niet Bytecode kan nog best knap snel zijn, de mogelijke performance "hit" geeft wel weer het voordeel dat .NET op alle platforms kan draaien bijv. via Mono of MS .NET freebsd versie.

URL:
http://www.devexpress.com/Products/NET/Refactor/

[ Voor 37% gewijzigd door alienfruit op 12-02-2005 11:34 ]

zaterdag 12 februari 2005 11:35

Acties:

zaterdag 12 februari 2005 11:44

-= Tja =-

EfBe schreef op zaterdag 12 februari 2005 @ 11:12:
[...]
Nou nou... een grap zou ik het niet willen noemen. Zoals ik hierboven al zei: refactoring is leuk, maar is niet gratis en refactoring add-ins zijn gewoon toe te voegen aan vs.net, maar toegegeven, het was leuk geweest als het er meteen in had gezeten.

Ik vind het zelf een tool die mijn productiviteit enorm verhoogt. Ohh.. het zit in een verkeerde package.. of de naam is niet duidelijk genoeg. Hopla.. en idea zoekt ook meteen in niet java bestanden wijzigingen die je eventueel kunt doorvoeren.

Wat me wel van het hart moet is dat ik me werkelijk niet voor kan stellen dat de performance van IntelliJ uitmuntend zal zijn bij een inmens project (200.000 regels code of meer), daar analyse van de code OOK in java gebeurt, en tijd kost, en bij wijziging van code dus ook die analyse weer gestart moet worden.

Ik heb persoonlijk nog nooit aan zulke grote projecten gezeten dus ik kan niet uit eigen ervaring spreken. En verder probeer ik grote systemen meestal kapot te hakken in kleinere systemen en die gooi ik dan in afzonderlijke projecten (is niet altijd mogelijk).

Resharper is ook van Jetbrains, en ze passen dezelfde dingen toe op de C# code. Nou... dat zakt behoorlijk door zn hoeven op een gegeven moment. Je maakt mij echt niet wijs dat het in IntelliJ ineens wel supersmooth en zonder slowdowns allemaal kan.

Ik heb tot zover nog nooit problemen gehad.

Ik denk dat dat erg meevalt. Wat een Java programmeur vaak vergeet is dat bij .NET je niet een hele santemekraam aan losse tooltjes en App servers nodig hebt om je applicatie te draaien, die zitten nl. OF in .NET OF in het OS. Bv transaction management. COM+ heeft al die services al ingebouwd, ik heb dus op .NET geen appserver nodig voor al die zaken, dat zit in het OS.

Yep. maar je moet ook denken aan log tools, parser generators, buildscripts, searchengines, etc etc. Java heeft daar enorm veel van. En alhoewel een enorme lading ook gewoon ronduit bagger is zijn er wel een aantal tools die ik onmisbaar vind.

Wat een Java programmeur mist op .NET zijn standaarden zoals EJB. Niet dat iedere javaprogrammeur daar nu warm voor loopt, maar toch, ze zijn er niet op .NET. Dat 'komt met indigo en longhorn'.

Hmm.. ik ben juist blij dat EJB op dit moment vrij snel grond aan het verliezen is aan bv Spring. EJB = een draak van een systeem. Het idee was leuk. uitvoering ronduit kut. EJB bepaalt je ontwerp.. niet de programmeur.. Verder is het ook volledig verweven met zijn container dus je kunt het ook voor geen meter testen.

[ Voor 10% gewijzigd door Alarmnummer op 12-02-2005 11:39 ]

Acties:

Daventry

alienfruit schreef op zaterdag 12 februari 2005 @ 11:31:
Trouwens Java compiled toch ook naar bytecode? Zo ook Coldfusion MX 7 (naar Java). Ik zie het probleem ook niet Bytecode kan nog best knap snel zijn, de mogelijke performance "hit" geeft wel weer het voordeel dat .NET op alle platforms kan draaien bijv. via Mono of MS .NET freebsd versie.

Vraag is: haalt .NET op andere platforms dezelfde (of ongeveer dezelfde) snelheid als op Windows?

Is bijvoorbeeld de Mono implementatie even snel als de .NET implementatie in Windows ... en zal Microsoft zich ook actief gaan bezighouden met het ontwikkelen van de nodige Virtual Machines (sorry, ken hiervoor de .NET naam niet) voor andere platforms?

Zo ja, is er geen probleem ...
Zo nee, dan mist .NET een beetje zijn doel vrees ik en had men beter niet met bytecode gewerkt

zaterdag 12 februari 2005 11:44

Acties:

zaterdag 12 februari 2005 12:21

-= Tja =-

alienfruit schreef op zaterdag 12 februari 2005 @ 11:31:
Ik ben zelf erg tevreden over de refactoring capiciteiten van Refactor! van DevExpress,
alleen dit heeft CodeRush nodig. Maar goed dat is in mijn opinie al een verplichtte add-on voor Visual Studio

Trouwens Java compiled toch ook naar bytecode? Zo ook Coldfusion MX 7 (naar Java). Ik zie het probleem ook niet Bytecode kan nog best knap snel zijn,

Java Bytecode is per definitie de allertraagste code die je maar kunt bedenken omdat het dus totaal niet geoptimaliseerd is (de optimize flag van de java compiler werkt zelfs niet eens meer). Gecompileerde java code kun je uitstekend decompileren naar java en krijg je exact dezelfde code terug. Het is niet de taak van de bytecode compiler om snelle code af te leveren want die bytecode is platform onafhankelijk, en ieder platform heeft zijn eigen optimalisaties. De JIT (Just In Time) Compiler is de compiler die het echte compileerwerk doet en deze wordt pas aangeroepen als je de applicatie uitvoert. De JIT zit in je vm en kan dus per plafform ander native gecompileerde code uithoesten).

Het compileer proces verloopt dus in 2 stappen:
Java -> Bytecode (wordt gedaan door de standaard java compiler)
Bytecode -> native instructies (wordt gedaan door de JIT)

Verder zijn ze trouwens al wel jaren bezig dat de gecompileerde code ook gecached kan worden, tussen meerdere runs van een applicatie .en het wordt al tijden belooft.. het zou in 1.5 zitten... maar nee.. de vlieger gaat weer niet op.

Maar ik heb er zelf niet veel problemen mee. Wij draaien alleen serverside apps en zelfs de opstart tijd van zo`n groot ding als JBoss is maar een paar seconden... Dus ik zie de toegevoegde waarde serverside er niet meer van in.

[ Voor 12% gewijzigd door Alarmnummer op 12-02-2005 11:49 ]

Acties:

alienfruit

the alien you never expected

Maar dan werkt het toch precies hetzelde als .NET gebaseerde toei

Zelf vind ik het punt van werkt .NET ook andere platforms niet echt punt.

An implementation of the runtime for the Common Language Infrastructure (ECMA-335) that builds and runs on Windows XP and FreeBSD

[ Voor 72% gewijzigd door alienfruit op 12-02-2005 12:29 ]

zaterdag 12 februari 2005 12:34

Acties:

zaterdag 12 februari 2005 14:00

-= Tja =-

Daventry schreef op zaterdag 12 februari 2005 @ 11:44:
[...]
Zo nee, dan mist .NET een beetje zijn doel vrees ik en had men beter niet met bytecode gewerkt

.NET heeft absoluut niet zijn doel gemist met bytecode. Het doel is om verschillende talen met elkaar samen te laten werken, en dat hebben ze voor elkaar gekregen door gebruik te maken van 1 universele instructieset: bytecode. Alle .NET talen compileren naar bytecode, dus alle talen kunnen elkaars componenten gebruiken.

Verder heeft bytecode nog veel meer voordelen oa security.

En het lijkt me verder ook vreemd dat ms veel behoefte zou hebben aan dat .NET ook op andere os`en kan draaien. Persoonlijk vind ik het meer een marketing stunt en eigelijk geen praktische waarde hebben. .NET is voor windows.. en bij mono hebben ze dat gewoon nog niet begrepen.. zinloos project.

[ Voor 23% gewijzigd door Alarmnummer op 12-02-2005 12:42 ]

Acties:

zaterdag 12 februari 2005 14:42

Daventry schreef op zaterdag 12 februari 2005 @ 11:23:
En jij vergeet dat de meeste serieuze servers NIET op Windows draaien en dat als .NET ook een rol wil spelen in de iet of wat meer serieuze business/webapplicatie (we hebben het hier eventjes niet over een forumpje of een gastboek) ze er misschien wel voor willen zorgen dat .NET ook op dingen als een UNIX of linux fatsoenlijk draait.

errr... volgens mij heb je het mis. Erg veel websites op IIS zijn webapplicaties die een big-iron Oracle doos zo bruikbaar voor het internet aanbieden. Verder zijn er best wel veel grote SqlServer databases (met duizenden tables). Je moet ook niet vergeten dat 1 grote big-iron box niet zo vaak gebruikt wordt. In heel nederland zijn er maar 1000 as/400's bv. Ook is de behoefte aan inmens grote databases en servers niet zo groot als men wel denkt. In nederland hebben we 600.000 bedrijven, waarvan slechts een fractie tot de grote bedrijven behoort. Nu zullen die wel grote servers gebruiken, maar het leeuwendeel gebruikt gewoon kleinere servers en die kunnen het prima aan.

Vindt MS dat niet belangrijk, en vinden ze het vooral belangrijk dat het ding op Windows goed werkt, zijn ze imho idioot om de rommel naar bytecode te vertalen ipv native code (omdat native code uitraard een stuk sneller is)

Jij snapt er weinig van volgens mij. At compiletime kun je code goed optimaliseren, maar alleen at runtime weet je de execution characteristics en kun je mbv een JIT ervoor zorgen dat code optimaler draait dan het met compile time analysis zou doen. Dmv bytecode krijg je dat voor elkaar.

De JIT is nu nog wat beperkt en native code is in veel gevallen wat sneller. Het nadeel van native code is wel dat je veel dingen mist zoals security (code security als ook gewone security) en echte type checking, dingen die mensen die puur op performance gefocussed zijn niet interessant vinden maar die wel erg belangrijk zijn voor het goed functioneren van software.

Ik werk dag in dag uit met J2ME (dus spelletjes in JAVA) en begrijp even niet wat daar mis mee is. Qua performance draaien die dingen perfect, de enige problemen die wij tegenkomen zijn brakke implementaties, die aan de telefoon liggen.

Ik zeg niet dat er iets mis aan is, ik zeg alleen dat java op de desktop niet de java is waar we het over hebben. Java op de desktop is al jarenlang een flop en dat weet sun zelf ook.

Java is een all-round taal ... akkoord, voor de desktop zijn ze misschien niet de beste maar voor mobiele spelletjes is het gewoon een schitterende taal die zijn gelijke op dit moment niet kent (kijk maar eens naar een aantal spelletjes die gemaakt zijn voor de Nokia 60 series ... dan zie je wel dat er knappe dingen mogelijk zijn in JAVA op toestellen met een relatief beperkt aantal resources)

Java is 2 dingen: een taal en een platform. Men haalt die dingen snel doorelkaar want ze hebben dezelfde naam. Java het platform is allround, er zijn voor weet ik wat voor hw platforms JVM's verkrijgbaar. Java als taal is op een andere manier allround.

En sorry, maar dat er spelletjes in gemaakt zijn maakt het niet iets fantastisch. In Z80 zijn ook de meests mooie spelletjes gemaakt, maar ik zou het nu niet een bijster goed platform willen noemen voor software development voor zeg... een enterprise database system (ja domme vergelijking, vandaar de metafoor)

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

alienfruit

the alien you never expected

Overigens wordt Flash Lite 1.1 ook erg interessant om op mobiele telefoons spellen te maken, het grootste probleem momenteel is dat er geen API's zijn om te praten met Bluetooth, fotocamera's e.d. Het is in iedergeval laagdrempeliger dan DoJava of J2ME en natuurlijk Symbian. Het zou nog wel een "hit" kunnen worden

zaterdag 12 februari 2005 15:11

Acties:

whoami

EfBe schreef op zaterdag 12 februari 2005 @ 10:45:
[...]

Ben ik het niet mee eens. Je kunt nog steeds je complete applicatie in een module bouwen, en erg veel mensen binnen het vs.net team doen er alles aan om sleur-n-pleur programming tot kunst te verheffen. Met als kers op de rottende taart: Edit & Continue

Tja, het is mogelijk, maar zijn ze dan goed bezig ?

Daventry schreef op zaterdag 12 februari 2005 @ 11:23:
[...]

En jij vergeet dat de meeste serieuze servers NIET op Windows draaien en dat als .NET ook een rol wil spelen in de iet of wat meer serieuze business/webapplicatie (we hebben het hier eventjes niet over een forumpje of een gastboek) ze er misschien wel voor willen zorgen dat .NET ook op dingen als een UNIX of linux fatsoenlijk draait.

Vroeger, ja... Echter, een UNIX doos onderhouden is nu ook niet zo goedkoop, en veel bedrijven werken ondertussen ook met Windows op hun servers.
Het was trouwens niet de bedoeling van MS om .NET echt cross-platform te maken; het was hun bedoeling om het 'cross-windows-platform' te maken.

Vindt MS dat niet belangrijk, en vinden ze het vooral belangrijk dat het ding op Windows goed werkt, zijn ze imho idioot om de rommel naar bytecode te vertalen ipv native code (omdat native code uitraard een stuk sneller is)

Wat hier eerder al gezegd is: het is pas at runtime dat je kan optimizen voor een specifiek platform.
Daarbij, als je trouwens native code wilt, dan kan dat in .NET (ngen tool).

[ Voor 59% gewijzigd door whoami op 12-02-2005 15:15 ]

https://fgheysels.github.io/

zaterdag 12 februari 2005 17:55

Acties:

Soultaker

Daventry schreef op zaterdag 12 februari 2005 @ 11:44:
Vraag is: haalt .NET op andere platforms dezelfde (of ongeveer dezelfde) snelheid als op Windows?

Microsoft mag hopen van niet. Als je een .NET application server onder UNIX net zo goed kan draaien onder Windows dan heeft Windows een stuk meer concurrentie. Ik weet niet precies wat Microsoft's plannen zijn, maar ik kan me voorstellen dat ze juist ook een deel van de servermarkt willen veroveren (omdat daar relatief veel te verdienen valt, omdat een groot deel van de servers door bedrijven en dus legaal gebruikt wordt). Het .NET platform is gratis, maar het besturingssysteem natuurlijk niet.

EfBe schreef op zaterdag 12 februari 2005 @ 14:00:
Jij snapt er weinig van volgens mij. At compiletime kun je code goed optimaliseren, maar alleen at runtime weet je de execution characteristics en kun je mbv een JIT ervoor zorgen dat code optimaler draait dan het met compile time analysis zou doen. Dmv bytecode krijg je dat voor elkaar.

Dat is het verhaal. Maar de praktijk is vooralsnog andersom. Een argument voor een native Java compiler zoals Excelsior JET is juist dat van te voren compileren betere performance oplevert. Dan blijft momenteel als argument voor bytecode de verifiability over.

Wat ik me afvraag is of het betere-performance-met-JIT-compilation-argument ooit waarheid wordt. De efficiëntie van Sun's Java compiler is met de JIT compiler in versie 1.4 wel gigantisch gestegen (en het geeft aan dat JIT-compilation een stuk zinniger is dan bytecode emulation) maar zijn ze ook in staat om het bestaande gat met native applications te dichten? Ik weet het antwoord niet.

zaterdag 12 februari 2005 19:04

Acties:

Verwijderd

Mensen blijven hameren op performance, performance dit, performance dat maar men vergeet eventjes ontwikkeltijd

Die performance is echt een non-argument aangezien je er zonder pardon een server naast plaatst. Servers zijn tegenwoordig goedkoper dan manuren. Daarbij heeft het ook weinig zin als je requests kunt uitvoeren op 0.00001ms maar, tenzij je cached, vervolgens wel bijv. 20ms moet wachten op de database. Lekker belangrijk dat applicatieserver A 2ms per 1000 requests sneller is dan applicatieserver B met een andere runtime. Zet er een server naast, ben je klaar.

zaterdag 12 februari 2005 19:55

Acties:

zaterdag 12 februari 2005 20:44

Soultaker schreef op zaterdag 12 februari 2005 @ 17:55:
Dat is het verhaal. Maar de praktijk is vooralsnog andersom. Een argument voor een native Java compiler zoals Excelsior JET is juist dat van te voren compileren betere performance oplevert. Dan blijft momenteel als argument voor bytecode de verifiability over.

Wat ik me afvraag is of het betere-performance-met-JIT-compilation-argument ooit waarheid wordt. De efficiëntie van Sun's Java compiler is met de JIT compiler in versie 1.4 wel gigantisch gestegen (en het geeft aan dat JIT-compilation een stuk zinniger is dan bytecode emulation) maar zijn ze ook in staat om het bestaande gat met native applications te dichten? Ik weet het antwoord niet.

Bij MS research zijn ze er heilig van overtuigd dat ze binnen enkele jaren een CLR kunnen maken met een jit die in de meeste gevallen C++ native code voorbijstreeft. Geen idee hoe ze dat gaan oplossen, maar 1 ding kunnen ze nog wel doen: at compile time hints meecompileren voor de JIT. Immers, als de JIT hints krijgt over de code die zijn geplaatst na uitvoerige compile-time analysis, kan de JIT wellicht veel betere beslissingen nemen wat te doen.

Ik kan het mis hebben, maar deed hotspot van Sun dit al niet?

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

Verwijderd

Ik hoop van harte dat Microsoft het .NET platform voorlopig laat bestaan. Het voordeel van het CLR model is dat ze een framework voor toekomstige platformen die ze maken (de opvolger van Longhorn, bijvoorbeeld) zouden kunnen maken die ervoor zorgt dat de software compatible blijft.

Ik werk bij een redelijk klein software bedrijf, en we hebben een mooi product, echter het kost de paar ontwikkelaars die we hebben meerdere jaren de tijd om over te schakelen naar een ander ontwikkelplatform (nu dus VB6 naar .NET). De lifecycle van een ontwikkeltaal moet zeker 10 jaar duren, anders is er voor de 'kleinere' ontwikkelaars weinig brood meer te verdienen

zondag 13 februari 2005 11:44

Acties:

zondag 13 februari 2005 11:45

Verwijderd schreef op zaterdag 12 februari 2005 @ 20:44:
Ik werk bij een redelijk klein software bedrijf, en we hebben een mooi product, echter het kost de paar ontwikkelaars die we hebben meerdere jaren de tijd om over te schakelen naar een ander ontwikkelplatform (nu dus VB6 naar .NET). De lifecycle van een ontwikkeltaal moet zeker 10 jaar duren, anders is er voor de 'kleinere' ontwikkelaars weinig brood meer te verdienen .

Het kostte mij 6 tot 8 maanden, en na een maand was ik al redelijk in staat om gewoon software te schrijven op .NET, en dan gebruikte ik ook nog C#. Als jij VB.NET neemt is de overstap helemaal niet zo bijzonder groot. Let maar eens op: pak vs.net en ga voor jezelf een .NET projectje doen, gewoon een of ander freubel applicatietje. Je zult zien dat het eerst even wennen is, maar daarna gewoon straight forward.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

prototype

Cheer Bear

Daventry schreef op vrijdag 11 februari 2005 @ 17:09:
[...]

3. Matige IDE's? Ik garandeer dat als je eenmaal met een pracht van een tool als IntelliJ of zelfs een Eclipse hebt gewerkt dat je dan nooit meer terugwil naar die slome Visual Studio .NET (refactoren anyone?)

Ik ben eergisteren naar het ASP.net seminar geweest te amsterdam, waar het e.e.a. aan nieuwigheden aan 't licht kwam mbt .net 2.
Refactoren zal ook in VS.net 2k5 zitten heb ik me door Scott Guthrie laten vertellen, en de performance is ook heel erg hard aan gesleuteld. Waar normaal een projectfile (die overigens tegenwoordig niet meer aanwezig is

) openen een seconde of 30 duurt op een 1,2ghz bak met 1gb aan ram, duurt 't nu nog maar 3-4 sec.
Wat betreft leercurves, 'k ben overgestapt van Java naar J# (tsjah, dat ging makkelijk

) en ben nu bezig met C#, dat veel overeenkomsten vertoond met java, echter dingen als attributes etc.. moet ik nog even bekijken

Al met al kon ik binnen 1 dag al een .net applicatie schrijven met windows forms evenals m'n eerste asp.net applicatie (een UBB stack tag parser

). Ging dus verrekte makkelijk

[ Voor 24% gewijzigd door prototype op 13-02-2005 11:51 ]

zondag 13 februari 2005 12:03

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

EfBe schreef op zaterdag 12 februari 2005 @ 10:45:
Met als kers op de rottende taart: Edit & Continue

Waarom is dat een slechte feature? Ik heb het hier overigens over het concept, de implementatie in VB.Net ken ik niet dus daar kan ik geen uitspraken over doen

. Ik vind edit&continue best handig tijdens sommige debug sessies. Goed, ik werk dan met C++, en je kunt er behoorlijk wat mee slopen tijdens een run (het werkt overigens ook niet altijd), maar het kan verdomd handig zijn om code tijdens run-time aan te passen zodat je niet opnieuw hoeft te compilen en het hele proces te doorlopen tot op het moment dat de bug optreedt. Want voor ons betekent dat soms een minuut of 10 door het level lopen voor je er eindelijk bent, en dat is een fucking waste of time

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

maandag 14 februari 2005 05:29

Acties:

Korben

() => {};

Weer on-topic: Ik denk, nee ik weet wel zeker, dat Microsoft .NET niet laat vallen. Het dringt steeds beter door tot developers, en veel (MS) devvers zijn er ook erg positief over, waaronder ikzelf.

Verder over de VB.NET vs. C# discussie; het is een feit dat Microsoft VB.NET nog steeds presenteert als een RAD-taal, en C# meer als een 'serieuze' taal. Kijk bij VB.NET (Whidbey) maar naar de VB-specifieke class-library, dan zie je daar toch de wat simpelere dingen die je in C# via een kleine omweg zou doen, in makkelijke classes (de Microsoft.VisualBasic.MyServices.FileSystemProxy class vs. de verschijdene System.IO classes bijvoorbeeld). Verder het (voor zover ik weet) ontbreken van unsafe en unchecked in VB.NET.

[ Voor 14% gewijzigd door Korben op 14-02-2005 05:32 ]

.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?

maandag 14 februari 2005 09:52

Acties:

maandag 14 februari 2005 10:50

.oisyn schreef op zondag 13 februari 2005 @ 12:03:
[...]

Waarom is dat een slechte feature? Ik heb het hier overigens over het concept, de implementatie in VB.Net ken ik niet dus daar kan ik geen uitspraken over doen . Ik vind edit&continue best handig tijdens sommige debug sessies. Goed, ik werk dan met C++, en je kunt er behoorlijk wat mee slopen tijdens een run (het werkt overigens ook niet altijd), maar het kan verdomd handig zijn om code tijdens run-time aan te passen zodat je niet opnieuw hoeft te compilen en het hele proces te doorlopen tot op het moment dat de bug optreedt. Want voor ons betekent dat soms een minuut of 10 door het level lopen voor je er eindelijk bent, en dat is een fucking waste of time

In dat geval kan ik het op zich nog wel begrijpen, alleen E&C zet aan tot ad-hoc development: eerst niet nadenken over algoritmen, die dan eerst testen, pre/post condities e.d., nakijken van code of je wel het algoritme hebt geimplementeerd dat je dacht dat je moest implementeren etc.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Mja, ik vind het een beetje kort door de bocht om te stellen dat E&C maar helemaal niet gebruikt mag worden omdat je code mogelijk niet op een goede manier tot stand komt. 't Is een kwestie van discipline, en ik zou niet graag zien dat een handige feature maar weg wordt gehaald omdat een stel idioten er niet goed mee om kunnen gaan

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 24 februari 2005 11:37

Acties:

donderdag 24 februari 2005 11:44

Gadgetfetisjist

EfBe schreef op zaterdag 12 februari 2005 @ 14:00:
Ik zeg niet dat er iets mis aan is, ik zeg alleen dat java op de desktop niet de java is waar we het over hebben. Java op de desktop is al jarenlang een flop en dat weet sun zelf ook.

En dat voorspelde ik 10 jaar geleden al toen Sun van de daken begon te schreeuwen dat alle programmeertalen overbodig waren geworden omdat over een paar jaar iedereen in het geweldige Java zou coden. Ik vond Java niks en ik vind het niks. Ik heb het hele traject afgelegd van BASIC op een Atari met 16KB, TP 3.0/4.0/TC 2.0/x86-assembly, TP6,BP,BC++, C++Builder/Delphi 1.0/2.0/4.0/6.0/2005 etc afgelegd en zie nogsteeds de meerwaarde van Java niet.

Sinds een tijdje ben ik me een beetje in .NET aan het verdiepen omdat ik uiteraard wel mee wil gaan met de tijd, maar tot op heden heb ik echt niet kunnen ontdekken wat er zo geweldig aan is. De mensen die het zo fantastisch vinden zijn mensen die weer met dezelfde argumenten komen als waarmee Java werd en wordt aangeprezen. Verder is het vooral dat .NET een sexy buzzword is waar de business bovenop duikt. Iedereen moet ineens .NET want .NET is goed.

Ik bekijk Java en .NET als programmeur en als gebruiker. Java is in mijn perceptie altijd bagger geweest voor de gebruiker. 10 jaar geleden was het al een ramp en retetraag, "maar dat zou allemaal anders worden want computers worden steeds sneller". Men hield er alleen geen rekening mee dat de grootte en complexiteit van Java software en de Java VM gewoon mee zou schalen met die van native gecompileerde code. Netto resultaat: het is nogsteeds baggertraag. Dus wat zijn we met Java opgeschoten?

Java is vooral vanuit de programmeur gezien een voordeel. Of dat zou het in ieder geval moeten zijn. De gebruiker heeft er alleen maar nadelen van, maar dat is natuurlijk vooral mijn eigen mening. Een ander argument voor Java zou zijn dat het bugvrijere software moet opleveren omdat programmeurs niet goed met pointers kunnen omgaan. Ik verfoei echter nogsteeds de voortschreidende abstrahering. Nog even en we kunnen alleen nog maar wat de virtual machine ons toestaat.

C# doet als taal voor mij aangenamer aan dan Java (ook dat is een kwestie van smaak). Maar wederom wordt de gebruiker opgezadeld met een loeigrote virtual machine en trager opstartende en werkende applicaties. En zijn die applicaties nou echt zoveel bugvrijer? Ik heb m'n twijfels... Ik programmeer nogstreeds erg graag in ANSI C, maar dat is vooral voor technisch georienteerde projecten (low-level networking, etc.). Daarna is C++ nogsteeds m'n favoriet en ik gebruik in Windows Delphi nog regelmatig om snel wat in elkaar te kloppen. Zou ook met C++ Builder kunnen maar omdat ik ooit in TP ben begonnen en altijd gecharmeerd van Delphi ben geweest, gebruik ik het nog graag.

Ik ben na heel veel lezen, en het bekijken van de mogelijkheden en veranderingen, nog GEEN argumenten tegengekomen die me overtuigen van het nut van .NET. Ik geloof er net zo min in als destijds (en nogsteeds) in Java.

Naar mijn mening schaalt de overhead van dit soort concepten mee met de complexiteit van software. Netto zal de gebruiker er dus niks op vooruit gaan. Tenzij de voordelen van C# echt betere software opleveren, maar dingen makkelijker maken veroorzaakt ook weer meer luiheid bij massa's programmeurs die alleen maar luier worden en geen betere code produceren.

Verder ben je overgeleverd aan de bugs in een OS, in bergen libraries, EN in de virtual machine. De abstrahering levert in de praktijk lang niet de kwaliteitsverbetering die beoogd werd en wordt.

Kan iemand me uitleggen waarom ik me niet langer moet verzetten tegen .NET?

"Logica brengt je van A naar B, verbeelding brengt je overal." - Albert Einstein

Acties:

donderdag 24 februari 2005 11:56

Gadgetfetisjist

Exirion schreef op donderdag 24 februari 2005 @ 11:37:
C# doet als taal voor mij aangenamer aan dan Java (ook dat is een kwestie van smaak). Maar wederom wordt de gebruiker opgezadeld met een loeigrote virtual machine en trager opstartende en werkende applicaties.

En ja, ik weet dat er aan JIT compilation wordt gedaan met caching van gecompileerde code. Resultaat: een oorspronkelijke bytecode executable en een cache met dezelfde code native gecompileerd. Ik zie vooralsnog alleen maar toenemende overhead zonder concrete voordelen.

"Logica brengt je van A naar B, verbeelding brengt je overal." - Albert Einstein

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Exirion schreef op donderdag 24 februari 2005 @ 11:37:
En dat voorspelde ik 10 jaar geleden al toen Sun van de daken begon te schreeuwen dat alle programmeertalen overbodig waren geworden omdat over een paar jaar iedereen in het geweldige Java zou coden.

Een dergelijke statement is sowieso onzin, ongeacht de taal waarover het gaat

Ik ben na heel veel lezen, en het bekijken van de mogelijkheden en veranderingen, nog GEEN argumenten tegengekomen die me overtuigen van het nut van .NET. Ik geloof er net zo min in als destijds (en nogsteeds) in Java.

Tsja, ik zie wel voordelen in .Net, ook al programmeer ik nog altijd C++ (duh, wie gaat er nou games maken in .net

), maar dan vooral op het windows platform en meer specifiek: het extenden van het windows platform en zijn applicaties. Voorheen had je COM, het systeem naar keuze als het ging om het maken van plugins en shell extensions, maar dat werkt nogal onhandig. In .Net is het een stuk beter geregeld, en talen kunnen op die manier prima met elkaar interacten.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 24 februari 2005 14:04

Acties:

mulder

ik spuug op het trottoir

Heb een beetje het idee dat mensen die zich 'verzetten' tegen .NET dezelfde mensen zijn die liever een vinyl LP luisteren dan een CD, geen mobiele telefoon willen en graag het wiel nog een keer uitvinden.

oogjes open, snaveltjes dicht

donderdag 24 februari 2005 14:37

Acties:

donderdag 24 februari 2005 16:49

Gadgetfetisjist

Don Facundo schreef op donderdag 24 februari 2005 @ 14:04:
Heb een beetje het idee dat mensen die zich 'verzetten' tegen .NET dezelfde mensen zijn die liever een vinyl LP luisteren dan een CD, geen mobiele telefoon willen en graag het wiel nog een keer uitvinden.

Dat zal bij veel van die mensen misschien het geval zijn. Zelf ben ik iemand die van vooruitgang houdt en openstaat voor nieuwe dingen, maar dan moeten er wel duidelijke voordelen zijn. Bij Java en .NET heb ik tot nu toe, zeker vanuit user perspective, vooral nadelen gezien. Dat is mijn hele punt.

"Logica brengt je van A naar B, verbeelding brengt je overal." - Albert Einstein

Acties:

donderdag 24 februari 2005 16:58

Exirion schreef op donderdag 24 februari 2005 @ 14:37:
Dat zal bij veel van die mensen misschien het geval zijn. Zelf ben ik iemand die van vooruitgang houdt en openstaat voor nieuwe dingen, maar dan moeten er wel duidelijke voordelen zijn. Bij Java en .NET heb ik tot nu toe, zeker vanuit user perspective, vooral nadelen gezien. Dat is mijn hele punt.

Gebruik je het toch niet? Niemand houd je tegen om gewoon het platform/taal te gebruiken die jij het prettigst vindt. Een gebruiker zal het worst zijn in wat voor taal het programma geschreven is, 9 van de 10 gebruikers weet niet eens wat een programmeertaal IS.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

farlane

Topicstarter

EfBe schreef op donderdag 24 februari 2005 @ 16:49:
[...]

Gebruik je het toch niet? Niemand houd je tegen om gewoon het platform/taal te gebruiken die jij het prettigst vindt. Een gebruiker zal het worst zijn in wat voor taal het programma geschreven is, 9 van de 10 gebruikers weet niet eens wat een programmeertaal IS.

Bij opdrachtgevers is dat vaak wel anders. Die hebben vaak wel eisen en wensen die met de taal/ het platform te maken hebben.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

donderdag 24 februari 2005 17:03

Acties:

OMX2000

By any means necessary...

farlane schreef op donderdag 24 februari 2005 @ 16:58:
[...]

Bij opdrachtgevers is dat vaak wel anders. Die hebben vaak wel eisen en wensen die met de taal/ het platform te maken hebben.

Een opdrachtgever gaat echt niet direct naar een taal kijken. Het gebruik van platform is afhankelijk van wat er al is (waarin al is geinvesteerd) of wat een opdrachtgever goedkoop kan kopen (korting van leverancier etc etc).

Of een bepaalde taal gekozen wordt kan afhankelijk zijn van de beschikbaarheid van resources. Dat is voor het .Net platform niet direct van belang. Als er voor .Net gekozen wordt zal de opdrachtgever het niet meer boeien in welke taal ontwikkeld wordt. Dit is iets wat door de techneuten zelf bepaald kan worden.

Dè developers podcast in je moerstaal : CodeKlets Podcast

donderdag 24 februari 2005 20:36

Acties:

Verwijderd

Wat farlane hier aantipt is echter wel de dagelijkse gang van zaken. Al weten de opdrachtgevers niet wat het doet, en wat het betekend, het dekt ze wel in. "Nobody ever got fired for using Microsoft" was het toch?

donderdag 24 februari 2005 21:40

Acties: