[Sammelthread] Vor- und Nachteile verschiedener Programmiersprachen

[Miuwa]

Scheinbar besteht hier immer wieder ein Bedürfnis über die Vor- und Nachteile verschiedener Programmiersprachen bzw. deren Features und Anwendungsbereiche zu diskutieren, selbst wenn das für die eigentlichen Fragen völlig irrelevant ist. Damit diese Diskussionen nicht dauernd in anderen Threads "ausgetragen" werden wollte ich mal versuchen dafür einen dedizierten (Sammel-) Thread zu starten.

Wenn ihr also das nächste Mal in einem Thread für Sprache X darauf hinweisen wollt, dass Problem Y in Sprache Z viel einfacher gelöst werden kann oder ihr eine Aussage über eure Lieblingssprache richtigstellen wollt (was mir z.B. hin und wieder passiert) wäre mein Vorschlag (mal schauen ob ihn irgendjemand annimmt) diesen Kommentar stattdessen hier zu posten und im Originalthread zu verlinken.

 

[Moselbär]

Sprachen gibt es viele mMn.

Die Frage ist doch - was willst Du mit welcher Effizienz - oder?

Assembler - DOS nah - alt - ok - fast unschlagbar?

Makros einsetzen - modernere Sprachen - geht auch?

Bitte mal einen Link zum Originalthread.

 

[r0b0t]

Apropos Sprache: Autoren, die dezidiert schrieben, meinten oft dediziert.

 

[Faust2011]

Ich würde hier nicht nur über Programmiersprachen reden wollen, sondern auch über den Programmierstil bzw. das Paradigma. Heutzutage werden vornehmlich objektorientierte Sprachen eingesetzt und trotzdem programmieren viele noch imperativ. Von Objektorientierung findet man fast keine Spur. Das ist dann so, als würde man sich einen Porsche kaufen, um mal schnell nach Paris fahren zu können, aber dann doch nur die Landstraße nutzen.

Interessant ist auch, welche Entwicklung JavaScript durchgemacht hat. Wurde es zu Beginn nur dazu eingesetzt, dass man hier und dort auf einer Website mit ein paar Zeilen Code das Verhalten (meistens im DOM-Tree) manipuliert hat, so ist es heute eine Sprache, die diverse Paradigmen unterstützt. Man kann damit imperativ programmieren, aber auch funktional oder gar objektorientiert.

So, das waren meine just 2 Cents als Einwurf hier

 

[andy_m4]

Java - der solide Business-Partner

Ich selbst hatte mit Java erstmal ca. Mitte der 90er Kontakt. Damals war ich C++-Geschädigter *g* welches für mich gegenüber Turbo Pascal eigentlich keine Besserung bot. TP war allerdings bereits so ziemlich am Ende und ging in Delphi auf, weshalb ich die Gelegenheit nutzte etwas Neues auszuprobieren. Durch den Java-Hype (Applets) auf die Sprache aufmerksam geworden, wand ich mich dann C++ ab.
Gegenüber dem zickigen C++ war Java in vielerlei Hinsicht tatsächlich erst mal ein Fortschritt. Keine Pointer-Probleme. Einfachere Syntax. Manuelle Speicherverwaltung war auch vom Tisch.

Allgemeine Spracheigenschaften

• Programmierparadigma: objektorientiert (Klassen-basiert)
• Objektorientierung: Kapselung, Vererbung, Polymorphie, selbstdefinierte Typen sind Objekte
• Interfaces als Ersatz für Mehrfachvererbung
• Methodenüberladung aber keine Operatorüberladung
• Typisierung: statisch, stark
• Reflection
• Annotationens, teilweise auch nutzbar für Spracherweiterung
• anonyme Funktionen
• Enums
• Generics
• Fehlerbehandlung: Exceptions
• Unterstützung für reguläre Ausdrücke
• Sicherheitsfeatures eingebaut
• Threadinguntersützung sehr gut
• angepeiltes Anwendungsgebiet: Applikationen, Web-Applikationen, Mobile Apps
• freie Lizenz (GPL)

Implementation(en)

Standard OpenJDK

• Speicherverwaltung: automatisch (per Default: Generational Garbage Collection)
• Ausführung in VM mit JIT
• Foreign Function Interface (JNI)
• Geschwindigkeit ok

Umgebung

• Umfangreiche Standardbibliothek
• Bibliotheken, Frameworks: gibt es eine Vielzahl
• Datenbanksupport für die gängisten Datenbanken via JDBC
• IDE-Support: Netbeans, Eclipse, Jetbrains IDEA
• Dokumentation: sehr umfangreich
• Verbreitung: sehr verbreitet (hauptsächlich Serveranwendung)
• Community: aktiv
• freie Interpreter, IDEs und Dokumentation verfügbar

Pro

• sehr verbreitet
• Kompatibilität
• Portabilität sogar auf Binärebene
• sichere Programmierung möglich
• viele Fehler werden vom Compiler erkannt
• viele Frameworks, Dokumentation, IDE-Support

Contra

• primitive Typen stellen ein Bruch da zum sonstigen OOP-Konzept
• Speicherbedarf
• ausschweifende Syntax

Links

• Java-Homepage: http://www.oracle.com/technetwork/java/index.html
• Java Download: http://java.com/de/download/
• OpenJDK: http://openjdk.java.net/
• Wikipedia: https://de.wikipedia.org/wiki/Java_(Programmiersprache)
• Openbook Java ist auch eine Insel: http://openbook.rheinwerk-verlag.de/javainsel/

 

[Miuwa]

Danke für die Zusammenfassung.

Mich (als jemand der fast ausschließlich C++ programmiert) hat an Java am meisten gestört, dass man fast nur mit Referenzen arbeitet (die eigentlich auch nichts anderes sind als Pointer) und es keine Äquivalent zu const Foo& aus C++ gibt. Ist vermutlich nur Gewöhnungssache, aber bessere Unterstützung für value semantics und immutable interfaces hätten die Javaerfinder gerne von C++ übernehmen können.

 

[Foochan]

keine Äquivalent zu const Foo& aus C++ gibt

Nicht sicher, ob du damit value objects meinst, aber ein erster Entwurf zu value objects in Java existiert bereits. Mit einer gewissen Wahrscheinlichkeit wird das in den nächsten Java Versionen kommen.

Siehe auch:
http://openjdk.java.net/jeps/169 und http://cr.openjdk.java.net/~jrose/values/values-0.html

 

[fhtagn]

In Java 10 sollen Value Types eingeführt werden. Gleichzeitig sollen die verunstalteten Generics repariert werden; kein Type-Erasure mehr und Sachen wie List<int> sollen möglich werden.

Das alles wird nur mit einem Bruch der Binärkompatibilität zu früheren Versionen möglich sein mMn. Ich frage mich auch wie die Syntax für Referenzen auf Wertetypen aussehen soll (steht bestimmt im Proposal, keine Lust nachzulesen). Intuitiv fände ich es gut, wenn Wertetypen klein geschrieben definiert werden (complex, quaternion) und implizit dazu ein Wrapper-Referenztyp generiert wird (Complex, Quaternion). Wäre dann so wie aktuell die vordefinierten Wertetypen als Referenztypen behandelt werden, Stichwort: boxing/unboxing.

@andy_m4 reguläre Ausdrücke kannst du nicht zu den Spracheigenschaften von Java zählen, die wurden nachträglich als API eingebaut. Andere Sprachen haben Literale und Operatoren für reguläre Ausdrücke.

Die Unterstützung von Threads durch die Sprache war in der Anfangszeit mal eines der großen Features von Java. Trotzdem ist die Programmierung mit Threads nicht wirklich einfacher geworden. Das Denkmodell mit gemeinsam genutzten Variablen und Synchronisierung mit kritischen Pfaden lässt sich nur schwer überblicken und es ist sehr labil gegenüber Codeänderungen. Andere Sprachen benutzen den intuitiveren Ansatz der Synchronisierung durch Kommunikation von Threads untereinander (CSP nach Hoare von 1978). Ein Thread kann nicht einfach auf eine Variable zugreifen, sondern muss warten bis der Wert von einem anderen Thread bereitgestellt wird. Wenn der bereitstellende Thread zu schnell ist, muss er wiederum warten bis der Wert abgeholt wird. Das Denkmodell ist zwar sehr eingeschränkt, aber dadurch auch leicht nachvollziehbar.

 

[Miuwa]

Nicht sicher, ob du damit value objects meinst, aber ein erster Entwurf zu value objects in Java existiert bereits. Mit einer gewissen Wahrscheinlichkeit wird das in den nächsten Java Versionen kommen.

Siehe auch:
http://openjdk.java.net/jeps/169 und http://cr.openjdk.java.net/~jrose/values/values-0.html

Klingt für mich nicht so, ich glaube da gehts mehr um das Thema value semantics bzw. Overhead.

const Foo& foo ist eine C++-Referenzvariable (ähnlich einer final referenz in Java) auf ein Foo Objekt über die du den Zustand des Objekts aber nicht verändern kannst. In Java muss man dazu meines Wissens (was zugegebenermaßen eher gering ist) eine extra Wrapperklasse bzw. ein entsprechendes Interface schreiben (Korrigiert mich bitte wenn ich falsch liege).

 

[VikingGe]

Java kennt eben überhaupt keine constness. Das führt dann entweder dazu, dass man entweder alle Klassen per Design immutable macht, oder aber jeder Mist einen Setter hat, den man dann auch von überall aufrufen kann - und man dann nachher an den unmöglichsten Stellen Fehler findet, weil man einen popeligen 2D-Vektor nicht ohne Aufwand einfach so durch die Gegend kopieren kann. Hallo LibGDX.

Der eine Artikel da bringt es eigentlich auf den Punkt, in 98% aller Fälle braucht und will man eigentlich keine explizite Heap-Allokation, in Java kommt man bisher aber nicht drum herum (es sei denn man schreibt schwer lesbaren und unwartbaren Code, der nur mit Arrays von primitiven Typen arbeitet).


Programmiert hier eigentlich irgendjemand in Rust? Ich mag ja die Tatsache, dass die Sprache expression-based ist und zur funktionalen Programmierung einlädt, auf der anderen Seite scheint mir der Borrow Checker gerne mal Dinge zu verbieten, die an sich absolut unproblematisch sind. Ich baue damit gerade eine kleine Webseite zusammen (FastCGI-Crates existieren wie Sand am Meer ), aber so richtig warm geworden bin ich damit bisher nicht.