http://googlecode.blogspot.com/2011/10/ ... d-web.html
Was haltet ihr davon? Sieht auf den ersten Blick interessant aus. Sieht etwas Java-like aus, hat aber Operatorüberladung. Warum man der Meinung war obligatorische Semikolons verwenden zu müssen ist mir aber noch schleierhaft.
Google stellt Dart vor.
-
BlackJack
@Darii: Das Java-like schreckt mich ab. Ich nehme mal an der zweite Punkt in dem Blog-Artikel ist schuld: „Make Dart feel **familiar and natural** to programmers and thus easy to learn.” Wobei mit „programmers” wohl vorwiegend Java-Programmierer meint.
Wenn ich eine Sprache haben möchte, die JavaScript als Übersetzungsziel bietet, dann finde ich CoffeeScript ehrlich gesagt interessanter und schöner was die Syntax angeht.
Wenn ich eine Sprache haben möchte, die JavaScript als Übersetzungsziel bietet, dann finde ich CoffeeScript ehrlich gesagt interessanter und schöner was die Syntax angeht.
Ein paar Worte von #python.de zu Dart:
(Ich hab das etwas bereinigt (joins, parts etc. entfernt und alle "Zwischenkommentare")
Code: Alles auswählen
__doc__ | wee, google dart is draussen
mq | __doc__: ich hab bisher nicht so viel super-positives Feedback drüber gelesen
__doc__ | mq: kein wunder :) was hast gelesen?
mq | kA mehr wo, aber es klang im Wesentlichen nach "ziemlich unspannend, sehr Java-like, Vorteile unklar"
__doc__ | mq: "vorteile unklar"? :)
__doc__ | mq: bist du vertraut mit vectoren?
__doc__ | mq: so wie in var a = new Vec3(); o.ä.
mq | Naja, wird halt nicht schneller sein als JS, so lange das nicht nativ vom Browser unterstützt wird
__doc__ | mq: in javascript hast du kein operator overloading, d.h. wenn du zwei vektoren addieren willst: var c = a.add(b); in dart: var c = a+b;
mq | Und es ist unklar, wann das in Chrome kommt und ob irgendwer anders das machen will.
mq | Okay, das Argument seh ich.
__doc__ | mq: natürlich kommt das in chrome, und was anderes interessiert mich dran auch nicht.
__doc__ | mq: als nächstes, #import
__doc__ | mq: schreib mal ein grösseres programm in JS, was machst?
__doc__ | mq: <script src="foo.js"></script><script src="main.js"></script> usw.
__doc__ | mq: in dart: <script type="application/dart" src="main.dart"></script> und in main.dart #import foo
mq | Ja gut, wenn dich nur ein Browser interessiert, ist das was anderes als beim durchschnittlichen Webentwickler
__doc__ | mq: mich interessiert webgl :)
__doc__ | mq: was schon mal das feld auf FF und Chrome beschränkt
__doc__ | mq: und mich interessiert geschwindigkeit und strukturiertes programmieren --> dart
__doc__ | mq: ich hab die nase stupsvoll von JS für so zeug
__doc__ | mq: es gibt nen grund warums dart releasen 21 tage vor ihrer webgl new game konferenz :)
__doc__ | mq: weiterer vorteil: lambdas
__doc__ | mq: JS: somearr.sort(function(a,b){return a-b}); Dart: somearr.sort((a,b) => a-b)
__doc__ | mq: in JS macht man häufig chaining, also z.b. somearr.sort(function(a,b){return a-b}).filter(function(a){return
| a%2==0}).map(function(a){return a/1000})
__doc__ | mq: das wäre in dart: somearr.sort((a,b) => a-b).filter((a) => a%2==0).map((a) => a/100)
Code: Alles auswählen
dav1d | __doc__: unterstützt schon irgendwas dart?
__doc__ | dav1d: nope
__doc__ | dav1d: aber geplant ist Chrome/Firefox support
Code: Alles auswählen
__doc__ | dav1d: Dart is nich java like
__doc__ | dav1d: typing ist optional, klassensyntax war überfällig in JS (besser als var Foo = Class({...
__doc__ | dav1d: java hat keine anonymen blöcke
__doc__ | dav1d: und ich hab noch nicht probiert, aber ich vermute dart unterstützt auch anonyme klassen :)
__doc__ | dav1d: ausserdem generatoren und ein brauchbares concurrency primitive (nicht threads)
__doc__ | dav1d: Dart is ein amalgam aus: Ruby, Python, JS und CoffeeScript
__doc__ | dav1d: gut ich glaub die idee von interfaces kommt von Java
__doc__ | dav1d: aber musst ja nich benutzen wenn nich willst
the more they change the more they stay the same
lunar hat geschrieben:@Darii: Und was zeichnet diese Sprache jetzt aus?
- Keine lustigen JS-Features wie implizite Typumwandlungen, Variablen global per default, kein Packet/Modulsystem etc.
- Kompilierbar zu JavaScript also ca. 100% Browserkompatibilität
- dynamisch Typisiert
- optionale statische Typprüfungen
- Operatorüberladung
- Nebenläufigkeit über Actors (genannt Isolates)
Jetzt müsste dass nur noch brauchbar sein.Darii hat geschrieben:
- Kompilierbar zu JavaScript also ca. 100% Browserkompatibilität
-
lunar
@DasIch: Schließt Du auch aus der Länge des generierten Assembler-Quelltexts auf die Brauchbarkeit von C? Falls nein, dann wäre es vielleicht sinnvoll, zu erklären, warum Dart ob des offensichtlich großen Kompilats unbrauchbar sein soll. Es fällt mir eher schwer, da einen Zusammenhang zu sehen. Oder übersehe ich etwas offensichtliches, und es geht hier nicht um die schiere Größe der Ausgabe?
So what? Die Sprache ist noch in der Entwicklung, da hat die Optimierung des Compilers erstmal weniger Priorität. Und selbst wenn jQuery hat unkomprimiert auch 9000 Zeilen und da meckert keiner drüber.DasIch hat geschrieben:Jetzt müsste dass nur noch brauchbar sein.Darii hat geschrieben:
- Kompilierbar zu JavaScript also ca. 100% Browserkompatibilität
-
lunar
@DasIch: Komprimiert hat dieses Beispiel gerade mal ein paar Dutzend KB. Da kräht heute doch kein Hahn mehr nach… selbst bei mir auf dem Dorf, wo die Bits noch einzeln durch die Leitungen getragen werden.
Mein erster Eindruck von Dart war: Enttäuschend. Ich hatte mir mehr erhofft. Radikaler, neuer, etwas, das in 2011 passt und nicht wie 1995 aussieht. Also nicht einfach nur Java mit einem optionalen Typsystem.
Da man ja mit etwas positivem beginnen soll, bevor man kritisiert: http://try.dartlang.org/ finde ich ziemlich gut als Idee. An dem optionalen Typsystem, welches absichtlich nicht "sound" ist, habe ich auch nichts auszusetzen. Meine Erfahrung zeigt, dass man ansonsten immer bei etwas wie Scala landet und das ist so schwergewichtig, dass es den Preis nicht wert ist. Ich bin da völlig bei den Leuten, dass die Typen Dokumentation und Tool-Unterstützung verbessern sollen, aber nicht notwendig sind, um die Sprache schnell zu machen (das ist ein Mythos, den bereits ein Paper von 1995 oder so aus dem Self-Projekt widerlegen konnte).
Ich kann jedoch nicht verstehen, wieso eine moderne Sprache ihre Zeilen mit ";" beenden muss. Das Zeilen zu lang werden können, ist bitte ein Problem, was das Tooling lösen kann. Xcode bricht etwa lange Zeilen automatisch um: Problem gelöst. Das { } statt Einrückung für Blöcke benutzt wird, kann ich noch eher verstehen, weil sich derartiger Quelltext in Webseiten besser einbinden lässt. Und wenn ich in diesem Kontext mehr als eine Anweisung in eine Zeile quetschen will, dann in Gottes Namen auch ein ";", aber ansonsten...
Warum es aber keine Mehrfachzuweisungen oder List-Comprehensions gibt, verstehe ich nicht. Auf generelles Pattern Matching will ich ja gar nicht hoffen. Ansonsten sind es viele Kleinigkeiten: Muss es wirklich "static final" statt "const" sein? Warum ist das, was eigentlich der Standard sein sollte, "final" für Variablen, länger und umständlicher und hässlicher, als "var". Ich finde, hier hat Scala mit "val" und "var" es richtig gemacht. Das hätte natürlich erfordert, dass man Typen hinter die Variablennamen schreibt und das wollten sie wohl nicht, weil so die IDE nicht aus dem Typ einen Variablennamen vorschlagen kann. Andererseits: Will man das wirklich, was für Informationen bringt mir ein "Person person = new Person()"? Auch gefällt mir die Idee von Scala, neben "class" noch "object" zu haben, um Singletons zu definieren und gleichzeitig "static" aus der Sprache zu verbannen. Die Traits von Scala (und Self) hätte ich natürlich auch gerne gehabt. Und bitte die impliziten Interfaces von Go. Das ist IMHO die eine großartige Neuerung dieser Sprache, die es verdient, in jede andere aufgenommen zu werden. Statt Klassen-Objekte "callable" zu machen und auf "new" als Schlüsselwort zu verzichten, erfindet man lieber komische factory-Pattern in der Sprache und hat eine IMHO umständliche Konstruktor-Syntax. Alternativ hätte mir auch der Weg von Smalltalk, Objective-C und Ruby gefallen, dass man Klassenmethoden hat und dann eben "Person.new()" aufruft, um eine Person zu erzeugen.
Schade ist auch, dass Dart nicht JSON-kompatibel ist und es keines alternatives Serialisierungsmodell in der Sprache gibt. C# oder JavaFX (als es noch eine Sprache war) haben da IMHO eine schöne Syntax gefunden. Allgemein: Ein Weg, optionale Schlüsselwortparameter bequem typisieren zu können, wäre hilfreich.
Ich störe mich auch daran, dass es "num" und "String" gibt, nicht aber "Number" und "String" oder meinetwegen "num" und "str", aber jedenfalls bitte (!) alle Typen gleichartig benennen. Das hat Python schon verkorkst und auch bei Scala hat es gedauert, bis man sich dann auf alles beginnt mit einem Großbuchstaben geeinigt hat.
Wenn man schon ein Schlüsselwort "operator" braucht, um nicht-alphanumerische Methodennamen zu definieren, warum kann man dann nicht mit "operator eur(x)" auch mal einen Postfix-Operator für Währungen oder so definieren. Will sagen, die Sprache ist mir nicht ortogonal genug.
Und das ist eine "NullPointerException" gibt, ist ja wohl ganz großes Kino. Was soll der Scheiß? Hat man bei Java nicht schon gelernt, dass es keine "Pointer" in dieser Sprache gibt und "NullReference" oder "MissingObject" oder irgendwas anderes außer Null Pointer ein besserer Name wäre? Warum ist null überhaupt standardmäßig erlaubt? Standardmäßig würde ich ja erwarten, dass null nicht Teil eines Typs ist und man einen spezielle Vereinigungstyp "Foo | Null", meinetwegen als "Foo?" geschrieben braucht, um eine Variable zu definieren, die beides enthalten kann. Vereinigungstypen gehören IMHO eh in ein gutes Typsystem, denn häufig will man gerade im JavaScript-Umfeld (man schaue sich nur mal Jquery oder Ext an) verschiedene Typen verarbeiten können, die auch nicht die selben Enten sind.
Klar, Bracha und Bak (und die anderen, die an Dart arbeiten), können vieles noch ändern, aber wie gesagt, meine Erwartungen waren höher: Ich dachte, es ist ausgereifter und enthält neue Ideen statt einfach nur ein Java oder besser noch ActionScript-Clone zu sein. Da können sie auch gerne schon mal eine IDE basierend auf Eclipse gebaut haben oder eine eigene VM, die vielleicht sogar auf mobilen Geräten läuft. Wenn die Sprache nicht stimmt, ist mir das egal. Die Sprache zeigt IMHO die Vision und die ist ernüchternd: Wieso sollte man Dart benutzen, wenn es nicht wirklich oder nur marginal besser ist als Java, JavaScript, ActionScript usw. Das ist das gleich Problem wie mit Python 3. Das ist auch nicht besser gut im Vergleich zu Python 2.
Wo ist die Vision, dass man mit Dart z.B. in einer Sprache Server und Client-seitig arbeiten kann. Das sie auf dem Client in JavaScript kompilieren können, ist klar. Sever-seitig wäre es ein leichtes, in Java bzw. JVM-Bytecode zu übersetzen. Doch das wäre keine Priorität, sagt Bracha in der Mailing-List. Dabei wäre das eine Produkt-Strategie. Und genau diese sehe ich nicht klar formuliert. Ein "mal gucken, was passiert" ist mir zu wenig.
Stefan
PS: Diesen Schwachsinns-gist (inklusive der genauso sinnlosen Diskussion in den Kommentaren) der zeigt, dass Dart zur Zeit offenbar seine komplette Laufzeitbibliothek an jedes Programm anhängt, kommentiere ich nicht weiter. Das sich dieses leicht abstellen liesse, muss doch nicht weiter erwähnt werden.
Da man ja mit etwas positivem beginnen soll, bevor man kritisiert: http://try.dartlang.org/ finde ich ziemlich gut als Idee. An dem optionalen Typsystem, welches absichtlich nicht "sound" ist, habe ich auch nichts auszusetzen. Meine Erfahrung zeigt, dass man ansonsten immer bei etwas wie Scala landet und das ist so schwergewichtig, dass es den Preis nicht wert ist. Ich bin da völlig bei den Leuten, dass die Typen Dokumentation und Tool-Unterstützung verbessern sollen, aber nicht notwendig sind, um die Sprache schnell zu machen (das ist ein Mythos, den bereits ein Paper von 1995 oder so aus dem Self-Projekt widerlegen konnte).
Ich kann jedoch nicht verstehen, wieso eine moderne Sprache ihre Zeilen mit ";" beenden muss. Das Zeilen zu lang werden können, ist bitte ein Problem, was das Tooling lösen kann. Xcode bricht etwa lange Zeilen automatisch um: Problem gelöst. Das { } statt Einrückung für Blöcke benutzt wird, kann ich noch eher verstehen, weil sich derartiger Quelltext in Webseiten besser einbinden lässt. Und wenn ich in diesem Kontext mehr als eine Anweisung in eine Zeile quetschen will, dann in Gottes Namen auch ein ";", aber ansonsten...
Warum es aber keine Mehrfachzuweisungen oder List-Comprehensions gibt, verstehe ich nicht. Auf generelles Pattern Matching will ich ja gar nicht hoffen. Ansonsten sind es viele Kleinigkeiten: Muss es wirklich "static final" statt "const" sein? Warum ist das, was eigentlich der Standard sein sollte, "final" für Variablen, länger und umständlicher und hässlicher, als "var". Ich finde, hier hat Scala mit "val" und "var" es richtig gemacht. Das hätte natürlich erfordert, dass man Typen hinter die Variablennamen schreibt und das wollten sie wohl nicht, weil so die IDE nicht aus dem Typ einen Variablennamen vorschlagen kann. Andererseits: Will man das wirklich, was für Informationen bringt mir ein "Person person = new Person()"? Auch gefällt mir die Idee von Scala, neben "class" noch "object" zu haben, um Singletons zu definieren und gleichzeitig "static" aus der Sprache zu verbannen. Die Traits von Scala (und Self) hätte ich natürlich auch gerne gehabt. Und bitte die impliziten Interfaces von Go. Das ist IMHO die eine großartige Neuerung dieser Sprache, die es verdient, in jede andere aufgenommen zu werden. Statt Klassen-Objekte "callable" zu machen und auf "new" als Schlüsselwort zu verzichten, erfindet man lieber komische factory-Pattern in der Sprache und hat eine IMHO umständliche Konstruktor-Syntax. Alternativ hätte mir auch der Weg von Smalltalk, Objective-C und Ruby gefallen, dass man Klassenmethoden hat und dann eben "Person.new()" aufruft, um eine Person zu erzeugen.
Schade ist auch, dass Dart nicht JSON-kompatibel ist und es keines alternatives Serialisierungsmodell in der Sprache gibt. C# oder JavaFX (als es noch eine Sprache war) haben da IMHO eine schöne Syntax gefunden. Allgemein: Ein Weg, optionale Schlüsselwortparameter bequem typisieren zu können, wäre hilfreich.
Ich störe mich auch daran, dass es "num" und "String" gibt, nicht aber "Number" und "String" oder meinetwegen "num" und "str", aber jedenfalls bitte (!) alle Typen gleichartig benennen. Das hat Python schon verkorkst und auch bei Scala hat es gedauert, bis man sich dann auf alles beginnt mit einem Großbuchstaben geeinigt hat.
Wenn man schon ein Schlüsselwort "operator" braucht, um nicht-alphanumerische Methodennamen zu definieren, warum kann man dann nicht mit "operator eur(x)" auch mal einen Postfix-Operator für Währungen oder so definieren. Will sagen, die Sprache ist mir nicht ortogonal genug.
Und das ist eine "NullPointerException" gibt, ist ja wohl ganz großes Kino. Was soll der Scheiß? Hat man bei Java nicht schon gelernt, dass es keine "Pointer" in dieser Sprache gibt und "NullReference" oder "MissingObject" oder irgendwas anderes außer Null Pointer ein besserer Name wäre? Warum ist null überhaupt standardmäßig erlaubt? Standardmäßig würde ich ja erwarten, dass null nicht Teil eines Typs ist und man einen spezielle Vereinigungstyp "Foo | Null", meinetwegen als "Foo?" geschrieben braucht, um eine Variable zu definieren, die beides enthalten kann. Vereinigungstypen gehören IMHO eh in ein gutes Typsystem, denn häufig will man gerade im JavaScript-Umfeld (man schaue sich nur mal Jquery oder Ext an) verschiedene Typen verarbeiten können, die auch nicht die selben Enten sind.
Klar, Bracha und Bak (und die anderen, die an Dart arbeiten), können vieles noch ändern, aber wie gesagt, meine Erwartungen waren höher: Ich dachte, es ist ausgereifter und enthält neue Ideen statt einfach nur ein Java oder besser noch ActionScript-Clone zu sein. Da können sie auch gerne schon mal eine IDE basierend auf Eclipse gebaut haben oder eine eigene VM, die vielleicht sogar auf mobilen Geräten läuft. Wenn die Sprache nicht stimmt, ist mir das egal. Die Sprache zeigt IMHO die Vision und die ist ernüchternd: Wieso sollte man Dart benutzen, wenn es nicht wirklich oder nur marginal besser ist als Java, JavaScript, ActionScript usw. Das ist das gleich Problem wie mit Python 3. Das ist auch nicht besser gut im Vergleich zu Python 2.
Wo ist die Vision, dass man mit Dart z.B. in einer Sprache Server und Client-seitig arbeiten kann. Das sie auf dem Client in JavaScript kompilieren können, ist klar. Sever-seitig wäre es ein leichtes, in Java bzw. JVM-Bytecode zu übersetzen. Doch das wäre keine Priorität, sagt Bracha in der Mailing-List. Dabei wäre das eine Produkt-Strategie. Und genau diese sehe ich nicht klar formuliert. Ein "mal gucken, was passiert" ist mir zu wenig.
Stefan
PS: Diesen Schwachsinns-gist (inklusive der genauso sinnlosen Diskussion in den Kommentaren) der zeigt, dass Dart zur Zeit offenbar seine komplette Laufzeitbibliothek an jedes Programm anhängt, kommentiere ich nicht weiter. Das sich dieses leicht abstellen liesse, muss doch nicht weiter erwähnt werden.
JavaScript vielleicht, aber gerade da haben sie bei Dart ja eine bessere Idee und wollen nur den Bytecode bzw. einen "Heap Dump" der vorgeladenen App so wie das damals bei Smalltalk in Form eines "Image" vorlag, benutzen. Das verbessert signifikant die Startzeit, weil nix mehr übersetzt werden muss und das in der Regel kleiner ist als der Quelltext.DasIch hat geschrieben:Den generierten Assembler-Quelltext von C schickt man im Gegensatz zu Javascript eher selten durchs Internet, dementsprechend ist die Größe von letzterem wesentlich interessanter.
Ob sie dann allerdings eine Form von Bytecode-Verifikation wie bei Java machen wollen oder so ein Image kryptografisch signieren: Keine Ahnung.
Natürlich blöd für alle Cargo-Cult-Programmierer ist dann, dass da kein Quelltext mehr zum Kopieren (und Lernen) ist. Was dem einen sein Nachteil, ist dem anderen natürlich sein Vorteil, denn manchmal möchte man den Quelltext ja auch nicht für jedermann offenlegen. Das AngryBirds für ihre HTML-Version GWT gewählt haben, ist sicherlich nicht nur ihre Liebe für Java, sondern auch der Umstand, dass da ziemlich unleserliches JavaScript rausfällt.
Stefan