[Warszawa JUG] 88. spotkanie Warszawa JUG - Maciej Jaśkowski o Scali i Jacek Laskowski o Clojure

[Wojciech Erbetowski]

Cześć!

Warszawska Grupa Użytkowników Javy (Warszawa JUG [1]) zaprasza na 88. spotkanie,  które odbędzie się w najbliższy wtorek, 22-go lutego o godzinie 18:00 w sali 3180 Wydziału MIM UW przy ul. Banacha 2 w Warszawie. 

Temat pierwszy: Scala na tle Java EE i Lift Prelegent: Maciej Jaśkowski [2]

Na spotkaniu będziemy się bawić Scalą, żeby stwierdzić, czy może być przydatna w codziennej pracy programisty Java. Zatem będziemy patrzeć nie tylko na ciekawe własności tego języka (przede wszystkim obiektowe i związane z lukrem syntaktycznym), ale również na możliwości integracji Scali z Javą i ewentualne problemy z tym związane. Wszystko to na przykładach standardowych bibliotek oraz J2EE ze szczyptą Lifta. 

Maciej Jaśkowski absolwent MIMUW, współorganizator konferencji Flaszki[3], były przewodniczący Samorządu MIMUW, programista Java od 18 miesięcy. Wierzę w testy jednostkowe i TDD, lubię NoSQL/Hadoop i języki funkcyjne, uznaję tylko metodyki SCRUM-opodobne. 

Temat drugi: Krótko i zwięźle o Clojure Prelegent: Jacek Laskowski [4]

W trakcie wystąpienia przedstawię programowanie funkcyjne na JVM z językiem Clojure. Zaprezentuję kilka interesujących cech języka, które sprawią, że programowanie obiektowe w Javie może wydać się czasami irytujące oraz zaprezentuję, co należy posiadać, aby rozpocząć swoją przygodę z programowaniem funkcyjnym na JVM, aby stało się równie funkcjonalne jak inne języki, z których obecnie korzystasz i uważasz za takowe. Wystąpienie traktuję jako możliwość podsumowania moich dotychczasowych doświadczeń z Clojure, aby zostać ukierunkowanym na praktyczne problemy, z którymi się stykasz w projektach, a dla których Clojure mógłby być ciekawym rozwiązaniem. W końcu to wciąż bajtkod JVM. 

Jacek Laskowski jest założycielem i liderem Warszawskiego JUGa. Interesuje się Javą w wydaniu podstawowym (Java SE) i korporacyjnym (Java EE), a od ponad roku zadużony w programowaniu funkcyjnym z Clojure (i w tle F#). Swoje przemyślenia publikuje na polskojęzycznym blogu Jacek Laskowski jawnie [4] oraz angielskojęzycznym Japila :: verba docent, exempla trahunt [5]. Krótkie myśli znajdziesz na kanale @jaceklaskowski [6]. Występuje podczas polskich konferencji, co traktuje jako wyróżnienie i miejsce prezentacji własnych poglądów. Będzie wdzięczny za wszelkie komentarze do jego publicznych aktywności. 

Planowany czas prezentacji to 45min (każda), po których planuje się 15-30-minutową dyskusję. 

Sponsorem spotkania jest firma SMT Software S.A., która nas przywita, zapewni pożywienie i zaprezentuje swój profil. 

[1] http://www.warszawa.jug.pl/

[2] http://samorzad.mimuw.edu.pl/wybory-2009/maciej-jaskowski/

[3] http://www.flaszki.waw.pl/

[4] http://jaceklaskowski.pl/

[5] http://blog.japila.pl/

[6] http://twitter.com/jaceklaskowski

[Jacek Laskowski]

2012/2/20 Wojciech Erbetowski <wojc...@erbetowski.pl>:

> Warszawska Grupa Użytkowników Javy (Warszawa JUG [1]) zaprasza na 88.
> spotkanie,  które odbędzie się w najbliższy wtorek, 22-go lutego o godzinie
> 18:00 w sali 3180 Wydziału MIM UW przy ul. Banacha 2 w Warszawie.

Uwaga, uwaga - spotkanie jest we wtorek, jutro, 21.02.2012. Przyjdzcie
punktualnie, aby pizza nie wystygła :)

Jacek

--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
"Hoping to save time by spending it" by David Blevins (Apache OpenEJB)

[Wojciech Erbetowski]

Ups, wpadka z datą na dobry początek.

Oczywiście wtorek 21.02 :-)

Dzięki Jacek

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[Jacek Laskowski]

2012/2/20 Wojciech Erbetowski <wojc...@erbetowski.pl>:

> Ups, wpadka z datą na dobry początek.
> Oczywiście wtorek 21.02 :-)
>
> Dzięki Jacek

Na moim polskojęzycznym blogu też już jest. Dzięki za opiekę nad tematem.

[Jacek Laskowski]

2012/2/20 Jacek Laskowski <ja...@japila.pl>:

> 2012/2/20 Wojciech Erbetowski <wojc...@erbetowski.pl>:
>
>> Warszawska Grupa Użytkowników Javy (Warszawa JUG [1]) zaprasza na 88.
>> spotkanie,  które odbędzie się w najbliższy wtorek, 22-go lutego o godzinie
>> 18:00 w sali 3180 Wydziału MIM UW przy ul. Banacha 2 w Warszawie.
>
> Uwaga, uwaga - spotkanie jest we wtorek, jutro, 21.02.2012. Przyjdzcie
> punktualnie, aby pizza nie wystygła :)

Dzisiaj, 21.02.2012, punktualnie o 18:00 rozpoczynamy party Warszawa JUG!

Sala jest gotowa. Zestaw nagrywający (przenośny, ale podobno w sali
też jest) również. Sponsor - SMT Software S.A. - umówiony. Pizza
także. Napoje będą. Prelegenci są. JVM się rozgrzewa na uruchomienie
nowoczesnych języków programowania (cokolwiek miałoby to znaczyć, ale
dla mnie są to same superlatywy).

Pozostaje jedyna niepewność - czy będzie komu "konsumować produkt"?!
:) Wierzę, że nie tylko przybędziecie licznie, ale i dacie się namówić
na odrobinę Clojure? Do zobaczenia!

p.s. Ładnie się ogolić, przystrzyc i uśmiechniętym przybyć na
spotkanie - będzie nagrywanie.

Jacek

--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl

"Never discourage anyone who continually makes progress, no matter how
slow." Plato

[Wojciech Erbetowski]

Wydarzenie też właśnie powinno się pojewić w Waszych kalendarzach :-)

Nie zapomnijcie też followować @warszawajug

Pozdrawiam,

Wojtek

[Jacek Laskowski]

2012/2/21 Jacek Laskowski <ja...@japila.pl>:

> Dzisiaj, 21.02.2012, punktualnie o 18:00 rozpoczynamy party Warszawa JUG!

I już po spotkaniu. Wierzę, że było równie produktywne dla Was, co dla
mnie. Poprawki do slajdów są nanoszone i kolejna ich odsłona już za 2
tygodnie we wtorek.

Zbieram tym samym komentarze o wadach i zaletach spotkań w tej formule
- 2 prelegentów, sponsor, pizza.

Co się Tobie podobało, a co irytowało, a może wręcz nie życzysz [*]
sobie tego typu "przerywników" podczas kolejnych spotkań? Czy
spodziewałeś się innego układu spotkania? Czy występ sponsora po
pizzy, a przed wystąpieniami, był wartościowy? Co byś zmienił? Co byś
usprawnił? Gdzie prelegenci popełnili błąd, a gdzie należałoby ich
wynieść na piedestał? Proszę o komentarze, na bazie których kolejne
wystąpienia będą bardziej dopasowane do potrzeb, a może i bardziej
profesjonalne?

Nie wahajcie się chwalić, ani ganić. Nikt tutaj nikogo nie powiesi za
dobre i złe słowo. Zero urazy. Wdzięczność gwarantowana!

Nagranie ze spotkania pojawi się niebawem. Dzisiaj/jutro konwersja i
upload. Stay tuned i dopytuj, kiedy temat stanie się nieświeży, a
wciąż w trakcie realizacji. Ciao.

[*] Używam formy męskiej wyłącznie dla uproszczenia komunikacji, ale
kobiety, które uczestniczyły w spotkaniu, powinny się również, a może
przede wszystkim, czuć zaproszone do udziału w ankiecie.

[Krzysztof Nielepkowicz]

Czy da�o by rad� za 2 tygodnie troch� kodu ;) Jak by� te� wspomnia� o
praktycznym zastosowaniu closure w projektach lub w jakich fragmentach
projekt�w warto u�ywa�, czego si� wystrzega� itp. Jednak ju� po
prezentacji Skali widz� �e mo�e nie by� tak prosto i przyjemnie z
mieszaniem j�zyk�w. Dla zatwardzia�ych javowc�w, w modernizacji
�wiatopogl�du, m�g� by by� pomocny LambaJ ;) Sk�adnia troch� przypomina
skal� ale z wielk� ilo�ci� ( i ) .

--
Serdecznie Pozdrawiam,
Krzysztof Nielepkowicz
fotografia : fotomilo.pl
m�j programistyczny blog : http://kyniek.blogspot.com/

> 2012/2/21 Jacek Laskowski<ja...@japila.pl>:
>
>> Dzisiaj, 21.02.2012, punktualnie o 18:00 rozpoczynamy party Warszawa JUG!

> I ju� po spotkaniu. Wierz�, �e by�o r�wnie produktywne dla Was, co dla
> mnie. Poprawki do slajd�w s� nanoszone i kolejna ich ods�ona ju� za 2
> tygodnie we wtorek.
>
> Zbieram tym samym komentarze o wadach i zaletach spotkaďż˝ w tej formule
> - 2 prelegent�w, sponsor, pizza.
>
> Co si� Tobie podoba�o, a co irytowa�o, a mo�e wr�cz nie �yczysz [*]
> sobie tego typu "przerywnik�w" podczas kolejnych spotka�? Czy
> spodziewa�e� si� innego uk�adu spotkania? Czy wyst�p sponsora po
> pizzy, a przed wyst�pieniami, by� warto�ciowy? Co by� zmieni�? Co by�
> usprawni�? Gdzie prelegenci pope�nili b��d, a gdzie nale�a�oby ich
> wynie�� na piedesta�? Prosz� o komentarze, na bazie kt�rych kolejne
> wyst�pienia b�d� bardziej dopasowane do potrzeb, a mo�e i bardziej
> profesjonalne?
>
> Nie wahajcie siďż˝ chwaliďż˝, ani ganiďż˝. Nikt tutaj nikogo nie powiesi za
> dobre i z�e s�owo. Zero urazy. Wdzi�czno�� gwarantowana!
>
> Nagranie ze spotkania pojawi siďż˝ niebawem. Dzisiaj/jutro konwersja i
> upload. Stay tuned i dopytuj, kiedy temat stanie si� nie�wie�y, a
> wci�� w trakcie realizacji. Ciao.
>
> [*] U�ywam formy m�skiej wy��cznie dla uproszczenia komunikacji, ale
> kobiety, kt�re uczestniczy�y w spotkaniu, powinny si� r�wnie�, a mo�e
> przede wszystkim, czu� zaproszone do udzia�u w ankiecie.
>
> Jacek
>

[Jacek Laskowski]

2012/2/22 Krzysztof Nielepkowicz <k.p.niel...@gmail.com>:
> Czy dało by radę za 2 tygodnie trochę kodu ;)

Tak się właśnie nastawiam. Poza para-matematycznymi problemami
usiądziemy również nad tworzeniem aplikacji webowej z dostępem do
MongoDB. Wszelkie uwagi uzupełniające mile widziane. Kod można już
podglądać w projekcie librarian-clojure [1].

[1] https://github.com/jaceklaskowski/librarian-clojure

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -

[Dawid Bielecki]

Kiedy będą ogłoszone wyniki losowania InteliJ IDEA?

--
Regards/Pozdrawiam,

Dawid Bielecki
http://www.dawciobiel.com
e-mail: dawciobiel AT gmail DOT com

[Vitaliy Oliynyk]

@Dawid Bielecki Kiedy będą ogłoszone wyniki losowania InteliJ IDEA?

+1 

? 

[Irek Matysiewicz]

@Jacek: A ja po spotkaniu nie mogę się powstrzymać od krytyki Clojure. :-)

- stwierdziłeś że w typowym kodzie Clojure jest mniej nawiasów niż w Javie. Udowodnij to, bo ja mam wrażenie że ściemniasz i że jest odwrotnie: (f x) -> f(x) - po tyle samo nawiasów, ale (+ x y) -> x + y - w Javie mniej nawiasów. Jedynie instrukcja rzutowania ma w Javie nadmiar nawiasów: ((TypDocelowy)obiekt).metoda(...) - dałoby się to zrobić lepiej, ale czy stosujemy to aż tak często? O wiele częściej stosujemy x+y czy x*y, które w Javie nie wymagają nawiasów a w Clojure wymagają.

- mówisz że homoikoniczność jest super, ale i w Javie w kilka dni mogę napisać coś takiego że bierze bajtkod (np. odpowiedzialny za instrukcję a+b*c) i zwróci strukturę danych reprezentującą ten kod, np. Plus(a, Mul(b, c)) - prawie to samo co lispowe (+ a (* b c)) będące jednocześnie kodem i danymi. Haskell ma już coś takiego zaimplementowane: [| kod... |] zwraca drzewo reprezentujące ten kod, to drzewo możesz sobie zmieniać do woli (metaprogramowanie) a potem tak zmieniony kod wywołać za pomocą operatora $( drzewo ) - http://stackoverflow.com/questions/5365746/typechecking-inside-quasi-quotes-in-template-haskell#5365890
I po co komu ta cała homoikoniczność? - chyba tylko dla znudzonych życiem matematyków.


Do tej pory miałem jak najgorsze zdanie o Clojure, twoja prezentacja mnie tylko w tym przekonaniu utrzymała. Przekonaj mnie że nie mam racji. :-)

[Bartek Zdanowski]

2012/2/23 Dawid Bielecki <dawci...@gmail.com>

Kiedy będą ogłoszone wyniki losowania InteliJ IDEA?

Chodzi Wam o 88 spotkanie?
 

--
Regards/Pozdrawiam,

Dawid Bielecki
http://www.dawciobiel.com
e-mail: dawciobiel AT gmail DOT com

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję http://twitter.com/bartekzdanowski
Confitura 2012 - największa bezpłatna konferencja programistyczna - http://confitura.pl
KO Warsjawa 2012 - warszawskie jesienne warsztaty javowe - http://warsjawa.pl

[Krzysztof Nielepkowicz]

Mo�e z innej beczki, mam taki pomys� by sponsorzy zamiast 3 os�b z PR przys�ali kogo� technicznego. No dobra - moze by� 2*PR + 1TECH.

2012/2/23 Dawid Bielecki <dawci...@gmail.com>

Kiedy b�d� og�oszone wyniki losowania InteliJ IDEA?

Chodzi Wam o 88 spotkanie?

ďż˝

--
Regards/Pozdrawiam,

Dawid Bielecki
http://www.dawciobiel.com
e-mail: dawciobiel AT gmail DOT com

--
Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
Wi�cej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Pozdrawiam,
Bartek Zdanowski

Blogujďż˝ http://blog.bartekzdanowski.pl i twittujďż˝ http://twitter.com/bartekzdanowski
Confitura 2012 - najwi�ksza bezp�atna konferencja programistyczna - http://confitura.pl

KO Warsjawa 2012 - warszawskie jesienne warsztaty javowe - http://warsjawa.pl

--
Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
Wi�cej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--

[Tomek Lipski]

Irku,

On 23 Lut, 14:23, Irek Matysiewicz <iir...@gmail.com> wrote:
> @Jacek: A ja po spotkaniu nie mogę się powstrzymać od krytyki Clojure. :-)
>

Wydaje mi się, że nie krytykujesz Clojure, tylko raczej porównujesz ją
z innymi językami na jakimś tam wycinku ich funkcjonalności - to
dobrze, warto się do czegoś odnieść. Z dialektami Lispa dla mnie jest
tak, że nie każdy je musi lubić i nie każdemu się muszą podobać.
Trochę jak z marcepanem albo produktami Apple - jedni nie mogą się od
nich oderwać, drudzy - nie mogą na nie patrzeć ;-) Są różni
programiści, różne przyzwyczajenia i style kodowania.

Wydaje mi się, że do języka programowania trzeba się przekonać samemu
i moim zdaniem zanim się zacznie krytykować Clojure, to warto dobrze
je poznać. Można na przykład Joy of Clojure przeczytać i wtedy
człowiek może mieć jakieś zdanie (chociaż raczej widać do czego język
jest zdolny po paru projektach raczej). Ale nikt nie gwarantuje Ci, że
jak przeczytasz, to się zachwycisz Clojure i będziesz chciał pisać
tylko w tym języku. I chyba też nikomu o to chodzi.

t

P.S. Nie widzę sensu w porównywaniu ilości nawiasów w Javie/Clojure bo
w Clojure kod będzie po prostu krótszy jeśli napisany właściwie.
Oczywiście jak będziemy pisać 1:1 kod "w stylu" Javy w Clojure, to
zysk może być niewielki jeśli chodzi o nawiasy. Ale po paru projektach
w danym języku i tak się "nie widzi" nawiasów ani w Clojure ani w
Javie.
P.S.2. Pozwoliłem sobie zmienić temat na bardziej zorientowany na
temat wypowiedzi.

[Tomek Lipski]

> P.S.2. Pozwoliłem sobie zmienić temat na bardziej zorientowany na
> temat wypowiedzi.

i zepsułem, przepraszam

t

[Łukasz Żuchowski]

Chyba zamiast z HR :)
Z drugiej strony sugerować możemy ale wymagań takich mimo wszystko bym
nie stawiał (fajnie mieć pizze i napoje). Warto jednak, żeby wcześniej
ustalić ile mają czasu na keynote, bo Pan z SMT trochę się rozgadał.
Fakt mówił dużo ale w większości były to chyba informacje, które ludzi
ze świata Java zbytnio nie interesują np. o partnerstwie z
Microsoftem, podkreślanym kilka razy. Na pewno milej by posłuchać
osoby technicznej.

W dniu 23 lutego 2012 15:21 użytkownik Krzysztof Nielepkowicz
<k.p.niel...@gmail.com> napisał:
> Może z innej beczki, mam taki pomysł by sponsorzy zamiast 3 osób z PR
> przysłali kogoś technicznego. No dobra - moze być 2*PR + 1TECH.
>
>
>
> 2012/2/23 Dawid Bielecki <dawci...@gmail.com>
>>
>> Kiedy będą ogłoszone wyniki losowania InteliJ IDEA?

>
> Chodzi Wam o 88 spotkanie?
>
>>
>>

>> --
>> Regards/Pozdrawiam,
>>
>> Dawid Bielecki
>> http://www.dawciobiel.com
>> e-mail: dawciobiel AT gmail DOT com
>>
>> --

>> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
>> Więcej informacji na stronie
>> http://groups.google.com/group/warszawa-jug?hl=pl
>> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

>> Oferty pracy dozwolone zgodnie z zasadami na
>> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>
>
>
>
> --
> Pozdrawiam,
> Bartek Zdanowski
>

> Bloguję http://blog.bartekzdanowski.pl i twittuję

> http://twitter.com/bartekzdanowski
> Confitura 2012 - największa bezpłatna konferencja programistyczna -

> http://confitura.pl
> KO Warsjawa 2012 - warszawskie jesienne warsztaty javowe -
> http://warsjawa.pl
> --

> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>
>
>
> --
> Serdecznie Pozdrawiam,
> Krzysztof Nielepkowicz
> fotografia : fotomilo.pl

> mój programistyczny blog : http://kyniek.blogspot.com/
>
> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Pozdrawiam,

Łukasz

[Michal Margiel]

Witajcie,

Nie mogę wyjść ze zdziwienia, że teraz jedną z miar "fajności"/"użyteczności" języka jest ilość nawiasów w kodzie.

--
Pozdrawiam/Best regards
Michał Margiel

http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu

[Michal Margiel]

W dniu 23 lutego 2012 15:52 użytkownik Łukasz Żuchowski <lukasz.z...@gmail.com> napisał:

Chyba zamiast z HR :)

chyba zamiast z kadr  :)

http://www.youtube.com/watch?v=WSGeKQcSsAA 

[Bartek Kuczyński]

W dniu 23 lutego 2012 15:56 użytkownik Michal Margiel
<michal....@gmail.com> napisał:

> Witajcie,
>
> Nie mogę wyjść ze zdziwienia, że teraz jedną z miar
> "fajności"/"użyteczności" języka jest ilość nawiasów w kodzie.

nawiasy to jeden z elementów składni, a ta bardzo często decyduje o
być albo nie być języka. Zobacz co stało się z javaFX Script czy
Cobolem. Poległy ponieważ miały "składnię odbiegającą od przyjętych
norm".

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

>
>
> --
> Pozdrawiam/Best regards
> Michał Margiel
>
> http://www.confitura.pl (dawniej Javarsovia)
> http://www.linkedin.com/in/MichalMargiel
> http://www.margiel.eu
>

[Michal Margiel]

W dniu 23 lutego 2012 16:01 użytkownik Bartek Kuczyński <bjkuc...@gmail.com> napisał:

W dniu 23 lutego 2012 15:56 użytkownik Michal Margiel
<michal....@gmail.com> napisał:

> Witajcie,
>
> Nie mogę wyjść ze zdziwienia, że teraz jedną z miar
> "fajności"/"użyteczności" języka jest ilość nawiasów w kodzie.

nawiasy to jeden z elementów składni, a ta bardzo często decyduje o
być albo nie być języka. Zobacz co stało się z javaFX Script czy
Cobolem. Poległy ponieważ miały "składnię odbiegającą od przyjętych
norm".

Żartujesz chyba?

Moim zdaniem składnia JavaFX była świetna (niedoskonała), natomiast  głownym problemem był absolutny brak dobrego IDE.

Ale oficjalnie, z tego co pamiętam, mówili, że trudno im było rozwiajać/dodawać nowe rzeczy (pewnie z powodu jakiś wczesnych decyzji projektowych).

O Cobolu się nie wypowiadam bo nigdy z nim nie pracowałem.

 

[Bartek Kuczyński]

JavaFX Script miała jeden feler. Nie była javą. Składnia bardzo
przyjemna, ale nie pasująca do "javowego sposobu myślenia". Co do
Cobola to odsyłam do Wikipedii :) Jest kilka dosadnych cytatów na jego
temat.

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

W dniu 23 lutego 2012 16:07 użytkownik Michal Margiel

[Michal Margiel]

W dniu 23 lutego 2012 16:12 użytkownik Bartek Kuczyński <bjkuc...@gmail.com> napisał:

JavaFX Script miała jeden feler. Nie była javą. Składnia bardzo
przyjemna, ale nie pasująca do "javowego sposobu myślenia".

A co konkretnie? Twój arguemnt dla mnie znaczy wszystko i nic.  Mi, zawodowemu javowcowi (jakkolwiek to brzmi), składnia bardzo pasowała.

[Bartek Kuczyński]

Chociażby struktura przypominająca skrzyżowanie yml'a z jsonem i
javascriptem co dawało dość nieciekawy wygląd bardziej rozbudowanych
programów (zagnieżdżamy, zagnieżdżamy, bo termin goni i nie mamy czasu
na refaktoryzację). To, że fajnie się w tym pisało to jedna sprawa, a
to że trzeba było zmienić sposób myślenia o kodzie jako takim to inna
sprawa. Do tego to co wspomniałeś czyli brak IDE. Język najzwyczajniej
się z jakiegoś powodu nie przyjął, bo gdyby pasował to by i IDE ktoś
zrobił porządne.

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

W dniu 23 lutego 2012 16:21 użytkownik Michal Margiel
<michal....@gmail.com> napisał:
>
>

[Łukasz Żuchowski]

W dniu 23 lutego 2012 15:59 użytkownik Michal Margiel
<michal....@gmail.com> napisał:
>
>

> W dniu 23 lutego 2012 15:52 użytkownik Łukasz Żuchowski
> <lukasz.z...@gmail.com> napisał:
>
>> Chyba zamiast z HR :)
>
>
>
> chyba zamiast z kadr  :)
> http://www.youtube.com/watch?v=WSGeKQcSsAA
>

A co zamiast PR ?

[Michal Margiel]

W dniu 23 lutego 2012 16:27 użytkownik Bartek Kuczyński <bjkuc...@gmail.com> napisał:

Chociażby struktura przypominająca skrzyżowanie yml'a z jsonem i
javascriptem co dawało dość nieciekawy wygląd bardziej rozbudowanych
programów (zagnieżdżamy, zagnieżdżamy, bo termin goni i nie mamy czasu
na refaktoryzację).

Hmm.. a pisałeś jakiś prawdziwy projekt w JavaFX Script? bo zapewniam Cię że to wszystko można było pięknie rozbić na klasy i  metody. Zrobić to.. na "javowy sposób myślenia" jak to ująłeś. 

 

To, że fajnie się w tym pisało to jedna sprawa, a
to że trzeba było zmienić sposób myślenia o kodzie jako takim to inna
sprawa. Do tego to co wspomniałeś czyli brak IDE. Język najzwyczajniej
się z jakiegoś powodu nie przyjął, bo gdyby pasował to by i IDE ktoś
zrobił porządne.

Czy naprawdę język był tutaj przyczyną nie przyjęcia JavaFX? Ta technologia po prostu była, z jednej strony, za wcześnie , zaś z drugiej  - za późno  wypuszczona .

Za późno bo flesh/flex/air miał już dobrą pozycję.

za wcześnie bo ta technologia była zajebiście niedopracowana.

 W pierwszych wersjach nie było nawet Comboboxa! nie było pola typu "password", do końca istnienia JavaFX script nie było porządnego komponentu tabelki. Jak można stworzyć aplikację bez tych, podstawowych, komponentów :/. Brakowało również "oficjalnej"[1] integracji ze swingiem.To dlatego JavaFX się nie przyjął, to dla tego nie powstało dobre IDE, i to dlatego pożegnaliśmy ten język.

Sorry ale ilość nawiasów nie wpłynęła na nie przyjęcie JavaFX (przypomnijmy że od tego zaczęła się dyskusja) 

[1] nieoficjalnie dało się to zrobić brudnymi hakami.

[Michal Margiel]

Mi się wydaje, że RP - rzecznik prasowy. 

[Dawid Bielecki]

tak jest

[Krzysztof Nielepkowicz]

On 2012-02-23 15:52, �ukasz �uchowski wrote:
> Chyba zamiast z HR:)

> Z drugiej strony sugerowa� mo�emy ale wymaga� takich mimo wszystko bym
> nie stawia� (fajnie mie� pizze i napoje). Warto jednak, �eby wcze�niej
> ustaliďż˝ ile majďż˝ czasu na keynote, bo Pan z SMT trochďż˝ siďż˝ rozgadaďż˝.
> Fakt m�wi� du�o ale w wi�kszo�ci by�y to chyba informacje, kt�re ludzi
> ze �wiata Java zbytnio nie interesuj� np. o partnerstwie z
> Microsoftem, podkre�lanym kilka razy. Na pewno milej by pos�ucha�
> osoby technicznej.
A� tak restrykcyjnie tego nie napisa�em ;) Oni wys�ali 3 osoby z kadr,
napewno nie za free. Podczas keyNote nie dowiedzia�em si� wi�cej ni� ze
strony sponsora. Jestem jednak g��boko przekonany �e je�li by cho� 10-15
min m�wi� techniczny to bardziej by zach�ci� potencjalnych kandydat�w do
aplikowania ;) wystarczy�o by par� s��w o projektach (bez podkre�lania
partnerstwa M$ ;) ) nawet jakieďż˝ anegdotki techniczne. Ale trzeba
przyzna� �e sponsor si� postara� - bo wys�anie a� 3 pracownik�w na
spotkanie javowe to nie byle co :)

--
Serdecznie Pozdrawiam,
Krzysztof Nielepkowicz
fotografia : fotomilo.pl

[Irek Matysiewicz]

W dniu 23 lutego 2012 15:56 użytkownik Michal Margiel <michal....@gmail.com> napisał:

Witajcie,

Nie mogę wyjść ze zdziwienia, że teraz jedną z miar "fajności"/"użyteczności" języka jest ilość nawiasów w kodzie.

Nie jest miarą użyteczności języka, ale jak za dużo nawiasów, to przynajmniej mi dwoi i troi się przed oczami i to utrudnia mocno czytanie kodu, a tam z tego co widziałem wszystko wymaga pary nawiasów.

[Irek Matysiewicz]

Oprócz wspomnianych przyczyn dlaczego JavaFX się nie przyjęło jest sporo, ktoś to zebrał na stronie: http://www.quora.com/Why-did-JavaFX-fail
Trzeba poczekać jeszcze ze dwie wersje, to podobnie jak EJB jest używalne dopiero od wersji 3.0 a Windows od wersji XP :-)

--

[Bartek Zdanowski]

2012/2/23 Vitaliy Oliynyk <xao...@gmail.com>

@Dawid Bielecki Kiedy będą ogłoszone wyniki losowania InteliJ IDEA?

+1 

Tu jest link. Wpisujcie imie nazwisko i mail.
 https://docs.google.com/spreadsheet/ccc?key=0AtG7no7pv0dcdEtpd1hOSWp5TUFBVFVpWWlwbzVhWlE

? 

W dniu 23 lutego 2012 12:15 użytkownik Dawid Bielecki <dawci...@gmail.com> napisał:

Kiedy będą ogłoszone wyniki losowania InteliJ IDEA?

--
Regards/Pozdrawiam,

Dawid Bielecki
http://www.dawciobiel.com
e-mail: dawciobiel AT gmail DOT com

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[Irek Matysiewicz]

A nie miało być tak że intellij zostanie rozlosowane wśród osób co wypełniły ankietę SMT?

[Łukasz Żuchowski]

Potwierdzam

W dniu 23 lutego 2012 19:54 użytkownik Irek Matysiewicz
<iir...@gmail.com> napisał:

--
Pozdrawiam,

Łukasz

[Dawid Bielecki]

Zgadza się, chyba, że losowanie za ankiety jest losowaniem dodatkowej
licencji.

[Bartek Zdanowski]

Losowanie licencji podarowanej przez JetBrains nie wymaga podpisywania
zadnych papierow. Nalezy na spotkaniu byc i rozmnozyc sie do 30+
uczestnikow.
Tyle wiem. Co wypelnialiscie i kto zafunduje w zw z tym Idee, tego nie
wiem. O co chodzi?

--
Sent from my mobile device

[Łukasz Żuchowski]

Bartku. Był sponsor i Jacek zarządził, że licencja zostanie
rozlosowana wśród osób które wypełnią ankietę. Także, pytanie kieruj
do niego. Była też puszczona lista obecności ale nie wiem kto ją ma.

[Mariusz Wziątek]

... lista leżała u dziewczyn, na na stoliku

Pozdrawiam
Mariusz Wziątek

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).

Więcej informacji na stronie http://...

[Jacek Laskowski]

2012/2/23 Łukasz Żuchowski <lukasz.z...@gmail.com>:

> Bartku. Był sponsor i Jacek zarządził, że licencja zostanie
> rozlosowana wśród osób które wypełnią ankietę. Także, pytanie kieruj
> do niego. Była też puszczona lista obecności ale nie wiem kto ją ma.

Potwierdzam. Była to bardziej zachęta do wypełniania ankiet niż
faktycznie wymaganie i teraz czytam, ile zamieszania wprowadziłem.

Listę osób już dostałem od naszego sponsora i wśród tych nazwisk
wylosuję zwycięzcę. Naliczyłem na spotkaniu prawie 50 osób (około 45),
ankietę wypełniło 39. Zgodnie z zasadami naszych spotkań, jak napisał
Bartek, żadna ankieta nie jest konieczna do wypełnienia. Jeśli jest
osoba, która nie wypełniła ankiety, a chce wziąć udział w losowaniu,
proszę o kontakt i dodam do puli.

Losowanie licencji w niedzielę, 26.02 (godzina bliżej nieznana, bo to
w końcu weekend! :)).

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

[Jacek Laskowski]

2012/2/23 Łukasz Żuchowski <lukasz.z...@gmail.com>:

> Warto jednak, żeby wcześniej ustalić ile mają czasu na keynote

Odnotowane. Ile proponujesz czasu na przemówienie? 5 czy bliżej 10 minut?

[Jacek Laskowski]

2012/2/23 Krzysztof Nielepkowicz <k.p.niel...@gmail.com>:

> Może z innej beczki, mam taki pomysł by sponsorzy zamiast 3 osób z PR
> przysłali kogoś technicznego. No dobra - moze być 2*PR + 1TECH.

Na to nie mamy wielkiego wpływu. Czy to nie jest tak, że jak przyślą
leszcza, to leszczy zatrudnią? Czym bardziej zależy sponsorowi,
komukolwiek, tym bardziej się przygotuje i dopyta o klientelę. Wszyscy
się uczymy i jednocześnie dopasowujemy do siebie. Na pewno z każdym
spotkaniem będzie przyjemniej.

[Maciej Jaśkowski]

to ja sie zgłaszam do losowania w takim razie :)

MJ

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).

> Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl

[Jacek Laskowski]

2012/2/23 Irek Matysiewicz <iir...@gmail.com>:

> - stwierdziłeś że w typowym kodzie Clojure jest mniej nawiasów niż w Javie.

Zapomnij o tym. Bardzo żałowałem tego porównania, bo jak pamiętasz,
deklarowałem brak tego typu wtrąceń, które większość może zrazić niż
zachęcić do spróbowania się z Clojure. Spróbuję Ci odpowiedzieć na to
pytania podczas kolejnego spotkania w postaci kawałków kodu, który
napiszemy wspólnie. Sam ocenisz, czy w tym stwierdzeniu może być
ziarenko prawdy. Zgoda?

> - mówisz że homoikoniczność jest super, ale i w Javie w kilka dni mogę
> napisać coś takiego...

Wszystko można. W końcu Clojure to bajtkod, więc prawie Java (od tej
pory Java jest dla mnie DSLem do generowania bajtkodu, podobnie jak
Clojure). Zaprezentuję zalety homoikoniczności podczas kolejnych
spotkań o Clojure, kiedy zaprezentuję makra. Tam znaczenie
jednolitości struktur danych z kodem wykonywalnym będzie bardziej
oczywista. To jednak za dopiero miesiąc. Teraz nie czuję się na siłach
i pewnie sprawiłbym Ci jeszcze większy zawód (i sobie upewniając Cię w
mylnym przekonaniu, że homoikoniczność nie jest cacy :)).

> Przekonaj mnie że nie mam racji. :-)

Wolę inne podejście. Ja zaprezentuję, co wiem na temat Clojure, a że
nie ma tego wcale tak wiele, nie powinno to trwać długo. Za 2 tygodnie
mamy pierwsze spotkanie, więc będzie można zobaczyć kod i narzędzia
wspierające budowanie projektów z Clojure. Później konferencja 33rd
degree w Krakowie, później 4Developers w Poznaniu (może w międzyczasie
devcrowd w Szczecinie i może GeeCON) i powinienem spełnić Twoją prośbę
częściowo. Zachęcam do udziału i zadawania pytań.

[Irek Matysiewicz]

W dniu 24 lutego 2012 00:19 użytkownik Jacek Laskowski <ja...@japila.pl> napisał:

2012/2/23 Irek Matysiewicz <iir...@gmail.com>:

> - stwierdziłeś że w typowym kodzie Clojure jest mniej nawiasów niż w Javie.

Zapomnij o tym. Bardzo żałowałem tego porównania, bo jak pamiętasz,
deklarowałem brak tego typu wtrąceń, które większość może zrazić niż
zachęcić do spróbowania się z Clojure. Spróbuję Ci odpowiedzieć na to
pytania podczas kolejnego spotkania w postaci kawałków kodu, który
napiszemy wspólnie. Sam ocenisz, czy w tym stwierdzeniu może być
ziarenko prawdy. Zgoda?

Ale się migasz od odpowiedzi :-)
Porównania są użyteczne bo dają jakiś kontekst i od razu wiadomo co do czego.

Przychodzi mi tylko jedna praktyczna sytuacja kiedy w Javie będziesz miał rozlazły kod z dużą liczbą nawiasów a w Clojure ładny zwięzły i wynika on z braku niektórych rzeczy w Javie, głównie wyrażeń lambda.
 
To zróbmy inne porównanie: gdzie będzie mniej nawiasów - w Groovym/Scali czy w Clojure - tu na pewno Clojure bezapelacyjnie przegra :-)

Brak nawiasów i notacja infiksowa znana z innych języków to wg mnie dobra rzecz bo ułatwia czytanie kodu.

Coś wspominałeś że Clojure ma możliwość ominięcia nawiasów dzięki makrom, ale nie jest to czasem przyznawanie się twórców Clojure  do błędu, że jednak inne języki są lepsze?

Moim zdaniem jedyna zaleta Clojure z tego co na razie widzę: łatwiej jest parsować pozagnieżdżane nawiasy (wystarczy zwykły stos) niż "normalny" język programowania (potrzebne gramatyki, parsery, itd...), ale napisanie parsera "normalnego" języka programowania też nie jest jakoś kosmicznie trudne bo są do tego gotowe narzędzia.

Może trochę d... zawracam ale szukam odpowiedzi na jedno pytanie: dlaczego warto zainteresować się Clojure? Wiem dlaczego warto zainteresować się Groovym, Scalą, ale dla Clojure powodu zupełnie nie widzę. :-(

[Jacek Laskowski]

2012/2/24 Irek Matysiewicz <iir...@gmail.com>:

> Ale się migasz od odpowiedzi :-)
> Porównania są użyteczne bo dają jakiś kontekst i od razu wiadomo co do
> czego.

Za słabym w temacie, aby odpowiedzieć właściwie, a czuję, że poziom
zainteresowania u Ciebie wzrasta i szkoda byłoby to stracić. Wolę
przetrzymać Cię chwilę.

> Może trochę d... zawracam ale szukam odpowiedzi na jedno pytanie: dlaczego
> warto zainteresować się Clojure? Wiem dlaczego warto zainteresować się
> Groovym, Scalą, ale dla Clojure powodu zupełnie nie widzę. :-(

Możesz napisać, dlaczego warto poznać Groovy albo Scala? Pewnie takie
same argumenty przemawiają za Clojure.

Uważam, że ewolucja programisty javowego idzie przez poznanie Groovy,
później Scala, ale na końcu powinien (musi?) być Clojure, bo tylko on
uzmysławia wady i zalety programowania obiektowego (albo funkcyjnego,
zależy na czym Ci zależy). Cała rzecz w tym, czy Ty w ogóle możesz
przyjąć zarzucenie programowania obiektowego na rzecz innego
paradygmatu? Coś mi mówi, że niekoniecznie. Szukasz powodów, aby
upewnić się w swoim myśleniu, że Java, Groovy, Scala są cacy, bo tak
wygodniej - przyzwyczajenia biorą górę i ciągle siedzisz tam, gdzie
byłeś 10 lat temu, kiedy Java zdobywała rynek. Wybacz bezpośredniość,
ale poszukuję wytłumaczenia na próbę porównania języków. Według mnie,
na początku bardzo pożądane, aby przekonać się o wartości poznania
nowego, ale niezwykle trudne, aby dopasować do rozmówcy. Możliwe
wytłumaczenie?

[Irek Matysiewicz]

W dniu 24 lutego 2012 12:34 użytkownik Jacek Laskowski <ja...@japila.pl> napisał:

2012/2/24 Irek Matysiewicz <iir...@gmail.com>:

> Ale się migasz od odpowiedzi :-)
> Porównania są użyteczne bo dają jakiś kontekst i od razu wiadomo co do
> czego.

Za słabym w temacie, aby odpowiedzieć właściwie, a czuję, że poziom
zainteresowania u Ciebie wzrasta i szkoda byłoby to stracić. Wolę
przetrzymać Cię chwilę.

ale się migasz...

Uważam, że ewolucja programisty javowego idzie przez poznanie Groovy,
później Scala, ale na końcu powinien (musi?) być Clojure, bo tylko on
uzmysławia wady i zalety programowania obiektowego (albo funkcyjnego,
zależy na czym Ci zależy).

Dlaczego tylko Clojure to uzmysławia, a Groovy/Scala nie?

 

Cała rzecz w tym, czy Ty w ogóle możesz
przyjąć zarzucenie programowania obiektowego na rzecz innego
paradygmatu? Coś mi mówi, że niekoniecznie. Szukasz powodów, aby
upewnić się w swoim myśleniu, że Java, Groovy, Scala są cacy, bo tak
wygodniej - przyzwyczajenia biorą górę i ciągle siedzisz tam, gdzie
byłeś 10 lat temu, kiedy Java zdobywała rynek.

Zróbmy test jak testy sprzętu w czasopismach komputerowych:
- programowanie obiektowe: Groovy 1, Scala 1, Clojure 0 (czy się mylę?)
- programowanie funkcyjne: Groovy 0.5, Scala 1, Clojure 1
- znajomość składni (po co mam marnować czas na naukę nowego): Groovy 1, Scala 0.5, Clojure 0
RAZEM: Groovy 2.5, Scala 2.5, Clojure 1

O czymś zapomniałem?
Jak masz problem z przekonaniem mnie do Clojure, jak przekonasz ludzi jak będziesz występował na płatnych konferencjach?

[Łukasz Żuchowski]

Myślę, że nie jest tak bardzo istotne ile tego czasu będzie ale aby było to ustalone z góry. Ja proponuje 10 minut. Ale jeżeli sponsor będzie miał specjalne życzenia to możemy to rozpatrywać indywidualnie. Warto jednak mieć z góry określą propozycję dla ewentualnych chętnych.

[Łukasz Żuchowski]

A czy zawsze chodzi o przekonywanie ? Czy zawsze chodzi o to który
język ma więcej punktów ?

Mi się prezentacja Jacka podobała. Choćby dlatego, że nie skupiała się
na porównywaniu jak prezentacja poprzednika. Fajne było założenie, że
słuchacze znają tylko Javę. Na pewno sprawia to, że łatwiej jest
znaleźć wspólny język i trudniej zgubić się gdzieś po drodze, przy
porównaniach do innych języków (zwłaszcza do ich funkcyjnej części).
Jestem ciekawy drugiej części.

Co więcej czy naprawdę wszechstronność jest zawsze zaletą ? Jeżeli
tak fachowcy zamiast skrzynek z narzędziami, każdym do innej
czynności/zadania nosili w kieszeni szwajcarski scyzoryk w wersji max.
Myślę, że nie można "winić" Clojure za brak wsparcia obiektowego
jeżeli jest to język funkcyjny.
Ja uważam, że programowanie funkcyjne nadaje się do pewnych
określonych części aplikacji i w tandemie z Javą może być fajną
mieszanką. Przy dużych projektach fajnie mieć kontrolę typów i
bezpieczeństwo pisania w Javie oraz dostępne tabuny deweloperów. A tam
gdzie kluczowe będzie przetwarzanie można zrobił moduły w Clojure i
mieć od tego 2-3 magików. Co więcej mam separację tych dwóch podejść
co może być zaletą i ułatwić obu typom programistów (tych
wyspecjalizowanych funkcyjnie i obiektowo pracę).

Ciekawe i prowokacyjne było przez Jack podważenie sensu programowania
obiektowego w które ja mocno wierze i myślę, że to coś więcej niż
tylko enkapsulacja. Ale to już temat na osobne rozważania.

W dniu 24 lutego 2012 14:02 użytkownik Irek Matysiewicz
<iir...@gmail.com> napisał:
>
>

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Pozdrawiam,

Łukasz

[Irek Matysiewicz]

Ja uważam, że programowanie funkcyjne nadaje się do pewnych
określonych części aplikacji i w tandemie z Javą może być fajną
mieszanką.

No ale to samo masz w Groovim/Scali. Dlaczego Clojure jest lepsze od nich? Dla mnie Clojure to byłaby bardziej możliwość uruchomienia starych programów w LISP pod JVM.

[Łukasz Żuchowski]

Być może Groovy będzie stanowił zbyt wielką pokusę by w tych miejscach
pisać nie tylko funkcyjnie ale cichcem wprowadzi się obiektowość ;-)
Nie uważam, że Clojure jest lepsze tylko, że brak wsparcia
obiektowości go nie dyskredytuje przy takim podejściu. Co nie oznacza,
że nie ma innych argumentów przeciw Clojure ale ten do mnie nie
przemawia.

W dniu 24 lutego 2012 14:31 użytkownik Irek Matysiewicz
<iir...@gmail.com> napisał:
>

[Tomek Lipski]

IMHO bez szans na uruchomienie starych programów w Lispie pod JVM.
Lisp to różne dialekty (Scheme, ANSI Common Lisp, Clojure, Emacs Lisp,
Rep, ...), z różnymi możliwościami. Np. z tego co się orientuję, to
reader macros nie są wspierane w Clojure - a dużo programów w ANSI CL
z nich korzysta.

Jeśli potrzebujesz odpalić program w ANSI Common Lispie pod JVM
(chociaż SBCL to też całkiem niezła maszyna wirtualna), to raczej ja
bym patrzył na ABCL - to jest implementacja ANSI CL pod JVM, dość
świeża oczywiście, ale chyba już sporo bibliotek działa. Co akurat
jest normalne przy Common Lispie, że przenośność pomiędzy nawet
różnymi implementacjami jest często czysto teoretyczna i wymaga
warunków w kodzie.

Co do lepszości Clojure od Scali/Groovego - tu już każdy musi sam
wyrobić zdanie. To jednak jest kwestia osobista a nie uniwersalna moim
zdaniem.

t

[Bartek Zdanowski]

Jacku,

2012/2/24 Jacek Laskowski <ja...@japila.pl>:

>> Losowanie licencji w niedzielę, 26.02 (godzina bliżej nieznana, bo to
> w końcu weekend! :)).

w takim razie czekam na imię, nazwisko i maila zwycięzcy, potem
załatwiam licencję.

[Tomek Lipski]

On 24 Lut, 14:35, Łukasz Żuchowski <lukasz.zuchow...@gmail.com> wrote:
> Być może Groovy będzie stanowił zbyt wielką pokusę by w tych miejscach
> pisać nie tylko funkcyjnie ale cichcem wprowadzi się obiektowość ;-)
> Nie uważam, że Clojure jest lepsze tylko, że brak wsparcia
> obiektowości go nie dyskredytuje przy takim podejściu. Co nie oznacza,
> że nie ma innych argumentów przeciw Clojure ale ten do mnie nie
> przemawia.

Warto tutaj zaznaczyć, że Clojure dostarcza mechanizmy i koncepcje
łączone często z OOP, takie jak np. runtime polimorfizm (http://
clojure.org/multimethods).
Od 1.2 mamy też np. protokoły (http://clojure.org/Protocols) jeśli
chodzi o jakieś standaryzowanie tego, co ma robić dany kod. Typy
danych oczywiście można definiować, jeśli ktoś lubi - http://clojure.org/datatypes
.

W książce Paula Grahama - ANSI Common Lisp (http://paulgraham.com/
acl.html) jest implementacja podstawowego OOP na 3 stronach książki,
więc brak OOP w Clojure jest też raczej kwestią idiomatyczności kodu i
tego, że tak się po prostu lepiej pisze w większości przypadków. ANSI
Common Lisp też na początku nie miał CLOS (Common Lisp Object System)
- główna specyfikacja to 1984 z tego co się orientuję, zaś CLOS -
1987-88.

t

[ags]

Jacku, a SICPa czytałeś? ;-)

2012/2/24 Jacek Laskowski <ja...@japila.pl>

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--

ags

[Jacek Laskowski]

2012/2/24 Irek Matysiewicz <iir...@gmail.com>:

> ale się migasz...

Wierz mi, że to nie o migranie chodzi, ale o moje przygotowanie, bo
stawką teraz jest właściwe wprowadzenie Clojure jako języka
funkcyjnego i uważam, że trzeba to robić baaaaardzo delikatnie i
właściwie. Nie sądzę, abym był przygotowany do takiego "ataku"
wkrótce. Sam jeszcze nie czuję zalet Javy jako języka obiektowego czy
Clojure jako język funkcyjny.

Ale możesz mi pomóc :)

Dlaczego uważasz, że warto inwestować czas w Javę? Co jest w samym
języku (nie piszę o JVM), co uwypukliłbyś w gronie, które przez całe
życie programowało w C++, albo Pascalu i teraz miałoby programować w
Javie?

> Dlaczego tylko Clojure to uzmysławia, a Groovy/Scala nie?

Groovy i Scala nie są językami funkcyjnymi. To hybrydy, które
umożliwiają programowanie funkcyjne, w których rzadko będzie to
podstawowym narzędziem. Uważam, że oba będą traktowane jak C++ w
stosunku do C - można programować funkcyjnie ale skoro znam OO, co mi
tam zmieniając myślenie.

Odnoszę wrażenie, że do poznania programowania funkcyjnego i czerpania
z niego korzyści należy zmienić myślenie, a Groovy i Scala w tym nie
pomagają. Pozwalają, ale jedynie Clojure wymusza.

> Zróbmy test jak testy sprzętu w czasopismach komputerowych:
> - programowanie obiektowe: Groovy 1, Scala 1, Clojure 0 (czy się mylę?)

Clojure pozwala na zbudowanie systemu obiektowego - opisane chociażby
w Clojure in Action. Co więcej, dzięki multimetods i let-over-lambda
możesz zbudować system z dowolnym rozumieniem dziedziczenia i
polimorfizmu. Kiedy o tym czytałem, prawie oderwało mi głowę! :)
Chciałbym móc przygotować się na tyle, aby zaprezentować to podczas
naszego spotkania. Może uda mi się to już na kolejne spotkanie. Byłoby
cudnie patrzeć, jak urywa Wasze :)

> - znajomość składni (po co mam marnować czas na naukę nowego): Groovy 1,
> Scala 0.5, Clojure 0

W Clojure prawie nie ma składni - są jedynie nawiasy :)

> RAZEM: Groovy 2.5, Scala 2.5, Clojure 1
>
> O czymś zapomniałem?

Programowanie wielowątkowe - GPars, Akka i w Clojure różnorodnie.
Chciałbym móc z kimś to porównać. Zdecydowałby się ktoś na prezentację
GPars i Akka.
Trwałość struktur danych
Niezmienność struktur

Pewnie kilka innych kategorii, które zbliżyłyby te języki do siebie,
co dla mnie ma tę zaletę, że nie wykluczyłoby Clojure. Nie zależy mi
na wyłonieniu Clojure jako zwycięzcy, a jedynie, aby rozważyć go jako
wartościowy język programowania.

> Jak masz problem z przekonaniem mnie do Clojure, jak przekonasz ludzi jak
> będziesz występował na płatnych konferencjach?

Cóż. Nie dane mi pewnie będzie zarobić na nich. Wystarczy mi, że przy
rozważaniu wartościowych języków na JVM pojawia się Clojure. Pewnie
mądrzejści ode mnie, wiedzą dlaczego, ale mnie nie dane jest jeszcze
umiejętne przedstawienie zalet Clojure. Pracuję nad tym i dziękuję Ci
za zintensyfikowanie wysiłków!

[Jacek Laskowski]

2012/2/24 Tomek Lipski <tomek....@gmail.com>:

> Np. z tego co się orientuję, to reader macros nie są wspierane w Clojure

Są wspierane, np. lista to '(), dostęp do zmiennych struktur
chronionych przed równoczesnym dostępem - ref, atom, agents przez @
i...zapraszam do lektury http://clojure.org/reader.

> Co do lepszości Clojure od Scali/Groovego - tu już każdy musi sam
> wyrobić zdanie. To jednak jest kwestia osobista a nie uniwersalna moim
> zdaniem.

Nie sądzę, aby można było określić lepszość jednego języka nad drugim,
bo podobnie możnaby zrobić z językami naturalnymi. Nawet, jeśli wydaje
nam się, że angielski to język zwycięzca, znajomość innych można
znacząco pomóc, jeśli nie być obowiązkiem.

Trochę prowokacyjnie, aby ustawić nasze myślenie na inne tory.
Zapominając o Clojure na moment - który język jest lepszy - Groovy czy
Scala? Dlaczego? Niemożność odpowiedzi na to pytanie jest moim
argumentem, aby właśnie tego nie robić. Lepiej poznać oba!

[Jacek Laskowski]

2012/2/24 ags <andrzej...@gmail.com>:

> Jacku, a SICPa czytałeś? ;-)

Zacząłem, ale poległem. Będę musiał do tego wrócić jednak, bo wielu
znawców tematu Clojure poleca jako lekturę obowiązkową.

[Jacek Laskowski]

2012/2/24 Łukasz Żuchowski <lukasz.z...@gmail.com>:

> Myślę, że nie jest tak bardzo istotne ile tego czasu będzie ale aby było to
> ustalone z góry. Ja proponuje 10 minut. Ale jeżeli sponsor będzie miał
> specjalne życzenia to możemy to rozpatrywać indywidualnie. Warto jednak mieć
> z góry określą propozycję dla ewentualnych chętnych.

Bardzo odpowiedzialne podejście! Podoba mi się i przy następnych
negocjacjach, kiedy zarzucą mi stanowczość (zamiast pochwalić!),
powiem, że to zasługa społeczności, a dokładniej Łukasza :)

[Irek Matysiewicz]

Dlaczego uważasz, że warto inwestować czas w Javę? Co jest w samym
języku (nie piszę o JVM), co uwypukliłbyś w gronie, które przez całe
życie programowało w C++, albo Pascalu i teraz miałoby programować w
Javie?

Jeśli mówimy tylko o samym języku, Java jest trochę słabszym językiem niż taki C++. Bez przedstawiania zalet JVM C++-owca do Javy chyba nie przekonasz.

Groovy i Scala nie są językami funkcyjnymi. To hybrydy, które
umożliwiają programowanie funkcyjne,

Ale sam dalej przyznałeś że Clojure też umożliwia programowanie obiektowe, czyli też w pewnym, choć może trochę mniejszym stopniu jest taką hybrydą.
 
Jak już było niedawno w którymś wątku, programowanie funkcyjne jest fajne, ale niektóre rzeczy robić tam to jak naciągać gacie przez głowę i wg mnie potrzebujemy właśnie takich hybryd.
(Ale (((zupełnie (nie widzę)) (sensu (dla ((pełnej nawiasów) (składni Clojure))))).

[Tomasz Szymański]

On Thu, Feb 23, 2012 at 5:01 PM, Bartek Kuczyński <bjkuc...@gmail.com> wrote:

Zobacz co stało się z javaFX Script czy Cobolem. Poległy ponieważ miały "składnię odbiegającą od przyjętych
norm".

No chyba zartujesz ! W prawie kazdym banku sa ciagle systemy pisane w cobolu. Do dzisiaj! Stoja i czasami nawet sa rozwijane ;-)

T. 

[Tomek Lipski]

On Feb 25, 5:52 pm, Jacek Laskowski <ja...@japila.pl> wrote:
> 2012/2/24 Tomek Lipski <tomek.lip...@gmail.com>:

>
> > Np. z tego co się orientuję, to reader macros nie są wspierane w Clojure
>
> Są wspierane, np. lista to '(), dostęp do zmiennych struktur
> chronionych przed równoczesnym dostępem - ref, atom, agents przez @
> i...zapraszam do lekturyhttp://clojure.org/reader.

Doskonale wiem, że Clojure ma swoje reader macros, ale nie są one
dostępne z poziomu języka -
w przeciwieństwie do np. Common Lispa. Idąc powyższym tokiem
rozumowania - Java też ma reader macros,
bo np. { "a", "b", "c" } tworzy tablicę ;-). Cytując z linka, który
podesłałeś: "The read table is currently not accessible to user
programs." i z tego co się orientuję, jest to świadoma decyzja.

Reader macros to funkcjonalność opisana np. tutaj:
http://dorophone.blogspot.com/2008/03/common-lisp-reader-macros-simple.html

Przykład zastosowania reader macros w praktyce, to biblioteka CLSQL,
gdzie na przykład budujemy wyrażenia SQLowe za pomocą nawiasów
kwadratowych (które w Common Lispie nie pełnią specjalnej funkcji - w
przeciwieństwie do Clojure).

Oczywiście dla jasności sytuacji - są próby realizacji reader macros w
Clojure, np. tutaj https://github.com/klutometis/reader-macros - ale
jednak działają trochę nieoficjalnie, np. zmieniając implementację
Clojure w locie (https://github.com/klutometis/reader-macros/blob/
master/src/reader_macros/core.clj).

t

[Bartek Kuczyński]

> No chyba zartujesz ! W prawie kazdym banku sa ciagle systemy pisane w cobolu. Do dzisiaj! Stoja i czasami nawet sa rozwijane ;-)

To ja wiem, że są i czasami są rozwijane. Nawet sam to robię :D
Chodziło mi raczej o "śmierć społeczną". Cobola douczam się
samodzielnie w miarę potrzeb. Nigdzie nie kupisz dziś świeżej książki
o tym języku. Trwa on sobie w świecie mainframów , ale nie istnieje
już jako język nauczany czy jakoś dynamicznie rozwijany. Aktualizacje
w stylu Cobol 2000 służą już tylko do przystosowania języka i
kompilatorów do współczesnej architektury i sysopów.

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

W dniu 25 lutego 2012 20:50 użytkownik Tomek Lipski
<tomek....@gmail.com> napisał:

[Tomek Lipski]

> Jak już było niedawno w którymś wątku, programowanie funkcyjne jest fajne,
> ale niektóre rzeczy robić tam to jak naciągać gacie przez głowę i wg mnie
> potrzebujemy właśnie takich hybryd.
> (Ale (((zupełnie (nie widzę)) (sensu (dla ((pełnej nawiasów) (składni
> Clojure))))).

Ojej, naprawdę nie rozumiem, co ludziom przeszkadzają nawiasy. Jak w
każdym języku, jeśli kod jest poprawnie sformatowany, to na nawiasy
rzadko zwraca się uwagę.
Porównajmy powyższe z Javą (z przymrużeniem oka oczywiście):
(new Ale(new Zupełnie(new Widzę(false))) (new Sensu (Przyimki.dla(new
Składnia(Języki.Java).setPełna(new Nawiasów)))))

OOP w Clojure - Clojure czy ogólnie dialekty Lispa, mają tą zaletę
(dla mnie), że można przyjąć model programowania pasujący do danego
problemu i nadal język będzie wspierał programistę a nie rzucał mu
kłody pod nogi. Po prostu Lisp (unix czy piła tarczowa także) zakłada,
że
programista/użytkownik jest myślącym, świadomym człowiekiem i nie
należy być mądrzejszym od niego. Co sprawia, że tak - można zrobić
więcej, ale też
łatwiej sobie zrobić krzywdę niż np. w Javie (co nie znaczy, że ludzie
nie robią sobie krzywdy w Javie - jasne, że robią!).

t

[Irek Matysiewicz]

Ojej, naprawdę nie rozumiem, co ludziom przeszkadzają nawiasy. Jak w
każdym języku, jeśli kod jest poprawnie sformatowany, to na nawiasy
rzadko zwraca się uwagę.

Po prostu: przyjęło się pisać "x+y*z" czy "f(x, y)" a nie "(+ x (* y z))" czy "(f x y)" - taki zwyczaj. Nowa składnia tu nic nowego dla programisty nie daje, a wręcz przeszkadza bo łamie przyjęty zwyczaj i wymaga niepotrzebnego trudu w celu przyzwyczajania się do nowego.

Jacek mówi że Clojure potrafi fajne rzeczy - jest to zapewne zaleta bibliotek, kompilatora bądź interpretera, a na pewno nie nietypowej składni (dla kompilatora sparsowany program to i tak drzewo). Wystarczy poznać te fajne rzeczy i przenieść je na grunt Javy/Grooviego/Scali (o ile już ich tam nie ma, pewnie są tylko inaczej się nazywają).

[Michal Margiel]

W dniu 25 lutego 2012 20:57 użytkownik Bartek Kuczyński <bjkuc...@gmail.com> napisał:

> No chyba zartujesz ! W prawie kazdym banku sa ciagle systemy pisane w cobolu. Do dzisiaj! Stoja i czasami nawet sa rozwijane ;-)

To ja wiem, że są i czasami są rozwijane. Nawet sam to robię :D
Chodziło mi raczej o "śmierć społeczną". Cobola douczam się
samodzielnie w miarę potrzeb. Nigdzie nie kupisz dziś świeżej książki
o tym języku. Trwa on sobie w świecie mainframów , ale nie istnieje
już jako język nauczany czy jakoś dynamicznie rozwijany. Aktualizacje
w stylu Cobol 2000 służą już tylko do przystosowania języka i
kompilatorów do współczesnej architektury i sysopów.

Bartek.. chyba się trochę zagalopowujesz w swoich stwierdzeniach. Śmierć społeczną? świeżej książki? licząc od daty  rozpoczęcia prac nad tym językiem (1959) COBOL jest już na rynku ponad 50 lat. Java nie jest nawet 20 (tak czy siak całkiem sporo). Więc takie porównania to wyciągnij z kieszeni za 30 lat. 

--
Pozdrawiam/Best regards
Michał Margiel

http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu

[Jacek Laskowski]

2012/2/25 Irek Matysiewicz <iir...@gmail.com>:

> Jeśli mówimy tylko o samym języku, Java jest trochę słabszym językiem niż
> taki C++. Bez przedstawiania zalet JVM C++-owca do Javy chyba nie
> przekonasz.

I to jest właśnie mój punkt widzenia. Jeśli siedzę w Javie, to po co
mi Groovy/Scala, jeśli nie dla uproszczeń składniowych?! Clojure
wymusza myślenie funkcyjne, które wymusza zmianę myślenia i patrzenia
na otaczający nas świat (którego abstrakcję budujemy w naszych
aplikacjach) dla programistów javowych. Scala/Groovy tylko na to
pozwalają. Możnaby rzecz, że zachęcają w pewnym sensie.

> Ale sam dalej przyznałeś że Clojure też umożliwia programowanie obiektowe,
> czyli też w pewnym, choć może trochę mniejszym stopniu jest taką hybrydą.

Clojure umożliwia konstrukcjami języka zbudowanie systemu obiektowego,
ale sam z siebie nie jest obiektowy, bo i po co?! Pojęcie obiektu jest
zwykle modelowane przez mapę (aka rekord). Właśnie dzięki Clojure
dostrzegłem brak niezwykłości w systemie klas - do niedawna tworzenie
klas było dla mnie jedynym słusznym podejściem, teraz jedynie opcją.

Clojure wymusza programowanie funkcyjne, a pozwala zbudować system
(para)obiektowy. Scala/Groovy pozwalają na programowanie obiektowe i
funkcyjne. Dostrzegasz brak "wymusza" w drugim zdaniu? To jest dla
mnie zaleta Clojure - na razie bardziej naukowa/teoretyczna niż
projektowa/praktyczna.

[Bartek Kuczyński]

Michał, ale ja mam porównanie do np. Fortrana (podobny wiek), którego
uczyli mnie na studiach. Cobola po prostu się nie uczy. W Fortranie
nadal robi się dziś projekty (akademickie) i nadal jest on rozwijany.
Cobol choć posiada ogromną część rynku aplikacji bankowych czy ogólnie
biznesowych to nie jest już w żaden sposób rozwijany poza tym co
pisałem, czyli dostosowaniem do istniejącej architektury i systemów.
Wystarczy zresztą porównać jak na Amazonie wygląda sprawa książek "dla
początkujących"

Fortran: http://www.amazon.com/s/ref=sr_nr_n_2?rh=n%3A283155%2Cn%3A!1000%2Cn%3A5%2Cn%3A3839%2Ck%3Afortran%2Cn%3A3944&bbn=3839&keywords=fortran&ie=UTF8&qid=1330206436&rnid=3839

Cobol: http://www.amazon.com/s/ref=sr_nr_n_3?rh=n%3A283155%2Cn%3A!1000%2Cn%3A5%2Cn%3A3839%2Ck%3Acobol%2Cn%3A3944&bbn=3839&keywords=cobol&ie=UTF8&qid=1330206405&rnid=3839

Nowości cobolowe są jeszcze z czasów mocno przedjavowych, a jak chcesz
się nauczyć Fortrana to nawet jakieś nowości z tego roku są.

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

W dniu 25 lutego 2012 22:33 użytkownik Michal Margiel
<michal....@gmail.com> napisał:

[Jacek Laskowski]

2012/2/25 Irek Matysiewicz <iir...@gmail.com>:

> (Ale (((zupełnie (nie widzę)) (sensu (dla ((pełnej nawiasów) (składni
> Clojure))))).

A takie coś satysfakcjonowałoby Cię?

(-> Clojure
składni
(pełnej nawiasów)
dla
sensu
(nie widzę)
zupełnie
Ale)

:-)

[sebastian.konkol]

Tak mi się skojarzyło, że w takim razie w Clojure trzeba chyba tworzyć
kod jak Yoda zdania w GW :-).

On 25 Lut, 22:52, Jacek Laskowski <ja...@japila.pl> wrote:
> 2012/2/25 Irek Matysiewicz <iir...@gmail.com>:
>
> > (Ale (((zupełnie (nie widzę)) (sensu (dla ((pełnej nawiasów) (składni
> > Clojure))))).
>
> A takie coś satysfakcjonowałoby Cię?
>
> (-> Clojure
>      składni
>      (pełnej nawiasów)
>      dla
>      sensu
>      (nie widzę)
>      zupełnie
>      Ale)
>
> :-)
>
> Jacek
>
> --
> Jacek Laskowski

> Functional languages (Clojure), Java EE, and IBM WebSphere -http://blog.japila.pl

[Irek Matysiewicz]

> Ale sam dalej przyznałeś że Clojure też umożliwia programowanie obiektowe,
> czyli też w pewnym, choć może trochę mniejszym stopniu jest taką hybrydą.

Clojure umożliwia konstrukcjami języka zbudowanie systemu obiektowego,
ale sam z siebie nie jest obiektowy, bo i po co?! Pojęcie obiektu jest
zwykle modelowane przez mapę (aka rekord). Właśnie dzięki Clojure
dostrzegłem brak niezwykłości w systemie klas - do niedawna tworzenie
klas było dla mnie jedynym słusznym podejściem, teraz jedynie opcją.

Rozumiem do czego zmierzasz: minimalistyczny język, a jego funkcjonalności rozszerzane za pomocą bibliotek (a nie wszystko wbudowane w kompilator). I zapewne do tego potrzebna jest (składnia (pełna (nawiasów))), bo dodanie dowolnej nowej konstrukcji do języka nie zmienia jego gramatyki formalnej, czyli możemy użyć ciągle tego samego kompilatora.
Ale czy to wszystko warte zachodu? Ja już chyba wolę kompilatory-molochy które same wszystko potrafią. :-)

[medyk]

Moje 3 grosze odnośnie spotkania:
1) O prezentacji Jacka mogę się wypowiedzieć w samych superlatywach,
ciekawa, od dobrej strony i w odpowiedniej wielkości kęsach ugryziona.
Wprost nie mogę się doczekać następnego JUGa, mam nadzieję, że poza
obiecanym kodem Jacek powie też kilka słów o tym jak to pożenić z
Javą.
2) Co do prezentacji Maćka to niestety spory minus, bo miała być
prelekcja na temat "Scala na tle Java EE i Lift", a było samo
wprowadzenie do Scali, a z tego co wiem, nie tylko ja się szykowałem
na część "na tle". Minus wyłącznie za nietrzymanie się tematu, sama
prezentacja bez większych zgrzytów, choć sam temat przynajmniej dla
mnie nieciekawy.
3) Sponsor jak to sponsor, ma swoje prawa i poza ograniczeniem czasu
na keynote do 10, max 15 minut nie powinniśmy narzucać innych
wymagań.

A poza konkursem dobrą praktyką byłoby umieszczanie gdzieś slajdów.

On 22 Lut, 10:41, Jacek Laskowski <ja...@japila.pl> wrote:
> 2012/2/21 Jacek Laskowski <ja...@japila.pl>:
>
> > Dzisiaj, 21.02.2012, punktualnie o 18:00 rozpoczynamy party Warszawa JUG!
>
> I już po spotkaniu. Wierzę, że było równie produktywne dla Was, co dla
> mnie. Poprawki do slajdów są nanoszone i kolejna ich odsłona już za 2
> tygodnie we wtorek.
>
> Zbieram tym samym komentarze o wadach i zaletach spotkań w tej formule
> - 2 prelegentów, sponsor, pizza.
>
> Co się Tobie podobało, a co irytowało, a może wręcz nie życzysz [*]
> sobie tego typu "przerywników" podczas kolejnych spotkań? Czy
> spodziewałeś się innego układu spotkania? Czy występ sponsora po
> pizzy, a przed wystąpieniami, był wartościowy? Co byś zmienił? Co byś
> usprawnił? Gdzie prelegenci popełnili błąd, a gdzie należałoby ich
> wynieść na piedestał? Proszę o komentarze, na bazie których kolejne
> wystąpienia będą bardziej dopasowane do potrzeb, a może i bardziej
> profesjonalne?
>
> Nie wahajcie się chwalić, ani ganić. Nikt tutaj nikogo nie powiesi za
> dobre i złe słowo. Zero urazy. Wdzięczność gwarantowana!
>
> Nagranie ze spotkania pojawi się niebawem. Dzisiaj/jutro konwersja i
> upload. Stay tuned i dopytuj, kiedy temat stanie się nieświeży, a
> wciąż w trakcie realizacji. Ciao.
>
> [*] Używam formy męskiej wyłącznie dla uproszczenia komunikacji, ale
> kobiety, które uczestniczyły w spotkaniu, powinny się również, a może
> przede wszystkim, czuć zaproszone do udziału w ankiecie.
>
> Jacek
>
> --
> Jacek Laskowski
> Java EE, functional languages and IBM WebSphere -http://blog.japila.pl

[medyk]

Ja jestem za tym, aby Maciek dostał licencje bez losowania.

Generalnie jestem za wprowadzeniem algorytmu przydzielania licencji
według wkładu w "JUGowe community", czyli w kolejności:
1. prelegent
2. osoby, które coś dla JUGa zrobiły, np. commiterzy jelatyny (nie
wiem, czy to jeszcze podpada pod Warszawskiego JUGa), załatwiły
sponsora, ogarniają całą imprezę (np. Wojtek Erbetowski), itp.
3. osoby, które popełniły na blogu jakąś relacje ze spotkania, itp.
4. pozostałe osoby
Oczywiście licencje, tylko dla osób uczestniczących w danym spotkaniu
Co wy na to?

PS. mam chrapkę na taką licencję, ale łapię się dopiero do 4rtej grupy

On 24 Lut, 00:17, Maciej Jaśkowski <maciej.jaskow...@gmail.com> wrote:
> to ja sie zgłaszam do losowania w takim razie :)
>
> MJ
>
> On 24 February 2012 00:06, Jacek Laskowski <ja...@japila.pl> wrote:
>
>
>
>
>
>
>
> > 2012/2/23 Krzysztof Nielepkowicz <k.p.nielepkow...@gmail.com>:
> >> Może z innej beczki, mam taki pomysł by sponsorzy zamiast 3 osób z PR
> >> przysłali kogoś technicznego. No dobra - moze być 2*PR + 1TECH.
>
> > Na to nie mamy wielkiego wpływu. Czy to nie jest tak, że jak przyślą
> > leszcza, to leszczy zatrudnią? Czym bardziej zależy sponsorowi,
> > komukolwiek, tym bardziej się przygotuje i dopyta o klientelę. Wszyscy
> > się uczymy i jednocześnie dopasowujemy do siebie. Na pewno z każdym
> > spotkaniem będzie przyjemniej.

>
> > Jacek
>
> > --
> > Jacek Laskowski
> > Functional languages (Clojure), Java EE, and IBM WebSphere -

> >http://blog.japila.pl
> > "Never discourage anyone who continually makes progress, no matter how
> > slow." Plato
>

> > --
> > Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).

> > Więcej informacji na stroniehttp://groups.google.com/group/warszawa-jug?hl=pl
> > Zachęcamy do odwiedzenia naszej strony domowejhttp://warszawa.jug.pl

[medyk]

Co do samego Clojure i ilości nawiasów, to chyba wszystko rozpatrujemy
na niewłaściwym poziomie, bo sama składnia języka niewiele się ma do
jego funkcjonalności. Zresztą do samej składni można się przyzwyczaić,
przekonać, a nawet polubić, pomimo, iż na pierwszy rzut oka wydaje
się ...miejsce_na_twój_epitet... :p. W pewnych zastosowania nawet
odwrotna notacja polska może być bardziej naturalna, niż inne, do
których przywykliśmy,i używamy na co dzień.

Tu raczej trzeba tak różne od siebie języki jak Java (i jej podobne) i
Clojure porównywać pod kątem zastosowań, a że głównie piszemy
aplikacje, które najłatwiej wyrazić za pomocą języków obiektowych (a
jeśli nawet nie, to i tak piszemy obiektowo :p), to wszystko co nie
przystaje do tego co znamy (przynajmniej z początku) wydaje się
herezją.
Sprawa języków obiektowych i funkcyjnych ma się podobnie jak baz
relacyjnych i tzw. baz NoSQL, odrzucamy te drugie, bo ich nie znamy i
nie rozumiemy, pomimo iż problemy, które próbujemy rozwiązać w
przypadku tych pierwszych, w ogóle nie występują w tych drugich.

[medyk]

Co to jest SICP?

> > Zachęcamy do odwiedzenia naszej strony domowejhttp://warszawa.jug.pl

[Irek Matysiewicz]

W dniu 26 lutego 2012 16:59 użytkownik medyk <msanit...@gmail.com> napisał:

Co to jest SICP?

Paaanie googluj trochę :-)
http://mitpress.mit.edu/sicp/

[Tomasz Szymański]

On Sat, Feb 25, 2012 at 11:49 PM, Bartek Kuczyński <bjkuc...@gmail.com> wrote:

Michał, ale ja mam porównanie do np. Fortrana (podobny wiek), którego
uczyli mnie na studiach. Cobola po prostu się nie uczy. W Fortranie
nadal robi się dziś projekty (akademickie) i nadal jest on rozwijany.

Ano true w sumie. Bo cobol jest wylacznie dlatego, ze ktos kiedys wydal pare milionow na system mainframe'owy i on do dzis dziala, wiec nokomu nie przychodzi do glowy, zeby to ruszac...

A juz nowych systemow w cobolu nikt przy zdrowych zmyslach pisac nie zaczyna... a w Fortranie jak najbardziej ;-)

Z tym, ze wydaje mi sie, ze to nie polega na tym, ze cobol mial jakas skladnie nie taka - ludzie po prostu lepsza wymyslili. Fortran, zyje bo to na dzisiejsze czasy bysmy nazwali de facto DSLem do robienia obliczen numerycznych ;-)

T.

p.s. sory za hijackowanie watku, juz nie bede ;-)

[Bartek Zdanowski]

Hej.

2012/2/26 medyk <msanit...@gmail.com>:

> Ja jestem za tym, aby Maciek dostał licencje bez losowania.

A ile osób było na spotkaniu?

> Generalnie jestem za wprowadzeniem algorytmu przydzielania licencji

Licencję rozdaję zgodnie z zasadami narzuconymi przez JetBrains,
twórców IntelliJ IDEA. Zasada jest prosta: 30+ uczestników, losujemy 1
licencję. 50+ losujemy 2. Kiedyś każdy prelegent dostawał z automatu,
ale pewnie za dużo tych licencji wychodziło. Jeśli wykład jest lipny,
to nie ma losowania.
Jednocześnie, załatwiłem z JetBrains, że jesli jest 50+ to mam prawo
"wręczyć" prelegentowi licencję, a drugą rozlosować.
Zatem, nie mamy możliwości dowolnego rozdawania. Choć Twój pomysł
niezmiernie mi się podoba, bo promuje zaangażowanie. I proponujesz go,
wiedząc że nie masz w tej chwili szans na lincencję.

> według wkładu w "JUGowe community", czyli w kolejności:
> 1. prelegent
> 2. osoby, które coś dla JUGa zrobiły, np. commiterzy jelatyny (nie
> wiem, czy to jeszcze podpada pod Warszawskiego JUGa), załatwiły
> sponsora, ogarniają całą imprezę (np. Wojtek Erbetowski), itp.
> 3. osoby, które popełniły na blogu jakąś relacje ze spotkania, itp.
> 4. pozostałe osoby
> Oczywiście licencje, tylko dla osób uczestniczących w danym spotkaniu
> Co wy na to?
>
> PS. mam chrapkę na taką licencję, ale łapię się dopiero do 4rtej grupy

Nie ma nic prostrzego - zrób prezentację na taki temat, który zachęci
50+ osób i licencja jest Twoja.

> Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

> Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--

[Jacek Laskowski]

2012/2/26 Bartek Zdanowski <bartek.z...@gmail.com>:

> A ile osób było na spotkaniu?

~46. Na pewno < 50.

> Licencję rozdaję zgodnie z zasadami narzuconymi przez JetBrains,

E tam. Można z nimi przegadać ten temat. Wystarczy, że na początku
prezentacji wyświetlimy ich logo, wspomnimy o ich udziale, czy
podobnie. Wszystko jest kwestią dogadania. Uważam, że są elastyczni i
chodzi im po prostu o promocję ich komercyjnego produktu. Trzeba ubrać
się w ich myślenie i zaproponować, aby wszyscy byli zadowoleni (ja już
zaproponowałem w drugim zdaniu).

> Nie ma nic prostrzego - zrób prezentację na taki temat, który zachęci
> 50+ osób i licencja jest Twoja.

Sprytnie!

[Jacek Laskowski]

2012/2/26 medyk <msanit...@gmail.com>:

> Sprawa języków obiektowych i funkcyjnych ma się podobnie jak baz
> relacyjnych i tzw. baz NoSQL, odrzucamy te drugie, bo ich nie znamy i
> nie rozumiemy, pomimo iż problemy, które próbujemy rozwiązać w
> przypadku tych pierwszych, w ogóle nie występują w tych drugich.

Super porównanie z tym SQL-NoSQL do OOP-FP. Pozwolę sobie to przywołać
na kolejnych spotkaniach odnośnie Clojure.

[Jacek Laskowski]

2012/2/26 medyk <msanit...@gmail.com>:

> 1) O prezentacji Jacka mogę się wypowiedzieć w samych superlatywach,
> ciekawa, od dobrej strony i w odpowiedniej wielkości kęsach ugryziona.
> Wprost nie mogę się doczekać następnego JUGa, mam nadzieję, że poza
> obiecanym kodem Jacek powie też kilka słów o tym jak to pożenić z
> Javą.

Tego się nie spodziewałem - same superlatywy! To jak zdobyć Oscara.

Dzięki Twojej uwadze, agenda następnego spotkania o Clojure wygląda
już następująco:

1. Leiningen - narzędzie do zarządzania projektami Clojure
2. Clojure Interop - współpraca Clojure z Javą w obu kierunkach - od i do Javy
3. Budowanie aplikacji webowej z Compojure

Coś jeszcze? Obecnie na każdy temat mam (średnio) 30 minut + 10 minut
na dyskusje.

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -

[Bartek Zdanowski]

2012/2/27 Jacek Laskowski <ja...@japila.pl>:

> 2012/2/26 Bartek Zdanowski <bartek.z...@gmail.com>:
>
>> A ile osób było na spotkaniu?
>
> ~46. Na pewno < 50.

W takim razie jest jedna licencja do rozlosowania.

>
>> Licencję rozdaję zgodnie z zasadami narzuconymi przez JetBrains,
>
> E tam. Można z nimi przegadać ten temat. Wystarczy, że na początku
> prezentacji wyświetlimy ich logo, wspomnimy o ich udziale, czy
> podobnie. Wszystko jest kwestią dogadania. Uważam, że są elastyczni i
> chodzi im po prostu o promocję ich komercyjnego produktu. Trzeba ubrać
> się w ich myślenie i zaproponować, aby wszyscy byli zadowoleni (ja już
> zaproponowałem w drugim zdaniu).
>
>> Nie ma nic prostrzego - zrób prezentację na taki temat, który zachęci
>> 50+ osób i licencja jest Twoja.
>
> Sprytnie!
>
> Jacek
>
> --
> Jacek Laskowski
> Functional languages (Clojure), Java EE, and IBM WebSphere -
> http://blog.japila.pl
> "Never discourage anyone who continually makes progress, no matter how
> slow." Plato
>

[Tomek Lipski]

On Feb 25, 10:21 pm, Irek Matysiewicz <iir...@gmail.com> wrote:
> > Ojej, naprawdę nie rozumiem, co ludziom przeszkadzają nawiasy. Jak w
> > każdym języku, jeśli kod jest poprawnie sformatowany, to na nawiasy
> > rzadko zwraca się uwagę.
>
> Po prostu: przyjęło się pisać "x+y*z" czy "f(x, y)" a nie "(+ x (* y z))"
> czy "(f x y)" - taki zwyczaj. Nowa składnia tu nic nowego dla programisty
> nie daje, a wręcz przeszkadza bo łamie przyjęty zwyczaj i wymaga
> niepotrzebnego trudu w celu przyzwyczajania się do nowego.

Tutaj warto zauważyć, że taka składnia (matematyczna) jest w
większości języków przypadkiem specjalnym bo odpowiednikiem
wywołań (+ x (* y z)) w Javie jest +(x, *(y, z).

Tak samo w Lispie (pomijam Clojure i brak możliwości tworzenia custom
read macros - nawiasy to nawiasy), można wprowadzić składnię:
#math(x + y * z) i spokojnie z niej korzystać.

Ciekawostka/dygresja: na studiach miałem kalkulator HP 48G, właśnie z
notacją odwrotną polską - i po paru laboratoriach liczyło się na tym o
wiele szybciej niż na klasycznym kalkulatorze. Ale to może tylko
dodawać siły tezie, że jednej osobie składnia Lispa pasuje a drugiej
nie ;-)

> Jacek mówi że Clojure potrafi fajne rzeczy - jest to zapewne zaleta
> bibliotek, kompilatora bądź interpretera, a na pewno nie nietypowej składni
> (dla kompilatora sparsowany program to i tak drzewo). Wystarczy poznać te
> fajne rzeczy i przenieść je na grunt Javy/Grooviego/Scali (o ile już ich
> tam nie ma, pewnie są tylko inaczej się nazywają).

Ah, czyli po prostu nie dla wszystkich jest jasne po co te obrzydliwe
nawiasy i co dają. Ok, to już próbuję wyjaśnić:

Nie, to nie biblioteki/kompilator/interpreter czynią Clojure fajnym/
poteżnym językiem. To właśnie te nawiasy. W skrócie - składnia jaką
oferują dialekty Lispa, pozwala na pisanie o wiele krótszego i
dostosowanego do konkretnego zagadnienia kodu źródłowego. Krótszy kod
= Lepszy kod. Nie trzeba się tyle powtarzać, nie trzeba pisać tyle
"boilerplate". Prosta sprawa w sumie.

Ale postaram się rozwinąć trochę temat makr/nawiasów (nie wiem na ile
pokrywa się z wykładami Jacka):

Każdy język programowania ma swój parser i ten parser tłumaczy kod
języka programowania na swoje struktury - http://en.wikipedia.org/wiki/Abstract_syntax_tree

Dla Pythona output może wyglądać np. tak (wyrażenie x+y*z):

>>> import ast
>>> source = 'x + y*z'
>>> node = ast.parse(source, mode='eval')
>>> ast.dump(node)
"Expression(body=BinOp(left=Name(id='x', ctx=Load()), op=Add(),
right=BinOp(left=Name(id='y', ctx=Load()), op=Mult(),
right=Name(id='z', ctx=Load()))))"

Prostsze wyrażenie (6+8)
Expression(
body=BinOp(
left=Num(n=6),
op=Add(),
right=Num(n=8)))

Fajne, prawda? A teraz spróbujmy pisać w składni powyżej. Nie jest to
zbyt zachęcające.

W Lispie piszesz w AST (to oczywiście nie do końca prawda - ale ma się
te same co możliwości co jakby się pisało w AST). W xhtmlu/xmlu - de
facto też, tylko domykasz tagi nazwami:

<+> x <*>y z</*></+>

Wszystkie flow languages w XMLu (np. webMethods flow, czy Mule flow)
stosują to samo podejście (tylko bez nieskończonego zagnieżdżania i
bez makr).

Pisanie bezpośrednio w AST, pozwala min. na proste tworzenie makr,
które operują na samym drzewku parsowania - co po prostu skraca i
upraszcza produkowany kod. Zaś krótszy kod (bez wynalazków of course),
to:
- mniej powtórzeń (np. boilerplate code, który jest smutną
koniecznością w Javie)
- mniej błędów (jeśli piszemy zgodnie z best practices)
- większa czytelność kodu (znowu oczywiście jeśli działamy zgodnie z
best practices)

Jeśli ktoś pisał całe życie w Javie, to jest to trudne do wyobrażenia
- po co komu takie makro? Weźmy na przykład klasyczny problem dostępu
do zasobu poza JVM (np. pliku):

Java:
InputStream is = new FileInputStream("test.txt");
try {
is.read();
}
catch (Exception e) {
logger.error(e); //albo jakoś inaczej
} finally {
is.close();
}
}

jeśli mamy 3 zasoby, to kod się robi dość paskudny. Łatwo o błąd.
Można oczywiście zrobić sobie dla każdego rodzaju zasobu klasę i
metodę opakowującą, która przyjmie anonimową klasę wewnętrzną. Tylko,
że to już symulowanie FP.

Zaś w Lispie wygląda to mniej-więcej tak:

(with-open-file (is "test.xml")
(read is))

Ale ok - takie makro (dokładnie - dwa jeśli dobrze pamiętam zajęcia na
studiach) na upartego napiszemy w C i może będzie nam działać, możemy
też dopisać coś w AOP i może nawet zadziała. To makro nie przetwarza
swojej treści, tylko dodaje otoczkę z góry i dołu.

Więc teraz zastąpmy kod w Javie, klasyczne "drzewko ifów":
if (var1.checkCondition("x1")) {
doSomething4("test2");
} else if (var1.checkCondition("x2")) {
doSomething5("test3");
} else if (var1.checkCondition("x3"))) {
doSomething6("test4");
throw new MyException("bo tak");
} else {
doSomething7("test5");
}
brzydkie, prawda?

Tymczasem w lispie (to akurat Common Lisp, ale makro to makro), za
pomocą krótkiego makra, które piszemy raz i używamy przez lata, mamy:
(funcase var1 #'checkCondition
("x1" (doSomething4 "test2"))
("x2" (doSomething5 "test3"))
("x3" (doSomething6 "test4") (throw "bo tak"))
(T (doSomething7 "test5"))

Widać, że po prostu jest mniej powtórzeń. Tak, oczywiście, można
napisać metodę
public static Object funcase(Object var1, Method method,
Map<String,Runnable> conds) {
} ale czy wtedy piszemy jeszcze w Javie? I czy nasz kod nie wygląda po
zastosowaniu takiej metody jeszcze gorzej i dłużej:

Map<String,Runnable> m = new HashMap<String,Runnable>();
m.put("x1", new Runnable() {
public void run() {
doSomething4("test2");
}
});
m.put("x2", new Runnable() {
public void run() {
doSomething5("test3");
}
});
m.put("x3", new Runnable() {
public void run() {
doSomething4("test4");
throw new MyException("bo tak"); //MyException musi być np.
RunnableException
}
});
m.put(null, new Runnable() { //default
public void run() {
doSomething4("test5");
}
});

funcase(var1, var1.getClass().getMethod("checkCondition"), m); //
compilator nam tego nie sprawdzi już - tracimy zaletę Javy

No dobra - i teraz można powiedzieć - "ale ja piszę tylko kod, który
korzysta z bibliotek, nie będę pisał żadnych makr". No ok, chociaż
pewnie wcześniej czy później człowiek to makro napisze, ale za to
autorzy bibliotek - korzystają z makr i już dzięki temu nasz kod się
robi o wiele krótszy - bo likwidujemy boilerplate związany z
bibliotekami.

Na koniec jeszcze jeden przykład (chociaż kusi mnie, aby pokazać makra
generujące definicje funkcji) - tym razem Clojure, generacja HTML. Ja
nie wyobrażam sobie generowania HTMLa w ten sposób z Javy w normalny
sposób:

W Javie wystarczy obejrzeć dowolny kod generujący XMLa z javax.xml
żeby wiedzieć, jak nieprzyjemne to jest w tym języku (o xstream nie
mówię, xstream jest super - ale on serializuje obiekty)

Za to w Clojure mamy bibliotekę hiccup, ma macro html, przykładowe
użycie wygląda tak:

user=> (html [:span {:class "foo"} (let [x (* 5 4)] (str x "a" "b"
"c"x))])
"<span class=\"foo\">20abc20</span>"

ale jeśli rozwiniemy makro, to widzimy, co robi hiccup tak naprawdę -
parsuje przekazane mu wyrażenie i tłumaczy to co jest HTMLem - na
HTML, a to co jest wyrażeniem - pozostawia jak jest:

user=> (macroexpand-1 '(html [:span {:class "foo"} (let [x (* 5 4)]
(str x "a" "b" "c"x))]))
(clojure.core/str "<span" " class=\"foo\"" ">" ((var hiccup.core/
render-html) (let [x (* 5 4)] (str x "a" "b" "c" x))) "</span>")


i nadal nie jest to specjalny feature języka (jak byłoby np. w JSP),
wymagający osobnego parsera, kompilatora itd - wszystko jest normalnym
zastosowaniem mechanizmu makr. Dla własnej implementacji JSP w Javie/
Groovym/Scali musimy napisać parser JSP od podstaw, który przejedzie
po całym kodzie, wyjmie odpowiednie tagi, zamieni to na łańcuch znaków
i odpali standardowy kompilator Javy. Inny język/zastosowanie -
piszemy od nowa. Oczywiście - ludzie to robią, ale jak rzadko?

I po to właśnie dla mnie są nawiasy - aby po prostu pisać krótszy kod
i się powtarzać jak najmniej. Żeby mieć możliwość tworzenia jak
najbardziej uniwersalnych i fajnych funkcji narzędziowych. Czysty
pragmatyzm, a jak widać składnia nie jest mocno różna (+ x (* y z)) vs
+(x, *(y,z)) - chyba że akurat mówimy o wyrażeniach arytmetycznych ;-)

Mam nadzieję, że choć trochę rozjaśniłem po co nawiasy.

t

P.S. Strasznie długo wyszło, pewnie nikt nie przeczyta ;-)
P.S.2 Nie znam Haskella, ale spodziewam się, że wspomniana
funkcjonalność we wcześniejszych postach daje efekt podobny do
pythonowego modułu ast.

[Dawid Bielecki]

i było już to losowanie? przegapiłem?

2012/2/27 Bartek Zdanowski <bartek.z...@gmail.com>

[Maciej Jaśkowski]

No nie moglem sie powstrzymac, przepraszam, i popelnilem tego krotkiego maila.

Btw. sorry jesli jezdzilem po Javie na prezentacji. Naprawde nie chcialem :/

>
> Java:
> InputStream is = new FileInputStream("test.txt");
>  try {
>  is.read();
>  }
>  catch (Exception e) {
>  logger.error(e); //albo jakoś inaczej
>  } finally {
>  is.close();
>  }
> }

Poprawcie mnie: w Javie 1.7 mozna chyba tego problemu uniknac piszac:
try (InputStream is = new FileInputStream("test.txt")) {
is.read();
}

a w nawiasie po try mozna nawet wiecej niz jedna linijke kodu napisac,
czyli miec kilka strumieni na ten przyklad.

W Scali nie ma wbudowanej konstrukcji dla takich rzeczy, ale... mozna
ja stworzyc :
def use[T <: { def close(): Unit }](closable: T)(block: T => Unit) {
try {
block(closable)
}
finally {
closable.close()
}
}

i pisac jak w Javie 1.7:
use(new FileInputStream("test.txt")) { is =>
is.read()
}

>
> Zaś w Lispie wygląda to mniej-więcej tak:
>
> (with-open-file (is "test.xml")
>  (read is))

> Więc teraz zastąpmy kod w Javie, klasyczne "drzewko ifów":
> if (var1.checkCondition("x1")) {
>  doSomething4("test2");
> } else if (var1.checkCondition("x2")) {
>  doSomething5("test3");
> } else if (var1.checkCondition("x3"))) {
>  doSomething6("test4");
>  throw new MyException("bo tak");
> } else {
>  doSomething7("test5");
> }
> brzydkie, prawda?
>
> Tymczasem w lispie (to akurat Common Lisp, ale makro to makro), za
> pomocą krótkiego makra, które piszemy raz i używamy przez lata, mamy:
> (funcase var1 #'checkCondition
>  ("x1" (doSomething4 "test2"))
>  ("x2" (doSomething5 "test3"))
>  ("x3" (doSomething6 "test4") (throw "bo tak"))
>  (T (doSomething7 "test5"))

a w Scali tak:
var1 match {
case x: x.checkCondition("x1") => doSomething4("test2")
case x: x.checkCondition("x2") => doSomething5("test3")
case x: x.checkCondition("x3") => doSomething6("test4")
case _ => doSomething7("test5")
}

Czesto mozna rowniez korzystac z "case class", wtedy (nie wchodzac w
szczegoly) kod moglby sie uproscic do:
var1 match {
case x("x1") => doSomething4("test2")
case x("x2") => doSomething5("test3")
case x("x3") => doSomething6("test4")
case _ => doSomething7("test5")
}

inna sprawa, ze jesli x jest dobrym obiektem, to wolelibysmy unikac
takich "switch-like statements".

>
> Za to w Clojure mamy bibliotekę hiccup, ma macro html, przykładowe
> użycie wygląda tak:
>
> user=> (html [:span {:class "foo"} (let [x (* 5 4)] (str x "a" "b"
> "c"x))])
> "<span class=\"foo\">20abc20</span>"

a w Scali czlowiek skorzysta z bibiloteki scala.xml i napisz tak:
(sic!)
val user = <span class="foo">{
val x = 5 * 4;
x + "a" + "b" + "c" + x }
</span>

I mozemy potem pisac:

assertThat(user \ "@class").isEqualTo("foo")

albo

majac:
val user = <foo><bar>text</bar></foo>

assertThat(user \ "bar").isEqualTo(<bar>text</bar>)

No i w Scali mamy typy i kompilator. Fajnie, co ?

Pozdr!
MJ

[Adam Lider]

On Feb 27, 2012, at 2:40 PM, Tomek Lipski wrote:
> W skrócie - składnia jaką
> oferują dialekty Lispa, pozwala na pisanie o wiele krótszego i
> dostosowanego do konkretnego zagadnienia kodu źródłowego. Krótszy kod
> = Lepszy kod. Nie trzeba się tyle powtarzać, nie trzeba pisać tyle
> "boilerplate". Prosta sprawa w sumie.

Z gory przepraszam z wyrwanie tego zdania, ale zuwazylem ze dosc mocno to podkreslasz, a osobiscie uwazam ze nie jest to prawda. Dlugosc kodu nie ma wiele wspolnego z jego jakoscia.

Biorac ponizszy przyklad (czesty w podobnych dyskusjach):

> Java:
> InputStream is = new FileInputStream("test.txt");
> try {
> is.read();
> }
> catch (Exception e) {
> logger.error(e); //albo jakoś inaczej
> } finally {
> is.close();
> }
> }

Dlaczego ten kod jest uwazany za paskudny? Bo dlugi? Narazony na bledy? Dla mnie ten kod jest czytelny i dajacy spora kontrole nad tym co sie tutaj dzieje, a dzieje sie b. duzo. Co wiecej czasem wydaje mnie sie ze i tak za duzo "zakrywa" jesli chodzi IO, bo przeciez plik na dysku to nie strumien danych ale zbior blokow.

> Zaś w Lispie wygląda to mniej-więcej tak:
>
> (with-open-file (is "test.xml")
> (read is))

nie znam lispa, ale czy ten kod nadal bedzie tak "ladny" jak dodamy obsluge sytuacji gdzie nie mamy prawa do pliku? albo chcemy czytac/zapisywac dane uzywajac struktury danych rowniej rozmiarowi bloku?

Moze sie myle, ale argumentacja z dlugoscia kodu przypomina mi troche sytuacje z roznego rodzaju frameworkami, gdzie przez podnoszenie poziomu abstrakcji, probuje sie zakryc co trudniejsze aspekty programowania aby kodowalo nam sie lepiej, szybciej i przyjemniej. Najczesciej do momentu.

Java jest naprawde rewelacyjna pod tym wzgledem ze daje nam do pracy abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy biznesowe wymagania, jak rowniez uwzgledniajacy aspekty niskiego poziomu, kiedy jest taka potrzeba.

- Adam.

[Tomek Lipski]

>
> Poprawcie mnie: w Javie 1.7 mozna chyba tego problemu uniknac piszac:
> try (InputStream is = new FileInputStream("test.txt")) {
>    is.read();
> }

Ok, odróżnijmy core'ową funkcjonalność języka, wprowadzaną kilka lat
od tego co można napisać. To są tylko przykłady tego, co można zrobić
- łatwo szybko i przyjemnie - nie jedyne 3 makra, które są dostępne w
Lispie.

> a w nawiasie po try mozna nawet wiecej niz jedna linijke kodu napisac,
> czyli miec kilka strumieni na ten przyklad.

aż do momentu, kiedy nie musisz zastosować swojej logiki przy
zwalnianiu zasobu. A co jak metoda nie może się nazywać close() bo
używasz jej do czegoś innego? Co, jak chcesz przechwycić wyjątek przy
zamykaniu zasobu X (przy Y już nie) a nie możesz nadpisać metody
close() swoją implementacją bo klasa jest final? A co jak trzeba
najpierw taki zasób zainicjalizować? :)

>
> W Scali nie ma wbudowanej konstrukcji dla takich rzeczy, ale... mozna
> ja stworzyc :
> def use[T <: { def close(): Unit }](closable: T)(block: T => Unit) {

Ok, fajnie - ale to jest tylko najprostszy przykład dla macra - raczej
pokazujący mechanikę. Dobrze, że Scala ma obsługę, dla tego jednego,
podstawowego przypadku. W Javie też można to osiągnąć poprzez Runnable
czy w C przez #define.

> a w Scali tak:
> var1 match {
> case x: x.checkCondition("x1") => doSomething4("test2")
> case x: x.checkCondition("x2") => doSomething5("test3")
> case x: x.checkCondition("x3") => doSomething6("test4")
> case _ => doSomething7("test5")

Znowu - chodzi o ilustrację jak to działa - i tak, w tym szczególnym
przypadku, Scala może jakoś to realizuje, ale jak widać nie bez
powtarzania kodu/nazwy funkcji. To jest prosty przykład, bo nie ma
miejsca na duże przykłady na grupie dyskusyjnej. Tutaj masz jedno
powtórzenie kodu, ale w realnym rozwiązaniu - będzie tego kilkanaście
razy więcej.

> }
> Czesto mozna rowniez korzystac z "case class", wtedy (nie wchodzac w
> szczegoly) kod moglby sie uproscic do:
> var1 match {
> case x("x1") => doSomething4("test2")
> case x("x2") => doSomething5("test3")
> case x("x3") => doSomething6("test4")
> case _ => doSomething7("test5")
>
> }

Ale to już jest feature języka - dedykowany dla konkretnego przypadku
- case.

>
> inna sprawa, ze jesli x jest dobrym obiektem, to wolelibysmy unikac
> takich "switch-like statements".

no jasne, ale trzeba pracować z tym, co się ma pod ręką. Znowu - nie
rozumiemy się chyba - ja nie pokazuję że te makra są jakieś super (bo
nie są) - tylko że takie efekty czy inne uzyskuje się samemu, bez
konieczności modyfikacji specyfikacji języka. Bo autor języka,
jakkolwiek nie jest wspaniały i mądry, nie przewidzi wszystkich
przypadków i potrzeb programistów.

> > Za to w Clojure mamy bibliotekę hiccup, ma macro html, przykładowe
> > użycie wygląda tak:
>
> > user=> (html [:span {:class "foo"} (let [x (* 5 4)] (str x "a" "b"
> > "c"x))])
> > "<span class=\"foo\">20abc20</span>"
>
> a w Scali czlowiek skorzysta z bibiloteki scala.xml i napisz tak:
> (sic!)
> val user = <span class="foo">{
> val x = 5 * 4;
> x + "a" + "b" + "c" + x }
> </span>

No super i ktoś napisał/użył parsera XML i jeszcze zmusił programistę
do pilnowania końca tagów - bardzo wygodne. Jeśli chcemy coś
podobnego, ale dla języka, który używa [ ] zamiast <> - rozumiem, że
piszemy znowu całą wielką bibliotekę i parser?

A da się zrobić tak w scala.xml?

(let [idname "id"
bolds ["test1" "test2" "test3"]]
(html
[:span {:class (str 7 "z") idname "2124"}

(let [x (* 5 4)] (str x "a" "b" "c" x))

(map #(html [:b (.toUpperCase %)]) bolds)]))

=> <span class=\"7z\" id=\"2124\">20abc20<b>TEST1</b><b>TEST2</
b><b>TEST3</b></span>

> I mozemy potem pisac:
>
> assertThat(user \ "@class").isEqualTo("foo")
>
> albo
>
> majac:
> val user = <foo><bar>text</bar></foo>
>
> assertThat(user \ "bar").isEqualTo(<bar>text</bar>)

Ok, ale czy nie naciągasz trochę faktów mówiąc "biblioteki scala.xml"
sugeruje to, że jest to jakaś niezależna biblioteka, tymczasem:
"Starting with Scala 1.2 (previous versions need to use the -
Xmarkupoption), you can conveniently create such labeled nodes using
standard XML syntax." - czyli jednak to jakiś feature wewnętrzny
języka - dedykowany dla XMLa? Dla mnie to wada - język powinien być
prosty i łatwy a nie mieć tysiące tajemnych features.

Czy to znaczy, że mogę napisać sobie bibliotekę (nie ingerującą w to
jak działa Scala) - tomeks.json i dopisać obsługę kodu, gdzie zamiast
{ } i będę miał % i $ (bo taka ułańska fantazja)?
I zadziała mi na przykład kod:

val user = % v1: "test1", v2: "test3" $

>
> No i w Scali mamy typy i kompilator. Fajnie, co ?

Jasne - bardzo fajnie, w porównaniu z Javą. Chociaż kompilator Scali
mógłby być trochę szybszy IMHO ;-) O zaletach i wadach silnego
typowania - można długo dyskutować i do niczego nie dojść.

Trochę się chyba nie rozumiemy - pokazuję, co można łatwo i przyjemnie
zrobić w Clojure, dzięki składni - w odpowiedzi dostaję jakieś
konkretne funkcjonalności języków, zrobione dokładnie pod dany case.
Nie, że się nie da, bo w końcu wszystko działa na tym samym procesorze
- tylko chodzi o to, jak bardzo trzeba się przy danym problemie
nabiegać.

Tylko przykład z resource w Scali pokazał jakiś ogólny mechanizm,
który można ogólnie zastosować do swoich potrzeb a nie czekać na aż
komitet sterujący językiem się zbierze - ale to było proste
zastosowanie makra i jak sam pisałem - nawet w C czy Javie można to
zasymulować.

Polecam jeszcze jeden przykład - Edi Weitz jakiś czas temu napisał
silnik a'la Drools w Common Lispie - bez pisania osobnego języka,
swojego parsera, itd. - na 104 linijkach sformatowanego kodu.

http://weitz.de/files/riddle.lisp

Nie, nie jest tak, że ta implementacja rozwiązuje tylko problem z
rybkami - można jej użyć do dowolnych zagadek tego typu. Wyjaśnienie
jak to działa znajduje się tutaj: http://weitz.de/einstein.html - w
skrócie: wprowadzając zagadkę, definiujemy szereg funkcji, które ją
rozwiązują.

Jestem ciekaw, jak implementacja takiego problemu wyglądałaby w Scali
- na pewno się da, ale czy tak elegancko i krótko? Nie mówię o
zastosowaniu biblioteki, którą ktoś napisał - tylko o mechanizmach
języka - starając się wyjaśnić co dają nawiasy (a nie który język jest
lepszy - żeby nie było wątpliwości).


t

[Tomek Lipski]

On Feb 27, 4:09 pm, Adam Lider <adam.li...@googlemail.com> wrote:
> On Feb 27, 2012, at 2:40 PM, Tomek Lipski wrote:
>
> > W skrócie - składnia jaką
> > oferują dialekty Lispa, pozwala na pisanie o wiele krótszego i
> > dostosowanego do konkretnego zagadnienia kodu źródłowego. Krótszy kod
> > = Lepszy kod. Nie trzeba się tyle powtarzać, nie trzeba pisać tyle
> > "boilerplate". Prosta sprawa w sumie.
>
> Z gory przepraszam z wyrwanie tego zdania, ale zuwazylem ze dosc mocno to podkreslasz, a osobiscie uwazam ze nie jest to prawda. Dlugosc kodu nie ma wiele wspolnego z jego jakoscia.

To już jak widać kwestia doświadczeń i opinii. Wolisz czytać klasę,
która ma 10000 linii czy taką, która ma 100 linii i robi to samo?
Długi kod to zazwyczaj kod zawierający dużo powtórzeń (może nie 1:1,
ale myślimy tutaj abstrakcyjnie). A chyba zgadzasz się, że należy
unikać powtórzeń w kodzie?

>
> Dlaczego ten kod jest uwazany za paskudny? Bo dlugi? Narazony na bledy? Dla mnie ten kod jest czytelny i dajacy spora kontrole nad tym co sie tutaj dzieje, a dzieje sie b. duzo. Co wiecej czasem wydaje mnie sie ze i tak za duzo "zakrywa" jesli chodzi IO, bo przeciez plik na dysku to nie strumien danych ale zbior blokow.

Bo treści są tam 2 linijki a reszta to konwencja. Bo pisząc go ręcznie
- można zapomnieć o klauzuli finally. Bo można użyć złego loggera. Bo
można użyć e.printStackTrace().

>
> > Zaś w Lispie wygląda to mniej-więcej tak:
>
> > (with-open-file (is "test.xml")
> > (read is))
>
> nie znam lispa, ale czy ten kod nadal bedzie tak "ladny" jak dodamy obsluge sytuacji gdzie nie mamy prawa do pliku? albo chcemy czytac/zapisywac dane uzywajac struktury danych rowniej rozmiarowi bloku?

to kwestia właśnie dodania makra. Dodajesz raz makro i masz:

(with-open-struct-file (struct-is "test.xml" :on-error #'my-error-
handler)
(read struct-is))

w każdym miejscu w kodzie. Jeśli #'my-error-handler to domyślna
implementacja - można ukryć.

>
> Moze sie myle, ale argumentacja z dlugoscia kodu przypomina mi troche sytuacje z roznego rodzaju frameworkami, gdzie przez podnoszenie poziomu abstrakcji, probuje sie zakryc co trudniejsze aspekty programowania aby kodowalo nam sie lepiej, szybciej i przyjemniej. Najczesciej do momentu.

Ale tutaj nie mówimy o frameworku - tylko o języku. To diametralna
różnica. To tak jakbyś miał możliwość uszycia sobie niewielkim
nakładem prac frameworku, który dokładnie robi to, co potrzebujesz - a
nie to, co przyszło komuś do głowy jak robił np. Springa.

>
> Java jest naprawde rewelacyjna pod tym wzgledem ze daje nam do pracy abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy biznesowe wymagania, jak rowniez uwzgledniajacy aspekty niskiego poziomu, kiedy jest taka potrzeba.

Ok, to można powiedzieć o każdym popularnym języku programowania
(proszę nie wycinać mojej wypowiedzi poniżej z kontekstu ;-):

C# jest naprawde rewelacyjny pod tym wzgledem ze daje nam do pracy

abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy biznesowe
wymagania, jak rowniez uwzgledniajacy aspekty niskiego poziomu, kiedy
jest taka potrzeba.

QBASIC jest naprawde rewelacyjny pod tym wzgledem ze daje nam do pracy

abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy biznesowe
wymagania, jak rowniez uwzgledniajacy aspekty niskiego poziomu, kiedy
jest taka potrzeba.

Scheme jest naprawde rewelacyjny pod tym wzgledem ze daje nam do pracy

abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy biznesowe
wymagania, jak rowniez uwzgledniajacy aspekty niskiego poziomu, kiedy
jest taka potrzeba.

Clojure jest naprawde rewelacyjny pod tym wzgledem ze daje nam do

pracy abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy
biznesowe wymagania, jak rowniez uwzgledniajacy aspekty niskiego
poziomu, kiedy jest taka potrzeba.

Python jest naprawde rewelacyjny pod tym wzgledem ze daje nam do pracy

abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy biznesowe
wymagania, jak rowniez uwzgledniajacy aspekty niskiego poziomu, kiedy
jest taka potrzeba.

Ruby jest naprawde rewelacyjny pod tym wzgledem ze daje nam do pracy

abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy biznesowe
wymagania, jak rowniez uwzgledniajacy aspekty niskiego poziomu, kiedy
jest taka potrzeba.

Drools jest naprawde rewelacyjny pod tym wzgledem ze daje nam do pracy

abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy biznesowe
wymagania, jak rowniez uwzgledniajacy aspekty niskiego poziomu, kiedy
jest taka potrzeba.

;-)

warto zauważyć, że potrzeba do uwzględniania aspektów niskiego poziomu
nie zależy w tym wypadku od nas - tylko od Javy. Nie mamy wolności
decyzji za dużo w przypadku Javy.

t

[Adam Lider]

On Feb 27, 2012, at 5:11 PM, Tomek Lipski wrote:

> On Feb 27, 4:09 pm, Adam Lider <adam.li...@googlemail.com> wrote:
>> On Feb 27, 2012, at 2:40 PM, Tomek Lipski wrote:
>>
>>> W skrócie - składnia jaką
>>> oferują dialekty Lispa, pozwala na pisanie o wiele krótszego i
>>> dostosowanego do konkretnego zagadnienia kodu źródłowego. Krótszy kod
>>> = Lepszy kod. Nie trzeba się tyle powtarzać, nie trzeba pisać tyle
>>> "boilerplate". Prosta sprawa w sumie.
>>
>> Z gory przepraszam z wyrwanie tego zdania, ale zuwazylem ze dosc mocno to podkreslasz, a osobiscie uwazam ze nie jest to prawda. Dlugosc kodu nie ma wiele wspolnego z jego jakoscia.
>
> To już jak widać kwestia doświadczeń i opinii. Wolisz czytać klasę,
> która ma 10000 linii czy taką, która ma 100 linii i robi to samo?
> Długi kod to zazwyczaj kod zawierający dużo powtórzeń (może nie 1:1,
> ale myślimy tutaj abstrakcyjnie). A chyba zgadzasz się, że należy
> unikać powtórzeń w kodzie?

100x mniej kodu? robi to samo? Ktores z powyzszych na pewno jest nieprawda. Ale nawet jesli teoretycznie tak, to nadal sie upieram ze te 10k lini Javy moze byc bardziej czytelne niz 100 lini jezyka funkcyjnego (nie tylko).

>
>>
>> Dlaczego ten kod jest uwazany za paskudny? Bo dlugi? Narazony na bledy? Dla mnie ten kod jest czytelny i dajacy spora kontrole nad tym co sie tutaj dzieje, a dzieje sie b. duzo. Co wiecej czasem wydaje mnie sie ze i tak za duzo "zakrywa" jesli chodzi IO, bo przeciez plik na dysku to nie strumien danych ale zbior blokow.
>
> Bo treści są tam 2 linijki a reszta to konwencja. Bo pisząc go ręcznie
> - można zapomnieć o klauzuli finally. Bo można użyć złego loggera. Bo
> można użyć e.printStackTrace().

Ta "konwecja" wymusza na nas myslenie, ze robimy cos wiecej niz wywylanie settera. Operacje IO sa krytyczne w wiekszosci systemow i czesto lekcewazone - a co tam, otworze sobie plik i przeczytam cos lub zapisze, przeciez to takie proste, jedna linia kodu - problem w tym ze "pod spodem" to nie jest jedna linia kodu, ani nawet 100. Poki to jest skrypt - helper developera to ok, ale jak chcemy robic cos powazniejszego to bedzie mieli problem.

>
>>
>>> Zaś w Lispie wygląda to mniej-więcej tak:
>>
>>> (with-open-file (is "test.xml")
>>> (read is))
>>
>> nie znam lispa, ale czy ten kod nadal bedzie tak "ladny" jak dodamy obsluge sytuacji gdzie nie mamy prawa do pliku? albo chcemy czytac/zapisywac dane uzywajac struktury danych rowniej rozmiarowi bloku?
>
> to kwestia właśnie dodania makra. Dodajesz raz makro i masz:
>
> (with-open-struct-file (struct-is "test.xml" :on-error #'my-error-
> handler)
> (read struct-is))

no i sie zaczyna i chociaz to i tak dalekie od uzywalengo to nie widze tego przelicznika 100 razy mnie kodu.

>
> w każdym miejscu w kodzie. Jeśli #'my-error-handler to domyślna
> implementacja - można ukryć.
>
>>

Fakt, moje stwierdzenie zabrzmialo gornolotnie, ale z tego co przytoczyles to tylko C# jest blisko Javy. QBasic i niski poziom? ;)

> warto zauważyć, że potrzeba do uwzględniania aspektów niskiego poziomu
> nie zależy w tym wypadku od nas - tylko od Javy. Nie mamy wolności
> decyzji za dużo w przypadku Javy.

Masz na mysli JVM? Fakt, niezla bestia, ale nawet jej mozna pomoc, uwzgledniaja fakty ze np. rozmiar bloku dyskowego to 4KB, a ramki ethernetowej 1,5KB, lub rozmiar cache'y procesorow, a Java ze swoja skladnia i core api nam tego nie utrudnia.

- Adam.

[Tomek Lipski]

> > To już jak widać kwestia doświadczeń i opinii. Wolisz czytać klasę,
> > która ma 10000 linii czy taką, która ma 100 linii i robi to samo?
> > Długi kod to zazwyczaj kod zawierający dużo powtórzeń (może nie 1:1,
> > ale myślimy tutaj abstrakcyjnie). A chyba zgadzasz się, że należy
> > unikać powtórzeń w kodzie?
>
> 100x mniej kodu? robi to samo? Ktores z powyzszych na pewno jest nieprawda. Ale nawet jesli teoretycznie tak, to nadal sie upieram ze te 10k lini Javy moze byc bardziej czytelne niz 100 lini jezyka funkcyjnego (nie tylko).

Oczywiście, że może - wydrukuj jedno i drugie i zobacz które szybciej
przeczytasz i zrozumiesz (tylko musisz się nauczyć Clojure do tego -
taki tajny plan ;).
Oczywiście, że Clojure/Lispem początkującemu łatwiej się pokaleczyć.
Ja nie rozsądzam, co jest lepsze - pokazuję tylko, po co są nawiasy w
Clojure i co dają. A czy to lepsze czy gorsze - to już kwestia
osobistej oceny. Ja wolę krótki kod, bez powtórzeń. Jak wolisz długi
kod, z powtórzeniami - Twoja sprawa :)

> > Bo treści są tam 2 linijki a reszta to konwencja. Bo pisząc go ręcznie
> > - można zapomnieć o klauzuli finally. Bo można użyć złego loggera. Bo
> > można użyć e.printStackTrace().
>
> Ta "konwecja" wymusza na nas myslenie, ze robimy cos wiecej niz wywylanie settera. Operacje IO sa krytyczne w wiekszosci systemow i czesto lekcewazone - a co tam, otworze sobie plik i przeczytam cos lub zapisze, przeciez to takie proste, jedna linia kodu - problem w tym ze "pod spodem" to nie jest jedna linia kodu, ani nawet 100. Poki to jest skrypt - helper developera to ok, ale jak chcemy robic cos powazniejszego to bedzie mieli problem.

Ok. Ja nie potrzebuję, żeby język programowania wymuszał na mnie
myślenie - myślę na okrągło (zwłaszcza jak programuję), jest to w
sumie dość męczące. Nie wiem zresztą jak wklejanie tych samych
kawałḱów kodu wzbudzi to myślenie o tym, że robimy coś więcej niż
wywołanie settera. No robimy - jeszcze piszemy klauzulę try { }
finally { }

Nie zauważyłem też, aby klauzula try { } finally { } jakoś zwiększyła
czytelność kodu (jest 6 linii do przeczytania zamiast 2) - ba! nawet
Sun przyznaje się bez bicia, że jest to kiepskie rozwiązanie, skoro w
Javie 7 dodają specjalny case na to.

> > to kwestia właśnie dodania makra. Dodajesz raz makro i masz:
>
> > (with-open-struct-file (struct-is "test.xml" :on-error #'my-error-
> > handler)
> > (read struct-is))
>
> no i sie zaczyna i chociaz to i tak dalekie od uzywalengo to nie widze tego przelicznika 100 razy mnie kodu.

nie rozumiem co się zaczyna (ale może to dobrze ;) kod dla mnie nadal
jest ładny i czytelny

100x - nie rozumiem też dlaczego oczekujesz po kilku linikowym kodzie,
że będzie dużo krótszy w różnych językach. Mówimy tutaj o kodzie,
który idzie w setki tysięcy linii w Javie - wtedy widać dużą różnicę
pisząc w Clojure. Ale też - nie ma gwarancji, że będzie 100x mniej.
Może tylko o 30%. Ale 100.000 linii kodu a 70.000 linii to i tak
czysty zysk (dla mnie - jak mówiłem - jak ktoś lubi długi, stateczny
kod z dużą ilością powtórzeń - nie moja sprawa).

Podsumowując (bo z tym chyba nie dyskutujesz, skoro dyskutujesz z
wynikającymi z tego faktami): Clojure daje krótszy kod niż Java (tak
samo czytelny dla wprawnego w języku programisty). Pozwala uniknąć
powtórzeń w kodzie. Czy to lepiej czy gorzej - to już kwestia
osobistych preferencji.

t

[Tomek Lipski]

> > warto zauważyć, że potrzeba do uwzględniania aspektów niskiego poziomu
> > nie zależy w tym wypadku od nas - tylko od Javy. Nie mamy wolności
> > decyzji za dużo w przypadku Javy.
>
> Masz na mysli JVM? Fakt, niezla bestia, ale nawet jej mozna pomoc, uwzgledniaja fakty ze np. rozmiar bloku dyskowego to 4KB, a ramki ethernetowej 1,5KB,  lub rozmiar cache'y procesorow, a Java ze swoja skladnia i core api nam tego nie utrudnia.

A kto utrudnia? Która składania/core api? Chociaż raczej jak schodzimy
na taki poziom i na to zwracamy uwagę, to czy na pewno chcemy mieć JVM
- w sumie nieprzewidywalną? Co z tego, że cache w CPU mamy 6 MB jak
nas garbage collector spowolni o 10%? :)
To pewnie zależy od całego projektu oczywiście - nie mówię nie

t

P.S. Fakt, z QBASIC się rozpędziłem :> ale biznesowe funkcjonalności
się dobrze tam opisuje ;)

[Adam Lider]

On Feb 27, 2012, at 6:26 PM, Tomek Lipski wrote:

>> Masz na mysli JVM? Fakt, niezla bestia, ale nawet jej mozna pomoc, uwzgledniaja fakty ze np. rozmiar bloku dyskowego to 4KB, a ramki ethernetowej 1,5KB, lub rozmiar cache'y procesorow, a Java ze swoja skladnia i core api nam tego nie utrudnia.
>
> A kto utrudnia? Która składania/core api? Chociaż raczej jak schodzimy
> na taki poziom i na to zwracamy uwagę, to czy na pewno chcemy mieć JVM
> - w sumie nieprzewidywalną? Co z tego, że cache w CPU mamy 6 MB jak
> nas garbage collector spowolni o 10%? :)

Mam nadzieje, ze mi pomozesz bo z moja znajomoscia Clojure to b. slabo. Zacznijmy od IO.

1. Zapis/odczyt plikow binarnych, tak powyzej 1GB. Na ile Clojure pozwala zrobic to w sposob w miare wydajny?
Wersja Java:

int BLOCK_SIZE = 4 * 1024;
long FILE_SIZE = BLOCK_SIZE * 500L * 500L;
FileOutputStream file = new FileOutputStream("file.bin");
byte[] buffer = new byte[BLOCK_SIZE];
int position = 0;
for (long i = 0; i < FILE_SIZE; i++) {
buffer[position++] = (byte) i;
if (position == BLOCK_SIZE) {
file.write(buffer, 0, BLOCK_SIZE);
position = 0;
}
}
file.close();

Calkiem prosta i normalna implementacja, a juz calkiem optymalna.

Adam.

[Tomek Lipski]

On 27 Lut, 20:46, Adam Lider <adam.li...@googlemail.com> wrote:
> On Feb 27, 2012, at 6:26 PM, Tomek Lipski wrote:
>
> >> Masz na mysli JVM? Fakt, niezla bestia, ale nawet jej mozna pomoc, uwzgledniaja fakty ze np. rozmiar bloku dyskowego to 4KB, a ramki ethernetowej 1,5KB,  lub rozmiar cache'y procesorow, a Java ze swoja skladnia i core api nam tego nie utrudnia.
>
> > A kto utrudnia? Która składania/core api? Chociaż raczej jak schodzimy
> > na taki poziom i na to zwracamy uwagę, to czy na pewno chcemy mieć JVM
> > - w sumie nieprzewidywalną? Co z tego, że cache w CPU mamy 6 MB jak
> > nas garbage collector spowolni o 10%? :)
>
> Mam nadzieje, ze mi pomozesz bo z moja znajomoscia Clojure to b. slabo. Zacznijmy od IO.
>
> 1. Zapis/odczyt plikow binarnych, tak powyzej 1GB. Na ile Clojure pozwala zrobic to w sposob w miare wydajny?

Nie do końca czuję, co to by dało i komu. Pokazujesz jakiś maciupki
kawałek kodu, który nie realizuje żadnej sensownej logiki. Co da
pokazanie, że w Clojure to wygląda lepiej albo gorzej? Ja nie mówię
tutaj o jakichś 20-linikowcach, bo można je pisać we wszystkim. Zalety
makr pokazują się dopiero, kiedy tego kodu jest więcej niż 20 linii.

Jak chcesz ten kod napisać dobrze i mieć go wydajnie - napisz go w C.

Jak chcesz, możemy odwrócić stół - weź proszę zagadkę einsteina o
której pisałem i napisz kod w Javie, który rozwiązuje zagadki tego
typu (http://weitz.de/einstein.html).

Nie mówiąc o tym, że we wklejonym kodzie masz błędy stylistyczne (np.
zmienne nazwane jak stałe) i logiczne (np. zapomniałeś o klauzuli
finally - dokładnie tak jak pisałem :))))))))))))

t

[ags]

Jako programista staram sie nie pisac kodu, bo jedyny kod, ktory nie ma bledow, to ten ktorego nie ma! Istniejacy kod sie glownie czyta, mniej kodu = lepiej, zobacz na historie javaca chocby.

[Adam Lider]

On Feb 27, 2012, at 10:50 PM, Tomek Lipski wrote:

> On 27 Lut, 20:46, Adam Lider <adam.li...@googlemail.com> wrote:
>> On Feb 27, 2012, at 6:26 PM, Tomek Lipski wrote:
>>
>>>> Masz na mysli JVM? Fakt, niezla bestia, ale nawet jej mozna pomoc, uwzgledniaja fakty ze np. rozmiar bloku dyskowego to 4KB, a ramki ethernetowej 1,5KB, lub rozmiar cache'y procesorow, a Java ze swoja skladnia i core api nam tego nie utrudnia.
>>
>>> A kto utrudnia? Która składania/core api? Chociaż raczej jak schodzimy
>>> na taki poziom i na to zwracamy uwagę, to czy na pewno chcemy mieć JVM
>>> - w sumie nieprzewidywalną? Co z tego, że cache w CPU mamy 6 MB jak
>>> nas garbage collector spowolni o 10%? :)
>>
>> Mam nadzieje, ze mi pomozesz bo z moja znajomoscia Clojure to b. slabo. Zacznijmy od IO.
>>
>> 1. Zapis/odczyt plikow binarnych, tak powyzej 1GB. Na ile Clojure pozwala zrobic to w sposob w miare wydajny?
>
> Nie do końca czuję, co to by dało i komu. Pokazujesz jakiś maciupki
> kawałek kodu, który nie realizuje żadnej sensownej logiki.

Podalem przyklad, gdzie Java pokazuje swoje mozliwosci (wcale nie jakies wysilone) na delikatnie nizszym poziomie. Nie wiem dlaczego zapis do pliku jest dla Ciebie bezsesnsona logika. Wedlug mojego doswiadczenia to czesto krytyczny element aplikacji. Nie zawsze to bedzie xGB, ale xMB to juz sie zdarza dosc czesto. To mial byc poczatek, wspolbieznosci zostawilem na pozniej. Szkoda.
Przypominam, ze sam mnie do tego zacheciles powyzej.

> Co da pokazanie, że w Clojure to wygląda lepiej albo gorzej? Ja nie mówię
> tutaj o jakichś 20-linikowcach, bo można je pisać we wszystkim.
> Zalety makr pokazują się dopiero, kiedy tego kodu jest więcej niż 20 linii.

Te, czy inne 20 lub mniej linij kodu moze byc krytyczne dla wydajnosci systemu skadajacego sie z tysiecy lini kodu, tzw hotspot

> Jak chcesz ten kod napisać dobrze i mieć go wydajnie - napisz go w C.

Skad wiesz? Napisales? Przetestowales? a moze w Javie bedzie wydajniej?

> Jak chcesz, możemy odwrócić stół - weź proszę zagadkę einsteina o
> której pisałem i napisz kod w Javie, który rozwiązuje zagadki tego
> typu (http://weitz.de/einstein.html).

Tutaj faktycznie mamy realny i biznesowy przypadek.
Oczywiscie nie bede dowodzil ze w Javie czy C, mozna zrobic lepiej rozwiazanie logicznych zagadek (chyba ze szybsze rozwiazanie).

> Nie mówiąc o tym, że we wklejonym kodzie masz błędy stylistyczne (np.
> zmienne nazwane jak stałe) i logiczne (np. zapomniałeś o klauzuli
> finally - dokładnie tak jak pisałem :))))))))))))

???
jak rowniez nie ma metody main, odpowiednich importow itp. Ten kod nie jest przypadkowy, ale nastepnym razem bede wiedzial, ze nalezy wkleic cala klase ;)

Liczylem ze podysktujemy na fajnym ("niskim":)) poziomie. Szkoda.

Adam.

[Michal Margiel]

W dniu 27 lutego 2012 22:55 użytkownik ags <andrzej...@gmail.com> napisał:

Jako programista staram sie nie pisac kodu, bo jedyny kod, ktory nie ma bledow, to ten ktorego nie ma! Istniejacy kod sie glownie czyta, mniej kodu = lepiej, zobacz na historie javaca chocby.

To oczywiście nie jest prawda :)

Refactoring (jak np extract method) często prowadzi  do dużo większej liczby linii kodu ale znacząco poprawia  jego czytelność.

TDD też raczej nie zmniejsza kodu do przeczytania (często testów jest więcej niż kodu produkcyjnego) ale wprowadza testy/przykłady które są nieocenione przy próbie zrozumienia co się w naszym kodzie dzieje.

Tako rzecze wujek Bob, a doświadczenie wyniesione z mojej codziennej pracy mówi, ze facet ma rację :)

Także ja jestem bardzo daleki od stwierdzenia, że mniej kodu -> to lepszy kod.

--
Pozdrawiam/Best regards
Michał Margiel

http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu

[Radosław Szmit]

W dniu 28 lutego 2012 09:04 użytkownik Michal Margiel <michal....@gmail.com> napisał:

To oczywiście nie jest prawda :)

Refactoring (jak np extract method) często prowadzi  do dużo większej liczby linii kodu ale znacząco poprawia  jego czytelność.

I tak i nie. Sam dobrze wiesz, że jak wydzielisz jakąś funkcję, metodę to później używasz jej w wielu miejscach i zamiast całego bloku kodu masz jedną linijkę z użyciem jednej funkcji. Pytanie też jak liczyć ilość kodu? Liczyć biblioteki? A co jeśli to nasza wewnętrzna biblioteka? Liczyć testy? Liczyć kod samej scali, jeśli ktoś w tym pisze?
 

Tako rzecze wujek Bob, a doświadczenie wyniesione z mojej codziennej pracy mówi, ze facet ma rację :)

Dodatkowo wujek Bob wielokrotnie pisał, że "check exceptions" to zła praktyka i przeszłość, a i tak mnóstwo osób nadal je tworzy, używa a nawet twierdzi że to bardzo dobra praktyka. Jednak przewijające się przez kod bloki try/catch dość mocno zaciemniają obraz i chyba w większości języków po Javie ich po prostu nie ma (np. w C#).

--
Pozdrawiam serdecznie
Radosław Szmit

[Tomek Lipski]

>
> > Co da pokazanie, że w Clojure to wygląda lepiej albo gorzej? Ja nie mówię
> > tutaj o jakichś 20-linikowcach, bo można je pisać we wszystkim.
> > Zalety makr pokazują się dopiero, kiedy tego kodu jest więcej niż 20 linii.
>
> Te, czy inne 20 lub mniej linij kodu moze byc krytyczne dla wydajnosci systemu skadajacego sie z tysiecy lini kodu, tzw hotspot

Nie do końca rozumiem - chcesz powiedzieć, że dlatego że 20 linii kodu
ze 100.000 będzie miało krytyczne znaczenie dla wydajności systemu
- należy go pisać w tym języku, który najlepiej pasuje do tych 20
linii?

> > Jak chcesz ten kod napisać dobrze i mieć go wydajnie - napisz go w C.
>
> Skad wiesz? Napisales? Przetestowales? a moze w Javie bedzie wydajniej?

Jak mówią - C łączy potęgę assemblera z elastycznością assemblera ;-)

> > Nie mówiąc o tym, że we wklejonym kodzie masz błędy stylistyczne (np.
> > zmienne nazwane jak stałe) i logiczne (np. zapomniałeś o klauzuli
> > finally - dokładnie tak jak pisałem :))))))))))))
>
> ???
> jak rowniez nie ma metody main, odpowiednich importow itp. Ten kod nie jest przypadkowy, ale nastepnym razem bede wiedzial, ze nalezy wkleic cala klase ;)

Raczej pokazuje Twój styl - jak piszesz, jakie masz nawyki. Ale nie
będę się kłócił, pewnie jakbyś wiedział, że ktoś przeczyta ten kod, to
byś napisał lepiej/ładniej. Jest taka zasada - "zawsze pisz swój kod
tak, jakby osoba, która w przyszłości go będzie utrzymywać była
maniakalnym mordercą, który wie gdzie mieszkasz". I coś w tym jest :>

>
> Liczylem ze podysktujemy na fajnym ("niskim":)) poziomie. Szkoda.
>

Przykro mi, że Cię rozczarowałem. Ja raczej programuję na wyższym
poziomie abstrakcji niż kopiowanie plików, więc może dlatego trudno mi
zrozumieć Twoje podejście. Dla mnie raczej ważniejsze jest, żeby
stworzony system był łatwy w późniejszym rozwoju i utrzymaniu, żeby
kod był krótki i zwięzły. Optymalizację tych kodu robię raczej na
końcu a nie na początku (chyba, że widzę od razu jakiś hotspot) -
jakoś wtedy łatwiej jest ustalić, który kod jest bottleneckiem.

t

[Tomek Lipski]

On 28 Lut, 09:04, Michal Margiel <michal.marg...@gmail.com> wrote:

> W dniu 27 lutego 2012 22:55 użytkownik ags <andrzej.grze...@gmail.com>napisał:
>
> > Jako programista staram sie nie pisac kodu, bo jedyny kod, ktory nie ma
> > bledow, to ten ktorego nie ma! Istniejacy kod sie glownie czyta, mniej kodu
> > = lepiej, zobacz na historie javaca chocby.
>
> > To oczywiście nie jest prawda :)
>
> Refactoring (jak np extract method) często prowadzi  do dużo większej
> liczby linii kodu ale znacząco poprawia  jego czytelność.
> TDD też raczej nie zmniejsza kodu do przeczytania (często testów jest
> więcej niż kodu produkcyjnego) ale wprowadza testy/przykłady które są
> nieocenione przy próbie zrozumienia co się w naszym kodzie dzieje.

Ale ten kod robi więcej - testuje.

>
> Tako rzecze wujek Bob, a doświadczenie wyniesione z mojej codziennej pracy
> mówi, ze facet ma rację :)
> Także ja jestem bardzo daleki od stwierdzenia, że mniej kodu -> to lepszy
> kod.

Trochę tutaj upraszczasz moją wypowiedź. Ja nie mówię, że mniej kodu =
lepiej automatycznie (chociaż programowałem parę lat w Perlu) - tylko
mniej kodu, który robi to samo i jest tak samo czytelny = lepiej. I
autorzy języka Java myślą tak samo np. wprowadzając for each'a czy try
dla resource'ów.

Ja po prostu jestem przeciwnikiem kodu zbędnego, nie kodu czytelnego.
Dlatego nie mówię - piszcie długie linijki w Javie, żeby było mniej
LoC - tylko sugeruję, że zastosowanie Clojure daje czytelny kod, który
jest krótszy niż odpowiednik w Javie. That's it.

t

[Adam Lider]

On Feb 28, 2012, at 9:36 AM, Tomek Lipski wrote:

>> Te, czy inne 20 lub mniej linij kodu moze byc krytyczne dla wydajnosci systemu skadajacego sie z tysiecy lini kodu, tzw hotspot
> Nie do końca rozumiem - chcesz powiedzieć, że dlatego że 20 linii kodu
> ze 100.000 będzie miało krytyczne znaczenie dla wydajności systemu
> - należy go pisać w tym języku, który najlepiej pasuje do tych 20
> linii?

Oczywiscie ze nie. Zauwaz prosze, ze dwa ostatnie moje wypowiedzi dotycza aspektow blizszych sprzetowi i bronia lekko wysmianej przez Ciebie tezy, ze cytujac siebie:

Java jest naprawde rewelacyjna pod tym wzgledem ze daje nam do pracy abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy biznesowe wymagania, jak rowniez uwzgledniajacy aspekty niskiego poziomu, kiedy jest taka potrzeba.

Chcialem podsykutowac o mozliwosciach jezyka w implementacji czegos innego niz np. naliczanie rabatu dla zamowienia, bo wiadomo, ze z tym java radzi sobie conajmniej dobrze.

>>> Nie mówiąc o tym, że we wklejonym kodzie masz błędy stylistyczne (np.
>>> zmienne nazwane jak stałe) i logiczne (np. zapomniałeś o klauzuli
>>> finally - dokładnie tak jak pisałem :))))))))))))
>>
>> ???
>> jak rowniez nie ma metody main, odpowiednich importow itp. Ten kod nie jest przypadkowy, ale nastepnym razem bede wiedzial, ze nalezy wkleic cala klase ;)
>
> Raczej pokazuje Twój styl - jak piszesz, jakie masz nawyki. Ale nie
> będę się kłócił, pewnie jakbyś wiedział, że ktoś przeczyta ten kod, to
> byś napisał lepiej/ładniej. Jest taka zasada - "zawsze pisz swój kod
> tak, jakby osoba, która w przyszłości go będzie utrzymywać była
> maniakalnym mordercą, który wie gdzie mieszkasz". I coś w tym jest :>

Piszac na grupe kilkusetosobowa zakladalem, ze ktos to przeczyta, ale zalozylem tez, ze pewne rzeczy sa domysle, jak to ze kopiujac kod z ide to maila powycinalem troche kodu. Moj blad.
>

Adam.

[Tomek Lipski]

On 28 Lut, 09:56, Adam Lider <adam.li...@googlemail.com> wrote:
> On Feb 28, 2012, at 9:36 AM, Tomek Lipski wrote:
>
> >> Te, czy inne 20 lub mniej linij kodu moze byc krytyczne dla wydajnosci systemu skadajacego sie z tysiecy lini kodu, tzw hotspot
> > Nie do końca rozumiem - chcesz powiedzieć, że dlatego że 20 linii kodu
> > ze 100.000 będzie miało krytyczne znaczenie dla wydajności systemu
> > - należy go pisać w tym języku, który najlepiej pasuje do tych 20
> > linii?
>
> Oczywiscie ze nie. Zauwaz prosze, ze dwa ostatnie moje wypowiedzi dotycza aspektow blizszych sprzetowi i bronia lekko wysmianej przez Ciebie tezy, ze cytujac siebie:
> Java jest naprawde rewelacyjna pod tym wzgledem ze daje nam do pracy abstrakcje, dzieki ktorej mozemy pisac kod ladnie wyrazajacy biznesowe wymagania, jak rowniez uwzgledniajacy aspekty niskiego poziomu, kiedy jest taka potrzeba.
> Chcialem podsykutowac o mozliwosciach jezyka w implementacji czegos innego niz np. naliczanie rabatu dla zamowienia, bo wiadomo, ze z tym java radzi sobie conajmniej dobrze.

Ah, to przepraszam. Stwierdzenie wydało mi się na tyle ironiczne, że w
ogóle o tym zapomniałem. Pisząc system w Clojure, jeśli miałbym
kawałki niskopoziomowe - zapewne napisałbym je w Javie. Naliczanie
rabatów - w Clojure.
Ale to tylko "rule of the thumb" a nie konkretne doświadczenie.

Nie ma co chyba dyskutować dalej. Nadal zachęcam do zapoznania się z
np. Joy of Clojure albo ANSI Common Lisp (nie są długie ~300 stron z
kodem), bo tak to widzę, że trudno mi w paru emailach wytłumaczyć o co
chodzi jak jednak osoba zna tylko Javę.

t