> 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)
--
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
Na moim polskojęzycznym blogu też już jest. Dzięki za opiekę nad tematem.
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
> 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.
--
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
>
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 -
--
Regards/Pozdrawiam,
Dawid Bielecki
http://www.dawciobiel.com
e-mail: dawciobiel AT gmail DOT com
@Dawid Bielecki Kiedy będą ogłoszone wyniki losowania InteliJ IDEA?
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
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
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
Chyba zamiast z HR :)
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
>
W dniu 23 lutego 2012 15:56 użytkownik Michal Margiel
<michal....@gmail.com> napisał:
> Witajcie,nawiasy to jeden z elementów składni, a ta bardzo często decyduje o
>
> Nie mogę wyjść ze zdziwienia, że teraz jedną z miar
> "fajności"/"użyteczności" języka jest ilość nawiasów w kodzie.
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~
\_/
|||
W dniu 23 lutego 2012 16:07 użytkownik Michal Margiel
JavaFX Script miała jeden feler. Nie była javą. Składnia bardzo
przyjemna, ale nie pasująca do "javowego sposobu myślenia".
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ł:
>
>
A co zamiast PR ?
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.
--
Serdecznie Pozdrawiam,
Krzysztof Nielepkowicz
fotografia : fotomilo.pl
Witajcie,Nie mogę wyjść ze zdziwienia, że teraz jedną z miar "fajności"/"użyteczności" języka jest ilość nawiasów w kodzie.
--
@Dawid Bielecki Kiedy będą ogłoszone wyniki losowania InteliJ IDEA?+1
?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
W dniu 23 lutego 2012 19:54 użytkownik Irek Matysiewicz
<iir...@gmail.com> napisał:
--
Pozdrawiam,
Łukasz
--
Sent from my mobile device
... 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://...
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
> Warto jednak, żeby wcześniej ustalić ile mają czasu na keynote
Odnotowane. Ile proponujesz czasu na przemówienie? 5 czy bliżej 10 minut?
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.
MJ
> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
> - 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ń.
2012/2/23 Irek Matysiewicz <iir...@gmail.com>:
Zapomnij o tym. Bardzo żałowałem tego porównania, bo jak pamiętasz,
> - stwierdziłeś że w typowym kodzie Clojure jest mniej nawiasów niż w Javie.
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.
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?
2012/2/24 Irek Matysiewicz <iir...@gmail.com>:
Za słabym w temacie, aby odpowiedzieć właściwie, a czuję, że poziom
> Ale się migasz od odpowiedzi :-)
> Porównania są użyteczne bo dają jakiś kontekst i od razu wiadomo co do
> czego.
zainteresowania u Ciebie wzrasta i szkoda byłoby to stracić. Wolę
przetrzymać Cię chwilę.
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.
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.
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
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ą.
W dniu 24 lutego 2012 14:31 użytkownik Irek Matysiewicz
<iir...@gmail.com> napisał:
>
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ę.
--
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
> 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!
> 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!
Zacząłem, ale poległem. Będę musiał do tego wrócić jednak, bo wielu
znawców tematu Clojure poleca jako lekturę obowiązkową.
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 :)
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?
Groovy i Scala nie są językami funkcyjnymi. To hybrydy, które
umożliwiają programowanie funkcyjne,
Zobacz co stało się z javaFX Script czy Cobolem. Poległy ponieważ miały "składnię odbiegającą od przyjętych
norm".
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ł:
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ę.
> 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.
> 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.
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ł:
> (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)
:-)
> Ale sam dalej przyznałeś że Clojure też umożliwia programowanie obiektowe,Clojure umożliwia konstrukcjami języka zbudowanie systemu obiektowego,
> czyli też w pewnym, choć może trochę mniejszym stopniu jest taką hybrydą.
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ą.
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.
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
--
> 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!
> 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.
> 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 -
>
>> 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
>
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
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.
> 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.
>> 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.
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.
> 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.
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ść.
Tako rzecze wujek Bob, a doświadczenie wyniesione z mojej codziennej pracy mówi, ze facet ma rację :)
>> 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.