Was halten Java-Entwickler von Scala? [geschlossen]


19

Ich habe festgestellt, dass die IDE-Unterstützung bei weitem nicht so gut ist, aber die Sprache selbst unterstützt funktionale Programmiersprachen viel sauberer.


3
Python ist meine Religion, daher interessiert mich nur, was Guido von Scala hält. neopythonic.blogspot.com/2008/11/scala.html
Job

7
Scala ist eine so großartige Sprache, dass sie nicht nur all diese großartigen Köpfe der Scala-Community anzieht, sondern auch viele neidische Hasser, die versuchen, im Grunde alles zu finden , um die Sprache und die Leute, die sie verwenden, anzugreifen.
soc

@soc: Nur um klar zu sein: Ich hasse Scala nicht und die Leute, die es benutzen, sollten sich wahrscheinlich weniger darum kümmern, was ich darüber denke. Ich finde es zu komplex. Das ist alles. Komplexität kann für diejenigen, die ein großes Gehirn haben, in Ordnung sein. Ich nicht :-)
Joonas Pulakka

3
Es tut mir leid, ich ärgere mich nur, wenn Leute immer wieder Mythen wiederholen, ohne ihre Behauptungen zu stützen.
Soc

2
@soc: Nun, diese ganze Frage ist völlig subjektiv, daher ist jede Antwort richtig, ob Mythos oder nicht.
Joonas Pulakka

Antworten:


18

Ich programmiere Scala jetzt seit mehr als einem Jahr, also versuche ich, mich ein Jahr zurückzusetzen, um diese Frage zu beantworten.

  • Scala-Code ist prägnanter als Java-Code (kein Setter oder Getter, viele Typinformationen können abgeleitet werden)
  • Die integrierte Unterstützung für XML-Literal ist sehr ansprechend.
  • Die Kompatibilität und Interoperabilität mit Java-Bibliotheken ist großartig
  • Die Unterstützung bestimmter funktionaler Redewendungen ist erfrischend (zum Verständnis, Schließen, Lambda-Funktionen, Karte, Falten, Reduzieren).
  • Es scheint keine coole Funktion zu geben, die der Sprachentwickler nicht einbeziehen wollte

Die obigen Punkte waren mehr oder weniger das, was ich von Scala hielt, bevor ich anfing, es zu lernen.

Im Laufe eines Jahres habe ich Folgendes herausgefunden:

  • Der Kauf des Treppenbuchs war eine großartige Investition und ersparte mir stundenlanges Lernen
  • Die Syntax hat einige Macken und manchmal war ich wirklich verwirrt, warum etwas nicht gültig war. Sobald Sie mit dem Code vertraut sind, ist der Code übersichtlicher und einfacher zu lesen. Beachten Sie, dass dies kein wirkliches Problem ist, wenn Sie Code lesen und nicht schreiben.
  • Die Sammlungsbibliothek in 2.8 ist eine Freude zu benutzen. Es ist schwer, auf Java zurückzukommen.
  • XML-Literal ist nett, aber abgesehen von einigen grundlegenden Dingen musste ich mich an das Ökosystem der Java-Bibliothek wenden. Es ist aber bequem.
  • Die Verwendung von Java-Bibliotheken von Scala ist sehr einfach und bequem. Die Verwendung von Scala-Klassen aus Java ist etwas kniffliger, funktioniert aber.
  • Ich habe auf die IntelliJ IDEA Community Edition umgestellt und obwohl sie nicht perfekt ist, ist sie mehr als gut genug.
  • Der Ersteller der Sprache hat sich wirklich Gedanken über die Funktionen gemacht und alles funktioniert sehr gut zusammen. Die objektorientierte Unterstützung ist besser als in Java (mit den Merkmalen) und Sie können funktionale Programmierung durchführen.
  • Es ist eine Sprache, die anscheinend einige Java-Entwickler leidenschaftlich hassen. Für mich hat es die Freude am Programmieren zurückgebracht.

21

Nun, ich denke Scala ist zu komplex. Es fühlt sich an wie C ++, da es eine Vielzahl von unterschiedlichen Methoden zur Ausführung von Dingen hat. Einige würden dies "Reichtum", "Ausdruckskraft" oder "Kraft" nennen, aber Ihre Laufleistung kann variieren. In vielen realen Projekten müssten Sie künstlich einschränken, welche Sprachfunktionen Sie verwenden möchten und welche nicht, damit alle beteiligten Entwickler dieselbe Teilmenge der Sprache sprechen können.

Für die funktionale Programmierung bevorzuge ich Clojure , das viel einfacher als Scala ist.

Lass den heiligen Krieg beginnen ;-)


2
Wenn sich nur Rich Hickey genauso für .Net interessieren würde wie für JVM ...
Job

Es wäre hilfreich, wenn Sie uns etwas näher erläutern würden, welche Dinge Ihrer Meinung nach zu komplex sind.
Richard Warburton

4
@Richard Warburton: Die Fragen der Komplexität von Scala (oder, wie Martin Odersky sagt, "Stärke und ein Problem von Scala: seine Erweiterbarkeit") wurden in vielen Foren ausführlich diskutiert. Eine solche Diskussion ist hier . Ich sage nicht, dass der Komplex per se schlecht ist . Das Problem ist, dass zwar die klügsten 1% der Programmierer in der Lage sind, mit Scala Wunder zu vollbringen, die überwiegende Mehrheit es aber einfach nicht "versteht", und das ist ein Problem für die reale Welt. Es ist wie mit einem Formel-1-Auto: Die überwiegende Mehrheit der Menschen wird einfach nicht in der Lage sein, ein solches Biest zu fahren.
Joonas Pulakka

2
+1 Für die Erwähnung von Clojure als gültige Alternative (wenn es um funktionale Programmierung geht).
Oliver Weiler

Clojure ist großartig, aber genauso performant wie Scala? Ist das Refactoring ohne diese statische Eingabe so einfach? (Das Refactoring von Python ist zum Beispiel ziemlich schwierig - ich habe Refactorings dafür geschrieben.)
9000

13

Vor ungefähr einem Jahr, als ich immer frustrierter über die Zukunft der Produkte meines Startups wurde, wenn ich weiterhin Java verwendete, entschloss ich mich, Scala auszuprobieren. Ich habe zu der Zeit bereits in JavaScript und Python programmiert, Ruby war auch eine gute Alternative, aber ich suchte nach einer statisch typisierten Sprache, vorzugsweise einer, die auf der JVM ausgeführt werden kann.

Ich habe wirklich versucht, Scala zu mögen, aber ich fand den Code äußerst hässlich und schwer zu verstehen. Ich wunderte mich dramatisch, dass wenn Scala unsere beste Antwort auf Java war, ich mit Sicherheit verarscht und verurteilt wurde, mit einer Sprache weiterzuarbeiten, die ich doch nicht mochte ...

Glücklicherweise erfuhr ich wenig später von Fantom . Oh Mann, habe ich es geliebt? Für mich war es Amerikas Glanzantwort auf die deutsche Bürokratie! Es entsprach den Anforderungen, die ich in Scala suchte, aber viel eleganter . Es hatte Vim- , Eclipse- und Netbeans- Integration, ein nettes Web-Framework , ausgereifte Produkte , eine kleine, aber unglaublich hilfreiche Community ... Dynamische und statische Typisierung! Ich freute mich!

(Ich könnte weitermachen, aber dieser Beitrag soll sich mit Scala befassen, nicht mit Fantom, also höre ich hier auf. Meine Präferenz ist klar , trotzdem gibt es diesen Beitrag , der die beiden miteinander vergleicht. Ich konnte nie verstehen, warum Fantom im Vergleich zu Scala so wenig Aufmerksamkeit erhält. Aber anscheinend bin ich nicht der Einzige, wenn Sie diesen Podcast [ mp3 ] bis zum Ende anhören .)


9

Als ich mich vor 2 Jahren mit Scala beschäftigte, sah es für mich fremd und einschüchternd aus. Irgendwann stellte ich fest, dass die Kernsprache tatsächlich viel einfacher ist als Java, aber ihre Syntax und Semantik so flexibel sind, dass Sie neue Sprachkonstrukte wie diese erstellen können, auch ohne eine Makrofunktion. Seitdem bin ich für alle meine Java-Projekte vollständig auf Scala umgestiegen, weil ich damit ohne zu viel Code schreiben kann.

Ich mag Clojure, aber es gibt Situationen, in denen die Plattform das Kompilieren von statischem Bytecode (Android, Applets, ...) erfordert, und während Sie dies tun können, ist es in Scala einfach da.

Während Sie mit Scala viele Probleme funktional lösen können, finde ich häufig Probleme, bei denen sich die Verwendung von Klassen natürlicher anfühlt. Das macht die Dinge etwas komplexer, aber bei weitem nicht die Komplexität und die Schmerzen von C ++.

Der größte Vorteil für mich, als ich anfing, die Sprache zu lernen, war, dass ich so programmieren konnte, wie ich es in Java getan habe, nur ohne das Rauschen (ein bisschen wie beim Starten von Groovy), aber irgendwann möchten Sie versuchen, tiefer in die Macht einzutauchen der Sprache - sie wächst mit dir.

Über die IDE-Frage: Nachdem ich Emacs für alles verwendet hatte, verschwanden alle meine IDE-Probleme :-)


9

Ich mag Scala aus vielen Gründen, aber es gibt einen, der oft übersehen wird: seine Einfachheit.

Scala ist vielleicht nicht so einfach wie Oberon, aber es ist viel einfacher als einige andere Sprachen. Die Scala-Sprachspezifikation umfasst ca. 160 Seiten, die Java-Sprachspezifikation ca. 600 Seiten (nur die Sprache, nicht die JVM oder die Bibliotheken!), Die ECMA-334 C # -Sprachspezifikation (die AFAIK einer Teilmenge von Visual C # 2.0 entspricht) ~ 440 Seiten (das sind keine Informationen wie das Verständnis von LINQ-Abfragen, Lambda-Ausdrücke, Erweiterungsmethoden, generische Co- und Contravariance dynamic, optionale Argumente mit Standardwerten, Schlüsselwortargumente usw. var). Selbst der aktuelle Entwurf für ECMAScript 5.1 ist mit ~ 210 Seiten größer. Und natürlich meine eigene "Standard" -Sprache, Ruby, deren aktueller ISO-Entwurf ~ 310 Seiten umfasst und die nur eine fast unbrauchbar kleine Teilmenge der Schnittmenge von Ruby 1.8.6, 1.9.1 und 1.9.2 angibt.


6
Die Anzahl der Seiten in der Sprachspezifikation ist ein interessantes Maß für die Komplexität. Es ist erstaunlich, wie Scala die Meinungen darüber teilt. Niemand würde sagen, Python ist komplex oder C ++ ist einfach, aber Scala scheint beides zu sein :-) zB scala-lang.org/node/7431
Joonas Pulakka

Sie können komplexe Dinge mit der Sprache erstellen, und einige sehen aus, als wären sie die Sprache - Methoden mit Nicht-Alnum-Namen, die wie eine Überladung von Operatoren aussehen, was zum Beispiel nicht der Fall ist.
Benutzer unbekannt

2
Die Anzahl der Seiten in der Sprachspezifikation ist eine SCHRECKLICHE Möglichkeit, die Komplexität zweier Sprachen zu vergleichen. Um nur zwei Beispiele zu nennen: Die Java-Spezifikation ist fast als Tutorial geschrieben, während die Scala-Spezifikation sehr knapp gehalten ist. Oder ein anderes Beispiel, C # 2.0 war tatsächlich ungefähr so ​​komplex wie Java heute oder vielleicht ein bisschen komplexer angesichts der "unsicheren" Maschinen, Delegierten und Eigenschaften. Wie Sie jedoch bemerken, ist die C # 2.0-Spezifikation kleiner als die von JLS.
James Iry

1
Nun hat Martin Odersky die Größe der formalen Grammatik der Sprachen verglichen. Das ist ein vernünftiges Maß für einen Aspekt der Komplexität. Aber es ist nur sinnvoll, weil Grammatiken nicht so flexibel sind wie Englisch. Auch dann muss man vorsichtig sein. Genau wie bei gewöhnlichen Programmen können Sie Grammatiken leicht strecken oder verkleinern, wobei Sie verschiedene Möglichkeiten haben, wie sie angeordnet werden sollen, wie viele verschiedene Produktionen enthalten sein sollen, welche grundlegenden Zeichenklassen anzunehmen sind usw.
James Iry

3
warte was ? Warum sollten Sie versuchen, die Komplexität anhand der Größe der Spezifikation zu messen? Es ist eine schreckliche Idee.
Smartnut007

9

Das ist scheiße an Scala:

  • Der Nullzeiger war anfangs eine ziemlich schlechte Idee. Hoare nannte es seinen "Milliarden-Dollar-Fehler", aber Scala ist noch schlimmer. Es hat Objekte mit den Namen null, null, none und null. null ist für die Interoperabilität mit Java. Null ist der Nullzeiger der W3C-DOM-Spezifikation, Keine ist das, durch das Null ersetzt werden sollte, und Nil ist ein leeres Element.

  • Wenn sich Sprachkonstruktionen als hacky herausstellen, ist es normalerweise der Programmierer, der die Schuld trägt und nicht die Sprache. In Scala enthält die Kernsprache jedoch bereits Bibliotheksklassen, deren einziges dokumentiertes Verhalten "Dies ist ein Hack" ist. Glaubst du es nicht? Durchsuchen Sie das scaladoc nach scala.xml.Group.

  • Last not least ist Scala schlecht dokumentiert. Kaum eine der Scala-Klassen in der offiziellen Dokumentation enthält Beispielcode. Scala ist bedeutend schwerer zu erlernen als Java und erfordert fundierte Kenntnisse in der Informatik.

Um nicht mit einem Scala-Hasser verwechselt zu werden, liebe ich Folgendes:

  • Ich habe weniger Ausnahmen. Ich hatte nie eine ClassCastException und sehr wenige NullPointerExceptions bei der Interaktion mit Java.
  • Code ist viel kürzer und prägnanter als Java
  • Es ist intellektuell herausfordernd. Java fühlt sich im Vergleich wie Babysprache an.

10
nullist Javas Nullzeiger, Nullist der "Typ" davon. Noneist ein möglicher "Zustand" Option[T]einer Sammlung mit einem oder null Elementen. Nilist eine leere Liste. Es klingt zwar beängstigend, ist es aber nicht. Diese Typen sind nicht austauschbar oder austauschbar und verhalten sich genau so, wie sie sollten.
soc

9

Scala ist komplex. Daran führt kein Weg vorbei! Die Syntax ist äußerst flexibel und kann auf zahlreiche Arten angepasst werden (vor allem Operatoren / Infix-Notation) - und das Typsystem bietet mehr verschiedene Funktionen als jede andere Sprache, die ich kenne.

Die Dinge sind also nicht so einfach wie zB in Haskell: Typeclasses, um sie alle abzudecken.

Während Scala versucht, funktionale Programmierung, OO, prozedurale Programmierung und Java-Bibliotheken sowie eigene Ideen zusammenzustellen, entstehen schließlich viele Konzepte , die irgendwie "in die gleiche Richtung" zu gehen scheinen:

  • Implizite Werte
  • Implizite Funktionen
  • Existentials
  • Platzhalter
  • Züge
  • Schnittstellen
  • Abstrakte Klassen
  • Fallklassen
  • Strukturtypen
  • Allgemeine Einschränkungen
  • Grenzen anzeigen
  • Anonyme Typen

Die Wahl zwischen ihnen scheint zunächst schwierig zu sein, und man könnte sich leicht fragen, ob man für ein Problem die richtige Lösung gefunden hat . Es ist sogar leicht möglich, durch Missbrauch von implicits hackiges Zeug zu produzieren .

Aber das Interessante ist: Scala funktioniert. Es ist manchmal schwer zu verstehen, warum (insbesondere herauszufinden, durch welche impliziten Konvertierungen + Vererbung + ... ein Objekt Funktionalität hat X), aber Sie müssen sich die meiste Zeit nicht darum kümmern.

Schreiben Sie Scala so einfach wie möglich und es wird funktionieren. Lassen Sie sich nicht von allem verwirren, was möglich ist, und verwenden Sie nur das, was Sie brauchen. Und wenn Sie etwas brauchen, können Sie sicher sein, dass Scala es irgendwie hat;)

Und je besser Sie werden, desto mehr können Sie Scala mit Operatoren, Impliziten, Monaden, Funky-Syntax anpassen ... und schließlich etwas in der Nähe eines DSL finden, das Ihr Problem perfekt angeht.

Schließlich haben Sie immer die Möglichkeit, Scala als viel besseres Java mit einer saubereren, einfacheren Syntax, Typinferenz und einigen funktionalen Merkmalen zu verwenden.


1
"Vor allem Operatoren / Infixnotation" - nur dass es an Operatoren mangelt. :) Es sind nur Methoden.
Benutzer unbekannt

6

Es ist eine ausgezeichnete Sprache, die in vielerlei Hinsicht einfacher ist als Java.

Die meisten Leute werden es nicht mögen, ob Java-Programmierer oder nicht, aus den gleichen Gründen, wie die meisten Leute, ob Programmierer oder nicht, nicht gerne neue Programmiersprachen lernen. Ich vermute, dass die meisten Leute, die eine Programmiersprache gelernt haben, das gar nicht gern gelernt haben.

Wenn Sie sich Sorgen machen, dass eine Sprache so kompliziert ist wie C ++, würde ich Clojure wie die Pest vermeiden. Das Wimmern, dass Scala komplizierter ist als Clojure, ist zum Ausweichargument für Menschen geworden, die eine oder beide Sprachen nicht kennen.

Clojure verfügt über Makros, dh Sie können die Syntax der Sprache beliebig ändern, sodass Sie nicht nur "unzählige verschiedene Arten, Dinge zu tun", sondern auch eine nahezu unbegrenzte Anzahl von Arten, Dinge zu tun. Und keine dieser neuen Syntaxen, die die Programmierer mit den Makros erstellen, wird irgendwo in der Sprachspezifikation dokumentiert.

"Wir können jedoch die Verwendung von Makros vermeiden oder festlegen, welche Makros in unserem Code zulässig sind", sagen Sie. Herzlichen Glückwunsch, Sie müssen jetzt "künstlich begrenzen, welche Sprachfunktionen Sie verwenden werden und welche nicht", und genau das haben die plappernden Idioten, die Clojure of Scala verwenden, als Grund herangezogen, Scala zu meiden.


6
Vielen Dank für Ihren Beitrag zu Scala vs Clojure, aber ist es das, worüber ich wirklich nach dem OP frage?
Martin Wickman

Interessanter Punkt bezüglich: Makros. Auch ein wenig besorgniserregend. Gibt es in Scala Makros oder ähnliches, oder ist die ganze "künstliche Begrenzung" eine Ablenkung?
Armand

1
Dies scheint eher ein Kommentar zu meiner Antwort als eine Antwort auf die ursprüngliche Frage zu sein. Ich stimme dir zu, Makros geben dir unendliche Macht, wenn sie falsch verwendet werden, saugen sie. Sie sollten sie also richtig verwenden (nur bei Bedarf). Dies ändert nichts an der Tatsache, dass Clojure die Sprache eine der einfachsten ist, die es gibt. Scala ist definitiv nicht.
Joonas Pulakka

> Dies ändert nichts an der Tatsache, dass Clojure eine der einfachsten Sprachen ist. <Dies ist auch völlig falsch, es sei denn, Sie verwenden eine Metrik wie "Anzahl der Sprachkonstrukte". Wenn Sie etwas Nützliches verwenden, zum Beispiel, wie einfach es ist, Programme in der Sprache zu lesen und zu schreiben, gehört Clojure nicht zu den einfachsten.
Josh

Machen Sie also bitte weiter und geben Sie uns ein gutes Maß für die Sprachkomplexität. "Wie einfach es ist, Programme in der Sprache zu lesen und zu schreiben" ist völlig subjektiv , daher hilft es hier nicht wirklich. Zugegeben, es ist praktisch unmöglich, eine nützliche und objektive Metrik zu finden. (Jörg W Mittag unten verwendet beispielsweise die Anzahl der Seiten in der Sprachspezifikation als Maß für die Komplexität. Ich bin mir zwar objektiv, aber nicht sicher, ob dies sehr nützlich ist.)
Joonas Pulakka

4

Ich mag die granulareren Typen der Scala-Bibliothek sehr. Anscheinend war die neue Sammlungsbibliothek gut durchdacht. Ich mag auch, wie es die Menge an Code reduziert, die für einfache Klassen erforderlich ist, und die funktionalen Konzepte, die es hinzufügt. Auch die Typinferenz ist sehr hilfreich. Es fühlt sich an wie Java ohne die Stützräder. Nach einer Weile mit C # fühlt sich Scala tatsächlich wie ein Konkurrent, wobei Java immer noch nützlich ist, aber zurückgelassen wird.


2

Als Java-Programmierer fand ich Scala zunächst interessant. Nachdem ich mich jedoch eine Weile damit beschäftigt hatte (und auf fast alle von anderen gelisteten Positiven / Negativen gestoßen war), fühlte ich mich sehr "meh" gegenüber. Die Sprachverbesserungen werden durch die geringere Verfügbarkeit von Toolsets ausgeglichen. Ich konnte mir einfach keinen entscheidenden Grund für einen Umstieg einfallen lassen. Es ist gut, aber nicht "besser genug", um einen Wechsel zu rechtfertigen. Hat auch diesen subjektiven Aufregungsfaktor nicht (wie Clojure scheint).

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.