🚀 go-pugleaf

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