Mam nadzieję, że chociaż Google Wave popchnie internet w dobrą stronę. Puki co, sam przyczyniam się do sukcesywnego oddalania internetu od słusznych idei jego twórców. Tak, jak Ameryka powstawała jako państwo ateistyczne i stricte wolnorynkowe, a dziś w jej PR wpisał się kościół i ekonomia socjalna, tak w zdecentralizowany internet wtacza się coraz więcej centralizujących projektów.

Google Search i Gmail to pół biedy. Pamiętam jeden przypadek awarii Gmaila i 0 awarii wyszukiwarki. Dalej wyłania się Facebook – scentralizowany mikrointernet – i Twitter – najszybsze medium świata polegające na wadliwej architekturze jednej grupy ludzi bez biznesplanu.

Dzisiaj podłączyłem Twittera do Google Readera za pomocą Readtwit. Właśnie tego najbardziej się obawiam – kultury mashupów pośredniczących w wymianie informacji. Te wędrują z rąk do rąk narażone na pęknięcie któregoś z ogniw.

To wszystko musi być zorganizowane inaczej. Tylko jak?

Właśnie robię kolejny raz tutorial Google App Engine, ale przepisuję go w Scali. Oto jedno porównanie długości kodu, którego zamieszczeniu nie mogę się oprzeć:

Java:

package guestbook;
import java.util.Date;
import javax.jdo.annotations.*;
import com.google.appengine.api.users.User;
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Greeting {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Long id;
    @Persistent
    private User author;
    @Persistent
    private String content;
    @Persistent
    private Date date;
    public Greeting(User author, String content, Date date) {
        this.author = author;
        this.content = content;
        this.date = date;
    }
    public Long getId() {
        return id;
    }
    public User getAuthor() {
        return author;
    }
    public String getContent() {
        return content;
    }
    public Date getDate() {
        return date;
    }
    public void setAuthor(User author) {
        this.author = author;
    }
    public void setContent(String content) {
        this.content = content;
    }
    public void setDate(Date date) {
        this.date = date;
    }
}

Scala:

package guestbook
import java.util.Date
import javax.jdo.annotations._
import com.google.appengine.api.users.User
@PersistenceCapable(identityType = IdentityType.APPLICATION)
class Greeting (@Persistent var author:User, @Persistent var content:String, @Persistent var date:Date){
 @PrimaryKey
 @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
 private var id:Long
}

W tym tygodniu:

• Tworząc skomplikowany system modułowy w ruby-sinatra/haml/js/compass-css zainteresowałem się javascriptem po stronie serwera jako językiem, w którym można stworzyć dynamiczny ajax-comet-framework
• Poznałem trochę Moo Tools i zainteresowałem się Google App Engine
• Uruchomiłem na GAE js, ruby (sinatra), scalę i javę
• Poznałem idee SOFEA/SOUI i zdecydowałem się na oddzielenie interfejsu od serwera
• Zainteresowałem się Jersey, Pure JS, Open Ajax Alliance, Ext JS
• Zainteresowałem się także Flash Builderem
• Zainteresowałem się tworzeniem aplikacji desktopowych i mobilnych
• Postanowiłem kupić iPhone’a
• Gdy zobaczyłem HTML 5 w Google Wave i Safari 4, zrezygnowałem z Flash Buildera na rzecz otwartych webowych standardów
• Postanowiłem przetestować Google Web Toolkit
• Zaczerpnąłem trochę inspiracji z Lift’a i pomyślałem, że można wykorzystać GWT jako podstawę pod framework, w którym rolę MXMLa i AS we flexie odgrywałyby XML i Scala
• Zrezygnowałem z GWT, gdy się okazało, że nie współpracuje ze Scalą, ani żadnym innym językiem poza Javą
• Znalazłem Appcelerator Titanium
• Uznałem, że Titanium na razie nie nadaje się do użytku, ale wersją finalną będę BARDZO zainteresowany
• Jersey i Scala na GAE też na razie sprawia za dużo problemów, więc zacząłem pisać w czystej Javie i JDO z zamiarem przesiadki w przyszłości

Perspektywy na dziś:

• Google App Engine
• Java
• JDO
• json/xml
• OpenAjax, PureJS + biblioteczki js w zależności od potrzeb

Perspektywy na przyszłość:

• Jersey + Scala
• HTML 5
• Titanium
• Google Wave

Pisałem wcześniej o internetowym systemie operacyjnym. Znalazłem projekt, który ma te same idee. Nie został jeszcze ukończony i jest jeszcze wiele do zrobienia, ale na razie jestem bardzo optymistycznie nastawiony. Tu fragment moich wcześniejszych planów:

Potrzebujemy:

* ustandaryzowany protokół wymiany informacji między stroną kliencką a stroną serwera
* cache danych i całych aplikacji u klienta
* język i jego środowisko
* rdzeń systemu, który umożliwia komunikację z serwerami, instalację aplikacji i interakcję pomiędzy nimi

Z perspektywy Persevere rozwiązaniem jest javascript i protokoły stworzone przez ludzi z SitePen (ludzie od Dojo). Są to JSONQuery i JSONPath. System działa nieźle. Umożliwia zapisywanie obiektów javascriptowych wraz z relacjami, dziedziczeniem i ich metodami. Ma wbudowane konta użytkowników i system uprawnień. Protokół umożliwia korzystanie z bazy obiektów po stronie przeglądarki i serwera w taki sam sposób. Projekt nie obsługuje jeszcze bazy Big Table na Google App Engine, ale ten temat zaczyna być omawiany. Jestem zwolennikiem.

Od kiedy napisałem poprzedniego posta moją uwagę przyciągnęły:

Clojure – Implementacja Lispa w Javie. Wygodna komunikacja z Javą. W projekcie języka nacisk na wielowątkowość. Wszystkie wady i zalety wynikające z tego, że to Lisp. W odróżnieniu od Common-Lispa, oderwanie od niektórych kompatybilności wynikających z przyzwyczajenia do poprzednich Lispów. Standaryzacja tego, co ustandaryzowane nie było. Dodatkowa składnia (“[]“, “{}”, “:”), która jest zamieniana na standardowe sekwencyjne odpowiedniki. Brak systemu obiektowego. Ogólnie porządny lisp. Jeśli ktoś kocha lispa – niech się zapozna. Sądzę, że Lisp to jeden z najciekawszych projektów języka jaki powstał, ale brakuje mi w nim obiektowości.

Clean – Bardzo szybki język funkcyjny (zbliżony szybkością do C). Najsilniejsza strona – kompilator. Clean jest bardzo podobny do Haskella. Istnieje translator z Haskella do Cleana, w celu skorzytania z kompilatora Cleana w kodzie Haskella. Mało popularny w sieci. Prawie żadnych materiałów do nauki.

Haskell – Jeden z najbardziej znanych całkowicie funkcyjnych języków programistycznych. Podobno od Haskella można się dużo nauczyć i warto go poznać. Piękna, czytelna składnia. Charakterystyczne cechy to “Lazy-evaluation” i inferencja typów. To pierwsze sprawia, że obliczenia są wykonywane tylko wtedy gdy to konieczne. Teoretycznie zastępuje to lispowe makra. Wykonanie a(b(2)) nie przekazuje do funkcji a wyniku b(2), tylko wynik ten jest wyliczany dopiero wewnątrz ciała funkcji a (lub w kolejnych zagłębieniach). Teoretycznie umożliwia to osiągnięcie podobnych efektów jak przy lispowych makrach. Inferencja typów sprawia, że nie musimy deklarować typów tam, gdzie kompilator jest je w stanie sam zobaczyć. W język bazowo wbudowane są także “partial functions”, co oznacza, że gdy podamy za mało argumentów do funkcji, to zwróci ona kolejną funkcję, która oczekuje pozostałych. Ciekawy język, ale nie wydał mi się aktualnie do niczego potrzebny

Scala – “Nowa Java”. Język funkcyjny i obiektowy jednocześnie, napisany na JVM. Duże zainteresowanie w internecie. Syntax podobny do Javy, ale lżejszy dzięki inferencji typów i cech funkcyjnych. Ciekawe podejście do projektowania składni, która kieruje się wieloma regułami, ale pozostaje w miarę uniwersalna. Operatory to metody. Funkcje to obiekty. Wiele składniowych trików (takich jak hash w ostatnim argumencie funkcji w ruby), które prowadzą m.in. do możliwości tworzenia własnych instrukcji warunkowych. “Tail recursive optimization” – coś, czego nie ma w Clojure. Nie podobają mi się 2 tryby pracy ze Scalą: tryb aplikacji i skryptu, czego efektem jest brak możliwości tworzenia nowych klas z poziomu REPL-a. Proces pisania i testowania nie jest przez to tak dynamiczny jak w Clojure. Przez to nie przekonuje mnie mimo swojego dużego momentum.

Rhino – Opensource’owy JavaScript na JVM zrobiony przez Mozillę. JavaScript ostatnio wychodzi z przeglądarek. Dzięki Rhino możemy korzystać z js lokalnie, na serwerze, lub zamieszczać w projektach javowych. Mozilla tworzy specyfikację ServerJS, która dodaje do js obsługę plików i inne zakazane w przeglądarce akcje. Istnieją projekty, które dodają te funkcjonalności do Rhino, co tworzy z niego język ogólnego przeznaczenia. Javascript ogólnie mi się podoba, a w nadchodzącym wydaniu drugim pojawi się kilka ciekawych nowości, w tym normalna obiektowość. Jeśli w projekcie duży udział ma javascript po stronie przeglądarki to użycie go także po stronie serwera jest całkiem zasadne. Rhino można sobie odpalić na Google App Engine i jest aktualnie moim tematem nr 1.

Ruby jest fantastycznym językiem i życzę mu żeby zastąpił w sieci PHP, a jest na dobrej drodze. Jednakże Clojure ma pewne idee, które jeszcze lepiej rokują na przyszłość.

Szybkość. Clojure – jak to Lisp, mimo że wszyscy o tym zapomnieli – jest szybki. Jeden z ideologicznych fundamentów takich języków jak Ruby czy Ioke głosi, że praca developera jest droższa od pracy serwera, więc warto używać języków operujących na wysokiej abstrakcji aby zmniejszyć koszta. Jednak analiza historyczna mówi, że przepustowość łączy rośnie szybciej od mocy obliczeniowej. Zbliżamy się więc do momentu, w którym czas przetworzenia jednego zapytania w sieci będzie większy od czasu transferu. Zjawisko to potęguje tendencja tworzenia zaawansowanych aplikacji internetowych. Jeśli oba trendy się nie zmienią to będzie musiał zostać nałożony nacisk na sporą optymalizację, której tak ekstrawaganckie języki jak Ruby mogą nie podołać.

Wielowątkowość. Clojure z niej słynie, bo został stworzony z myślą o niej. Zwiększa to jego walory na polu optymalizacji.

JVM. Java jaka by nie była, jest językiem nr 1 na świecie i powstało dla niej dużo dobrego kodu. Sam język miał pewne założenia, które musiały być przetestowane w praktyce, żeby wyciągnąć z nich wnioski. Język może się zmienić, ale JVM jest maszyną wirtualną, dla której zagrożenia nie widać. Clojure jest bardzo ściśle związany z Javą. Daje nową funkcjonalność, ale jest cienką warstwą, pod którą widać javę “jak przez taflę lodu”.

Oprócz tego, Clojure ma ciekawy zestaw cech, które wykorzystują siebie wzajemnie.

• Nawiązując do złotych sentencji przyświecających Merbowi, “All you need… nil you don’t.”, a poprzednio “No-code is the fastest code.”, nasuwa się “No-syntax is the best syntax”. Clojure ma mały zbiór “special forms”, które wyglądają i działają jak funkcje, definiowalne przez użytkownika. Cała reszta jest napisana w samym Clojure. Można więc wyciąć biblioteki standardowe i napisać (lub nadpisać) je po swojemu (w tym sposób definiowania funkcji!).
• Dane (zbiory, wektory, listy) mogą być sprowadzone do jednolitej postaci – sekwencji. Dzięki temu funkcje operujące na danych nie muszą być duplikowane i specjalizowane, a Clojure udostępnia dużo gotowych funkcji ogólnego przeznaczenia.
• Wszystko jest prezentowane w jednakowy sposób, zarówno kod, jak i dane.
• Tworzy to unikalną dla Lispa możliwość pisania makr, które wyglądają jak funkcje, ale transformują kod (jako sekwencję) przed jego wykonaniem. Rozwiązuje to problemy nieosiągalne dla innych języków.

Dobrze na przyszłość rokuje także Terracotta. Udostępnia ona współdzieloną pamięć jako miejsce do lokowania danych. Dzięki niej można pożegnać tradycyjne bazy danych i SQL. Wszystkie operacje na danych można wykonywać w języku w jakim zostały stworzone oraz zapisywać i odczytywać w formie w jakiej powstały.

Clojure na razie nie integruje się z Terracottą, ale prace nad tym połączeniem trwają.

That’s my solution for simple implementation of flash feature in Sinatra:

helpers do
  def flash
    @flash ||= {}
  end
  def redirect(uri, *args)
    session[:flash] = flash unless flash.empty?
    status 302
    response['Location'] = uri
    halt(*args)
  end
end

before do
  if session[:flash] and not session[:flash].empty?
    @flash, session[:flash] = session[:flash], nil
  end

end

Pastie

Stuart Halloway -  autor Programming Clojure – na swoim blogu przekłada przykładowe kody z książek o lispie na clojure. Do tej pory przeportował:

• Practical Common Lisp – Peter Seibel
• On Lisp – Paul Graham

There’s JMS:
http://en.wikipedia.org/wiki/Java_Message_Service
https://mq.dev.java.net/
http://joram.objectweb.org/
http://activemq.apache.org/

XMPP:
http://en.wikipedia.org/wiki/Xmpp
http://www.igniterealtime.org/projects/index.jsp

JXTA/Shoal:
http://en.wikipedia.org/wiki/Jxta
https://shoal.dev.java.net/

JINI:
http://en.wikipedia.org/wiki/Jini
http://incubator.apache.org/projects/river.html

DHTs like Pastry:
http://freepastry.org/

JGroups:
http://www.jgroups.org/javagroupsnew/docs/index.html

Terracotta:
http://www.terracotta.org

Jinterface:
http://www.erlang.org/doc/apps/jinterface/

NetKernel:
http://www.1060.org/

and more. All useful from Clojure. Given the diversity, sophistication, maturity, interoperability, robustness etc of these options, it’s unlikely I’m going to fiddle around with some language-specific solution. That said, I have been thinking about putting a simple wrapper API around queues that would work both locally and over something like JMS.

Rich Hickey – Clojure could be to Concurrency-Oriented Programming what Java was to OOP

One of the best programmers I ever hired had only a High School degree; he’s produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.

Peter Norvig – Teach Yourself Programming in Ten Years

Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter

Eric Raymond, author of The New Hacker’s Dictionary