Jython reaktywacja
Rob Wolfe
Hej,
od jakiegoś czasu czytam tu i tam, że prace nad Jythonem
znowu ruszyły z kopyta. No ale nie wiedziałem, że to wygląda
aż tak optymistycznie:
http://www.eweek.com/c/a/Application-Development/Sun-Hires-Python-Experts/
http://fwierzbicki.blogspot.com/2008/02/jythons-future-looking-sunny.html
RW
Rafał Zawadzki
o, będą współpracować z ianem murdockiem - autorem dystrybucji która
zmieniła świat ;)
--
bluszcz
"Don't criticise yourself, it's my privilige." - Bitter Moon
http://web-dev.pl - Dynamiczny świat internetowych aplikacji od środka
Adam Przybyla
open source spoza swoich projektow, widac, ze konkurencja
powtarza tylko to posuniecie;-) Z powazaniem
Adam Przybyla
Rob Wolfe
Tam gdzie się wielcy biją, to my szaraki możemy tylko skorzystać. ;)
Ale w Sun-ie to faktycznie coś drgnęło. To nie jest jednorazowe
posunięcie, najpierw Ian Murdock, potem JRuby, a teraz Jython...
wygląda to ciekawie.
RW
Rafał Zawadzki
> potem JRuby,
- jeszcze gorzej ;)
> a teraz Jython...
W końcu mają szansę się zrehabilitować i odzyskać twarz ;)
Jarek Zgoda
> Z firmą Sun jest jróżnie, najpierw fatalnie - Java
>
>> potem JRuby,
>
> - jeszcze gorzej ;)
>
>> a teraz Jython...
>
> W końcu mają szansę się zrehabilitować i odzyskać twarz ;)
Twarz Suna przypomina rozdeptany kalafior - to twarz Jonathana
Schwartza. Ich poprzednia (McNealy) twarz miała lepsze zęby, ale
wyglądała jak dno mydelniczki.
--
Jarek Zgoda
http://zgodowie.org/
"We read Knuth so you don't have to" - Tim Peters
Rafał Zawadzki
> Rafał Zawadzki pisze:
>> Z firmą Sun jest jróżnie, najpierw fatalnie - Java
>>
>>> potem JRuby,
>>
>> - jeszcze gorzej ;)
>>
>>> a teraz Jython...
>>
>> W końcu mają szansę się zrehabilitować i odzyskać twarz ;)
>
> Twarz Suna przypomina rozdeptany kalafior - to twarz Jonathana
> Schwartza. Ich poprzednia (McNealy) twarz miała lepsze zęby, ale
> wyglądała jak dno mydelniczki.
>
Niesamowite! Nie uwierzysz - ale czytając o firmie sun odnośnie tego newsa
zajrzałem na stronę gdzie są wymienieni wszyscy CEO.
I powiedziałem na głos "o jezu, co za parszywe gęby" ;)
Radosław Bułat
> Z firmą Sun jest jróżnie, najpierw fatalnie - Java
>
>> potem JRuby,
>
> - jeszcze gorzej ;)
Wiesz, myślę, że gdyby nie JRuby to Jython by się nie podniósł i umarłby
śmiercią naturalną. Dlatego takie docinki, pomimo dodania ";)" (co nie
uznaję wcale za żart z Twojej strony), są nie bardzo na miejscu.
>
>> a teraz Jython...
>
> W końcu mają szansę się zrehabilitować i odzyskać twarz ;)
>
--
Radosław Bułat
http://radarek.jogger.pl - mój blog
Rafał Zawadzki
> Rafał Zawadzki pisze:
>> Z firmą Sun jest jróżnie, najpierw fatalnie - Java
>>
>>> potem JRuby,
>>
>> - jeszcze gorzej ;)
>
> Wiesz, myślę, że gdyby nie JRuby to Jython by się nie podniósł i umarłby
> śmiercią naturalną. Dlatego takie docinki, pomimo dodania ";)" (co nie
> uznaję wcale za żart z Twojej strony), są nie bardzo na miejscu.
Bardzo mnie zastanawia Twoja intepretacja ";)" inaczej niż żart.
Tell me about your mo^W point of view ;)
--
bluszcz
Radosław Bułat
> Radosław Bułat pisze:
>> Rafał Zawadzki pisze:
>>> Z firmą Sun jest jróżnie, najpierw fatalnie - Java
>>>
>>>> potem JRuby,
>>>
>>> - jeszcze gorzej ;)
>>
>> Wiesz, myślę, że gdyby nie JRuby to Jython by się nie podniósł i
>> umarłby śmiercią naturalną. Dlatego takie docinki, pomimo dodania
>> ";)" (co nie uznaję wcale za żart z Twojej strony), są nie bardzo na
>> miejscu.
>
> Bardzo mnie zastanawia Twoja intepretacja ";)" inaczej niż żart.
>
> Tell me about your mo^W point of view ;)
>
Ogólna interpretacja ";)" oczywiście oznacza żart. Ale to, że taki
dodatek występuje nie oznacza, że to jest żart. Bo co miał niby znaczyć
Twój żarcik? Jeśli piszesz coś takiego na grupie pythona to chyba nie
dziwne, że odbieram to tak jak odbieram? Uprzedzam, że poczucie humoru
mam, ale czepiam się dlatego, że niby my programiści rubiego, perla,
pythona jesteśmy po tej samej stronie, ale takie dopiski ("niby żart")
pokazują coś innego. Potem dziwić się, że ludzie tak kurczowo trzymają
się jednego języka ("skoro lubię Pythona, a Pythoniści nie lubią Rubiego
to ja go też nie lubię").
Adam Karpierz
> Ogólna interpretacja ";)" oczywi¶cie oznacza żart. Ale to, że taki dodatek
> występuje nie oznacza, że to jest żart. Bo co miał niby znaczyć Twój
> żarcik?
Radek, zdecydowanie przesadzasz
My tu jestesmy moze lekko ironiczni i zlosliwi,
ale jednak spolegliwi a nie zgryzliwi czy wrogo nastawieni :)
Co do Rubiego
Znielubialem go z dwoch powodow.
1. Mmimo osiagniecia wiekszej zgodnosci 'paradygmatycznej'
z OOP zatracil zdecydowanie przejrzystosc skladni (Perlizacja)
2. Pomimo ze powstal lata temu _wybitnie_ na bazie Pythona,
autorzy nie wspomnieli o Pythonie ani slowem.
Byla bardzo dawno temu o tym dyskusja na comp.lang.python
wcale nienaznaczona niechecia do tworcow Rubiego ale.. takim
jakgdyby jednak lekkim niesmakiem i kilkoma neizwykle
lekko ironicznymi komentarzami w stylu ze oprocz twardego
prawa (Python jest wolny od restrykcji na mody=fikacje/wykorzystanie)
istnieje jeszcze cos takiego jak kultura ;).
Wiec jesli juz to Ruby zawdziecza wszystko Pythonowi a nie
odwrotnie.
AK
Piotr 'piter' Hlawski
> Użytkownik "Radosław Bułat" <rada...@poczta.fm> napisał:
>
>> Ogólna interpretacja ";)" oczywiście oznacza żart. Ale to, że taki
>> dodatek występuje nie oznacza, że to jest żart. Bo co miał niby znaczyć
>> Twój żarcik?
>
> Radek, zdecydowanie przesadzasz
> My tu jestesmy moze lekko ironiczni i zlosliwi,
> ale jednak spolegliwi a nie zgryzliwi czy wrogo nastawieni :)
Spolegliwy - to taki na którym można polegać. To tak gwoli ścisłości. Czy
właśnie to miałeś na myśli? :)
>
> Co do Rubiego
> Znielubialem go z dwoch powodow.
>
> 1. Mmimo osiagniecia wiekszej zgodnosci 'paradygmatycznej'
> z OOP zatracil zdecydowanie przejrzystosc skladni (Perlizacja)
>
Kwestia gustu. Dla mnie składnia Ruby jest bardziej przejrzysta niż
Python'a. "Perlizacja" jest tutaj mitem powtarzanym z ust do ust, de facto
odchodzi się dzisiaj w Ruby od jakichkolwiek zawiłych perlowych
naleciałości...
--
[ Piotr 'piter' Hlawski ( <phlawski$gmail,com> ) ( GG: 4534287 ) ]
Rob Wolfe
Piotr 'piter' Hlawski napisał(a):
> Adam Karpierz wrote:
>
> > Uzytkownik "Radoslaw Bulat" <rada...@poczta.fm> napisal:
> >
> >> Ogolna interpretacja ";)" oczywiscie oznacza zart. Ale to, ze taki
> >> dodatek wystepuje nie oznacza, ze to jest zart. Bo co mial niby znaczyc
> >> Twoj zarcik?
> >
> > Radek, zdecydowanie przesadzasz
> > My tu jestesmy moze lekko ironiczni i zlosliwi,
> > ale jednak spolegliwi a nie zgryzliwi czy wrogo nastawieni :)
>
> Spolegliwy - to taki na ktorym mozna polegac. To tak gwoli scislosci. Czy
> wlasnie to miales na mysli? :)
Zakladam, ze chodzilo o potoczne znaczenie tego slowa:
http://sjp.pwn.pl/lista.php?co=spolegliwy
patrz: pkt2
> > Co do Rubiego
> > Znielubialem go z dwoch powodow.
> >
> > 1. Mmimo osiagniecia wiekszej zgodnosci 'paradygmatycznej'
> > z OOP zatracil zdecydowanie przejrzystosc skladni (Perlizacja)
> >
>
> Kwestia gustu. Dla mnie skladnia Ruby jest bardziej przejrzysta niz
> Python'a. "Perlizacja" jest tutaj mitem powtarzanym z ust do ust, de facto
> odchodzi sie dzisiaj w Ruby od jakichkolwiek zawilych perlowych
> nalecialosci...
Hmm... jakos dziwnie czesto mozna sie z tym mitem zderzyc:
<code>
def initialize(f)
unless defined? f.gets
f = open(f, "r")
opened = true
end
@header = {}
@body = []
begin
while line = f.gets()
line.chop!
next if /^From /=~line # skip From-line
break if /^$/=~line # end of header
if /^(\S+?):\s*(.*)/=~line
(attr = $1).capitalize!
@header[attr] = $2
elsif attr
line.sub!(/^\s*/, '')
@header[attr] += "\n" + line
end
end
return unless line
while line = f.gets()
break if /^From /=~line
@body.push(line)
end
ensure
f.close if opened
end
end
</code>
Nie wiem na ile ta funkcja jest reprezentatywna dla Rubiego, ale jesli
jest,
to dla mnie podobienstwo do Perla jest uderzajace.
Poza tym mozliwosc opuszczania nawiasow przy wywolaniu funkcji dobija
mnie maksymalnie.
Ale jak powiedziales sa gusta i gusciki. Nie wszyscy musza lubic
Ruby'iego,
tak samo jak i Pythona.
RW
Piotr Meyer
>> Kwestia gustu. Dla mnie skladnia Ruby jest bardziej przejrzysta niz
>> Python'a. "Perlizacja" jest tutaj mitem powtarzanym z ust do ust, de facto
>> odchodzi sie dzisiaj w Ruby od jakichkolwiek zawilych perlowych
>> nalecialosci...
>
> Hmm... jakos dziwnie czesto mozna sie z tym mitem zderzyc:
Troszkę się chyba nie zrozumieliście. AFAIK to Ruby porzuca "złe"
nawyki z Perla, jak na przykład nadużywanie zmiennej $_ - dzięki
czemu zmniejsza się ilość sytuacji, w których nie wiadomo skąd się,
do cholery, wzięła ta wartość w tym miejscu.
Przykład kodu do czepiania się też dobrałeś nieszczęśliwie, bo
odpowiednik:
next if /^From /=~line
Możesz też wygenerować w Pythonie (jeśli masz na myśli to, że
między operatorem '~=' a argumentami nie ma spacji. Jeśli mówisz
o konstrukcjach 'wyrażenie' if 'warunek' to - stosowane rozsądnie
- są bardzo wygodne. A i Python ostatnio dorobił się podobnego
potworka dla przypisań, prawda?
Gdybyśmy mieli czepiać się na serio to proponowałbym wytknąć
pomysł, żeby metoda zwracała wynik ostatnio wykonanego polecenia:
def t1(jeden)
jeden+=2
return "dwa"
end
def t2(jeden)
jeden+=2
end
puts t1(1) # => "dwa"
puts t2(1) # => 3
To próbka dla 1.8, ciekawe, czy w 1.9 się to zmieniło.
> Nie wiem na ile ta funkcja jest reprezentatywna dla Rubiego, ale jesli
> jest, to dla mnie podobienstwo do Perla jest uderzajace.
Zadeklaruj się, czy przeszkadza Ci to, ze "Zapis jest taki jak w Perlu,
co prowadzi do... i jest złe" czy "Zapis nie wygląda tak, jak w Pythonie".
--
Piotr 'aniou' Meyer
Tomek Paczkowski
--
Oinopion
Adam Karpierz
napisał:
> Spolegliwy - to taki na którym można polegać. To tak gwoli ścisłości. Czy
> właśnie to miałeś na myśli? :)
Oba znaczenia sa prawdziwe :)
AK
Rob Wolfe
> Rob Wolfe <r...@smsnet.pl> wrote:
>
>>> Kwestia gustu. Dla mnie skladnia Ruby jest bardziej przejrzysta niz
>>> Python'a. "Perlizacja" jest tutaj mitem powtarzanym z ust do ust, de facto
>>> odchodzi sie dzisiaj w Ruby od jakichkolwiek zawilych perlowych
>>> nalecialosci...
>>
>> Hmm... jakos dziwnie czesto mozna sie z tym mitem zderzyc:
>
> Troszkę się chyba nie zrozumieliście. AFAIK to Ruby porzuca "złe"
> nawyki z Perla, jak na przykład nadużywanie zmiennej $_ - dzięki
> czemu zmniejsza się ilość sytuacji, w których nie wiadomo skąd się,
> do cholery, wzięła ta wartość w tym miejscu.
Plus dla Ruby'iego.
>
> Przykład kodu do czepiania się też dobrałeś nieszczęśliwie, bo
> odpowiednik:
>
> next if /^From /=~line
>
> Możesz też wygenerować w Pythonie (jeśli masz na myśli to, że
Nie mam zamiaru udowadniać czy Python jest lepszy od Ruby'iego
czy nie. Pokazałem, że Ruby ma podobne konstrukcje do Perla
i dla mnie (i pewnie wielu innych) jest do niego podobny.
> między operatorem '~=' a argumentami nie ma spacji. Jeśli mówisz
> o konstrukcjach 'wyrażenie' if 'warunek' to - stosowane rozsądnie
> - są bardzo wygodne. A i Python ostatnio dorobił się podobnego
> potworka dla przypisań, prawda?
O to, to ... "potworka". ;)
Ale bardziej miałem na myśli te wszystkie "break if", "next if",
mieszanie wyrażeń regularnych z logiką kodu itp.
> Gdybyśmy mieli czepiać się na serio to proponowałbym wytknąć
> pomysł, żeby metoda zwracała wynik ostatnio wykonanego polecenia:
>
>
> def t1(jeden)
> jeden+=2
> return "dwa"
> end
>
>
> def t2(jeden)
> jeden+=2
> end
>
> puts t1(1) # => "dwa"
> puts t2(1) # => 3
>
> To próbka dla 1.8, ciekawe, czy w 1.9 się to zmieniło.
>
>> Nie wiem na ile ta funkcja jest reprezentatywna dla Rubiego, ale jesli
>> jest, to dla mnie podobienstwo do Perla jest uderzajace.
>
> Zadeklaruj się, czy przeszkadza Ci to, ze "Zapis jest taki jak w Perlu,
> co prowadzi do... i jest złe" czy "Zapis nie wygląda tak, jak w Pythonie".
Lubię przejrzystość, a ani Ruby ani Perl przejrzyste *DLA MNIE* nie są,
choć próbowałem się ich nauczyć.
Nie ciągnijmy tego, bo jak Tomek zauważył szkoda czasu.
RW
Radosław Bułat
>> żarcik?
>
> Radek, zdecydowanie przesadzasz
> My tu jestesmy moze lekko ironiczni i zlosliwi,
> ale jednak spolegliwi a nie zgryzliwi czy wrogo nastawieni :)
Ok, ale trzeba uważać. Z php też lubimy (zarówno Wy jak i my Rubiści)
żartować bo go nie lubimy ;).
>
> Co do Rubiego
> Znielubialem go z dwoch powodow.
Moje wtrącenie nie miało wywołać dyskusji dlaczego lubimy język X
bardziej niż Y.
>
> 1. Mmimo osiagniecia wiekszej zgodnosci 'paradygmatycznej'
> z OOP zatracil zdecydowanie przejrzystosc skladni (Perlizacja)
Im dłużej programuję w Rubym tym bardziej dziwią mnie takie stwierdzenia
:). Owszem, Ruby próbował zapożyczyć od Perla co nieco. Przeglądając
nawet stdlib Rubiego możesz napotkać perlowe konstrukcje, nie przeczę. W
tej chwili jedyne co jest jeszcze jako tako akceptowalne to regexpy (=~,
aczkolwiek ja osobiście wolę wersję obiektową string.match(/regexp/)).
Pisanie pięknych składniowo DSLi w Rubym to bułka z masłem (to dlatego
Ci co próbują skopiować walidacje, relacje i inne elementy railsów
polegają na tym).
Jeśli chodzi o samą składnię to Ruby ma zdecydowanie więcej znaków
interpunkcyjnych niż Python ((), &, =>, @, $ itp), których jednak
prawidłowe użycie zwiększa czytelność (spróbuj przeczytać książkę, która
nie ma żadnego przecinka, kropki, wykrzyknika).
Dodam jeszcze, że jak w każdym języku w Rubym też można pisać brzydki kod.
>
> 2. Pomimo ze powstal lata temu _wybitnie_ na bazie Pythona,
> autorzy nie wspomnieli o Pythonie ani slowem.
> Byla bardzo dawno temu o tym dyskusja na comp.lang.python
> wcale nienaznaczona niechecia do tworcow Rubiego ale.. takim
> jakgdyby jednak lekkim niesmakiem i kilkoma neizwykle
> lekko ironicznymi komentarzami w stylu ze oprocz twardego
> prawa (Python jest wolny od restrykcji na mody=fikacje/wykorzystanie)
> istnieje jeszcze cos takiego jak kultura ;).
Nie wiem co to za dyskusja była (mógłbyś podać linka?). Jednakże nie
bardzo mogę to zrozumieć gdyż jak tylko czytam jakieś opisy historii
Rubiego to widzę, że Matz (twórca Rubiego) wzorował się m.in. na
Pythonie. Tak masz napisane choćby na wiki
(http://pl.wikipedia.org/wiki/Ruby_(j%C4%99zyk_programowania) , na
angielskiej to samo). Ostatnio robiłem prezentację o Rubym i tam także
nie widziałem powodów by nie napisać, że Python był jednym ze wzorów dla
Matza
(http://radarek.jogger.pl/2008/03/01/prezentacja-rubiego-i-dwie-inne-sprawy/).
A co do samych zapożyczeń. Nie widzę żadnego problemu z tym. Po pierwsze
żaden z elementów nie został na ślepo wzięty z Python i wstawiony do
Rubiego. A także takie elementy jak obiektowość, metaklasy, domknięcia
itp itd nie są unikalne dla Pythona, więc nie wiem w czym problem. Sam
Guido nie ukrywa, że sam wzorował się na innych językach.
> Wiec jesli juz to Ruby zawdziecza wszystko Pythonowi a nie
> odwrotnie.
>
> AK
>
Hm, ja to odniosłem to kwestii JRuby <=> Jython. Jakoś zapał panom od
Jythona spadła, dopiero sukces JRubiego (jako sukces mam na myśli
zainteresowanie Suna, integracja z netbeans, a także jakość samego
interpretera) spowodował że coś się ruszyło na nowo :).
Sam Ruby zawdzięcza tyle Pythonowi na ile pozwoliło to Matzowi wziąć to
co w nim lubił i dać (pod taką czy inną postacią) do Rubiego. Jakby nie
było Ruby idzie własną ścieżką, Python własną.
Disclaimer: jeśli uważasz wypowiedzi tego typu za flame to sorry. Dla
mnie to zwykła dyskusja (póki nie padają jakieś głupie teksty oraz
przekomarzanie się "w twoim języku to głupie jest to i to").
Radosław Bułat
>
> Piotr 'piter' Hlawski napisał(a):
Uderzająca jest bo:
- pisał ją jakiś leszcz (przepraszam ale nie mogłem się powstrzymać,
obsługa parametru, który może być zarówno obiektem pliku jak i nazwą to
przesada, stąd te opened = true i sprawdzanie w ensure)
- defined? - nie ma sensownego powodu by go używać
- pierwszy raz widzę użycie /regexp/=~"string" (w tej kolejności), skąd
Ty ten kod wziąłeś?;)
- tak jak pisałem wcześniej, użycie =~ to kwestia gustu, ja osobiście
wolę wersję obiektową
- kod parsuje tekst co zawsze wiążę się z regexpami itp - taki kod nigdy
nie będzie ładny
Moja wersja (więcej chyba nie da się wycisnąć), po usunięciu obsługi
zarówno obiektu pliku jak i nazwy (zostawiłem samą nazwę).
<code>
def initialize(fn)
@header = {}
@body = []
File.open(fn) do |f|
while line = f.gets()
line.chop!
next if line.match(/^From/)
break if line.empty?
if m = line.match(/^(\S+?):\s*(.*)/)
attr = m[1].capitalize
@header[attr] = m[2]
elsif attr
line.sub!(/^\s*/, '')
@header[attr] << "\n" + line
end
end
return unless line
while line = f.gets()
break if line.match(/^From /)
@body << line
end
end
end
</code>
Dalej widzisz Perla?:) (niech Cię nie myli @, to zupełnie co innego ;)).
> Poza tym mozliwosc opuszczania nawiasow przy wywolaniu funkcji dobija
> mnie maksymalnie.
Kwestia przyzwyczajenia. W Rubym gdy masz obiekt.cos to 'cos' zawsze
jest metodą (atrybuty nie są widoczne z zewnątrz tak jak w Pythonie).
Niejednoznaczność jest tylko wtedy jak nie podajesz domyślnego odbiorcy
(self), co może zostać pomylone ze zmienną lokalną. Jednakże to nie
powinien być problem, jeśli tylko utrzymuje się małą liczbę zmiennych
lokalnych (co w językach dynamicznych jest musem by kod był czytelny i
łatwy w refaktoryzacji).
> Ale jak powiedziales sa gusta i gusciki. Nie wszyscy musza lubic
> Ruby'iego,
> tak samo jak i Pythona.
>
> RW
Ano nie każdy :). Przymusu nie ma :).
Radosław Bułat
> LOL - serio chcecie się tu tak falme'ować?
>
> --
> Oinopion
? Typowe podejście: ja lubię bardziej Rubiego, Ty bardziej Pythona - to
musi być flame war. Póki co to nawet zapachu siarki nie czuję...
Adam Karpierz
>> Co do Rubiego
>> Znielubialem go z dwoch powodow.
>
> Moje wtrącenie nie miało wywołać dyskusji dlaczego lubimy język X bardziej
> niż Y.
Powinienem napisac "znielubialem"
Identycznie jak u Roba Wolfa moje "znielubienie" mialo
wylacznie podloze merytoryczne/techniczne, a nie emocjonalna.
Wlasnie po to przygladalem sie Ruby-emu aby na niego przejsc
(pelne OO np.) ale.. zrezygnowalem jednak.
Swiadomie i merytorycznie podjalem decyzje pozostania
przy Pythonie (co skutkowalo zakupem domen python.pl
i python.org.pl:)
> Jeśli chodzi o samą składnię to Ruby ma zdecydowanie więcej znaków
> interpunkcyjnych niż Python ((), &, =>, @, $ itp), których jednak
> prawidłowe użycie zwiększa czytelność (spróbuj przeczytać książkę, która
> nie ma żadnego przecinka, kropki, wykrzyknika).
Jest _dokladnie_ odwrotnie.
Jezyk usiany 'interpunkcjami' nie jest czytelny.
Kazdy - nie tylko Ruby
Dobry (w sensie synktatyki) to taki jezyk
ktorego sie nie zna, a rozumie, a nie taki ktorego
sie rozumie dopiero po glebszym poznaniu.
Jak to powiedziel moj Kolega muzyk-amator
"Nie sztuka zagrac na czyms na czym sie umie -
to kazdy palant potfafi :)
sztuka zagrac pieknie ne czyms na czym sie nie umie !"
> Dodam jeszcze, że jak w każdym języku w Rubym też można
> pisać brzydki kod.
To prawda (no sa wyjatki np Algol :)),
ale chodzi o latwosc tego czynu, a i przyjete
powszechnie 'idiomy'.
IMHO w Rubym o wiele latwiej niz w Py o zagmatwanie.
> Nie wiem co to za dyskusja była (mógłbyś podać linka?).
Top bylo dobre 8 lat temu chyba ale..
sprobuje znalesc w archiwach.
> Ostatnio robiłem prezentację o Rubym i tam także nie widziałem powodów by
> nie napisać, że Python był jednym ze wzorów dla Matza
To oczywiste ze sie wzorowal i bardzo ladnie ze to napisales.
Tyle tylko ze _sam Matz_ tego nie przyznal gdy tworzyl Rubyego
> A co do samych zapożyczeń. Nie widzę żadnego problemu z tym. Po pierwsze
> żaden z elementów nie został na ślepo wzięty z Python i wstawiony do
> Rubiego. A także takie elementy jak obiektowość, metaklasy, domknięcia itp
> itd nie są unikalne dla Pythona, więc nie wiem w czym problem. Sam Guido
> nie ukrywa, że sam wzorował się na innych językach.
No wiesz.. wzorowac a zrobic w 80% koie to jednak roznica
Guido zawsze przyznawal ze generatory wzial z Icona
for in z Ady (chyba?) itp
To nie chodzi o zabronienie bazowania :
Ba ! Uwazam ze idiotyzmem jest (poza
nielicznymi wyjatkami vide Prolog) pisanie
jezyka od 0 (mowie o mechanizmach a nie skladni).
Nikt tez nie zarzucal Rubyemui _ze_ powstaje
Wprost przeciwnie.
Chodzilo tylko o nieco wiecej kultury dla swego "Ojca" :)
Co do tego ze nie na slepo - zgadzam sie.
To nie byla kopia dla kopii, ale chec stworzenia czegos
lepszego.
> Hm, ja to odniosłem to kwestii JRuby <=> Jython. Jakoś zapał panom od
> Jythona spadła,
Przyczyna 'braku zapalu' byla i jest prozaiczna
Sun 'olal' zwyczajnei Jythona a Hugunin (tworca Jythona
i wieloletni mainteiner) zostal kupiony przez MS kilka lat
temu wlacznei z raczkujacym wtedy IronPythonem
Sun sie ocknal neidawno
Ruby tu nie ma _nic_ do rzeczy
Jythona nieco uzywalem (i uzywam) gdy o Ruby
nikt nie slyszal
>dopiero sukces JRubiego (jako sukces mam na myśli zainteresowanie Suna,
>integracja z netbeans, a także jakość samego interpretera) spowodował że
>coś się ruszyło na nowo :).
j/w
> Sam Ruby zawdzięcza tyle Pythonowi na ile pozwoliło to Matzowi wziąć to co
> w nim lubił i dać (pod taką czy inną postacią) do Rubiego. Jakby nie było
> Ruby idzie własną ścieżką, Python własną.
Tyle ze 80% Rubiego to kopia Pythona
Nalezalo to przyznac u uszanowac.
I tylko o ta szczypte elementarnej kultury chodzilo
> Disclaimer: jeśli uważasz wypowiedzi tego typu za flame to sorry.
Alez skad.
> Dla mnie to zwykła dyskusja (póki nie padają jakieś głupie teksty oraz
> przekomarzanie się "w twoim języku to głupie jest to i to").
Dla mnnie tez
Dyskusja rozni sie od flame tym ze sa argumenty
Na razie sa.
AK
Piotr Meyer
>> Ostatnio robiłem prezentację o Rubym i tam także nie widziałem powodów by
>> nie napisać, że Python był jednym ze wzorów dla Matza
>
> To oczywiste ze sie wzorowal i bardzo ladnie ze to napisales.
> Tyle tylko ze _sam Matz_ tego nie przyznal gdy tworzyl Rubyego
Dokładnie. Ukrył ten fakt w bardzo przebiegły sposób, pisząc
w przedmowie do pierwszego wydania "Pickaxe Book", że najpierw
zapoznał się z Perlem i Rubym a potem zapragnął stworzyć coś,
co będzie potężniejsze niż ten pierwszy i bardziej obiektowe
niż ten drugi. Przecież wiemy, że nikt nie czyta przedmów i
w ten sposób Matz przekonał autorów książki, że nie muszą co
drugi rozdział wstawiać zastrzeżeń "a to wzięto z Pythona",
"a tamto wzięto z Pythona", "a ideę zapisywania kodu programu
za pomocą znaków z zakresu ASCII wzorowano na...".
--
Piotr 'aniou' Meyer
Rob Wolfe
>> Nie wiem na ile ta funkcja jest reprezentatywna dla Rubiego, ale
>> jesli
>> jest,
>> to dla mnie podobienstwo do Perla jest uderzajace.
>
> Uderzająca jest bo:
> - pisał ją jakiś leszcz (przepraszam ale nie mogłem się powstrzymać,
Bałem się, że to powiesz. ;)
> obsługa parametru, który może być zarówno obiektem pliku jak i nazwą
> to przesada, stąd te opened = true i sprawdzanie w ensure)
> - defined? - nie ma sensownego powodu by go używać
> - pierwszy raz widzę użycie /regexp/=~"string" (w tej kolejności),
> skąd Ty ten kod wziąłeś?;)
Wprost z biblioteki standardowej Ruby'iego.
ruby-1.8.6-p111/lib/mailread.rb
Hmmm...leszcz mówisz... :)
No wybacz, ale `chop` jest aż do bólu perlowy (nie wiem, czy gdzieś jeszcze
występuje). ;)
W każdym razie Twoja wersja duuużo bardziej mi się podoba.
> (niech Cię nie myli @, to zupełnie co innego ;)).
Tak, to już zdążyłem wyczaić.
>
>> Poza tym mozliwosc opuszczania nawiasow przy wywolaniu funkcji dobija
>> mnie maksymalnie.
>
> Kwestia przyzwyczajenia. W Rubym gdy masz obiekt.cos to 'cos' zawsze
> jest metodą (atrybuty nie są widoczne z zewnątrz tak jak w
> Pythonie).
To trochę tak jakby Python zmuszał nas do używania wszędzie properties'ów
zamiast zwykłych atrybutów. To trochę wylanie dziecka z kąpielą imho.
> Niejednoznaczność jest tylko wtedy jak nie podajesz
> domyślnego odbiorcy (self), co może zostać pomylone ze zmienną
> lokalną. Jednakże to nie powinien być problem, jeśli tylko utrzymuje
> się małą liczbę zmiennych lokalnych (co w językach dynamicznych jest
> musem by kod był czytelny i łatwy w refaktoryzacji).
OK, ale czy naprawdę informacja o tym, czy mamy do czynienia ze
zwykłym atrybutem, a nie metodą nie poprawia przejrzystości?
W moim przykładzie ten "leszcz" raz używa `gets` z nawiasami,
raz bez i nie wiadomo czy to tylko akcesor, czy jakaś
konkretna metoda (abstrahuję od tego, że w tym przypadku wiadomo
co to jest). Z tego co zdążyłem zaobserwować taki kod w Ruby
nie należy do rzadkości.
RW
Radosław Bułat
> Radosław Bułat" <rada...@poczta.fm> wrote:
>
>>> Co do Rubiego
>>> Znielubialem go z dwoch powodow.
>> Moje wtrącenie nie miało wywołać dyskusji dlaczego lubimy język X bardziej
>> niż Y.
>
> Powinienem napisac "znielubialem"
>
> Identycznie jak u Roba Wolfa moje "znielubienie" mialo
> wylacznie podloze merytoryczne/techniczne, a nie emocjonalna.
>
> Wlasnie po to przygladalem sie Ruby-emu aby na niego przejsc
> (pelne OO np.) ale.. zrezygnowalem jednak.
> Swiadomie i merytorycznie podjalem decyzje pozostania
> przy Pythonie (co skutkowalo zakupem domen python.pl
> i python.org.pl:)
Wcale się nie dziwię. Jeśli już się coś polubiło i w jakiś sposób
wpasowuje się to w nasze myślenie to po co zmieniać? Do wielu rzeczy po
prostu się przyzwyczajamy (tak jak ";" na końcu linii, () w wywołaniu
metody itp) i potem na wszystko inne mówimy że nam się nie podoba:).
>
>> Jeśli chodzi o samą składnię to Ruby ma zdecydowanie więcej znaków
>> interpunkcyjnych niż Python ((), &, =>, @, $ itp), których jednak
>> prawidłowe użycie zwiększa czytelność (spróbuj przeczytać książkę, która
>> nie ma żadnego przecinka, kropki, wykrzyknika).
>
> Jest _dokladnie_ odwrotnie.
> Jezyk usiany 'interpunkcjami' nie jest czytelny.
> Kazdy - nie tylko Ruby
Nie zgodzę się. Przesada interpunkcji - tak, jej brak - tak samo. Nawet
piszą używasz przecinków, kropek (nawiasów), dwukropków, pytajników,
wykrzykników i innych znaków. Jednak ich brak lub zbyt duża ilość albo
zaciemniają znaczenie ("czesc, pisales cos" - napisał kolega, zapytał
czy stwierdził?) albo czynią tekst bezsensowny ("ala ( ma ))) - !
kota)"). Przykładem takich znaków z Rubiego są ! oraz ? (można dodać do
nazwy metody).
>
> Dobry (w sensie synktatyki) to taki jezyk
> ktorego sie nie zna, a rozumie, a nie taki ktorego
> sie rozumie dopiero po glebszym poznaniu.
>
> Jak to powiedziel moj Kolega muzyk-amator
> "Nie sztuka zagrac na czyms na czym sie umie -
> to kazdy palant potfafi :)
> sztuka zagrac pieknie ne czyms na czym sie nie umie !"
Niestety takie coś to tylko w erze :). Przepraszam, ale programowanie to
nie sztuka, którą można się nauczyć w dzień, tydzień czy miesiąc (z
muzyką jest podobnie więc nie wiem skąd takie stwierdzenie). Zatem nie
łudźmy się, że jak się za bardzo nie zna danego języka to się go będzie
rozumieć. Pewne elementy zapewne tak ("oo, tu jest pętla"), ale raczej
samemu się w tym sprawnie pisać nie będzie.
>> Dodam jeszcze, że jak w każdym języku w Rubym też można
>> pisać brzydki kod.
>
> To prawda (no sa wyjatki np Algol :)),
> ale chodzi o latwosc tego czynu, a i przyjete
> powszechnie 'idiomy'.
> IMHO w Rubym o wiele latwiej niz w Py o zagmatwanie.
Zgadza się, ale również łatwiej pisze się kod ładniejszy :) (chociaż dla
Ciebie zapewne najładniejszy i tak jest kod Pythona).
>> Nie wiem co to za dyskusja była (mógłbyś podać linka?).
>
> Top bylo dobre 8 lat temu chyba ale..
> sprobuje znalesc w archiwach.
Oj, to jakaś stara sprawa :).
>
>> Ostatnio robiłem prezentację o Rubym i tam także nie widziałem powodów by
>> nie napisać, że Python był jednym ze wzorów dla Matza
>
> To oczywiste ze sie wzorowal i bardzo ladnie ze to napisales.
> Tyle tylko ze _sam Matz_ tego nie przyznal gdy tworzyl Rubyego
Na prawdę ciężko mi w to uwierzyć. Sam Matz lubi Pythona i z niczym się
nie ukrywa:). http://flickr.com/photos/john_lam/1910968816/ .
Zaskoczony?:) Zdjęcie robione na rubyconf 2007.
>
>> A co do samych zapożyczeń. Nie widzę żadnego problemu z tym. Po pierwsze
>> żaden z elementów nie został na ślepo wzięty z Python i wstawiony do
>> Rubiego. A także takie elementy jak obiektowość, metaklasy, domknięcia itp
>> itd nie są unikalne dla Pythona, więc nie wiem w czym problem. Sam Guido
>> nie ukrywa, że sam wzorował się na innych językach.
>
> No wiesz.. wzorowac a zrobic w 80% koie to jednak roznica
A zaraz perlowcy powiedzą że 80% to też z Perla :). Nie przesadzajmy z
tymi 80%. Obiektowość jest dosyć podobna (ale są i tak spore różnice), a
to akurat jest podobne w wielu językach.
Gdyby Ruby był w 80% Pythonem to ... nie mówilibyście że to Perl ;-).
> Guido zawsze przyznawal ze generatory wzial z Icona
> for in z Ady (chyba?) itp
>
> To nie chodzi o zabronienie bazowania :
> Ba ! Uwazam ze idiotyzmem jest (poza
> nielicznymi wyjatkami vide Prolog) pisanie
> jezyka od 0 (mowie o mechanizmach a nie skladni).
> Nikt tez nie zarzucal Rubyemui _ze_ powstaje
> Wprost przeciwnie.
> Chodzilo tylko o nieco wiecej kultury dla swego "Ojca" :)
Za bardzo Wam się wydaje że Ruby to kopia Pythona :). Nawet na wiki
wymienionych jest z 5 języków, z których czerpał Matz. Więc Python jest
conajwyżej jednym z ojców ;-).
> Co do tego ze nie na slepo - zgadzam sie.
> To nie byla kopia dla kopii, ale chec stworzenia czegos
> lepszego.
>
>> Hm, ja to odniosłem to kwestii JRuby <=> Jython. Jakoś zapał panom od
>> Jythona spadła,
>
> Przyczyna 'braku zapalu' byla i jest prozaiczna
> Sun 'olal' zwyczajnei Jythona a Hugunin (tworca Jythona
> i wieloletni mainteiner) zostal kupiony przez MS kilka lat
> temu wlacznei z raczkujacym wtedy IronPythonem
> Sun sie ocknal neidawno
> Ruby tu nie ma _nic_ do rzeczy
> Jythona nieco uzywalem (i uzywam) gdy o Ruby
> nikt nie slyszal
>
>> dopiero sukces JRubiego (jako sukces mam na myśli zainteresowanie Suna,
>> integracja z netbeans, a także jakość samego interpretera) spowodował że
>> coś się ruszyło na nowo :).
>
> j/w
>
>> Sam Ruby zawdzięcza tyle Pythonowi na ile pozwoliło to Matzowi wziąć to co
>> w nim lubił i dać (pod taką czy inną postacią) do Rubiego. Jakby nie było
>> Ruby idzie własną ścieżką, Python własną.
>
> Tyle ze 80% Rubiego to kopia Pythona
> Nalezalo to przyznac u uszanowac.
> I tylko o ta szczypte elementarnej kultury chodzilo
Patrz wyżej.
>
>> Disclaimer: jeśli uważasz wypowiedzi tego typu za flame to sorry.
>
> Alez skad.
>
>> Dla mnie to zwykła dyskusja (póki nie padają jakieś głupie teksty oraz
>> przekomarzanie się "w twoim języku to głupie jest to i to").
>
> Dla mnnie tez
> Dyskusja rozni sie od flame tym ze sa argumenty
> Na razie sa.
>
> AK
>
>
Radosław Bułat
> Adam Karpierz <karp...@noooospaaaampython.pl> wrote:
>
>>> Ostatnio robiłem prezentację o Rubym i tam także nie widziałem powodów by
>>> nie napisać, że Python był jednym ze wzorów dla Matza
>> To oczywiste ze sie wzorowal i bardzo ladnie ze to napisales.
>> Tyle tylko ze _sam Matz_ tego nie przyznal gdy tworzyl Rubyego
>
> Dokładnie. Ukrył ten fakt w bardzo przebiegły sposób, pisząc
> w przedmowie do pierwszego wydania "Pickaxe Book", że najpierw
> zapoznał się z Perlem i Rubym a potem zapragnął stworzyć coś,
> co będzie potężniejsze niż ten pierwszy i bardziej obiektowe
> niż ten drugi.
> Przecież wiemy, że nikt nie czyta przedmów i
> w ten sposób Matz przekonał autorów książki, że nie muszą co
> drugi rozdział wstawiać zastrzeżeń "a to wzięto z Pythona",
> "a tamto wzięto z Pythona", "a ideę zapisywania kodu programu
> za pomocą znaków z zakresu ASCII wzorowano na...".
>
No proszę Cię :). Czyli sugerujesz że Python to jakiś święty język i
autorzy książki Pickaxe powinni na każdym kroku pisać mniej więcej tak:
"Oto tablica, a = [1, 2, 3], zostało to zapożyczone od Pythona"?
Bardziej śmiesznego argumentu nie słyszałem ostatnio :).
Sulsa
Radosław Bułat <rada...@poczta.fm> wrote:
> Nie zgodzę się. Przesada interpunkcji - tak, jej brak - tak samo. Nawet
> piszą używasz przecinków, kropek (nawiasów), dwukropków, pytajników,
> wykrzykników i innych znaków. Jednak ich brak lub zbyt duża ilość albo
> zaciemniają znaczenie ("czesc, pisales cos" - napisał kolega, zapytał
> czy stwierdził?) albo czynią tekst bezsensowny ("ala ( ma ))) - !
> kota)"). Przykładem takich znaków z Rubiego są ! oraz ? (można dodać do
> nazwy metody).
Interpunkcja w języku polskim(angielskim, rozyjskim, itp) to cos
zupelnie innego niz interpunkcja w jezyku programowania. Rownie dobrze
mozesz porównywać znaki drogowe i obrazy picasso, a na koniec
stwierdzic ze picasso robil straszne te obrazy bo jakby zrobic z nich
znaki drogowe to kierowca w pore by nie skapowal co tam "jest napisane".
Jaroslaw Zabiello
> No wybacz, ale `chop` jest aż do bólu perlowy (nie wiem, czy gdzieś
No to użyj line.strip! zamiast line.chop! Dodatkowy znak ! jest akurat
przewagą Rubiego bo pokazuje, że metoda zmienia obiekt w miejscu. Jak
bardzo jest to nieelegancko w Pythonie widać o metodzie sort() która
zmienia obiektu w miejscu ale zwraca debilną wartość None. Z kolei,
poźniej chyba dodali aby to jakoś wyrównać, funkcja sorted() nie jest
wykonywana jako metoda obiektu i nic nie zmienia w obiekcie.
> OK, ale czy naprawdę informacja o tym, czy mamy do czynienia ze
> zwykłym atrybutem, a nie metodą nie poprawia przejrzystości?
Tak może mowić tylko ktoś kto nie zna w ogóle Rubiego. W Ruby wszystkie
atrybuty klasy są prywatne i nie ma do nich bezpośredniego dostępu tak jak
w Pythonie, PHP czy Javie. Wszystkie atrybuty są w Rubim dostępne
zewnętrznie tylko i wyłącznie za pomocą akcesorów. Jest to więc spójne i
jakiekolwiek nawiasy by tu nic nie zmieniły.
> W moim przykładzie ten "leszcz" raz używa `gets` z nawiasami,
> raz bez i nie wiadomo czy to tylko akcesor, czy jakaś
> konkretna metoda
W Ruby nie ma to znaczenia. Wszystko jest metodą. A to czy opakowuje ona
dostęp do jakiegoś atrybutu, czy robi coś więcej, to już zupełnie inny
temat. Ruby nie potrzebuje takiego sztucznego podziały na dwa rodzaje
metod, bo w praktyce jest to podział sztuczny i ograniczający to co można
zaimplementować w tych metodach.
--
Jarosław Zabiełło
http://blog.zabiello.com
Jaroslaw Zabiello
> Lubię przejrzystość, a ani Ruby ani Perl przejrzyste *DLA MNIE* nie są,
> choć próbowałem się ich nauczyć.
To nie tak. Ruby ma większy potencjał niż sądzisz. Trochę długo pisałem w
Pythonie i muszę przyznać, że w Rubim kod jest po prostu piękniejszy. Do
tego stopnia, że poprzepisywałem trochę wcześniejszych skryptów shellowych
z Pythona do Ruby. Widziałeś może RSpec w akcji? To biblioteka do
Behaviour Driven Development (nowsza metodologia od starej TDD używanej
powszechnie w kręgach Pythona). Ostatnio dodane Rspec Stories pokazują
piękno i potęgę Rubiego:
http://www.tomtenthij.co.uk/2008/1/25/rspec-plain-text-story-runner-on-a-fresh-rails-app
--
Jarosław Zabiełło
http://blog.zabiello.com
irc://irc.eu.freenode.net/ruby.pl
irc://irc.eu.freenode.net/python.pl
Jaroslaw Zabiello
<karpierz@_NOSPAM_python.pl> wrote:
> 2. Pomimo ze powstal lata temu _wybitnie_ na bazie Pythona,
Guzik prawda. Ruby ma dużo więcej ze Smalltalka niż Pythona. Od słów
kluczowych po symbole, sposób tworzenia instancji klas, bloki kodu (ang.
closures), kontynuacje itp. Jak ktoś jeszcze nie rozumie filozofii
Rubiego, jego modelu obiektowego i powodu istnienia otwartych klas,
powinien poczytać sobie trochę o Smalltalku.
http://blog.zabiello.com/articles/2006/05/14/dlaczego-ruby-on-rails-jest-wyj%C4%85tkowy
Radosław Bułat
> Radosław Bułat <rada...@poczta.fm> writes:
>
>>> Nie wiem na ile ta funkcja jest reprezentatywna dla Rubiego, ale
>>> jesli
>>> jest,
>>> to dla mnie podobienstwo do Perla jest uderzajace.
>> Uderzająca jest bo:
>> - pisał ją jakiś leszcz (przepraszam ale nie mogłem się powstrzymać,
>
> Bałem się, że to powiesz. ;)
>
>> obsługa parametru, który może być zarówno obiektem pliku jak i nazwą
>> to przesada, stąd te opened = true i sprawdzanie w ensure)
>> - defined? - nie ma sensownego powodu by go używać
>> - pierwszy raz widzę użycie /regexp/=~"string" (w tej kolejności),
>> skąd Ty ten kod wziąłeś?;)
>
> Wprost z biblioteki standardowej Ruby'iego.
> ruby-1.8.6-p111/lib/mailread.rb
> Hmmm...leszcz mówisz... :)
Tak, tylko zobacz sobie kiedy to było pisane. Wtedy jeszcze Perlizmy
były powszechnie używane. Daję głowę że dzisiaj nie zostałoby to tak
napisane. Poza tym pokazujesz jakiś jeden kawałek kodu (dalej
podtrzymuję że brzydki). W Pythonie pewnie też znajdziesz (na swój
sposób) nieczytelnego, nie zrozumiałego. Wystarczy przesadzić z metodami
__xxx__ (notabene nie lubię tego :)) i efekt będzie podobny.
Ale to tylko nazwa metody. A słowo kluczowe "class" jest bardziej
Pythonowe czy Javowe?
> W każdym razie Twoja wersja duuużo bardziej mi się podoba.
>
>> (niech Cię nie myli @, to zupełnie co innego ;)).
>
> Tak, to już zdążyłem wyczaić.
>
>>> Poza tym mozliwosc opuszczania nawiasow przy wywolaniu funkcji dobija
>>> mnie maksymalnie.
>> Kwestia przyzwyczajenia. W Rubym gdy masz obiekt.cos to 'cos' zawsze
>> jest metodą (atrybuty nie są widoczne z zewnątrz tak jak w
>> Pythonie).
>
> To trochę tak jakby Python zmuszał nas do używania wszędzie properties'ów
> zamiast zwykłych atrybutów. To trochę wylanie dziecka z kąpielą imho.
Nie ma czegoś takiego stricte jak akcesor i metoda. Jest tylko metoda.
Metoda, która zwraca wartość atrybutu potocznie zwana jest akcesorem.
Jak się coś krytykuje to trzeba wiedzieć jak działa :).
>> Niejednoznaczność jest tylko wtedy jak nie podajesz
>> domyślnego odbiorcy (self), co może zostać pomylone ze zmienną
>> lokalną. Jednakże to nie powinien być problem, jeśli tylko utrzymuje
>> się małą liczbę zmiennych lokalnych (co w językach dynamicznych jest
>> musem by kod był czytelny i łatwy w refaktoryzacji).
>
> OK, ale czy naprawdę informacja o tym, czy mamy do czynienia ze
> zwykłym atrybutem, a nie metodą nie poprawia przejrzystości?
Patrz wyżej.
> W moim przykładzie ten "leszcz" raz używa `gets` z nawiasami,
> raz bez i nie wiadomo czy to tylko akcesor, czy jakaś
> konkretna metoda (abstrahuję od tego, że w tym przypadku wiadomo
> co to jest). Z tego co zdążyłem zaobserwować taki kod w Ruby
> nie należy do rzadkości.
Bo za pierwszy razem sprawdzany jest fakt, czy jest obiekt ma metodę
gets (define? f.gets, co jest okropne, ale dzisiaj zostałoby to na bank
napisane jako if f.respond_to?(:gets), być może jak było to pisane nie
było tego w rubym, dlatego tym bardziej pokazywanie takich kawałków kodu
jest bez sensu). Zwykle wywołanie metody bez argumentów jest bez ().
>
> RW
Piotr Meyer
> Oczywiście chodziło Ci o "Perl i Pythonem"?
A tak, oczywiście. Przepraszam, pisałem będąc już jedną nogą
za drzwiami i nie upilnowałem.
> Bardziej śmiesznego argumentu nie słyszałem ostatnio :).
A nie czujesz, że coś Cię w zadnią część ciała podgryza?
--
Piotr 'aniou' Meyer
Jaroslaw Zabiello
>>> nie napisać, że Python był jednym ze wzorów dla Matza
>>
>> To oczywiste ze sie wzorowal i bardzo ladnie ze to napisales.
>> Tyle tylko ze _sam Matz_ tego nie przyznal gdy tworzyl Rubyego
>
> Dokładnie. Ukrył ten fakt w bardzo przebiegły sposób, pisząc
> w przedmowie do pierwszego wydania "Pickaxe Book", że najpierw
> zapoznał się z Perlem i Rubym a potem zapragnął stworzyć coś,
> co będzie potężniejsze niż ten pierwszy i bardziej obiektowe
> niż ten drugi.
Wtedy kiedy powstawał Ruby faktycznie Python miał "taką sobie"
obiektowość. To zostało dopiero potem poprawione.
Nie rozumiem dlaczego co niektórzy czepiają się Matza o to że nie trąbi
jak to zapożyczał z Pythona, skoro on też się nie chwali że zapożyczał ze
Smalltalka a na pewno więcej w Rubim jest ze Smalltalka niż z Pythona.
Matz się inspirował różnymi źródłami, z Lispem włącznie.
Ruby jest jaki jest, jeszcze Python jest w wielu dziedzinach dojrzalszy,
ale moim zdaniem Ruby jest pięknieszy i rozwija się szybciej. Taki JRuby
to też już poważna sprawa. Najnowsza wersja JRuby bije w wielu testach nie
tylko CRuby 1.9, ale także Pythona 2.5, a to jeszcze nie koniec tego co
może być osiągnięte.
Zaimplementowana w JRuby i CRuby 1.9 Oniguruma jest dużo bardziej
zaawansowaną biblioteką do wyrażeń regularnych niż to jest w Pythonie.
Sequel ORM podciął w moich oczach przewagę SQLAlchemy (która dużo traci na
swej mętnej, zbliżonej filozoficznie do Perla - składni). A uniwersalny
Merb podcina zalety Pylonsa. Ruby ma już odpowiednik WSGI - Rack. Zaś
RSpec + RCov i AutoTest wprowadzają testowanie aplikacji na dużo wyższy
poziom abstrakcji niż to co oferuję Unit Testy czy Nose w Pylons, Django.
Myślę, że dużo wniesie też Rubinius (jest inspirowany prostotą maszyny
wirtualnej Smalltalka). Powinien ogromnie przyśpieszyć dalszy rozwój
języka (nie tylko Ruby, też JRuby, bo tam myślą o odpowiedniku Jubinius i
już teraz mogą po prostu skopiować z Rubiniusa całą bibliotekę standardową
ktora jest już przepisana w Ruby)
Adam Byrtek
> W Ruby nie ma to znaczenia. Wszystko jest metodą. A to czy opakowuje ona
> dostęp do jakiegoś atrybutu, czy robi coś więcej, to już zupełnie inny
> temat. Ruby nie potrzebuje takiego sztucznego podziały na dwa rodzaje
> metod, bo w praktyce jest to podział sztuczny i ograniczający to co
> można zaimplementować w tych metodach.
W Rubym łatwiej wyobrazić to sobie jako wysyłanie wiadomości do obiektu,
który jest odpowiedzialny za jej obsłużenie. W Pythonie za to w zasadzie
"dobieramy się" bezpośrednio do elementu słownika danego obiektu.
Więcej o problemach z akcesorami tutaj:
http://www.adambyrtek.net/2008/02/09/trivial-accessors-and-uniform-access/
Nie powiedziałbym, że któryś z modeli jest zdecydowanie lepszy. Ruby
trochę lepiej zachowuje enkapsulację, ale z drugiej strony (szczególnie
w świecie Rails) powszechne i proste jest jej obchodzenie.
Pozdrawiam,
Adam
--
Adam Byrtek | Alpha
http://www.adambyrtek.net
Rafał Zawadzki
> Rob Wolfe pisze:
>> Radosław Bułat <rada...@poczta.fm> writes:
>>
>>>> Nie wiem na ile ta funkcja jest reprezentatywna dla Rubiego, ale
>>>> jesli
>>>> jest,
>>>> to dla mnie podobienstwo do Perla jest uderzajace.
>>> Uderzająca jest bo:
>>> - pisał ją jakiś leszcz (przepraszam ale nie mogłem się powstrzymać,
>>
>> Bałem się, że to powiesz. ;)
>>
>>> obsługa parametru, który może być zarówno obiektem pliku jak i nazwą
>>> to przesada, stąd te opened = true i sprawdzanie w ensure)
>>> - defined? - nie ma sensownego powodu by go używać
>>> - pierwszy raz widzę użycie /regexp/=~"string" (w tej kolejności),
>>> skąd Ty ten kod wziąłeś?;)
>>
>> Wprost z biblioteki standardowej Ruby'iego.
>> ruby-1.8.6-p111/lib/mailread.rb
>> Hmmm...leszcz mówisz... :)
>
> Tak, tylko zobacz sobie kiedy to było pisane. Wtedy jeszcze Perlizmy
> były powszechnie używane. Daję głowę że dzisiaj nie zostałoby to tak
> napisane. Poza tym pokazujesz jakiś jeden kawałek kodu (dalej
> podtrzymuję że brzydki). W Pythonie pewnie też znajdziesz (na swój
> sposób) nieczytelnego, nie zrozumiałego. Wystarczy przesadzić z metodami
> __xxx__ (notabene nie lubię tego :)) i efekt będzie podobny.
Radku - piszesz, że moje słowa były niesprawiedliwe dla "JRuby".
Natomiast Ty jedziesz na maksa po bandzie z hasłem "ruby został napisany
przez leszcza" - oczywiście nie napisałeś tego wprost tylko dałeś się
zwabić w *wyjątkową* przewrotną pułapkę.
Pozdrawiam gorąco i jeśli ktokolwiek poczuł się urażony, iż obraziłem
jego język programowania pseplasam ;)
Acha - jak mi ktoś mówi, że python to gówniany język to czasem przyznaję
mu rację, czasem nie :)
Nie warto toczyć krwi ;)
Adam Karpierz
> Wcale się nie dziwię. Jeśli już się coś polubiło i w jakiś sposób
> wpasowuje się to w nasze myślenie to po co zmieniać?
Nie. Chetnie bym zmienil.
Dopiero Python3000 mi bardziej odpowiada
(a i to nie do konca).
Nie jestem przywiazany do Pythona jako takiego
ale do Pythonowego podejscia jak najbardziej.
Nie ograniczylem sie do sledzenai co sie dzieje
do Rybyego. "Bawilem" sie Groovym (bardziej strong typing)
To _nie byla_ kwestia przyzwyczajenia.
> Do wielu rzeczy po prostu się przyzwyczajamy (tak jak ";" na końcu linii,
> () w wywołaniu metody itp) i potem na wszystko inne mówimy że nam się nie
> podoba:).
Nie.
Nigdy nie podobalo mi sie apply() np.
Nigdy nie spodoba mi sie print >>,
Nigdy sie nie pogodze z:
a = x if z else y
Nie zapominaj ze ja jestem starym Algolowcem
gdzie bylo naturalne
a := if z then x else y;
(Skladalem propozycje
a = if z: x else: y - przepadla z jakichs parsopodobnych
wzgledow)
Do dzisiaj z drobiazgow wprost brazni mnie:
def metoda(self, ...):
zamiast :
def self.metoda(...)
Natomiast nie proboj mnie przekonac
do @attr czy nawet attr zamiast self.attr :)
Nie proboj mnie tez przekonac do
obj.metoda zamiast obj.metoda()
W Algolu/Simuli wlasnie bylo procedura czy obj.metoda
i nigdy mi sie to nie podobalo
> Przykładem takich znaków z Rubiego są ! oraz ? (można dodać do nazwy
> metody).
Pytam _po co_ ?
Wlasnie one sie rzucaja w oczy i powoduja konfuzje.
Nie przekonasz mnie do interpuncji i juz.
Za duzo widzialem jezykow 'interpunkcyjnych'
i za duzo sie przez nie nacierpialem.
Pytam wie po co te ? po co te !
po co te | x | ? w Rybym
Po co te @ jesli Ruby nei posiada
innych atrybutow poza prywatnymi ?
> Niestety takie coś to tylko w erze :). Przepraszam, ale programowanie to
> nie sztuka, którą można się nauczyć w dzień, tydzień czy miesiąc (z muzyką
> jest podobnie więc nie wiem skąd takie stwierdzenie). Zatem nie łudźmy
> się, że jak się za bardzo nie zna danego języka to się go będzie rozumieć.
> Pewne elementy zapewne tak ("oo, tu jest pętla"), ale raczej samemu się w
> tym sprawnie pisać nie będzie.
Nauczyc nie, aleprogram _zrozumiec_ tak..
W Pythonie rozumiem program od razu
W Algolu tez.
W Prologu (jesli znam 'logike' Prologu) tez
Neistey w Rubym mniej, w Perlu
wiedomo w Tcl ? Roznie - ale lagodnie mowiac
nie przepadam
>> IMHO w Rubym o wiele latwiej niz w Py o zagmatwanie.
>
> Zgadza się, ale również łatwiej pisze się kod ładniejszy :)
Jesli jezyk zezwala, ludfzie maja 100% tendencje do gmatwania
i pisania brzydko.
> (chociaż dla Ciebie zapewne najładniejszy i tak jest kod Pythona).
Co to znaczy ladniejszy ?
Jest latwiej zrozumialy.
> Oj, to jakaś stara sprawa :).
Pelne poczatki Rubyego.
> Gdyby Ruby był w 80% Pythonem to ... nie mówilibyście że to Perl ;-).
Nie. te wlasnie inne 20% to w duzj mieze Perlis-tosc
> Za bardzo Wam się wydaje że Ruby to kopia Pythona :).
Dobra powiem wprost bo wtedy zylem i sledzilem
powstawanie Ruby-ego
To byla i jest kopia Pythona.
Nie ma w Rubym zadnej nowej filozoffi
jest tylko wyczyszczenie paradygmatu OO
a reszta to zbedne zabawy skladniowe.
> Nawet na wiki wymienionych jest z 5 języków, z których czerpał Matz. Więc
> Python jest conajwyżej jednym z ojców ;-).
Ojciec jest zawsze jeden.
Inni to tylko dotkneli.
AK
Adam Karpierz
> oczywiście nie napisałeś tego wprost tylko dałeś się zwabić w *wyjątkową*
> przewrotną pułapkę.
;))
AK
Jaroslaw Zabiello
<karpierz@_NOSPAM_python.pl> wrote:
> Dobra powiem wprost bo wtedy zylem i sledzilem
> powstawanie Ruby-ego
> To byla i jest kopia Pythona.
Bullshit. Nie żebym miał coś przeciwko Pythonowi, ale Ruby jest duuużo
bardziej wzorowany na Smalltalku niż Pythonie (vide:
http://c2.com/cgi/wiki?RubyInsteadOfSmalltalk). Ruby ma zupełnie inny od
Pythona model obiektowy i użycie modułów. Ma też inną filozofię, często
zupełnie przeciwną Pythonowi. Np. jest bardziej "magiczny", co jest wbrew
pythonowej zasadzie "explicite is better than implicite". Ma bardzo wiele
metod, nawet w kilku nazwach (aliasy) co zaprzecza Pythonowej zasadzie o
tym, że powinna istnieć jedna droga do celu (nawiasem mówiąc, pythonowy
ORM - SQLAlchemy - też jest przeciwny tej zasadzie). Ruby ma smalltalkowe
otwarte klasy, też wbrew Pythonowym niemodyfikowalnym typom prostym (str,
int, float). Ruby jest w pełni OO, czego nie można powiedzieć o Pythonie
(który jest częściowo obiektowy, częściowo funkcyjny). Ruby ma inspirowane
składnią Smalltalka symbole, closures, kontynuacje, nawet sposób tworzenia
klas za pomocą Klasa.new. Ruby ma też zupełnie inny, bardziej wyrafinowany
od Pythona poziom bezpieczeństwa kodu (metody prywatne, protected i
publiczne, możliwość zamrażania dowolnych obiektów, możliwość ustawienia
poziomu bezpieczeństwa wyłączającego niektóre niebezpieczne funkcje języka
itp., vide
http://blog.zabiello.com/articles/2006/03/10/mechanizmy-bezpiecze%C5%84stwa-w-ruby)
Radosław Bułat
> Radku - piszesz, że moje słowa były niesprawiedliwe dla "JRuby".
> Natomiast Ty jedziesz na maksa po bandzie z hasłem "ruby został napisany
> przez leszcza" - oczywiście nie napisałeś tego wprost tylko dałeś się
> zwabić w *wyjątkową* przewrotną pułapkę.
Mój błąd, że nazwałem tak osobę, która napisała ten kod. Ale co do kodu
zdania nie zmienię, jest słaby, ale był pisany jeszcze za czasów gdy
perlizmy to było coś normalnego w Rubym. Żart mu wyszedł, ale czy jakiś
wniosek z tego mamy wyciągnąć? Rozumiem, że my wszyscy po kolei umiemy
zaprojektować i napisać język programowania tak jak umiał Matz?;]
> Pozdrawiam gorąco i jeśli ktokolwiek poczuł się urażony, iż obraziłem
> jego język programowania pseplasam ;)
> Acha - jak mi ktoś mówi, że python to gówniany język to czasem przyznaję
> mu rację, czasem nie :)
Ja tam nic do pythona nie mam, ani jednego złego zdania w tej dyskusji
na niego nie napisałem. Czemu? Bo wiem, że jest ok, ale akurat mnie nie
pasuje _tak jak_ Ruby i tyle.
>
> Nie warto toczyć krwi ;)
>
--
Radosław Bułat
Żeby podkreślić semantykę metody. Tylko i aż tyle.
> po co te | x | ? w Rybym
Widzisz, coś tam sobie ubzdurałeś i tak będziesz to powtarzał :).
|x| to parametryzacja bloku, który jak wiemy jest "dokładany" do
wywołania metody. Jak inaczej wyobrażasz sobie pokazanie, że blok ma
parametr? Jakiś inny pomysł?
> Po co te @ jesli Ruby nei posiada
> innych atrybutow poza prywatnymi ?
Po to, że w klasie możesz odwołać się poprzez @ do atrybutu (z zewnątrz
poprzez metodę dostępową). $ (zmienne globalne) i @ (zmienne
instancyjne) mają ogromny sens. W Pythonie też przecież musicie je
odróżniać (stąd konstrukcja global, a atrybuty nie pomylą się ze
zmiennymi lokalnymi bo używa się przez self.atrr).
>
>> Niestety takie coś to tylko w erze :). Przepraszam, ale programowanie to
>> nie sztuka, którą można się nauczyć w dzień, tydzień czy miesiąc (z muzyką
>> jest podobnie więc nie wiem skąd takie stwierdzenie). Zatem nie łudźmy
>> się, że jak się za bardzo nie zna danego języka to się go będzie rozumieć.
>> Pewne elementy zapewne tak ("oo, tu jest pętla"), ale raczej samemu się w
>> tym sprawnie pisać nie będzie.
>
> Nauczyc nie, aleprogram _zrozumiec_ tak..
> W Pythonie rozumiem program od razu
> W Algolu tez.
> W Prologu (jesli znam 'logike' Prologu) tez
> Neistey w Rubym mniej, w Perlu
> wiedomo w Tcl ? Roznie - ale lagodnie mowiac
> nie przepadam
Widać nie widziałeś porządnie napisanej aplikacji np w rails. Dobrze
napisany model jest samoopisujący się. Nie dość że wiadomo o co chodzi
to często widać _logikę biznesową_ gołym okiem. W dużje mierze to po
prostu DSL.
>
>>> IMHO w Rubym o wiele latwiej niz w Py o zagmatwanie.
>> Zgadza się, ale również łatwiej pisze się kod ładniejszy :)
>
> Jesli jezyk zezwala, ludfzie maja 100% tendencje do gmatwania
> i pisania brzydko.
Czyli w javie (która składniowo jest bardzo prosta) pisze się najlepsze
(czytelność) programy?;) Każdy programuje tak jak umie. Język
diametralnie tego nie zmieni ani w jedną ani w drugą stronę.
>
>> (chociaż dla Ciebie zapewne najładniejszy i tak jest kod Pythona).
>
> Co to znaczy ladniejszy ?
Przeciwieństwo brzydkiego (chyba umiesz poznać taki kod?).
Np ładny (co zawsze jest oczywiście subiektywnym odczuciem):
<code>
context Stack do
it "should be empty after create" do
@stack = Stack.new
@stack.should be_empty
end
end
#albo
class User < ActiveRecord::Base
has_many :projects
belongs_to :user_group
validates_presence_of :login, :name, :password, :email, :age
validates_uniquenes_of :login
before_create :notify_admin
after_destroy :say_goodbye
end
</code>
> Jest latwiej zrozumialy.
Ładny kod zwykle jest łatwiej zrozumiały.
>
>> Oj, to jakaś stara sprawa :).
>
> Pelne poczatki Rubyego.
>
>> Gdyby Ruby był w 80% Pythonem to ... nie mówilibyście że to Perl ;-).
>
> Nie. te wlasnie inne 20% to w duzj mieze Perlis-tosc
>
>> Za bardzo Wam się wydaje że Ruby to kopia Pythona :).
>
> Dobra powiem wprost bo wtedy zylem i sledzilem
> powstawanie Ruby-ego
> To byla i jest kopia Pythona.
> Nie ma w Rubym zadnej nowej filozoffi
> jest tylko wyczyszczenie paradygmatu OO
> a reszta to zbedne zabawy skladniowe.
Myślisz, że komuś by się chciało pisać nowy język, który jest kopią
innego?:) Pokaż mi tą kopię, bo ja jej nie widzę. Ruby wziął paradygmat
OO z Pythona? Po części tak, ale ten paradygmat nie jest dla Pythona
unikalny. Przed Pythonem już dawno istniał choćby Smalltak, w pełni
obiektowy język.
>
>> Nawet na wiki wymienionych jest z 5 języków, z których czerpał Matz. Więc
>> Python jest conajwyżej jednym z ojców ;-).
>
> Ojciec jest zawsze jeden.
> Inni to tylko dotkneli.
Pythonie, Ty ojcze Rubiego :D. Z jednej strony "Ruby jest bee", z
drugiej "przyznajcie się, Ruby czerpie z Pythona garściami" :).
Jaroslaw Zabiello
wrote:
> Ruby wziął paradygmat OO z Pythona? Po części tak, ale ten paradygmat nie
> jest dla Pythona unikalny.
A ja twierdzę że model obiektowy Rubiego nie ma ani związku ani żadnego
podobieństwo do Pythona. Jest zupełnie inny.
Radosław Bułat
Twórca języka Ruby jest leszczem? Rozumiem, że Wy wszyscy napisali swój
język, potrafią go zaprojektować i zaimplementować? Mogę sobie napisać
cokolwiek, ale nie zmieni to fakt, że Matz to świetny twórca języka.
Adam Karpierz
> Tak, dałem się złapać. I co z tego wynika, bo nie bardzo wiem? Znaczy
> Twórca języka Ruby jest leszczem?
Nooo logika na to wskazuje :)
> Rozumiem, że Wy wszyscy napisali swój język, potrafią go zaprojektować i
> zaimplementować?
Owszem ! ;)
> Mogę sobie napisać cokolwiek, ale nie zmieni to fakt,
> że Matz to świetny twórca języka.
Nie dorasta do piet GvR :)
Gdyby nie Rails to Ruby by nie istnial
AK
Radosław Bułat
> Użytkownik "Radosław Bułat" <rada...@poczta.fm> napisał:
>
>> Tak, dałem się złapać. I co z tego wynika, bo nie bardzo wiem? Znaczy
>> Twórca języka Ruby jest leszczem?
>
> Nooo logika na to wskazuje :)
Co miałeś z logiki? Co najwyżej wynika, że ja nazywając kogoś leszczem
po marnym kawałku kodu jestem debilem. Podtrzymuję, że kod jest słaby,
ale na pewno Matz nie. Człowieku ten kod ma 10 lat, jest z 1998 roku.
Napisany jest tak a nie inaczej i widocznie działa na tyle dobrze, że
nie doczekał się przepisania (jak coś działa to i po co przepisywać?).
>
>> Rozumiem, że Wy wszyscy napisali swój język, potrafią go zaprojektować i
>> zaimplementować?
>
> Owszem ! ;)
Jakieś szczegóły?
>
>> Mogę sobie napisać cokolwiek, ale nie zmieni to fakt,
>> że Matz to świetny twórca języka.
>
> Nie dorasta do piet GvR :)
> Gdyby nie Rails to Ruby by nie istnial
Nie bardzo wiem czy jaja sobie robisz, czy próbujesz się (jako
Pythonista) dowartościować czy co? GvR to jakiś guru oczywiście? Nie
znasz Matza a takie sądy wydajesz.
Ruby bez railsów istniał sobie w Japonii i miał się lepiej od Pythona.
To, że Japończycy słabo władają angielskim miało niebagatelny wpływ na
to, że tak późno Ruby wyszedł poza Japonię. A takie sądy, że Ruby bez
railsów nie istnieje to wydają ludzie, którzy niewiele wiedzą o Rubym.
Ruby to w 80% Python, ze składnią Perla. Tego się dzisiaj od Was
nauczyłem ;). Jeszcze wytłumacz mi co z tą obiektowością zapożyczoną od
Pythona i będzie super. Czekam na pełną analizę.
> AK
Grzegorz Staniak
> Mój błąd, że nazwałem tak osobę, która napisała ten kod. Ale co do kodu
> zdania nie zmienię, jest słaby, ale był pisany jeszcze za czasów gdy
> perlizmy to było coś normalnego w Rubym. Żart mu wyszedł, ale czy jakiś
> wniosek z tego mamy wyciągnąć? Rozumiem, że my wszyscy po kolei umiemy
> zaprojektować i napisać język programowania tak jak umiał Matz?;]
Ja w zasadzie jako ignorant i nawet nie programista powinienem siedzieć
cicho, ale z tym argumentem to się specjalnie nie rozpędzaj - umiejętność
zaprojektowania i napisania języka programowania nie jest niczym specjalnym
wśród absolwentów kierunków informatycznych. Co niektórzy mieli okazję to
zrobić jeszcze w ramach studiów.
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Jaroslaw Zabiello
<karpierz@_NOSPAM_python.pl> wrote:
> Nie dorasta do piet GvR :)
Za to GvR nie dorasta do pięt DHH i jego naśladowcom, jeśli chodzi o
umiejętności promocji technologii. Promocja Pythona zawsze była żałośnie
nieudolna. To środowisko jest chyba jakieś skrzywione na tym punkcie.
Pytałem się kiedyś na kanale #pylons dlaczego nie podniosą wersji Pylons
do 1.0 skoro wg nich od dawna jest stabilny i w zasadzie niewiele się tam
zmienia. Nie chcieli! Ważniejsze było dla nich to "jak uzasadnią" przeskok
z 0.96 do 1.0 developerom rozwijającym ten framework. Promocja frameworka
to niby małe uzasadnienie? Przecież, z psychologicznego pkt. widzenia, to
oczywiste, że większość osób stykających się z Pylonsami po raz pierwszy i
widząc, że projekt jest w dopierow wersji 0.x ma pewne obawy co do
stabilności i dojrzałości tego rozwiązania. I to samo jest z Django. Tak
trudno im to zrozumieć?
Po prostu to towarzystwo skazane jest na niszę na własne życzenie i na
własne życzenie będzie wypierane przez Rubiego i Rails, które prą do
przodu niczym ruski czołg. Także pod względem ilości wydawanych książek to
Ruby w mgnieniu oka pobił to co przez lata wydano dla Pythona. To nie jest
przypadek. To głupota GvR która idzie w dół.
I efekt tego teraz jest, że Ruby i Rails ostro prą do przodu niczym ruski
czołg i łatwo zajmują pozycje, gdzie mógłby wedrzeć się Python, gdyby ktoś
o nim coś więcej wiedział. To nie Python, ale Ruby, Rails (i ostatnio
JRuby) skutecznie docierają do świadomości środowiska enterprise, np.
kręgów Javy. Coraz częściej spotykam osoby które słyszały o "Ruby on
Rails" a nie słyszały nic o Django, Pylons, TurboGears czy nawet Zope
(choć tu jeszcze coś im się o uszy obiło).
> Gdyby nie Rails to Ruby by nie istnial
Rails spowodował prawdziwą eksplozję zainteresowania Rubim, to fakt. Po
prostu, jak o tym pisał Zen Shaw (ten od Mongrela i słynnego wpisu w blogu
pełnego fucków), dopiero Rails uwypuklił to, co jest siłą i atrakcją
Rubiego - łatwość i piękno metaprogramowania i tworzenia DSLi w tym
języku. Rails to przecież jeden wielki DSL w Ruby. Dlatego tak ładnie
wygląda. To samo RSpec. Nie ma szans aby w Pythonie uzyskać takie piękno i
naturalność składni.
Adam Byrtek
> To byla i jest kopia Pythona.
> Nie ma w Rubym zadnej nowej filozoffi
> jest tylko wyczyszczenie paradygmatu OO
> a reszta to zbedne zabawy skladniowe.
Mocno kontrowersyjna teza. Zamiast odpowiadać bezpośrednio, zwrócę uwagę
na ważną konstrukcję, o której nie było jeszcze mowy w tym wątku -
mianowicie na bloki. To potężne narzędzie, powszechnie stosowane w
Rubym. Tutaj z pewnością można mówić o zasadniczo odmiennej filozofii, a
każdy z Was pewnie przyzna, że lambda w Pythonie jest bardzo prymitywna
i nie ma wielu zastosowań (zresztą sam Guido chciał ją usunąć z 3k).
Tę zmianę filozofii widać na przykład w konstrukcjach iterujących:
arr.each {|item| puts item }
w stosunku do:
for item in arr:
print item
W Rubym iteracja jest zadaniem samego obiektu (iterator wewnętrzny),
który wywołuje przekazany do niego blok. W Pythonie przeciwnie, iterator
zwraca kolejne elementy, na których wywoływany jest zewnętrzny blok kodu.
To tylko przykład, bloki pojawiają są wszędzie, można też oczywiście
pisać własne metody przyjmujące bloki, co więcej bloki są domknięciem
(closure). Poznając Ruby'ego to właśnie zastosowanie bloków było dla
mnie jednym z najciekawszych elementów języka.
Radosław Bułat
Myślisz, że gdybym nie wiedział czego uczą (i jak) na studiach
informatycznych to dawałbym takie tezy? Owszem, było coś o
kompilatorach, o automatach itp itd. Ale teoria to jedno, praktyka to
drugie. Zastanów się na jak wielu rzeczach musi znać się taki
potencjalny implementator. Nie umniejszając nikomu raczej przerasta to
dzisiejszych absolwentów informatyki.
Adam Byrtek
> To tylko przykład, bloki pojawiają są wszędzie, można też oczywiście
> pisać własne metody przyjmujące bloki, co więcej bloki są domknięciem
> (closure). Poznając Ruby'ego to właśnie zastosowanie bloków było dla
> mnie jednym z najciekawszych elementów języka.
Uzupełnienie do powyższego posta:
http://martinfowler.com/bliki/CollectionClosureMethod.html
Sulsa
"Jaroslaw Zabiello" <ab...@tpnet.pl> wrote:
Z wszystkim co napisales sie zgodze, oprocz tego:
"dopiero Rails uwypuklił to, co jest siłą i atrakcją
Rubiego - ... *piękno* metaprogramowania i tworzenia DSLi w tym
języku. ... *Dlatego tak ładnie wygląda*. To samo RSpec. Nie ma szans
aby w Pythonie uzyskać takie *piękno i naturalność składni*."
To są argumenty bardzo subiektywne. Mi skłądnia rubiego zupelnie sie
nie podoba, a bloki które ktoś tak bardzo zachwalał wyglądają w
porównaniu ze zwykłą pythonową pętlą(w której zresztą nie znosze
używania iteratora xrange) poprostu brzydko i są dla kogoś kto nie
poznał ich konstrukcji poprostu nie czytelne. Pythona, nie znając tego
języka, czyta się poprostu łatwiej.
--
Jaroslaw Zabiello
> Z wszystkim co napisales sie zgodze, oprocz tego:
> "dopiero Rails uwypuklił to, co jest siłą i atrakcją
> Rubiego - ... *piękno* metaprogramowania i tworzenia DSLi w tym
> języku. ... *Dlatego tak ładnie wygląda*. To samo RSpec. Nie ma szans
> aby w Pythonie uzyskać takie *piękno i naturalność składni*."
>
> To są argumenty bardzo subiektywne. Mi skłądnia rubiego zupelnie sie
> nie podoba,
Składnia Rubiego (czy dowolnie innego języka) będzie *taka jak jej
programista*. Brzydki kod można napisać w każdym języku. Jednak (i to jest
oczywiście moje odczucie) tak pięknego jak w Ruby już nie będzie łatwo
napisać w Pythonie (pomijając fakt, że Python też jest ładny, tego nie
przeczę).
Zobacz jak pisze się kod testujący w Ruby i RSpec (używana jest tu nowsza
metodologia BDD). Tworzysz sobie plik tekstowy ze scenariuszami.
Story: User logging in
As a user
I want to login with my details
So that I can get access to the site
Scenario: User uses wrong password
Given a username 'jdoe'
And a password 'letmein'
When the user logs in with username and password
Then the login form should be shown again
Scenario: Creates a new user
Given a username 'jdoe'
And a password 'letmein'
And an email 'jd...@test.com'
And there is no user with this username
When the user creates an account with username, password and email
Then there should be a user named 'jdoe'
And should redirect to '/'
Potem zamieniasz to na właściwy kod
steps_for(:login) do
Given "a username '$username'" do |username|
@username = username
end
Given "a password '$password'" do |password|
@password = password
end
Given "an email '$email'" do |email|
@email = email
end
Given "there is no user with this username" do
User.find_by_login(@username).should be_nil
end
When "the user logs in with username and password" do
post "/sessions/create", :user => { :login => @username, :password =>
@password }
end
When "the user creates an account with username, password and email" do
post "/users/create", :user => { :login => @username,
:password => @password,
:password_confirmation => @password,
:email => @email }
end
Then "the login form should be shown again" do
response.should render_template("sessions/new")
end
Then "there should be a user named '$username'" do |username|
User.find_by_login(username).should_not be_nil
end
Then "should redirect to '$path'" do |path|
response.should redirect_to(path)
end
end
Albo zobacz jak się definiuje w Railsach relacje między modelami i
porównaj to do tego co ci oferuje SQLAlchemy...
class Firm < ActiveRecord::Base
has_many :clients
has_one :account
belongs_to :conglomorate
# wbudowane walidacje:
validates_presence_of :subdomain, :name, :email_address, :password
validates_uniqueness_of :subdomain
validates_acceptance_of :terms_of_service, :on => :create
validates_confirmation_of :password, :email_address, :on => :create
end
Jak to nie jest piękne i czytelne to chyba mamy zupełnie odmienne poczucie
estetyki :)
> a bloki które ktoś tak bardzo zachwalał wyglądają w
> porównaniu ze zwykłą pythonową pętlą(w której zresztą nie znosze
> używania iteratora xrange) poprostu brzydko
Ruby nie zmusza cię do pisania
items.each do |item|
end
Możesz użyć takiej składni jak ci zależy:
for item in items
end
Tylko że ta pierwsza konstrukcja daje dużo więcej możliwości. Chyba nigdy
nie widziałeś co potrafią robić bloki Rubiego. Np. można do metody sort
przekazać reguły porównania za pomocą bloku. Dużo ładniej niż tworzenie w
Pythonie lambd. Tu akurat podaję b. prosty przykład, ale łatwo sobie
wyobrazić coś bardziej złożonego.
a = [ "d", "a", "e", "c", "b" ]
a.sort {|x,y| y <=> x }
# => ["e", "d", "c", "b", "a"]
Sulsa
"Jaroslaw Zabiello" <ab...@tpnet.pl> wrote:
> Składnia Rubiego (czy dowolnie innego języka) będzie *taka jak jej
> programista*.
Nie, składnia w języku jest ustalona i nic z tym nie zrobisz. Co
najwyzej kod napisany przy użyciu tej składni może być brzydki lub
ładny.
> Brzydki kod można napisać w każdym języku.
Z tym sie chyba kazdy zgodzi.
> Jednak (i to jest
> oczywiście moje odczucie) tak pięknego jak w Ruby już nie będzie łatwo
> napisać w Pythonie (pomijając fakt, że Python też jest ładny, tego nie
> przeczę).
Z tym sie zupelnie nie zgodze. Co gorsza odbieram rubiego jako duplikat
pythona o innej skladni, ktora mi nie odpowiada. Wiec jesli jezyk nie
wnosi nic nowego i ma, w moim odczuciu, gorsza skladnie to nie chce mi
sie poswiecac mu uwagi. Ostatnie zdanie jest oczywiscie bardzo
subiektywne i tu nie ma co dyskutowac bo kazdy moze preferowac inna.
Rzeczywiście bardzo fajne podejscie i bardzo jest to czytelne. Tylko
pozazdrościć i czekś kiedy zaimplementują coś podobnego w pythonie.
> Albo zobacz jak się definiuje w Railsach relacje między modelami i
> porównaj to do tego co ci oferuje SQLAlchemy...
>
> class Firm < ActiveRecord::Base
> has_many :clients
> has_one :account
> belongs_to :conglomorate
> # wbudowane walidacje:
> validates_presence_of :subdomain, :name, :email_address, :password
> validates_uniqueness_of :subdomain
> validates_acceptance_of :terms_of_service, :on => :create
> validates_confirmation_of :password, :email_address, :on => :create
> end
>
> Jak to nie jest piękne i czytelne to chyba mamy zupełnie odmienne poczucie
> estetyki :)
>
Nie znam Railsow i nic mi ten kod nie mowi, moze jest piekny ale dla
mnie bardzo "kryptyczny". Poprzedni kawałek kodu zrozumielem bez
znajomosci RSpec, wiec zupelnie mnie nie przekonales o czytelnosci
ActiveRecord, a wprost przeciwnie.
> Ruby nie zmusza cię do pisania
>
> items.each do |item|
> end
Ale ogrom kodu, który czytalem tego używa i to jest paskudne.
> Tylko że ta pierwsza konstrukcja daje dużo więcej możliwości. Chyba nigdy
> nie widziałeś co potrafią robić bloki Rubiego. Np. można do metody sort
> przekazać reguły porównania za pomocą bloku. Dużo ładniej niż tworzenie w
> Pythonie lambd. Tu akurat podaję b. prosty przykład, ale łatwo sobie
> wyobrazić coś bardziej złożonego.
>
> a = [ "d", "a", "e", "c", "b" ]
> a.sort {|x,y| y <=> x }
> # => ["e", "d", "c", "b", "a"]
>
Pozatym że nie wiem co znaczy operator <=> to rzeczywiście jest to
ładny i czytelny kod. Lambdy w pythonie są zwykle paskudne, kolega ich
używa na potęge -- widac ze bardzo je lubi -- jednak ja jak widze kod
usiany tymi konstrukcjami to juz mam wrazenie nie czytelnosci, chociaz
wiekszosc jego programow czytam bez problemu.
Sulsa
Radosław Bułat <rada...@poczta.fm> wrote:
> To, że Japończycy słabo władają angielskim miało niebagatelny wpływ na
> to, że tak późno Ruby wyszedł poza Japonię.
Ich znajomosc tego jezyka widac w szczegolnosci na anglojezycznych
bugtrackach i forach z feature requestami do roznych programow, gdzie
oni uparcie pisza wszystko swoimi krzaczkami i oczywiscie nigdy nie
doczekuja sie odpowiedzi. Podobno najinteligentniejszy, w sensie testow
na iq, naród swiata, a tak podstawowego jezyka nie moga sie nauczyc.
--
Grzegorz Staniak
>>> Mój błąd, że nazwałem tak osobę, która napisała ten kod. Ale co do kodu
>>> zdania nie zmienię, jest słaby, ale był pisany jeszcze za czasów gdy
>>> perlizmy to było coś normalnego w Rubym. Żart mu wyszedł, ale czy jakiś
>>> wniosek z tego mamy wyciągnąć? Rozumiem, że my wszyscy po kolei umiemy
>>> zaprojektować i napisać język programowania tak jak umiał Matz?;]
>>
>> Ja w zasadzie jako ignorant i nawet nie programista powinienem siedzieć
>> cicho, ale z tym argumentem to się specjalnie nie rozpędzaj - umiejętność
>> zaprojektowania i napisania języka programowania nie jest niczym specjalnym
>> wśród absolwentów kierunków informatycznych. Co niektórzy mieli okazję to
>> zrobić jeszcze w ramach studiów.
>
> Myślisz, że gdybym nie wiedział czego uczą (i jak) na studiach
> informatycznych to dawałbym takie tezy? Owszem, było coś o
> kompilatorach, o automatach itp itd. Ale teoria to jedno, praktyka to
> drugie. Zastanów się na jak wielu rzeczach musi znać się taki
> potencjalny implementator. Nie umniejszając nikomu raczej przerasta to
> dzisiejszych absolwentów informatyki.
Piszesz tak, jakby języki pisali jacyś nadludzcy tytani, wybrańcy bogów,
superherosi i geniusze. O ile Ruby nie jest stricte jednoosobowym
przedsięwzięciem, w co wątpię, to raczej kwestia wytrwałości, pracowitości,
umięjętności kierowania projektem niż jakichś wyjątkowych zdolności - nie
sądzę, żeby się to znacząco różniło od programowania systemowego, a pewien
znany system napisał praktycznie dla satysfakcji student informatyki,
z całym szacunkiem dla niego bynajmniej nie "genialny programista". I tak
samo jak systemy, języki potrafią przejść dłuuugą drogę od wersji 0.1 do 2.6.
Jaroslaw Zabiello
>> Brzydki kod można napisać w każdym języku.
>
> Z tym sie chyba kazdy zgodzi.
No właśnie. Ważne są też nawyki z poprzednich języków. Zwłaszcza
tragicznie wyglądają próby pisanie w Ruby (ale to samo jest w Pythonie)
przez osoby który mentalnie są przy nawykach z Javy, C++ czy, tfu ;), PHP.
> Co gorsza odbieram rubiego jako duplikat pythona o innej skladni,
Niby w czym podobny? Model obiektowy zupełnie inny. Filozofia (w wielu
pkt.) też. Do pewnego stopnia wszystkie języki mają podobne konstrukcje.
Ale to trochę za mało aby mówić o duplikacie w tym wypadku. To jest
kompletnie idiotyczna teza wynikająca po prostu z nieznajomości Rubiego.
> Wiec jesli jezyk nie wnosi nic nowego
Tu jesteś w błędzie. Też tak myślałem jak nie znalem Rubiego. Może kiedyś
napiszę dokładniejszą analizę czy Ruby może coś wnieść dla pythonisty. A
może wnieść sporo. Np. Capistrano, służy do tzw. deployingu (nie tylko
kodu Rubiego, można tego użyć do aktualizacji serwerów w dowolnej
technologii). Albo God, system monitoringu, też ustawiany w Ruby. Albo
Rake (nie znam odpowiednika w Pythonie, w Javie byłby to z grubsza Ant)
Ułatwia pisanie tasków administracyjnych. Bardzo fajna sprawa. Łatwe i
przyjemne. Rails i Merb śmigające już asynchronicznie na EventMachine i
Rack (odpowiednik WSGI). Oczywiście Python ma potężny Twisted, tylko co z
tego jak cholernie skomplikowany? Java też ma potężne biblioteki, tylko
czy każdy ma czas i dość zaparcia aby je poznać? To, czego ja oczekuję od
softu to po pierwsze: prostoty i piękna, po drugie: elastyczności.
Rozwiązania w Pythonie bledną przy tym co potrafi RSpec, Sequel (ORM),
Merb, Rails, Rake, Capistrano. Są albo wyraźnie *bardziej skomplikowane*
albo nie mają odpowiedników. Z innej beczki. Weźmy taki RubyGems,
podstawowa biblioteka do zarządzania pakietami Rubiego. Bije na głowę
prostotą, designem i możliwościami pythonowe setuptools z ich skryptem
easy_install (czy oni w ogóle wiedzą co to jest easy install? :P)
Oczywiście Python wciąż trzyma kilka mocnych asów w rękawie (np. takich
jak Zope3, ZODB, PIL, wbudowany Unicode) ale nie da się już powiedzieć, że
Ruby nie jest w stanie wnieść nic nowego. Jestem ciekaw czy gdyby nie
pojawiły się Railsy, powstałyby takie projekty jak Pylons czy TurboGears.
No i czy Sun by pomyślał o Jythonie gdyby nie fenomenalny rozwój JRuby?
> Rzeczywiście bardzo fajne podejscie i bardzo jest to czytelne. Tylko
> pozazdrościć i czekś kiedy zaimplementują coś podobnego w pythonie.
Nie masz co czekać. To się nigdy nie stanie. Ograniczeniem jest składnia
Pythona. Nie pozwala na tworzenie takich konstrukcji. Duża część piękna
Rubiego wynika z możliwości pomijania nawiasów i klamer oraz otwartych
klas. Dlatego można napisać coś takiego:
show_me :all_users, :created_at => 6.hours.ago
> Nie znam Railsow i nic mi ten kod nie mowi
Myślałe, że masz jakiekolwiek pojęcie. No dobra. To pełniejszy obraz.
Active Record stosuje prostą zasadę: mapuje każdą tabelę na klasę.
Atrybuty klasy są odpowiednikami kolumn w tabeli. A instancje klas to
wiersze z tabeli. Spróbuj to samo uzyskać w SLQAlchemy, zobaczysz ile się
naklepiesz kodu.
class Client < ActiveRecord::Base
belongs_to :firm
end
class Account < ActiveRecord::Base
belongs_to :firm
end
class Firm < ActiveRecord::Base
has_many :clients
has_one :account
end
No to coś dodajmy:
Client.create :name => 'Jarek'
firm = Firm.new
firm.clients << Client.find_by_name('Jarek')
firm.account = Account.find(:first)
firm.save!
> Poprzedni kawałek kodu zrozumielem bez znajomosci RSpec, wiec zupelnie
> mnie nie przekonales o czytelnosci ActiveRecord, a wprost przeciwnie.
Ty nie przesadzaj z kolei. Skąd mogłem wiedzieć że nie jesteś w ogóle w
temacie?
>> Ruby nie zmusza cię do pisania
>>
>> items.each do |item|
>> end
>
> Ale ogrom kodu, który czytalem tego używa i to jest paskudne.
Rzecz gustu. To daje większe możliwości. Z tego powodu w Pythonie nie
dałoby się zaimplementować takich szablonów RJS używanych przez Rails do
wspomagania generowanie kodu JavaScript.
> nie wiem co znaczy operator <=>
Krótszy zapis dla:
if x > y
1
elsif x == y
0
else
-1
end
Adam Karpierz
> > Brzydki kod można napisać w każdym języku.
> Z tym sie chyba kazdy zgodzi.
Nie.
Nie da sie np napisac (no mowie z przekasem
szczerze to baaardzo trudno) napisac brzydkiego
kodu w Algolu/Simuli
AK
Adam Karpierz
> No i czy Sun by pomyślał o Jythonie gdyby nie fenomenalny rozwój JRuby?
Pomyslalby (bo JRuby tu nie mial znaczenia - jak juz to przeszkodzil - bo
zajal
juz miejsce Jythona u Suna).
Sun pomyslal o Jythonie dopiero gdy zobaczyl co sie stalo z IronPythonem
Pomyslal kilka lat za pozno.
AK
Sulsa
"Adam Karpierz" <karpierz@_NOSPAM_python.pl> wrote:
> Pomyslalby (bo JRuby tu nie mial znaczenia - jak juz to przeszkodzil - bo
> zajal
> juz miejsce Jythona u Suna).
> Sun pomyslal o Jythonie dopiero gdy zobaczyl co sie stalo z IronPythonem
> Pomyslal kilka lat za pozno.
Moze glupio sie spytam, ale co sie stalo z IronPythonem? Nie slyszalem
o jego szerszych zastosowaniach.
Rafał Zawadzki
Jak dla mnie idea IronPythona śmierdzi troche chęcią ubicia Jythona
przez Microsoft.
Ale tylko trochę - spiskowa teoria...
Adam Karpierz
> Jak dla mnie idea IronPythona smierdzi troche checia ubicia Jythona przez
> Microsoft.
>
> Ale tylko troche - spiskowa teoria...
Raczej spiskowa.
IronPython powstal wczesniej.
To pozniej MS zatrudnil Hugunina (ten Pan jest dla mnie
niedosciglym idealem :)
AK
Piotr Sawicki
> tak pięknego jak w Ruby już nie będzie łatwo napisać w Pythonie
[...]
> Given "a username '$username'" do |username|
> @username = username
> end
>
> Given "a password '$password'" do |password|
> @password = password
> end
>
> Given "an email '$email'" do |email|
> @email = email
> end
Erm... Ty tak poważnie o urodzie powyższego zapisu?
Bo mnie właśnie ten przykład ze strony rspeca odrzucił.
Piotr Sawicki
Jaroslaw Zabiello
<ps17...@students.mimuw.edu.pl> wrote:
> Bo mnie właśnie ten przykład ze strony rspeca odrzucił.
AP porównaj to sobie z typowym unit testami i starą metodologią Test
Driven Development. Zobacz też inne przykłady. Dosyć dobrze się to czyta.
Oczywiście czytanie kodu Rubiego nie jest zasadniczo przeznaczone dla
kogoś kto nie ma pojęcia o Rubim. Dotyczy to każdego języka.
Rafał Zawadzki
> On Thu, 06 Mar 2008 13:50:45 -0000, Piotr Sawicki
> <ps17...@students.mimuw.edu.pl> wrote:
>
>> Bo mnie właśnie ten przykład ze strony rspeca odrzucił.
>
> AP porównaj to sobie z typowym unit testami i starą metodologią Test
> Driven Development. Zobacz też inne przykłady. Dosyć dobrze się to
> czyta. Oczywiście czytanie kodu Rubiego nie jest zasadniczo przeznaczone
> dla kogoś kto nie ma pojęcia o Rubim. Dotyczy to każdego języka.
Tak więc sam widzisz, że "tak pięknego jak w Ruby już nie będzie łatwo
napisać w Pythonie " jest bardzo względne - programistę Ruby rzuci na
kolana, programistę pythona nie.
Mi akurat się w miarę podoba.
Piotr Sawicki
>
>> Bo mnie właśnie ten przykład ze strony rspeca odrzucił.
>
> AP porównaj to sobie z typowym unit testami i starą metodologią Test
No dobra (w metodologie nie wierzę), ale liczyłem na przykład
czegoś co w rubym jest piękne a w pythonie się równie elegancko
nie da i już, z powodu immanentnych cech języka.
> Driven Development. Zobacz też inne przykłady. Dosyć dobrze się to czyta.
Mnie osłabiają kilometry bezmyślnego kodu (jak akcesory w javie).
> Oczywiście czytanie kodu Rubiego nie jest zasadniczo przeznaczone dla
> kogoś kto nie ma pojęcia o Rubim. Dotyczy to każdego języka.
Kiedy właśnie python mnie ujął tym, że rozumiałem kodu bez znajomości
języka, jak widzę program w rubym to napada> :mnie @interpunkcja!
Piotr Sawicki
Jaroslaw Zabiello
<ps17...@students.mimuw.edu.pl> wrote:
>> AP porównaj to sobie z typowym unit testami i starą metodologią Test
>
> No dobra (w metodologie nie wierzę),
Nie rozumiem, co tu wiara ma do rzeczy?
> ale liczyłem na przykład czegoś co w rubym jest piękne a w pythonie się
> równie elegancko nie da i już, z powodu immanentnych cech języka.
A da się napisać taką bibliotekę jak RSpec lepiej w Pythonie?
Albo da się uzyskać taką składnię? (przykład z książki do Railsów)
puts 20.bytes #=> 20
puts 20.kilobytes #=> 20480
puts 20.megabytes #=> 20971520
puts 20.gigabytes #=> 21474836480
puts 20.terabytes #=> 21990232555520
puts 20.petabytes #=> 22517998136852480
puts 1.exabyte #=> 1152921504606846976
puts 20.seconds #=> 20
puts 20.minutes #=> 1200
puts 20.hours #=> 72000
puts 20.days #=> 1728000
puts 20.weeks #=> 12096000
puts 20.fortnights #=> 24192000
puts 20.months #=> 51840000
puts 20.years #=> 630720000
puts Time.now #=> Thu May 18 23:29:14 CDT 2006
puts 20.minutes.ago #=> Thu May 18 23:09:14 CDT 2006
puts 20.hours.from_now #=> Fri May 19 19:29:14 CDT 2006
puts 20.weeks.from_now #=> Thu Oct 05 23:29:14 CDT 2006
puts 20.months.ago #=> Sat Sep 25 23:29:16 CDT 2004
puts 20.minutes.until("2006-12-25 12:00:00".to_time) #=> Mon Dec 25
11:40:00 UTC 2006
puts 20.minutes.since("2006-12-25 12:00:00".to_time) #=> Mon Dec 25
12:20:00 UT C 2006
> Mnie osłabiają kilometry bezmyślnego kodu (jak akcesory w javie).
Mnie też. W Rubim można pisać kod jeszcze krócej niż w Pythonie bez
dramatycznych szkód dla czytelności jak to jest w Perlu.
> Kiedy właśnie python mnie ujął tym, że rozumiałem kodu bez znajomości
> języka, jak widzę program w rubym to napada> :mnie @interpunkcja!
A nie dopadło cię na początku tajemnicze "def msg(self, a,b)" gdzie
"msg(1,2,3)" wywalo blad bo przecież self nie wchodzi w skład parametrów?
Pamiętam nawet, że niektóre książki tłumaczyły to self na jakiś mętny
polski odpowiednik i dopiero z tego wychodziła kaszana!
Oczywiście, mnie osobiście to pythonowe self nie przeszkadza odkąd wiem po
co jest, ale na początku może być trochę dezorientujące, bo ta nazwa jest
w Pythonie przecież kwestią czystej umowy. Tak więc, gdy zapoznasz sie z
podstawami Rubiego i zrozumiesz do czego sa symbole i jak oznaczane sa
zmienne instancji, klasy i globalne to potem nie będziesz robił wielkich
oczu patrząc na @zmienną_instancji, @@klasową, $globalną czy Stałą.
Tupteq
Dla mnie jest to cholernie nieczytelne "20.months.ago" - niegramatyczne
- jakieś kropki. Tu trzeba kropki, tam kreski i strzałki, setki
powielonych metod. Zamiast "puts 20.gigabytes" wolę "print 20 * 2**30",
bo co ma liczba 20 do gigabajtów? Nic! Skąd mam wiedzieć, że metoda
megabytes tylko mnoży, równie intuicyjne wydaje mi się stworzenie
tablicy o takim właśnie rozmiarze. Fakt, mogę sobie przeczytać
dokumentację, ale ZTCW typy wbudowane Ruby'ego mają bardzo dużo metod,
więc nie jest to taka szybka i prosta sprawa.
Tak więc _moim_zdaniem_ nie jest to piękne, a redundantne.
--
Pozdro... Tupteq
Piotr Sawicki
>>> AP porównaj to sobie z typowym unit testami i starą metodologią Test
>>
>> No dobra (w metodologie nie wierzę),
>
> Nie rozumiem, co tu wiara ma do rzeczy?
W jaraniu się kolejnymi metodologiami? Też mnie to zastanawia.
>> ale liczyłem na przykład czegoś co w rubym jest piękne a w pythonie się
>> równie elegancko nie da i już, z powodu immanentnych cech języka.
>
> A da się napisać taką bibliotekę jak RSpec lepiej w Pythonie?
To nie ja twierdzę, że python jest lepszy niż ruby, tylko Ty przeciwnie.
> Albo da się uzyskać taką składnię? (przykład z książki do Railsów)
>
> puts 20.bytes #=> 20
> puts 20.kilobytes #=> 20480
[ciach zylion kopii tego samego przykładu]
A dlaczego 20.kilobytes miałoby być ładniejsze niż kilobytes(20)?
Mam nadzieję, że z tym pięknem nie chodzi o ascii-artową estetykę
kodu poprzeplatanego takimi urodziwymi leksemami jak #=>...
>> Mnie osłabiają kilometry bezmyślnego kodu (jak akcesory w javie).
>
> Mnie też. W Rubim można pisać kod jeszcze krócej niż w Pythonie bez
> dramatycznych szkód dla czytelności jak to jest w Perlu.
No to pokaż jakiś zwięzły przykład kodu krótszego a czytelnego.
> A nie dopadło cię na początku tajemnicze "def msg(self, a,b)" gdzie
> "msg(1,2,3)" wywalo blad bo przecież self nie wchodzi w skład parametrów?
Może jakbym nie widział nigdy obiektowości i konwencji wołania metod.
Bardziej mnie irytują __podkreślenia__.
> Pamiętam nawet, że niektóre książki tłumaczyły to self na jakiś mętny
> polski odpowiednik i dopiero z tego wychodziła kaszana!
To problem kaszaniarskich tłumaczy. I don't give a fuck.
> Tak więc, gdy zapoznasz sie z podstawami Rubiego i zrozumiesz
Och, zapoznałem się. A i w smalltalku sporo pisałem.
> do czego sa symbole i jak oznaczane sa zmienne instancji, klasy
> i globalne to potem nie będziesz robił wielkich oczu patrząc na
> @zmienną_instancji, @@klasową, $globalną czy Stałą.
A gdybyś się zapoznał z atari basic i zrozumiał do czego służą
symbole, to byś nie robił wielkich oczu patrząc na napis$.
Taki argument to można i o APL-u napisać.
Piotr Sawicki
Jaroslaw Zabiello
<ps17...@students.mimuw.edu.pl> wrote:
>>> No dobra (w metodologie nie wierzę),
>>
>> Nie rozumiem, co tu wiara ma do rzeczy?
>
> W jaraniu się kolejnymi metodologiami? Też mnie to zastanawia.
Jakiemu jaraniu? Po prostu BDD jest lepsze od TDD.
>> A da się napisać taką bibliotekę jak RSpec lepiej w Pythonie?
>
> To nie ja twierdzę, że python jest lepszy niż ruby, tylko Ty przeciwnie.
Zależy do czego. Ja głównie polemizowałem z wysoce debilną tezą jakoby
Ruby był tylko kopią Pythona z elementami Perla.
> A dlaczego 20.kilobytes miałoby być ładniejsze niż kilobytes(20)?
Naturalniej się czyta. No ale nie będę się spierał, bo to rzecz gustu. W
każdym razie takiego DSL jak ma RSpec nie stworzysz w Pythonie.
> No to pokaż jakiś zwięzły przykład kodu krótszego a czytelnego.
Naprawdę chcesz się zmierzyć? :)
"No to pokaż jak byś odwrócił Pythonie taki string".reverse
Albo jak byś wyświetlił czy dany 'filepath' jest folderem?
print File.directory? filepath
Albo jak byś sprawdził czy on istnieje?
print File.exists? filepath
Albo jak byś wyłączył wybraną metodę z listy metod w klasie bez
komentowania?
class C
#...
def metoda_niedostepna
#...
end if false # :)
end
Albo pokaż jak byś wysłał do serwera poniższą strukturę. Ma to
pójść metodą POST i dane mają być kodowane JSON'em.
data = {
'labels': ['first', 'second', 'third'],
'times': [1,2,3],
'data': [[1,2,3], [4,5,6], [7,8,9]],
}
W Ruby wygląda to tak:
require 'rubygems'
require 'net/http'
require 'uri'
require 'json'
# Dla Ruby 1.9 definicja zmiennej data może być taka sama jak w Pythonie
# Ale tu podam dla starszej wersji, 1.8x
data = {
:labels => %w(first second third), # nie trzeba tak, ale ja lubię, bo
mniej pisania
:times => [1,2,3],
:data => [[1,2,3], [4,5,6], [7,8,9]],
}
Net::HTTP.post_form URI.parse('http://localhost:3000/charst/1'), :data =>
data.to_json
Pokaż że w Pythonie to da się napisać ładniej i krócej.
Jaroslaw Zabiello
wrote:
> Dla mnie jest to cholernie nieczytelne "20.months.ago" - niegramatyczne
Niby co niegramatyczne?
> Zamiast "puts 20.gigabytes" wolę "print 20 * 2**30",
I to ma być ładniejsze? :) A jak byś zapisał to?
puts 20.minutes.since "2006-12-25 12:00:00".to_time
> bo co ma liczba 20 do gigabajtów?
To jest akurat fragment DSL używany w Rails. W danym kontekście to ma
sens. Np. w Active Record można zapisać
User.find :all, :created_at => 15.minutes.ago
Jak ty byś zapisał ten czas aby było czytelniej?
Grzegorz Staniak
> Naprawdę chcesz się zmierzyć? :)
A może byście sobie poszli na pl.comp.lang.ruby, na priva, albo jakoś tak?
Piotr Sawicki
>> W jaraniu się kolejnymi metodologiami? Też mnie to zastanawia.
>
> Jakiemu jaraniu?
Trzeba coś zajarać, żeby się zachwycić takim junk codem jak w tej
próbce rspeca, który nie wprowadza kompletnie żadnej logiki
a w aspekcie czytelności stanowi masło maślane usiane dziwną
interpunkcją, $username "being a" >username :is_a @username
'therefore' &username means! `username` yadda yadda yadda.
> W każdym razie takiego DSL jak ma RSpec nie stworzysz w Pythonie.
Zgoda, czytając kod pythonowy mam pewność że będzie napisany w pythonie.
>> No to pokaż jakiś zwięzły przykład kodu krótszego a czytelnego.
>
> Naprawdę chcesz się zmierzyć? :)
Chciałbym wreszcie zobaczyć ten legendarny czytelny fragment kodu
w rubym, którego w pythonie się równie zwięźle napisać nie da.
> "No to pokaż jak byś odwrócił Pythonie taki string".reverse
>
> Albo jak byś wyświetlił czy dany 'filepath' jest folderem?
>
> print File.directory? filepath
>
> Albo jak byś sprawdził czy on istnieje?
>
> print File.exists? filepath
Normalnie - procedurą. Sposób znany od czasów, kiedy dosiadający
dinozaurów jaskiniowcy wycinali chińczykiem subroutiny w fortranie.
Różnicę w zwięzłości kodu między językami dają takie ich cechy
jak np. możliwość definiowania własnych funkcji (powszechna już
od dawna), automatyczne odśmiecanie (od nie tak znowu dawna),
zwrotne tuple i pattern matching, polimorfizm, type inference,
funkcje wyższych rzędów, partial evaluation czy kontynuacje.
Różnicę w takim sensie, że choćby przyszło tysiąc atletów i zjadło
tysiąc kotletów, to w języku bez danej cechy nie zdołają pewnych
konstrukcji (nie chodzi o pojedyncze wywołania gotowców z biblioteki)
zapisać równie prosto. Mój ulubiony przykład to zastosowanie leniwego
wartościowania argumentów (ma to choćby haskell) do problemu SameFringe.
Kilka ekranów programu skraca się do trywialnie jasnej linijki, bez
żadnych dirty hacków, nie przez wywołanie z góry przewidzianego do
tego kodu, tylko dzięki konsekwentnemu wbudowaniu w język lenistwa.
> Albo jak byś wyłączył wybraną metodę z listy metod w klasie bez
> komentowania?
>
> class C
> #...
> def metoda_niedostepna
> #...
> end if false # :)
> end
Tak samo, z różnicą że warunek jest przed definicją a nie po.
> Albo pokaż jak byś wysłał do serwera poniższą strukturę. Ma to
> pójść metodą POST i dane mają być kodowane JSON'em.
[ciach słownik i importy]
> Net::HTTP.post_form URI.parse('http://localhost:3000/charst/1'),
> :data => data.to_json
O rany, nie widzę powodu żeby to nie mogło w pythonie wyglądać
mniej więcej jak BibliotekaDoJSON.zrobTo(dane=slownik).
Nie używam jsona, więc nie wiem czy jest razem z bateriami
(szybki gugiel pokazuje, że jest jakiś json.py), ale nawet
jeśli do takiego zapisu nie wystarczyłby własny jednolinijkowy
wrapper, to ten argument nazywałby się ,,więcej bibliotek''
- a nie jestem pewien czy to ruby ma ich faktycznie więcej.
Piotr Sawicki
Radosław Bułat
> On 06.03.2008, Jaroslaw Zabiello <ab...@tpnet.pl> wroted:
>
>> Naprawdę chcesz się zmierzyć? :)
>
> A może byście sobie poszli na pl.comp.lang.ruby, na priva, albo jakoś tak?
>
> GS
Nie rozumiem takiego podejścia. Padają z Waszej strony zarzuty, że Ruby
jest podobny do Perla, Ruby to w dużej mierze kopia Pythona, więc my się
bronimy. Już nawet nie chodzi o porównywanie, jaki język jest
ładniejszy, czytelniejszy, bo to jest zawsze subiektywna ocena.
I jakkolwiek mnie możecie zlać to słowa Jarosława powinny przemawiać do
Was. W końcu Jarek pisze zarówno w Rubym jak i Pythonie (oba języki zna
bardzo dobrze) więc ma pełne porównanie.
A mnie osobiście bardzo razi takie czcze gadanie, niepoparte żadnymi
faktami.
Ja od siebie mogę podsumować ten temat tak:
- lubię zarówno Rubiego jak i Pythona (z tym, że ten drugi język jeszcze
nie znam dobrze, wolę zainwestować swój czas w coś bardziej odmiennego)
- odczucia co do czytelności i przejrzystości kodu to często subiektywne
odczucie, ale jednak to Ruby uchodzi z język, w którym pisze się
przepiękne DSLe (i znów pewnie znajdą się osoby co będą kręcić nosem na
hasło "przepiękne", ale nigdy wszystkim nie dogodzi :)). Mnie osobiście
kod podany przez Jarka podoba się bardzo. Ale często to kwestia
znajomości języka. Sam pamiętam, że wcale mnie składnią Ruby na początku
nie ujął. A teraz to najpiękniejszy język jaki znam.
- jeśli miałbym wybrać to co mi się podoba w Pythonie, a czego nie ma w
Rubym to namespacesy i importy. Dzięki temu mamy "czystą" przestrzeń
nazw i o konflikt bardzo ciężko (w Rubym łatwiej, ale to już
konsekwencja innych rzeczy, coś za coś)
Grzegorz Staniak
>>> Naprawdę chcesz się zmierzyć? :)
>>
>> A może byście sobie poszli na pl.comp.lang.ruby, na priva, albo jakoś tak?
>
> Nie rozumiem takiego podejścia. Padają z Waszej strony zarzuty, że Ruby
> jest podobny do Perla, Ruby to w dużej mierze kopia Pythona, więc my się
> bronimy.
To może weź tych "was" co zarzucają i umówcie się na jakąś ustawkę?
Piotr 'piter' Hlawski
Poprosiłem przed chwilą kolegę z pracy nie znającego ani Pythona ani Ruby o
odczytanie:
20.gigabytes
i
20 * 2**30
i o opinię "Co jest dla ciebie czytelniejsze jeśli czytałbyś kod?". Oto jego
odpowiedź:
'''
To pierwsze jest czytelniejsze, eeee, jakieś 20 * 2, chuj wie co to jest
''''
Twoja opinia 'tu trzeba kropki' jest co najmniej dziwna. Kropka powinna być
dla Ciebie naturalnym oddzieleniem metody od odbiorcy.
Co do argumentu 'co ma liczba 20 do gigabajtów? Nic!' -- nie zgodzę się.
Problem u Ciebie jest taki, że nie traktujesz 20 jako obiektu. To _JEST_
obiekt.
--
[ Piotr 'piter' Hlawski ( <phlawski$gmail,com> ) ( GG: 4534287 ) ]
Szymon
To przykre, rozumiem, że wziąłeś kogoś kto nie ma pojęcia o jakimkolwiek
programowaniu, nie? I tacy ludzie mają być ekspertami? Ciekawe czy na
pytanie, który zapis jest czytelniejszy:
'''
dupa
'''
// dupa
#dupa
/* dupa */
też odpowie... "że co? po chuj jakieś /* */ "
--
Wojciech Malinowski
>> No to pokaż jakiś zwięzły przykład kodu krótszego a czytelnego.
>
> Naprawdę chcesz się zmierzyć? :)
>
> "No to pokaż jak byś odwrócił Pythonie taki string".reverse
Nie chciałbym się wtrącać w środek ładnie rozwijającego się i
bezsensownego flame'a ale zainteresowała mnie jedna rzecz.
Rozmawiałem z kilkoma osobami na temat Ruby i zawsze powyższy argument o
metodzie reverse stringów się pojawiał jako pierwszy.
Programuję już ładnych kilka lat w różnych językach i technologiach ale
nigdy nie odwracałem stringa. Przycinałem, podmieniałem, wyszukiwałem,
wklejałem, a nawet iterowałem od tyłu, ale nigdy nie odwracałem.
Pytanie moje jest więc takie: jakie są możliwe zastosowania odwracania
stringa? Jeżeli takie rzeczy zostają wbudowane w język, czy jego
bibliotekę standardową to chyba ja coś przeoczyłem, bo ludzie muszą
używać tego na codzień.
Pozdrawiam,
Wojciech Malinowski
Piotr 'piter' Hlawski
[...]
>> Poprosiłem przed chwilą kolegę z pracy nie znającego ani Pythona ani Ruby
>> o odczytanie:
>>
>> 20.gigabytes
>>
>> i
>>
>> 20 * 2**30
>>
>> i o opinię "Co jest dla ciebie czytelniejsze jeśli czytałbyś kod?". Oto
>> jego odpowiedź:
>> '''
>> To pierwsze jest czytelniejsze, eeee, jakieś 20 * 2, chuj wie co to jest
>> ''''
>
> To przykre, rozumiem, że wziąłeś kogoś kto nie ma pojęcia o jakimkolwiek
> programowaniu, nie? I tacy ludzie mają być ekspertami? Ciekawe czy na
> pytanie, który zapis jest czytelniejszy:
>
> '''
> dupa
> '''
>
> // dupa
> #dupa
> /* dupa */
>
> też odpowie... "że co? po chuj jakieś /* */ "
>
Zaraz, zaraz. A gdzie ja napisałem, że ten człowiek jest "ekspertem -
programistą" ?
Zapytałem specjalnie postronną osobę o czytelność zapisu, bo o tym była
mowa. Nie obrażaj tego człowieka, bo jest on w swojej dziedzinie ekspertem.
Bycie ekspertem nie implikuje bycia programistą.
Szymon
Ależ ja nie chciałem go obrazić, to nie jego wina, że ktoś mu zadaje
pytania i oczekuje fachowej opiniotwórczej odpowiedzi na tematy, na
których się nie zna.
Czy jak będzie ekspertem w dziedzinie hodowli drobiu (z pełnym
szacunkiem dla tych ludzi) to będziesz go pytał o to jak powinien
wyglądać język programowania? To tak jakby mnie pytać o to czy kurczaki
są lepiej hodowane jak są karmione raz dziennie czy dwa razy dziennie.
Jak szukasz odpowiedzi na pytanie o ładną składnię, to pytaj ludzi,
którzy się na tym znają.
Piotr 'piter' Hlawski
> Piotr 'piter' Hlawski pisze:
[...]
>>
>> Zaraz, zaraz. A gdzie ja napisałem, że ten człowiek jest "ekspertem -
>> programistą" ?
>> Zapytałem specjalnie postronną osobę o czytelność zapisu, bo o tym była
>> mowa. Nie obrażaj tego człowieka, bo jest on w swojej dziedzinie
>> ekspertem. Bycie ekspertem nie implikuje bycia programistą.
>>
>
> Ależ ja nie chciałem go obrazić, to nie jego wina, że ktoś mu zadaje
> pytania i oczekuje fachowej opiniotwórczej odpowiedzi na tematy, na
> których się nie zna.
>
> Czy jak będzie ekspertem w dziedzinie hodowli drobiu (z pełnym
> szacunkiem dla tych ludzi) to będziesz go pytał o to jak powinien
> wyglądać język programowania? To tak jakby mnie pytać o to czy kurczaki
> są lepiej hodowane jak są karmione raz dziennie czy dwa razy dziennie.
>
> Jak szukasz odpowiedzi na pytanie o ładną składnię, to pytaj ludzi,
> którzy się na tym znają.
>
Nie masz racji. Chodziło o czytelność _kodu_. Czemu tak cię boli, że
czytelniejszym kodem jest 20.gigabytes. Tak Wam, Pythonautom, nie może
przejść przez gardło, że coś jest czytelniejsze niż w Python?
mrk
<phlawski@cut_this_crap.gmail.com> wrote:
> Nie masz racji. Chodziło o czytelność _kodu_. Czemu tak cię boli, że
> czytelniejszym kodem jest 20.gigabytes. Tak Wam, Pythonautom, nie może
> przejść przez gardło, że coś jest czytelniejsze niż w Python?
znacznie czytelniejsze imho by było:
from siprefix import *
20*giga
nie znam ruby, ale rozumiem, że można też napisać:
50.kilotons, 20.nanofarads itd?
--
mrk
Grzegorz Staniak
>> Nie masz racji. Chodziło o czytelność _kodu_. Czemu tak cię boli, że
>> czytelniejszym kodem jest 20.gigabytes. Tak Wam, Pythonautom, nie może
>> przejść przez gardło, że coś jest czytelniejsze niż w Python?
>
> znacznie czytelniejsze imho by było:
>
> from siprefix import *
>
> 20*giga
>
> nie znam ruby, ale rozumiem, że można też napisać:
> 50.kilotons, 20.nanofarads itd?
Też nie znam, ale domyślam się, że to _nie są_ standardowe metody obiektów
typu 'int' (or compatible), ale wynik możliwości modyfikowania typów
wbudowanych. Piękny efekt czegoś, co się w Pythonie nazywa 'monkeypatching'.
Piotr 'piter' Hlawski
Oczywiście nie, bez przesady, ale nic nie stoi na przeszkodzie abyś sobie
otworzył klasę Integer i dopisał metodę kilotons czy też nanofarads.
Szymon
Nie, ja mam to w dupie. Nie interesuje mnie czy coś jest w Pythonie
czytelne czy też nie. Python jak każdy język: ma swoje zalety i ma też
pełno wad. Nie rozumiem tylko czemu pytasz o przejrzystość człowieka,
który nawet nie rozumie zapisu: 20*2, pewnie zapisu: 1_234_567 też
pewnie nie zrozumie.
Piotr 'piter' Hlawski
> Piotr 'piter' Hlawski pisze:
[...]
>> Nie masz racji. Chodziło o czytelność _kodu_. Czemu tak cię boli, że
>> czytelniejszym kodem jest 20.gigabytes. Tak Wam, Pythonautom, nie może
>> przejść przez gardło, że coś jest czytelniejsze niż w Python?
>>
>
> Nie, ja mam to w dupie. Nie interesuje mnie czy coś jest w Pythonie
> czytelne czy też nie. Python jak każdy język: ma swoje zalety i ma też
> pełno wad. Nie rozumiem tylko czemu pytasz o przejrzystość człowieka,
> który nawet nie rozumie zapisu: 20*2, pewnie zapisu: 1_234_567 też
> pewnie nie zrozumie.
>
A ja nie rozumiem, dlaczego z góry zakładasz co ten człowiek rozumie a czego
nie rozumie. Jest inżynierem. Dobrym. Chyba nie sądzisz że człowiek po
polibudzie nie wie co oznacza zapis 20*2 ? Ogólnie wie, ale ocenił poziom
_czytelności_. EOT z mojej strony, bo widzę że się nie dogadamy.
Szymon
Że zacytuję co napisałeś:
"To pierwsze jest czytelniejsze, eeee, jakieś 20 * 2, chuj wie co to jest"
Czy to nie świadczy o tym, że ten człowiek tego nie rozumie? Jeżeli dla
niego "20*2 chuj wie co to" to niech nie chwali się, że politechnikę
skończył, bo cóż z tego, że skończył skoro nic się nie nauczył i dla
niego 20*2 to "chuj wie co".
Piotr 'piter' Hlawski
Tak, teraz to już zdecydowany EOT, ale uzupełnie - może do ciebie dotrze o
co w tym chodzi.
Czepiasz się słówek aby obrócić kota ogonem. Taka jest prawda. W porównaniu
z 20.gigabytes - 20*2**30 to chgw co to jest. Bo co to jest? Oprócz tego,
że jest to liczba 21474836480.. 21474836480 czego? Bananów? Litrów piwa?
Radosław Bułat
--
Radosław Bułat
Tu chodzi o coś innego. Każdy przecież wie, że zapis 20*2 to mnożenie
liczb. Ale to może oznaczać cokolwiek (kilobajty, ilość buraków, masa).
Tu chodzi o _semantykę_ zapisu. W momencie gdy np masz taki zapis:
obiekt.size = 20.kilobytes
zamiast
obiekt.size = 20 * 1024
Od razu wiesz o co chodzi. Nie musisz nawet komentować (zakładając, że
wiesz co dana metoda robi, w tym wypadku mnoży 20 * 1024).
Ja Wam się bardzo dziwię Pythoniści (być może część poczuje się urażona,
że ugólniam), ale dopiero co argumentowaliście, że Python jest łatwy w
odczycie, nawet dla kogoś kto _nie jest ekspertem_ od Pythona. Myślę, że
głupio by było argumentować, że zapis 20.kilobytes jest czytelny nawet
dla nie-programistów, ale za to jest ogromnie czytelny dla kogoś kto nie
pisał tego kodu. Bo jakby nie było programiści to też ludzie i umilając
sobie takimi drobnymi elementami odejmujemy sobie pracy: myślenia. Niech
to będzie choćby "jeden takt" naszego ludzkiego procesora, zawsze to coś.
Przytaczany przez Jarka przykład 5.years.ago chyba jest lepsze niż
ręcznie obliczanie daty (którego proces obliczania musi powtórzyć osoba
czytająca kod)? Gdzie to Wasze "Simple is better than complex." czy tam
"Readability counts."?
Tupteq
> On Thu, 06 Mar 2008 16:15:17 -0000, Tupteq <tupte...@CIACHtlen.pl>
> wrote:
>
>> Dla mnie jest to cholernie nieczytelne "20.months.ago" - niegramatyczne
>
> Niby co niegramatyczne?
Te pseudo-zdania z kropkami i innymi fikołkami wplecionymi w środek.
Ponadto powyższy zapis nie daje mi żadnej informacji co jest jednostką -
minuta, sekunda? Ja wolę normalne timedelta, przynajmniej nie dodam
sobie do wyniku 5 i się nie będę zastanawiał czy dodałem 5 sekund, czy 5
dekad.
>> Zamiast "puts 20.gigabytes" wolę "print 20 * 2**30",
>
> I to ma być ładniejsze? :)
Oczywiście. Liczba to liczba, a tak to nie wiem co mi się dostanie na
wyjściu gigabajtsów. Btw: jak w Rubym napiszesz 1 gigabajt? 1.gigabyte,
czy 1.gigabytes?
> A jak byś zapisał to?
> puts 20.minutes.since "2006-12-25 12:00:00".to_time
format = '%Y-%m-%d %H:%M:%S'
base = datetime.strptime("2006-12-25 12:00:00", format)
print base + timedelta(minutes=20)
:P
>> bo co ma liczba 20 do gigabajtów?
>
> To jest akurat fragment DSL używany w Rails. W danym kontekście to ma
> sens. Np. w Active Record można zapisać
>
> User.find :all, :created_at => 15.minutes.ago
>
> Jak ty byś zapisał ten czas aby było czytelniej?
To chyba oczywiste: "now() - timedelta(minutes=15)" :)
Generalnie chyba mój "problem" tkwi w fakcie, iż bardzo podoba mi się
zasada "Explicit is better than implicit.". Nie lubię polegać na zbyt
"sprytnych" funkcjach, bo zawsze, prędzej czy później, obraca się to
przeciwko mnie. Wolę powiedzieć co chcę otrzymać, a nie zastanawiać się
czy przypadkiem sprytna funkcja źle mnie nie zrozumiała. Ofkorz nie
chodzi mi też o to, żeby uciekać się do takich ekstremów jak statyczne
typowanie i takie tam ;)
--
Pozdro... Tupteq
Szymon
yyy, że co? Mylisz pojęcia. 20.gigabytes = 20*(2**10). I co z tego
wynika? Ano to, że to są dwie liczby i nic więcej. Jak idziesz kupować
kartofle to bierzesz je na 'kila' czy 'kilogramy'? Ludzie kupują na
kila, a ile to jest kilo, ano to jest tysiąc, a czego tysiąc? No właśnie
nie wiadomo.
Jak już chcesz rozdzielać pojęcia 20 gigabajtów i 20*2**10 to nie możesz
tego traktować tak jak teraz, czyli jako zwykłe liczby w programie.
Powinno to być ubrane w klasy, z odpowiednimi operatorami tak by nie
można było zrobić np. 20GB*20GB, bo to jest bez sensu.
Taki system typów kiedyś napisałem w C++ i potem kilka osób się wkurzało
dlaczego 10zł*10zł jest bez sensu bo program się wykrzacza.
W pythonie jak sobie nawet zapiszesz:
size = 20.gigabytes
to na czytelności (IMHO) niewiele zyskujesz jako, że potem to i tak jest
traktowane jako zwykła liczba, a nie jako gigabajty. Co zatem masz potem
w zmiennej 'size'? Masz tam gigabajty czy liczbę? Wydaje mi się, że
liczbę/ilość, ale wtedy pytanie: ilość czego?
Podsumowując:
- zapis 20.gigabytes nie jest zły
- pytanie o opinię człowieka, który sprawia wrażenie, że nie rozumie
zapisu 20 * 2**10 jest bez sensu
- jako, że i tak znacznie rzadziej się używa takich specjalizowanych
jednostek, lepiej może rozwijać składnię w stronę tego co jest np. w Adzie:
2_000_000 = 2000000
Albo też można wprowadzić osobne klasy dla każdej jednostki. To daje Ci
takie rzeczy jak:
- przechowywanie informacji o jednostce
- konwersja z jednej jednostki na inną
- uniemożliwienie konwersji jeśli jest ona zbyt głupia
Bez takiego systemu typów to możesz zapomnieć o czytelnym programowaniu,
bo i tak wszystko będzie traktowane jako liczba.
Jaroslaw Zabiello
wrote:
> domyślam się, że to _nie są_ standardowe metody obiektów typu 'int' (or
> compatible), ale wynik możliwościmodyfikowania typów wbudowanych. Piękny
> efekt czegoś, co sięw Pythonie nazywa 'monkeypatching'.
Monkeypatching nie jest tu chyba dobrym terminem bo kojarzy się głównie z
łataniem (patching) ad-hoc głupich (małpich-monkey) błędow w dostarczonym
kodzie.
Ruby nie dzieli (tak jak Python, Java, C++) obiekty na jakieś typy
prymitywne i na obiekty wyższego rzędu. Każdy obiekt ma tam te same prawa
i podlega tym samym regułom (jak w Smalltalku).
Fakt, że takie dodawanie metod jest dosyć popularną techniką w Ruby, ale
to dlatego, że uzyskuje się dzięki temu ładne DSL'e. Taka praktyka nazywa
się tam "duck punching".
Grzegorz Staniak
>> domyślam się, że to _nie są_ standardowe metody obiektów typu 'int' (or
>> compatible), ale wynik możliwościmodyfikowania typów wbudowanych. Piękny
>> efekt czegoś, co sięw Pythonie nazywa 'monkeypatching'.
>
> Monkeypatching nie jest tu chyba dobrym terminem bo kojarzy się głównie z
> łataniem (patching) ad-hoc głupich (małpich-monkey) błędow w dostarczonym
> kodzie.
Nie, to jest ogólne słowo-klucz na określenie zmian zachowania obiektów
w trakcie wykonywania programu, http://en.wikipedia.org/wiki/Monkey_patch
[...]
> Fakt, że takie dodawanie metod jest dosyć popularną techniką w Ruby, ale
> to dlatego, że uzyskuje się dzięki temu ładne DSL'e. Taka praktyka nazywa
> się tam "duck punching".
Same thing. See above.
Jaroslaw Zabiello
wrote:
> Ja wolę normalne timedelta, przynajmniej nie dodam sobie do wyniku 5 i
> sięnie będę zastanawiał czy dodałem 5 sekund, czy 5 dekad.
Jak słusznie napisał Radek, tu chodzi o _semantykę_ zapisu. W momencie gdy
np masz taki zapis:
obiekt.size = 20.kilobytes zamiast obiekt.size = 20 * 1024 od razu wiesz o
co chodzi w tym kontekście.
>>> Zamiast "puts 20.gigabytes" wolę "print 20 * 2**30",
>> I to ma być ładniejsze? :)
>
> Oczywiście. Liczba to liczba
No tak, ale ja wolę zapisać 3.gigabytes zamiast z niczym się nie kojarzącą
wartość 3221225472.
> jak w Rubym napiszesz 1 gigabajt? 1.gigabyte, czy 1.gigabytes?
W Rails zdefiniowali 1.gigabyte oraz 1.gigabytes (jestem generalnie
przeciwnikiem używania polskich nazw metod, klas czy modułów). Dziala tak
samo (użyto aliasów). To po to, aby kod ładniej wyglądał. Wybierasz tą
wersję, która lepiej się prezentuje w danym kontekście. Czyli 1.gigabyte
i 2.gigabytes.
>> A jak byś zapisał to?
>> puts 20.minutes.since "2006-12-25 12:00:00".to_time
>
> format = '%Y-%m-%d %H:%M:%S'
> base = datetime.strptime("2006-12-25 12:00:00", format)
> print base + timedelta(minutes=20)
I to ma być czytelniejsze? :-D
>> User.find :all, :created_at => 15.minutes.ago
>> Jak ty byś zapisał ten czas aby było czytelniej?
>
> To chyba oczywiste: "now() - timedelta(minutes=15)" :)
15.minutes.ago jednak wygląda dużo czytelniej i ładniej.
> Generalnie chyba mój "problem" tkwi w fakcie, iż bardzo podoba mi się
> zasada "Explicit is better than implicit."
Ja też lubię tą zasadę, i wypadku wolę sposób w jaki Python podchodzi do
namespaces. Ale z drugiej strony, jestem w stanie nie przejmować się tą
zasadą jeśli celem jest uzyskanie ładnego DSL'a. W końcu po to się tworzy
DSL'e aby można było coś robić łatwiej i czytelniej.
> Ofkorz nie chodzi mi też o to, żeby uciekać się do takich ekstremów jak
> statyczne typowanie i takie tam ;)
No sam widzisz, że z tą zasadą explicite>imlicite trzeba trochę umiaru. :)
Piotr Husiatyński
> On Fri, 07 Mar 2008 11:02:07 -0000, Tupteq <tupteqCI...@CIACHtlen.pl>
> wrote:
>
> > Ja wolę normalne timedelta, przynajmniej nie dodam sobie do wyniku 5 i
> > sięnie będę zastanawiał czy dodałem 5 sekund, czy 5 dekad.
>
> Jak słusznie napisał Radek, tu chodzi o _semantykę_ zapisu. W momencie gdy
> np masz taki zapis:
> obiekt.size = 20.kilobytes zamiast obiekt.size = 20 * 1024 od razu wiesz o
> co chodzi w tym kontekście.
>
> >>> Zamiast "puts 20.gigabytes" wolę "print 20 * 2**30",
> >> I to ma być ładniejsze? :)
20.gitabytes powinno być czytelniejsza dla osoby która nie zna ruby. O
ile nie pomyśli
że 20 to jakaś zmienna. Przecież nie wie że zmienne nie zaczynają się
od liczb.
Ale wystarczy że ta sama osoba zobaczy więcej takich `magicznych`
rozwiązań,
poprzeplatanych różnymi znakami i kod przestaje być czytelny.
Zamiast 20.gigabytes wolałbym zobaczyć 20 * SIZE_GIGABYTE. I to
zrozumie
już chyba każdy.
> Jarosław Zabiełłohttp://blog.zabiello.com
> irc://irc.eu.freenode.net/ruby.pl
> irc://irc.eu.freenode.net/python.pl
Bardzo ciekawy flame się wywiązał. Zawsze uważałem, że najlepsze są
takie,
w których nie ma szans na przekonanie do czegokolwiek drugiej
strony :P
Ruby jest teraz modny, więc ma wielu fanów którzy są nim zachwyceni.
Zobaczymy za jakiś czas czy rzeczywiście pomysły składniowe w nim
zrealizowane są takie dobre.
Sulsa
Wojciech Malinowski <vir...@wp.pl> wrote:
> Nie chciałbym się wtrącać w środek ładnie rozwijającego się i
> bezsensownego flame'a ale zainteresowała mnie jedna rzecz.
>
> Rozmawiałem z kilkoma osobami na temat Ruby i zawsze powyższy argument o
> metodzie reverse stringów się pojawiał jako pierwszy.
>
> Programuję już ładnych kilka lat w różnych językach i technologiach ale
> nigdy nie odwracałem stringa. Przycinałem, podmieniałem, wyszukiwałem,
> wklejałem, a nawet iterowałem od tyłu, ale nigdy nie odwracałem.
>
> Pytanie moje jest więc takie: jakie są możliwe zastosowania odwracania
> stringa? Jeżeli takie rzeczy zostają wbudowane w język, czy jego
> bibliotekę standardową to chyba ja coś przeoczyłem, bo ludzie muszą
> używać tego na codzień.
Zgadzam się z tezą, tymbardziej ze w pytonie ta operacja jest logiczną
kontynuacją wprowadzonych juz mechanizmów indeksowania sekwencji:
>>> string = "12345"
>>> string[::-1]
'54321'
Krócej i też czytelnie, więc argument był chybiony. Pozatym takie
przykłady mozna mnozyc w kazdym jezyku programowania bo zostaly one
dobrane pod ruby. W kazdym innym jezyku mozna znalezc procedure ktorej
nie ma w ruby i kazac programista ruby przepisac ja krocej na ruby.
Sulsa
Piotr 'piter' Hlawski <phlawski@cut_this_crap.gmail.com> wrote:
>
> 20.gigabytes
>
> i
>
> 20 * 2**30
>
> i o opinię "Co jest dla ciebie czytelniejsze jeśli czytałbyś kod?". Oto jego
> odpowiedź:
> '''
> To pierwsze jest czytelniejsze, eeee, jakieś 20 * 2, chuj wie co to jest
> ''''
>
To pogratuluj koledze wsponiałej znajomości matematyki, może nich
zapisze się na korepetycje do jakiegos ucznie klasy 3 podstawowki, on
mu wytlumaczy co jest mnozenie, z potegowaniem moze byc juz gorzej bo
musialby pogadac z 7 klasista, a on z checi udowodnienia swojej
wyższosci intelektualnej(dzieci w tym wieku sie powoli juz buntuja)
moglby go zmieszac z blotem.
Pozatym co oznacza 20.gigabytes? Skad mam wiedziec czy to jest
rozmiar w bajtach czy w kilobajtach, a moze w bitach? Taka formula moze
robic wiele rzeczy i wcale nie jest piekna, łącznie z nią aby być
konsekwentnym do typu liczbowego trzeba by dodac takie komendy jak:
20.beers
20.vodkas
20.sockets
20.potatos
20.kilometers
20...
--
Jaroslaw Zabiello
<PHusia...@gmail.com> wrote:
> 20.gigabytes powinno być czytelniejsza dla osoby która nie zna ruby. O
> ile nie pomyśli że 20 to jakaś zmienna. Przecież nie wie że zmienne nie
> zaczynają się od liczb.
A w Pythonie jest niby inaczej? Tam liczby też są obiektami posiadającymi
swoje metody.
>>> dir(1)
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
'__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
'__floordiv__', '__getattribute__', '__getnewargs__', '__hash__',
'__hex__', '__index__', '__init__', '__int__', '__invert__', '__long__',
'__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__',
'__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__',
'__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__',
'__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__',
'__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__',
'__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']
Kolejny przykładm, gdzie wersja Pythona jest mniej czytelna od Rubiego:
Ruby:
>> -1.abs
=> 1
Python:
>>> -1 .__abs__()
-1
Co ciekawe, jak przed kropką nie będzie spacji to Python wywali
SyntaxError. Nie powiesz że to jest oczywiste.
> Zamiast 20.gigabytes wolałbym zobaczyć 20 * SIZE_GIGABYTE. I to
> zrozumie już chyba każdy.
Bo ja wiem czy każdy :). W wypadku liczby to może nie jest wielka różnica,
ale przy 6.hours.ago już miałbyś problem aby to podobnie czytelnie wyrazić
w Pythonie. Kolega próbował z deltą, wyszło dużo więcej kodu i całość jest
dużo brzydsza.
--
Jarosław Zabiełło
Grzegorz Staniak
> Kolejny przykładm, gdzie wersja Pythona jest mniej czytelna od Rubiego:
>
> Ruby:
>>> -1.abs
>=> 1
>
> Python:
>>>> -1 .__abs__()
> -1
>
> Co ciekawe, jak przed kropką nie będzie spacji to Python wywali
> SyntaxError. Nie powiesz że to jest oczywiste.
Przecież od tego jest builtin. Podaj przykład sytuacji, kiedy musisz użyć
metody __abs()__.
Radosław Bułat
> Zgadzam się z tezą, tymbardziej ze w pytonie ta operacja jest logiczną
> kontynuacją wprowadzonych juz mechanizmów indeksowania sekwencji:
>>>> string = "12345"
>>>> string[::-1]
> '54321'
>
> Krócej i też czytelnie, więc argument był chybiony. Pozatym takie
> przykłady mozna mnozyc w kazdym jezyku programowania bo zostaly one
> dobrane pod ruby. W kazdym innym jezyku mozna znalezc procedure ktorej
> nie ma w ruby i kazac programista ruby przepisac ja krocej na ruby.
>
I to jest intuicyjne?:D Nawet nie wiedziałem że tak w pythonie można
odwrócić string. Spodziewałem się coś na obraz len: reverse(string).
Radosław Bułat
> Bardzo ciekawy flame się wywiązał. Zawsze uważałem, że najlepsze są
> takie,
> w których nie ma szans na przekonanie do czegokolwiek drugiej
> strony :P
Dobry flame nie jest zły :P.
> Ruby jest teraz modny, więc ma wielu fanów którzy są nim zachwyceni.
> Zobaczymy za jakiś czas czy rzeczywiście pomysły składniowe w nim
> zrealizowane są takie dobre.
Wybralem Ruby bo po bliższym przyjrzeniu się po prostu zakochałem się w
składni w jego dynamiźmie. Nie, nie jestem fan-boyem (jak to niektórzy
określają), bo wiem _dlaczego_ kocham ten język.
Te pomysły składniowe to nie jest coś wprowadzonego wczoraj. Na tym
zbudowano railsy (które notabene nie są idealnym frameworkiem, ale to
już inny temat). Ta składnia już się sprawdziła dla wielu ludzi
(powtórzę się: nigdy wszystkich nie zadowoli :)).
Btw, gwoli ścisłości. Tu nie chodzi o to, że każda linijka programu w
Rubym ma być napchana takimi ozdobnikami, elementami DSL. Ale
odpowiednie ilości mnie osobiście bardzo się podobają i ułatwiają pracę
(np. wspominana walidacja modelu, albo filtry w kontrolerach). To jest
coś co sprawia, że patrzę na cudzy model i od razu wyłapuję pewne rzeczy
(relacje z innymi modelami, walidację, callbacki etc). Mało tego,
definicja takiego modelu ma potem logiczne części oraz właściwą
implementację.
Jaroslaw Zabiello
>> 20 * 2**30
> To pogratuluj koledze wsponiałej znajomości matematyki
A niby od kiedy to takie oczywiste, że dwie gwiazdki to operator
potęgowania? :-D To w matematyce używa się powszechnie takich symboli na
oznaczenie operatora potęgowania?
> Pozatym co oznacza 20.gigabytes? Skad mam wiedziec czy to jest
> rozmiar w bajtach czy w kilobajtach, a moze w bitach?
No chyba żartujesz. Przecież to wynika z samej nazwy. Giga to przedrostek
krotności a byte(s) jednostka. Gdyby miały być bity to byłby zapis
20.gigabits.
> robic wiele rzeczy i wcale nie jest piekna, łącznie z nią aby być
> konsekwentnym do typu liczbowego trzeba by dodac takie komendy jak:
> 20.beers
> 20.vodkas
> 20.sockets
> 20.potatos
> 20.kilometers
> 20...
Dlaczego zaraz "trzeba by dodać"? Dodajesz tylko wtedy, jeśli potrzebujesz
uzyskać bardziej SAMODOKUMENTUJĄCY się kod. Rails nie zlicza ziemniaków
ani wódek, więc nie ma potrzeby aby to dodawać. Wiadomo że i tak to
wszystko są zwykłe liczby. Chodzi tu tylko o zwiększenie czytelności i
uczynienie kodu samodokumentującym.
A rozszyfrowanie takiego potencjalnego 20.kilometers nie wymaga wcale
doktoratu z matematyki, tylko trochę pomyślenia. 20 = ilość, kilo =
krotność, metr = podstawowa jednostka, czyli 20_000 metrów. Chyba spójne
podejście, co?