D Programmierung

[Helium]

Jester schrieb:

Helium schrieb:

Ich muss nochmehr nachdenken? Da wäre ja der GC doch cooler. Was ist so toll daran, dass ich mir noch ein paar Stunden lang Gedanken machen muss, wie wer wann was warum aufräumt?
Das Argument hat mich jetzt echt nicht überzeugt.

Du mußt es ja auch lesen.

Du brauchst eine Liste mit allen Einheiten, sozusagen die Einheitenverwaltung. Sonst kannste nicht abspeichern. Diese Datenstruktur mußt Du so oder so aufbauen. Auch der GC nimmt Dir das nicht ab.

Volkard sagt, daß diese Datenstruktur dann auch gleich die Freigabe mitverwalten kann. Damit haste nen eindeutigen Besitzer für die Einheiten und weißt wo das delete hin muß. Damit fällt dieses Argument für den GC deutlich schwächer aus.

Mein Zitat endet mit "wobei dann doch zu überlegen ist, ob refcounting der tolle trick ist, oder <snip>". Alles, was davor steht muss ich mir Überlegen, egal ob GC oder nicht (sprich die Geschichte mit der Collection). Alles danach muss ich mir nur überlegen, wenn ich keinen GC habe.

Ansonsten: Siehe Optimizer's post.

[daHa]

das einheitenbsp ist unbrauchbar.
spielstand speichern is ja schon ein bsp.

ein weiteres:
spaetestens wenn man alles seine einheiten in formation aufstellen will muss ein verwalter her.

und wenn diese formation gehalten werden muss sind konsturkte ala, wenn mein nachbar gekillt ist, schliess die formation mit den nachbarn meines schon gekillten nachbarn eher etwas muehsam zu implementieren.

es fehlt also noch immer ein bsp wo die ueberlegenheit des gc, ausser in verschleiern von programmierfehlern, demonstriert wird.

[Gast]

daHa schrieb:

das einheitenbsp ist unbrauchbar.
spielstand speichern is ja schon ein bsp.

Das hat nur gezeigt, dass die Einheiten trotzdem noch in irgendeiner Datenstruktur gesammelt werden müssen. Dem hat keiner widersprochen, ich sehe auch kein krasses Problem darin und was jetzt genauer noch damit gezeigt werden soll, ist mir momentan ein Rätsel. Und inwiefern das Beispiel "unbrauchbar" ist, wurde bis jetzt weder genauer ausgeführt noch gar bewiesen.

es fehlt also noch immer ein bsp wo die ueberlegenheit des gc, ausser in verschleiern von programmierfehlern, demonstriert wird.

Wurde bereits genannt. Ich muss mir Gedanken machen. Ich muss beispielsweise nen shared_ptr verwenden. Ein shared_ptr ist einem GC in Punkto Zuverlässigkeit, Performance und Komfort in den meisten Fällen unterlegen. q.e.d.
Oder ich kann Graphenalgorithmen verwenden. Das kann der GC mit seinen Generationen und dirty-writes besser als jeder von uns (außer volkard, aber ihm wäre es vielleicht zu viel Aufwand), q.e.d.

Im übrigen glaube ich nicht, dass du beurteilen kannst, wann ich Programmierfehler mache. Es wurde noch nicht mal bewiesen (nur behauptet), dass ein GC zum Verschleiern von Programmierfehlern benutzt werden kann (es wurde sogar behauptet, dass dies oft der Fall sei). Der Beweis, dass es immer einen "Besitzer" geben muss, damit das Design sauber ist (was bei dem Einheiten-Beispiel übrigens der Spieler wäre, also nicht mal ein Argument), steht auch noch aus. Ihr überzeugt mich nicht.

[Gast]

Und nochmal, es ging darum, was an optionaler gc schlecht ist. Man kann argumentieren, dass man es in D nur einfach an- oder ausschalten kann sei schlecht. Dem stimme ich zu, das ist jedoch wenn dann ein Problem von D.
So wie in C++/CLI ist es godlike (ohne Beweis, persönliche Meinung, muss nicht übernommen werden).

[daHa]

optimizer, bitte

ich hab weder dir noch sonst irgendjemand hier direkt unterstellt das er schlecht programmiert bzw einen schlechten stil pflegt.

es tut mir leid das ich so schlampig forumliert hab das du dich betroffen fuehlst, duerfte mein fehler sein.

ich hab nur darum ersucht ein beispiel aus der praxis zu bringen wo ein gc nachweislich vorteile bringt, und mir erlaubt darauf hinzuweisen das das gebrachte bsp etwas suboptimal ist.

ich hab die frage ernst gemeint.

wenn du meine postings gelesen hast, dann hast du vielleicht auch bermerkt das ich mir schwer tu festzustellen wo der vorteil eines gc liegt.
die grunde dafuer hab ich in einem post oben erwaehnt.

ich hab naemlich bis jetz kein bsp bekommen wo es um etwas anderes geht als dem programmierer das aufraeumen des speichers abzunehem, was ich nicht als vorteil empfinde.

wo die vorteile bei der programmausfuehrung liegen ist mir bis jetzt einfach nicht klar, ich kanns mir auch nicht vorstellen, desshalb hab ich um ein bsp ersucht.

[volkard]

Optimizer schrieb:

Finde ich nicht. Volkard muss immer noch wissen, wann er die Einheit deleted und das kann er nur über Referenzzählung oder Graphenalgorithmen erreichen.

einheiten werden gelöscht, wenn sie tot sind? zum beispiel sei gesichert, daß pro runde (der hauptschleife) jede einheit einmal mit überlegen drankommt und daß ein dauerbefehl wie "transporter eskortieren" jedesmal prüft, ob der transporter noch lebt, und wenn nicht, sich selbst (also den befehl) löscht. dann könnte man leicht nach jeder runde alle leichen löschen. ohne refcounting und graphenalgos. und mir kommt gar kein gedanke, wozu ich nen gc nehmen sollte. was war noch mal der genaue grund? daß ich irgendwas weniger überlegen muß?

ich überlege folgendes: must, daß mit dem löschen der leichen ist mit zu seltsam, zu spät. die existenz von leichen ist schlimm, ein objekt, das nicht mehr existiert, soll auch im programm nicht mehr herumgeistern.

das andere, die bidirektionalen verknüpfungen, wo der keuzer automatisch bescheid bekommt, wenn der transporter untergegangen ist, braucht natürlich sofort zuschlagende destruktoren. ich muss mir so ne klasse für bidirektionale zeiger basteln, ganz egal ob mit oder ohne gc. dadurch brauche ich nicht mehr mir gedanken zu machen, wer alles bescheid bekommen muß, wenn ich strebe. und ich brauche nicht vor jeder zeigerbenutzung gucken, ob das objekt dahinter noch lebt. so, jetzt gibt es keine wilden zeiger mehr (ohne gc typischerweise zeiger auf gelöschten speicher, mit gc typischerweise zeiger auf als tot markierte einheiten) und keinen bedarf für einen gc.

In jedem Fall sehe ich aber keinen Gewinn durch den Verzicht auf GC.

ich sehe keinen gwinn duch den gc.
das argument, daß man unbedingt etwas nehmen sollte, das kostenlos und optional ist, kann ich nicht nachvollziehen. warum sollte ich zu meinem auto ne kostenlose optionale (also ich habe die wahl, ob ich sie dann benutze) atombombe einbauen lassen, falls mir das einer anbietet?

Ich sehe nur mehr Aufwand, mehr Nachdenken.

mehr nachdenken in welchem rahmen denn? wenn man eh mehrere tage über das design nachdenken muß, um einen ersten entwurf zu haben, und nochmal wochenlang experimentieren muss (und ich glaube kaum, daß du für so ein spiel dir deutlich weniger zeit nehmen solltest), dann darf da auch ein wenig nachdenken über die speicherfreigabe drin sein. und dieses nachdenken jetzt in minuten zu messen und anzuklagen, zeigt nur die halbe wahrheit. mit gc dahinter komme ich zu anderen problemen, nämlich verzögerten destrukor-aufrufen, die mir mehr nachdenken bereiten oder die besonders eleganze lösungen erst gar nicht zulassen, so daß ich mit gc länger nachdenken muss.

[Helium]

volkard schrieb:

mit gc dahinter komme ich zu anderen problemen, nämlich verzögerten destrukor-aufrufen, die mir mehr nachdenken bereiten oder die besonders eleganze lösungen erst gar nicht zulassen, so daß ich mit gc länger nachdenken muss.

Der Thread hat doch immernoch ein wening D-Hintergrund, oder? Dort gibt es trotz GC sofort zuschlagende Destruktoren ("auto"-Klassen).

[Gast]

volkard schrieb:

zum beispiel sei gesichert, daß pro runde (der hauptschleife) jede einheit einmal mit überlegen drankommt und daß ein dauerbefehl wie "transporter eskortieren" jedesmal prüft, ob der transporter noch lebt, und wenn nicht, sich selbst (also den befehl) löscht.

Und alle eingereihten Befehle ebenfalls ständig überprüft. Und ich kann die Einheit nie schlafen legen, wenn sie z.B. in einem Gebäude ist. Sondern muss auch in solchen Situationen alle eingereihten Befehle auf Gültigkeit prüfen. Ich finde sowas nervig. Du findest das gutes Design, ich empfinde das aber eher als eine Einschränkung in meinen Design-Möglichkeiten, denn jetzt bin ich schonmal darauf festgelegt, in jeder Runde alle Befehle zu validieren.

Zunehmend wird es auch wichtiger, die 64 Kerne zukünftiger Prozessoren auszunutzen. Wenn alle Threads ununterbrochen allokieren und Zeiger verbiegen können wie sie wollen, halte ich das für einen Vorteil. Der GC macht natürlich irgendwann einen harten Break, der dann 64fach wehtut, den macht er aber nicht oft. Demgegenüber musst du bei anderen Systemen vielleicht viel mehr synchronisieren.

das argument, daß man unbedingt etwas nehmen sollte, das kostenlos und optional ist, kann ich nicht nachvollziehen. warum sollte ich zu meinem auto ne kostenlose optionale (also ich habe die wahl, ob ich sie dann benutze) atombombe einbauen lassen, falls mir das einer anbietet?

Als echter C++ler musst du sie (sowohl GC als auch die A-Bombe) einbauen. Du hast ja auch Überladen von '&&' und ',', warum keine Atombombe? Bei keinem Feature wird gegeizt, egal wie zeifelhaft der Sinn ist. Warum ausgerechnet bei diesem?

mehr nachdenken in welchem rahmen denn? wenn man eh mehrere tage über das design nachdenken muß, um einen ersten entwurf zu haben, und nochmal wochenlang experimentieren muss (und ich glaube kaum, daß du für so ein spiel dir deutlich weniger zeit nehmen solltest), dann darf da auch ein wenig nachdenken über die speicherfreigabe drin sein.

Gut, Argument. Das Nachdenken wäre eigentlich nicht so schlimm, das habe ich auch mit GC. Ich kann auch nen OutOfMemory kriegen, weil ich einfach aus meiner Liste die gestorbenen Einheiten vergessen habe, auszutragen. Da muss ich nen Tool anwerfen, was mir den Heap-Status anzeigt, dann seh ich den Fehler hoffentlich bald.

Aber wenn ohne GC halt doch mal ein anderer Fehler in der Speicherverwaltung ist (z.B. ein fehlgeleiteter Zeiger), hast du wirklich Freude beim debuggen, was ich nicht habe. Und beim debuggen geht bestimmt mehr Zeit drauf als beim Design.

mit gc dahinter komme ich zu anderen problemen, nämlich verzögerten destrukor-aufrufen, die mir mehr nachdenken bereiten oder die besonders eleganze lösungen erst gar nicht zulassen, so daß ich mit gc länger nachdenken muss.

Am meisten managed man doch immer die Resource "Speicher". Wenn jede Einheit eine Socket-Verbindung hält, brauche ich selbstverständlich ein anständiges System mit deterministischer Destruktion. Wenn das nicht der Fall ist, ist die verzögerte Destruktion aber eher ein Vorteil. Außerdem verstehe ich nicht, welche elegante Lösung ein GC nicht zulassen würde... ein GC tut ja schließlich meinen Objekten nichts, wenn ich sie referenziere, verhindert also auch keine deterministische Destruktion.

[kartoffelsack]

Was alle am for_each so toll finden, versteh ich net. Habs mal ein mittelgroßes Ein-Mann-Projekt lang versucht überall einzusetzen, wo ichs brauche (zugegeben die C++-Variante) --> an zwei Stellen. Ich hab echt extrem selten die Anforderung irgendwas mit ALLEN Objekten eines Containers zu tun. Sehr oft hingegen muss ich entscheiden ob ein Objekt noch in dem Container zu bleiben hat oder nicht. Und da komm ich um ne klassische Schleife net rum.

Seit ich mal tagelang nach Fehlern wegen zyklischer Referenzierung gesucht hab, bin ich von der Gleichwertigkeit von smartpointern zu ner GC auch nicht mehr überzeugt. Allerdings ist das Ref-Counting in C++ halt nur ein Nebenprodukt der automatischen Dtor-Aufrufe. Und mit denen kann ich auch andere Sachen wie Speicher verwalten und dafür gibts in den GC-Sprachen imho nix gleichwertiges.

[Ben04]

kartoffelsack schrieb:

Was alle am for_each so toll finden, versteh ich net. Habs mal ein mittelgroßes Ein-Mann-Projekt lang versucht überall einzusetzen, wo ichs brauche (zugegeben die C++-Variante) --> an zwei Stellen. Ich hab echt extrem selten die Anforderung irgendwas mit ALLEN Objekten eines Containers zu tun. Sehr oft hingegen muss ich entscheiden ob ein Objekt noch in dem Container zu bleiben hat oder nicht. Und da komm ich um ne klassische Schleife net rum.

Löschen ist natürlich das Beispiel wo ein for_each nicht geht, allerdings ist hierfür auch die normalle Benutzung der for Schleife ungeeignet. Für viele anderen Situation geht es recht gut. Zum Beispiel zum Suchen :

int find_foo(const container&vec)
{
  foreach(i in vec)
    if(is_foo(i))
      return i;
  throw not_found();
}

Zugegeben es wäre nicht schlecht ein etwas flexibleres foreach zu haben das vielleicht auch Löschen möglich machen würde.

[daHa]

std::find/_end/first_of/_if

danke zum suchen braucht man ein for_each auch nicht unbedingt

[Gast]

daHa schrieb:

std::find/_end/first_of/_if

danke zum suchen braucht man ein for_each auch nicht unbedingt

Jo, das wär auch noch zu viel Code. Aber sieh dir das mal an. Irgendwann ist es unlustig, einen Funktor zu schreiben, dem ich dann 5 Parameter (node, candidateList, isObstacle, size, this) übergebe. Es geht sowieso nicht so wahnsinnig elegant, für alle Anwendungsgebiete mit unterschiedlich viel beteiligten Objekten einen Funktor zu definieren. Bei foreach schreib ich den Funktor einfach in den Schleifenrumpf, bei Beibehaltung des gesamten lokalen Kontexts.

private void connectToCandidates(PathfindingNode node, IList<PathfindingNode> candidateList, Predicate<CollisionObject> isObstacle, long size) {
	foreach( PathfindingNode candidate in candidateList ) {
		if( candidate == node   ||   !canConnect(node, candidate, size, ObstacleCategory.FixedPosOnly, isObstacle) )
				continue;

			long distance = node.Pos.DistanceTo(candidate.Pos);
			PathfindingNode.Connect(node, candidate, distance);
		}
}

for-Schleifen habe ich gar nicht so viele. Ich habe eigentlich mehr foreach-Schleifen. Natürlich nicht, um selber FindFirst(Predicate) nach zubauen, aber für Fälle, wo es sich eher anbietet.

[adxin]

volkard schrieb:

ich sehe keinen gwinn duch den gc.
das argument, daß man unbedingt etwas nehmen sollte, das kostenlos und optional ist, kann ich nicht nachvollziehen. warum sollte ich zu meinem auto ne kostenlose optionale (also ich habe die wahl, ob ich sie dann benutze) atombombe einbauen lassen, falls mir das einer anbietet?

Diese Analogie zieht nicht, da unrealistisch. Einen kostenlosen Navi könnte man zu einem Neuwagen doch noch verhandeln.
Außerdem wenn man diese Logik anwendet, dann kann man sich auch folgende Frage stellen: Wozu muss man unbedingt etwas wie Templates nehmen, es ist kostenlos und optional. Ich kann das auch nicht nachvollziehen.
Oder warum soll ich höhere Programmiersprachen wie C o. C++ nehmen, sie sind (manchmal) kostenlos und optional.
Das selbe gilt für for-Schleifen. Warum sollte ich sie anwenden, wenn ich dasselbe mit goto erreichen kann?
(Diese Übertreibungen dienen der Verständlichkeit.)

[volkard]

adxin schrieb:

Diese Analogie zieht nicht, da unrealistisch. Einen kostenlosen Navi könnte man zu einem Neuwagen doch noch verhandeln.

aber es gibt unzweifelhaft kostenlose sachen (wie handys mit vertrag, wie religiöse mitgliedschaften, wie erste extasy-pillen, wie nordic-walking-kurse, wie analsex), die man aufgeschatzt bekommen soll oder enorm tolle sachen zum fairen preis (wie vorwerk-staubsauger), von denen man besser die finger lassen sollte. es ist nicht alles gold, was glänzt. und blei ist sogar giftig.

Außerdem wenn man diese Logik anwendet, dann kann man sich auch folgende Frage stellen: Wozu muss man unbedingt etwas wie Templates nehmen, es ist kostenlos und optional. Ich kann das auch nicht nachvollziehen.
Oder warum soll ich höhere Programmiersprachen wie C o. C++ nehmen, sie sind (manchmal) kostenlos und optional.
Das selbe gilt für for-Schleifen. Warum sollte ich sie anwenden, wenn ich dasselbe mit goto erreichen kann?
(Diese Übertreibungen dienen der Verständlichkeit.)

in den letztgenannten punkten sehe ich noch einen bescheidenen sinn. irgendwie ist keinem ein beispiel eingefallen, wo der gc signifikante vorteile bringt. nur die vermutung, er würde irgendwelches nachdenken vereinfachen, wo ich gegenvermute, daß er um die ecke noch mehr nachdenken erzwingt.

[adxin]

volkard schrieb:

in den letztgenannten punkten sehe ich noch einen bescheidenen sinn. irgendwie ist keinem ein beispiel eingefallen, wo der gc signifikante vorteile bringt. nur die vermutung, er würde irgendwelches nachdenken vereinfachen, wo ich gegenvermute, daß er um die ecke noch mehr nachdenken erzwingt.

Mir fällt auch kein stichhaltes Argument ein, da ich nur Hobby-Programmierer und Schüler bin. Ich habe ich den GC nicht als die Lösung aller Probleme dargestellt.
Ich finde bloß, dass einige Leute hier übertreiben, wenn sie ein foreach als etwas darstellen, was einen Programmierer zum "Bösen" verleitet.

Und um jetzt nochmal auf das ursprüngliche Thema zurück zu kommen:
Mit D kann man alles? machen, was auch mit C++ möglich ist. Darüber hinaus gibt es auch einen optionalen! GC, was soll daran schlecht sein?

PS: Mich würde interessieren, was z.B. die Entwickler von Java sich dabei gedacht haben als sie einen GC den Nutzern aufgezwungen haben. Aus Spaß haben sie das nicht gemacht - behaupte ich jetzt mal. Vielleicht können sie dann diese stichhalten Argumente liefern, wenn es diese überhaupt gibt.

[rzu]

adxin schrieb:

PS: Mich würde interessieren, was z.B. die Entwickler von Java sich dabei gedacht haben als sie einen GC den Nutzern aufgezwungen haben. Aus Spaß haben sie das nicht gemacht - behaupte ich jetzt mal. Vielleicht können sie dann diese stichhalten Argumente liefern, wenn es diese überhaupt gibt.

Hmm, Java war doch ursprünglich hauptsächlich für Internetprogramme(Applets und son Zeug) gedacht, oder? Da macht es schon Sinn, einen GC zu haben, wenn man will, dass die Leute sich auch trauen, den Kram anzumachen. Aber ich denke mal, die haben auch andere Argumente.

[daHa]

adxin schrieb:

Ich finde bloß, dass einige Leute hier übertreiben, wenn sie ein foreach als etwas darstellen, was einen Programmierer zum "Bösen" verleitet.

das stimmt nicht
keiner hat foreach als etwas dargestellt das programmierer zu boesem verleitet.

adxin schrieb:

Und um jetzt nochmal auf das ursprüngliche Thema zurück zu kommen:
Mit D kann man alles? machen, was auch mit C++ möglich ist. Darüber hinaus gibt es auch einen optionalen! GC, was soll daran schlecht sein?

ist aus dem zusammenhang gerissen.

ich glaub niemand hat geschrieben das D mist oder boese ist weil es einen gc anbietet.

ich denke das ist eine leicht trivialisierte zusammenfassung einiger seiten diskussion, vielleicht noch mal lesen?

[daHa]

Optimizer schrieb:

daHa schrieb:

std::find/_end/first_of/_if

danke zum suchen braucht man ein for_each auch nicht unbedingt

Jo, das wär auch noch zu viel Code. Aber sieh dir das mal an. Irgendwann ist es unlustig, einen Funktor zu schreiben, dem ich dann 5 Parameter (node, candidateList, isObstacle, size, this) übergebe. Es geht sowieso nicht so wahnsinnig elegant, für alle Anwendungsgebiete mit unterschiedlich viel beteiligten Objekten einen Funktor zu definieren. Bei foreach schreib ich den Funktor einfach in den Schleifenrumpf, bei Beibehaltung des gesamten lokalen Kontexts.

private void connectToCandidates(PathfindingNode node, IList<PathfindingNode> candidateList, Predicate<CollisionObject> isObstacle, long size) {
	foreach( PathfindingNode candidate in candidateList ) {
		if( candidate == node   ||   !canConnect(node, candidate, size, ObstacleCategory.FixedPosOnly, isObstacle) )
				continue;

			long distance = node.Pos.DistanceTo(candidate.Pos);
			PathfindingNode.Connect(node, candidate, distance);
		}
}

for-Schleifen habe ich gar nicht so viele. Ich habe eigentlich mehr foreach-Schleifen. Natürlich nicht, um selber FindFirst(Predicate) nach zubauen, aber für Fälle, wo es sich eher anbietet.

schoen, hat aber eher weniger mit dem find zu tun auf welches ich micht bezogen hab.
weil das gebrachte find mit foreach bsp laesst sich mit deiner argumentation gemauso nachteilshaft, so es das ueberhpt ist, darstellen

fuer alles laesst sich der ein oder andere fall konstruieren wo sich dieses oder jendes fuer diesen oder jenen besser lesbar/weniger zeilen oder sonst irgendwie vorteilshaft darstellen laesst.

und ob man den functor code im schleifenrumpf moechte oder nicht ist ebenfalls vielfach geschmack oder gewoehnung.

manchmal is mir ein commentar lieber als der code weil mich nicht interessiert was genau gemacht wird, sonder nur das etwas gemacht wird, und ich bin froh soundso viel zeilen code nicht an dieser stelle zu haben.
ein anderes mal is es umgekehrt.

eine verallgemeinerung oder eine % wertung, in soundsoviel% is das besser, laesst sich da meiner bescheidenen meinung nach nicht treffen.

schoen wenn ein foreach da ist, aber auch schoen wenn ein for_each da ist.
was wann wie wo wem unter welchen umstaenden lesbarer erscheint, nunja, mag ich nciht beurteilen, bzw nur fuer mich, und es liegt mir fern meinen persoenlichen geschmack jeden aufdraengen zu wollen.
ausserdem behaupt ich auch gar nicht das ich ein foreach nicht verwenden wuerd wenns da is, mir gehts aber nicht so aber das ich mir 3x taeglich denke mist das das in c++ nicht so gibt.

was diskussionswuerdig waere ist die frage ob ein foreach als sprachfeature einer anderen implementierung ueberlegen ist.
diese frage stellt sich fuer mich aber eher sekundaer, meist ist der code drumherum, oder besser zwischen drinnen, eher diskussionswuerdig.

mit D koennte man uU, so man lust und laune hat, event einen vergleich machen, wobei dann immernoch die frage offen ist ob beide implementierungen des compilers gleichwertig sind, wenns an unterschied ueberhpt gibt.

wuerde ein foreach in den meisten faellen soundsoviel messbar bessere ergebnisse erziehlen wie for_each (oder entsprechende eigenimpl.) dann waere es natuelich ueberlegnswert dies als killerfeature anzupreisen, denk aber das das so nicht sein wird, wodurch foreach fuer mich immer noch ein nice to have aber kein estentieller vorteil / argument fuer oder gegen eine sprache ist.

[volkard]

adxin schrieb:

PS: Mich würde interessieren, was z.B. die Entwickler von Java sich dabei gedacht haben als sie einen GC den Nutzern aufgezwungen haben. Aus Spaß haben sie das nicht gemacht - behaupte ich jetzt mal. Vielleicht können sie dann diese stichhalten Argumente liefern, wenn es diese überhaupt gibt.

das ist einfach. es wurde mal eine sprache OAK entwickelt für embedded systems, waschmaschinen, toaster, kühlschränke und so. mit vm, damit der hersteller leicht den prozessor in der waschmaschine austauschen kann, und mit bewußt kindergartenhaftem verhalten, damit auch der dümmste programmierer damit klarkommt, in der annahme, daß mikrocode für toaster programmieren eine solche strafe ist, daß kein normaler entwickler dort landet. außerdem ist laufzeit gar nicht wichtig, voll interpretierter zwischencode, überall exceptions. der gc war sinnvoll, daß kein mensch mit OAK komplexe programme schreiben sollte, die laufzeit egal war und mit recht ungeschickten programmierern zu rechnen war. tja, und dann hat man OAK umgenannt nach JAVA und fürs internet entdeckt, schnell die ursprünge verwischt (in den ersten java-sdks war aber der name OAK noch zu lesen) und marketinglügen verbreitet, daß sich die balken biegen.
so kommt es, daß keiner versteht, warum java genau so und nicht anders ist, daß java wie von hirnlosen idioten zusammengeklopt erscheint, aber wenn man die geschichte kennt, muß man zugeben, daß java für waschmaschinen einfach excellent ist, elegant, angemessen, toll, einfach super und nicht den hauch einer fehlentscheidung spüren läßt.

[Gast]

Wir reden hier immerhin über eine Waschmaschine mit Multithreading.