Warum diese Versuche, Scala mit Xtend und Kotlin zu verwässern? [geschlossen]

26

Jetzt bietet Eclipse Xtend und JetBrains Kotlin an - beides scheint verwässerte Versionen von Scala zu sein. Meine Frage ist warum? Ich habe ein bisschen mit Scala gespielt und es ist nicht so schwer. Ist dies nur eine Reaktion auf die inhärente Schwierigkeit des Sprunges vom Imperativen zum Funktionalen oder ist hier noch etwas anderes am Werk?

EDIT: Entschuldigung. Wenn ich die Frage noch einmal lese, wie ich sie ursprünglich gepostet habe, kann ich sehen, wo es sich ein bisschen nach Trolling anhört. Die Art und Weise, wie ich die Frage formuliert habe, schien einfach die beste Art zu sein, die Frage zu stellen. Ich habe Blogpostings gesehen, die den Effekt "Scala ist zu hart / Scala ist zu komplex" und auch "Kotlin ist ein Versuch, Scala zu machen, aber einfacher" hatten. Ich werde die Formulierung so lassen, wie sie ursprünglich war, aber ich habe ehrlich gesagt nicht versucht, zu trollen.

programming-languages scala Onorio Catenacci
quelle
20
Es scheint mir ziemlich verrückt zu sein, einfach anzunehmen, dass eine neue Sprache, die etwas mit Scala zu tun hat, eine "verwässerte Version von Scala" sein muss, die von Leuten geschrieben wurde, für die Scala zu hart ist. Wenn Sie die Frage so stellen, ist es weniger wahrscheinlich, dass Sie überlegte Antworten erhalten.
Michael Borgwardt
8
Assembly ist nur eine verwässerte Version des Maschinencodes, oder?
Ben Brocka
6
@ BenBrocka: Nein, es ist isomorph zu Maschinencode;)
4
Scala ist großartig. Ich glaube, die Leute sollten auf Java-Nekromantie verzichten und die Neuerfindung von Fahrrädern aufgeben (all diese neuen Sprachen, erwähnt und nicht) und einfach Scala verwenden und verbessern. MEINER BESCHEIDENEN MEINUNG NACH.
Ivan
2
@ MichaelBogwardt ein fairer Punkt. Ich stütze mich auf das, was ich in der Blogosphäre gesehen habe. "Scala ist zu hart" und "Scala ist zu komplex" scheinen relativ häufige Beschwerden zu sein.
Onorio Catenacci

Antworten:

39

IMHO von jemandem, der in den letzten 7 Jahren in Java programmiert hat und meine stärkste Sprache ist, finde ich Scala ziemlich fremd und es fällt mir schwer, mich daran zu gewöhnen.

Xtend fühlt sich eher wie Java an und konnte damit viel schneller eine einfache Anwendung schreiben. Zugegeben, ich habe mir nicht genug Zeit für Scala genommen, aber ich verstehe auf jeden Fall, warum manche davon abgeschaltet werden.

Wenn dies gesagt ist, werden die Menschen eine vertraute Hölle einem unbekannten Himmel vorziehen.

maple_shaft
quelle
19
+1: "Menschen werden eine vertraute Hölle einem unbekannten Himmel vorziehen".
Giorgio
18

JetBrains hat eine Wiki-Seite , die Scala mit Kotlin vergleicht, und es scheint ein paar Dinge zu geben, die Kotlin tut und Scala nicht:

  • Null-Overhead-Null-Sicherheit. Scala hat Option, ein syntaktischer Wrapper zur Laufzeit
  • Intelligente Besetzungen
  • Statische Erweiterungsfunktionen. Anstatt zur Laufzeit zu wickeln
  • Kotlins Inline-Funktionen ermöglichen nichtlokale Sprünge
  • String-Vorlagen. Es gibt ein Compiler-Plugin von Drittanbietern für Scala mit ähnlichen Funktionen: ScalaEnhancedStrings
  • Erstklassige Delegation. Auch über das Plugin eines Drittanbieters implementiert: Autoproxy-Module

Kotlin eine Verwässerung der Scala zu nennen, ist wahrscheinlich eine große Vereinfachung. Ich denke, Xtend richtet sich hauptsächlich an X-Text-Benutzer und nicht an ein breiteres Publikum. Ein wesentlicher Unterschied zu Scala besteht darin, dass Xtend nicht in Bytecode, sondern in Java kompiliert wird.

Eine andere "Java Killer" Sprache, die Sie Ihrer Liste hinzufügen sollten, ist Red Hats Ceylon , obwohl ich keine Ahnung habe, ob und wie es mit Scala verglichen wird.

yannis
quelle
13
Automatische Casts klingen beängstigend.
Jonas
14
Die Branche hat diese zyklischen Revolutionen, in denen Entwickler immer wieder von einem Extrem ins andere gehen. Leistungsstarke Programmiersprachen waren gut, dann schrieben Idioten schlechten Code und wir fanden die Gefahren, so dass die Leute zur wahrgenommenen Sicherheit von Java strömten und nun wieder zu Power-Programmierern zurückkehrten. Schauen Sie sich an, wie gut Javascript und browserbasiert waren, dann kamen Applets und RIA mit Browser-Plugins und schlecht Javascript, dann kamen moderne AJAX-Frameworks und Plugins waren unsicher und schlecht, dann kam Silverlight und die Leute sagten, AJAX sei tot, JETZT HTML5 ist wieder vogue und plugins schlecht! :)
maple_shaft
3
@Jonas Ich weiß nicht einmal, ob ich damit einverstanden bin , aber es ist ein Phänomen, das ich bemerkt habe. Mit jeder Umdrehung kommt sicher eine ausgefeiltere Lösung, aber jede Lösung hat immer eine Achillesferse. Die Lösung des Heel-Problems lässt einige auf frühere Lösungen für Ideen zurückblicken, aber mit der Zeit vergessen die Leute, warum diese alten Lösungen ursprünglich aufgegeben wurden. Im Laufe der Zeit wird die Ferse jedoch mit jeder Umdrehung kleiner. Java + XTend ist sicherlich nicht so ausgereift wie Scala, die Probleme sind jedoch geringer als die Investition, vollständig auf eine neue Sprache umzusteigen.
maple_shaft
2
@Jonas Nun, nur eine extrem starke Vereinfachung der technologischen Entwicklung würde in einen Kommentar passen. Ich stimme jedoch maple_shaft zu, die technologische Evolution hat ein iteratives Gefühl .
Yannis
3
@Jonas diese Besetzung ist keine automatische, sondern eine intelligente Besetzung: Wenn Sie sich das ansehen, werden Sie feststellen,
cy6erGn0m
11

Ich verwende Scala seit einem Jahr als meine Hauptsprache (mit Java als zweitwichtigster Sprache, beides innerhalb einer großen älteren Java-Codebasis). Ich muss immer noch ziemlich grundlegende Funktionen nachschlagen, wenn ich sie in a nicht verwendet habe während. Sicher, Sie können einige Scala schnell schreiben, aber es ist eine äußerst funktionsreiche Sprache und es dauert lange, bis Sie sie beherrschen.

Darüber hinaus ist seine Komplexität nicht nur ein Problem für den Menschen, sondern auch für IDEs und Compiler. Sowohl Celyon als auch Kotlin kompilieren direkt, um JavaScript ziemlich sauber zu machen. Scala kann JavaScript über GWT erzeugen, obwohl die Anreise kompliziert ist und die GWT-Ausgabe weder lesbar noch für die Wiedergabe mit externem JavaScript oder HTML geeignet ist.

In Scala bin ich definitiv produktiver als in Java, und der Code ist kompakter und leserlicher (wenn Sie ein wenig Scala kennen). Aber seine Komplexität lässt mich zögern, ihn anderen zu empfehlen. Eine Sprache mit 20% der Komplexität, aber 80% der Fähigkeiten wäre eine willkommene Alternative.

[Bearbeitet, um Erwähnung von Legacy-Code zu entfernen, siehe Kommentar unten.]

[Nachtrag 2017: Scala unterstützt jetzt JavaScript als Build-Ziel, während Kotlin weiterhin Funktionen hinzufügt, die für einen Scala-ähnlichen Java / Groovy / JavaScript-Ersatz sinnvoll sind. Sie sind jetzt markantere Sprachen als zu der Zeit, als ich das geschrieben habe.]

David Leppik
quelle
Könnten Sie bitte den "Lagacy-Teil" etwas näher erläutern? Welche Methoden verwenden Sie zum Beispiel eher für Listen als für Seqs?
Kiritsuku
Ich werde das editieren, da die Standard-Scala-Bibliothek das eigentlich selten macht. JSONArray erstellt eine Liste, die meisten Konstruktoren jedoch nicht. Ungeachtet dessen besteht in der Dokumentation immer noch eine Tendenz zu Listen, zumal Programming in Scala, 2nd Edition, nur Scala 2.8 abdeckt, das älter ist als Vectors. Und seine Codebeispiele haben in der Regel Konstruktoren, die List nehmen, wo Seq besser wäre.
David Leppik
Ja, für 2.10 sind einige Dinge besser ( +:zum Beispiel Extraktoren). Ich hoffe, dass die Programmierung in Scala in naher Zukunft aktualisiert wird. Für 2.11 verbessern sich einige Dinge weiter. Die stdlib ist bereits von Verfall befreit und wird auch etwas schrumpfen. Vielleicht scala.util.parsingwird es auch außerhalb von stdlib verschoben. Wir werden sehen ...
kiritsuku
1
Ich sollte hinzufügen, dass mein eigentliches Problem mit Lists vs. Vectors darin besteht, dass das Hinzufügen von Elementen zu einer Liste (dh Seq in Scala) eine sehr grundlegende Operation ist, und es gibt zu viele äquivalente Möglichkeiten, dies zu tun, alle mit komischen Symbolen, die schwer zu tun sind merken. Der kanonische Weg ist ::, ::=oder +:=welche voranstellen, aber die meisten Leute wollen :+=welche anhängen, aber das ist für eine Liste nicht effizient.
David Leppik
10

JetBrains hat seine Ziele für Kotlin sehr klar formuliert :

Wir wollen produktiver werden, indem wir zu einer ausdrucksstärkeren Sprache wechseln. Gleichzeitig können wir keine Kompromisse hinsichtlich der Java-Interoperabilität eingehen (die neue Sprache wird schrittweise eingeführt und muss reibungslos mit der vorhandenen Codebasis zusammenarbeiten) oder der Kompilierungsgeschwindigkeit (die Kompilierung unserer Codebasis dauert lange genug javac, und wir können es uns nicht leisten, es langsamer zu machen). Das Nächste ist auch ziemlich einfach: Wir erwarten, dass Kotlin den Umsatz von IntelliJ IDEA steigern wird.

Michael Borgwardt
quelle
8

Ich habe Scala einige Monate in Eclipse mit Play Framework verwendet. Ich mag die Sprache, aber es gibt auch Dinge, die ich nicht mag.

Für mich ist der Grund, von Java zu einer anderen Sprache zu wechseln, produktiver.

Bisher war ich mit Scala nicht produktiver. Ein Grund ist der Mangel an guter Unterstützung für Scala in Eclipse, das Scala-Plugin ist schlecht (z. B. Einrücken schlägt fehl) und hat noch nicht viele Funktionen (z. B. keine "Open Call Hierarchy"). Der Scala-Compiler ist ebenfalls langsam, dies ist möglicherweise kein Problem, aber ich verwende Scala mit Play Framework, das den Code für jede Anforderung kompiliert, und dabei ist die Compilergeschwindigkeit wichtig.

Jonas
quelle
2
Vielleicht haben Sie nicht genug Scala-Redewendungen gelernt. Ich habe Scala für kleine Projekte (Tools) verwendet und bin in Scala viel produktiver als in Java, obwohl ich in Java (> 10 Jahre) viel mehr Erfahrung habe als in Scala (<2 Jahre).
Giorgio
4

Ich weiß nichts über Kotlin, aber Scala und Xtend sind zwei sehr unterschiedliche Bestien.

Im Gegensatz zu üblichen Sprüchen ist Scala KEIN besseres Java. Scala ist eine viel umfangreichere Sprache als Java, mit eigener Syntax und Semantik und einem eigenen Paket von Basisbibliotheken.

Xtend ist ein besseres Java. Es behält die Java-Semantik bei und verbessert die Syntax. Jede Zeile Xtend-Code kann direkt in eine Reihe von Java-Codezeilen übersetzt werden. Es gibt auch keine zusätzliche Laufzeit.

Ich denke, dass beide Ansätze richtig sind, obwohl sie unterschiedlich sind. Ich mag Scala (als Sprache) nicht, aber ich mag es nicht, Scala-Gläser zu meinen Projekten hinzuzufügen. Ich kann Scala in Android auch nicht richtig verwenden (es führt zu Gewichts- und Leistungsproblemen). Xtend ist nicht so gut ausgestattet, aber für mich ist es in Ordnung (es ist viel wert, es als Java-Sprache zu verwenden) und es funktioniert auf jeder Plattform, als würde ich direkt in Java schreiben.

Ich glaube, dass beide Sprachen unterschiedliche Nischen abdecken und koexistieren können, ohne sich gegenseitig zu stören. Meiner Meinung nach ist Scala einfach zu komplex und fügt nichts Neues hinzu. Wenn Sie mehr Funktionalität und weniger OO möchten, wählen Sie einfach eine der vielen einfacheren funktionalen Sprachen wie Clojure oder JHaskell. Wenn Sie nur Java mit einer besseren Syntax und ein bisschen funktionaler Programmierung wollen, wäre Fantom genauso gut wie Scala (es ähnelt C # sehr).

Aber ich finde, Xtend ist ein süßer Punkt zwischen all diesen Sprachen. Es fügt all die syntaktischen Muster hinzu, die ich für Java wollte, und behält die guten Teile von Java (seine Semantik) bei. Betrachten Sie es als Coffescript für Java.

Und der Eclipse-Support ist hervorragend ...

Ivan Hernandez
quelle
… Und es wird nur in Eclipse unterstützt. Recht? Und Eclipse ist eine Hölle ...
Sarge Borsch
Xtend hat eine zusätzliche Laufzeit. Über 3MB habe ich zuletzt nachgesehen.
mm2001
@ mm2001 Ja, es gibt Abhängigkeiten: ca. 300 Ko für xtend und 2 Mo für guava für mein kleines Testprojekt ( github.com/pdemanget/examples/tree/master/xtend/message-send ) Aber es ist keine Laufzeit, das sind zusätzliche Klassen für Dinge wie InputOutput, die zusätzlichen Annotationen. Es wird mir nicht der Hauptgrund genommen, dass Scala und Xtend zwei sehr unterschiedliche Sprachen sind, wie in dieser Antwort erwähnt.
pdem