Programmiersprache mit schönster Syntax?
Welche Sprache hat eurer Meinung nach die schönste Syntax?
7 Antworten
Dazu müsste man erstmal definieren was man persönlich als "schön" ansieht....
In den 90ern hat jeder Pascalprogrammierer bei C-Syntax-Code die Nase gerümpft... zurecht.
🤣🤣🤣
...aber es geht nicht immer um "Schönheit" und heute ist Pascal nahzu verschwunden.
Viel leichter wäre es zu definieren was hässlich ist.
Ein fürchterliches "Gemetzel" bekommt man in nahezu jeder Sprache hin...
Um in Batch in ein schreckliches "Massaker" abzugleiten braucht es nur den den verzweifelten Versuch mit unvorhersehbaren Sonderzeichen im Input fertig zu werden.
...und Powershell dürfte auch nicht unbedingt für einen Wettbewerb in "Hübsch" konkurrieren.
...aber das ist auch nicht der Anspruch einer Sprache, welche ohne viele Schnörkel für "Schnellschüsse aus der Hüfte" konzipiert ist.
Des ist ne gute Frage.
Ich würde sagen Go hat ein paar schöne Dinge. Keine ;, func, := -> sind doch gar nicht so hässlich.
Würde sagen Sprachen wie Java, C++ und so weiter fliegen bei der Kategorie Schönheit definitiv direkt mal raus. Mein persönlicher Preis für die hässlichste Sprache würde denk ich an VBS gehen. Alleine schon wegen subroutines vs functions und oft Großgeschriebenen Keywords.
Keine bzw. Alle - eben die, an die Du dich am meisten gewöhnt hast.
Es gibt keine schöne oder weniger schöne Syntax. Wenn dann müsste man die Syntax einzelner Funktionen zweier Sprachen vergleichen. Wirklich relevant ist die Frage aber erst bei komplexeren Features, da die einfach Grundfunktionen im Wesentlichen immer ähnlich aufgebaut sind. Bei den Grundfunktionen ist die Syntax eigentlich nur eine Frage des Geschmacks.
Und nein, auch Java ist nicht die Sprache, die Code am besten strukturiert (ja, ich meine dich, grtgrt)
Java ist eine Sprache, die eine einfache Syntax bietet, ob sie nun besser oder schlechter ist, als Andere oder ob man damit den Code besser strukturieren kann, als mit anderen Sprachen, ist einzig und allein eine Frage des Geschmacks.
Du magst Java am besten finden, ich finde C# am besten. Wer hat Recht? Niemand.
Dein Absatz (C/C++ vs. Java) könnte aber durchaus stimmen, allerdings liegt das nicht an der Syntax, sondern an der völlig anderen Arbeitsweise und den Vereinfachungen, die Java bietet bzw. die Komplexität, die C/C++ erzwingen. Aber auch in C/C++ kann man gut strukturierten Code schreiben, man muss auf dem Weg nur mehr selber machen und beachten, was (z.B. aus Zeitgründen, Faulheit oder mangelndem Wissen oder Erfahrung) gerne mal "vergessen" wird.
Was aber definitiv stimmt:
Java bietet sehr viel weniger Funktionen als C/C++ oder C#, das ja auch immer komplexer wird.
Für jemanden, der nicht weiß, was er tut, mag deine Aussage also stimmen, denn das Fehlen dieser komplexen und schwierigen Features sorgt natürlich dafür, dass man sie nicht falsch oder missbrauchen kann. Bei C/C++ oder C# gibt's immer das Risiko, dass ein unerfahrener Entwickler irgendwo von einem Features liest und dann meint, es unbedingt nutzen zu müssen, dabei aber nur Probleme einbaut.
Das ist aber kein Argument für die Schönheit oder generell Qualität einer Syntax, es sagt nur aus, dass es leichter ist, Java zu meistern, im Gegensatz zu C/C++ und C#.
Aber natürlich ist die ganze Diskussion, ob eine Syntax gut ist oder besser zum Strukturieren von Code geeignet ist, völlig irrelevant, da es einzig und allein vom Können, der Erfahrung und der Zusammenarbeit der beteiligten Entwickler abhängt.
Es wird immer Leute geben, die es nicht tun, und eben deswegen ist Syntax, die dazu zwingt, ja so hilfreich
Die Syntax erzwingt aber nur ein paar wenige Punkte, während die Problematik - dass besagte Leute keinen Wert auf sauber strukturierten Code legen - noch sehr viel weiter geht.
Ich muss besagten Leuten also immer noch beibringen, wie sie sich an Coding Guidelines halten oder dass sie auf ordentlich strukturierten Code achten. Die paar Details, die die Syntax erzwingt, sind dabei das kleinste Problem, wirklich hässlich wird es bei Leuten, die z.B. random Code hin und her kopieren.
Mag sein, dass eine einfachere Syntax in gewissem Maß sauberen Code erzwingt, aber dieser Vorteil betrifft dabei nur einen winzigen Teil des tatsächlichen Problems. Gleichzeitig sorgt dieser Umstand aber auch für den gravierenden Nachteil, dass diejenigen, die damit umgehen können und wollen, in ihren Möglichkeiten eingeschränkt sind.
Wenn man nun damit rechnet, dass nur Idioten im Team sitzen - ok.
Ich persönlich würde mich damit aber nur ungern zufrieden geben, sowohl persönlich, als auch zum Vorteil der Firma.
Die Javasyntax — mehr als die anderer Sprachen — erzwingt ein gewisses Mindestmaß an Verständlichkeit von Code
Java kann einfach nicht so viel wie andere Sprachen.
Klar, man kann diese Features nicht falsch nutzen, richtig nutzen kann man sie aber auch nicht.
Ich denke da z.B. an die structs von C# und wie sie für vordefinierte Typen genutzt werden. Dadurch hat ein normaler int umfassende Funktionen, während ich in Java erst ein Integer-Objekt erstellen muss. Das finde ich z.B. unnötig umständlich.
Die Syntax von Java ist eindeutig die, welche Code am besten strukturiert (und daher fremden Code am ehesten verständlich macht).
Es gibt absolut unverständlichen C oder C++ Code, der — hätte man ihn in Java geschrieben — durchaus verständlich sein würde.
Du schreibst ja nicht selten fragwürdige Antworten, aber Java als am besten strukturiert zu bezeichnen geht echt langsam zu weit
Wer das glaubt, kann nicht wirklich Erfahrung in Code-Reengineering haben.
Weil das so gut funktioniert nutzen modernere Sprachen auch absichtlich keine Klassen, siehe Go oder Rust. Teilweise auch JS.
Komponenten basiertes Design ist wichtiger als eine Aufteilung in Klassen und oft flexibler wenn vernünftig programmiert als irgendwelche Klassen basierten Lösungen die oop-fetischisten manchmal raus hauen.
Da gebe ich Dir recht. Aber oben ging es ja wirklich nur um wünschenswerte Qualität der Syntax von Programmiersprechen.
Wie grtgrt ja schon schreibt: Hier geht's um die Syntax, nicht um OOP vs. Funktional ;)
Ich lasse die eigentliche Frage zur Syntax aber mal zurück und gehe auf deinen Kommentar ein:
Weil das so gut funktioniert nutzen modernere Sprachen auch absichtlich keine Klassen, siehe Go oder Rust. Teilweise auch JS.
Das ist kein Argument. Nur weil relativ neue Programmiersprachen (oder JS) keinen so strengen OOP-Ansatz verfolgen, wie z.B. Java, sind die nicht automatisch besser, sondern nur anders.
Beide Ansätze können gut sein, wenn man damit umgehen kann.
Perl ist meine persönliche Hölle (nicht generell, sondern aus eigener Erfahrung), aber es gibt sicher Leute, die super strukturierten und leicht verständlichen Code damit schreiben können.
Komponenten basiertes Design ist wichtiger als eine Aufteilung in Klassen und oft flexibler wenn vernünftig programmiert als irgendwelche Klassen basierten Lösungen die oop-fetischisten manchmal raus hauen.
Komponentenbasiertes Design ist ein Prinzip, wie man das Projekt strukturiert, Klassen sind ein Werkzeug. Das ist, als würdest Du sagen: Fachwerk ist wichtiger als Schrauben. (Kein guter Vergleich, aber ich hoffe, es wird klar, was ich meine)
Man kann auch mit Klassen ein gutes komponentenbasiertes Design entwerfen, man muss nur wissen, wie, genauso wie man wissen muss, wie man funktional ein gutes komponentenbasiertes Design nur entwerfen kann, wenn man weiß, wie.
Ich bin nicht mit der funktionalen Entwicklung "groß geworden", aber nach dem, was ich dazu gehört/gelesen habe (und wenn ich darauf aufbauend meine eigenen Erfahrungen einordne), würde ich sagen:
Man braucht beides, um ein gutes komponentenbasiertes Design aufzubauen. Man sollte sich nicht auf eines von beiden versteifen, sondern je nach Situation so arbeiten, wie es am besten passt.
Natürlich wird eine Sprache, die auf beiden Hochzeiten tanzt, wieder komplexer, als z.B. Java, das einen strengeren OOP-Ansatz verfolgt.
Du schreibst ja nicht selten fragwürdige Antworten, aber Java als am besten strukturiert zu bezeichnen geht echt langsam zu weit
Dabei teile ich aber deine Meinung. Nicht im Bezug auf frühere Antworten (dazu bräuchte ich einen größeren Überblick), aber im Bezug auf die Fragwürdigkeit dieser Antwort. Ich finde das sogar so unpassend, dass ich in meiner Antwort ausführlich darauf eingegangen bin.
Naja das worauf ich in dem Fall eingegangen bin war ja
Die Syntax von Java ist eindeutig die, welche Code am besten strukturiert
Wer das glaubt, kann nicht wirklich Erfahrung in Code-Reengineering haben.
Und spätestens da gings ja nicht mehr nur um Syntax
Das ist kein Argument. Nur weil relativ neue Programmiersprachen (oder JS) keinen so strengen OOP-Ansatz verfolgen
Naja, für OOP braucht man keine Klassen
sind die nicht automatisch besser, sondern nur anders.
Gut, sehe ich anders. Nicht weil ich Klassen jetzt unfassbar furchtbar finde, aber ich finde den Ansatz von Go und Rust einfach besser. Natürlich ist das nicht der einzig relevant Faktor einer Sprache, aber was das angeht find ich andere Konzepte tatsächlich besser.
Komponentenbasiertes Design ist ein Prinzip, wie man das Projekt strukturiert, Klassen sind ein Werkzeug. Das ist, als würdest Du sagen: Fachwerk ist wichtiger als Schrauben. (Kein guter Vergleich, aber ich hoffe, es wird klar, was ich meine)
Ja aber Klassen zu nutzen hat ja grundlegend die selben Ziele wie Code in Komponenten aufzuteilen. Es ist ja nicht so als würden Klassen in JS (gut da gibts die ja optional sogar auch), oop geht ja trotzdem noch. Mit Interfaces oder Traits wie sie in Go und Rust funktionieren wird eben größerer Wert auf Komposition gelegt und man ist etwas feier in dem wie man seinen Code aufbaut. Natürlich würde ähnliches auch in Sprachen mit Klassen funktionieren, ist eben nur umständlicher wenn so viel Wert auf Aufteilung in Klassen gelegt wird.
Bevor wir hier aneinander vorbei reden:
Meinst Du schwach typisiert? Also z.B. das Duck-Typing wie in JavaScript, dass man Objekte nicht anhand eines Typs definiert, sondern anhand der Eigenschaften?
Nicht wirklich, nein.
In Rust hast du Traits, quasi Interfaces.
In deinen Traits definierst du Methoden, in einem Struct natürlich data. Du kannst dann beliebig Traits für Structs implementieren. Duck Typing impliziert ja son bisschen checks zu runtime, das wäre ja genau das Gegenteil davon wie Rust designed ist, da sollen ja möglichst viele Fehler schon beim compilen gefunden werden.
Beispiel aus der Doku (https://doc.rust-lang.org/book/ch05-03-method-syntax.html)
#[derive(Debug)]
struct Rectangle {
width: u32,
height: u32,
}
impl Rectangle {
fn area(&self) -> u32 {
self.width * self.height
}
}
fn main() {
let rect1 = Rectangle {
width: 30,
height: 50,
};
println!(
"The area of the rectangle is {} square pixels.",
rect1.area()
);
}
In Go ist das ein bisschen ähnlicher zu duck typing, aber trotzdem noch statisch. Da wird dann ein Interface automatisch implementiert wenn man die entsprechenden Methoden für ein Struct implementiert.
Beispiel aus Wikipedia (https://en.wikipedia.org/wiki/Go_(programming_language)#Interface_system)
import "math"
type Shape interface {
Area() float64
}
type Square struct { // Note: no "implements" declaration
side float64
}
func (sq Square) Area() float64 { return sq.side * sq.side }
type Circle struct { // No "implements" declaration here either
radius float64
}
func (c Circle) Area() float64 { return math.Pi * math.Pow(c.radius, 2) }
Beide Sprachen haben also strong static typing aber keine Klassen im klassischen Sinne und Implementationen können nicht vererbt werden.
JS hat natürlich duck typing, aber da kommt oop ja eben über Prototypen statt Klassen (eigentlich, wie gesagt gibt ja class syntax).
Gut - hättest Du jetzt "Ja" geantwortet, hätte ich aufgegeben :D
Ich halte DuckTyping bei allem, was über "mal eben so ein Skript schreiben" hinaus geht, für grausam ...
Deine zwei Beispiele erinnern mich aber ein bisschen an die ExtensionMethods von C#, also eigentlich nur ausgelagerte Implementierungen von Methoden.
Das ist sicher eine nützliche Angelegenheit, aber wo liegt da der Vorteil im Vergleich zur "normalen" Klasse? Klar, man kann sie etwas flexibler trennen, aber ich wüsste nicht, wo ich das brauchen würde.
Klar, ich kann einem Typ nachträglich leichter eine Methode (und damit indirekt ein Interface) ergänzen, aber wenn das notwendig wird, dann sollte ich lieber schauen, ob meine Architektur noch aktuell ist oder ggf. überarbeitet werden muss.
Joa Duck Typing ist so ne Sache.
Das Rust Beispiel nutzt gar keinen trait sehe ich gerade, ist aber auch nicht so schlimm.
Genau, das ist flexibler. Und wo der Vorteil liegt sieht man schon an deinem Kommentar. Wenn du dir in so einem Fall überlegen musst ob deine Architektur noch aktuell ist und sie überarbeiten musst, dann ist sie nicht flexibel. Architekturen mit Inheritence können gut funktionieren, aber sie können auch schnell komplex werden groß wachsen und irgendwann nicht mehr mit neuen Anforderungen klar kommen.
Inheritance kann komplex werden bei großen Klassen oder vielen Vererbungen. Und wenn man sowieso konsequent composition nutzt, wofür braucht man dann noch Klassen, wenn eh alles was man macht Interfaces implementieren ist.
Architekturen mit Inheritence können gut funktionieren, aber sie können auch schnell komplex werden groß wachsen und irgendwann nicht mehr mit neuen Anforderungen klar kommen.
Ach dir geht's um die Vererbung, weniger um die Klassen an sich?
Dann haben wir die ganze Zeit aneinander vorbei geredet :D
Ja, Vererbung ist gefährlich und - wenn man es an den falschen Stellen nutzt - ein echtes Problem.
Deshalb würde ich aber nicht pauschal darauf verzichten.
Im kleinen Rahmen nutze ich Vererbung gerne, um Default-Implementierungen zu bieten, oder um in einer Ableitung etwas punktuell am Verhalten ändern zu können.
Aber egal wie ich es mache, der Rest vom Programm arbeitet immer gegen ein Interface, einfach nur, weil Interfaces flexibler sind und man Klassen in einer Vererbungshierarchie nur schwer herauslösen kann.
Also Vererbung ist definitiv ein wichtiger Punkt. Mir gefallen diese Konzepte generell, nicht aus einem einzelnen Punkt.
Klar gibt es andere Lösungen für die ganzen Vorteile, besser aufteilen -> partial, eigene Eigenschaften auf bestehde Typen erweitern -> Extension Methods um mal bei C# zu bleiben.
Aber ich finde einfach keine Klassen zu nutzen ist eben eine simplere, schönere Lösung.
Vererbung in Rust ist glaube ich tatsächlich etwas doof wenn man es mal doch braucht, ich meine die Lösung ist da macros zu nutzen.
JavaScript
Bin aber generell Fan von C-ähnlicher Syntax, also C, C++, Java, C#, …
Damit hast Du recht. Der Punkt ist nur: Es wird immer Leute geben, die es nicht tun, und eben deswegen ist Syntax, die dazu zwingt, ja so hilfreich: Die Javasyntax — mehr als die anderer Sprachen — erzwingt ein gewisses Mindestmaß an Verständlichkeit von Code (und insbesondere auch von Codedokumentation). Mir ist das mehrfach beim Re-engineering großer Mengen von Code im Vergleich mit C++ Code als sehr positiv aufgefallen.
Schönste Syntax ist für mich eine, die Code (von wem auch immer geschrieben) maximal gut verständlich macht.