vb.net en c# worden beide naar hetzelfde gecompileerd... Alleen c++ wordt in whidbey 'beter' gecompileerd omdat er veel enhancements in de compilatie zitten. Overigens zou c++ niet in .Net thuis horen in mijn mening omdat het unmanaged code toe laat.Soultaker schreef op woensdag 09 februari 2005 @ 13:45:
[...]
Richard Grimes schrijft over alle technische details van het .NET platform en heeft in DDJ een serie over C++.NET in Whidbey geschreven. Hij is dus zeker weten wel een hard-core ontwikkelaar en niet een 'gewone' journalist zonder verstand van zaken. Hij weet dus zeker wel waar hij het over heeft.
Zijn kritiek wegzetten alsof het de ongefundeerde mening van een idioot zou zijn, lijkt me dan ook zeer onterecht. Het lijkt me dat je toch een betere (inhoudelijke!) verdediging zou moeten kunnen voeren, in plaats van de geloofwaardigheid van een opponent in twijfel te trekken (nogal een zwaktebod, naar mijn mening).
[...]
Dat klopt en dat is dus ook het bezwaar: de enige reden dat VB.NET bestaat is vanwege de marketingoverweging dat die naam bestaande VB programmeurs meer aanspreekt dan C#; een product van PHB's om andere PHB's tot aankoop aan te zetten.
Inhoudelijk (en daar gaat het de software engineer om) is C# op praktisch elk punt superieur aan VB.NET! Er wordt wel gezegd dat C# geschikt is voor 'complexere' applicaties en VB.NET voor 'simpele' toepassingen (omdat je geen threading of exceptions hebt bijvoorbeeld), maar als je kritisch kijkt is de conclusie dat voor 'simpele' toepassingen C# net zo goed geschikt is als VB.NET. Er is dus eigenlijk nooit een voordeel. (Of ik hierin gelijk heb is een discussie op zich, maar die discussie is al zo vaak gevoerd dat ik 'm eigenlijk niet wil herhalen.)
Vanwege een marketingbeslissing die geen relevant technisch voordeel biedt, zitten we nu opgescheept met (bijna) dubbel zo grote redistributables, dubbele support in application servers, IDE's, etcetera. Dat is allemaal zo ontzettend contra-productief.
:strip_exif()/u/11775/SoulTaker.gif?f=community)
Tja, dan kun je je webapplicaties ook wel in assembly language schrijven, want daar wordt het toch allemaal naar gecompileerd. 
Verwijderd
Daarom is het een column en geen verslag van een persconferentie waarin Steve Ballmer zegt: "Hey mensen, we zien .NET niet meer zitten hoor. Developers!"
Natuurlijk is het de auteur die dit veronderstelt. De vraag is, denk je dat de auteur gelijk heeft in zijn veronderstelling dat Microsoft .NET aan het opgeven is? (Klaarblijkelijk niet
)En ik merk dat ik mijn persoonlijke mening nog niet gegeven heb, dus bij deze:
Mir ist's egal.
Ik heb .NET als gebruiker zoveel mogelijk ontweken (vanwege de grootte van het framework, jawel, maar om dezelfde reden ontwijk ik Java). Van de andere kant, van mijn vrienden hoor ik dat programmeren in C# toch behoorlijk relaxt is, dus ik was wel van plan het eens te gaan proberen.
Maar ik ben niet meer zo enthousiast over Microsoft's 86.000 verschillende technologieën waar je hele systeem van vergeven raakt en die allemaal een berg dependencies (en niet te vergeten registerinstellingen) hebben waar je van gaat gillen. Hoe meer ik op de *NIX manier werk, hoe beter het me gaat bevallen, en hoe minder alles wat Microsoft uitpoept me kan schelen.
Dus als .NET er aan gaat zal het me worst wezen, en als het blijft bestaan en zwaar succesvol wordt (wat het wel verdient, imho), dan ook.
(Mijn excuses voor de aggressieve toon waarin dit stukje geschreven is)
/u/70465/crop55e568772a198_cropped.png?f=community)
* OZ-Gump aait OneOfBorg: maakt niet uit hoor
De (verhitte) discussie die hier woedt over de voor- en nadelen van VB.Net tegenover C# en vice versa zorgt ervoor dat de uiteindelijke vraag van dit topic verloren gaat:
Denken jullie, net als Richard Grimes, dat Microsoft het vertrouwen in .Net verliest?
Mijn redelijke korte antwoord daarop: nope
[ Voor 6% gewijzigd door OZ-Gump op 09-02-2005 14:59 ]
Verwijderd
.Net programma's kunnen zonder register werken. Zelfs support ervoor om dit keurig en netjes te doen. Wordt zelfs aangemoedigt.. Zelfs een best pattern en practice..:
[...]
Daarom is het een column en geen verslag van een persconferentie waarin Steve Ballmer zegt: "Hey mensen, we zien .NET niet meer zitten hoor. Developers!"
Natuurlijk is het de auteur die dit veronderstelt. De vraag is, denk je dat de auteur gelijk heeft in zijn veronderstelling dat Microsoft .NET aan het opgeven is? (Klaarblijkelijk niet
En ik merk dat ik mijn persoonlijke mening nog niet gegeven heb, dus bij deze:
Mir ist's egal.
Ik heb .NET als gebruiker zoveel mogelijk ontweken (vanwege de grootte van het framework, jawel, maar om dezelfde reden ontwijk ik Java). Van de andere kant, van mijn vrienden hoor ik dat programmeren in C# toch behoorlijk relaxt is, dus ik was wel van plan het eens te gaan proberen.
Maar ik ben niet meer zo enthousiast over Microsoft's 86.000 verschillende technologieën waar je hele systeem van vergeven raakt en die allemaal een berg dependencies (en niet te vergeten registerinstellingen) hebben waar je van gaat gillen. Hoe meer ik op de *NIX manier werk, hoe beter het me gaat bevallen, en hoe minder alles wat Microsoft uitpoept me kan schelen.
Dus als .NET er aan gaat zal het me worst wezen, en als het blijft bestaan en zwaar succesvol wordt (wat het wel verdient, imho), dan ook.
(Mijn excuses voor de aggressieve toon waarin dit stukje geschreven is)
en 86.000 microsoft technologieen... ja kom laten we niks innovatiefs meer doen! en bang zijn om dingen te doen die zouden kunnen mislukken... dat schiet lekker op
en alsof je als *nix gebruiker door de bomen het bos niet meer ziet..
Dan zal je vast blij zijn met de mogelijkheid voor IsolatedStorage in .NET om instellingen op te slaan ipv in het Register
Canon EOS 400D + 18-55mm F3.5-5.6 + 50mm F1.8 II + 24-105 F4L + 430EX Speedlite + Crumpler Pretty Boy Back Pack
:strip_icc():strip_exif()/u/29007/crop592572815b642.jpeg?f=community)
:strip_exif()/u/7759/red_cat.gif?f=community)
Leuk artikel: trapt alle open deuren in die de meeste mensen met een beetje gezond verstand al open hadden zien staan 
Vrijwel alles klopt wat ie zegt, maar om nou te zeggen dat het nieuw is, of schokkend zelfs, gaat wel erg ver
Vrijwel alles klopt wat ie zegt, maar om nou te zeggen dat het nieuw is, of schokkend zelfs, gaat wel erg ver
Verwijderd
EfBe,
Kun je je volgende opmerking uitleggen "HTML controls zijn icm javascript toch erg lame" ? Of ben jij voorstander van dat trage logge gebruiks- en bandbreedteonvriendelijke postback principe waardoor je elke keer die efficiente 120kb code (die dynamisch wordt aangemaakt) van de gemiddelde .NET control van bijv. infragistics binnentrekt?
Wat betreft de .NET strategie, het heeft gewoon zijn tijd nodig, Microsoft brengt makkelijker meer geld in het laatje dan andere technologiën, en kijkende naar bijv. Java, hoelang heeft de kristallisering en acceptatie daarvan niet geduurt, het heeft gewoon zijn tijd nodig.
Waar men wel op moet letten, is dat men in het geval van web ontwikkeling ook daadwerkelijk let op de web kant van het verhaal, en niet puur als software architect zijn doos met componenten opentrekt, deze een voor een op zijn canvas pleurt, de boel compiled, en "klaar" roept. Vind je het dan nog gek dat zaken traag reageren, en dat een web ui totaal niet meer reageert. Over het algemeen zijn .NET developers enorm lui, door onwetendheid.
Kun je je volgende opmerking uitleggen "HTML controls zijn icm javascript toch erg lame" ? Of ben jij voorstander van dat trage logge gebruiks- en bandbreedteonvriendelijke postback principe waardoor je elke keer die efficiente 120kb code (die dynamisch wordt aangemaakt) van de gemiddelde .NET control van bijv. infragistics binnentrekt?
Wat betreft de .NET strategie, het heeft gewoon zijn tijd nodig, Microsoft brengt makkelijker meer geld in het laatje dan andere technologiën, en kijkende naar bijv. Java, hoelang heeft de kristallisering en acceptatie daarvan niet geduurt, het heeft gewoon zijn tijd nodig.
Waar men wel op moet letten, is dat men in het geval van web ontwikkeling ook daadwerkelijk let op de web kant van het verhaal, en niet puur als software architect zijn doos met componenten opentrekt, deze een voor een op zijn canvas pleurt, de boel compiled, en "klaar" roept. Vind je het dan nog gek dat zaken traag reageren, en dat een web ui totaal niet meer reageert. Over het algemeen zijn .NET developers enorm lui, door onwetendheid.
[ Voor 112% gewijzigd door Verwijderd op 09-02-2005 15:33 ]
/u/3813/100_8985_ICON2.JPG?f=community)
Maar wat is jouw mening over / reactie op het statement wat hij maakt?:
Leuk artikel: trapt alle open deuren in die de meeste mensen met een beetje gezond verstand al open hadden zien staan
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.
Dat VB.NET een slap excuus is om VB6 ontwikkelaars niet te vervreemden is een feit. Dat het een incapabele taal is waar alle 'moeilijke dingen' zoals operator overloads e.d. express uitgelaten zijn is een feit. Dat C# een slap aftreksel was van Java in eerste instantie uit pure jaloezie omdat er een populaire technologie was die noch een open standaard noch van hun was kunnen we ook redelijk als feit bestempelen.
Verder gaat Avalon (of een vergelijkbare rich-GUI-technologie) op termijn vast ASP.NET overbodig maken, al zie ik dat niet gebeuren binnen nu en 5 jaar, vooral niet als ASP.NET 2.0 wel enigszins in staat blijkt standardscompliant HTML uit te poepen. Dat gaat Avalon overigens niet doen omdat ASP.NET ruk is, maar omdat HTML over HTTP gewoon ruk is voor applicaties omdat het een pull-only mechanisme is wat dodelijk is voor echt sterke applicaties, en daardoor zullen PHP en ASP(.NET) over een tijdje sowieso vanzelf afsterven, of het nu door Avalon of een andere 'innovatie' komt.
Een interessant punt waar de columnist overigens aan voorbij gaat is dat het me sterk lijkt dat mensen meer dan 5% van de Avalon applicaties in een andere taal dan VB.NET of C# gaan schrijven, in .NET dus. Ik zie wat dat betreft dan ook nog lang geen einde aan het dotNet-tijdperk
[ Voor 3% gewijzigd door curry684 op 09-02-2005 16:13 ]
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
Mja, ik lees toch echt dingen waarvan ik denk: een ontwikkelaar gaat echt dat soort dingen niet zeggen. En schrijven over iets hoeft niet te betekenen dat je een doorgewinterde ontwikkelaar bent.
Ik heb punten aangedragen hier, maar verder nog tijd verdoen aan dingen als de mening van deze meneer lijkt me toch wat zinloos. Hij heeft een mening, die slaat IMHO nergens op, hij krijgt er veel aandacht mee, leuk voor hem, en op dit forum praten we er over alsof het belangrijk is. Ik zou zeggen: mission accomplished voor de schrijver
Nee niet echt. VB.NET is meer op RAD gebaseerd en trekt andere ontwikkelaars aan dan C#. het heeft dus wel degelijk een plaats.
VB.NET .net 1.x heeft een paar features minder, maar bv de editor is echt beter dan de C# editor. Superieur op elk punt is dan ook erg overdreven want ze wijken niet zoveel af van elkaar.
huh? Geen threading en exceptions in vb.net? En dan ga jij mij vertellen dat jouw mening over een stukjesschrijver wel waar is en de mijne niet?
.Dubbele support in applicatie servers? Alles compileert naar IL, of was je dat even vergeten?
Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com
Ik zei toch 'behalve C++', dus m.a.w.: C++ NIET en alle andere talen WEL managed. Je hebt idd MC++, maar op dit moment (wat komt in volgende versies heb ik het niet over, het is altijd beter in een volgende versie) is MC++ niet zo bruikbaar IMHO. Je kunt 'behalve' ook lezen als "C++ en alle andere talen managed, dat bedoelde ik dus niet
(edit): met UITZONDERING van C++ had het moeten zijn.
Oh nee dat bedoelde ik niet:
Kun je je volgende opmerking uitleggen "HTML controls zijn icm javascript toch erg lame" ? Of ben jij voorstander van dat trage logge gebruiks- en bandbreedteonvriendelijke postback principe waardoor je elke keer die efficiente 120kb code (die dynamisch wordt aangemaakt) van de gemiddelde .NET control van bijv. infragistics binnentrekt?
Wat ik bedoelde was dat je met een thin layer web-applicaties zou moeten kunnen maken (en met XAML zou dat moeten kunnen) waarbij je een winforms look en feel kunt maken, dus als jij een radiobutton selecteert, dat dan bepaalde controls enabled/disabled worden, dat wanneer je een checkbox aanvinkt een combo box wordt gevuld etc. Nu in HTML een numeric textbox gebruiken met een mask is erg lastig.
[ Voor 41% gewijzigd door EfBe op 09-02-2005 16:27 ]
Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com
:strip_icc():strip_exif()/u/16071/underworld.jpg?f=community)
In oude VB, bedoelde ik. Vandaar dat het niet zo zinnig is om dat door te voeren naar het .NET platform, want dan zul je er echt aan moeten geloven, en dan kan je dus net zo goed C# leren.:
huh? Geen threading en exceptions in vb.net? En dan ga jij mij vertellen dat jouw mening over een stukjesschrijver wel waar is en de mijne niet?
Dus het feit dat er functionerende workarounds om een structurele tekortkoming zijn betekent dat het nu een volwaardig alternatief voor alles is?
Da's gewoon absolute bullshit, pull-only is gewoon een idiote tekortkoming die door toekomstige innovaties teruggedrukt gaat worden naar de wereld van websites, met nieuwe protocollen en technologieen voor webapplicaties.Was ik niet degene die net zei dat ik binnen 5 jaar geen aardverschuivingen in webland zie gebeuren?
Maar de toegankelijkheid is wederom gewoon bullshit: over 5 jaar zal FireFox v5.0 net zo functioneel zijn voor de webapplicaties nieuwe stijl als IE9. HTTP is een anachronisme uit de tijd van dialupverbindingen en datacenters die als geheel op 1Mbit zaten, en de technologische eisen van nu rennen hard voorbij de limitaties van dat protocol. Het is imho slechts een kwestie van tijd voordat er volwaardige realtime full-duplex vervangers voor HTTP komen.HTML is het probleem sowieso niet overigens, HTML druk je inderdaad niet zomaar weg. Maar HTML kun je over meer protocollen versturen dan alleen HTTP, net zoals email over 5 jaar imho niet meer over SMTP zal gaan
Welke van de 2 is het protocol?
Daarnaast zeg ik expliciet dat HTTP absoluut niet voldoet voor de vragen van de moderne webapplicatie, en dat HTML intussen een rijke standaard is die vrijwel alles kan wat het moet doen.
Heb jij wel eens geprobeerd een serverside event naar een browser client te pushen? Om maar een simpel voorbeeld te noemen: een chatapplicatie die je meldt dat er iemand tegen je aan wil lullen? Jij noemt hidden frames met Javascript-pollcode die acties uitvoert in andere frames geen "brakke ranzige workarounds"?
De wereld schreeuwt om serverside events in webapplicaties, maar omdat ze hopeloos brak zijn (HTTP1.1 mag maar 2 connecties naar dezelfde server maken tegelijkertijd, da's helemaal feestelijke tekortkoming) gebeurt er niets mee. The next step in de beurstickers die jij noemt is dat die webpage open staat en automatisch een window opgooit zodra de biedprijs onder drempel X is gezakt. Zie jij HTML over HTTP daartoe in staat zonder ranzigheden? En wedden dat 95% van de klanten van Binck en Alex dat morgen nog willen hebben als het realistisch zou kunnen?
Verwijderd
We beginnen pas, HTML is nog jong, de mogelijkheden zijn nog niet eens voor 10% benut. Als je nu al kijkt naar hoe lang het heeft mogen duren om op dit niveau te komen, kun je ervanuit gaan dat de ontwikkeling qua HTML zich nog geruime tijd doorzet, precies zoals werd voorspeld door analisten.
Hoe vaak denk je zelf dat het in de praktijk voorkomt dat je realtime events moet pushen, .. en nu, laten we er even vanuit gaan dat we inderdaad serverpush nodig hebben, dan bestaan daarvoor dedicated producten voor rich internet applications. Middelen als communication server, flash xml sockets, en de vele andere producten die zich op deze markt begeven.Heb jij wel eens geprobeerd een serverside event naar een browser client te pushen? Om maar een simpel voorbeeld te noemen: een chatapplicatie die je meldt dat er iemand tegen je aan wil lullen? Jij noemt hidden frames met Javascript-pollcode die acties uitvoert in andere frames geen "brakke ranzige workarounds"?
Dat je in de praktijk nog geen alternatieve oplossingen hebt gezien, tja, dat kan. Ze zijn er echter wel. Hidden frames met pollcode zijn vaak de codesamples die je op de blogs van software engineers tegenkomt. Het valt me persoonlijk vaak op dat ze hopeloos achterlopen, oude technieken gebruiken, deprecated methods, en quick n dirty vaak de voorkeur heeft.
Communicatie kan ook op andere manieren, maps.google.com is er een goed voorbeeld van.
En dan spreek ik uit eigen ervaring, zoals serverpush van 360c cameras, serverpush van microfoon activiteit. Het is allemaal mogelijk.
Jazeker, ... sterker nog, ik heb het al gedaan. Realtime veiligingen, beursinformatie en communicatiemiddelen. De wereld schreeuwt niet om die serverside events, de marketing machine van Microsoft doet dat voor je. Het is echter lastig om door al die lawaai ook nog de producten te zien die gespecializeerd zijn in serverpush voor het web, maar ze zijn er wel degelijk. Kijk bijvoorbeeld eens naar Macromedia Breeze, ... dit is realtime mass communication.
Dat HTTP1.1 maximaal 2 connecties mag openen heeft een reden, maar ik zie niet de beperking die dat in de praktijk zou moeten meebrengen, tenzij je blijft hameren op connecties die continue open moeten blijven staan.
Voorlopig zal er een scheiding blijven tussen windows applicaties, en web applicaties. Ze zijn ieder specifiek toe te passen, een P2P programma via het web is waardeloos, een CRM systeem via het web echter, is waardevol.
[ Voor 6% gewijzigd door Verwijderd op 09-02-2005 17:26 ]
Ik snap niet waarom je op dingen als Flash, Communication Server en Breeze zit te hameren en vervolgens niet in 1 adem door durft toe te geven dat HTTP zelf gewoon brak en outdated is dat je er externe meuk voor nodig hebt
Die stomme browser waar je nu tegenaan kijkt moet dat gewoon native doen, als native onderdeel van de standaard webprotocollen. Punt
Voor de rest is dit een beetje een pointless discussie: ik stel dat er uitbreidingen nodig zijn om bepaalde dingen voor mekaar te krijgen die nu te moeilijk, omwegen of externe programma's nodig hebben, en het enige wat je er tegen in brengt is dat mensen het nu niet willen en vooral niet moeten willen. Anders ben je like even conservatief of zo, en noem je mij een verstokte software engineer
Die stomme browser waar je nu tegenaan kijkt moet dat gewoon native doen, als native onderdeel van de standaard webprotocollen. Punt
Voor de rest is dit een beetje een pointless discussie: ik stel dat er uitbreidingen nodig zijn om bepaalde dingen voor mekaar te krijgen die nu te moeilijk, omwegen of externe programma's nodig hebben, en het enige wat je er tegen in brengt is dat mensen het nu niet willen en vooral niet moeten willen. Anders ben je like even conservatief of zo, en noem je mij een verstokte software engineer
[ Voor 36% gewijzigd door curry684 op 09-02-2005 17:34 ]
Voor de topicstarter: http://slashdot.org/artic...245&tid=201&tid=109&tid=1
Ik denk dat we wel klaar zijn
Ik denk dat we wel klaar zijn
Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com
Verwijderd
En als er al .NET zaken missen in Longhorn dan zal dat niet liggen aan een gebrek aan vertrouwen, maar aan een instortende product ontwikkeling structuur bij Microsoft en als resultaat daarvan het schrappen van functionaliteiten
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.
Verwijderd
Dat is een utopie, dezelfde gedachtengang is er ook met Java, maar in de praktijk zie je dit toch niet altijd werken.
Bovendien, Microsoft heeft het momenteel veel te druk met zichzelf voorbijlopen, dus ik zie het resultaat van een dergelijke visie nog niet zo snel verschijnen. Het schijnt tegenwoordig echt complete chaos te zijn op het gebied van productontwikkeling bij Microsoft als ik de employees moet geloven Men heeft de grootste moeite om milestones te halen oa door de strategie rondom security en patches, en het zit schijnbaar allemaal een beetje tegen
Bovendien, Microsoft heeft het momenteel veel te druk met zichzelf voorbijlopen, dus ik zie het resultaat van een dergelijke visie nog niet zo snel verschijnen. Het schijnt tegenwoordig echt complete chaos te zijn op het gebied van productontwikkeling bij Microsoft als ik de employees moet geloven
Men heeft de grootste moeite om milestones te halen oa door de strategie rondom security en patches, en het zit schijnbaar allemaal een beetje tegen
[ Voor 5% gewijzigd door Verwijderd op 10-02-2005 10:54 ]
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.
J# helemaal nieuw
Is J# dan niet de "opvolger" (kuch) van het het o zo geweldige Visual J++ dat op zich een poging van Microsoft was om iets JAVA-achtig te doen?
De bestaansreden van J# is mij geheel onduidelijk - zeker nu ze met C# al een halve JAVA kloon hebben ... J# is gewoon een poging om JAVA programmeurs naar .NET te halen, en voor de gemiddelde JAVA programmeur wordt het al vrij snel duidelijk dat je er geen ruk mee kunt uithalen omdat het ding zo ongeveer overeenkomt met Java 1.1, wat al meer dan antiek is, en omdat je wil je iets serieuzer doen je alsnog die C# zooi nodig hebt (maw dan kan je beter ineens C# leren)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Wat dacht je, dat Sun uitvinder was van deze concepten? Het idee is write/compile once, run anywhere, en dat kan niet zonder een sandbox omgeving die voor elk platform gegarandeerd hetzelfde is (de VM dus). En het concept garbage collection is al zo oud als de weg naar rome. Juist van deze dingen zeggen dat MS ze heeft afgekeken van Java vind ik onzin.
En Arnaud, je zegt steeds C maar bedoel je niet C++? Die twee talen zijn essentieel verschillend
[ Voor 11% gewijzigd door .oisyn op 11-02-2005 16:36 ]
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.
:strip_exif()/u/80759/monstermania_small.gif?f=community)
Gelukkig draaien ze de sole dependency op de Garbage Cultivator in 2.0 deels terug naar ik heb begrepen
Verwijderd
Sterker nog, Java is momenteel overall nog steeds sneller dan .NET Dat Java traag is komt nog uit haar begindagen.
Dat verandert uiteindelijk wel, immers .NET is nog piepjong
Dat Java traag is komt nog uit haar begindagen.Dat verandert uiteindelijk wel, immers .NET is nog piepjong
[ Voor 26% gewijzigd door Verwijderd op 11-02-2005 17:47 ]
Je kan veel dingen zeggen van vs.net, maar sloom is het zeker niet. Ga maar grote classes editen, kom je er wel achter dat de sloomheid wel meevalt (en voordat iemand de dooddoener opmerking van de week maakt: sommige form handling classes zijn ranzig groot door de vele controls en dus handling code. )
Kom maar op met die benchmarks.:
Sterker nog, Java is momenteel overall nog steeds sneller dan .NET
[ Voor 16% gewijzigd door EfBe op 11-02-2005 18:22 ]
Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com
Sun beheerder van een open standaard? Je refereert hier toch niet naar Java, of wel?
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.
Verwijderd
Performance Comparison of Java/.NET Runtimes (Oct 2004) Het is niet veel, maar het is er
http://www.shudo.net/jit/perf/
En uiteraard hebben we ook een test van Microsoft, maar ik krijg daar persoonlijk een nare smaak van als je die vergelijking gaat maken met een Tomcat, en dat ook maar even tussen de specificaties in weg vrot.
http://www.gotdotnet.com/team/compare/Benchmark_response.pdf
.NET gaat vanaf Longhorn wel een gigantische boost krijgen, aangezien .NET voor zover ik heb begrepen echt integraal onderdeel gaat uitmaken in het OS, in plaats van het zijn van een laag. Performance increases van 300% heb ik men horen zeggen, maar vooralsnog moeten we zulke grote cijfers nog even met een korreltje zout nemen totdat er testcases zijn
[ Voor 70% gewijzigd door Verwijderd op 11-02-2005 18:49 ]
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.
Verwijderd
Daarom zei ik ook overall Bovendien is performance niet een doorslaggevende factor voor een taal, er zijn zaken die velen malen belangrijker zijn waaronder ontwikkelsnelheid en die is bij .NET veel hoger.
Bovendien is performance niet een doorslaggevende factor voor een taal, er zijn zaken die velen malen belangrijker zijn waaronder ontwikkelsnelheid en die is bij .NET veel hoger.
Goh, wat een boel reacties ineens op een topic dat leek dood te bloeden!
whoami
. De reden dat er in .NET zoveel talen mogelijk zijn is omdat de meeste programmeurs een verleden hebben. In dat verleden zijn ze gewend geraakt om op een bepaalde manier te denken en te schrijven. Als jij 10 jaar ervaring hebt in VB (whitespace counts, capitals don't) dan is het makkelijker om over te schakelen naar VB.NET dan naar Java (of naar C#). Microsoft geeft je in dat geval de keuze om te programmeren in een taal die jou bevalt en SUN geeft je die keuze niet.
Wat ik eigenlijk probeerde te zeggen met dit punt is dat toen MS begon met de .NET-ontwikkeling (5 jaar of misschien nog wel langer geleden) ze de performance van Java als een zwak punt zagen en dat hun Framework daar bij introductie geen last van mocht hebben.
Ik blijf dan ook bij mijn conclusie dat .NET een geweldige toekomst tegemoet gaat.
whoami
Mee eens, daarom schrijf ik ook
Ik had dit soort reacties namelijk al verwacht. Op GOT is posten blijkbaar makkelijker dan lezen.
Zo werkt dus alle ontwikkeling: Evolutie, geen revolutie. De auto had niet uitgevonden kunnen worden zonder wiel, maar tussen wiel en auto zaten honderden tussenontwikkeling. Toch denk ik dat MS deze ideëen heeft overgenomen uit Java (net als Sun ze ooit over heeft genomen) omdat Java deze ideëen "aan de massa" heeft getoond. Beter goed gejat dan slecht bedacht tenslotte. (en ik bedoel inderdaad meestal C++ waar ik C schrijf)
Voor mij was overstappen naar .NET makkelijk omdat VB.NET dezelfde syntax heeft als VB6 en het was moeilijk omdat ik niet gewend was om OO te denken (de richting waar .NET je toch duidelijk naar toe duwt). Ben je overigens overgestapt van Delphi naar Delphi.NET of naar een andere taal?
Probeer maar eens een Fries te dwingen om alleen nog maar ABN te spreken
. De reden dat er in .NET zoveel talen mogelijk zijn is omdat de meeste programmeurs een verleden hebben. In dat verleden zijn ze gewend geraakt om op een bepaalde manier te denken en te schrijven. Als jij 10 jaar ervaring hebt in VB (whitespace counts, capitals don't) dan is het makkelijker om over te schakelen naar VB.NET dan naar Java (of naar C#). Microsoft geeft je in dat geval de keuze om te programmeren in een taal die jou bevalt en SUN geeft je die keuze niet.Dit komt (ook in andere posts) steeds weer naar voren. Dat SWING traag is geeft waarschijnlijk weinig discussie, maar misschien dat iemand een linkje kan plaatsen waar de snelheid van een (recente) Java-App en een (recente) .NET-App met elkaar vergeleken worden. Gevoelsmatig zeg ik dat bijvoorbeeld ASP.NET over het algemeen iets sneller is dan ASP, maar dat daar ook een grotere overhead voor nodig is. Gevoelsmatig zeg ik ook dat een .NET-App minder overhead heeft als een Java-App en dat de snelheid (GUI uitgezonderd) gelijk ligt.
Wat ik eigenlijk probeerde te zeggen met dit punt is dat toen MS begon met de .NET-ontwikkeling (5 jaar of misschien nog wel langer geleden) ze de performance van Java als een zwak punt zagen en dat hun Framework daar bij introductie geen last van mocht hebben.
Als je met IntelliJ of Eclipse ook .NET-applicaties kan schrijven zou je nog een punt kunnen hebben, maar aangezien ik .NET-ontwikkelaar ben lijkt me VS toch echt een betere IDE voor mij. Met een plug-in van 1 MB (waarschijnlijk standaard in VS2005) kan ik ook refactoren en van sloomheid heb ik nog nooit iets gemerkt. (staat in 5 seconden klaar op mijn 5 jaar oude laptop, alle menu's en shortcuts reageren altijd binnen 1 seconde)
Eigenlijk wel, maar als je goed leest zie je dat ik (semi) open standaard had staan. Je moet een (semi) open standaard natuurlijk niet gaan vergelijken met Open (Source) Software.
Nogal onduidelijke test. Windows en Linux lopen door elkaar heen en als er 1 ding duidelijk is dan is het wel het feit dat er van Java zoveel verschillende versies en varianten zijn dat over performance geen zinnig woord kan worden gesproken. Wel is duidelijk dat MS.NET duidelijk beter scoort dan Mono. De testen van MS en zeker de vage beloftes voor de toekomst vind ik verder niet de moeite van een discussie waard. Ik hoop dat iemand nog een betere benchmark-link weet.
Helemaal mee eens. Performance is 1, ontwikkelsnelheid is 2 en zo zijn er nog honderden technische redenen waar .NET aan moet voldoen (en waarvan ik geloof dat ze er al aan voldoen of dat in de toekomst zullen doen). Maar ook zaken praktische zaken als marketing, marktpenetratie, vertrouwen in de leverancier enz zijn bij MS (en dus bij .NET) gewoon in goede handen.
Ik blijf dan ook bij mijn conclusie dat .NET een geweldige toekomst tegemoet gaat.
Om de semi heb ik niet heen gelezen, maar Java is vrij gesloten itt .Net, vandaar
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.
Dat zit ook in de laatste versie van VS.NET (2005) -eindelijk-, maar ik had hier eerder iets gelezen over de 'prachtige IDE van MS'.
Wel, ik denk dan
Er zitten toch nog heel wat bugs in: Windows Form designers die plots over hun nek gaan, en die heel je form vernaggelen, etc...
De beste IDE waar ik tot nu toe mee gewerkt hebt, is en blijft die van Borland Delphi. Rock-stable.
[ Voor 10% gewijzigd door whoami op 11-02-2005 19:46 ]
https://fgheysels.github.io/
:
[...]
.NET gaat vanaf Longhorn wel een gigantische boost krijgen, aangezien .NET voor zover ik heb begrepen echt integraal onderdeel gaat uitmaken in het OS, in plaats van het zijn van een laag. Performance increases van 300% heb ik men horen zeggen, maar vooralsnog moeten we zulke grote cijfers nog even met een korreltje zout nemen totdat er testcases zijn
Dat snap ik niet.
.NET zal toch altijd een laag blijven.
https://fgheysels.github.io/
Eerst C# en vervolgens ook Delphi.NET (vanaf D7), als je bekend met de VCL heb je toch echt een voorsprong omdat er erg grote verschillen tussen de VCL en FCL. Verschillen zijn vooral eigenlijk naam verschillen zo is de event dispatch method in FCL OnClick en in VCL juist Click.
Jongske, zeg dan gewoon ook zo geen dingen die kant noch wal raken, of die helemaal nergens op slaan. Je moet die talen niet in hokjes plaatsen.
Ga je dan zeggen dat MS alles gepikt heeft van Java ?
De ideeën die al in Java zaten, bestonden gewoon al.
VB.NET en VB6 hebben slechts in beperkte mate eenzelfde syntax.
Dé leercurve in het overstappen van vb6 naar (vb).NET zit 'm dan ook in het concept. Geen sleur'n pleur programmatie meer, maar echt OO nadenken als je het goed wil doen.
Overstappen van Delphi naar .NET (of het nu naar C#, VB.NET of Delphi.NET is maakt niet uit, het is vooral de denkwijze en het framework dat je moet leren kennen, de syntax van een taal kennen is imo ondergeschikt), is imo zowiezo makkelijker omdat -zoals al eerder gezegd- het VCL framework van Delphi soms grote gelijkenissen vertoond met bepaalde onderdelen in het .NET framework.
Logisch ook; Anders Hjelsberg
Dat is gewoon een marketing-truc. Een goeie programmeur moet kunnen programmeren en denken, geen syntax vanbuiten kennen.Probeer maar eens een Fries te dwingen om alleen nog maar ABN te spreken
Heb je beschikking over inside information bij MS ofzo ? }:o
Is het niet zo dat C# veel opener is dan Java ?
https://fgheysels.github.io/
Verwijderd
Voor zover ik heb begrepen heeft het te maken met een closere integratie met Windows van de runtime, maar zolang er feitelijk nog niets naar buiten is gekomen blijft het bullshit bingo.:
[...]
Dat snap ik niet.
.NET zal toch altijd een laag blijven.
Die cijfers van 300% vond ik persoonlijk dan ook betwistbaar omdat je dan over de performance van C zou stuiven, met een managed environment. Getuned en geknutseld zal er zeker worden, maar of we echt zulke klappers krijgen... ik betwijfel het
[ Voor 26% gewijzigd door Verwijderd op 11-02-2005 20:02 ]
Verwijderd
Wat ik dus al eerder aangaf in deze thread, Microsoft begint uit de rails te lopen, met als resultaat problemen bij de ontwikkeling van producten en functionaliteit. Totdat het patch verhaal, en het security verhaal nog niet volledig is geintegreerd blijven ze problemen houden. Je kunt het zien alsof Microsoft momenteel een complete reorganisatie ondergaat
Desondanks de jaarcijfers zijn goed, dus het is bedrijfstechnisch gezien niet een issue.
Desondanks de jaarcijfers zijn goed, dus het is bedrijfstechnisch gezien niet een issue.
[ Voor 12% gewijzigd door Verwijderd op 11-02-2005 22:35 ]
Nou dat gaat prima hoor.Probeer maar eens een Fries te dwingen om alleen nog maar ABN te spreken
Het idee van een VM is al zou oud als de weg naar Rome, dus Sun is echt niet de ideeenbrenger geweest voor MS om .NET te maken.
Waar ik wel in mee wil gaan is dat MS het design van .NET, qua features, lijkt te hebben gespiegeld aan Java's design. Ik begrijp bv tot vandaag de dag nog steeds niet waarom .NET niet bij aanvang generics had. Dat wordt eind dit jaar pas geintroduceerd, met al die migratie ellende van dien.
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
Volgens mij doen ze in de mainframe wereld al jaren aan hardware abstractie, maar ik kan me vergissen...
Refactoring is aardig, maar refactoring is niet gratis: het kost tijd EN het geeft aan dat je originele design fout was (het had beter gekund). Agile development kan alleen bestaan als er refactoring is, en dat is logisch: men denkt niet echt na over wat er eventueel in de toekomst zou kunnen gebeuren misschien, alleen wat NU nodig is: dan kan het voorkomen dat je dingen moet verbouwen omdat je nieuwe functionaliteit moet toevoegen.
Normaal development houdt in zekere zin rekening met wat er eventueel kan gebeuren in de toekomst en refactoring komt dan ook veel minder voor.
Het is ook niet 'free', je bent er echt tijd aan kwijt, ongeacht de tools. Het probleem is verder dat even een method renamen of een stukje code tot method promoveren wel leuk is, maar veel refactor werk moet je echt met de hand doen. Voorbeeldje? Ik heb LLBLGen Pro vrij agile ontwikkelt, dwz: nu bouwen wat je nu nodig hebt en alleen subsystems algemeen definieren. Dit werkt heel goed, alleen nu moet ik dus een feature inbouwen waarbij ik veel moet verbouwen: entities moeten ook op views kunnen worden gemapped. Dus overal waar table objects worden gereferenced moet ik een nieuwe interface referencen. Geen refactor tool die dat voor me oplost. Is ook niet erg, maar alleen om aan te geven dat refactor functionaliteit in een IDE lang niet altijd alles oplost voor je. Dus daarop vertrouwen of naar verwijzen is leuk maar zegt mij althans niet zo bar veel.
Wat ik al eerder zei over journalisten, gaat ook hier weer op. Weer een die aandacht wil. MS heeft recent een mega winst laten zien. Dan ga je echt niet down the drain hoor. Bij MS weten ze allang dat Office zn langste tijd gehad heeft. De volgende cashcow is MKB automatisering met op maat toegesneden software.
Ieder OS heeft vertraging opgelopen, en dat is wellicht deels aan management te wijten maar ook aan ambities. Wat MS wel fout doet is het eindproduct teveel door marketing laten beinvloeden. Maar dat zul je wel altijd blijven houden. MS heeft alleen een probleem in de OS wereld: wat de gemiddelde mens nu heeft is 'good enough'. M.a.w.: een nieuwe OS kopen is niet zo noodzakelijk. dan moet je andere dingen zoeken waar je je brood mee kunt verdienen: server software, bedrijfsautomatisering en home-entertainment. 3 gebieden die eigenlijk nog compleet open liggen. De Xbox is dan ook een gouden zet.
[ Voor 96% gewijzigd door EfBe op 12-02-2005 11:06 ]
Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com
/u/44276/got_icon5.png?f=community)
Aan de inhoud van de bovenstaande tekst kunnen geen rechten worden ontleend, tenzij dit expliciet in dit bericht is verwoord.
:strip_exif()/u/31626/eend.gif?f=community)
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.
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.
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
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/
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 ]
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.
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).
Ik heb tot zover nog nooit problemen gehad.
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.
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.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 10% gewijzigd door Alarmnummer op 12-02-2005 11:39 ]
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).:
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,
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 ]
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
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 ]
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
Tja, het is mogelijk, maar zijn ze dan goed bezig ?:
[...]
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
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.
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/
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.
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.
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 .
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.:
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
Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com
:strip_exif()/u/28900/sharingan.gif?f=community)
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 ]
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:
Met als kers op de rottende taart: Edit & Continue
. 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.
/u/19474/avatar2015.png?f=community){kind=avatar}
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.:
[...]
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
Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com
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.
/u/2801/crop5ccb23f820755.png?f=community)
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
Een dergelijke statement is sowieso onzin, ongeacht de taal waarover het gaat
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.
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.
:strip_exif()/u/19853/Goku1.gif?f=community)
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?
Inderdaad, .NET is voor de bobo's weer zo'n buzzword als XML. Ze weten amper wat het is, maar het moet er wel in/bij/op zitten:
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?
"Logica brengt je van A naar B, verbeelding brengt je overal." - Albert Einstein