🚀 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 ) ]