
Nie zamierzałem robić kolejnego slajdowiska i postanowiłem przejść przez cechy Groovy i Grails z dużym udziałem kodu tworzonego na żywo. Czego mi brakowało to spójnego tworzenia pewnej, bogatej funkcjonalnie aplikacji webowej, która mogłaby poprowadzić uczestników przez cechy obu rozwiązań w sposób usystematyzowany i spójny. Mam nad czym popracować. Dyskusja była, argumenty za i przeciw Groovy też i był Krzysiek Kowalczyk, który niestrudzenie naprowadza mnie na właściwą drogę zrozumienia zawiłości technologicznych przez komentarze do wpisów na moim blogu. Dzięki Krzysiek za pomoc przed i w trakcie spotkania, szczególnie sprowadzeniu mnie na ziemię z tą inferencją typów i "kaczym typowaniem". Doczytam i kolejnym razem będę bardziej precyzyjny. Dziękuję Pawłowi Zubkiewiczowi z wrocławskiego JUGa za zorganizowanie spotkania, które już zdążył skomentować na swoim blogu. Już dawno nie uczestniczyłem w tak intrygujących dyskusjach z tyloma uczestnikami. Ach, byłbym zapomniał - wybacz Grzesiek! Miałem okazję poznać Grzegorza Białka, którego eclipsowe wojaże śledzę już od dawna. Było kilka innych osób, które poznałem, ale naturalnie poza imionami nie mam namiarów na ich bytność w Sieci, więc wciąż pozostaną anonimowi.
Prezentacja dostępna jest jako JacekLaskowski-WroclawJUG-GroovyGrails-15.06.2009.pdf.
Jeśli wiedzy o Groovy i Grails było mało, i intrygują Cię ich możliwości zapraszam na COOLuary v.2. Będzie tam także Scala, która ma się pojawić na kolejnym wrocławskim JUGu. Zdaje się, że Wrocław lekko ożył z zimowego letargu (i po zakończonej magisterce Pawła Szulca :)). Tylko czekać, kiedy na mapie polskich imprez javowych pojawi się pierwsza konferencja zorganizowany przez Wrocław JUG. Wystarczy pojemna sala i rzutnik. Reszta jest. Może kontynuacja COOLuarów we Wrocku?
Jacek, skąd Ty znasz moją ksywkę z liceum?
OdpowiedzUsuńKowalczyk to moje nazwisko :p
Odnośnie tych paskudnych typizacji to pojęć słaba i silna nie wypada używać bo mają wiele różnych znaczeń i wprowadzają zamęt. Statyczna i dynamiczna to sprawa jasna.
Inferencja typów to cecha wcześniej zarezerowowana do języków statycznie typowanych w których nie pisze się jaki jest typ, ale jest on odgadywany na podstawie kodu (jeśli jest to możliwe) tak ma Scala, Ocaml/F#, C# 3 miejscami. Łatwiej zapamiętać korzystając z nazwy "implicite typing".
Przykładowo gdyby Groovy był silnie typowany i miał inferencje możesz powtórzyć błędu z wykładu:
def a = [1]
a << a
println a
bo za pierwszym razem "a" dostanie typ ArrayList< Integer > i kompilator! nie pozwoli na linię 2. Ok inferencja może być różnie zaimplementowana i nie wiem czy tak by to było np. w Scala, ale zasadniczo jest to cechą jezyków statycznie typowanych i pozwala mimo to na pomijanie typu przy wielu okazjach.
Nie lubię też stosowania nazwy Duck Typing w przypadku Groovy. Rzeczywiście co chodzi jak kaczka jest kaczką w Groovy, ale w takich wesołych językach jak Ocaml Duck Typing jest statyczny i jest jeszcze fajniej. To znaczy nie ważna była hierarchia dziedziczenia, ważne czy sygnatury typu oczekiwanego występowały w typie podanym.
http://en.wikipedia.org/wiki/Type_inference
Pozdrawiam,
Krzysztof Kowalczyk