Dart - structured Web Language (neue Programmiersprache)

[Poke646]

Warum diskutiert ihr hauptsächlich um Performance? Auf dieser Seite des Threads geht es fast um nichts anderes...

Dart wurde primär sicherlich nicht entworfen, weil man bei Google der Meinung war, JS sei zu langsam. Man wollte eher eine moderne und schönere Sprache auf die Beine stellen, und das ist wohl ohne Zweifel auch gelungen. Wenn man sich durch deren Docs wühlt geht es fast nie um Performance, das war kaum das Ziel.

Google hat nicht vor, Dart aggressiv zu vermarkten. Aber JS hat nunmal einige Defizite, die sie aufzeigen wollen. Falls sich JS weiterentwickeln würde, so wäre das auch ok.

At the same time, Google is also placing bets that JavaScript can be evolved as needed, and contributing to that work. Google wants web development to be great, and if that happens with JavaScript, we're happy.

 

[ice-breaker]

Weil irgendwer damit angefangen hat ^^

Und in dem Moment wo Dart nur noch nach JavaScript transpiliert, kann ich praktisch jede Sprache nehmen, z.B. CoffeeScript oder Haxe. Letzteres existiert schon lange und ist Dart sehr ähnlich. Oder ich kompiliere PHP nach JavaScript, hat irgendein "Verrückter" mittlerweile auch gebaut, dem sind keine Grenzen gesetzt. Oder die in JavaScript implementierte RubyVM damit man Ruby verwenden kann.
Wer der Meinung ist eine bessere Sprache statt JavaScript verwenden zu wollen hat jetzt schon viele Möglichkeiten. Da brauchen wir kein Google, die noch eine neue Sprache versuchen zu etablieren statt sich um das zu kümmern, was sie schon haben (Google Go).

 

[Dese]

@ice-breaker:
ich kürz das mal ab: nichts an meinem post klingt provokativ in der richtung man solle doch dart js vorziehen wegen performance gründen. da bist du uas einer falschan erwartungshaltung auf den holzweg geraten. schau dir meinen post noch einmal an. passiert

ich habe mich nämlich gar nicht über dart selbst geäussert. wie könnte ich auch, hab von dart so gut wie keine ahnung.

aber ich widerspreche wehement der aussage, dass der ressourcenbedarf bei js allein aufgrund dämlicher programmierer zurück zu führen wäre. dann wären nömlich ALLE ausnahmslos dämlioche programmeirer.

wir haben hier denke ich ein mißverständnis. ich sehe bei js zwei probleme, eines ist weniger ein problem von JS selbst (also der sprache) ein anderes aber sehr wohl:

ich fang mit dem 2.ten an:
js erlaubt verschiedene dinge möglichst einfach umzusetzten, so dass man sich als programmeirer nicht viel gedanken drumm machen muss. das problem von sprachlich unterstützten vereinfachung die sehr weit gehen ist immer, dass sie im allgemeinen ressourcen kosten, wenn man sie zu viel verwendet. schlimmer ist es, wenn es für spezielle zwecke keine oder nur vergleichsweise sehr unbequeme möglichkeiten gibt effizient zu programmieren.

compiler können so etwas nur begrenzt abdecken. das ist ein problem was im allgemeinen alle script-sprachen haben, adaptive datentypen, mächtige impliziete transformationen und operationen auf strings... ja, da wird oft sehr viele strings umgewälzt und speicher verwendet wo das gar nicht nötig ist, weil es das sprachdesign es einem sehr einfach macht (im übrigen auch ein recht großes problem bei java selbst) und effiziente alternativen entweder kaum vorhanden oder nur umständlich vorhanden sind.

hinzu kommt, dass meiner erfahrung nach web-entwickler weit weniger ahnung von ressourceneffizienter programmierung haben (auch profis). warum das so ist sei mal dahin gestellt. ich weiß, das wird so manchen hier provozieren.

zu ersterem:
ob js, dart oder buxdehude ist ne frage von sprachdesign und damit impliziete lenkung des entwicklers zu effizienter programmierung. was einfach geht wird häufiger verwendet und gemacht.
aber, es gibt noch ein ganz anderes problem: ganze document object model selbst. die representation eines dokuments wie es so mal definiert wurde ist in so vielerlei hinsicht problematisch umgesetzt. du magst zwar mit js primitive operationen schön flott ausführen können, aber der umgang mit speicherintensiven komplexen dom instanzen ist überhaupt nicht mehr effizient, wegen der implemtierung des dom selbst.

laggende dropdown menues, laggende js scripte und anwendungen sehe ich jeden tag. die performance ist unter aller sau bei dem meisten was ich mit js sehe, in relation gesehen zu dem was es eigentlich nur machen soll. mir schient wir haben da ganz unterschiedliche wahrnehmungsschwellen. schau dir mal die cpu auslastung an beim navigieren und benutzen von rel. einfachen seiten mit js-scripten. das ist lächerlich!

aber nein, dart wird daran auch nichts ändern, z.m. nicht an diesem punkt.

 

[carom]

@ice-breaker

Klar gibt es längst Alternativen, aber du scheinst dich nur für die Sprache an sich zu interessieren. Dart bringt noch allerlei anderes Zeug mit wie ein einfach zu benutzendes DOM-Interface und ebenso einfache Socket/IO Funktionalität für die Serverseite. Coffescript und ähnliches sind hingegen quasi nur Präprozessoren, die haben keine Standardbibliothek und jQuery und Co. braucht man nach wie vor. Da steckt schon einiges mehr dahinter als nur andere Syntax.

Versteh mich nicht falsch, ich bin kein Dart-Verfechter (habe es nicht einmal ernsthaft verwendet), aber wenn andere Alternativen ihre Daseinsberechtigung haben, dann hat sie Dart auch.

Go ist übrigens ein ganz anderes Thema, Schnittmenge beider Sprachen und Ziele gehen gegen null

 

[ice-breaker]

js erlaubt verschiedene dinge möglichst einfach umzusetzten, so dass man sich als programmeirer nicht viel gedanken drumm machen muss. das problem von sprachlich unterstützten vereinfachung die sehr weit gehen ist immer, dass sie im allgemeinen ressourcen kosten, wenn man sie zu viel verwendet. schlimmer ist es, wenn es für spezielle zwecke keine oder nur vergleichsweise sehr unbequeme möglichkeiten gibt effizient zu programmieren.

Hast du Beispiele? Ich meine wir können Stunden auf theoretischer Basis sprechen ohne uns fortzubewegen. Aber generell klingt mir die Aussage praktisch auf jede Sprache anwendbar, ersetze ich "js" durch "Java" ist diese Aussage wieder genauso gültig, oder bei vielen weiteren Sprachen.

compiler können so etwas nur begrenzt abdecken. das ist ein problem was im allgemeinen alle script-sprachen haben, adaptive datentypen, mächtige impliziete transformationen und operationen auf strings... ja, da wird oft sehr viele strings umgewälzt und speicher verwendet wo das gar nicht nötig ist, weil es das sprachdesign es einem sehr einfach macht (im übrigen auch ein recht großes problem bei java selbst) und effiziente alternativen entweder kaum vorhanden oder nur umständlich vorhanden sind.

Da gebe ich dir Recht. Man erkauft sich eben die einfache Entwicklung durch geminderte Effizienz mancher Operationen. Im Gegensatz wollen wir das aber auch irgendwie: Wir wollen so einfach wie mit JavaScript für den Browser entwickeln können und nicht mit einem Java rumkrebsen, da es wirklich einige Implementierungen einfacher macht.

hinzu kommt, dass meiner erfahrung nach web-entwickler weit weniger ahnung von ressourceneffizienter programmierung haben (auch profis). warum das so ist sei mal dahin gestellt.

Gebe ich dir vollkommen Recht.

aber, es gibt noch ein ganz anderes problem: ganze document object model selbst. die representation eines dokuments wie es so mal definiert wurde ist in so vielerlei hinsicht problematisch umgesetzt.

100% ack.

laggende dropdown menues, laggende js scripte und anwendungen sehe ich jeden tag.

Ich nicht, hast du Beispiele? Ich sehe nur dass die Browser ein Dropdown komplett ohne JavaScript nichtmal wunderbar flüssig darstellen (also das Öffnen davon zum Beispiel)

 

[Dese]

Hast du Beispiele? Ich meine wir können Stunden auf theoretischer Basis sprechen ohne uns fortzubewegen. Aber generell klingt mir die Aussage praktisch auf jede Sprache anwendbar, ersetze ich "js" durch "Java" ist diese Aussage wieder genauso gültig, oder bei vielen weiteren Sprachen.

die impliziete typentransformierung, verlgeiche von variablen verschiedener typen, vergleiche von strings. es erlaubt und verführt zu dingen, die dann versteckt teuer sind.

Da gebe ich dir Recht. Man erkauft sich eben die einfache Entwicklung durch geminderte Effizienz mancher Operationen. Im Gegensatz wollen wir das aber auch irgendwie: Wir wollen so einfach wie mit JavaScript für den Browser entwickeln können und nicht mit einem Java rumkrebsen, da es wirklich einige Implementierungen einfacher macht.

habe ich auch nichts dagegen, solange JS nur für bissle schnick schack benutzt wird. aber mittlerweile sehe ich manchmal in js so viel gecoded, dass es das zugrundeliegende performanceproblem des gnazen modells auswirkt. kein wunder, dafür war es nie gedacht.

Gebe ich dir vollkommen Recht.

ich sehe wir verstehen uns jetzt.

Ich nicht, hast du Beispiele? Ich sehe nur dass die Browser ein Dropdown komplett ohne JavaScript nichtmal wunderbar flüssig darstellen (also das Öffnen davon zum Beispiel)

kann ihc dir leider im moment kein konkretes nennen. ich hab darauf schon lange nicht mehr geziehlt geachtet. mir fällt mittlerweile nur noch dauern auf, wenn ich auf einer seite bin ohne js, bzw. mit nur sehr wenig, dass es flüssiger läuft und schneller läd.

auch wenn aktionen / buttons keine direkten links sind sondern erst durch ein js-script das irgendwas einfaches checkt, so merk ich deutlich den latenz zuwachs der reaktion. so was macht sich interessanterweise aber erst richtig deutliuch bemerkbar, wenn ich auch mehrere tabs mit js seiten offen habe. wie gesagt, das dunterliegende modell ist scheisse implemetiert, auf allen browsern.

 

[Simple Man]

Performance ist atm kein Thema. Alle Programmiersprachen kochen mit Wasser.

Wesentlich wichtiger finde ich die Herangehensweise der Sprachentwickler bei Dart. Komplett objektorientiert, fühlt sich stark wie Java oder C# bezüglich der Syntax, Editor wird gleich mitentwickelt, Erfahrungen mit älteren Programmiersprachen werden in Betracht gezogen, etc etc

 

[Daaron]

Komplett objektorientiert

Sowas ist hochgradige Scheiße.

Oder willst du mir allen ernstes erzählen, dass System.String("Hello World!").print(); besser ist als echo "Hello World!";?

Meiner Meinung nach sollte eine gute Sprache immer auch jenseits des Tunnelblick-OO-Designs wunderbar funktionieren. Alles andere ist einfach nur monströser Overhead für den Entwickler, den Compiler oder den Interpreter.

 

[Dese]

Oder willst du mir allen ernstes erzählen, dass System.String("Hello World!").print(); besser ist als echo "Hello World!";?

geht doch auch so (voll objektorientiert):
out.println("Hallo World!");

ausserdem, wie mir scheint geht es dir in dem beispiel um die lange schreibweise. als ob man das nicht auch anders kürzen könnte

 

[ice-breaker]

@Daaron: Dese hat da vollkommen Recht, nur weil alles OOP ist, muss es noch lange nicht kompliziert sein. In Scala ist auch alles OOP und trotzdem sind deine mathematischen Operationen weiterhin "val = 1 + 2". Und werden auch weiterhin als artihmetische Operationen und nicht Methoden ausgeführt (obwohl die Sprache sie als Methoden definiert), der Compiler machts.
Und in dem Beispiel von Dese ist die Angabe eines String eben Syntactic Sugar des Compilers, denn dieser würde aus deiner Sicht unsichtbar ein String-Objekt erzeugen. Ob dies im Hintergrund wirklich passiert, ist da wieder eine andere Sache, aber du programmierst eben nach einem Modell in dem alles ein Objekt ist, wirklich alles.

 

[Dese]

korrekt.

objektorientiert definiert die beziehung zwischen methoden und deren daten und deren modellierung. für vereinfachung der syntax sind da aber keine einschränkungen gegeben.

natürlich sollte es man mit solchen verinfachungen nicht übertreiben um nicht die intuition für das objektorientierte modell zu verlieren.

Ergänzung (23. September 2012)

aber mal vo der anderen seite... mir persönlihc ist es völlig latte ob voll objektorientiert oder nicht. so lange das wesentliche und wichtigste damit abgedeckt ist macht es praktisch keinen unterschied.

 

[Simple Man]

print("print is a top lvl function in Dart");