Ruby: Bagian Buruk [ditutup]


20

Saya baru-baru ini membaca buku Crockford "Javascript: The Good Parts" dan salah satu dasar yang mendasari adalah bahwa bahasa pemrograman dapat memiliki set fitur yang buruk yang harus dihindari oleh programmer.

Saya seorang Rubyist dan sementara saya suka bahasa selalu ada nilai dalam mendapatkan perspektif. Jadi, apa yang Anda lihat sebagai fitur terburuk (misalnya metode, kelas, praktik) di Ruby? Maksud saya di sini bukan untuk memulai argumen tentang manfaat bahasa itu sendiri atau kecepatannya dan sebagainya. Sebaliknya saya lebih suka diskusi tentang fitur apa yang Anda anggap berbahaya / merepotkan / menyakitkan untuk digunakan, berdasarkan pengalaman masa lalu.


1
Saya tidak pernah menjadi penggemar harus menggunakan kata "akhir", dan kemudian campuran itu dengan "{" dan "}" menjadi lebih menyebalkan. Itu membuat saya menghargai sintaks gaya Python atau langsung {&}. Meskipun orang bisa bolak-balik tentang hal ini, dan pada akhirnya itu ada hubungannya dengan preferensi pribadi. Saya mendengar seseorang berkata bahwa Ruby mengambil bagian Python dan Perl yang paling jelek dan menyatukannya. Saya menikmati belajar Ruby.

Saya sebenarnya cukup menyukai pertanyaan ini dan akan menantikan jawaban, tetapi tetap memilih untuk menutupnya. Saya tidak berpikir itu cocok untuk Stack Overflow (karena berpotensi terlalu subyektif / argumentatif, terbuka, dll).
stakx

Saya pikir ini layak untuk dibahas karena dapat menerangi praktik berbahaya yang harus dihindari. Saya melihat maksud Anda dan mengedit pertanyaannya menjadi lebih sempit.

9
Saya tidak melihat bagaimana pertanyaan ini cukup berbeda, misalnya Apa hal yang ingin Anda tingkatkan dalam bahasa Ruby? , Apa itu Ruby Gotcha yang harus diingatkan oleh seorang pemula? , Apa masalah dunia nyata dengan Ruby? atau salah satu pertanyaan trilyun lainnya tentang poin rasa sakit Ruby. Plus, bahkan jika pertanyaan ini dikembangkan untuk membedakan dirinya dari yang lain, itu akan menjadi milik Programmer.SE , bukan StackOverflow.
Jörg W Mittag

2
Saya perlu memeriksakan mata saya - saya pikir judul pertanyaan ini adalah "Ruby: The Brad Pitts".
oosterwal

Jawaban:


8

Anda harus menonton Python vs Ruby: A Battle to The Death oleh Gary Bernhardt. Dia membuat kutipan:

Hal-hal yang saya anggap jelek di Ruby adalah apa yang membuat perangkat lunak Ruby yang luar biasa seperti RSpec mungkin, dan Python tidak akan pernah bisa (mengingat implementasi saat ini).

Sementara dia berbicara banyak tentang Python secara khusus, dia menyentuh banyak hal yang aneh di Ruby. Salah satu subjek besar yang memayungi adalah tambalan monyet .

Objek Ruby (tidak seperti objek dalam beberapa bahasa berorientasi objek lainnya) dapat dimodifikasi secara individual. Anda selalu dapat menambahkan metode pada basis per objek. Di Ruby, perilaku atau kemampuan suatu objek dapat menyimpang dari yang disediakan oleh kelasnya.

Walaupun ini memberikan banyak fleksibilitas dan kekuatan beberapa permata Ruby yang paling populer dan rumit, itu dapat menggigit Anda di pantat jika Anda mencoba men-debug masalah tanpa menyadari bahwa beberapa perpustakaan di suatu tempat telah memodifikasi metode inti.


Javascript memungkinkan Anda untuk memperlakukan objek dengan cara itu juga.
0112

8

Beberapa orang hanya memikirkan ruby ​​dalam hal ruby ​​pada rel dan itu agak menjengkelkan karena bahasanya berdiri sendiri.


7

Saya pikir fitur terburuk adalah open classesyang memungkinkan Anda untuk mengubah perilaku semua instance kelas saat ini dan di masa depan secara global.

Bagian bermasalah dari fitur ini adalah, bahwa perubahan tesis (global) ini terjadi selama runtime ketika penerjemah Ruby menemukan definisi, yang mungkin lama setelah Anda sudah instantiated beberapa objek yang sekarang mengubah perilaku mereka tiba-tiba.

Dalam basis kode besar ini dapat mengakibatkan bug yang sangat, sangat sulit ditemukan - terutama karena ini diperparah oleh kelemahan Ruby (dibandingkan dengan contohnya dengan CLR atau JVM) men-debug cerita dan penggunaan fitur-fitur lain (misalnya eval) dalam konteks ini dapat membuat cukup sulit untuk menemukan lokasi di mana perubahan global ini terjadi. yaitu jika Anda sudah mencapai titik di mana Anda mencurigai kelas 'benar' menyebabkan masalah! Dalam pengalaman saya, Anda biasanya memulai dengan pengejaran angsa liar, karena masalah mulai muncul pada suatu objek menggunakan pelakunya yang sebenarnya.

Jadi yang terbaik adalah berhenti menggunakan kelas terbuka ( #extenddan menempatkan perubahan pada ModuleIMHO jauh lebih aman, lebih mudah dimengerti dan lebih baik untuk diuji) atau jika tidak dapat dihindari untuk:

  • hanya memperluas kelas dengan perilaku baru (yaitu tidak mengabaikan perilaku yang ada)
  • memiliki tempat yang ditentukan di pohon kode sumber, di mana semua ekstensi menggunakan kelas terbuka harus ditempatkan
  • jangan gunakan #evaldan teman-teman untuk membuat kelas terbuka
  • letakkan semua penggunaan kelas terbuka pada bagan besar yang terlihat, tempat semua pengembang dapat melihatnya - dan memperjelas bahwa setiap perubahan pada mereka adalah 'keputusan arsitektural' yang memengaruhi seluruh basis kode (yang mereka lakukan) dan bukan tempat untuk peretasan cepat yang bermanfaat untuk tugas Anda saat ini

5

Alasan terbesar saya tidak menggunakan Ruby: Ini lebih lambat dari molase pada bulan Januari di Kutub Utara selama zaman es. Bahasa pembandingan adalah ilmu yang tidak eksak, tetapi Ruby tampak lebih lambat secara drastis daripada JavaScript dan Python.


itu juga pengalaman saya.
Chuck Stephanski

2
aplikasi apa yang Anda kembangkan untuk ruby ​​yang terlalu lambat? Maksud saya, saya percaya Anda ketika Anda mengatakan itu lambat, tetapi bagaimana itu menghentikan Anda dari mencapai tujuan Anda?
David

1
Saya pikir Ruby sangat bagus ketika Anda ingin membuat sesuatu seperti prototipe dan ingin itu dilakukan dengan cepat, sesuatu yang tidak besar dan tidak akan menghasilkan banyak angka. Jika Anda berharap untuk terus-menerus mengunyah banyak siklus CPU, setiap programmer yang baik tahu untuk menggunakan sesuatu seperti C atau C ++.
Jeff Welling

1
@ David: Saya akan mempertimbangkan menggunakan Ruby untuk kode pemrosesan urutan DNA sederhana, tapi saya tidak melakukannya karena Python mengisi ceruk yang sama, memiliki fitur yang serupa dan jauh lebih cepat. Jika saya bersedia naik level, D bahkan lebih cepat dan masih nyaman.
dsimcha

1
@ Jeff Jeff: Setuju, tetapi C dan C ++ sulit ditulis. Inti dari bahasa tingkat tinggi seperti Ruby adalah untuk menghindari berurusan dengan rasa sakit ini sebanyak mungkin. Semakin lambat mereka, semakin kurang baik mereka memenuhi tujuan ini. Ruby lambat bahkan untuk bahasa dinamis tingkat tinggi. Itu dan NumPy / SciPy adalah mengapa saya menggunakan Python sebagai gantinya ketika saya membutuhkan bahasa dinamis tingkat tinggi.
dsimcha

4

Jika ini dapat diperluas ke Ruby on Rails, maka:

  1. Fakta bahwa logika database memberi setiap tabel auto_incrementkunci utama, termasuk tabel yang tidak membutuhkannya dan tidak boleh memilikinya.

  2. Fakta bahwa kunci majemuk tidak didukung sama sekali.

Untuk Ruby biasa, keluhan saya akan sama dengan bahasa apa pun yang memperdagangkan keselamatan untuk ekspresif; mudah untuk melakukan banyak hal hanya dengan sedikit kode, tetapi juga sangat mudah untuk membuat kekacauan besar dengan jumlah kode apa pun.


Silakan lihat hasil edit saya karena saya mempersempit ruang lingkup pertanyaan. Saya akan memulai paralel lain untuk Rails jika pertanyaan dengan suntingan ini disetujui.

1
Maaf, tetapi Anda salah, tidak setiap tabel dalam aplikasi Rails diharuskan memiliki auto_incrementid, terutama bergabung dengan tabel untuk has_and_belongs_to_many hubungan disarankan secara eksplisit TIDAK memiliki kolom id.
Brett Bender

@ Brett - Apakah itu penambahan yang relatif baru? Ketika saya bermain dengan itu kembali pada awal 2008 itu pasti tidak memiliki fitur-fitur itu. Bagaimanapun, itu bagus bahwa mereka tersedia sekarang.

1
@aroth: Saya tidak yakin semua orang akan menganggap "relatif baru" berarti "dalam tiga tahun terakhir" :-)

Ada alternatif untuk ActiveRecord Rails yang disebut DataMapper , yang tidak sependapat dengan ActiveRecord.
Endy Tjahjono

3

Ruby mencakup metaprogramming (refleksi, introspeksi), pemrograman multi-paradigma, dan dinamika pada tingkat yang tidak biasa. Mudah menembak diri sendiri di kaki dengan kekuatan dan fleksibilitas.

Sulit? Ruby memiliki kemampuan untuk menjadi sangat mudah dibaca atau tidak rusak. Saya telah melihat kode yang sepertinya milik skrip Bash.

Praktik Buruk? Beberapa Rubyist menghargai kepintaran daripada kebijaksanaan. Mereka menulis dan berbagi trik yang menunjukkan kepintaran mereka, tetapi ini menciptakan kode yang tidak dapat dibaca dan rapuh.

Sebagai tambahan: Javascript adalah bencana karena desain, dan buku "The Good Parts" mencoba mengekstrak keindahan tersembunyi itu. Perl, sebuah bahasa yang mempopulerkan "Ada Lebih Dari Satu Cara Untuk Melakukannya" (yaitu, fleksibilitas), memiliki buku serupa dalam "Perl, Best Practices". Sejarah Perl adalah salah satu eksperimen dan pengalaman yang sulit didapat, "Praktik Terbaik" mewakili pengetahuannya. Perl 6 akan, saya pikir itu adil untuk mengatakan, reboot bahasa berdasarkan pengetahuan itu dan banyak lagi. Ruby mungkin menderita masalah serupa.

@James dan untuk loop ... Ketika Anda melakukan loop for di ruby, itu kemudian memanggil ".each". Oleh karena itu, "untuk" adalah gula sintaksis untuk orang yang lebih nyaman dengan loop gaya C. Tetapi sebagai seorang Rubyist, Anda akan menggunakan iterator seperti .map, .inject, .each_with_object, sepanjang waktu. Anda tidak perlu menulis for for loop dengan sesuatu seperti "i = 0; i> 6; i ++" di ruby, dan akhirnya Anda menghentikan kebiasaan itu. @ andrew ... rubi fasih tidak mendukung loop.


-1

Ini lebih tentang programmer daripada bahasa, tetapi mengapa programmer Ruby sangat membenci loop?

Saya menyadari Ruby memiliki:

someCollection.each do |item|
   ...
end

tapi saya belum pernah melihat itu digunakan dalam situasi di mana for for loop tidak akan melakukan hal yang persis sama.

Saya sudah bertanya beberapa kali dan tidak pernah mendapat jawaban yang bagus untuk yang satu ini.

Jika ini hanya masalah gaya, saya senang menerimanya, tetapi saya telah melihat programmer Ruby benar-benar memahami hal ini dan saya benar-benar ingin tahu.


1
Bahkan ketika saya mendapat jawaban "Ini bukan penekanan tombol", yang jelas salah ... :-)
James

2
Dua teori: 1) Menggunakan forloop adalah sesuatu yang dilakukan n00bs. Orang yang memprogram C di Ruby. 2) Blok banyak digunakan di Ruby, jadi menggunakan sesuatu yang tidak seperti blok hanyalah upaya mental ekstra.
Andrew Grimm

3
Sementara saya baru mulai belajar Ruby, blok adalah sesuatu yang sangat saya sukai dan rindukan ketika saya mencoba menggunakan Python. Akankah for for loop melakukan hal yang sama? Tentu saja, bagi saya, gaya seperti ini hanya cocok untuk preferensi saya lebih dari satu untuk loop.
Jetti

2
@ andrew Sejujurnya, jawaban pertama Anda adalah jenis sampah yang saya dapatkan ketika saya bertanya sebelumnya. Tidak ada alasan nyata, dengan penghinaan halus di atas. @Wayne, @Jetti dan @andrews jawaban ke-2: terima kasih. Cukup adil.
James

1
Jika maksud Anda "ditingkatkan" untuk loop (alias. Untuk <nilai> dalam <ekspresi> lakukan ...) tidak ada perbedaan selain dari #setiap digunakan dan penampilan lebih dekat dengan sepupunya yang biasa digunakan #inject, #collect, # tolak dll. Jika Anda berbicara tentang loop berindeks gaya 'C' (alias. untuk int i = 0; i <apa pun; ++ i) perbedaannya adalah, bahwa a) kesalahan "off by one" tidak mungkin dan b) bahwa itu membuat maksud lingkaran Anda jelas - #masing-masing berarti "untuk setiap elemen menghasilkan efek samping". A for loop mengharuskan Anda membaca seluruh loop hanya untuk mendapatkan 'intisari' dari tujuannya.
Alexander Battisti

-1

Saya biasanya menghindari hal-hal yang ditambahkan hanya agar kompatibel dengan bahasa lain. Sebagai contoh, Perlisms dan for x in y.


Saya baru saja mengirim jawaban tentang Programmer Ruby dan loop, dan jika Anda dapat menjelaskan saya akan berterima kasih :-)
James
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.