Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Community-Fossil
Sterben wird es aber wohl so schnell nicht. Außer Facebook etc. möchten ihre Exabyte an Daten auf ein neues System migrieren.
Garbage Collection war vermutlich die dümmste Idee seit Anbeginn der Informatik. Zum Glück haben die Menschen das langsam kapiert, darum gibt es auch keine nennenswerten, neuen Sprachen mehr, die ernsthaft darauf aufbauen...
So wie Go? (https://golang.org/doc/faq#garbage_collection)
Letztendlich kommt es doch wie immer darauf was und wie man entwickelt. Wenn man eine hohe Entwicklungsgeschwindigkeit will und dabei das Risiko für Mem Leaks gering halten will, nimmt man halt eine Sprache mit GC.
Wie du auf das Sterben von Java und .Net kommst ist mir ein Rätsel...
Gerade im Businessbereich wo stark auf Microsoft gesetzt wird ist .Net ganz vorne dabei.
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »dot« (12.05.2016, 13:56)
@dot: guck dir mal Go an und sag uns was du davon hältst. Würde mich interessieren, da ich die Sprache für fast "perfekt" halte (vor allem erfrischend konsequent). Garbage Collection ist in den älteren Sprachen teils nicht gut umgesetzt (gerade Java hat da ein komisches System, mit mehreren Ebenen, keine Garantien usw.). Aber zu sagen, dass automatische Speicherverwaltung generell keine gute Idee war halte ich für falsch. Schließlich benutzen wir auch in C++ Smartpointer und Co, um eben nicht selbst daran denken zu müssen. Die GC von Go zusammen mit den Pointern sorgt für automatische Speicherverwaltung + das nicht das Java Feeling aufkommt "everything is a reference".
Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »dot« (12.05.2016, 12:37)
allein schon weil sie für das, was ich mache, dadurch völlig unbrauchbar ist...
Aber es gibt nun mal Projekte bei denen es keinen wirklichen Nachteil bringt. Und dafür vereinfacht es die Entwicklung ungemein. Es hat immer wieder Neuerscheinungen in Sachen Programmiersprachen gegeben und es wurde immer gesagt das neue kann nichts sein. GC war eben ein Ansatz um die Speicherverwaltung zu vereinfachen. Das ist nicht unbedingt immer sinnvoll aber auch nicht immer schlecht.
Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »dot« (12.05.2016, 12:59)
Facebook hat ein Heer an C++ Experten die nichts anderes tun als Tag und Nacht das Backend optimieren. Wie Andrei Alexandrescu selbst gesagt hat: Wenn du es schaffst, aus Facebook auch nur 1% Performance rauszuholen, hast du allein in den gesparten Energiekosten dein Gehalt und das deiner Kollegen für viele Jahre schon wieder reingeholt...über Java wird man da nichtmal für einen Moment auch nur nachdenken...
Community-Fossil
Ich hab mir Go damals, als es rauskam, kurz angeschaut. Ein kurzer Blick in die Doku genügt mir aber, um recht schnell zu beschließen, dass ich von einer Sprache, die Dinge wie Typeswitches als Feature ansieht und dafür keine Lösung für Ressourcenmanagement anbietet (ja, es gibt defer, aber das ist auch nur die selbe Krücke, auf die sich z.B. auch C# und Java mit Using-Blöcken bzw. Try-With-Resources stützen, weil das Fundament der GC eine ordentliche Lösung unmöglich macht) nicht viel halten kann...allein schon weil sie für das, was ich mache, dadurch völlig unbrauchbar ist...
Quellcode |
|
1 2 3 4 5 |
resource, err := os.Open("irgendwas") defer resource.Close() // edit: äh das gehört natürlich hier hin if err != nil { // behandel mal } |
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »DeKugelschieber« (12.05.2016, 13:18)
In der Realität ist es aber wesentlich schwerer, in modernem C++ ein Memory Leak zu bauen, als in Java oder C# ein Filehandle zu verlieren.
Java-Quelltext |
|
1 2 3 4 5 6 |
static String readFirstLineFromFile(String path) throws IOException { try (BufferedReader br = new BufferedReader(new FileReader(path))) { return br.readLine(); } } |
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »dot« (12.05.2016, 13:23)
Ich sehe nicht wirklich das Problem ein
Quellcode
1 2 3 4 5 resource, err := os.Open("irgendwas") defer resource.Close() // edit: äh das gehört natürlich hier hin if err != nil { // behandel mal }
zu machen oder eben das Equivalent in C++.
Typswitch ist nur ein Werkzeug, um etwas komplexere dynamische Casts übersichtlicher zu gestalten. Wirklich oft braucht man das nicht.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »dot« (12.05.2016, 13:28)
Community-Fossil
Zitat von »dot«
Der Punkt ist aber, dass solche Typeswitches in der Regel als Symptom eines Designfehlers anzusehen sind. Statt dem Programmierer also zu helfen, sich möglichst unbemerkt noch weiter im Sumpf zu versenken, würde eine ordentliche Sprache ihm das Leben genau an der Stelle so schwer wie nur irgendwie möglich machen...
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »DeKugelschieber« (12.05.2016, 13:34)
Werbeanzeige