Google Dart – pierwsze wrażenie

Dzisiaj Google zaprezentował na blogu chromium pierwsze informacje na temat swojego nowego języka „Dart”. Dart prezentowany jest przez firmę z Mountain View jako język do „strukturalnego programowanie webowego”, mający docelowo zastąpić Javascript w roli głównego narzędzia do pisania aplikacji webowych po stronie przeglądarki. Postanowiłem przyjrzeć się szybko jak język ten wygląda i podzielić się pierwszymi wrażeniami jakie mi przyszły do głowy. W dalszej części artykułu, będę się opierał na jednym z artykułów, który jest mini tutorialem do Darta i przedstawia dość obszernie kod, który zwykle jest używany przez programistów jak i różne Dartowe smaczki.

Na pierwszy rzut oka Dart wygląda na kolejny klon Javy / C# z większym podobieństwem do C#. Jak każdy w miarę nowoczesny język posiada funkcje anonimowe i domknięcia. Jest oparty na klasach więc większość osób łatwo się w nim odnajdzie. Jest to główna i fundamentalna różnica pomiędzy Dartem a Javascriptem, oprócz oczywiście składni. Poza tą różnicą Dart wspiera DSL (domain specific languages), dzięki temu, że podobnie jak w Scali, operatory są tak naprawdę zwykłymi metodami, czyli mamy możliwość wywoływania metod bez użycia kropki. Dart wspiera też opcjonalne typowanie – możemy zadeklarować typ zmiennej i będzie on sprawdzony w czasie kompilacji.

Jeżeli porównamy Darta do PHP, to oprócz wcześniej wymienionych ficzerów jedyną w zasadzie różnicą będzie obsługa funkcji akcesorowych znanych z C# (metod prefiksowanych przez get/set).

Dart posiada jeszcze kilka mniej znaczących smaczków, które są głównie lukrem składniowym i mogą być z łatwością odtworzone przy użyciu innych konstrukcji językowych. Pierwszym z takich smaczków są nazwane konstruktory – czyli googlowy sposób na przeciążanie konstruktora w języku dynamicznie typowanym nieobsługującym przeciążania metod. Drugi sposób to metody fabryczne, czyli metody klasy poprzedzone słowem kluczowym „factory”, ich zastosowanie jest dla mnie generalnie mało zrozumiałe. Ostatnim „ficzerem” jaki zauważyłem są „krótkie konstruktory”, które oszczędzają nam trochę pisania – zamiast:

class Point {
    num x, y;
    Point(num x, num y) {
        this.x = x;
        this.y = y;
    }
}

można napisać tak:

class Point {
   num x, y;
   Point(this.x, this.y);
}

Podsumowując – szału nie ma. Co jak co, ale po Google spodziewałem się więcej. Czego mi brakuje ?

  1. Większego nacisku na programowanie funkcyjne – np. łatwego sposóbu na tworzenie immutable data types, chociażby a’la Scala:
     case class User(firstName: String, lastName: String, birthday: Date) 
  2. Anonimowe klasy
  3. Wsparcie dla przetwarzania równoległego / wielowątkowego – jest w postaci aktorów (podziękowania dla wookieba)
  4. Przestrzeni nazw / modułów
  5. „Odwróconych” interfejsów a’la GO, czyli coś w rodzaju:
    class Test {
        Integer foo(){
            return 1;
        }
    }
    
    interface Foo {
         Integer foo();
    }
    
    Foo someFoo = new Test(); /* ok! - nie ma błędu -
    klasa Test nie deklaruje, że implementuje interfejs Foo,
    ale sygnatura jej metod jest zgodna z nim */
    

    Więcej na stronie 8tlight

Jestem ciekaw jaka jest Wasza opinia ?

  1. wookieb pisze:

    Wielowątkowość: http://www.dartlang.org/docs/api/Isolate.html#Isolate::Isolate
    Doc: „Dart code is always single threaded. There is no shared-state concurrency in
    Dart. Concurrency is supported via actor-like entities called isolates.
    An isolate is a unit of concurrency. It has its own memory and its own
    thread of control. Isolates communicate by message passing (10.14.4). No state
    is ever shared between isolates. Isolates are created by spawning (10.11).”

    Niemutowalne w sensie „final” przed zmienną? – Jest

  2. wookieb pisze:

    Pomyłka – miałem napisać „współbieżność” zamiast „wielowątkowość”

  3. Wookieb widzę, że zajrzałeś trochę głębiej niż ja. Co do wsparcia dla niemutowalnych typów danych, miałem na myśli wsparcia dla szybkiego tworzenia niemutowalnych typów danych, czyli coś jak case class z Scali:

    case class User(firstName: String, lastName: String, birthday: Date)
    

    Jak widać w powyższym przykładzie, od razu otrzymujemy w jednej linijce niemutowalny typ danych wraz z ekstrasami dodawanymi przez kompilator w rodzaju, metody equals etc.

  4. wookieb pisze:

    Ok, rozumiem :)

    A tak ogólna moja opinia o Dart-cie jest bardzo dobra. W końcu są klasy (niestety brak protected), w końcu są interfejsy, w końcu jest typowanie argumentów funkcji (no nareszcie). Settery i gettery pisane w ludzki sposób (porównaj deskryptory w ES5 to się uśmiejesz). Proces klepania w czymś takim jest o wiele wydajniejszy niżeli w js + ES5 jeżeli chciałbyś uzyskać ten sam efekt. Niestety po pierwszych opiniach ze światka JS widzę, że pomysł raczej się nie przyjmie dopóki korpo i masa ludzi, którzy lubią pisać szybko dobry kod nie nacisną społeczności aby używano Dart-a zamiast JavaScriptu.

    Poza tym, DART póki co demonem wydajności jeszcze nie jest – potrzeba czasu na rozwój. http://www.reddit.com/r/programming/comments/l6uwv/dart_programming_language/

  5. Ja generalnie nie jestem jakimś wielkim fanem klas i podoba mi się podejście Javascriptu do obiektowości. Typowanie i interfejsy jestem na tak, co do deskryptorów to i tak pisząc własny kod w ogóle raczej nie używam getterów i setterów także osobiście nie jest mi to do niczego potrzebne.

  6. Theq pisze:

    Jest normalne typowanie i to mi wystarczy, żeby było lepiej niż JS. Większość błędów jakie widze na forach polegała na jakiś głupich literówkach, które ciężko znaleźć bo według przeglądarki jest wszystko ok.

  7. Co do typowania to muszę Ci przyznać rację, jak przesiadłem się na Javę, to rzeczywiście pozwala na uniknięcie wielu błędów :)

  8. snapshot pisze:

    Niestety Google odbiega w tym momencie od standardów i tworzy kolejne dziwne twory – niczym IE w czasie swojej dominacji. Nie rozumiem sensu tworzenia czegoś innego, w momencie gdy nie wnosi to nic nowego. Oczywiście główną kwestią jest szybkość, ale wydaje mi się, że dałoby się przenieść JS na inny poziom podczas wykonywania kodu. W każdym razie FAIL.

  9. wookieb pisze:

    A co nowego ma dodać? Kodowanie myślami? Samo typowanie + w końcu jakieś klasy daję wyższość nad bałąganem w JS.

  10. Już to widziałem, ale to normalka bo leci tam cały runtime, przy coffescrpitcie jest pewnie podobnie 😛

  11. Rodzyn pisze:

    Hello World w CoffeeScript ma tyle samo co w JS 😛

    Jeszcze jedno:
    http://webreflection.blogspot.com/2011/10/what-is-wrong-about-17259-lines-of-code.html

  1. There are no trackbacks for this post yet.

Leave a Reply

Informuj mnie o odpowiedziach poprzez e-mail. Możesz również subskrybować wpis bez zostawiania komentarza.