My2c, want hier wordt nogal wat zever verkocht, imho.
mausdabber zei:
Akkoord. Zet je schrap:
* In Java alloceer je alles, zelfs als er maar één instantie van een object nodig is. Software-matig is dit niet nodig.
Je moet mij eens uitleggen wat je onder alloceren verstaat. In java wordt een object instantie pas "gealloceerd" wanneer dit nodig is. Ik zie niet in hoe je iets afgehandeld krijgt als je *nooit* een object aanmaakt.
In C++ kan je toch evengoed vergeten van je objecten op het juiste moment te verwijderen? Ik zie het verschil in foute code niet met een programmeur die gans de tijd een overdaad aan objecten maakt. Erger nog.. Wanneer een C++ programmeur AFAIK vergeet van objecten te verwijderen dan blijven die bestaan 'tot in den treure' of tot de server crasht. Wanneer een onvoorzichtige Java programmeur teveel objecten aanmaakt maar ze omwille van hun nutteloosheid nooit naar refereert zullen deze automatisch verwijderd worden.
mausdabber zei:
* In Java leer je niet wat geheugen de-alloceren is, want dat doet java voor jou.
Dat is dus utter bollocks. Het is aan de programmeur om te weten waar, en hoe een object door de VM gaat "garbage collected" worden. Het is waar dat er in java geen expliciete destructor bestaat, maar de finalize() methode bestaat wel degelijk en fungeert op die manier. Maar zelfs dat is niet nodig, de VM is slim genoeg om te weten wanneer er geen verwijzingen meer naar een bepaald object meer bestaan en waardoor dat object dus verwijderd mag worden. Zoek maar op: "heap", "stack" en "garbage collector".
mausdabber zei:
* Java doet heel veel met exception handling, een luxe zeg maar die je afleert hoe je routines maakt die alle (fout)situaties opvangen.
Niks houd je als java programmeur tegen om exceptions op te vangen, in te slikken en deze routinematig te behandelen. Maar imo is dit crappy code. Exceptions zijn net zeer nuttig om op een efficiënte manier fouten in het systeem te behandelen en daar gevolg aan te geven. Trouwens exceptions bestaan in C++ toch ook?
mausdabber zei:
* Java mist een aantal zaken die niet nodig zijn omdat het ding in een VM draait, maar die wel essentieel zijn in de software-wereld: pointers, alignment, bit-velden, geheugen de-alloceren, unsigned types.
De VM zorgt ten eerste al voor platform onafhankelijke software. Verder zijn alle objecten in java pointers. Enkel primitieve variabelen zijn dit niet. Hierdoor gebeurt alles dmv. call by reference, uiteraard uitgezonderd primitieve variabelen.
De zogenaamde "bit-velden" zijn bruikbaar in C++ omdat dit relatief platform afhankelijk is en past in een "word", wat vertaald wordt naar een cpu adres (edx, eax, ...) register. In de VM is dit niet nodig en niet nuttig en zeker al niet efficiënter.
mausdabber zei:
* Dit ga je niet graag horen: Java verbiedt goto. Nochtans is het leerrijk om de voor- en nadelen ervan te bestuderen gewoon door het te proberen. Als je zoals ik vaak eerst een schema tekent en dat dan omzet in source code dan kan een goto best wel noodzakelijk zijn, of net niet en je doen inzien dat het schema verbeterd kan worden.
Een labelled break en continue bestaan wel degelijk in Java... Ze worden echter maar uiterst zelden gebruikt omwille van hun bijna nutteloosheid. Ik zit al enkele jaren in het vak en heb nog nooit zoiets gebruikt of zelfs maar gezien.
mausdabber zei:
Ik heb samengewerkt met mensen die van Java naar C++ zijn omgeschakeld en vice versa. Het valt me op dat iemand met C++ achtergrond goede Java-software maakt. Het valt me ook op dat iemand die na jaren Java overstapt op C++ vaak geen goede software schrijft, net vanwege m'n argumenten: hij alloceert objecten tot in den treure, hij creëert geheugenlekken omdat hij vergeet te de-alloceren, pointers begrijpt hij niet goed.
Ik denk dat uw stelling enkel opgaat voor mensen die in hun eerste weken van omschakeling zitten en even aanpassing nodig hebben. Een Java programmeur die pointers niet goed begrijpt is geen goeie Java programmeur.
mausdabber zei:
Ik breek Java niet af, in tegendeel, ik gebruik het af en toe zelf, je kan er mooie software mee maken. Maar Java is geen goede basis om te leren programmeren of software te leren begrijpen. Het is te simpel en software is niet simpel.
Volgens mij is de simpelste oplossing de beste oplossing. We moeten niet allemaal opnieuw het wiel uitvinden he.
Java lijkt simpel, zeker als je het in z'n enge betekenis bekijkt, maar Java is ook alle open-source frameworks zoals Spring, Hibernate, iText, ... Deze 3 frameworks zijn ondertussen na lang zagen geport naar .net en c#. En verder is Java een volledig Object Georiënteerde taal die op een paar semantische zaken na even ingewikkeld kan zijn als c++. Alleen is het platform onafhankelijk en heb je daarvoor geen ingewikkeld geheugen- en machine afhankelijke bewerkingen en declaraties meer voor nodig.
Het is helemaal geen kwestie van het slechter dan of beter dan... Het is een kwestie van deftig gebruik van de programmeertaal en deftige keuze van de taal voor het gestelde probleem.
) is de simpelste oplossing de beste oplossing. Of toch uitermate vaak.
