🚀 go-pugleaf

Marcin Gryszkalis wrote:

> Witam

Również witam

[...]
> 
> No i muszę przyznać, że jestem troszkę zawiedziony :) Być może tutejsi
> spece odpowiedzą coś konstruktywnego na to co mi wyszło w trakcie...
> 
> 1. środowisko - dużo słyszałem, że NB6 jest wspaniale jeśli chodzi o
> rubiego, sam używałem go do javy i byłem zadowolony a tutaj:
>  - podpowiedzi działają sensownie jedynie jeśli zmienna jest wcześniej
> przypisana do stałej albo do Klasa.new - niby rozumiem, że język
> dynamiczny i można zwracać co się chce, ale... jakoś tak jak jestem w NB
> to przyzwyczajony jestem do tego, że w Javie podpowiedzi są 100%. Dla
> nowego programisty, który nie zna jeszcze API są one nieco mało pomocne...
> kiedy .add prezentuje mi listę 1000 klas, w których takowa meta się
> pojawia

Odpowiedziałeś sobie sam. Bardzo trudno napisać mechanizm podpowiedzi, który
znasz z języków takich jak Java w języku tak dynamicznym jak Ruby. IMHO NB
ma i tak najlepszy. Btw, jest już NB 6.1

>  - debugger działa fatalnie (używałem "classic debugger" bo jakoś nie
>  bardzo
> byłem w stanie uruchomić "fast"), nie zatrzymuje się na ustawionych
> breakpointach a zatrzymuje się w nieokreslonych miejscach, czasami wogóle
> się gubi...

Użyj fast, jest o lata świetlne lepszy i działa dokładnie tak jakbyś tego
sobie życzył.

> 
> 2. sam ruby
>  - jeszcze się nie przyzwyczaiłem do "kontroli typów bez określania
>  typów",
> dotychczas pisałem albo w Javie, gdzie wszystko jest precyzynie z góry
> określone, albo w perlu, gdzie właściwie nie ma typów...
>  - składnia jest miła, do braku średników się przyzwyczaiłem szybko, bloki
>  i
> yield są fajne, regexpy są na szczęście w języku i nie trzeba się
> wygłupiać jak w Javie
>  - niektórych rzeczy nie czuję - czy modyfikowanie istniejących klas (np.
> String) przez dodawanie metod nie powoduje zbyt dużego zamętu? Czemu nie
> zrobić tego "normalnie", czyli odziedziczyć, rozszerzyć i używać jawnie
> zmodyfikowanej wersji? Przecież przekazując projekt komuś innemu wpędzimy
> go w nerwicę zanim się zorientuje, że przedefiniowaliśmy metodę '+' w
> bibliotecznej klasie String...

Nikt nikogo do niczego nie zmusza. Nie chcesz, nie modyfikujesz. Chcesz,
robisz to i dokumentujesz jak należy. Jest rdoc, który Ci to umożliwia :)
Mnie osobiście otwieranie klas kilka razy bardzo pomogło. Dziedziczenie, jak
podajesz, będzie działać, ale nie będzie _tak_ wygodne - bo jak
zrealizujesz coś takiego:

class String
  def suffix
    "bubu" + self
  end
end

>> "foo".suffix
=> "bubu foo"
>> x = "bar"
=> "bar"
>> x.suffix
=> "bubu bar"

z dziedziczeniem będziesz musiał zrobić:

class SuffixedString < String
  def suffix
    "bubu " + self
  end
end

>> x = SuffixedString.new("foo")
=> "foo"
>> x.suffix
=> "bubu foo"

musisz jawnie deklarować x jako SuffixedString aby to działało. Nie
skorzystasz w ten sposób z faktu że bezpośrednio podany string jako "jakiś
string" jest String i będzie w pierwszym przykładzie od razu posiadał
metodę suffix. Jak zwykle w takich wypadkach oczywiście miecz posiada dwa
ostrza, bo fakt, można otworzyć klasę, nic o tym nie powiedzieć innym
programistom i narobić bigosu, ale to jest już kwestia zaufania do siebie i
bycia profesjonalnym :) Tutaj wyraźnie mamy podejście takie jak w Pythonie,
czyli "panie i panowie, jesteśmy poważni i wiemy co robimy".

Moim zdaniem to jest kwestia przyzwyczajenia programisty i podejścia do
sprawy. Przychodzisz z Javy, więc dla Ciebie naturalne są inne zachowania,
jednak otwartość klas daje duże pole do popisu programistom np. frameworków
takich jak Rails.

>  - dlaczego w haszach czasem używa się po prostu stałych Stringów, a
>  czasem
> symboli (tj. 'a' => 'a' VS :a => 'a')?

Bo jest to możliwe. Preferowane jest jednak indeksowanie symbolami. O
symbolach:

http://tinyurl.com/2p3uxx

> 
> 3. biblioteki i dokumentacja
>  - bardzo mi brakuje czegoś jak CPAN dla perla, jedno miejsce, gdzie w
> ustandaryzowanej postaci znajdę wszystkie możliwe biblioteki, z
> dokumentacją, historią wersji, plikami itd. a w rubym? weźmy taki sobie
> rubymail - na rubyforge są pliki ale nie ma dokumentacji, na ruby-doc jest
> dokumentacja tylko do biblioteki standardowej, historię i linki mam na
> http://raa.ruby-lang.org, dokumentacje po instalacji z gema lokalnie (a
> jeśli najpierw chciałbym sprawdzić API czy wogóle warto instalować?) A do
> tego wszystkiego pakiet nazywa się rubymail a klasy są w przestrzeni
> RMail, super spójne ;)
>  - ruby-mysql i mysql-ruby, jeden o statusie preview a drugi "test",
>  obydwa
> tego samego autora.

Ja akurat jestem zadowolony z rubyforge jako serwisu i z dokumentacji. Samo
API Ruby jest również świetnie opisane. To, że znajduje się trochę softu
third-party, które ma mankamenty - cóż, piszą to różni ludzie, nie można
mieć o to pretensji do samego języka. W większości wypadków dokumentacja
jest bardzo dobra. Fakt, jeśli spotkałeś się z brakiem dokumentacji w necie
i musisz coś instalować aby poznać co-to-w-ogóle-jest, to jest upierdliwe. 
Jednakże, chodzi o to aby te minusy nie przesłoniły nam plusów ;P a więc:

Pisałem kiedyś w Perlu, kiedyś w PHP, trochę w Pythonie, ostatnio w Javie i
co stwierdzam --- coś takiego jak zarządzanie pakietami po przez rubygems
jest genialne. Perl, z przeproszeniem, jest tutaj 100 lat za murzynami.
Python ze swoimi eggs też wysiada. No, powiedzmy PHP'owe pear coś tam umie,
ale każdy już z nich wymięka przy takim czymś jak gem server. Co do samego
pisania w języku takim jak Ruby - po półtora roku intensywnego
programowania w nim uważam, że nie ma piękniejszego języka dla
programisty :) Fakt, ma mankamenty, głównie związane z wydajnością, jednak
rozwija się cały czas i mam nadzieję, że cały czas ku lepszemu.


-- 
[ Piotr 'piter' Hlawski ( <phlawski$gmail,com> ) ( GG: 4534287 ) ]

Marcin Gryszkalis pisze:
> 2. sam ruby
>  - jeszcze się nie przyzwyczaiłem do "kontroli typów bez określania typów",
> dotychczas pisałem albo w Javie, gdzie wszystko jest precyzynie z góry
> określone, albo w perlu, gdzie właściwie nie ma typów...

Witaj w świecie języków dynamicznych :) To, że się nie możesz 
przyzwyczaić jest całkowicie naturalne, bo bez kontroli typów jesteś 
narażony na błędy, które w Javie mogłeś szybko wyłapać.

W związku z tym polecam pisanie testów, w Ruby on Rails testowanie
jest naprawdę łatwe i przyjemne - nawet dla programisty, który o testach
jednostkowych wcześniej tylko słyszał ;-)

>  - niektórych rzeczy nie czuję - czy modyfikowanie istniejących klas (np.
> String) przez dodawanie metod nie powoduje zbyt dużego zamętu? Czemu nie
> zrobić tego "normalnie", czyli odziedziczyć, rozszerzyć i używać jawnie
> zmodyfikowanej wersji? Przecież przekazując projekt komuś innemu wpędzimy
> go w nerwicę zanim się zorientuje, że przedefiniowaliśmy metodę '+' w
> bibliotecznej klasie String... 

To jest cecha spotykana w czysto obiektowych językach programowania, 
którymi Ruby jest zainspirowany. Dla programisty Javy jest to pewien 
szok poznawczy :) Mimo wszystko bywa przydatne.

>  - dlaczego w haszach czasem używa się po prostu stałych Stringów, a czasem
> symboli (tj. 'a' => 'a' VS :a => 'a')?

Symbole to jest osobny temat do dyskusji. Najlepiej poświęcić troszkę 
czasu na złapanie ich "filozoficznego" sensu i nauczyć się stosować.
W razie potrzeby symbol można zamienić na string i vice versa.


-- 
Tomek małpka japko kropka info.

TomekC wrote:
> W związku z tym polecam pisanie testów, w Ruby on Rails testowanie
> jest naprawdę łatwe i przyjemne - nawet dla programisty, który o testach
> jednostkowych wcześniej tylko słyszał ;-)
Unit testy robiłem, choć dla takiego malutkiego projektu z właściwie jedną
metodą "biznesową" to temat pominąłem :) Czytałem sobie choćby tutaj
http://blog.zabiello.com/articles/2007/10/28/shoulda-rspec
ale na początek postanowiłem skupić się jednak na wszystkich "cudach i
dziwiach" rubiego ;)

pozdrawiam
-- 
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@fork.pl, gg:2532994
http://the.fork.pl

Piotr 'piter' Hlawski wrote:
> Odpowiedziałeś sobie sam. Bardzo trudno napisać mechanizm podpowiedzi,
> który znasz z języków takich jak Java w języku tak dynamicznym jak Ruby.
> IMHO NB ma i tak najlepszy. Btw, jest już NB 6.1
gdzieś tam czytałem o jakimś ide komercyjnym, gdzie autorzy właściwie
wbudowali w ide rodzaj interpretera rubiego, który wykonuje kawałki
programu i rozpoznaje co jaka nazwa odpowiada jakiej klasie. Nie pamiętam w
tej chwili nazwy i nie widziałem tego na oczy...

> Użyj fast, jest o lata świetlne lepszy i działa dokładnie tak jakbyś tego
> sobie życzył.
przy następnej okazji spróbuję i będę krzyczał tutaj jak nie będzie
działało ;)

> Nikt nikogo do niczego nie zmusza. Nie chcesz, nie modyfikujesz. Chcesz,
> robisz to i dokumentujesz jak należy. 
Jasne, rdoc jest ok, tylko chociażby ze względu na sposób działania ide o
tym, że metoda się zmieniła dowiadujesz się po fakcie, przypadkiem przy
czytaniu dokumentacji itd. Nie mniej jednak w pełni się zgadzam, że taka
możliwość jest baaaaaardzo kusząca, fajna i wygodna :) tym bardziej
nieostrożnie użyta może być niebezpieczna ;)

> musisz jawnie deklarować x jako SuffixedString aby to działało. 
oczywiście, to tak na prawdę troch jednak kwestia filozoficzna wydaje mi
się: java daje mi scyzoryk a i tak boi się, że się skaleczę - ruby daje mi
(i reszcie zespołu) katany i ufa, że sobie nie poucinamy rączek ;)

> "panie i panowie, jesteśmy poważni i wiemy co robimy".
:)

>>  - dlaczego w haszach czasem używa się po prostu stałych Stringów, a
>>  czasem
>> symboli (tj. 'a' => 'a' VS :a => 'a')?
> Bo jest to możliwe. 
ach! brzmi jak perl ;)

> Preferowane jest jednak indeksowanie symbolami. O 
> symbolach:
> http://tinyurl.com/2p3uxx
fajne, dzięki

> Ja akurat jestem zadowolony z rubyforge jako serwisu i z dokumentacji.
> Samo API Ruby jest również świetnie opisane. 
To co jest na ruby-doc jest zupełnie ok

> To, że znajduje się trochę 
> softu third-party, które ma mankamenty - cóż, piszą to różni ludzie, nie
> można mieć o to pretensji do samego języka.
ja rozumiem, że to jest 3rd party ale może ktoś za mało precyzji narzucił na
twórców (jeśli chodzi o nazewnictwo modułów i klas na przykład - bo rdoc
sam format dość dobrze na moje oko porządkuje).


> Pisałem kiedyś w Perlu, kiedyś w PHP, trochę w Pythonie, ostatnio w Javie
> i co stwierdzam --- coś takiego jak zarządzanie pakietami po przez
> rubygems jest genialne. Perl, z przeproszeniem, jest tutaj 100 lat za
> murzynami. 
Prawdę mówiąc jakbyś tak krótko napisał na czym pokega ta przewaga gems nad
cpan'em, bo moje używanie ograniczało się do `gem install`, a z drugiej
strony nadal do końca nie rozumiem, czemu muszę pisać

gem 'rmail'
require 'rmail'

a przy mysqlu wystarczy

require 'mysql'


> Python ze swoimi eggs też wysiada. No, powiedzmy PHP'owe pear 
> coś tam umie, ale każdy już z nich wymięka przy takim czymś jak gem
> server. 

Rozumiem, że stosujesz to do dystrybucji własnych pakietów? W czym to jest
lepsze od wyciągniecia wersji np. z subversion?

> Co do samego pisania w języku takim jak Ruby - po półtora roku 
> intensywnego programowania w nim uważam, że nie ma piękniejszego języka
> dla programisty :) Fakt, ma mankamenty, głównie związane z wydajnością,
> jednak rozwija się cały czas i mam nadzieję, że cały czas ku lepszemu.
Prawdę mówiąc własnie czytając takie opinie postanowiłem spróbować czegoś
nowego :) może to była za krótka próba - w każdym razie jeszcze nie
odpuszczam, następny krok to któryś z reklamowanych frameworków...

pozdrawiam
-- 
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@fork.pl, gg:2532994
http://the.fork.pl

On May 16, 1:14 am, Marcin Gryszkalis <m...@fork.pl> wrote:
> 1. środowisko - dużo słyszałem, że NB6 jest wspaniale jeśli chodzi o
> rubiego, sam używałem go do javy i byłem zadowolony a tutaj:
>  - podpowiedzi działają sensownie jedynie jeśli zmienna jest wcześniej
> przypisana do stałej albo do Klasa.new - niby rozumiem, że język dynamiczny
> i można zwracać co się chce, ale... jakoś tak jak jestem w NB to
> przyzwyczajony jestem do tego, że w Javie podpowiedzi są 100%. Dla nowego
> programisty, który nie zna jeszcze API są one nieco mało pomocne...
> kiedy .add prezentuje mi listę 1000 klas, w których takowa meta się pojawia
Kwestia gustu, dla wielu programistów podpowiadanie nie jest
szczególnie istotne.

> 2. sam ruby
>  - jeszcze się nie przyzwyczaiłem do "kontroli typów bez określania typów",
> dotychczas pisałem albo w Javie, gdzie wszystko jest precyzynie z góry
> określone, albo w perlu, gdzie właściwie nie ma typów...
W Javie nie wszystko jest precyzyjnie określone. Weźmy na przykład
taką klasę ArrayList, która zwraca elementy jako obiekty klasy Object
nie ważne co do niej włożymy. Następnie trzeba rzutować.. brrrrr.
Oczywiście mamy też typy generyczne, jednak nie jest możliwe
umieszczenie w takiej kolekcji obiektów o różnych klasach bez potrzeby
późniejszego rzutowania z klasy bazowej...

>  - niektórych rzeczy nie czuję - czy modyfikowanie istniejących klas (np.
> String) przez dodawanie metod nie powoduje zbyt dużego zamętu? Czemu nie
> zrobić tego "normalnie", czyli odziedziczyć, rozszerzyć i używać jawnie
> zmodyfikowanej wersji? Przecież przekazując projekt komuś innemu wpędzimy
> go w nerwicę zanim się zorientuje, że przedefiniowaliśmy metodę '+' w
> bibliotecznej klasie String...
Zwykle nie modyfikuje się metod 'wbudowanych', gdyż prawie na pewno
dostaniemy wtedy nowy język. Zmiana '+' w klasie String lub Fixnum
spowodowałaby totalną katastrofę, gdyż na 100% metody te są używane w
bibliotece standardowej. Jednak dodawanie własnych metod jest bardzo
pomocne i często spotykane. np. w niektórych projektach dodanie
Array#shuffle (miesza losowo elementy) bywa bardzo pomocne.

>  - dlaczego w haszach czasem używa się po prostu stałych Stringów, a czasem
> symboli (tj. 'a' => 'a' VS :a => 'a')?
Dlaczego czasem użwany jest MySQL, a czasem PostgreSQL? :) Ogólnie
klasa Symbol jest wydajniejsza, więc jest częsciej spotykana w tym
zastosowaniu. W bibliotece ActiveSupport znajdziesz klasę
HashWithIndefferentAccess która traktuje :a i 'a' jako identyczne
klucze.

>  - ruby-mysql i mysql-ruby, jeden o statusie preview a drugi "test", obydwa
> tego samego autora.
Uroki Open Source... Niezła podpowiedzią co do jakości biblioteki jest
ilość artukułów/postów/blogów o niej. Zwykle Google dobrze tutaj
podpowiada.

Pozdrawiam,
Wojciech Piekutowski

Wojciech Piekutowski wrote:
> Kwestia gustu, dla wielu programistów podpowiadanie nie jest
> szczególnie istotne.
No toteż piszę, że mój gust własnie zrobił bleeee ;)

> W Javie nie wszystko jest precyzyjnie określone. Weźmy na przykład
> taką klasę ArrayList, która zwraca elementy jako obiekty klasy Object
> nie ważne co do niej włożymy. Następnie trzeba rzutować.. brrrrr.
> Oczywiście mamy też typy generyczne, jednak nie jest możliwe
> umieszczenie w takiej kolekcji obiektów o różnych klasach bez potrzeby
> późniejszego rzutowania z klasy bazowej...
Kwestia podejścia, logicznie rzecz biorąc jak umieszczasz w jednej kolekcji
obiekty róznych klas to prawie zawsze znaczy, że mają one ze sobą coś
wspólnego... nie mówię, że jest to rozwiązanie idealne, m.in. dlatego nie
siedzę sobie grzecznie w tej javie tylko szukam przygód w świecie
rubiego ;)

> Zwykle nie modyfikuje się metod 'wbudowanych', gdyż prawie na pewno
> dostaniemy wtedy nowy język. Zmiana '+' w klasie String lub Fixnum
> spowodowałaby totalną katastrofę, gdyż na 100% metody te są używane w
> bibliotece standardowej. Jednak dodawanie własnych metod jest bardzo
> pomocne i często spotykane. np. w niektórych projektach dodanie
> Array#shuffle (miesza losowo elementy) bywa bardzo pomocne.
Jasne, a tak na marginesie - czy API biblioteki standardowej zmienia się w
drobnych wydaniach języka (drobnych czyli nowe x dla 1.8.x)? Czy jeśli
nagle metoda shuffle pojawi się w bibliotece standardowej to nie jest to
groźne dla istniejącego kodu?

>> - ruby-mysql i mysql-ruby, jeden o statusie preview a drugi "test",
>> obydwa tego samego autora.
> Uroki Open Source... Niezła podpowiedzią co do jakości biblioteki jest
> ilość artukułów/postów/blogów o niej. Zwykle Google dobrze tutaj
> podpowiada.
Tak też robiłem...

pozdrawiam
-- 
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@fork.pl, gg:2532994
http://the.fork.pl

Piotr 'piter' Hlawski wrote:
>>  - ruby-mysql i mysql-ruby
Tutaj jeszcze uwaga co do spójności i ruby gems - 
pakiet oficjalnie nazywa się 'rubymail', załączam go przez 'gem "rmail"'
a uzywam przez klasy RMail:: - podobnie z tym mysqlem, piszę
require 'mysql' i nie wiem czy używam pakietu 'ruby-mysql'
czy  'mysql-ruby' :)

czy pakiety gemowe nie mogłyby się nazywać tak jak moduły najwyższego
poziomu?

pozdrawiam
-- 
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@fork.pl, gg:2532994
http://the.fork.pl

Dnia 15-05-2008 o 23:14:22 Marcin Gryszkalis <mg@fork.pl> napisał(a):

>  - debugger działa fatalnie (używałem "classic debugger" bo jakoś nie  
> bardzo byłem w stanie uruchomić "fast"),

Domyślnie NB używa JRuby który nie ma działa z fastdebuggerem. Przełącz  
sobie na zwykły Ruby. No i oczywiście NB 6.1 a nie 6.0.

> 3. biblioteki i dokumentacja - bardzo mi brakuje czegoś jak CPAN dla 
> perla, jedno miejsce, gdzie w ustandaryzowanej postaci znajdę wszystkie 
> możliwe biblioteki,

Przecież jest RubyForge i zarządzający tym (świetny) RubyGems.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Dnia 16-05-2008 o 11:25:50 Marcin Gryszkalis <mg@fork.pl> napisał(a):

> Czy jeśli nagle metoda shuffle pojawi się w bibliotece standardowej to  
> nie jest to
> groźne dla istniejącego kodu?

Teoretycznie tak, w praktyce mała na to szansa. Ruby pozwala na zamrożenie  
dowolnych obiektów. Wystrzeli wyjątkiem jak coś będzie chciało grzebać w  
obiektach które zamrozisz (włącznie z tymi wbudowanymi). To, plus  
automatyczne testy (co jest w zasadzie i tak konieczne do pisania) powinno  
móc być w stanie wyłapać różne sytuacje.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

On Fri, 16 May 2008 12:34:36 +0200, Marcin Gryszkalis <mg@fork.pl> wrote:

>>>  - ruby-mysql i mysql-ruby
> Tutaj jeszcze uwaga co do spójności i ruby gems -
> pakiet oficjalnie nazywa się 'rubymail', załączam go przez 'gem "rmail"'
> a uzywam przez klasy RMail:: - podobnie z tym mysqlem, piszę
> require 'mysql' i nie wiem czy używam pakietu 'ruby-mysql'
> czy  'mysql-ruby' :)
>
> czy pakiety gemowe nie mogłyby się nazywać tak jak moduły najwyższego
> poziomu?

moglyby i w wiekszosci tak sie nazywaja. w tym przypadku skrewil autor  
biblioteki, nie jezyka :P

jest jeszcze taka kwestia jak konwencja zamiany nazw klas na pliki i  
odwrotnie. jezeli w Javie masz klase np. CamelCaseClass to powinna sie ona  
znajdowac w CamelCaseClass.java. w Ruby powinno byc raczej  
camel_case_class.rb.

no i w nazwach gemow nie mozna (chyba) stosowac ':', z kolei w nazwach  
klas i pakietow jest problem z '-'.

pzdr
	szeryf

-- 
Przemysław ,,Szeryf'' Kowalczyk :: http://szeryf.wordpress.com/

On Fri, 16 May 2008 00:14:22 +0200, Marcin Gryszkalis <mg@fork.pl> wrote:
>
> Napisałem aplikację w rubim, serwerek SOAP, kilka funkcji plus proste

SOAP - bleeee :)

> operacje na bazie, plus wysyłanie maili w oparciu o szablony,  
> konfiguracja
> w yamlu. Wszystko razem niecałe 500 wierszy.

sweet. moglbys sie podzielic swoim oszacowaniem, ile "wierszy" zajeloby to  
w Javie? :)

> Uzyłem NB6 jako środowiska i "programowania w ruby" pragmatycznych
> programmerów jako przewodnika. Moje doświadczenie to głównie java (razem  
> z
> ee) i perl.

ja tez sie przesiadlem z Javy na Ruby okolo rok temu, wiec moja droga byla  
podobna :)

> No i muszę przyznać, że jestem troszkę zawiedziony :) Być może tutejsi  
> spece
> odpowiedzą coś konstruktywnego na to co mi wyszło w trakcie...
>
> 1. środowisko - dużo słyszałem, że NB6 jest wspaniale jeśli chodzi o
> rubiego, sam używałem go do javy i byłem zadowolony a tutaj:
>  - podpowiedzi działają sensownie jedynie jeśli zmienna jest wcześniej
> przypisana do stałej albo do Klasa.new - niby rozumiem, że język  
> dynamiczny
> i można zwracać co się chce, ale... jakoś tak jak jestem w NB to
> przyzwyczajony jestem do tego, że w Javie podpowiedzi są 100%. Dla nowego
> programisty, który nie zna jeszcze API są one nieco mało pomocne...
> kiedy .add prezentuje mi listę 1000 klas, w których takowa meta się  
> pojawia

zapomnij o IDE (ja uzywalem Eclipse). najlepszy jest dobry, lekki edytor  
(w pracy uzywamy TextMate) plus porzadne srodowisko z linia polecen (czyli  
bash z odpowiednimi skrotami, aliasami itp.) im szybciej pozbedziesz sie  
naiwnej wiary, ze IDE jest Ci do czegos potrzebne w Rubym, tym lepiej :)

podpowiadanie metod - zapomnij o tym :) nie potrzebujesz tego.  
potrzebujesz tylko dobrego helpa z lista wszystkich metod (polecam  
gotapi.com) i odrobine doswiadczenia/intuicji, zeby wiedziec jak moze sie  
nazywac to, czego szukasz. poczatkujacemu moze byc z poczatku nieco  
trudno, ale nie sadze, zeby to bylo duzo gorsze od szukania metod w  
Javadoc :)

TextMate nie ma podpowiadania metod, za to ma cos znacznie  
przydatniejszego: dopelnianie kontekstowe (czy jak to sie nazywa, w vimie  
^P/^N). piszesz np. so, naciskasz Esc i wyskakuje Ci some_long_method czy  
co tam ostanio pisales. dziala to oczywiscie nie tylko dla metod, ale dla  
wszelkich nazw - klas, modulow, zmiennych, parametrow, symboli, stringow  
itp.

>  - debugger działa fatalnie (używałem "classic debugger" bo jakoś nie  
> bardzo
> byłem w stanie uruchomić "fast"), nie zatrzymuje się na ustawionych
> breakpointach a zatrzymuje się w nieokreslonych miejscach, czasami wogóle
> się gubi...

zapomnij o debuggerze :) w czasie roku pracy z Rubym nie uzylem go ani  
razu. testy, irb i p Twoimi przyjaciolmi. prawdziwymi przyjaciolmi.  
debugger nie jest Twoim przyjacielem. bedzie Ci wmawial ze jest, ale tak  
na prawde jest jak diler narkotykow :)

> 2. sam ruby
>  - jeszcze się nie przyzwyczaiłem do "kontroli typów bez określania  
> typów",
> dotychczas pisałem albo w Javie, gdzie wszystko jest precyzynie z góry
> określone, albo w perlu, gdzie właściwie nie ma typów...

w Rubym masz najlepsze z obu wymienionych: dynamic, strong typing. czyli  
jest dynamicznie, ale wszystko jest pilnowane. przyklad - jaki jest wynik  
wyrazenia: "2" + 1 w Javie? "21". a w Rubym leci wyjatek. wiec ktory jezyk  
ma silniejsza kontrole typow? :)

i znow: w czasie roku pracy z Rubym chyba nigdy nie zastanawialem sie  
"wlasciwie jakiego typu jest dany obiekt?". w 99% to albo jest oczywiste z  
kontekstu, albo nie ma znaczenia.

owszem, zdarzaja sie bledy polegajace na wywolaniu niewlasciwej metody na  
niewlasciwym obiekcie, ale wiesz jaki jest to najczesciej obiekt? nil  
oczywiscie. w Rubym nie ma NullPointerException (ktory jest chyba  
najczesciej spotykanym wyjatkiem w Javie), zamiast tego dostajesz wyjatek  
"NoMethodError: undefined method `metoda' for nil:NilClass".

>  - niektórych rzeczy nie czuję - czy modyfikowanie istniejących klas (np.
> String) przez dodawanie metod nie powoduje zbyt dużego zamętu? Czemu nie
> zrobić tego "normalnie", czyli odziedziczyć, rozszerzyć i używać jawnie
> zmodyfikowanej wersji? Przecież przekazując projekt komuś innemu wpędzimy
> go w nerwicę zanim się zorientuje, że przedefiniowaliśmy metodę '+' w
> bibliotecznej klasie String...

musisz pozbyc sie podejscia typowego dla javowcow, czyli "wszyscy  
programisci (poza mna) chca mi (i/lub sobie) zrobic krzywde". przestan tak  
myslec, a przestaniesz sie o to martwic. "w czasie roku pracy z Rubym"(TM)  
nie spotkalem sie z takim przypadkiem (tzn. zeby modyfikacje jakiejs klasy  
spowodowaly jakies wieksze problemy, ktorych nie wylapaly testy).

pzdr
	szeryf

-- 
Przemysław ,,Szeryf'' Kowalczyk :: http://szeryf.wordpress.com/

Przemysław Kowalczyk wrote:
> moglyby i w wiekszosci tak sie nazywaja. w tym przypadku skrewil autor
> biblioteki, nie jezyka :P
To pewnie prawda - ale poznając nowy język nie mogę oglądać go tylko z
erspektywy gołego języka, biblioteka standardowa i niestandardowa są co
najmniej równie istotne. Dawno temu kiedy w ramach takiego zapoznawania się
z .NET pisałem mały programik w C# byłem zachwycony - ale nie tym jak jst
zbudowany język, jak działa CLR itd. - po prostu biblioteka standardowa
zawierała akurat te funkcje, które były mi potrzebne - podczas gdy w Javie
często było tak, że klasa miała mnóstwo funkcji do niczego mi
niepotrzebnych, a akurat tej co potrzebowałem nikt nie zaimplementował :) 

pozdrawiam
-- 
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@fork.pl, gg:2532994
http://the.fork.pl

Jaroslaw Zabiello wrote:
> Teoretycznie tak, w praktyce mała na to szansa. Ruby pozwala na zamrożenie
> dowolnych obiektów. 

a to fajne, znaczy przynajmniej warto mieć świadomość, że w razie potrzeby
mam taką możliwość...
pozdrawiam
-- 
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@fork.pl, gg:2532994
http://the.fork.pl

Przemysław Kowalczyk wrote:
> SOAP - bleeee :)
kwestia gustu, jak chcę udostępnić metodę dla "szerokiej publiczności",
która ma aplikacje w j2ee tudzież w .NET to zapodaje im wsdl i już...
Może to nie takie zwięzłe jak zwykłe RPC/Corba ale akurat tutaj wydajność
nie jest istotna...

>> Wszystko razem niecałe 500 wierszy.
> sweet. moglbys sie podzielic swoim oszacowaniem, ile "wierszy" zajeloby to
> w Javie? :)

Obawiam się, że przy moim doświadczeniu to mniej więcej tyle samo jak nie
mniej ;) Prawde mówiąc połowa z tych 500 wierszy to kod (sprawdziłem - 260
kod, 100 wsdl, 50 szablon do maila, 30 konfiguracja).

W jednym i drugim języku wszystko mam gotowe (serwer http/soap gotowy,
parser konfiguracji gotowy, parser soap gotowy, dostęp do bazy gotowy,
logger gotowy, mailer gotowy) - jedyne autorskie elementy w kodzie to
walidacja, której nie byłem w stanie zrobić na poziomie XML-a...

> zapomnij o IDE (ja uzywalem Eclipse). najlepszy jest dobry, lekki edytor
> (w pracy uzywamy TextMate) plus porzadne srodowisko z linia polecen (czyli
> bash z odpowiednimi skrotami, aliasami itp.) im szybciej pozbedziesz sie
> naiwnej wiary, ze IDE jest Ci do czegos potrzebne w Rubym, tym lepiej :)
Prawdę mówiąc w aktualnych wersjach nie narzekam na ciężkość NB, ale
faktycznie sam zazwyczaj piszę w lekkim edytorze opartym na Kate-part z KDE
(szczególnie w perlu). Natomiast IDE używam ze względu na 
 - debugger (do dyskusji niżej ;) )
 - refactoring (tutaj odpada jak rozumiem)
 - podpowiedzi (tutaj odpada niestety)
 - ładne wsparcie dla subversion czego Kate nie ma

> podpowiadanie metod - zapomnij o tym :) nie potrzebujesz tego.
> potrzebujesz tylko dobrego helpa z lista wszystkich metod (polecam
> gotapi.com) 
trochę mi to wygląda na "nie możemy tego mieć to powtarzajmy wszyscy razem
głośno >>podpowiedzi są niepotrzebne<< - może uwierzymy" :) Biblioteka
standardowa JDK zawiera prawie 3500 klas, większości z nich nie uzywasz na
codzień - naprawdę jest to przyjemne jeśli nagle potrzbujesz użyć jakies
URLConnection i nie musisz szukać po dokumentacji czy metoda getHeaderField
bierze jako argument int czy String i co zwraca - bo po ctrl-spacja masz
przed nosem opis właśnie tej metody.

Nie mówie, że jest to niezbędne bo w perlu pracuję w oparci o podpowiedzi
oparte na wystąpieniach stringów w otwartch plikach (chyba to to samo o
czymi pisałeś w kontekście textmate) i też da się żyć :)

> zapomnij o debuggerze :) w czasie roku pracy z Rubym nie uzylem go ani
> razu. testy, irb i p Twoimi przyjaciolmi. prawdziwymi przyjaciolmi.
> debugger nie jest Twoim przyjacielem. bedzie Ci wmawial ze jest, ale tak
> na prawde jest jak diler narkotykow :)
eee... w czym ci zawiniły biedne debuggery, że masz o nich takie złe
zdanie? :)

> w Rubym masz najlepsze z obu wymienionych: dynamic, strong typing. czyli
> jest dynamicznie, ale wszystko jest pilnowane. przyklad - jaki jest wynik
> wyrazenia: "2" + 1 w Javie? "21". a w Rubym leci wyjatek. wiec ktory jezyk
> ma silniejsza kontrole typow? :)
Już chyba o tym pisałem - ale ja wcale nie jestem miłośnikiem Javy, a już
szczególnie po tym zamieszaniu, które pojawiło się w 1.5 (autoboxing i
okolice).

> i znow: w czasie roku pracy z Rubym chyba nigdy nie zastanawialem sie
> "wlasciwie jakiego typu jest dany obiekt?". w 99% to albo jest oczywiste z
> kontekstu, albo nie ma znaczenia.
A widzisz, ja się zastanawiałem, bo na przykład moja klasa serwera
dziedziczy z SOAP::RPC::HTTPServer, który ma jako parent
napisany "Logger::Application" - a faktycznie jest oparty na na Webricku. 
Dokumentacja konstruktora jest porażająca wręcz:
http://www.ruby-doc.org/core/classes/SOAP/RPC/HTTPServer.html
na szczęscie nie boję się czytać źródeł gdzie wypatrzyłem 
  def initialize(config)
    @webrick_config = config.dup
    @server = WEBrick::HTTPServer.new(@webrick_config)

> w Rubym nie ma NullPointerException (ktory jest chyba
> najczesciej spotykanym wyjatkiem w Javie), zamiast tego dostajesz wyjatek
> "NoMethodError: undefined method `metoda' for nil:NilClass".
To akurat jest całkiem fajne :) A już najbardziej mi się podoba z takich
bazowych rozwiązań, że fałsz to fałsz i nie ma nic wspólnego z 0 albo 1
(tak na marginesie).

> musisz pozbyc sie podejscia typowego dla javowcow, czyli "wszyscy
> programisci (poza mna) chca mi (i/lub sobie) zrobic krzywde". 
Na szczęście nie jestem typowym javowcem i robię też duże rzeczy w perlu
gdzie bez przerwy robimy sobie na wzajem krzywdy i nadal jest fajnie ;)

pozdrawiam
-- 
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@fork.pl, gg:2532994
http://the.fork.pl

Przemysław Kowalczyk pisze:
> zapomnij o debuggerze :) w czasie roku pracy z Rubym nie uzylem go ani 
> razu. testy, irb i p Twoimi przyjaciolmi. prawdziwymi przyjaciolmi. 
> debugger nie jest Twoim przyjacielem. bedzie Ci wmawial ze jest, ale tak 
> na prawde jest jak diler narkotykow :)

Debugger jak najbardziej się przydaje. Zwłaszcza w sytuacjach gdy dzieje 
się coś zupełnie niezrozumiałego (magia zaczyna brać górę w kodzie). 
Miałem takie sytuacje, że bez debuggera nie dostrzegłbym co jest grane. 
Nie wiem skąd się wzięło to hasło "nie potrzebujesz debuggera", ale 
spotkałem się już z nim wcześniej.

Debugger w NB działa dobrze, ja nie miałem z nim problemów.

-- 
Radosław Bułat
http://radarek.jogger.pl - mój blog

Jaroslaw Zabiello pisze:
> Dnia 16-05-2008 o 11:25:50 Marcin Gryszkalis <mg@fork.pl> napisał(a):
> 
>> Czy jeśli nagle metoda shuffle pojawi się w bibliotece standardowej to 
>> nie jest to
>> groźne dla istniejącego kodu?
> 
> Teoretycznie tak, w praktyce mała na to szansa. Ruby pozwala na 
> zamrożenie dowolnych obiektów. Wystrzeli wyjątkiem jak coś będzie 
> chciało grzebać w obiektach które zamrozisz (włącznie z tymi 
> wbudowanymi). To, plus automatyczne testy (co jest w zasadzie i tak 
> konieczne do pisania) powinno móc być w stanie wyłapać różne sytuacje.
> 

Z tym zamrażaniem to jest dla mnie mit. Spotkałem się może kilka razy 
gdy ktoś używał freeze, zwykle na zasadzie:

Stala = [1, 2, 3].freeze

(by nie zmodyfikować obiektu wskazywanego przez Stala)

Nie spotkałem się natomiast by ktoś zamrażał klasy, a już na pewno nie 
wbudowane (zupełnie bez sensu). A nawet jeśli zamrożę to jedyne co 
dostanę to wyjątek. Co jeśli jest on powodowany przez jakąś bibliotekę? 
Ok, niby lepsze to niż nic, ale jednak zamrożenie nie jest rozwiązaniem 
problemu "a co jeśli ktoś to zmodyfikuje, albo będzie kolizja nazw".

Istniejące klasy (nie nasze), zwłaszcza te wbudowane mimo wszystko 
powinniśmy zostawić w spokoju za wszelką cenę. Dopiero gdy stwierdzimy, 
że nie mamy innego wyjścia to można pomyśleć nad tym rozwiązaniem. Niby 
oczywiste, ale często jest to nadużywane (monkey-patching).

-- 
Radosław Bułat
http://radarek.jogger.pl - mój blog

On Sat, 17 May 2008 19:05:27 +0200, Marcin Gryszkalis <mg@fork.pl> wrote:
>
>> zapomnij o IDE (ja uzywalem Eclipse). najlepszy jest dobry, lekki edytor
>> (w pracy uzywamy TextMate) plus porzadne srodowisko z linia polecen  
>> (czyli
>> bash z odpowiednimi skrotami, aliasami itp.) im szybciej pozbedziesz sie
>> naiwnej wiary, ze IDE jest Ci do czegos potrzebne w Rubym, tym lepiej :)
> Prawdę mówiąc w aktualnych wersjach nie narzekam na ciężkość NB, ale
> faktycznie sam zazwyczaj piszę w lekkim edytorze opartym na Kate-part z  
> KDE
> (szczególnie w perlu). Natomiast IDE używam ze względu na
>  - debugger (do dyskusji niżej ;) )
>  - refactoring (tutaj odpada jak rozumiem)

dlaczego mialby odpadac? podstawowe rzeczy (rename method czy rename  
class) jestes w stanie zrobic dobrym edytorem. NB i Eclipse daja tez  
troche bardziej zaawansowane funkcje. rzeczy typu extract variable czy  
extract method mozna zrobic makrem w TextMate. w czym problem?

>  - podpowiedzi (tutaj odpada niestety)

ale, jak pisalem, sa inne mozliwosci. Ruby to nie Java i na prawde latwiej  
sie w nim polapac.

>  - ładne wsparcie dla subversion czego Kate nie ma

ale bash ma :) ja sobie porobilem aliasy na najczesciej uzywane funkcje i  
nie narzekam. z tego co wiem, koledzy z zespolu uzywaja tez obslugi SVN  
wbudowanej w Textmate.

w codziennej pracy uzywam 5 funkcji SVN: status, update, commit, add,  
remove. dodatkowo w Textmate od czasu do czasu: blame, diff, log. czy  
naprawde trzeba miec do tego jakies wodotryski?

>> podpowiadanie metod - zapomnij o tym :) nie potrzebujesz tego.
>> potrzebujesz tylko dobrego helpa z lista wszystkich metod (polecam
>> gotapi.com)
> trochę mi to wygląda na "nie możemy tego mieć to powtarzajmy wszyscy  
> razem
> głośno >>podpowiedzi są niepotrzebne<< - może uwierzymy" :)

nie, to brzmi jak: Ruby jest prostszy od Javy :)

> Biblioteka
> standardowa JDK zawiera prawie 3500 klas,

Ruby jest prostszy od Javy :)

> większości z nich nie uzywasz na
> codzień - naprawdę jest to przyjemne jeśli nagle potrzbujesz użyć jakies
> URLConnection i nie musisz szukać po dokumentacji czy metoda  
> getHeaderField
> bierze jako argument int czy String

"int czy String" to jest dokladnie 0 informacji. powinienes pytac, "co" ma  
byc argumentem (np. host albo nr portu), a nie "jakiego to jest typu". jak  
bedziesz wiedzial "co", to typ bedzie mniej lub bardziej oczywisty.

> i co zwraca

j/w

> - bo po ctrl-spacja masz
> przed nosem opis właśnie tej metody.

masz opis jak masz kod zrodlowy do jara podpiety w odpowiednim miejscu w  
IDE, a w nim javadoce. jak nie masz, to widzisz tylko typy. czyli jak  
pisalem wyzej, masz tylko tyle informacji, zeby zadowolic marudny  
kompilator. ale to jeszcze nie znaczy, ze program bedzie dzialal tak, jak  
bys chcial.

> Nie mówie, że jest to niezbędne bo w perlu pracuję w oparci o podpowiedzi
> oparte na wystąpieniach stringów w otwartch plikach (chyba to to samo o
> czymi pisałeś w kontekście textmate) i też da się żyć :)

no widzisz. IMHO czesto jest to lepsze, niz podpowiadanie metod w IDE, bo  
w kodzie czesto powtarzaja sie te same identyfikatory, i to nie tylko jako  
nazwy metod.

>> zapomnij o debuggerze :) w czasie roku pracy z Rubym nie uzylem go ani
>> razu. testy, irb i p Twoimi przyjaciolmi. prawdziwymi przyjaciolmi.
>> debugger nie jest Twoim przyjacielem. bedzie Ci wmawial ze jest, ale tak
>> na prawde jest jak diler narkotykow :)
> eee... w czym ci zawiniły biedne debuggery, że masz o nich takie złe
> zdanie? :)

mi w niczym, bo nigdy nie dalem sie uzaleznic :) ale jak czasem czytam, co  
inni wypisuja o debuggerach, to mam podejrzenie, ze sie uzaleznili.

dla mnie antidotum jest proste: testy jednostkowe, czytanie stacktrace'ow,  
prosty kod (nie za dlugie metody, nie za duzo zmiennych, nie  
kombinowanie), w ostatecznosci "p zmienna" i jazda. dobre pokrycie testami  
czesto zastepuje debugger, gdyz odpalajac jedna metode od razu wchodzisz  
do kodu, ktory chcesz sprawdzic. kilka prob z p i wiesz o co chodzi.

>> i znow: w czasie roku pracy z Rubym chyba nigdy nie zastanawialem sie
>> "wlasciwie jakiego typu jest dany obiekt?". w 99% to albo jest  
>> oczywiste z
>> kontekstu, albo nie ma znaczenia.
> A widzisz, ja się zastanawiałem, bo na przykład moja klasa serwera
> dziedziczy z SOAP::RPC::HTTPServer, który ma jako parent
> napisany "Logger::Application" - a faktycznie jest oparty na na Webricku.
> Dokumentacja konstruktora jest porażająca wręcz:
> http://www.ruby-doc.org/core/classes/SOAP/RPC/HTTPServer.html

no rzeczywiscie, dokumentacja do tej klasy jest fatalna. i to jeszcze jest  
klasa ze standardowej biblioteki, jezeli dobrze rozumiem? jak juz pisalem:  
SOAP - bleeee :)

> To akurat jest całkiem fajne :) A już najbardziej mi się podoba z takich
> bazowych rozwiązań, że fałsz to fałsz i nie ma nic wspólnego z 0 albo 1
> (tak na marginesie).

a wiekszosci sie nie podoba :) ale zawsze mozna sie pobawic w  
przedefiniowanie operatorow logicznych dla 0 :P

>> musisz pozbyc sie podejscia typowego dla javowcow, czyli "wszyscy
>> programisci (poza mna) chca mi (i/lub sobie) zrobic krzywde".
> Na szczęście nie jestem typowym javowcem i robię też duże rzeczy w perlu
> gdzie bez przerwy robimy sobie na wzajem krzywdy i nadal jest fajnie ;)

LOL

pzdr
	szeryf

-- 
Przemysław ,,Szeryf'' Kowalczyk :: http://szeryf.wordpress.com/

On Sat, 17 May 2008 23:12:32 +0200, Radosław Bułat <radarrek@poczta.fm>  
wrote:
>> zapomnij o debuggerze :) w czasie roku pracy z Rubym nie uzylem go ani  
>> razu. testy, irb i p Twoimi przyjaciolmi. prawdziwymi przyjaciolmi.  
>> debugger nie jest Twoim przyjacielem. bedzie Ci wmawial ze jest, ale  
>> tak na prawde jest jak diler narkotykow :)
>
> Debugger jak najbardziej się przydaje. Zwłaszcza w sytuacjach gdy dzieje  
> się coś zupełnie niezrozumiałego (magia zaczyna brać górę w kodzie).  
> Miałem takie sytuacje, że bez debuggera nie dostrzegłbym co jest grane.  
> Nie wiem skąd się wzięło to hasło "nie potrzebujesz debuggera", ale  
> spotkałem się już z nim wcześniej.

bo nie potrzebujesz :) nikt w moim zespole nie uzywa, a mimo to trzaskamy  
projekt za projektem :) oczywiscie, sa to niezbyt skomplikowane aplikacje  
webowe w RoR, wiec moze nie wiemy, co to Naprawde Zagmatwany Kod, ale IMHO  
tym lepiej dla nas :)

> Debugger w NB działa dobrze, ja nie miałem z nim problemów.

bomba :)

pzdr
	szeryf

-- 
Przemysław ,,Szeryf'' Kowalczyk :: http://szeryf.wordpress.com/

Przemysław Kowalczyk wrote:
>>  - refactoring (tutaj odpada jak rozumiem)
> dlaczego mialby odpadac? podstawowe rzeczy (rename method czy rename
> class) jestes w stanie zrobic dobrym edytorem. 
Możesz automatycznie zmienić nazwę metody, która nie jest unikalna względem
różnych klas? 


>>  - ładne wsparcie dla subversion czego Kate nie ma
> w codziennej pracy uzywam 5 funkcji SVN: status, update, commit, add,
> remove. dodatkowo w Textmate od czasu do czasu: blame, diff, log. czy
> naprawde trzeba miec do tego jakies wodotryski?
NB pokazuje mi linie zmienione i dodane (i w pewnym sensie usunięte też) w
danym pliku (w porównaniu z repozytorium) - i ja to lubię :) Na codzień
operacje na svn robię z ręki, bardziej zaawansowane z IDE albo ze SmartSVN.


>> trochę mi to wygląda na "nie możemy tego mieć to powtarzajmy wszyscy
>> razem głośno >>podpowiedzi są niepotrzebne<< - może uwierzymy" :)
> nie, to brzmi jak: Ruby jest prostszy od Javy :)
:)

>> Biblioteka
>> standardowa JDK zawiera prawie 3500 klas,
> Ruby jest prostszy od Javy :)
Myślę, że ilość klas w stdlib nie jest wyznacznikiem prostoty... 

>> większości z nich nie uzywasz na
>> codzień - naprawdę jest to przyjemne jeśli nagle potrzbujesz użyć jakies
>> URLConnection i nie musisz szukać po dokumentacji czy metoda
>> getHeaderField
>> bierze jako argument int czy String
> "int czy String" to jest dokladnie 0 informacji. powinienes pytac, "co" ma
> byc argumentem (np. host albo nr portu), a nie "jakiego to jest typu". jak
> bedziesz wiedzial "co", to typ bedzie mniej lub bardziej oczywisty.
Masz rację, co nie zmienia siły przykładu :)


>> - bo po ctrl-spacja masz
>> przed nosem opis właśnie tej metody.
> 
> masz opis jak masz kod zrodlowy do jara podpiety w odpowiednim miejscu w
> IDE, a w nim javadoce. jak nie masz, to widzisz tylko typy. czyli jak
> pisalem wyzej, masz tylko tyle informacji, zeby zadowolic marudny
> kompilator. ale to jeszcze nie znaczy, ze program bedzie dzialal tak, jak
> bys chcial.
To już kwestia ustawienia sobie środowiska, tak samo jak ustawiam sobie
odpowiednie czcionki, skróty klawiszowe do których jestem przyzwyczajony
itd. 

>> http://www.ruby-doc.org/core/classes/SOAP/RPC/HTTPServer.html
> no rzeczywiscie, dokumentacja do tej klasy jest fatalna. i to jeszcze jest
> klasa ze standardowej biblioteki, jezeli dobrze rozumiem? jak juz pisalem:
> SOAP - bleeee :)
fajnie masz, jak zawsze możesz pisać to co chcesz i tak jak chcesz :)

>> A już najbardziej mi się podoba z takich
>> bazowych rozwiązań, że fałsz to fałsz i nie ma nic wspólnego z 0 albo 1

> a wiekszosci sie nie podoba :) ale zawsze mozna sie pobawic w
> przedefiniowanie operatorow logicznych dla 0 :P

Ha, widzisz, pełna obiektowość to jest to co w/g mnie bardzo działa na plus
w porównaniu z javą, rozumiem skąd się wzięły typu prymitywne w javie ale i
tak uważam, że to jedna z najgorszych cech języka...

pozdrawiam
-- 
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@fork.pl, gg:2532994
http://the.fork.pl

Przemysław Kowalczyk wrote:

> On Fri, 16 May 2008 00:14:22 +0200, Marcin Gryszkalis <mg@fork.pl> wrote:
>> 1. środowisko - dużo słyszałem, że NB6 jest wspaniale jeśli chodzi o
>> rubiego, sam używałem go do javy i byłem zadowolony a tutaj:
>>  - podpowiedzi działają sensownie jedynie jeśli zmienna jest wcześniej
>> przypisana do stałej albo do Klasa.new - niby rozumiem, że język
>> dynamiczny
>> i można zwracać co się chce, ale... jakoś tak jak jestem w NB to
>> przyzwyczajony jestem do tego, że w Javie podpowiedzi są 100%. Dla nowego
>> programisty, który nie zna jeszcze API są one nieco mało pomocne...
>> kiedy .add prezentuje mi listę 1000 klas, w których takowa meta się
>> pojawia
> 
> zapomnij o IDE (ja uzywalem Eclipse). 

jakbym "musiał" używać Eclipse, to też bym szybko chciał zapomnieć o tym
traumatycznym przeżyciu ;P Jego edytor jest tragiczny...

> najlepszy jest dobry, lekki edytor 
> (w pracy uzywamy TextMate) plus porzadne srodowisko z linia polecen (czyli
> bash z odpowiednimi skrotami, aliasami itp.) im szybciej pozbedziesz sie
> naiwnej wiary, ze IDE jest Ci do czegos potrzebne w Rubym, tym lepiej :)

Używałem w życiu nedit, vim, jedit (ten ostatni baaardzo długo) a obecnie NB
6.1 i uważam, że nie masz racji - porządne IDE z porządnym edytorem (a taki
posiada NB) daje bardzo wiele.

> podpowiadanie metod - zapomnij o tym :) nie potrzebujesz tego.

przydaje się...

[...]
 
> TextMate nie ma podpowiadania metod, za to ma cos znacznie
> przydatniejszego: dopelnianie kontekstowe (czy jak to sie nazywa, w vimie
> ^P/^N). piszesz np. so, naciskasz Esc i wyskakuje Ci some_long_method czy
> co tam ostanio pisales. dziala to oczywiscie nie tylko dla metod, ale dla
> wszelkich nazw - klas, modulow, zmiennych, parametrow, symboli, stringow
> itp.

Ma to również NB (jEdit zresztą też)

> 
>>  - debugger działa fatalnie (używałem "classic debugger" bo jakoś nie
>> bardzo
>> byłem w stanie uruchomić "fast"), nie zatrzymuje się na ustawionych
>> breakpointach a zatrzymuje się w nieokreslonych miejscach, czasami wogóle
>> się gubi...
> 
> zapomnij o debuggerze :) w czasie roku pracy z Rubym nie uzylem go ani
> razu. testy, irb i p Twoimi przyjaciolmi. prawdziwymi przyjaciolmi.
> debugger nie jest Twoim przyjacielem. bedzie Ci wmawial ze jest, ale tak
> na prawde jest jak diler narkotykow :)

To, że Ty go nie użyłeś zupełnie nie oznacza, że się nie przydaje.
Parafrazując "Misia" - mnie się przydaje i co mi Pan zrobi :]


-- 
[ Piotr 'piter' Hlawski ( <phlawski$gmail,com> ) ( GG: 4534287 ) ]

On Mon, 19 May 2008 08:01:31 +0200, Piotr 'piter' Hlawski  
<phlawski@cut_this_crap.gmail.com> wrote:
>
>> najlepszy jest dobry, lekki edytor
>> (w pracy uzywamy TextMate) plus porzadne srodowisko z linia polecen  
>> (czyli
>> bash z odpowiednimi skrotami, aliasami itp.) im szybciej pozbedziesz sie
>> naiwnej wiary, ze IDE jest Ci do czegos potrzebne w Rubym, tym lepiej :)
>
> Używałem w życiu nedit, vim, jedit (ten ostatni baaardzo długo) a  
> obecnie NB
> 6.1 i uważam, że nie masz racji - porządne IDE z porządnym edytorem (a  
> taki
> posiada NB) daje bardzo wiele.

primo: nie pisalem, ze nic nie daje
secundo: nic nie przebije TextMate :)

>> podpowiadanie metod - zapomnij o tym :) nie potrzebujesz tego.
>
> przydaje się...

miedzy "przydaje sie" a "jest niezbedne" jest dokladnie taka sama roznica,  
jak miedzy "Ruby" a "Java"

>>>  - debugger działa fatalnie (używałem "classic debugger" bo jakoś nie
>>> bardzo
>>> byłem w stanie uruchomić "fast"), nie zatrzymuje się na ustawionych
>>> breakpointach a zatrzymuje się w nieokreslonych miejscach, czasami  
>>> wogóle
>>> się gubi...
>>
>> zapomnij o debuggerze :) w czasie roku pracy z Rubym nie uzylem go ani
>> razu. testy, irb i p Twoimi przyjaciolmi. prawdziwymi przyjaciolmi.
>> debugger nie jest Twoim przyjacielem. bedzie Ci wmawial ze jest, ale tak
>> na prawde jest jak diler narkotykow :)
>
> To, że Ty go nie użyłeś zupełnie nie oznacza, że się nie przydaje.
> Parafrazując "Misia" - mnie się przydaje i co mi Pan zrobi :]

jak wyzej. nie twierdze, ze sie nie przydaje. komus czasem na pewno sie  
przydaje. ale nie jest niezbedne, jak w Javie.

Java to jezyk uzalezniony od narzedzi. do Javy _niezbedne_ jest wypasione  
IDE z podpowiadaniem metod i generowaniem skladni, bo normalny programista  
nie jest w stanie tej przegadanej skladni wklepac z palca bezblednie. tak  
samo _niezbedny_ jest debugger, bo jak czlowiek musi napisac 30 linii kodu  
zamiast 3, to jest 10x wieksze prawdopodobienstwo bledu i 10x trudniej go  
znalezc po prostu patrzac w kod.

kto twierdzi inaczej, niech sprobuje napisac jakis nietrywialny program w  
Javie np. w notatniku. zobaczymy, czy da rade napisac wiecej niz 2 ekrany  
zanim sobie odgryzie rece :)

w Rubym te narzedzia nie sa niezbedne. sa _przydatne_, ale nie  
_niezbedne_. sa zespoly, ktore sie bez nich obywaja, a mimo to maja  
swietna efektywnosc. i tylko tyle chcialem powiedziec w tym watku.

pzdr
	szeryf

-- 
Przemysław ,,Szeryf'' Kowalczyk :: http://szeryf.wordpress.com/

On Mon, 19 May 2008 00:12:18 +0200, Marcin Gryszkalis <mg@fork.pl> wrote:
>>>  - refactoring (tutaj odpada jak rozumiem)
>> dlaczego mialby odpadac? podstawowe rzeczy (rename method czy rename
>> class) jestes w stanie zrobic dobrym edytorem.
> Możesz automatycznie zmienić nazwę metody, która nie jest unikalna  
> względem
> różnych klas?

a jak czesto nazywasz metody swoich klas 'f1' albo 'f2'? bo taki jest  
chyba najczesciej spotykany przyklad na 'niemoznosc' refactoringu w  
jezykach dynamicznych.

ja uzywam takich nazw, ktore _zazwyczaj_ sa unikalne. i _zazwyczaj_ nie  
mam problemow przy refactoringu. a tam gdzie mam, wykrywaja mi to testy.

refactoring jako idea narodzil sie w Smalltalku. jeszcze jakies pytania? :)

>>>  - ładne wsparcie dla subversion czego Kate nie ma
>> w codziennej pracy uzywam 5 funkcji SVN: status, update, commit, add,
>> remove. dodatkowo w Textmate od czasu do czasu: blame, diff, log. czy
>> naprawde trzeba miec do tego jakies wodotryski?
> NB pokazuje mi linie zmienione i dodane (i w pewnym sensie usunięte też)  
> w
> danym pliku (w porównaniu z repozytorium) - i ja to lubię :) Na codzień
> operacje na svn robię z ręki, bardziej zaawansowane z IDE albo ze  
> SmartSVN.

no widzisz, czyli jednak IDE nie jest niezbedne? TextMate tez pokazuje  
diffa calkiem sensownie.

>>> Biblioteka
>>> standardowa JDK zawiera prawie 3500 klas,
>> Ruby jest prostszy od Javy :)
> Myślę, że ilość klas w stdlib nie jest wyznacznikiem prostoty...

a ja mysle, ze jest. co wiecej, jest to dla mnie oczywiste :)

>>> większości z nich nie uzywasz na
>>> codzień - naprawdę jest to przyjemne jeśli nagle potrzbujesz użyć  
>>> jakies
>>> URLConnection i nie musisz szukać po dokumentacji czy metoda
>>> getHeaderField
>>> bierze jako argument int czy String
>> "int czy String" to jest dokladnie 0 informacji. powinienes pytac, "co"  
>> ma
>> byc argumentem (np. host albo nr portu), a nie "jakiego to jest typu".  
>> jak
>> bedziesz wiedzial "co", to typ bedzie mniej lub bardziej oczywisty.
> Masz rację, co nie zmienia siły przykładu :)

jak to nie? moim skromnym zdaniem to ten przyklad obala :)

>>> - bo po ctrl-spacja masz
>>> przed nosem opis właśnie tej metody.
>>
>> masz opis jak masz kod zrodlowy do jara podpiety w odpowiednim miejscu w
>> IDE, a w nim javadoce. jak nie masz, to widzisz tylko typy. czyli jak
>> pisalem wyzej, masz tylko tyle informacji, zeby zadowolic marudny
>> kompilator. ale to jeszcze nie znaczy, ze program bedzie dzialal tak,  
>> jak
>> bys chcial.
> To już kwestia ustawienia sobie środowiska,

nie tylko srodowiska, bo jak masz jara bez zrodel i javadocow (spotkalem  
sie z kilkoma takimi), to srodowisko nic nie pomoze.

>>> http://www.ruby-doc.org/core/classes/SOAP/RPC/HTTPServer.html
>> no rzeczywiscie, dokumentacja do tej klasy jest fatalna. i to jeszcze  
>> jest
>> klasa ze standardowej biblioteki, jezeli dobrze rozumiem? jak juz  
>> pisalem:
>> SOAP - bleeee :)
> fajnie masz, jak zawsze możesz pisać to co chcesz i tak jak chcesz :)

no nie zawsze, ale SOAPa bym unikal. na szczescie wsrod klientow jest moda  
raczej na RESTful webservices, a to Rails daje praktycznie z paczki.

> Ha, widzisz, pełna obiektowość to jest to co w/g mnie bardzo działa na  
> plus
> w porównaniu z javą, rozumiem skąd się wzięły typu prymitywne w javie  
> ale i
> tak uważam, że to jedna z najgorszych cech języka...

amen :)

pzdr
	szeryf


-- 
Przemysław ,,Szeryf'' Kowalczyk :: http://szeryf.wordpress.com/

Przemysław Kowalczyk wrote:
>> Możesz automatycznie zmienić nazwę metody, która nie jest unikalna
>> względem różnych klas?
> 
> a jak czesto nazywasz metody swoich klas 'f1' albo 'f2'? bo taki jest
> chyba najczesciej spotykany przyklad na 'niemoznosc' refactoringu w
> jezykach dynamicznych.

f1 nie, ale metody zazwyczaj pochodzą od angielskich słów typu add, save,
commit czy process - takie nazwy bywaja nieunikalne...

>> Myślę, że ilość klas w stdlib nie jest wyznacznikiem prostoty...
> a ja mysle, ze jest. co wiecej, jest to dla mnie oczywiste :)
To mi wytłumacz, jeśli np. jdk wspiera obsługę musyki i urządzeń midi no to
ma klasy MidiEvent, MidiFileReader itd. To że ruby w standardzie nie
wspiera midi to znaczy, że jest prostszy?

pozdrawiam
-- 
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@fork.pl, gg:2532994
http://the.fork.pl

On Tue, 20 May 2008 12:15:36 +0200, Marcin Gryszkalis <mg@fork.pl> wrote:
>>> Możesz automatycznie zmienić nazwę metody, która nie jest unikalna
>>> względem różnych klas?
>>
>> a jak czesto nazywasz metody swoich klas 'f1' albo 'f2'? bo taki jest
>> chyba najczesciej spotykany przyklad na 'niemoznosc' refactoringu w
>> jezykach dynamicznych.
>
> f1 nie, ale metody zazwyczaj pochodzą od angielskich słów typu add, save,
> commit czy process - takie nazwy bywaja nieunikalne...

no oczywiscie, w niektorych paskudnych przypadkach refactoring sie nie  
powiedzie, nie twierdze ze nie. dlatego warto miec w zanadrzu dobry zestaw  
testow.

>>> Myślę, że ilość klas w stdlib nie jest wyznacznikiem prostoty...
>> a ja mysle, ze jest. co wiecej, jest to dla mnie oczywiste :)
> To mi wytłumacz, jeśli np. jdk wspiera obsługę musyki i urządzeń midi no  
> to
> ma klasy MidiEvent, MidiFileReader itd. To że ruby w standardzie nie
> wspiera midi to znaczy, że jest prostszy?

dokladnie tak! nie wiem, jaka masz definicje prostoty, ale dla mnie to  
jest wlasnie to. jezeli cos ma mniej funkcji, mniej czesci skladowych,  
jest latwiejsze, wymaga mniej czasu do nauki, to jest wlasnie prostsze.

pzdr
	szeryf

-- 
Przemysław ,,Szeryf'' Kowalczyk :: http://szeryf.wordpress.com/