Niedawno przeczytałem książkę Crockforda „JavaScript: dobre części”, a jedną z podstawowych przesłanek było to, że języki programowania mogą mieć złe zestawy funkcji, których programiści powinni unikać.
Jestem rubinistą i choć uwielbiam język, zawsze warto mieć perspektywę. Więc co uważasz za najgorszą funkcję (np. Metody, ćwiczenia, praktyki) w Rubim? Nie zamierzam tutaj spierać się o zalety samego języka lub jego szybkości i tak dalej. Wolałbym raczej dyskusję o tym, jakie funkcje uważasz za niebezpieczne / kłopotliwe / bolesne w użyciu, w oparciu o wcześniejsze doświadczenia.
Odpowiedzi:
Powinieneś obejrzeć Python vs Ruby: A Battle to The Death w reżyserii Gary'ego Bernhardta. Robi cytat:
Podczas gdy dużo mówi w szczególności o Pythonie, dotyka wielu rzeczy, które są po prostu dziwne w Ruby. Jednym z głównych tematów jest łatanie małp .
Chociaż zapewnia to dużą elastyczność i moc niektórych najpopularniejszych i najbardziej skomplikowanych klejnotów Ruby, może ugryźć cię w tyłek, jeśli próbujesz debugować problem, nie zdając sobie sprawy, że jakaś biblioteka gdzieś zmodyfikowała podstawową metodę.
źródło
Niektórzy ludzie myślą o ruby tylko w kategoriach rubinu na szynach i jest to trochę denerwujące, ponieważ język radzi sobie całkiem dobrze.
źródło
Myślę, że najgorszą funkcją jest
open classes
globalna zmiana zachowania wszystkich obecnych i przyszłych instancji zmienionej klasy.Problematyczną częścią tej funkcji jest to, że tezy (globalne) zachodzą w czasie wykonywania, gdy interpreter języka Ruby natrafi na definicję, co może potrwać długo po utworzeniu instancji kilku obiektów, które nagle zmieniają swoje zachowanie.
W dużej bazie kodu może to prowadzić do bardzo, bardzo trudnych do znalezienia błędów - zwłaszcza, że pogarsza to słaba (w porównaniu np. CLR lub JVM) historia debugowania i użycie innych funkcji (np.
eval
) W tym kontekście może sprawić, że trudno jest znaleźć lokalizację, w której nastąpiła ta globalna zmiana. tzn. jeśli osiągnąłeś już punkt, w którym podejrzewasz, że „właściwa” klasa powoduje problemy! Z mojego doświadczenia wynika, że zwykle zaczynasz od pogoni za gęsią skórką, ponieważ problemy zaczynają pojawiać się na obiekcie przy użyciu prawdziwego winowajcy.Najlepszą rzeczą byłoby zatem zaprzestanie korzystania z otwartych klas (
#extend
a umieszczenie zmian wModule
IMHO jest znacznie bezpieczniejsze, łatwiejsze do zrozumienia i lepiej przetestować) lub jeśli nie można tego uniknąć:#eval
i znajomych do tworzenia otwartych zajęćźródło
Największy powód, dla którego nie używam Ruby: Jest wolniejszy niż melasa w styczniu na biegunie północnym podczas epoki lodowcowej. Języki testów porównawczych są niedokładną nauką, ale Ruby wydaje się znacznie wolniejsza niż nawet JavaScript i Python.
źródło
Jeśli można to rozszerzyć na Ruby on Rails, to:
Fakt, że logika bazy danych nadaje każdej tabeli
auto_increment
podstawowy klucz, w tym tabele, które ich nie potrzebują i nie powinny ich mieć.Fakt, że klucze złożone nie są w ogóle obsługiwane.
Dla zwykłego Ruby mój problem byłby taki sam jak dla każdego języka, który zamienia bezpieczeństwo na ekspresję; łatwo jest zrobić wiele za pomocą małego kodu, ale równie łatwo jest zrobić wielki bałagan przy dowolnej ilości kodu.
źródło
auto_increment
identyfikator, a zwłaszcza dołączanie do tabel w relacjach has_and_belongs_to_many sugeruje się, aby jawnie NIE miały kolumny identyfikatora.Ruby obejmuje metaprogramowanie (refleksja, introspekcja), programowanie z wieloma paradygmatami i dynamikę na niespotykanym poziomie. Łatwo jest strzelać w stopę dzięki sile i elastyczności.
Kłopotliwy? Ruby może być wyjątkowo czytelny lub niezniszczalny. Widziałem kod, który wygląda, jakby należał do skryptu Bash.
Złe praktyki? Niektórzy rubiści cenią spryt nad mądrością. Piszą i dzielą się sztuczkami, które pokazują ich spryt, ale tworzy to nieczytelny i delikatny kod.
Nawiasem mówiąc: Javascript był z założenia katastrofą, a książka „The Good Parts” próbuje wydobyć ukryte piękno. Perl, język, który spopularyzował „Jest więcej niż jeden sposób na to” (czyli elastyczność), ma podobną książkę w „Perl, Best Practices”. Historia Perla to historia eksperymentów i ciężko zdobytych doświadczeń. „Najlepsze praktyki” reprezentują jej wiedzę. Perl 6 będzie, jak sądzę, uczciwym powiedzeniem, restartem języka opartym na tej wiedzy i nie tylko. Ruby może cierpieć z powodu podobnych problemów.
@James i pętle ... Kiedy robisz pętlę for w ruby, wówczas wywołuje „.each”. Dlatego „for” to cukier składniowy dla osób bardziej komfortowych z pętlami w stylu C. Ale jako Rubyista będziesz przez cały czas używać iteratorów takich jak .map, .inject, .each_with_object. Nigdy nie będziesz musiał pisać pętli for z czymś takim jak „i = 0; i> 6; i ++” w ruby, więc w końcu porzucisz nawyk. @ andrew ... elokwentny rubin nie popiera pętli.
źródło
Chodzi bardziej o programistów niż język, ale dlaczego programiści Ruby tak bardzo nienawidzą pętli?
Zdaję sobie sprawę, że Ruby:
ale nigdy nie widziałem tego używanego w sytuacjach, w których pętla for nie zrobiłaby dokładnie tego samego.
Pytałem kilka razy i nigdy nie uzyskałem dobrej odpowiedzi na to pytanie.
Jeśli jest to tylko styl, cieszę się, że to akceptuję, ale widziałem, jak programiści Ruby naprawdę się tym zajęli i jestem naprawdę ciekawy.
źródło
for
pętli jest czymś, co robi n00bs. Ludzie, którzy programują C w Ruby. 2) Bloki są często używane w Ruby, więc używanie czegoś, co nie jest podobne do bloku, to tylko dodatkowy wysiłek umysłowy.Generalnie unikałbym rzeczy, które zostały dodane tylko po to, by były kompatybilne wstecz z innymi językami. Na przykład Perlizmy i
for x in y
.źródło