Ruby: Kötü Bölümler [kapalı]

Son zamanlarda Crockford'un "Javascript: The Good Parts" kitabını okudum ve temel alanlardan biri, programlama dillerinin programcıların kaçınması gereken kötü özelliklere sahip olabilmesiydi.

Ben bir Rubyistim ve dili sevsem de perspektif kazanmanın her zaman değeri var. Peki, Ruby'deki en kötü özellik (ör. Yöntemler, sınıflar, uygulamalar) olarak ne görüyorsunuz? Buradaki amacım, dilin kendisinin esası ya da hızı vb. Hakkında bir tartışma başlatmak değil. Daha ziyade, geçmiş deneyimlere dayanarak, tehlikeli / zahmetli / acı verici olarak düşündüğünüz özellikleri tartışmayı tercih ederim.

Gary Bernhardt - Python vs Ruby: Ölümüne Bir Savaş izle Alıntı yapıyor:

Ruby'de çirkin bulduğum şey, RSpec gibi şaşırtıcı Ruby yazılımını mümkün kılan şeydir ve Python'un (mevcut uygulama göz önüne alındığında) asla sahip olamayacağı şeydir.

Özellikle Python hakkında çok konuşurken, Ruby'de sadece garip olan birçok şeye dokunuyor. Büyük kapsayıcı konulardan biri maymun yamasıdır .

Yakut nesneler (diğer nesne yönelimli dillerdeki nesnelerin aksine) ayrı ayrı değiştirilebilir. Her zaman nesne başına yöntem ekleyebilirsiniz. Ruby'de, bir nesnenin davranışı veya yetenekleri kendi sınıfı tarafından sağlananlardan farklı olabilir.

Bu, çok fazla esneklik sağlar ve Ruby'nin en popüler ve karmaşık taşlarından bazılarına güç sağlarken, bir yerlerde bir kütüphanenin çekirdek bir yöntemi değiştirdiğini fark etmeden bir sorunu ayıklamaya çalışıyorsanız, sizi popoda ısırır.

Bazı insanlar yakutu raylar üzerinde yakut olarak düşünür ve bu biraz sinir bozucu çünkü dil kendi başına iyi duruyor.

Bence en kötü özellik, open classesdeğişen sınıfın tüm mevcut ve gelecekteki örneklerinin davranışını küresel olarak değiştirmenize izin vermesidir.

Bu özelliğin sorunlu kısmı, Ruby yorumlayıcısı tanımla karşılaştığında bu çalışma sırasında (global) değişikliklerin meydana gelmesidir; bu, davranışlarını aniden değiştiren birkaç nesneyi zaten başlatmanızdan çok sonra olabilir.

Büyük bir kod tabanında bu, hataların bulunması çok, çok zor olabilir - özellikle de Ruby'nin zayıflığıyla (örneğin CLR veya JVM ile karşılaştırıldığında) hata ayıklama hikayesi ve evalbu bağlamda diğer özelliklerin (örneğin ) kullanılması bu küresel değişimin gerçekleştiği yeri bulmak oldukça zor. yani 'doğru' sınıfın soruna neden olduğundan şüphelendiğiniz noktaya ulaştıysanız! Deneyimlerime göre, sorunlar gerçek suçluyu kullanarak bir nesnede ortaya çıkmaya başladığı için genellikle vahşi bir kaz kovalamacıyla başlarsınız.

Bu yüzden en iyi şey, ya açık sınıfları kullanmayı bırakmak ( #extendve değişiklikleri a koymak ModuleIMHO'yu çok daha güvenli, anlaşılması daha kolay ve test edilmesi daha iyi olacaktır) ya da bundan kaçınılamıyorsa:

• yalnızca yeni davranışa sahip sınıfları genişlet (yani mevcut davranışı geçersiz kılmamak)
• kaynak kod ağacında, açık sınıfları kullanan tüm uzantıların yerleştirilmesi gereken tanımlanmış bir yere sahip olmak
• #evalaçık sınıflar oluşturmak için ve arkadaşlarını kullanmayın
• açık sınıfların tüm kullanımlarını, tüm geliştiricilerin görebileceği büyük bir görünür grafiğe koyun - ve bunlarda yapılacak herhangi bir değişikliğin, hızlı saldırıların yeri değil, tüm kod tabanını (yaptıkları) etkileyen 'mimari kararlar' olduğunu açıkça belirtin mevcut göreviniz için

Ruby'yi kullanmamamın en büyük nedeni: Buzul çağında Ocak ayında Kuzey Kutbu'ndaki pekmezden daha yavaş . Karşılaştırma dilleri tam olmayan bir bilimdir, ancak Ruby, JavaScript ve Python'dan bile çok daha yavaş görünür.

Bu, Ruby on Rails'e genişletilebilirse, o zaman:

1. Veritabanı mantığının her tabloya auto_increment, bunlara ihtiyaç duymayan ve bunlara sahip olmaması gereken tablolar da dahil olmak üzere birincil anahtar sağlaması.

2. Bileşik anahtarların hiç desteklenmemesi.

Sadece sade Ruby için benim tutkum ifade güvenliği için her dil ile aynı olurdu; küçük bir kodla çok şey yapmak kolaydır, ancak herhangi bir miktarda kodla büyük bir karmaşa yapmak kolaydır.

Ruby meta programlamayı (yansıma, içgözlem), çoklu paradigma programlamayı ve dinamizmi nadir bir düzeyde kucaklar. Güç ve esneklikle ayağınıza ateş etmek kolaydır.

Zahmetli? Ruby son derece okunabilir veya anlaşılmaz olabilir. Bash betiğine ait gibi görünen bir kod gördüm.

Kötü Uygulamalar? Bazı Rubyist bilgelik üzerinde zekâya değer verir. Akıllılıklarını gösteren püf noktaları yazarlar ve paylaşırlar, ancak bu okunamayan ve kırılgan kodlar yaratır.

Bir kenara: Javascript tasarım açısından bir felaketti ve "İyi Parçalar" kitabı gizli güzelliğini çıkarmaya çalışıyor. "Bunu Yapmanın Birden Fazla Yolu Var" (yani esneklik) popülerliğini taşıyan Perl, "Perl, En İyi Uygulamalar" da benzer bir kitaba sahiptir. Perl'in tarihi bir deney ve zor kazanılmış deneyimlerden biridir, "En İyi Uygulamalar" bilgisini temsil eder. Perl 6, bence söylemek gerekirse, bu bilgiye ve daha fazlasına dayanan bir dilin yeniden başlatılması adil olacak. Ruby benzer sorunlardan muzdarip olabilir.

@James ve döngüler için ... Ruby'de bir for döngüsü yaptığınızda ".each" olarak adlandırılır. Bu nedenle, "for" C tarzı döngülerden daha rahat insanlar için sözdizimsel şekerdir. Ancak bir Rubyist olarak, her zaman .map, .inject, .each_with_object gibi yineleyicileri kullanacaksınız. Asla yakutta "i = 0; i> 6; i ++" gibi bir şey için bir for döngüsü yazmak zorunda kalmazsınız ve böylece alışkanlığı düşürürsünüz. @andrew ... etkili yakut döngüler için onay vermez.

Bu programcılar hakkında dilden çok daha fazlası, ama Ruby programcıları döngüler için neden bu kadar nefret ediyorlar?

Ruby'nin:

someCollection.each do |item|
   ...
end

ancak for döngüsünün tamamen aynı şeyi yapmayacağı durumlarda kullanıldığını hiç görmedim.

Birkaç kez sordum ve buna iyi bir cevap alamadım.

Sadece stil bir şeyse, bunu kabul etmekten mutluluk duyuyorum, ama Ruby programcılarının bu konuda gerçekten işe yaradığını gördüm ve gerçekten merak ediyorum.

Genellikle eklenen dillerden diğer dillerle geriye dönük olarak uyumlu olmaktan kaçınırım. Örneğin, Perlisms ve for x in y.