Ruby: The Bad Parts [zamknięte]

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.

Powinieneś obejrzeć Python vs Ruby: A Battle to The Death w reżyserii Gary'ego Bernhardta. Robi cytat:

To, co uważam za brzydkie w Rubim, sprawia, że ​​niesamowite oprogramowanie Ruby, takie jak RSpec, jest możliwe i którego Python nigdy nie mógłby mieć (biorąc pod uwagę bieżącą implementację).

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 .

Obiekty Ruby (w przeciwieństwie do obiektów w niektórych innych językach obiektowych) mogą być indywidualnie modyfikowane. Zawsze możesz dodawać metody dla poszczególnych obiektów. W Rubim zachowanie lub możliwości obiektu mogą różnić się od tych dostarczonych przez jego klasę.

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ę.

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.

Myślę, że najgorszą funkcją jest open classesglobalna 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 ( #extenda umieszczenie zmian w ModuleIMHO jest znacznie bezpieczniejsze, łatwiejsze do zrozumienia i lepiej przetestować) lub jeśli nie można tego uniknąć:

• rozszerzaj klasy tylko o nowe zachowanie (tzn. nie zastępuj istniejącego zachowania)
• mają określone miejsce w drzewie kodu źródłowego, w którym należy umieścić wszystkie rozszerzenia korzystające z klas otwartych
• nie używaj #evali znajomych do tworzenia otwartych zajęć
• umieść wszystkie zastosowania klas otwartych na dużym widocznym wykresie, na którym wszyscy programiści mogą je zobaczyć - i wyjaśnij, że wszelkie zmiany na nich są „decyzjami architektonicznymi” wpływającymi na całą bazę kodu (co robią), a nie miejsce na szybkie hacki przydatne do bieżącego zadania

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.

Jeśli można to rozszerzyć na Ruby on Rails, to:

1. Fakt, że logika bazy danych nadaje każdej tabeli auto_incrementpodstawowy klucz, w tym tabele, które ich nie potrzebują i nie powinny ich mieć.

2. 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.

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.

Chodzi bardziej o programistów niż język, ale dlaczego programiści Ruby tak bardzo nienawidzą pętli?

Zdaję sobie sprawę, że Ruby:

someCollection.each do |item|
   ...
end

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.

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.