der scheinbare ach so große Vorteil von Scala sind die vielen "magic" syntax sugar Teile drin. Ich gebe zu, dass dies erst mal verlocken ist.
Aber genau das ist das Problem an Scala: Code wird nun mal viel öfter gelesen als geschrieben! Und damit ist es v.a. wichtig, dass Code einfach und schnell zu lesen ist. Wenn man 5 (gute) Java-Entwickler an eine überschaubare Sache sezt, kann man sich fast sicher sein, dass sie alle fast identischen Code abliefern und ähnliche Design-Entscheidungen treffen. Und damit kann man sich ganz recht schnell in fremden Code einarbeiten. So etwas ist überlebensnotwendig in größeren Projekten!
Wenn du dagegen als Einzelkämpfer in deinem Keller werkelst, ist das natürlich egal - aber in zeiten von "agil" dürfte das nciht relevant sein.
Wie definierst du also Fortschritt?d ava war ein großer Fortschritt, weil es geschafft wurde, die sinnvollen Sachen drinzulassen, die Syntax einfach zu halten und v.a. Überflüssiges rauszuwerfen, um somit alles auf _eine_ gute Art und Weise machen zu können.
Das Gute ist einfach. Java ist einfach. Scala ist ein "ich wlll alles machen können" Teil. Scala ist dafür sicher nicht schlecht, das will ich nicht sagen, aber IMHO (!) haben die Java-Designer einen viel größeren Weitblick bewiesen. Wer das nicht einsieht, soll zu Scala gehen und seine Kollegen mit nicht mehr zu durchblickendem Code in den Wahnsinn treiben. Wer so etwas dann als "Fortschritt" ansieht, den kann man nicht als Entwickler ernst nehmen - bleib beim Fußball, Rudi!
Der Vorteil von Scala ist nicht syntaktischer Zucker, sondern die funtkionale Programmierung, die im Vorfeld viele Fehler verhindert. Ich arbeite viel mit Java und nicht alle guten Entwickler liefern gleichen Code ab, sondern auch extrem unterschiedlichen. Ich selbst zähle mich zu den sehr guten Entwicklern, weil ich viel über Muster, über Programmiersprachen und Compiler und insbesondere über Java weiß. Ich weiß leider auch, welche Fehler häufig gemacht werden und welche Fehler auch Profis machen.
Typische Fehlerquellen sind die impliziten Casts bei Java, von double nach long, von int nach long usw. Die Fehler werden oft nicht aus Unwissenheit, sondern aus Schussligkeit getan. Eine funktionale Programmiersprache kann das verhindern.
Haskell, SML, OCaml, F#, Clean, Erlang und Scheme sind auch funktionale Sprachen, und deren Syntax sieht nicht aus als hätte jemand seinen Perl Spaghetti-Code gerade wieder hochgewürgt und ausgekotzt um "Scala" zu produzieren.
Auf der JVM gibts Kawa, SISC und meinetwegen auch Clojure, wenn man auf Interop mit seinem Java-Krempel nicht verzichten will.
Die Frage ist aber auch, ob eine gute Dokumentation das Wett machen kann. Ich zum Beispiel bin ein großer Freund des Literal Programmings. Und ich denke, wenn man eine Sprache beherrscht, eine sauber Architektur hat und seinen Code gut dokumentiert, dann gibt es bezüglich der Lesbarkeit keine großen Probleme. Jedenfalls denke ich nicht, dass die Menge verfübarer Syntax einen so entscheidenen Einfluss hat. Prolog oder Lisp haben ja auch eine furchtbar simple Syntax (Horn-Klauseln oder lediglich Listen) und gelten auch nicht als „leichte” Sprachen.
Dazu haben kürzere Statements um in einer Sprache etwas auszdrücken mehrere Vorteile, bezüglich der Sicherheit des Codes, der Wartbarkeit, der Wiederverwendbakeit etc pp.
Das die Java Designer großen Weitblick bewiesen haben, würde ich anders sehen. Ich verstehe zum Beispiel bis heute nicht, warum sie ihr OO-Konzept durch primitive Datentypen versaut haben. Auch die große Menge an Boilerplate-Code in Java-Programmen ist nicht gerade ein Qualitätsmerkmal der Sprache.
Hallo Rudi,
der scheinbare ach so große Vorteil von Scala sind die vielen "magic" syntax sugar Teile drin. Ich gebe zu, dass dies erst mal verlocken ist.
Aber genau das ist das Problem an Scala:
Code wird nun mal viel öfter gelesen als geschrieben!
Und damit ist es v.a. wichtig, dass Code einfach und schnell zu lesen ist.
Wenn man 5 (gute) Java-Entwickler an eine überschaubare Sache sezt, kann man sich fast sicher sein, dass sie alle fast identischen Code abliefern und ähnliche Design-Entscheidungen treffen.
Und damit kann man sich ganz recht schnell in fremden Code einarbeiten.
So etwas ist überlebensnotwendig in größeren Projekten!
Wenn du dagegen als Einzelkämpfer in deinem Keller werkelst, ist das natürlich egal - aber in zeiten von "agil" dürfte das nciht relevant sein.
Wie definierst du also Fortschritt?d
ava war ein großer Fortschritt, weil es geschafft wurde, die sinnvollen Sachen drinzulassen, die Syntax einfach zu halten und v.a. Überflüssiges rauszuwerfen, um somit alles auf _eine_ gute Art und Weise machen zu können.
Das Gute ist einfach.
Java ist einfach.
Scala ist ein "ich wlll alles machen können" Teil.
Scala ist dafür sicher nicht schlecht, das will ich nicht sagen, aber IMHO (!) haben die Java-Designer einen viel größeren Weitblick bewiesen.
Wer das nicht einsieht, soll zu Scala gehen und seine Kollegen mit nicht mehr zu durchblickendem Code in den Wahnsinn treiben.
Wer so etwas dann als "Fortschritt" ansieht, den kann man nicht als Entwickler ernst nehmen - bleib beim Fußball, Rudi!
Hallo Xer,
meine Name ist Vudi, Vudi Röller.
Der Vorteil von Scala ist nicht syntaktischer Zucker, sondern die funtkionale Programmierung, die im Vorfeld viele Fehler verhindert. Ich arbeite viel mit Java und nicht alle guten Entwickler liefern gleichen Code ab, sondern auch extrem unterschiedlichen. Ich selbst zähle mich zu den sehr guten Entwicklern, weil ich viel über Muster, über Programmiersprachen und Compiler und insbesondere über Java weiß. Ich weiß leider auch, welche Fehler häufig gemacht werden und welche Fehler auch Profis machen.
Typische Fehlerquellen sind die impliziten Casts bei Java, von double nach long, von int nach long usw. Die Fehler werden oft nicht aus Unwissenheit, sondern aus Schussligkeit getan. Eine funktionale Programmiersprache kann das verhindern.
Haskell, SML, OCaml, F#, Clean, Erlang und Scheme sind auch funktionale Sprachen, und deren Syntax sieht nicht aus als hätte jemand seinen Perl Spaghetti-Code gerade wieder hochgewürgt und ausgekotzt um "Scala" zu produzieren.
Auf der JVM gibts Kawa, SISC und meinetwegen auch Clojure, wenn man auf Interop mit seinem Java-Krempel nicht verzichten will.
Niemand braucht "Scala".
Die Frage ist aber auch, ob eine gute Dokumentation das Wett machen kann. Ich zum Beispiel bin ein großer Freund des Literal Programmings. Und ich denke, wenn man eine Sprache beherrscht, eine sauber Architektur hat und seinen Code gut dokumentiert, dann gibt es bezüglich der Lesbarkeit keine großen Probleme. Jedenfalls denke ich nicht, dass die Menge verfübarer Syntax einen so entscheidenen Einfluss hat. Prolog oder Lisp haben ja auch eine furchtbar simple Syntax (Horn-Klauseln oder lediglich Listen) und gelten auch nicht als „leichte” Sprachen.
Dazu haben kürzere Statements um in einer Sprache etwas auszdrücken mehrere Vorteile, bezüglich der Sicherheit des Codes, der Wartbarkeit, der Wiederverwendbakeit etc pp.
Das die Java Designer großen Weitblick bewiesen haben, würde ich anders sehen. Ich verstehe zum Beispiel bis heute nicht, warum sie ihr OO-Konzept durch primitive Datentypen versaut haben. Auch die große Menge an Boilerplate-Code in Java-Programmen ist nicht gerade ein Qualitätsmerkmal der Sprache.