Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Mir erschliesst sich die Logik deines Blogposts nicht. Genauso haette man vor ein paar Jahren mit Scala argumentieren koennen. Haette man das dann befolgt, gaebe es heute kein Scala.
Was macht dich traurig, wenn sich jemand freiwillig hinsetzt und sich ne neue Programmiersprache ausdenkt? Ich geh mit, wahrscheinlich wird sich keine der drei genannten Sprachen auf Dauer durchsetzen. Genauso wie ich das ueber Scala denke (aber das ist nur meine kleine Meinung - ich will hier blos kein sinnfreies Gebashe lostreten). Aber das ist doch nicht schlimm. Wenn sich nur eine von 100 neuen Sprachen durchsetzt find ich das gut. Nur so kann doch Neues entstehen.
ich stimme schalentier bzgl des Blogposts vollkommen zu. Klingt etwas nach beleidigten Kind dem man Gefahr nimmt das Spielzeug wegzunehmen. Da hattest du schon bei weitem bessere...
auch sonst stimme ich dem Beitrag von schalentier zu - ob wie sich etwas durchsetzt wird man sehen.
Mir erschliesst sich die Logik deines Blogposts nicht. Genauso haette man vor ein paar Jahren mit Scala argumentieren koennen. Haette man das dann befolgt, gaebe es heute kein Scala.
Verstehe ich nicht. Ich habe überhaupt nichts gegen neue JVM-Sprachen. Aber eben "neu" im Sinne "gibt es noch nicht". Scala was damals neu, und hat damit einen Standard für Innovation gesetzt - wenn man in eine bestimmte Richtung gehen will. Sprachen wie Fantom, Clojure, Mirah, Ioke u.s.w. tun das auch, nur in andere Richtungen. Aber Gosu, Ceylon und Kotlin spielen nur mit den vorhandenen Lego-Steinchen herum und versuchen sich an ein paar Mikro-Optimierungen, wobei sie aber meilenweit hinter ihrem Original zurückbleiben. Die Argumentation, mehr könne man den armen Programmierern nicht zumuten, hat zu Javas Stagnation geführt. Und viele sind ja anscheinend mit dieser Stagnation zufrieden - damit habe ich kein Problem. Aber was ich für ein Problem halte, ist mit ein paar Versatzstücken diejenigen, die Innovation wollen, zu locken, und dann auf halbem Wege stehenzubleiben - und das wo es schon eine vielleicht nicht perfekte, aber bewährte und funktionierende Lösung gibt. Das ist einfach unnötig, und es ist schade um Aufwand, der am Ende vergebens sein wird. Stattdessen hätte man Scala besser machen können. Natürlich kann niemand sagen, ob es sich endgültig durchsetzen wird, aber die Vorzeichen sehen viel, viel besser aus als für seine Möchtegern-Epigonen.
Am meisten ärgert mich wohl die "Scala ist komplex"-Gebetsmühle, und das gerade von Leuten, die es eigentlich besser wissen müssten. Scala ist komplex, keine Frage, aber das ist vom Standpunkt eines Anwendungsprogrammierers völlig irrelevant. Selbst in Java ist das so: Fast jeder in diesem Forum kann [c]List[/c] oder [c]Map[/c] korrekt verwenden, aber kaum einer könnte korrekten generischen Code schreiben, wenn es nur ein wenig schwieriger wird. Ich habe meinen Kollegen Schnipsel aus meiner highJ-Bibliothek gezeigt, und sie haben mich angeschaut, als hätte ich Erdnussbutter auf der Stirn. Und der Witz ist, dass ich Generics auch nicht in allen Details verstehe, und immer wieder über neue Dinge stolpere.
Das Problem an den Sprachen, denen man eine hohe Innovation zuschreibt ist jedoch, dass diese es sehr schwer haben sich im kommerziellen Bereich durchzusetzen. Damit meine ich nicht diese super modernen Firmen wie Google, Facebook, Twitter, etc. (die jedoch nahezu ausschließlich Websites für den Massenmarkt machen) sondern die klassischen IT-Firmen/IT-Beratungen, die für einen Kunden SW entwickeln.
Bei einer derartig neuen und andersartigen Sprache muss zuerst eine gewisse Reife auftreten, dann braucht man genügend Entwickler, die das ganze schreiben/lesen können (und damit meine ich eben nicht nur die Basics). Dazu kommt dann noch Tooling und evtl. weitere Infrastruktur (Application/WebServer etc.).
Insofern kann ich den Punkt den die drei Sprachen versuchen sehr gut verstehen. Hier ist es (ähnlich wie bei Groovy) sehr schnell möglich einen Java-Entwickler dran zu setzen (zumal diese Sprachen "klassischen" Java-Code ja zumeist 1:1 kompilieren) und diese können dann an Stellen die sie wirklich stören die neuen Features nutzen). Zudem ist die Kompatibilität zu Altcode bei diesen Sprachen natürlich unwahrscheinlich hoch.
Im Akademischen Umfeld muss ich dir zu 100% Recht geben, da sind Innovative Sprachen sicherlich sinnvoller.
Insofern kann ich den Punkt den die drei Sprachen versuchen sehr gut verstehen. Hier ist es (ähnlich wie bei Groovy) sehr schnell möglich einen Java-Entwickler dran zu setzen (zumal diese Sprachen "klassischen" Java-Code ja zumeist 1:1 kompilieren) und diese können dann an Stellen die sie wirklich stören die neuen Features nutzen). Zudem ist die Kompatibilität zu Altcode bei diesen Sprachen natürlich unwahrscheinlich hoch.
Am meisten ärgert mich wohl die "Scala ist komplex"-Gebetsmühle, und das gerade von Leuten, die es eigentlich besser wissen müssten. Scala ist komplex, keine Frage, aber das ist vom Standpunkt eines Anwendungsprogrammierers völlig irrelevant. Selbst in Java ist das so: [..] Schnipsel aus meiner highJ
der Unterschied ist dass bei Scala selbst die aller einfachsten Code-Beispiele irrsinnig aussehen,
ob nötig oder nicht, vielleicht wird einem das nur von den Experten extra unter die Nase gerieben
Simple Examples
A list of simple Scala snippets[!], useful to understand some basics of the language [!], as well as to see what Scala code looks like.[!]
in Java gibts im einfachen Maßstab Generics, ja,
aber dass eine List<String> eine Liste für Strings ist, versteht man ja noch,
und dann die anonymen inneren Klassen, auf die man außer als ActionListener für Buttons selten stößt,
also eher nicht am Anfang
wenn Kotlin einfachen Code produziert, dann ist das ja schon etwas sympatischer,
auf dieser Seite hier: Basic syntax walk-through - Kotlin - Confluence
sehe ich beim Scrollen überwiegend angenehmes,
in den ersten Sekunden fällt mir nur die unsägliche unnötige Umstellung "Variablenname : Typ" +
das anscheinend unvermeidbare neuere switch-Konzept a la
Code:
fun cases(obj : Any) {
when(obj) {
1 => print("One")
"Hello" => print("Greeting")
is Long => print("Long")
!is String => print("Not a string")
else => print("Unknown")
}
}
auf, schlimm genug, aber erstmal immerhin so dosiert, dass man(ch einer) die Sprache nicht gleich komplett abschreibt
Na ja, einfach liegt im Auge des Betrachters. Jemand, der bereits Erfahrung in funktionalen Sprachen hat dürfte die "einfachen" Code-Beispiele auch wirklich einfach finden, zumindest vom Verständnis was der Code macht. Für jemanden aus der imperativen Ecke sind die Beispiele natürlich schweren nachzuvollziehen. Wobei ich auch nicht genau verstehe wie auf der Seite die Einteilung der Codes in "simple" und "advanced" getroffen wurde - da ist vieles noch von 2008, sollte man vllt. mal überarbeiten.
Closures und Higher-order functions sollen doch mit Java8 auch kommen, ursprünglich waren sie sogar für Java7 angekündigt. Das erhält doch mittlerweile in jede Sprache Einzug, langfristig wird also niemand drumherum kommen sich das anzugucken.
die angesprochene "Scala ist komplex"-Gebetsmühle und das Zielpublikum von Java, von Kotlin, von der Welt allgemein
sind eben gewiss nicht die Leute mit 'Erfahrung in funktionalen Sprachen'
Closures und Higher-order functions sollen doch mit Java8 auch kommen, ursprünglich waren sie sogar für Java7 angekündigt. Das erhält doch mittlerweile in jede Sprache Einzug, langfristig wird also niemand drumherum kommen sich das anzugucken.
Könnte man auch so ausdrücken: Mal sehen was wirklich reinkommt, hat man ja schon mehrmals angekündigt bzw. es wurde schon öfters phantasiert darüber, was wirklich reinkommt.
Bis dahin kann sich immer viel ändern, speziell welche Features gerade gehyped werden bzw. was gerade unerlässlich, wichtig und nützlich erscheint.
Aber eben "neu" im Sinne "gibt es noch nicht". Scala was damals neu, und hat damit einen Standard für Innovation gesetzt - wenn man in eine bestimmte Richtung gehen will.
Was ist denn "neu" im Sinne von "gibt es noch nicht". Man koennte es so betrachten, dass es keine Sprache gibt, die irgendwie neu im Sinne von "gab es noch nicht" ist. Oder auch andersrum, alle Sprachen sind irgendwie neu.
Die Idee hinter Scala ist, so wie ich es verstanden hab, dass man quasi alle bekannten und unbekannten Sprachelemente in einer Sprache vereint. Irgendwie kann man ja auch neue Konzepte per Plugin dazu nehmen. Also sind die einzelnen Features von Scala auch nicht neu. Gabs alles schonmal und wurde mit Scala zusammengefuehrt.
Kotlin dagegen will: "make it way simpler than the most mature competitor – Scala.". Eben nur ein paar Dinge, die der Erfinder fuer sinnvoll haelt.
Fuer mich ist klar und hier schliess ich mich auch einem Grundgedanken von Linux an: Jedes Tool (Sprache, Programm, App, ...) sollte genau eine Sache richtig gut koennen. Soll heissen, wenn ich einen Teil meiner Anwendung funktional machen moechte, weil ich z.B. eine sehr hohe Skalierbarkeit bzgl. der vorhandenen CPU/Kerne haben moechte, nehm ich Erlang. Will ich eine Webanwendung ohne extrem grosse Komplexitaet bauen, nehm ich Ruby (on Rails). Will ich eine stabil laufende Desktopanwendung nehm ich Java/Swing. Will ich hochperformanten Code fuer ne Spieleengine schreiben, nehm ich C++ und GLGS. Ich brauch keine Sprache, die alle koennen will.
Ob Kotlin irgendwann mal fuer irgendwas sinnvoll sein koennte, weiss ich jetzt noch nicht. Aber da ich Jetbrains Fanboi bin, werd ich ein Auge drauf werfen ;-)
Noch zu dem hüschen implicits-Beispiel. Es ist einfach sehr knapp geschrieben. Wenn man eine eigene Klasse verwendet, sollte es schon viel "normaler" aussehen:
Code:
class ArrayWrapper[A:ClassManifest](array:Array[A]) {
def sort(p: (A, A) => Boolean) = {
util.Sorting.stableSort(array, p)
array
}
}
object implicits extends Application {
implicit def arrayWrapper[A : ClassManifest](a: Array[A]) = new ArrayWrapper(a)
val array = Array(2, 3, 1, 4)
println("array = "+ array.sort((x: Int, y: Int) => x < y).mkString)
}
Zuerst haben wir eine Klasse, die eine sort-Methode definiert. Die Sort-Methode nimmt zum Vergleichen eine übergebene Vergleichsmethode p - genau wie in Java ein Comparator übergeben würde (und das sieht erst furchtbar aus, wenn es inline definiert wird). Dann haben wir eine implizite Umwandlung von unserem Array zum Wrapper - ganz einfach. Danach kann ich die im Wrapper definierte Methode auch für Arrays verwenden, wie auch gezeigt wird.
Die Notwendigkeit, ein ClassManifest zu benutzen, ergibt sich aus Type Erasure im Zusammenhang mit der haarsträubenden Implementierung von Arrays in Java, bei anderen Typen wie List wäre das nicht notwendig.
Der wichtigste Punkt ist aber, dass der ganze Code bis auf die letzten zwei Zeilen normalerweise in einer Bibliothek verborgen ist, und das einzige, was der Nutzer sieht ist, dass das Array auf einmal eine sort-Methode hat.
So ist es mit vielen Beispielen, die bei näherer Betrachtung eher harmlos sind. Ich sehe hier jedenfalls keinen Wahnsinn, nur Code.
ja wie nun, ist 'Implicits' ein wichtiges Feature der Sprache welches man ständig programmieren will, dann ist es sichtbar,
oder soll es versteckt werden, wozu ist es dann da?
du magst sicherlich zwischen einfachen Grundlagen und darüber hinaus möglichen Erweiterungen unterscheiden,
aber letztere spielen nunmal die Musik, gerade auch um sich von normalen Java zu unterscheiden?,
nimmt man als neue Beispiel Links wie Scala (programming language) - Wikipedia, the free encyclopedia
oder Scala (Programmiersprache) ? Wikipedia
dann sind die quasi ersten Beispiele jeweils gleich funktionales Quicksort
Java kann nicht viel, aber das ist eher ein Vorteil als ein Nachteil,
imperativer Ansatz (überzeugend, nicht nur 'auch dabei'), grundsätzliches OO mit Vererbung usw. vorhanden + sauberes einfaches Codebild,
das sind Trümpfe
ja wie nun, ist 'Implicits' ein wichtiges Feature der Sprache welches man ständig programmieren will, dann ist es sichtbar,
oder soll es versteckt werden, wozu ist es dann da?
Implicits sind auf jeden Fall ein wichtiges Feature, ohne Implicits wäre Scala viel weniger flexibel, und vor allem hätte man keine Möglichkeit, Java-Klassen typsicher "aufzubohren".
Was das Verstecken angeht, kommt es ganz darauf an. Für Anfänger ist es wahrscheinlich erst einmal besser, implicits nur zu benutzen, und nicht selbst zu schreiben. Kann man ein Framework wie Lift nutzen, wird das auch viele nützliche implicits mitbringen. Will man selbst eine Bibliothek oder sogar eine DSL schreiben, wird man dagegen um eigene Implicits nicht umhinkommen. In normalen Code würde ich sie nur sehr sparsam einsetzen, nämlich dort, wo man anders nicht weiterkommt, wo eine bestimmte Umwandlung sehr oft benötigt wird und wo sie spezifisch genug sind (man kann sich ja leicht ausmalen, dass z.B. eine allgemeine Umwandlung A -> Option[A] oder String -> Int eine ganz schlechte Idee ist).
Implicits sind eines der "schweren Geräte" im Werkzeugkasten: Gut, dass man sie hat, aber nicht dazu da, um jede Mücke damit zu erschlagen. Ähnliches gilt auch für Pseudo-Operator-Überladungen, Higher-Kinded Types, Strukturelle Typen und Extraktoren. Man bekommt recht schnell ein Augenmaß dafür, wann sich der Einsatz lohnt.
Man kann jetzt online mit Kotlin herumspielen: Kotlin Web Demo
Die Syntax kommt mir durchaus "harmonischer" vor als etwa bei Ceylon, es gibt ein paar nette Features und es dürfte da keine großen Einstiegsschwierigkeiten geben. Trotzdem wirkt die Sprache auf mich ideenlos, denn wirklich alles was über Java hinausgeht, findet sich fast 1:1 so bei Scala (mit Ausnahme von String-Interpolationen, die es dafür in so ziemlich jeder anderen Sprache - angefangen bei Perl - gibt). Es fehlen einfach die echten Killer-Features (Closures sind es jedenfalls nicht mehr, denn Oracle wird es nicht wagen, die bei Java 8 auszulassen), aber wer weiß, vielleicht kommt ja noch etwas interessantes...
Interessant, mein erster Gedanke war: "Hui, das is ja wie Ruby, nur direkt in der JVM". Zudem sagen die JetBrains Leute ja, dass Kotlin ein Scala Ersatz darstellt - dass man dann dort Scala Features findet, ueberrascht mich jedenfalls nicht. Bin ich froh, dass es noch keine Moeglichkeit gibt, Ideen zu patentieren/schuetzen. ;-)
Das Killerfeature koennte sein, dass es von Anfang an eine super IDE als Bonus oben drauf gibt.
. Und sie scheint auch echt spaß zu machen:
