[ALG] Blijven bij C++ of overstappen naar C#?

[hneel]

therat10430 schreef op woensdag 17 oktober 2007 @ 00:21:
nadeeltje: .Net nodig (is normaal geen nadeel maar misschien wel voor oude apperatuur waar nog even een C++ programmatje op moet draaien)

Hmm, dit kan inderdaad nog wel een praktisch probleempje worden. We werken hier nog veel met oude win9x laptopjes, en de software moet daar wel (vlot) op draaien.

[Janoz]

therat10430 schreef op woensdag 17 oktober 2007 @ 00:21:
En tsja verder heb je het fijne Visual Studio (maarja ik weet niet of je "office' applicaties ontwikkeld, zoniet dan is dat wat minder waard, maar ook de intellisense e.d. van VS zijn erg fijn (een van mijn grootste anti-java argumenten, of nouja eigenlijk mijn enige is dat de ontwikkelprogramma's niet zo fijn zijn)

Grappig dat je dat zegt . Over het algemeen loopt Visual Studio behoorlijk achteraan mbt features. Het enige voordeel dat VS heeft is dat het out of the box goed integreerd met andere MS software (ISS, Office, SourceSafe en Sharepoint ed). Als dit je enige argument is zou ik als ik jou was maar niet naar Intellij gaan kijken aangezien je dan waarschijnlijk een nieuwe taal meot leren ... Maar goed, om dit maar niet teveel op te rakelen toch maar ff op de topicstart reageren.

De beste oplossing lijkt me inderdaad .oisyns voorstel. Schrijf als het ware een 'driver' in C++ die je vervolgens in elke .net taal kunt aanspreken.

[farlane]

therat10430 schreef op woensdag 17 oktober 2007 @ 00:21:
Verder is Oisyn' idee natuurlijk ook het overwegen waard, hoewel dat een beetje halve weg is. Zelf zou ik liever 'echt' voor iets kiezen ipv alles door elkaar heen.

Op die manier gebruik je de right tool voor de right job.

[flowerp]

farlane schreef op woensdag 17 oktober 2007 @ 13:02:
[...]
Op die manier gebruik je de right tool voor de right job.

.oisyn's idee is denk ik inderdaad een goed idee. Het is ook absoluut niet 'raar' ofzo en zelfs wel logisch. Veel systemen maken gebruik van een hardware driver die in b.v. C of zelfs assembly is geschreven, maar natuurlijk ga je niet de GUI in assembly schrijven en alleen de echte diehards maken hun GUI volledig in C (of het groepje fanatieke Linux aanhangers natuurlijk die in het "objects are evil" verhaal mee gaan, maar laten we die even buiten beschouwing houden)/

Ook in b.v. de web wereld zie je al rustig zo'n 9(!) talen door elkaar gebruikt worden: java voor de backend en business logic, SQL om met de DB te praten, reguliere expressies om patronen te matchen, taglibs en expression language om de GUI en de bindings naar je code
te definiëren, diverse XML dialecten voor de configuratie, her en der wat directe HTML voor dingen die je components niet lekker doen, natuurlijk bind je ook nog stukjes javascript voor client-side behaviours en, hoe kan ik het niet als eerste noemen, voor AJAX. Last but not least voorzien we onze components nog van een mooie styling via de taal CSS.

C++/CLI voor de lowend stuff en C# voor de GUI vind ik dan nog een hele magere diversiteit aan talen

[H!GHGuY]

therat10430 schreef op woensdag 17 oktober 2007 @ 00:21:
Threads zijn errrg makkelijk in C# (zelfs ik snap het )

Ik wou onlangs terug beginnen met C# en wou messaging based threading gebruiken.
Geen locking, maar function-calls waar nodig omzetten in messages die dan in de juiste thread afgehandeld worden. Met andere woorden: InvokeRequired en Invoke.

Ik vroeg me echt af waarom een high-level taal als C# dit nog niet in de library heeft.
De System.Windows.Forms heeft dit wel, maar daar ben ik niet veel mee voor een console app.

Bovendien ben ik flexibiliteit verloren door dit zelf te implementeren, hoewel ik met wat reflection-trucken deze kan terugwinnen, maar tegen welke kost?

Ik vind dit een groot gebrek. Natuurlijk hebben ze locks en threads en zijn ze gemakkelijk in gebruik; zonder higher-level concept zijn ze niet altijd even bruikbaar.

[Verwijderd]

voordeel C# lekker makkelijk
voordeel C++ je mag alles lekker zelf doen. Meer werk maar vooral als je beperkte resources hebt ga ik zeker voor c++ (en assembly als ik in een hardcore bui ben )
ik hou zoizo meer van c++. maar dat is ook omdat ik het gewend ben.

wat eerder werd gezegt kan ik het ok alleen maar mee eens zijn.. het is altijd goed meerdere talen te kennen en dan kan je afhankelijk van je project kiezen wat je wilt toepassen. dit doe ik zelf ook. laatst nog een prog in java (blegh;) ) geschreven omdat degene voor wie het was zelf enkel java kent en graag er zelf aan verder wil werken.

[roy-t]

Janoz schreef op woensdag 17 oktober 2007 @ 09:16:
[...]

Grappig dat je dat zegt . Over het algemeen loopt Visual Studio behoorlijk achteraan mbt features. Het enige voordeel dat VS heeft is dat het out of the box goed integreerd met andere MS software (ISS, Office, SourceSafe en Sharepoint ed). Als dit je enige argument is zou ik als ik jou was maar niet naar Intellij gaan kijken aangezien je dan waarschijnlijk een nieuwe taal meot leren ... Maar goed, om dit maar niet teveel op te rakelen toch maar ff op de topicstart reageren.

Misschien waar, maar VS werkt out of the box meteen goed, en je hoeft niet eerst een paar uur te zoeken naar fijne plugins om dezelfde functionaliteit te verkrijgen als VS.

Maar misschien is het voor de niet "Ik hobby een beetje aan"-hobbyist geen gedoe om eerst uren je Eclipse in te stellen (zeker voor een groot project is het het waard). En als je eenmaal de fijne tools kent dan gaat dit natuurlijk in 10min.

Ik vraag me wel af welke technieken eclipse bijvoorbeeld mee voorloopt op VS? Waarschijnlijk moet ik me ook eens in java gaan verdiepen (ivm studie switch )

[Bobco]

therat10430 schreef op woensdag 17 oktober 2007 @ 23:57:
[...]
Misschien waar, maar VS werkt out of the box meteen goed, en je hoeft niet eerst een paar uur te zoeken naar fijne plugins om dezelfde functionaliteit te verkrijgen als VS.

Maar misschien is het voor de niet "Ik hobby een beetje aan"-hobbyist geen gedoe om eerst uren je Eclipse in te stellen (zeker voor een groot project is het het waard). En als je eenmaal de fijne tools kent dan gaat dit natuurlijk in 10min.

Ik vraag me wel af welke technieken eclipse bijvoorbeeld mee voorloopt op VS? Waarschijnlijk moet ik me ook eens in java gaan verdiepen (ivm studie switch )

Volgens mij had Janoz het over IntelliJ IDEA en niet over Eclipse. Zelf ben ik ook een fervente IntelliJ gebruiker. IntelliJ zit vol met handigheidjes die het leven van een ontwikkelaar heel veel gemakkelijker maken.

Kijk er voor de lol maar eens naar en vergelijk de features met Eclipse en VS.Net. Je zult zien dat IntelliJ de meest rijpe IDE op de markt is, tenminste IMHO. Goed, je kunt er geen C# in kloppen, maar dat is maar een klein nadeel

Iets waar bijvoorbeeld IntelliJ veel verder mee is is automatische refactoring. Verder zijn er stapels handigheidjes: CTRL-O geeft een lijst van methodes die je zou kunnen overriden. Je selecteert degene die je wilt en IntelliJ zet de method signatures voor je neer. Body schrijven en klaar.

[farlane]

Bobco schreef op donderdag 18 oktober 2007 @ 14:53:
Iets waar bijvoorbeeld IntelliJ veel verder mee is is automatische refactoring. Verder zijn er stapels handigheidjes: CTRL-O geeft een lijst van methodes die je zou kunnen overriden. Je selecteert degene die je wilt en IntelliJ zet de method signatures voor je neer. Body schrijven en klaar.

Mwah dat doet VS 2005 ook, als ik override tik geeft ie me een lijst van te overiden functies die ik met tab kan invoegen.

[Janoz]

therat10430 schreef op woensdag 17 oktober 2007 @ 23:57:
[...]


Misschien waar, maar VS werkt out of the box meteen goed, en je hoeft niet eerst een paar uur te zoeken naar fijne plugins om dezelfde functionaliteit te verkrijgen als VS.

Maar misschien is het voor de niet "Ik hobby een beetje aan"-hobbyist geen gedoe om eerst uren je Eclipse in te stellen (zeker voor een groot project is het het waard). En als je eenmaal de fijne tools kent dan gaat dit natuurlijk in 10min.

Ik vraag me wel af welke technieken eclipse bijvoorbeeld mee voorloopt op VS? Waarschijnlijk moet ik me ook eens in java gaan verdiepen (ivm studie switch )

3 dingen:

1: Ik had het inderdaad niet over Eclipse. Eclipse heeft inderdaad als nadeel dat een beginner de plugins nog niet kent. Zou je echter in een ingerichte omgeving ingezet worden dan valt dit verschil alvast weg en kunnen beide platformen zich goed aan elkaar meten. Daarnaast worden er genoeg redelijk compleet uitgeruste eclips varianten geleverd door verschillende leveranciers.
2: De omgevingen waar ik met Eclipse gewerkt heb waren absoluut geen 'ik hobby een beetje aan' omgevingen. (Bedenk bijvoorbeeld dat de ontwikkel omgevingen van IBM en Oracle ook op Eclipse gebaseerd zijn)
3: De afgelopen reclame campagne omtrent VS heeft mij ernstig verbaasd. Bij al die 'nieuwe features' was ik met stomheid geslagen dat dat blijkbaar nog niet eens in VS zat. Kijk voor de gein eens naar de features van versie 7 van IntelliJ: http://www.jetbrains.com/idea/features/index.html . Let bijvoorbeeld eens op de refactor mogelijkheden (2e kolom bovenaan). Zelfs de refactoring mogelijkheden van versie 3 van IntelliJ (die ergens rond 2003 op de markt kwam w2as uitgebreider dan wat nu in VS zit.

[ Voor 3% gewijzigd door Janoz op 18-10-2007 15:10 ]

[/\/\|)]

Voor de volledigheid wijs ik even op het bestaan van Resharper (ook van JetBrains), de VS.net/C# tegenhanger van IntelliJ.

[roy-t]

@ Janoz en consorten.

Ik bedoelde met aanhobbyen zeg maar dat dat mijn manier van programmeren is en bedoelde dan de plugin structuur van Eclipse juist als voordeel voor "echt" programmeren.
(even zodat ik zeker weet dat we elkaar begrijpen)

Hmm ik heb die opties nog nooit gemist.. maarja tot 2jr terug was ik tevreden met visual studio 6 (97)

Ik zal zeker eens kijken naar IntelliJ want wie weet misschien moet ik voor school zo in java gaan werken. En het kan nooit kwaad je horizon te verbreden .

Maargoed sorry voor deze unintended topic kaping, ik heb iig weer wat geleerd. Al enig nieuws wat de TS overal van vind?

Edit:

Ho ho wacht is even, IntelliJ er bij betrekken is niet echt eerlijk, Visual Studio Express is gratis, Netbeans is gratis, Eclipse is gratis. maar IntelliJ kost voor de meest simpele licentie al €500,-

*dat wordt dus toch Eclipse+plugins over een tijdje :P*

[ Voor 17% gewijzigd door roy-t op 18-10-2007 17:39 ]

[flowerp]

therat10430 schreef op donderdag 18 oktober 2007 @ 17:27:
maarja tot 2jr terug was ik tevreden met visual studio 6 (97)

Studenten van bijvoorbeeld de Universiteit Leiden moeten het nog steeds doen met VS6, en zullen dat zo ongeveer de komende 10 jaar nog moeten doen (het pakket zal dan 20 jaar oud zijn!). Als dit bij andere CS opleidingen ook zo is dan worden er behoorlijk weinig mensen opgeleid met al die leuke truukjes en handigheidjes in Eclipse, IntelliJ en de nieuwere releases van VS.

[roy-t]

Nog steeds met VS6? Waarom zetten ze er niet Visual Studio Express op? Is gratis (ook voor educatie dacht ik) en imho en mijn ervaring al een stuk gebruiksvriendelijker en beter dan VS6 (wat opzich ook niet zo slecht was, maar een beetje ehm meer zelf doen, en geen refactoring behalve dan cltr+f )

[flowerp]

therat10430 schreef op donderdag 18 oktober 2007 @ 20:03:
Nog steeds met VS6? Waarom zetten ze er niet Visual Studio Express op?

Geen idee, gewoonte misschien, of het feit dat je op een universiteit toch niet echt hele lappen code ontwikkeld, maar voornamelijk kleine stukjes eigenlijk. Toch is het jammer voor hen die er mee moeten werken want VS6 ondersteunde ~70% van de C++ standaard ofzo.

beter dan VS6 (wat opzich ook niet zo slecht was, maar een beetje ehm meer zelf doen, en geen refactoring behalve dan cltr+f )

Ik heb jaren met VS6 gewerkt en nog een poosje met VS 2002 en heel kort met 2003 (die laatste zelf nog aangeschaft, maar vlak daarna bijna volledig op Java overgegaan).

1 ding wat ik miste in VS was de mogelijkheid om snel naar code te navigeren. In Eclipse druk ik op de ctrl key en alle methods en variablen worden hyperlinks als ik er met de muis overheen ga. Met 1 click zit ik de definitie of bij de declaratie.

1 ding wat overigens in Eclipse mist is dat de debugger aangeeft wat de return value was na een method call. Eclipse kan dit niet, en dat is soms heel erg lastig.

[Janoz]

@therat10430: Ik probeer je ook absoluut niet over te halen en wil al helemaal niet de java evangelist uithangen. Ik wilde alleen even rechtzetten dat, ondanks wat MS beweert, VS niet de meest vooruitstrevende IDE is, maar dat het eerder achterop loopt in vergelijking met de mogelijkheden in andere ontwikkel omgevingen.

[whoami]

Mag ik de mensen er eens op wijzen dat dit topic ondertussen 'verzand' is in een discussie die eigenlijk niet veel meer met de originele vraag te maken heeft ?

De oorspronkelijke vraag was: 'moet ik bij c++ blijven voor de dingen die ik wil doen, of kan ik dat ook met c#', en ondertussen zijn we bezig over IDE's ...

[ATS]

therat10430 schreef op woensdag 17 oktober 2007 @ 00:21:
Threads zijn errrg makkelijk in C# (zelfs ik snap het )

Serial poorten dacht ik ook (dunno gebruik ze nooit)

En tsja verder heb je het fijne Visual Studio (maarja ik weet niet of je "office' applicaties ontwikkeld, zoniet dan is dat wat minder waard, maar ook de intellisense e.d. van VS zijn erg fijn (een van mijn grootste anti-java argumenten, of nouja eigenlijk mijn enige is dat de ontwikkelprogramma's niet zo fijn zijn)

Maargoed ik geloof niet dat je Java uberhaupt overwoog.

Zelf heb ik geen kennis van C++, behalve dan dat het een vrij oude taal is. Dus ja, C# is hardstikke nieuw up-to date en fijn met threads (en zo te lezen ook met serial poorten)

nadeeltje: .Net nodig (is normaal geen nadeel maar misschien wel voor oude apperatuur waar nog even een C++ programmatje op moet draaien)

Verder is Oisyn' idee natuurlijk ook het overwegen waard, hoewel dat een beetje halve weg is. Zelf zou ik liever 'echt' voor iets kiezen ipv alles door elkaar heen.

Nu wil ik niet lullig doen, maar in feite voeg je helemaal niets toe met dit bericht. OK, threads zijn makkelijk, maar dat was al gezegd, en verder is alles uit de tweede hand.

* ATS is zich ervan bewust dat ook dit bericht niets aan de oorspronkelijke vraag toevoegt.

[ Voor 3% gewijzigd door ATS op 19-10-2007 17:04 ]

[phobosdeimos]

Ik zie geen enkele reden waarom je van C++ zou willen afwijken.
Het is nog steeds de industriestandaard voor serieuze software, het geeft je de vrijheid om te ontwikkelen op welke manier je maar wil (linux, mac, windows, makefiles, scons, vim, emacs, visual studio, eclipse, netbeans, kladblok, je doet maar).
C# is leuker voor de mensen die graag met het handje genomen worden, maar verder houdt de overstap enkel nadelen en beperkingen in (alsjeblief laat niemand nu met een opmerking over Mono afkomen).

[ Voor 34% gewijzigd door phobosdeimos op 23-10-2007 21:07 ]

[.oisyn]

phobosdeimos schreef op dinsdag 23 oktober 2007 @ 21:00:
C# is leuker voor de mensen die graag met het handje genomen worden

Oh kom op zeg, dit slaat werkelijk helemaal nergens op. Alsof softwaredevelopment in C# of Java niet serieus is. Waar baseer je dat in hemelsnaam op, op het feit dat je zelf je geheugen moet kunnen managen? Of dat je niet "op je vingers getikt" wil worden als je buiten een buffer schrijft?

Als C++ zealot vind ik C++ natuurlijk een hele mooie en fijne taal om in te ontwikkelen, maar het gaat helemaal nergens over om te zeggen dat C# een taal is voor mensen die bij het handje genomen willen worden.

En het heeft al helemaal niet enkel nadelen en beperkingen. Het .Net framework is erg uitgebreid en compleet, daar waar standaard C++ juist erg summier is (geen threading, geen xml support, geen regex, geen GUI, ...).

[ Voor 13% gewijzigd door .oisyn op 23-10-2007 21:12 ]

[MrBucket]

@phobosdeimos Wat een zeldzaam ongenuanceerde en ongefundeerde mening heb je daar neergepend zeg...

Maar goed. Vooropgesteld: ik, als vroegere C++ fan, kan je C# van harte aanraden Zeker met de komst van generics in .NET 2.0 (de C++ "templates") is het een erg fijne programmeertaal.

hneel schreef op dinsdag 16 oktober 2007 @ 13:48:
De seriele poort is cruciaal. Verder is er eigenlijk weinig directe hardware aansturing nodig. In het kort komt het er op neer dat ik moet kunnen communiceren met bestaande microcontroller systemen. Daar omheen kan dan allerlei extra functionaliteit worden gebouwd, maar dat zijn eigenlijk alleen standaard technieken. De standaard GUI dingen, af en toe een timertje, wat standaard file I/O, enz.

Dus als ik de seriele poort aan de praat kan krijgen zit ik in principe goed, denk ik.

Nu is het wel zo dat Mircosofts .NET platform met name geent is op enterprise applications. Dat uit zich in veel ondersteuning voor user-interface implementatie, database-support, web-applicaties, webservices, xml, etc. Het is niet bedacht met zaken als compact, low-level, en tijdskritisch operaties kunnen uitvoeren in het achterhoofd. Je zult .NET code met "aan zekerheid grenzende waarschijnlijkheid" niet kunnen compilen om op een microcontroller te draaien.

Maar microcontrollers aansturen vanuit .NET kan zonder meer. Misschien dat er al custom libraries in .NET voor bestaan, en anders is er nog geen man over boord. Dan kun je nl. gewoon de basic operaties die je nodig hebt om zo'n controller aan te sturen (ik vermoed het uitlezen van en schrijven naar hardware porten?) uitwerken in C++, en als je dit als DLL compiled kun je deze DLL gewoon vanuit .NET gebruiken om je applicatielogica en UI omheen te bouwen.

Ik zeg: doen!

[ Voor 3% gewijzigd door MrBucket op 23-10-2007 21:29 ]

[Verwijderd]

C# is leuker voor de mensen die graag met het handje genomen worden

Met alle respect, maar wat een onzinnige en denigrerende opmerking is dat!

offtopic:
Spuit 11... Niet eerst een half uurtje bellen en dan op submit drukken...

[ Voor 22% gewijzigd door Verwijderd op 23-10-2007 21:38 ]

[flowerp]

phobosdeimos schreef op dinsdag 23 oktober 2007 @ 21:00:
Ik zie geen enkele reden waarom je van C++ zou willen afwijken.
Het is nog steeds de industriestandaard voor serieuze software,
C# is leuker voor de mensen die graag met het handje genomen worden

De 'grap' is dat er een legioen mensen is die ongeveer hetzelfde zegt van C vs C++. Ik denk dat C# zeker een hele serieuze taal is en op sommige punten C++ overtreft. Dan heb ik het niet over de .NET library (die zeer uitgebreid is), maar puur over de taal zelf.

C++, Java, C# hebben misschien wel allemaal hun eigen marktsector (die ook dikwijls enigszins overlappen) , maar elk op zich zijn het dikwijls de tools van serieuze software developers.

Ik zou zeggen dat C++ ongeveer de high-performance games markt en de 'legacy' desktop software heeft (d.w.z. software waar op zich nog steeds nieuwe versies van komen, maar die al vrij lang bestaan en dus niet hergeschreven gaan worden in een andere taal). Java heeft een groot gedeelte van de serverside/web app markt , met name de serieuze kant ervan (systemen waar vliegvelden of banken op draaien) en de mobile (eenvoudige) games markt, terwijl C# met name domineert op het gebied van redelijk recent geschreven desktop software en ook qua serverside/web app sterk aanwezig is en zich ongeveer op dezelfde markt als Java richt.

Concreet voor deze thread pakt C++ dan ook nog een stukje van de low-level hardware control markt, hoewel voor de echte low-level stuff volgens mij C nog steeds overheerst.

[phobosdeimos]

C heeft an sich niet veel te maken met C++, behalve de overeenkomsten qua syntax, en de (gedeeltelijke) compatibiliteit waarbij je C broncode ook met een C++ compileren kan gaan compileren.
C wordt voornamelijk gebruikt voor programmeren op systeemniveau, terwijl C++ een taal is die vooral dient om applicaties in te schrijven.

[.oisyn]

Leuk verhaaltje. Ga je nog in op de inhoudelijke kritiek op je eerste reactie of laat je het hierbij?

[farlane]

flowerp schreef op woensdag 24 oktober 2007 @ 00:04:
Concreet voor deze thread pakt C++ dan ook nog een stukje van de low-level hardware control markt, hoewel voor de echte low-level stuff volgens mij C nog steeds overheerst.

Eigenlijk wordt voor embedded spul ( uP dan, niet het 'PDA embedded spul' daarvan zou ik het niet durven zeggen ) eigenlijk alleen C gebruikt, met heel af en toe een platform waarop ook C++ gebruikt kan worden. ( Er wordt vaker nog in asm *shudder* gepielt dan in C++ heb ik het idee )

[phobosdeimos]

.oisyn schreef op woensdag 24 oktober 2007 @ 01:24:
Leuk verhaaltje. Ga je nog in op de inhoudelijke kritiek op je eerste reactie of laat je het hierbij?

Liever hier bij laten. Ik gebruik zowiezo niets wat uit de Microsoft stal komt, en ik heb inderdaad een denigrerende positie ten opzichte van zaken zoals het .Net platform.
Maar uit ervaring weet ik dat je over zo'n dingen beter kan zwijgen, om geen flame wars te creeëren
In ieder geval: the best tool for the job.
Als het werkt voor jou in jouw situatie, dan zou ik het gewoon gebruiken, iedereen tevreden.

[whoami]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 11:35:
[...]


Liever hier bij laten. Ik gebruik zowiezo niets wat uit de Microsoft stal komt, en ik heb inderdaad een denigrerende positie ten opzichte van zaken zoals het .Net platform.

Hoe kan je een onderbouwde mening over iets hebben - of uberhaupt een mening over iets hebben, als je het niet gebruikt.
Ik zou zeggen, werk er eerst eens even mee, vooraleer je dingen gaat afbreken.

---

[Hydra]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 11:35:
Liever hier bij laten.

Ja, je zal er ook eens compleet uitgeluld worden

C++ wordt tegenwoordig in zowel back-end, server applicaties als ook webapplicaties compleet voorbijgestreefd door Java en C#. Er is ook VEEL meer vraag naar mensen met Java en C# ervaring, dan vraag naar C++-ers.

C++ is geweldig als het op snelheid aankomt, maar dat is het voornaamste voordeel. GUI applicaties en grote multi-tier systemen worden tegenwoordig fijn in talen gebouwd waar ontwikkelen gewoon twee keer zo snel in gaat.

[.oisyn]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 11:35:
Maar uit ervaring weet ik dat je over zo'n dingen beter kan zwijgen, om geen flame wars te creeëren

Klopt, flames -zoals je eerdere post nu blijkt te zijn- kun je beter achterwege laten. Onderbouwde meningen echter, hoe controversieel ook, worden gewoon op prijs gesteld (door mij iig, en ik zal ze zelf ook niet onder tafels of stoelen schuiven)

[ Voor 6% gewijzigd door .oisyn op 24-10-2007 12:28 ]

[phobosdeimos]

whoami schreef op woensdag 24 oktober 2007 @ 11:41:
[...]
Hoe kan je een onderbouwde mening over iets hebben - of uberhaupt een mening over iets hebben, als je het niet gebruikt.
Ik zou zeggen, werk er eerst eens even mee, vooraleer je dingen gaat afbreken.

---

Misschien ligt het ook aan je achtergrond, ik heb zowiezo een lage dunk van de microsoft ontwikkelmethode, en op menig universiteit worden wetenschappelijke projecten gewoonweg in C++ geschreven omdat dat de taal is die je de vrijheid en snelheid geeft om dergelijke zaken te realiseren.
Kies je voor C#, dan kies je voor vendor lock-in.
Ik snap dat er miljoenen zoniet miljarden mensen tevreden zijn in de Windows/Office gevangenis, maar ik hoor daar niet bij, dus blijf ik ook zo ver mogelijk weg van .Net.
Ik heb trouwens niets negatief gezegd over Java.
Sun doet ten minste moeite om Java open te maken/houden, en ik kan mijn Java software draaien op alle platformen zonder zorgen hoeven te maken of Sun volgend jaar plots een rechtzaak aan mijn neus hangt (cfr: microsoft die linux distro's bedreigt en aanklaagt, samenzwering met SCO en Novell, etcetera).

[Verwijderd]

Hydra schreef op woensdag 24 oktober 2007 @ 12:17:
C++ is geweldig als het op snelheid aankomt, maar dat is het voornaamste voordeel.

En ook dat is allang niet meer waar. Sterker nog, Vitual Machines zijn vaak en hebben de theoretische mogelijkheid om sneller te code uit te voeren dan statisch gecompileerde talen. Enkel waar direct hardware aangesproken kan worden heeft C++ nog altijd de overhand, hoewel bijvoorbeeld .Net dat gat behoorlijk dicht.

[phobosdeimos]

Ja, op theoretisch vlak zou het mogelijk moeten zijn, totdat je effectief een C++ en een .NET of Java implementatie naast elkaar benchmarkt, en dan zal je grote ogen trekken
Ook te lezen in deze leuke benchmark suite.
Daar zie je dat puur op CPU tijd Java6 een stuk of 2.6 keer trager is dan C, en C# met Mono pakweg 3.2 keer trager gemiddeld.
Als je daarbij ook nog het geheugenverbruik in rekening zou nemen dan komt het op respectievelijk 4.3 en 4.1 keer slechter uit.

[ Voor 52% gewijzigd door phobosdeimos op 24-10-2007 12:48 ]

[RayNbow]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 12:30:
en op menig universiteit worden wetenschappelijke projecten gewoonweg in C++ geschreven omdat dat de taal is die je de vrijheid en snelheid geeft om dergelijke zaken te realiseren.

Gewoonweg? Volgens mij worden wetenschappelijke projecten geschreven in een taal die past bij de eisen van het project. Het wetenschappelijke project Tribler maakt bijv. gebruik van Python vanwege reeds bestaande code.

Kies je voor C#, dan kies je voor vendor lock-in.

.NET is gewoon een standaard.

phobosdeimos schreef op woensdag 24 oktober 2007 @ 12:39:
Ja, op theoretisch vlak zou het mogelijk moeten zijn, totdat je effectief een C++ en een .NET of Java implementatie naast elkaar benchmarkt, en dan zal je grote ogen trekken

Benchmarks... jaaaa.... Ga dan voor de functionele taal van de universiteit Nijmegen genaamd Clean. [Benchmark]

[Janoz]

Tja, dat je van alles roept over dingen terwijl je er eigenlijk geen ervaring in of onderbouwing voor hebt was ons eerder ook al duidelijk geworden ....

[google=benchmark java c++ .net]

[phobosdeimos]

Janoz schreef op woensdag 24 oktober 2007 @ 12:50:
Tja, dat je van alles roept over dingen terwijl je er eigenlijk geen ervaring in of onderbouwing voor hebt was ons eerder ook al duidelijk geworden ....

[google=benchmark java c++ .net]

Aha dus mijn benchmarks van het Debian language shootout project dat noem je "geen onderbouwing", maar jouw google zoekopdracht is wel een degelijke onderbouwing?

[Janoz]

Toen ik mijn bericht begon te tikken stond er nog geen onderbouwing bij. Tijdens het tikken heb ik meerdere benchmarks doorgelezen om te kijken wat er in stond om te zien wat de uitkomsten waren.

[phobosdeimos]

Wel in ieder geval, daarom kun je beter over dergelijke zaken niet beginnen, want het resulteert toch in een welles-nietes spelletje. Ik haal benchmarks boven in het voordeel van C, dan haalt iemand anders er boven waar bewezen wordt dat Java stukken sneller is dan C++. Windows vs Linux, Vim vs Emacs, Java vs C#: eindeloze discussies die meestal eindigen in oeverloos gezwam
Ik gebruik geen microsoft technologie (meer), ik heb daar mijn redenen en overtuigingen voor, en zoals mij zijn er steeds meer mensen te vinden.

[RayNbow]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 12:52:
[...]
Aha dus mijn benchmarks van het Debian language shootout project dat noem je "geen onderbouwing", maar jouw google zoekopdracht is wel een degelijke onderbouwing?

Benchmarks zeggen ook geen fuck. Benchmarks zijn namelijk erg te beinvloeden.

Om m'n punt duidelijker te maken:
[q=http://www.gamedev.net/community/forums/viewreply.asp?ID=2754633]
Original post by Emmanuel Deloget:
I remember a test done by a C++ guru and a C# guru. The whole point was to play with the STL and the corresponding part of the CLR. In the end, the C++ guru won (its code was running in 60 ms, while the managed code was running in 100 ms IIRC). Of course, this is a rather big improvement. Hovewer, this improvement has to be minimized since:

• it took 6 iterations to the C++ guru to be able to beat the first C# version of the program
• the C++ guru had to play with his own allocator implementation and had to be really clever about how to organize and micro-optimize his code in order to just run at twice the speed of the C# version.
• So far, it tells us a big story: C# is not that slow, and can beat C++ if you don't have time to waste on a large scale micro-optimization process (which is usually the case in most development teams, even game development teams: money is not auto-generating itself in order to match the wasted develoment time).

quote: http://www.gamedev.net/co.../viewreply.asp?ID=2754869

Original post by Promit:
So here's the thing. The C# version in tht race ran equally fast at the end of everything. Emmanuel neglected to mention that the times cited include executable start up and shutdown time -- that is, the time was taken immediately before the process started and immediately after the process terminated. .NET binaries take longer to start up and shutdown, for a number of (mostly obvious) reasons -- by the time Main was executed for the C# version, 60ms had already passed. The actual algorithm running time for the two was basically identical, but the C++ version took several times more work and a metric asston of extra code to match the C# one.

In other words, C# won that race, and won it easily. And frankly, I'm willing to bet I can write faster games in C# than most people here can do in C++.

Meer achtergrondinformatie is te lezen in deze blogpost van de C# progger in kwestie. Het is ook interessant te lezen dat de new operator een van de trage punten was in de C++ implementatie is.

Nou ja, memory allocation kan gewoon traag zijn in een unmanaged taal:

quote: http://www-128.ibm.com/de...=dgr-jw22JavaUrbanLegends

Pop quiz: Which language boasts faster raw allocation performance, the Java language, or C/C++? The answer may surprise you -- allocation in modern JVMs is far faster than the best performing malloc implementations. The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions (data provided by Sun; see Resources), whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call (Detlefs, et. al.; see Resources).

[.oisyn]

Om overigens het hele game verhaal te ontkrachten, ik moet de eerste compiler nog zien die scalar math omzet naar vector math door gebruik te maken van SIMD instructies van het onderliggende platform. Tot die tijd kun je in de meeste C++ implementaties gewoon gebruik maken van SIMD intrinsics (alsmede als intrinsics voor memory fences, data prefetches, etc.), dus met een goed geïmplementeerde vector en matrix lib schrijf je zonder moeite al fantastisch geoptimaliseerde code.

Memory allocation is idd een issue, en de standaard C++ allocator is natuurlijk opgezet als general purpose allocator, daar waar JIT compiled talen een allocator kunnen kiezen op basis van het gebruik van bepaalde objects in bepaalde contexts. Maar elke fatsoenlijke game heeft een tal van custom geïmplementeerde allocators in zich (fixed block heaps, transient heaps, stack based heaps, ...), dus dat is meestal een non-issue. C++ is en blijft de ideale taal voor games.

That said, games en simulaties vallen onder de uitzonderingen, en benchmarks van bepaalde algoritmes zeggen natuurlijk helemaal geen fuck over dagelijkse softwaredevelopment.

[EfBe]

Rico Mariani is de performance engineer voor het C# team, dus geen wonder dat hij er snelle code uit perst. Ik denk niet dat een random C# developer net zulke snelle code zal afleveren.

[RayNbow]

IMO wordt C++ door gamebedrijven gebruikt vanwege de code base die ze al hebben en hun ervaring met C++. Tevens moeten deze bedrijven vaak het uiterste uit het target platform halen en dan is het idd lonend om veel controle te hebben zoals in C++.

Ik zou echter niet zeggen dat C++ de ideale taal is voor gamedev in het algemeen. Voor de AAA titels is de taal zeker geschikt, maar voor bijv. een hobbyist is een taal als C# net zo geschikt. Zo'n hobbyist hoeft namelijk niet het onderste uit de kan te halen.

Deze post is natuurlijk overbodig als je met games sowieso de AAA titels bedoelde.


Edit:

EfBe schreef op woensdag 24 oktober 2007 @ 13:46:
Rico Mariani is de performance engineer voor het C# team, dus geen wonder dat hij er snelle code uit perst. Ik denk niet dat een random C# developer net zulke snelle code zal afleveren.

Maar de eerste implementatie ziet er niet bijzonder uit. Dit kan denk ik elke C# devver wel maken.

[ Voor 29% gewijzigd door RayNbow op 24-10-2007 13:52 ]

[.oisyn]

Als ik het over games heb, dan heb ik het over echte games in mijn vakgebied, en niet over hobbyisten-crap, jamba-troep, photoplay-ruk of mijnenveger (ja, AAA titels dus ). Het staat buiten kijf dat de kleinere spelletjes (mobiel, webgames, etc) ook prima in andere talen geschreven kunnen (of moeten) worden

[ Voor 32% gewijzigd door .oisyn op 24-10-2007 13:57 ]

[Hydra]

.oisyn schreef op woensdag 24 oktober 2007 @ 13:21:
That said, games en simulaties vallen onder de uitzonderingen, en benchmarks van bepaalde algoritmes zeggen natuurlijk helemaal geen fuck over dagelijkse softwaredevelopment.

Executiesnelheid is belangrijk in games, maar niet bijzonder relevant in de meeste server systemen. Een 2e server kopen en hosten is vaak een stuk goedkoper dan de extra kosten die een C++ i.p.v. een Java implementatie met zich meebrengen.

[EfBe]

Hydra schreef op woensdag 24 oktober 2007 @ 14:26:
[...]
Executiesnelheid is belangrijk in games, maar niet bijzonder relevant in de meeste server systemen. Een 2e server kopen en hosten is vaak een stuk goedkoper dan de extra kosten die een C++ i.p.v. een Java implementatie met zich meebrengen.

Waar is dat op gebaseerd? Je onderbuik? Server performance is erg belangrijk, ook bij VM gebruikende talen en je kunt wel roepen dat 'een paar servers extra de kosten niet zijn' t.o.v. C++ gebruik, maar zonder wetenschappelijke analyse is er geen zinnig woord over te zeggen. Immers: meer servers betekent ellende mbt state, load balancing etc.

[phobosdeimos]

EfBe schreef op woensdag 24 oktober 2007 @ 17:02:
[...]

Waar is dat op gebaseerd? Je onderbuik? Server performance is erg belangrijk, ook bij VM gebruikende talen en je kunt wel roepen dat 'een paar servers extra de kosten niet zijn' t.o.v. C++ gebruik, maar zonder wetenschappelijke analyse is er geen zinnig woord over te zeggen. Immers: meer servers betekent ellende mbt state, load balancing etc.

Als ik Azureus (bekende Java bittorrent client) op heb staan, gebruik die ergens tussen de 200 en 600 megabyte ram geheugen (van een totaal van 1gb), afhankelijk van de situatie.
Als ik Transmission aan heb staan (C++ GTK bittorrent client) gebruikt die 12 megabyte voor dezelfde functionaliteit.
Wetenschappelijk? Nee.

[Hydra]

EfBe schreef op woensdag 24 oktober 2007 @ 17:02:
Waar is dat op gebaseerd? Je onderbuik?

Ervaring. Natuurlijk chargeerde ik nogal, het is OOK belangrijk, maar die 10%/90% regel geldt daar ook. Als je 10% snelheidswinst haalt met 90% van de inspanning, is het het vaak gewoon niet waard. Dat geldt ook voor server software.

En wat betreft 'problemen' kwa state: daar heb je sowieso rekening mee te houden. Als je schaalbaarheid wil moet je d'r niet vanuit gaan dat je er mee wegkomt met een net iets nieuwere snellere server in je rack te schuiven ter vervanging van de oude.

phobosdeimos schreef op woensdag 24 oktober 2007 @ 17:30:
Als ik Azureus (bekende Java bittorrent client) op heb staan, gebruik die ergens tussen de 200 en 600 megabyte ram geheugen (van een totaal van 1gb), afhankelijk van de situatie.
Als ik Transmission aan heb staan (C++ GTK bittorrent client) gebruikt die 12 megabyte voor dezelfde functionaliteit.
Wetenschappelijk? Nee.

Je gebruikt Azureus dus voor porno met dikke vrouwen? Busted!

[ Voor 28% gewijzigd door Hydra op 24-10-2007 17:34 ]

[phobosdeimos]

Hydra schreef op woensdag 24 oktober 2007 @ 17:32:

Je gebruikt Azureus dus voor porno met dikke vrouwen? Busted!

[.oisyn]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 17:30:

Als ik Azureus (bekende Java bittorrent client) op heb staan, gebruik die ergens tussen de 200 en 600 megabyte ram geheugen (van een totaal van 1gb), afhankelijk van de situatie.
Als ik Transmission aan heb staan (C++ GTK bittorrent client) gebruikt die 12 megabyte voor dezelfde functionaliteit.
Wetenschappelijk? Nee.

utorrent.exe gebruikt bij mij 4mb. Ergo, C++ is blijkbaar 3x zo goed als C++.

[phobosdeimos]

.oisyn schreef op woensdag 24 oktober 2007 @ 17:50:
[...]

utorrent.exe gebruikt bij mij 4mb. Ergo, C++ is blijkbaar 3x zo goed als C++.

Als je zoals Hydra wil over gaan op onzinnige opmerkingen, doet het dan eventueel in PM naar elkaar?

[RayNbow]

Laten we niet ingaan op het geheugengebruik dat bijv. Task Manager weergeeft. Ik kan Task Manager laten geloven dat bijv. MSN Messenger 7.5 maar 1 MB geheugen in gebruik neemt...

Nog een relevante blogpost over perceived memory usage:
Xiaobin Lu's Blog: Perception == Reality

[Hydra]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 17:53:
Als je zoals Hydra wil over gaan op onzinnige opmerkingen, doet het dan eventueel in PM naar elkaar?

Hey, jij begint er onzinnige dingen aan de haren bij te slepen, niet ik...

[.oisyn]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 17:53:

Als je zoals Hydra wil over gaan op onzinnige opmerkingen, doet het dan eventueel in PM naar elkaar?

Blijkbaar zie je de onzinnigheid in je eigen opmerking niet, en dat probeerde ik aan te tonen met een vergelijkbare opmerking waarin je de onzinnigheid wel ziet. Je vergelijkt een willekeurige applicatie met een willekeurige andere applicatie die ogenschijnlijk dezelfde features bieden, maar waarbij de ene dat overduidelijk efficienter doet dan de andere, en je denkt vervolgens dat dat te ontlenen valt aan het feit dat de ene in Java is geschreven en de andere in C++, terwijl daar geen enkel causaal verband tussen hoeft te bestaan. Vergelijkbaar voorbeeld van wat jij zegt: het broeikaseffect is in de afgelopen jaren toegenomen. Zo ook het aantal piraten. Blijkbaar waren piraten een tegenpool voor het broeikaseffect.

Een andere mogelijke verklaring is dat de makers van Azareus prutsers zijn, terwijl de programmeurs van Transmission veel tijd hebben gespendeerd aan het optimaliseren van hun applicatie.

[ Voor 21% gewijzigd door .oisyn op 24-10-2007 18:26 ]

[phobosdeimos]

Dus oisyn als zelfverklaarde informaticus-expert heeft nog niet opgemerkt dat een willekeurige Java-desktop of server applicatie steevast een veelvoud van het geheugen gebruikt dan een functioneel equivalente C++ implementatie?
Nee RayNBow ik kijk niet naar Task Manager want ik gebruik geen windows.

[.oisyn]

Ik geloof niet dat ik verklaard heb informaticus-expert te zijn, ik geef enkel aan dat een willekeurig programma A tegenover willekeurig programma B nog geen bewijs vormt voor jouw stelling. En je hoeft geen informaticus-expert te zijn om dat in te zien. Ik zeg dus niet dat je ongelijk hebt (want blijkbaar lijk jij zoiets af te leiden uit mijn woorden), ik zeg dat je argumentatie niet klopt.

[ Voor 21% gewijzigd door .oisyn op 24-10-2007 18:28 ]

[phobosdeimos]

Het was het eerste praktijkvoorbeeld dat ik tevoorschijn kon toveren, maar een vergelijking met andere Java/C++ desktop applicaties zal gelijkaardige feiten laten zien.

[ Voor 5% gewijzigd door phobosdeimos op 24-10-2007 18:39 ]

[RayNbow]

---

Kijk eens... Azureus is best een efficient programma. Het gebruikt minder dan 4 MB!

Bij het maken van deze screenshot...
[list]
• draaide Azureus met 1 actieve, seedende torrent en 56 stopped torrents.
• is geen Photoshop oid gebruikt om het geheugengebruik aan te passen.


Toch heb ik Task Manager doen laten geloven dat Azureus maar 4 MB gebruikt.

[phobosdeimos]

Raynbow, who cares?
Ik gebruik geen Windows.
Het enige wat je nu aantoont is dat je task manager van windows kan misleiden om een verkeerde hoeveelheid geheugen te rapporteren.

[RayNbow]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 18:55:
Raynbow, who cares?
Ik gebruik geen Windows.
Het enige wat je nu aantoont is dat je task manager van windows kan misleiden om een verkeerde hoeveelheid geheugen te rapporteren.

Wat gebruik je dan? Linux? Heb je de eerdere link die ik gepost heb gelezen? Volgens mij niet...

"Perceived" footprint is the number reported by the operating system (by tools such as "ps" and "top" on Unix/Linux, and "Task Manager" on Windows) that a process takes up in RAM. In reality, the size a process takes up in memory consists of executable code, global data, stack and heap etc. However, to the end-user running one of these process-viewing tools, the size of a process is much different since sometimes these tools include some memory that is not actually allocated in RAM at all.

[MrBucket]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 18:55:
Raynbow, who cares?
Ik gebruik geen Windows.
Het enige wat je nu aantoont is dat je task manager van windows kan misleiden om een verkeerde hoeveelheid geheugen te rapporteren.

We care.

En uitspraken als
• "Ik gebruik geen microsoft technologie (meer), ik heb daar mijn redenen en overtuigingen voor, en zoals mij zijn er steeds meer mensen te vinden.",
• "...oisyn als zelfverklaarde informaticus-expert...",
• "C# is leuker voor de mensen die graag met het handje genomen worden, maar verder houdt de overstap enkel nadelen en beperkingen in (alsjeblief laat niemand nu met een opmerking over Mono afkomen)."
• "Raynbow, who cares? Ik gebruik geen Windows."
geven niet echt blijk van enige sociale vaardigheden of kennis van zaken. Imo vervuil je gewoon het topic met offtopic en slecht onderbouwd geblaat.

[.oisyn]

RayNbow schreef op woensdag 24 oktober 2007 @ 18:46:
[afbeelding]

---

Kijk eens... Azureus is best een efficient programma. Het gebruikt minder dan 4 MB!

Bij het maken van deze screenshot...
[list]
• draaide Azureus met 1 actieve, seedende torrent en 56 stopped torrents.
• is geen Photoshop oid gebruikt om het geheugengebruik aan te passen.


Toch heb ik Task Manager doen laten geloven dat Azureus maar 4 MB gebruikt.

Wat niet wegneemt dat Azureus idd een draak van een programma is (die CPU tijd in je screenshot is ook een mooie indicator daarvan), maar dat ligt geheel aan Azureus en geenszins aan Java .

Verder sluit ik me aan bij MrBucket. Ik heb niet de illusie dat die plaat voor phobosdeimos' hoofd met valide argumenten weg te praten is, dus ik steek er verder ook geen moeite meer in.

.edit @ hieronder: beetje jammer dat die kennis dan gevangen zit achter die plaat zodat het zich niet kan ontplooien . Ook blijf je weer erg zwart-wit bezig. Niemand beweert hier dat .Net en Java volledige vervangers zijn van C++. Dat is een uitspraak die alleen leeft in jouw hoofd.

[ Voor 24% gewijzigd door .oisyn op 24-10-2007 19:21 ]

[phobosdeimos]

Ok laten we besluiten dat .Net en Java prachtige omgevingen zijn, die C en C++ volledig kunnen vervangen, en uiterst zuinig omspringen met CPU tijd en beschikbaar RAM geheugen.
Eerder zullen jullie toch niet tevreden zijn.
MrBucket: over mijn kennis van zaken zou ik zeker niet twijfelen, dan ga je bedrogen uitkomen.

[RayNbow]

.oisyn schreef op woensdag 24 oktober 2007 @ 19:14:
[...]

Wat niet wegneemt dat Azureus idd een draak van een programma is (die CPU tijd in je screenshot is ook een mooie indicator daarvan), maar dat ligt geheel aan Azureus en geenszins aan Java

Het CPU gebruik is hoog vanwege 't trucje dat ik gebruik om Taskman te misleiden . Vlak voor en na 't trucje gebruikt Azureus maar 0-2% CPU.

[Cloud]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 19:17:
Ok laten we besluiten dat .Net en Java prachtige omgevingen zijn, die C en C++ volledig kunnen vervangen, ...

Wat is er gebeurd met "the right tool for the job"?

Niemand loopt hier te beweren dat er één (of twee) omgeving is die alle andere kan vervangen, dat is bullshit. Er is geen beste. Er is alleen de beste meest geschikte, voor een bepaalde situatie.

[Brent]

MrBucket schreef op woensdag 24 oktober 2007 @ 19:03:
En uitspraken als
• "Ik gebruik geen microsoft technologie (meer), ik heb daar mijn redenen en overtuigingen voor, en zoals mij zijn er steeds meer mensen te vinden.",
• "...oisyn als zelfverklaarde informaticus-expert...",
• "C# is leuker voor de mensen die graag met het handje genomen worden, maar verder houdt de overstap enkel nadelen en beperkingen in (alsjeblief laat niemand nu met een opmerking over Mono afkomen)."
• "Raynbow, who cares? Ik gebruik geen Windows."
geven niet echt blijk van enige sociale vaardigheden of kennis van zaken. Imo vervuil je gewoon het topic met offtopic en slecht onderbouwd geblaat.

Even afgezien van opmerking drie, brengt hij weldegelijk een punt van C#/.net onder de aandacht, waar inderdaad niet inhoudelijk op ingegaan wordt, en dat is de (in bepaalde mate) platformgebondenheid. Of dat een probleem is voor de TS weet ik niet, maar kan een showstopper zijn.

RayNbow schreef op woensdag 24 oktober 2007 @ 19:18:
[...]

Het CPU gebruik is hoog vanwege 't trucje dat ik gebruik om Taskman te misleiden . Vlak voor en na 't trucje gebruikt Azureus maar 0-2% CPU.

Zo lust ik er nog een paar Bovendien vergeet je volgens mij java.exe mee te nemen.

[MrBucket]

Brent schreef op woensdag 24 oktober 2007 @ 19:41:
[...]

Even afgezien van opmerking drie, brengt hij weldegelijk een punt van C#/.net onder de aandacht, waar inderdaad niet inhoudelijk op ingegaan wordt, en dat is de (in bepaalde mate) platformgebondenheid. Of dat een probleem is voor de TS weet ik niet, maar kan een showstopper zijn.

Nja. In theorie is C++ platform-onafhankelijk en zou je je programma zonder al te veel problemen moeten kunnen porten om (bijv.) onder linux te draaien. Maar dat is de theorie; in praktijk zul je echt veel moeite moeten doen om je applicatie zo te programmeren dat het ook op Linux te gebruiken valt. En zeker wanneer je met zaken als user interfaces (of andere dingen waarvoor je het OS aan moet spreken) aan de gang gaat.

Bovendien, wanneer was de laatste keer dat jij besloot dat je applicatie opeens op een ander OS moest kunnen draaien?

@TS: _{waar issie heen, trouwens - die zal het gekibbel wel zat zijn geworden...}
Don't take our word for it, probeer het anders gewoon zelf uit. Visual C# Express is een lichtgewicht Visual Studio variant die gratis te downloaden is, en er zijn genoeg C# tutorials te vinden.

Kijk maar eens of het je wat lijkt

[H!GHGuY]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 19:17:
MrBucket: over mijn kennis van zaken zou ik zeker niet twijfelen, dan ga je bedrogen uitkomen.

Net jouw overschatting van jezelf zorgt dat _jij_ bedrogen uitkomt.

Dat de memory footprint van een Java/C# app groter is dan die van een C++ app... sure!
Dat hyperoptimized C++ sneller is dan hyperoptimized C#... sure!
Dat C# voor veel applicaties een fractie van de code nodig heeft van een C++ app... sure!
Dat de .NET omgeving het beste MS product is... my opinion!
Dat een heel groot deel van de informatica markt bestaat uit Java/C# development... sure!
Dat jij jezelf voor aap zet met je hoge-toren geblaat... sure!

Dat je veel weet mag best zijn, zo'n attittude kunnen we hier missen.

Ik heb overlaatst een eenvoudig system tray tooltje in elkaar geflanst om windows te arrangen zoals ik het wil met multi-monitor support en what else. Resultaat: een executable van enkele K groot, een minimale hoeveelheid code, geen last van performantie (niet dat dit een issue zou (kunnen) zijn) en wat nog.

Bovendien kun je nu blaten dat mijn app mss 10MB geheugen in beslag neemt door het .NET platform, maar dan is mijn eenvoudige reactie dezelfde als die van jouw: who cares.
- Het zijn SHARED libraries, nog een .NET app in het geheugen maakt het extra verbruik minimaal.
- Als het geheugen niet gebruikt wordt, dan swapt mijn OS het wel uit. De working set is quasi niets dus eenmaal uitgeswapt heb ik nog steeds geen performance penalty.

Ikzelf "ken" beide talen en het zijn beide mijn favorieten voor development in managed omgeving en development in unmanaged omgeving, linux, ... (Ik zie C# gewoon als (managed ((c)++)++))

Het is zelfs puur als niet-taalkennis een zeer interessante taal aangezien bepaalde problemen anders aangepakt worden dan in C++. Het zorgt dus zeker voor een rijkere kennis in programmeren algemeen. Ook naar later kan het zeker een plus zijn als je C# kent.

Algemene tip:
Google een paar dagen intensief op alles wat C# en .NET is en kijk of het je bevalt en of jouw programma past in de taal. (niet omgekeerd) Kies je alsnog voor C++ dan kan het wel mooi zijn om in je vrije tijd eens een C#-tooltje in elkaar te boksen.

[RayNbow]

Brent schreef op woensdag 24 oktober 2007 @ 19:41:
[...]

Zo lust ik er nog een paar Bovendien vergeet je volgens mij java.exe mee te nemen.

Al sinds een aantal versies van Azureus wordt er slechts 1 proces gestart, genaamd Azureus.exe, onder Windows. Vroeger had je idd een aparte launcher (Azureus.exe) en de werkelijke applicatie (javaw.exe), maar nu is het dus 1 proces (Azureus.exe).

Om iets van m'n trucje te onthullen, het CPU gebruik van Azureus steeg omdat ik 't venster minimaliseerde.

[FTL]

C# en Java ontwikkelen gewoon erg snel. Minimale inspanning met maximaal resultaat. Het wordt steeds meer declaratief (WAT je wil, niet per definitie HOE).

Bijkomend voordeel is dat de managed talen ook veel veiliger zijn out of the box. Type safety, checked indexes, sandboxen, garbage collection (niet expliciet destructen) e.d.

Ikzelf heb de laatste tijd met Netbeans, Eclipse en VS2005 gewerkt, ik moet met MS nageven: VS wint qua ontwikkel snelheid. Ja lees goed, ik heb het hier over de IDE, niet over de taal! Geen uitgesproken voorkeur voor Java of C#.

En jah: de standaard plumbing code wordt dan gegenereerd. Daar is niets mis mee: als je maar weet wat en hoe hij het doet. Wil je echt l33t zijn: er is mogelijkheid voor in deze talen en IDE's.

Ze zullen misschien wel wat trager zijn met bepaalde dingen of meer geheugen gebruiken maar ze hebben voordelen die vele malen belangrijker zijn: ontwikkel-snelheid en veiligheid.

In gemiddelde situaties zal het een gebruiker worst zijn of hij 4 of 5 ms moet wachten op resultaat. De server kant kan simpel en goedkoop de capaciteit uitgebreid worden mocht je toch die 20% extra snelheid willen. De kosten van hardware uitbreidingen zijn nog altijd goedkoper dan de uren van ontwikkelaars.

In praktisch elke applicatie zal de snelheid van managed talen meer dan voldoende zijn. Functionaliteit en ontwikkel snelheid zullen belangrijker zijn.
Programma's die als functionele eis: maximale snelheid hoe dan ook zullen misschien native talen moeten kiezen.

Alle ontwikkel tools die je nodig bent voor .net (of java for that matter) zijn gratis aanwezig en hebben zelfs open-source varianten, geen echte reden om bang te zijn voor vendor-lockin. de CLI is gewoon een standaard.

Vergis je niet, ben niet tegen c++ e.d., maar weet de dingen te relativeren.
Naar mijn idee heb je met C++ wat meer 'controle' en mischien snelheid, met als nadeel dat het ontwikkelen trager zal zijn.

Persoonlijk geeft ik dus vaak de voorkeur aan Visual Studio als IDE en .NET als framework (voelt meer native windows aan qua GUI) en C# als taal, toch C(++) achtige syntax.

[edit] Er zijn natuurlijk altijd situaties te bedenken dat sommige bovenstaande stellingen niet opgaan, het zal altijd per situatie bekeken moeten worden wat het slimst is om te gebruiken.

[ Voor 4% gewijzigd door FTL op 25-10-2007 08:05 ]

[whoami]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 19:17:

MrBucket: over mijn kennis van zaken zou ik zeker niet twijfelen, dan ga je bedrogen uitkomen.

Kijk, ik kan natuurlijk ook over mezelf verklaren dat ik veel kennis heb op een bepaald vakgebied, maar daarmee is het nog altijd niet bewezen.

Daarnaast is het jammer dat dit topic helemaal verziekt is door mensen die met on-onderbouwde meningen komen.
Daarom: probeer eens niet op de man te spelen, kom met onderbouwde meningen ipv de knuppel in het hoenderhok te gooien met boude statements, anders zie ik me genoodzakt om dit topic te sluiten

[ Voor 16% gewijzigd door whoami op 24-10-2007 21:27 ]

[.Gertjan.]

Programmeertaal is toch slechts een gereedschap? (zo zie ik het in ieder geval) In principe is het handig om meerdere talen te kunnen gebruiken. Zelf ben ik op school "groot gebracht" met Java en een stuk C++. Toen vond ik C++ een stuk krachtiger, maar tegelijk ook moeilijker.

Na mijn opleiding ben ik me (vanwege het bedrijf waar ik ging werken) gaan specialiseren in .NET 1.1 en later 2.0 (C#) en dat is me eingelijk best goed bevallen. Ook ik was zoals sommige anderen een beetje terughoudend betreft .NET, omdat ik het eerst als een JAVA achtige clone zag en de platform onafhankelijkheid niet echt terug zag.

Maar toen ik er eenmaal mee werkte wilde ik eigenlijk niet meer terug. Toen had ik al een vermoeden dat het misschien toch erg populair kon worden en het nuttig zou zijn om me in .NET te specialiseren. En het lijkt inmiddels toch vrij populair (zie ook projecten als MONO en de hoeveelheid gevraagde .NET ontwikkelaars).

Binnenkort moet ik me "omscholen" naar VB.NET. Bij omscholen hoef je in principe alleen de syntax en een stuk van de standaard libraries kennen (libraries zijn nu niet van toepassing). Maar zelfs als je een hele tijd in .NET werkt weet je nog niet alle functionaliteiten binnen het framework. En het fijne is dat je meerdere talen kan gebruiken binnen .NET.

Ik geloof dat er ook boeken/online tutorials zijn die C++ ontwikkelaars helpen bij hun overstap naar .NET. Misschien nuttig om eens naar te kijken.

[farlane]

FTL schreef op woensdag 24 oktober 2007 @ 20:39:
In gemiddelde situaties zal het een gebruiker worst zijn of hij 4 of 5 seconden moet wachten op resultaat.

Die gemiddelde situatie is alleen van toepassing op jouw situatie want die toepassingen die ik maak wil de gebruiker ( of dat nou een mens of machine is ) echt niet zolang wachten.

Ik geloof dat er ook boeken/online tutorials zijn die C++ ontwikkelaars helpen bij hun overstap naar .NET

Waarom nou overstap? Kunnen we het niet gewoon erbij doen?

[FTL]

farlane schreef op woensdag 24 oktober 2007 @ 23:30:

Die gemiddelde situatie is alleen van toepassing op jouw situatie want die toepassingen die ik maak wil de gebruiker ( of dat nou een mens of machine is ) echt niet zolang wachten.

Ik bedoel het verschil in tijd natuurlijk, lees anders 4ms (C++) of 5ms (C#).
Dacht dat dat wel duidelijk was, toch maar ff uitgelegd.

[.Gertjan.]

farlane schreef op woensdag 24 oktober 2007 @ 23:30:
[...]


Die gemiddelde situatie is alleen van toepassing op jouw situatie want die toepassingen die ik maak wil de gebruiker ( of dat nou een mens of machine is ) echt niet zolang wachten.


[...]

Waarom nou overstap? Kunnen we het niet gewoon erbij doen?

good point

Met overstappen bedoel ik eigenlijk dat je geholpen wordt om aan de hand van je C++ kennis C# te leren... Na de "overstap" ben je (hopelijk) niet alle C++ kennis kwijt.

[riezebosch]

FTL schreef op woensdag 24 oktober 2007 @ 20:39:
[...]
Ze zullen misschien wel wat trager zijn met bepaalde dingen of meer geheugen gebruiken maar ze hebben voordelen die vele malen belangrijker zijn: ontwikkel-snelheid en veiligheid.
[...]

Vergeet niet de onderhoudbaarheid

.Gertjan. schreef op woensdag 24 oktober 2007 @ 21:40:
[...]
Ik geloof dat er ook boeken/online tutorials zijn die C++ ontwikkelaars helpen bij hun overstap naar .NET. Misschien nuttig om eens naar te kijken.

Zelf vond ik dit wel een goeie uitleg: Appendix D: C# for C++ Developers.
Let wel: het is een appendix van Professional C# 3rd edition (2004).

[EfBe]

Hydra schreef op woensdag 24 oktober 2007 @ 17:32:
[...]
Ervaring. Natuurlijk chargeerde ik nogal, het is OOK belangrijk, maar die 10%/90% regel geldt daar ook. Als je 10% snelheidswinst haalt met 90% van de inspanning, is het het vaak gewoon niet waard. Dat geldt ook voor server software.

Ervaring? Wat voor ervaring? Dit soort dingen moet je niet baseren op nattevingerwerk van de koude grond, maar harde feiten. Een toets van n=1 (jij) is volstrekt irrelevant. Met wat 'handwaving' wat opmerkingen plaatsen dat het wel zo zal zijn gebaseerd op eigen ervaring is niet toereikend om toegepast te worden in een andere situatie, plus wie zegt dat de situaties waar jij mee te maken hebt gehad beter af zijn in een VM gebruikende taal?

Dom voorbeeld horen? Ik maakte een aantal jaren geleden voor onze webapps (we praten over 1998-2002) de COM components vaak in VB6, omdat dat makkelijk was: geen gezeik met memory, veel code is native compiled (de runtime lib) etc.

Voor de gein heb ik een deel van die dingen toen eens in C++ herschreven. De code was qua grootte bijna gelijk. Door de smart pointer generation mbt COM components (ADO is com based en echt niet zo brak als de .NET marketeers je willen doen geloven) is het nauwelijks meer werk.

Veel meer tijd moeten investeren? Nee niet echt. Echter liep die code wel een klap harder dan die vb com components.

[EfBe]

Brent schreef op woensdag 24 oktober 2007 @ 19:41:
[...]

Even afgezien van opmerking drie, brengt hij weldegelijk een punt van C#/.net onder de aandacht, waar inderdaad niet inhoudelijk op ingegaan wordt, en dat is de (in bepaalde mate) platformgebondenheid. Of dat een probleem is voor de TS weet ik niet, maar kan een showstopper zijn.

Waarom moet er ingegaan worden op een BS argument? C# is een standaard, iedereen kan een implementatie maken (zie bv Mono).

Platformgebondenheid is sowieso altijd aanwezig. Of wil je beweren dat bij Java je geen gebondenheid hebt aan je applicatieserver of bij C++ niet aan de gebruikte libs? De illusie dat een random programma met veel functionaliteit overal compileerbaar is is precies dat: een illusie.

[Hydra]

Brent schreef op woensdag 24 oktober 2007 @ 19:41:
Even afgezien van opmerking drie, brengt hij weldegelijk een punt van C#/.net onder de aandacht, waar inderdaad niet inhoudelijk op ingegaan wordt, en dat is de (in bepaalde mate) platformgebondenheid. Of dat een probleem is voor de TS weet ik niet, maar kan een showstopper zijn.

Als je kiest voor Java OF C# is het sowieso makkelijk genoeg over te stappen later. C# heeft als 'nadeel' dan dat als je overstapt naar Java opeens een aantal dingen (delegates, properties) moet missen. Even wennen maar daar kom je wel doorheen.

Het is wat anders als je gaat webdevven want Asp.net is compleet anders dan JSP, en dan is ASP.Net 2 WEER compleet anders dan Asp.net (1).

whoami schreef op woensdag 24 oktober 2007 @ 21:26:
Daarom: probeer eens niet op de man te spelen, kom met onderbouwde meningen ipv de knuppel in het hoenderhok te gooien met boude statements, anders zie ik me genoodzakt om dit topic te sluiten

Sorry dat ik misschien een metadiscussie start hiermee, maar ik vind dit een beetje een vreemde manier van modden. Alle participanten 'straffen' omdat een gozer de arrogante lul uit zit te hangen.

EfBe schreef op donderdag 25 oktober 2007 @ 10:04:
Ervaring? Wat voor ervaring? Dit soort dingen moet je niet baseren op nattevingerwerk van de koude grond, maar harde feiten. Een toets van n=1 (jij) is volstrekt irrelevant. Met wat 'handwaving' wat opmerkingen plaatsen dat het wel zo zal zijn gebaseerd op eigen ervaring is niet toereikend om toegepast te worden in een andere situatie, plus wie zegt dat de situaties waar jij mee te maken hebt gehad beter af zijn in een VM gebruikende taal?

Nouja, als je tegenwoordig een project doet waarbij webservices of webapplicaties opgeleverd moeten worden, hoef je sowieso niet aan te komen met C++ lijkt me? Dat is mijn 'ervaring', dat de default basis .Net of Java is. Waarom is dat? Onderhoudbaarheid en ontwikkelsnelheid. Dat de executietijd marginaal langer is, is voor de opdrachtgever niet relevant.

Ik zeg niet dat Java / .Net ALTIJD de beste tool for the jo zijn, heck, in een project een tijdje terug is nog iemand (gelukkig niet ik) in COBOL bezig geweest, maar het meeste nieuwe spul code je daar niet in

Dom voorbeeld horen? Ik maakte een aantal jaren geleden voor onze webapps (we praten over 1998-2002) de COM components vaak in VB6, omdat dat makkelijk was: geen gezeik met memory, veel code is native compiled (de runtime lib) etc.

Voor de gein heb ik een deel van die dingen toen eens in C++ herschreven. De code was qua grootte bijna gelijk. Door de smart pointer generation mbt COM components (ADO is com based en echt niet zo brak als de .NET marketeers je willen doen geloven) is het nauwelijks meer werk.

Veel meer tijd moeten investeren? Nee niet echt. Echter liep die code wel een klap harder dan die vb com components.

Ik begrijp niet helemaal wat je hiermee wil bereiken, maar ik zie niet hoe de snelheid van een VB COM component hier relevant is. 'Vroegah' was ik ook fijn in VBS binnen ASP bezig, maar dat vind ik niet relevant in deze discussie.

Daarnaast is iets 'herschrijven' kwa tijdsinvesteringsvergelijking niet helemaal eerlijk. Als ik een Java app van mij herschrijf in Java, is java opeens ook 2x zo snel als java kwa devven?

[.Gertjan.]

Hydra schreef op donderdag 25 oktober 2007 @ 11:52:
[...]
Als je kiest voor Java OF C# is het sowieso makkelijk genoeg over te stappen later. C# heeft als 'nadeel' dan dat als je overstapt naar Java opeens een aantal dingen (delegates, properties) moet missen. Even wennen maar daar kom je wel doorheen.

Het is wat anders als je gaat webdevven want Asp.net is compleet anders dan JSP, en dan is ASP.Net 2 WEER compleet anders dan Asp.net (1).

Zo heel veel verschillen .NET 1.0 en 2.0 toch niet van elkaar. Wel ben ik met je eens dat beiden anders werken dan PHP, JSP en het klassieke ASP (3), omdat het hele model eigenlijk anders in elkaar zit. Werken met pagina's als objecten, de flow van asp.net en andere zaken. Dat is even wennen.

Maar 1.0 en 2.0 verschillen alleen van elkaar op het gebied van "leuke extratjes" zoals masterpages. Neemt niet weg dat ik als ASP.NET ontwikkelaar hier niet blij mee was, ik kon bij wijze van spreken juist een vreugde sprongetje maken

Over java weet ik niet helemaal of je gelijk hebt, heeft java niet inmiddels ook de mogelijkheid om properties te maken (is al ruim 3 jaar geleden dat ik met java heb gewerkt). En anders maak je de get en set methodes aan (kun je vast wel een snippet of plugin voor vinden/maken), is denk ik een kwestie van gewoon aanleren En betreft delegates, ik dacht dat java dat ook kon... Maar goed java had dan weer anonieme methodes, want .net pas sinds kort heeft.

Zo heeft iedere taal zijn charme. Zoals het with keyword in visual basic. Die miste ik in het begin (toen ik na een tijdje VB als hobby naar de informatica opleiding ging waar we java kregen), maar na verloop van tijd kijk/werk je daar omheen en mis je het niet zo zeer meer

[EfBe]

Hydra schreef op donderdag 25 oktober 2007 @ 11:52:
[...]
Nouja, als je tegenwoordig een project doet waarbij webservices of webapplicaties opgeleverd moeten worden, hoef je sowieso niet aan te komen met C++ lijkt me? Dat is mijn 'ervaring', dat de default basis .Net of Java is. Waarom is dat? Onderhoudbaarheid en ontwikkelsnelheid. Dat de executietijd marginaal langer is, is voor de opdrachtgever niet relevant.

Ik zie niet in wat een taal met onderhoudbaarheid te maken heeft. Ontwikkelsnelheid is ook niet 'vanzelfsprekend korter' in een VM gebruikende taal, puur omdat er een GC in zit. Mensen die de STL als hun broekzak kennen, rennen rondjes om jou en je java met wellicht nog minder geinvesteerde tijd ook. Niet onderhoudbaar? Kost erg veel tijd? Lijkt me niet, want is het niet zo dat de meeste tijd van een softwareproject wordt gespendeerd aan andere zaken dan code tikken?

Overigens, als ik C++ door php vervang, is het dan ineens zo dat VM gebruikende talen brak zijn want de ontwikkeltijd is langer dan bij PHP?

Ik zeg niet dat Java / .Net ALTIJD de beste tool for the jo zijn, heck, in een project een tijdje terug is nog iemand (gelukkig niet ik) in COBOL bezig geweest, maar het meeste nieuwe spul code je daar niet in

Volgens mij weet jij niet half in wat voor talen de meeste software geschreven wordt. Die paar websites die gebouwd worden hier en daar... dat is een fractie van de bakken met code die overal ter wereld aan applicaties worden toegevoegd. En ja, nieuwe dingen op grote machines worden wellicht nog altijd in cobol gedaan, of RPG, domweg omdat de rest dat ook is. Ouwe-lulle code? Troep? nee, realiteit.

[...]
Ik begrijp niet helemaal wat je hiermee wil bereiken, maar ik zie niet hoe de snelheid van een VB COM component hier relevant is. 'Vroegah' was ik ook fijn in VBS binnen ASP bezig, maar dat vind ik niet relevant in deze discussie.

Het is wellicht een rare opmerking, maar 'nieuwe' software is echt niet relevant voor deze wereld. het gros van de software developers werkt al voor korte of langere tijd aan bestaande code en dat wordt alleen maar erger.

Wat ik wilde aangeven is dat een VM gebruikende taal (VB) met dezelfde karakteristieken als Java en C# mbt geheugenbeheer en pointermanagement niet zoveel sneller is qua ontwikkelsnelheid als C++ voor hetzelfde programma. Tuurlijk, een UI bouwen in C++ is wellicht wat lastiger, maar is dat de applicatie an sig? Lijkt me niet meer dan een onderdeel.

Daarnaast is iets 'herschrijven' kwa tijdsinvesteringsvergelijking niet helemaal eerlijk. Als ik een Java app van mij herschrijf in Java, is java opeens ook 2x zo snel als java kwa devven?

Lees die opmerking nu eens over, en ga dan eens nadenken waar de meeste tijd kennelijk gaat zitten mbt software development en je hebt zelf antwoord gegeven of het echt relevant is welke taal je gebruikt (ok, brainfuck daargelaten ) mbt ontwikkelsnelheid. (hint: als ik dus gewoon goed nadenk en daar 2/3e van de tijd aan besteed, boeit het niet in welke taal ik het opschrijf)

[Hydra]

EfBe schreef op donderdag 25 oktober 2007 @ 13:00:
Het is wellicht een rare opmerking, maar 'nieuwe' software is echt niet relevant voor deze wereld. het gros van de software developers werkt al voor korte of langere tijd aan bestaande code en dat wordt alleen maar erger.

*shrug*

Best, we lullen langs mekaar heen. Ik zeg dat mijn ervaring is dat NIEUWE systemen (en dan heb ik het over multi-tier systemen met zowel een frontoffice deel alsook een customer facing webapp interface) in projecten waar WIJ inzitten 9 van de 10 keer in Java of .Net gebouwd worden (en die 10e is dan PHP). Ik ben op dit moment met een project bezig waarbij we een stuk infrastructuur aan het ombouwen zijn naar een Java SOA structuur omdat de oude meuk (Cap Gemini zooi) te ononderhoudbaar is bijvoorbeeld. En dit is bij een groot overheidsbedrijf hier in NL. Dit is mijn ervaring. Je hebt 100% gelijk dat er een hoop oude systemen zijn waar dingen bijgeklust worden (vandaar m'n opmerking over COBOL, ik heb dat ook gezien ja, alleen de uitvoer daarvan werd door een Java service verwerkt), maar ik refereerde aan NIEUWE systemen.

Een discussie prima, maar aan het typische PRG ik-weet-het-beter haantjesgedrag heb ik een broetje dood. Dus: toedels.

[EfBe]

Hydra schreef op donderdag 25 oktober 2007 @ 13:50:
[...]
*shrug*
Best, we lullen langs mekaar heen. Ik zeg dat mijn ervaring is dat NIEUWE systemen (en dan heb ik het over multi-tier systemen met zowel een frontoffice deel alsook een customer facing webapp interface) in projecten waar WIJ inzitten 9 van de 10 keer in Java of .Net gebouwd worden (en die 10e is dan PHP).

Dat is fijn, maar jij presenteert het alsof het DE realiteit is voor ALLE software. Dat is waar ik een opmerking over had.

Ik ben op dit moment met een project bezig waarbij we een stuk infrastructuur aan het ombouwen zijn naar een Java SOA structuur omdat de oude meuk (Cap Gemini zooi) te ononderhoudbaar is bijvoorbeeld. En dit is bij een groot overheidsbedrijf hier in NL. Dit is mijn ervaring. Je hebt 100% gelijk dat er een hoop oude systemen zijn waar dingen bijgeklust worden (vandaar m'n opmerking over COBOL, ik heb dat ook gezien ja, alleen de uitvoer daarvan werd door een Java service verwerkt), maar ik refereerde aan NIEUWE systemen.

Maar het gros van de developers op aarde maakt al geen NIEUWE systemen meer. Ga dan niet jouw ervaringen projecteren op de groep developers als zijnde 'de waarheid' want die is echt wel even anders, hoe hard jij ook wilt gaan roepen dat wat jij meemaakt toch echt erop lijkt alsof iedereen dat meemaakt.

Een discussie prima, maar aan het typische PRG ik-weet-het-beter haantjesgedrag heb ik een broetje dood. Dus: toedels.

Hoe kun je een discussie houden wanneer jij niet kunt hebben dat iemand anders een andere mening heeft en wellicht verstand van zaken heeft? Of denk jij dat ik geen reet verstand heb van waarover ik praat?

[Cloud]

EfBe schreef op donderdag 25 oktober 2007 @ 13:00:
Ik zie niet in wat een taal met onderhoudbaarheid te maken heeft. Ontwikkelsnelheid is ook niet 'vanzelfsprekend korter' in een VM gebruikende taal, puur omdat er een GC in zit. Mensen die de STL als hun broekzak kennen, rennen rondjes om jou en je java met wellicht nog minder geinvesteerde tijd ook. Niet onderhoudbaar? Kost erg veel tijd? Lijkt me niet, want is het niet zo dat de meeste tijd van een softwareproject wordt gespendeerd aan andere zaken dan code tikken?

NOFI: Misschien doe je opzettelijk alsof je niet begrijpt wat de beste man bedoelt, of misschien snap je het echt gewoon niet.
We hebben het over nieuwe projecten. En in dit licht, hebben we het ook over nieuwe mensen die aan die projecten werken. Tuurlijk een ervaren rot in C++ doet dingen sneller dan een beginner die met .NET/Java werkt. Maar daar gaat het helemaal niet over, we hebben het over doorsnee programmeurs.

De productiviteit van .NET ligt nu eenmaal (veel) hoger dan die van C++ als je die van doorsnee gebruikers vergelijkt. Zeker voor beginnende programmeurs! Er is een hele berg aan componenten/api's kant-en-klaar om te gebruiken voor de meest uit een lopende zaken. Onderhoudbaarheid is ook beter in .NET simpelweg vanwege het feit dat de taal zoveel simpeler is. Dat betekent dat nieuwe mensen zich sneller in de code kunnen werken, dit ook omdat er gebruik gemaakt kan worden van standaard functionaliteit die zij al kennen.

Goed, dat is dat. Dit is vooralsnog een discussie die geen donder met de vraag van de TS te maken heeft.

@TS:
Het lijkt mij een mooi moment voor je om (al dan niet geheel) over te stappen op C#. Zoals al gezegd is en je ongetwijfeld zelf ook hebt gezien, er zijn verschrikkelijk veel .NET/Java vacatures. Het aantal C++ begint gewoon af te nemen.

Daarnaast, als je met C# leert werken, leer je een framework kennen. Je kunt dus web applicaties, webservices, standalone applicaties, mobile applicaties maken, allemaal vanuit één framework en taal. Dit is m.i. een van de grootste voordelen van een overstap. Je bent klaar voor de toekomst, want hoe je het ook wendt of keert, het aantal C++ vacatures zie ik niet meer (fors) stijgen

[.oisyn]

wolkje schreef op donderdag 25 oktober 2007 @ 16:03:
Daarnaast, als je met C# leert werken, leer je een framework kennen. Je kunt dus web applicaties, webservices, standalone applicaties, mobile applicaties maken, allemaal vanuit één framework en taal. Dit is m.i. een van de grootste voordelen van een overstap. Je bent klaar voor de toekomst, want hoe je het ook wendt of keert, het aantal C++ vacatures zie ik niet meer (fors) stijgen

Maar als senior C++ developer zie ik mijn rate daarentegen wel stijgen, want ik word zeldzaam. Dus idd, iedereen moet vooral gaan .Netten

[Cloud]

.oisyn schreef op donderdag 25 oktober 2007 @ 16:08:
[...]

Maar als senior C++ developer zie ik mijn rate daarentegen wel stijgen, want ik word zeldzaam. Dus idd, iedereen moet vooral gaan .Netten

Fair enough Zo kun je het natuurlijk ook bekijken.

[EfBe]

wolkje schreef op donderdag 25 oktober 2007 @ 16:03:
[...]
NOFI: Misschien doe je opzettelijk alsof je niet begrijpt wat de beste man bedoelt, of misschien snap je het echt gewoon niet.

Erm... hij deed een opmerking over onderhoudbaarheid e.d. mbt taalkeuze. Die connectie is er echt niet, onderhoudbare software kan in alle talen en onmogelijke crap evenzeer.

We hebben het over nieuwe projecten. En in dit licht, hebben we het ook over nieuwe mensen die aan die projecten werken. Tuurlijk een ervaren rot in C++ doet dingen sneller dan een beginner die met .NET/Java werkt. Maar daar gaat het helemaal niet over, we hebben het over doorsnee programmeurs.

Mja, wat is doorsnee programmeur. Ik wil niet arrogant overkomen, maar de doorsnee programmeur op .NET is echt niet zo productief bezig, omdat deze zich veelal meer laat verleiden door het spenderen van veel tijd in designers en andere tijdvreters en minder in het goed opzetten van code en het schrijven van slimme classes.

De productiviteit van .NET ligt nu eenmaal (veel) hoger dan die van C++ als je die van doorsnee gebruikers vergelijkt. Zeker voor beginnende programmeurs!

Ik ben het wel met je eens dat beginners wellicht iets meer uit .net krijgen dan uit C++. Maar beginners moeten zich geen illusies maken: ze zijn in alle talen een beginner en dat heeft niets met de taal te maken, het zijn beginnende programmeurs, dus prutsen ze zich een slag in de rondte. Dat is niet erg, daar zijn het beginners voor. Maar programmeren heeft niet zoveel met talen an sig te maken, dus welke taal je kiest is eigenlijk irrelevant. Vind je de taal WEL relevant, dan beschouw je de programmeur als een menselijke code generator. Nu is het echter zo dat een digitale code generator het er meestal wat beter vanaf brengt, dus om nu in te gaan zetten op het noeste typewerk, dat lijkt me niet erg slim.

Er is een hele berg aan componenten/api's kant-en-klaar om te gebruiken voor de meest uit een lopende zaken. Onderhoudbaarheid is ook beter in .NET simpelweg vanwege het feit dat de taal zoveel simpeler is. Dat betekent dat nieuwe mensen zich sneller in de code kunnen werken, dit ook omdat er gebruik gemaakt kan worden van standaard functionaliteit die zij al kennen.

Maar een C++ programmeur kent ook zn libraries.
En onderhoudbaarheid heeft geen ruk met taalkeuze te maken! Ik vind het overigens knap dat mensen die aan nieuwe dingen sleutelen, een voorstelling kunnen maken hoe onderhoudbaar .NET code is tov. hoe onderhoudbaar C++ code is. Immers, wanneer zijn deze experts op het gebied van onderhoudbaarheid dan bezig met een project dat een grote applicatie van versie x naar versie y migreert? (en waarbij de software al een tijdje bestaat)

Hint: erg belangrijk bij onderhoudbaarheid is dat je begrijpt wat de code doet. Een transactional graph versioner in C# is voor jou abracadabra als jij niet weet wat een graph versioner is en hoe transacties werken op graphs van objects in-memory.

Goed, dat is dat. Dit is vooralsnog een discussie die geen donder met de vraag van de TS te maken heeft.

Waarom niet? Omdat jij dat vindt? Ik zie allerlei mensen uitspraken doen mbt .NET en andere VM based platforms mbt onderhoudbaarheid, tijd die het kost om software te schrijven en wat al niet...

Als je daar dan geen kanttekeningen bij mag plaatsen, mij best, maar hou dan geen discussie.

Daarnaast, als je met C# leert werken, leer je een framework kennen. Je kunt dus web applicaties, webservices, standalone applicaties, mobile applicaties maken, allemaal vanuit één framework en taal. Dit is m.i. een van de grootste voordelen van een overstap. Je bent klaar voor de toekomst, want hoe je het ook wendt of keert, het aantal C++ vacatures zie ik niet meer (fors) stijgen

waarom dan geen Java? of ruby? No offence, en als woorden van een C# MVP zoals ondergetekende klinkt dit wellicht leip, maar ik zou echt voor Java kiezen ipv C#.

[Cloud]

EfBe schreef op donderdag 25 oktober 2007 @ 21:01:
[heel veel praat]
Waarom niet? Omdat jij dat vindt? Ik zie allerlei mensen uitspraken doen mbt .NET en andere VM based platforms mbt onderhoudbaarheid, tijd die het kost om software te schrijven en wat al niet...

Dat waren allemaal offtopic reacties. Daarom stelde ik voor om weer terug naar de TS te gaan. Het gaat hier om de vraag of het wenselijk is voor de TS is om over te stappen van C++ naar C# (of Java), en niet om onderhoudbaarheid, ontwikkelsnelheid etc. En dan kunnen nog zo veel lui daar over blaten, dat betekent nog steeds niet dat dit topic daarvoor bedoeld is. Toch?

Kortom: ik vind helemaal niets, ik lees de topicstart.

[...]
waarom dan geen Java? of ruby? No offence, en als woorden van een C# MVP zoals ondergetekende klinkt dit wellicht leip, maar ik zou echt voor Java kiezen ipv C#.

En jij gaat ons natuurlijk niet vertellen waarom je bijvoorbeeld Java zou moeten kiezen. Wederom een loze uitspraak zonder onderbouwing, waar (ik herhaal) de TS geen donder aan heeft.

offtopic:
sorry als dit een beetje persoonlijk over komt, maar je weet blijkbaar niet van ophouden

Nog maar een poging tot ontopic:
Overigens kan ik Ruby meteen al afraden. Het is een leuk taaltje, met veel potentie, maar er is werkelijk niemand die er commercieel in bezig is (even uitgaande van vacatures). Eerst maar even een paar jaar wachten voordat dat aantrekkelijk wordt. Hobbyen kan natuurlijk altijd.

Trouwens Java is net zo'n goede keuze als C# hoor, het punt wat ik probeerde te maken is dat overstappen van C++ af, wel een goede beslissing is in mijn ogen. De markt heeft veel meer vraag naar Java en .NET programmeurs.
Overigens al wel weer lang geleden dat de TS een reactie geplaatst heeft. Issie al overgestapt ofzo?

[djc]

Zonder hier verder in te willen gaan op de Java/.NET flamewar die hier kennelijk niet minder aantrekkelijk is dan elders, zou ik de topicstarter toch ook nog graag willen wijzen op D.

Deze taal, die is gebaseerd op C en C++ en gecompileerd wordt naar machine code maar qua features Java en C# (voor zover ik dat kan overzien) veelal overstijgt is wat nieuwer, maar biedt wel een aantal mogelijkheden die Java en C# in ieder geval nog niet bevatten. Ik vind het in ieder geval een interessant project.

[flowerp]

EfBe schreef op donderdag 25 oktober 2007 @ 21:01:
Erm... hij deed een opmerking over onderhoudbaarheid e.d. mbt taalkeuze. Die connectie is er echt niet

Ik denk dat die connectie er wel degelijk is. Een taal kan bepaalde syntax constructies bevatten die speciaal zijn bedoeld voor het (beter) structureren van code. De aanname is dan dat het structureren van je code de onderhoudbaarheid vergroot. Immers als de structuur van code duidelijk is kun je er als mens snel hetgeen in vinden wat je wilt aanpassen.

In een taal die dergelijke structurerings mogelijkheden niet kent, kun je natuurlijk nog steeds zelf structureren en d.m.v. conventies bepaald gebruik voorschrijven. Het punt is natuurlijk dat er dan geen garanties zijn dat elke programmeur op een project zich ook exact aan die conventies houdt. Tevens zal elk project toch wel z'n eigen conventies gaan invoeren.

Als extreem voorbeeld; neem een taal zonder het expliciete concept "functie/procedure" zoals b.v assembly of het oude Basic. Het moge duidelijk zijn dat grote projecten in dergelijke talen zeer moeilijk te onderhouden zijn.

Moderne talen hebben diverse manieren die helpen bij het vergroten van de structuur in je programma: assemblies, classes, packages/namespaces en ondersteunende middelen zoals access modifiers. Als je daarmee b.v. encapsulatie goed toepast, dan verhoogt dat de onderhoudbaarheid. Je weet immers dat vreemde code niet bij de private delen kan komen van een class. Zonder expliciete taal constructies hiervoor worden die garanties een stuk lastiger of helemaal niet te geven.

Ook het platform kan in grote mate bijdrage aan de onderhoudbaarheid. Neem b.v. PHP. Dat is HTML met brokken code ertussen. De onderhoudbaarheid is hier laag, omdat je niet snel ziet wat bij wat hoort (alles staat door elkaar). ASP.NET en Java EE/JSF bieden hier structurerings mogelijkheden in de vorm van web controls resp web components. Deze zijn veel meer op zichzelf staand vergeleken met de diverse verspreide losse stukjes code zoals het PHP platform dat alleen maar kent.

Vanzelfsprekend moeten de handvaten die een taal biedt natuurlijk wel gebruikt worden. Iemand zou in C++ bijvoorbeeld 1 hele grote globale functie kunnen schrijven en dan met het goto statement heen en weer springen. Of in Java kan men alle instance variabelen van een class altijd public maken en alle classes in 1 enkele package zetten.

[EfBe]

wolkje schreef op donderdag 25 oktober 2007 @ 22:53:
[...]
Dat waren allemaal offtopic reacties. Daarom stelde ik voor om weer terug naar de TS te gaan. Het gaat hier om de vraag of het wenselijk is voor de TS is om over te stappen van C++ naar C# (of Java), en niet om onderhoudbaarheid, ontwikkelsnelheid etc. En dan kunnen nog zo veel lui daar over blaten, dat betekent nog steeds niet dat dit topic daarvoor bedoeld is. Toch?

Nee. Hoe kun je nu een keuze bediscussieren als volgens jou de aspecten waar je mee te maken kunt krijgen niet mag bediscussieren?

En jij gaat ons natuurlijk niet vertellen waarom je bijvoorbeeld Java zou moeten kiezen. Wederom een loze uitspraak zonder onderbouwing, waar (ik herhaal) de TS geen donder aan heeft.

offtopic:
sorry als dit een beetje persoonlijk over komt, maar je weet blijkbaar niet van ophouden

Ik wil best aangeven waarom C# de mindere keuze is hoor. Maar jij wilt puur drammen op het feit dat je niet mag bediscussieren wat aan de keuze hangt die je maakt tussen een taal (nee, niet onderhoudbaarheid). En kennelijk bepaal jij wat er bediscussieerd wordt hier, toch?

Nog maar een poging tot ontopic:
Overigens kan ik Ruby meteen al afraden. Het is een leuk taaltje, met veel potentie, maar er is werkelijk niemand die er commercieel in bezig is (even uitgaande van vacatures). Eerst maar even een paar jaar wachten voordat dat aantrekkelijk wordt. Hobbyen kan natuurlijk altijd.

*cough* thoughtworks *cough* (om maar wat te noemen)

De mensen die met ruby bezig zijn zijn veelal geen kleine kleuters of hobbyende prutsers. Dat jij niet snapt waar ruby goed voor is, is tekenend. Ooit gehoord van het concept 'DSL' ? Ooit over nagedacht dat Ruby (niet RoR, maar Ruby) als taal veel sterke kanten heeft en bv ingebed in een andere taal, bv via jRuby, een andere taal kan aanvullen? Nee?

Hobby-spul, toch? Laat me niet lachen, man.

Trouwens Java is net zo'n goede keuze als C# hoor, het punt wat ik probeerde te maken is dat overstappen van C++ af, wel een goede beslissing is in mijn ogen. De markt heeft veel meer vraag naar Java en .NET programmeurs.

Java is de betere keuze omdat de taal veel volwassener is, de hoeveelheid software die beschikbaar is is vele malen groter en volwassener, de gebruikte technieken zijn veelal al in een verder stadium en veel wetenschappelijk onderzoek wordt gedaan mbv java. Ook is het ontwerp van java niet echt beinvloed door product-druk van binnenuit bij sun. Dit is erg belangrijk. C# is in de komende iteratie (3.0) 'verrijkt' met nieuwe features die veelal te kort schieten of maar half zijn en anderen missen weer (geen AOP ondersteuning, wel extension methods, geen extension properties, kreupele linq syntaxis etc.). Alle nieuwe features in C# zijn toegevoegd om Linq mogelijk te maken. Dus er is niet nagedacht omtrent 'dit moet de taal nog hebben en dat voegen we toe', maar onder het mom van linq heeft de taal nu dingen als extension methods. Maar bv nog steeds geen co-variance.

En de 'markt'. Het is maar net wat je daar onder verstaat. Niet iedereen wil consultant worden en van hot naar her rijden in de auto van de zaak.

Deze hele discussie gaat nl. aan het punt voorbij wat het allerbelangrijkste is: het werk zelf. Niet de baan, niet het geld, maar het werk: wat voor software ga je schrijven? Welke kennis heb je al in huis? Heeft een programmeertaal dan wel zoveel invloed op welk werk men gaat doen? Het zou niet zo moeten zijn, immers: is men software engineer of een specialist in de syntax en compiler behavior van een bepaald taaltje? Denk goed na wat je daarop antwoord, want de komende jaren gaan veel dingen richting multi-taal gebruik: veel meer DSLs zullen worden toegepast waar nu nog general purpose talen worden ingezet. Ben je specialist op een taalgebied, dan verlies je terrein, terwijl dat eigenlijk niet mogelijk zou moeten zijn, want programmeren is taal onafhankelijk. Het is dus IMHO beter om de taal als tool te zien en je te focussen op het werkelijke programmeren. Alleen dan stijg je boven het maaiveld uit van handjes die code kloppen, want helaas voor de mensen in NL, maar veel van dat werk is tegenwoordig goedkoper in India te doen.

[ Voor 17% gewijzigd door EfBe op 26-10-2007 09:26 ]

[Cloud]

EfBe schreef op vrijdag 26 oktober 2007 @ 09:18:
*cough* thoughtworks *cough* (om maar wat te noemen)

De mensen die met ruby bezig zijn zijn veelal geen kleine kleuters of hobbyende prutsers. Dat jij niet snapt waar ruby goed voor is, is tekenend. Ooit gehoord van het concept 'DSL' ? Ooit over nagedacht dat Ruby (niet RoR, maar Ruby) als taal veel sterke kanten heeft en bv ingebed in een andere taal, bv via jRuby, een andere taal kan aanvullen? Nee?

Nou nou nou. Ik heb nooit beweert dat mensen die met ruby bezig zijn alleen maar kleine kleuters of hobbyend prutsers zijn. Dat maak jij ervan. En ik snap niet waar ruby goed voor is is tekenend? Dude doe normaal. Alleen omdat ik geen heel repertoire aan fancy buzzwords hier neer flikker, tekent dat mijn kennis van Ruby? *zucht*
Ik ben er inmiddels al achter waarom de anderen in deze discussie afgehaakt zijn

Maar toch, tegen alle verwachtingen in, reageer je ook nog normaal, volwassen en on topic:

Java is de betere keuze omdat de taal veel volwassener is, de hoeveelheid software die beschikbaar is is vele malen groter en volwassener, de gebruikte technieken zijn veelal al in een verder stadium en veel wetenschappelijk onderzoek wordt gedaan mbv java. Ook is het ontwerp van java niet echt beinvloed door product-druk van binnenuit bij sun. Dit is erg belangrijk. C# is in de komende iteratie (3.0) 'verrijkt' met nieuwe features die veelal te kort schieten of maar half zijn en anderen missen weer (geen AOP ondersteuning, wel extension methods, geen extension properties, kreupele linq syntaxis etc.). Alle nieuwe features in C# zijn toegevoegd om Linq mogelijk te maken. Dus er is niet nagedacht omtrent 'dit moet de taal nog hebben en dat voegen we toe', maar onder het mom van linq heeft de taal nu dingen als extension methods. Maar bv nog steeds geen co-variance.

Met dat antwoord kan ik leven. Java lijkt in die opzichten de betere taal en zou dus ook zeker overwogen kunnen worden door de TS.

En de 'markt'. Het is maar net wat je daar onder verstaat. Niet iedereen wil consultant worden en van hot naar her rijden in de auto van de zaak.

Help me even, maar waar heb ik voorgesteld dat de TS consultant moet worden? Met de markt bedoel ik vacatures, met de markt bedoel ik wat er leeft. Of bestaat de markt tegenwoordig alleen nog uit consultants die van hot naar her rijden in auto's van hun zaken?

Deze hele discussie gaat nl. aan het punt voorbij wat het allerbelangrijkste is: het werk zelf. Niet de baan, niet het geld, maar het werk: wat voor software ga je schrijven? Welke kennis heb je al in huis? Heeft een programmeertaal dan wel zoveel invloed op welk werk men gaat doen? Het zou niet zo moeten zijn, immers: is men software engineer of een specialist in de syntax en compiler behavior van een bepaald taaltje? Denk goed na wat je daarop antwoord, want de komende jaren gaan veel dingen richting multi-taal gebruik: veel meer DSLs zullen worden toegepast waar nu nog general purpose talen worden ingezet. Ben je specialist op een taalgebied, dan verlies je terrein, terwijl dat eigenlijk niet mogelijk zou moeten zijn, want programmeren is taal onafhankelijk. Het is dus IMHO beter om de taal als tool te zien en je te focussen op het werkelijke programmeren. Alleen dan stijg je boven het maaiveld uit van handjes die code kloppen, want helaas voor de mensen in NL, maar veel van dat werk is tegenwoordig goedkoper in India te doen.

Ook eindelijk een nuttig punt van jouw kant waar ik het dan ook mee eens ben. Gelukkig heeft de TS al veel C++ kennis in huis, dus daar heeft hij niet last van Een goede programmeur kan zich elke taal meester maken. Daarom vind ik ook (en de meesten met mij) dat het erbij leren van een taal een goede keus is. Je hoeft niet volledig over te stappen natuurlijk.

[EfBe]

wolkje schreef op vrijdag 26 oktober 2007 @ 10:30:
[...]
Nou nou nou. Ik heb nooit beweert dat mensen die met ruby bezig zijn alleen maar kleine kleuters of hobbyend prutsers zijn. Dat maak jij ervan.

Lijkt me een logische conclusie uit jouw opmerking dat ruby nog maar even niet moet worden gebruikt buiten de hobbysfeer om. PRECIES dat punt is tekenend dat je niet snapt waar de kracht van ruby ligt of DSL's in zn algemeenheid. Je vergeet dat meer dan de mensen in deze thread deze thread lezen, en dan jouw 'advies' lezen. Het lijkt me dan ook nuttig voor die lezers dat er aangegeven wordt hoe de wereld werkelijk werkt.

En ik snap niet waar ruby goed voor is is tekenend? Dude doe normaal. Alleen omdat ik geen heel repertoire aan fancy buzzwords hier neer flikker, tekent dat mijn kennis van Ruby? *zucht*
Ik ben er inmiddels al achter waarom de anderen in deze discussie afgehaakt zijn

Wat heeft het aanhalen van ruby met buzzwords te maken? Ik haat buzzword bingo.

[...]
Help me even, maar waar heb ik voorgesteld dat de TS consultant moet worden? Met de markt bedoel ik vacatures, met de markt bedoel ik wat er leeft. Of bestaat de markt tegenwoordig alleen nog uit consultants die van hot naar her rijden in auto's van hun zaken?

Fair enough, ik krijg nl. de indruk dat menigeen het hier heeft over banen bij bv cap, cmg en andere handenverhuurders.

[...]
Ook eindelijk een nuttig punt van jouw kant waar ik het dan ook mee eens ben. Gelukkig heeft de TS al veel C++ kennis in huis, dus daar heeft hij niet last van Een goede programmeur kan zich elke taal meester maken. Daarom vind ik ook (en de meesten met mij) dat het erbij leren van een taal een goede keus is. Je hoeft niet volledig over te stappen natuurlijk.

Dus het topic van deze thread is eigenlijk een onzinnige vraag? Kijk, nu komen we ergens

[Cloud]

EfBe schreef op vrijdag 26 oktober 2007 @ 10:48:
Lijkt me een logische conclusie uit jouw opmerking dat ruby nog maar even niet moet worden gebruikt buiten de hobbysfeer om. PRECIES dat punt is tekenend dat je niet snapt waar de kracht van ruby ligt of DSL's in zn algemeenheid. Je vergeet dat meer dan de mensen in deze thread deze thread lezen, en dan jouw 'advies' lezen. Het lijkt me dan ook nuttig voor die lezers dat er aangegeven wordt hoe de wereld werkelijk werkt.

Oke daar zit wat in. Zo bedoelde ik het eigenlijk ook niet, al kan ik me voorstellen dat het zo overkwam. Ruby is inderdaad een mooie ontwikkeling en heeft veel potentie. Er kan en moet daarom ook commercieel mee gewerkt worden, dat is mooi en belangrijk.
Het is nu alleen nog zo, dat er niet zo bijzonder veel commercieel mee gedaan wordt (er zijn altijd uitzonderingen). Dus mijn punt is meer, "wil je een van de eersten zijn?".

Dat is een afweging die je moet maken en je hebt gelijk als je zegt dat je het niet per definitie moet laten.

Dus het topic van deze thread is eigenlijk een onzinnige vraag? Kijk, nu komen we ergens

Oh nee zeker niet! Er bestaan geen onzinnige vragen hé, alleen onzinnige antwoorden Het is inderdaad waar dat de TS de "overstap" niet zo zwart-wit moet zien, maar meer als een toevoeging op wat hij al heeft/kent.

Alleen nu raak ik wel meer en meer benieuwd naar de reactie van de TS op dit alles. In het geval van de TS moet hij natuurlijk ook voor het bedrijf een keuze maken tussen C++, C# en Java, het is niet handig om op het bedrijf alles door elkaar te gaan gebruiken natuurlijk Hoewel natuurlijk alles kan...

offtopic:
de rest laat ik opzettelijk in 't midden

[Glimi]

EfBe schreef op vrijdag 26 oktober 2007 @ 09:18:
De mensen die met ruby bezig zijn zijn veelal geen kleine kleuters of hobbyende prutsers. Dat jij niet snapt waar ruby goed voor is, is tekenend. Ooit gehoord van het concept 'DSL' ? Ooit over nagedacht dat Ruby (niet RoR, maar Ruby) als taal veel sterke kanten heeft en bv ingebed in een andere taal, bv via jRuby, een andere taal kan aanvullen?

Just curious, maar waarom vind je Ruby een DSL? Het komt mij vrij general purpose over, zonder specefiek domein waar het op gericht is. Puur omdat het embedded in een andere taal is?

[Hydra]

EfBe schreef op donderdag 25 oktober 2007 @ 14:56:
Dat is fijn, maar jij presenteert het alsof het DE realiteit is voor ALLE software. Dat is waar ik een opmerking over had.

Dan moet je toch eens beter leren lezen, want dat heb ik gewoon niet gezegd. Ik zei zelfs al dat bijvoorbeeld games/simulaties logischerwijs in C++ (voor een groot deel) geschreven worden, omdat elke frame per seconde daar telt. Ook zei ik eerder al dat oude software die uitgebreid moet worden (COBOL shit bijvoorbeeld) ook niet zondermeer 'even' herschreven worden in Java.

Maar het gros van de developers op aarde maakt al geen NIEUWE systemen meer. Ga dan niet jouw ervaringen projecteren op de groep developers als zijnde 'de waarheid' want die is echt wel even anders, hoe hard jij ook wilt gaan roepen dat wat jij meemaakt toch echt erop lijkt alsof iedereen dat meemaakt.

Gast, wat is jouw probleem zeg? Ik zeg LETTERLIJK dat nieuwe software over het algemeen in Java of C# ontwikkeld wordt. Dat er ik-weet-niet-hoeveel programmeurs oude software BEHEREN zal me een zorg wezen, ik zal nooit software beheren. Ik wil nieuwe dingen bedenken, geen bugs fixen in andermans zooi.

Hoe kun je een discussie houden wanneer jij niet kunt hebben dat iemand anders een andere mening heeft en wellicht verstand van zaken heeft? Of denk jij dat ik geen reet verstand heb van waarover ik praat?

Nee, het punt is dat je doet alsof IK geen reet verstand heb van waarover ik praat. Ik heb in de 6 jaar werkervaring die ik heb bij tientallen verschillende klanten van ons minstens evenzoveel projecten gedaan, die allemaal 'nieuwe' maatsoftware waren, en eigenlijk allemaal in Java of .Net ontwikkeld werden. Onze klanten zitten in een flink aantal marktsegmenten (HR, eCommerce, Biometrics), en daar zie ik overal vraag naar Java en C# developers. Wij doen ook wel eens wat C++ werk, maar dat zijn over het algemeen simpele kleine dingetjes.

Dus, als jij ervaring hebt met grote commerciele systemen (multi-tier, backend, frontoffice en website) waarbij het systeem op dit moment from scratch in C++ geschreven wordt hoor ik het graag. Ik geloof best dat jij weet waar je het over hebt, maar ik hoop dat jij ook het respect kunt hebben om wat anderen aandragen niet meteen als volslagen onzin af te doen.

EfBe schreef op donderdag 25 oktober 2007 @ 21:01:
Erm... hij deed een opmerking over onderhoudbaarheid e.d. mbt taalkeuze. Die connectie is er echt niet, onderhoudbare software kan in alle talen en onmogelijke crap evenzeer.

Leuke theorie, maar in de praktijk werkt dit toch iets anders. De verschillende C++ libraries die je bij het ontwikkelen van software nodig hebt zijn vaak niet uniform, (MFC, *braak*), en C++ nodigt veel meer dan bijvoorbeeld Java uit tot gegochel met de prepocessors en pointers bijvoorbeeld. Een goeie programmeur zal in theorie natuurlijk in een willekeurige taal prachtige code schrijven, maar in de praktijk zijn de meeste programmeurs lui (of hebben tenminste een deadline). Daarbij komt ook nog eens dat dingen als garbage collection gewoon een hoop tijd schelen, en het op zich best fijn is dat je een nette exception krijgt in plaats van een coredump op 't moment dat je buiten je array aan 't schrijven bent.

Mja, wat is doorsnee programmeur. Ik wil niet arrogant overkomen, maar de doorsnee programmeur op .NET is echt niet zo productief bezig, omdat deze zich veelal meer laat verleiden door het spenderen van veel tijd in designers en andere tijdvreters en minder in het goed opzetten van code en het schrijven van slimme classes.

Je doet nu alsof een .Net programmeur gemiddeld genomen minder nadenkt over z'n uiteindelijke oplossing dan een C++ programmeur.

Ik ben het wel met je eens dat beginners wellicht iets meer uit .net krijgen dan uit C++. Maar beginners moeten zich geen illusies maken: ze zijn in alle talen een beginner en dat heeft niets met de taal te maken, het zijn beginnende programmeurs, dus prutsen ze zich een slag in de rondte. Dat is niet erg, daar zijn het beginners voor. Maar programmeren heeft niet zoveel met talen an sig te maken, dus welke taal je kiest is eigenlijk irrelevant. Vind je de taal WEL relevant, dan beschouw je de programmeur als een menselijke code generator. Nu is het echter zo dat een digitale code generator het er meestal wat beter vanaf brengt, dus om nu in te gaan zetten op het noeste typewerk, dat lijkt me niet erg slim.

De taal zelf is niet enorm relevant, het SOORT taal wel. Java of C# zijn een andere categorie dan C++. C++ is een beetje als een oude raceauto. Je moet er een hoop aan knutselen, maar dan gaat 'ie retehard. C# is meer een Opel. Iedereen kan zo'n ding gebruiken en besturen, en voor normaal gebruik gaat 'ie hard zat. Je mag hier toch niet harder dan 120.

Maar een C++ programmeur kent ook zn libraries.
En onderhoudbaarheid heeft geen ruk met taalkeuze te maken! Ik vind het overigens knap dat mensen die aan nieuwe dingen sleutelen, een voorstelling kunnen maken hoe onderhoudbaar .NET code is tov. hoe onderhoudbaar C++ code is. Immers, wanneer zijn deze experts op het gebied van onderhoudbaarheid dan bezig met een project dat een grote applicatie van versie x naar versie y migreert? (en waarbij de software al een tijdje bestaat)

Anekdote: Wij hebben bij een klant te maken met een datatransport programma dat in C++ is geschreven waar regelmatig onderhoud op gepleegd moet worden (niet door mij). Ik heb die code wel eens onder ogen gehad, en zit me, ondanks redelijk wat C++ ervaring te hebben, behoorlijk achter m'n oren te krabben. De klant is nu bezig met een Java versie.

Feit blijft dat Java (en C#) als talen simpeler zijn. Je kunt er ook een enorme rotzooi van maken (en trust me, ik heb ook complete Java rotzooi gezien), maar je ziet enorm simpel wat de code doet, je hoeft niet te gaan zitten nadenken over tyische pointer truukjes of ranzige operator overloads (persoonlijk vind ik als je als platform met dingen als cout<< aankomt mensen uitnodigt operator overloading voor de meest ranzige dingen te gebruiken)

Hint: erg belangrijk bij onderhoudbaarheid is dat je begrijpt wat de code doet. Een transactional graph versioner in C# is voor jou abracadabra als jij niet weet wat een graph versioner is en hoe transacties werken op graphs van objects in-memory.

Tja. Ik denk dat als je veel in Java doet, je Java code leesbaarder vindt dan C++ code, en vice versa. Maar Java code is weldegelijker simpeler te lezen dankzei de afwezigheid van pointers en preprocessing spul.

Waarom niet? Omdat jij dat vindt? Ik zie allerlei mensen uitspraken doen mbt .NET en andere VM based platforms mbt onderhoudbaarheid, tijd die het kost om software te schrijven en wat al niet...

Als je daar dan geen kanttekeningen bij mag plaatsen, mij best, maar hou dan geen discussie.

Kanttekeningen plaatsen prima, maar je beweert dat coden in C++ net zo snel is als in Java. Toch grappig dat de 'markt' dat niet zo ziet.

[ Voor 50% gewijzigd door Hydra op 26-10-2007 12:27 ]

[Glimi]

Hydra schreef op vrijdag 26 oktober 2007 @ 12:08:
Dat er ik-weet-niet-hoeveel programmeurs oude software BEHEREN zal me een zorg wezen, ik zal nooit software beheren. Ik wil nieuwe dingen bedenken, geen bugs fixen in andermans zooi.

Ook je eigen zooi niet?

[Hydra]

Glimi schreef op vrijdag 26 oktober 2007 @ 12:13:
Ook je eigen zooi niet?

Liever niet Gelukkig werk ik als 'consultant' en kan ik door mij geschreven code fijn over een schutting gooien als het 'af' is

(niet dat ik er niet keihard op afgerekend wordt als ik bagger aflever hoor )

[EfBe]

Glimi schreef op vrijdag 26 oktober 2007 @ 11:14:
[...]
Just curious, maar waarom vind je Ruby een DSL? Het komt mij vrij general purpose over, zonder specefiek domein waar het op gericht is. Puur omdat het embedded in een andere taal is?

ruby mist veelal een framework waarmee je icm de taalinterpreter een volwaardige applicatie kunt bouwen. De kracht van ruby, ducktyping bv, komt tot zijn recht in specifieke elementen van een applicatie, en bv schermpjes en UI afhandeling behoren daar door de bank genomen bv niet echt toe (hangt er vanaf hoe je het opzet natuurlijk).

Het ligt dan voor de hand om voor de verschillende elementen in je applicatie die taal te kiezen die daar het best tot zijn recht komt. Ruby heeft een aantal specifieke kenmerken die je juist mist in general purpose static typed talen als C#/Java etc. Ideaal is dus die te combineren, waar mogelijk.

[Hydra]

EfBe schreef op vrijdag 26 oktober 2007 @ 14:14:
Het ligt dan voor de hand om voor de verschillende elementen in je applicatie die taal te kiezen die daar het best tot zijn recht komt. Ruby heeft een aantal specifieke kenmerken die je juist mist in general purpose static typed talen als C#/Java etc. Ideaal is dus die te combineren, waar mogelijk nodig.

Fixed

[EfBe]

Hydra schreef op vrijdag 26 oktober 2007 @ 14:37:
[...]
Fixed

Nee, waar 'mogelijk', niet waar 'nodig'. Immers, 'ideaal' is dat je ze gebruikt waar mogelijk, alleen dan krijg je de power van de beste taal voor het specifieke onderdeel van de totale applicatie. Waar 'nodig' is niet relevant, want dan gaat iemand bepalen of het nodig is, en dat is met een general purpose taal in de hand dus nauwelijks het geval, want de persoon in kwestie zal, in het achterhoofd hebbende dat hoe meer talen hoe minder noodzaak voor hem/haarzelf, altijd zoeken naar een oplossing in 1 enkele taal.