Saya tidak akan memposting ini sebagai jawaban, tetapi Xeoncross memintaku, jadi di sini kita mulai:
(Sidenote: jika seseorang dapat memperbaiki masalah penurunan harga dalam contoh kode kecil, saya akan menghargainya.)
Erik Max Francis menulis:
"Brandon J. Van Every" menulis:
Apa yang lebih baik tentang Ruby daripada Python? Saya yakin ada sesuatu. Apa itu? Bukankah lebih masuk akal untuk bertanya pada orang Ruby ini, daripada orang Python?
Mungkin, atau mungkin tidak, tergantung pada tujuan seseorang - misalnya, jika tujuan seseorang termasuk "studi sosiologis" dari komunitas Python, maka mengajukan pertanyaan kepada komunitas itu kemungkinan akan membuktikan lebih banyak mengungkapkan informasi tentang hal itu, daripada menempatkannya di tempat lain :-). Secara pribadi, saya dengan senang hati mengambil kesempatan untuk mengikuti tutorial Ruby satu hari Dave Thomas di OSCON terakhir. Di bawah lapisan tipis perbedaan sintaks, saya menemukan Ruby dan Python sangat mirip - jika saya menghitung pohon rentang minimum di antara sembarang bahasa, saya cukup yakin Python dan Ruby akan menjadi dua daun pertama yang bergabung menjadi simpul perantara :-).
Tentu, saya mendapatkan lelah, di Ruby, mengetik konyol "akhir" pada akhir setiap blok (bukan hanya unindenting) - tapi kemudian saya mendapatkan untuk menghindari mengetik sama-konyol :
yang Python membutuhkan pada
awal dari setiap blok, jadi itu hampir mencuci :-). Perbedaan sintaksis lainnya seperti @fooversus
self.foo, atau signifikansi case yang lebih tinggi dalam Ruby vs Python, benar-benar sama tidak relevannya bagi saya.
Yang lain tidak diragukan lagi mendasarkan pilihan mereka pada bahasa pemrograman hanya pada masalah seperti itu, dan mereka menghasilkan perdebatan terpanas - tetapi bagi saya itu hanya contoh dari salah satu Hukum Parkinson dalam tindakan (jumlah pada debat tentang suatu masalah berbanding terbalik dengan masalah tersebut. kepentingan aktual). Satu perbedaan sintaks yang saya anggap penting, dan mendukung Python - tetapi orang lain pasti akan berpikir sebaliknya - adalah "bagaimana Anda memanggil fungsi yang tidak memerlukan parameter". Dalam Python (seperti dalam C), untuk memanggil fungsi Anda selalu menerapkan "operator panggilan" - membuntuti tanda kurung tepat setelah objek yang Anda panggil (di dalam tanda kurung trailing pergi argumen yang Anda sampaikan dalam panggilan - jika Anda tidak memberikan argumen, maka tanda kurung kosong). Ini meninggalkan hanya penyebutan objek apa pun, tanpa melibatkan operator, sebagai makna hanya referensi ke objek - dalam konteks apa pun, tanpa kasus khusus, pengecualian, aturan ad-hoc, dan sejenisnya. Di Ruby (seperti dalam Pascal), untuk memanggil fungsi DENGAN argumen, Anda meneruskan argumen (biasanya dalam tanda kurung, meskipun tidak selalu demikian) - TETAPI jika fungsi tersebut tidak menggunakan argumen, cukup sebutkan fungsi yang secara implisit memanggilnya. Ini mungkin memenuhi harapan banyak orang (setidaknya, tidak diragukan lagi, mereka yang hanya memiliki pengalaman pemrograman sebelumnya dengan Pascal, atau bahasa lain dengan "panggilan implisit" yang serupa, seperti Visual Basic) - tetapi bagi saya, itu berarti hanya menyebutkan suatu objek dapat BAIK berarti referensi ke objek, ATAU panggilan ke objek, tergantung pada jenis objek - dan dalam kasus-kasus di mana saya tidak bisa mendapatkan referensi ke objek hanya dengan menyebutkannya saya akan perlu menggunakan eksplisit "beri saya referensi untuk ini, JANGAN menyebutnya!" operator yang tidak diperlukan sebaliknya. Saya merasa ini berdampak pada "kelas-pertama" fungsi (atau metode, atau objek yang dapat dipanggil lainnya) dan kemungkinan menukar objek dengan lancar. Oleh karena itu, bagi saya, perbedaan sintaksis khusus ini adalah tanda hitam yang serius terhadap Ruby - tetapi saya mengerti mengapa orang lain melakukan hal sebaliknya, walaupun saya hampir tidak bisa berselisih lebih keras dengan mereka :-). Di bawah sintaks, kita masuk ke beberapa perbedaan penting dalam semantik dasar - misalnya, string dalam Ruby adalah objek yang bisa berubah-ubah (seperti di C ++), sementara di Python mereka tidak bisa berubah (seperti di Jawa, atau saya percaya C #). Sekali lagi, orang-orang yang menilai berdasarkan apa yang sudah mereka kenal mungkin berpikir ini adalah nilai tambah untuk Ruby (kecuali mereka akrab dengan Java atau C #, tentu saja :-). Saya, saya pikir string tidak dapat diubah adalah ide yang bagus (dan saya tidak terkejut bahwa Java, secara independen saya pikir, menemukan kembali ide yang sudah di Python), meskipun saya tidak akan keberatan memiliki tipe "buffer string yang dapat diubah" juga. (dan idealnya dengan kemudahan penggunaan yang lebih baik daripada "string buffer" Java sendiri); dan saya tidak memberikan penilaian ini karena terbiasa - sebelum mempelajari Java, selain dari bahasa pemrograman fungsional di mana orang-orang yang menilai berdasarkan apa yang sudah mereka kenal mungkin berpikir ini adalah nilai tambah untuk Ruby (kecuali mereka akrab dengan Java atau C #, tentu saja :-). Saya, saya pikir string tidak dapat diubah adalah ide yang bagus (dan saya tidak terkejut bahwa Java, secara independen saya pikir, menemukan kembali ide yang sudah di Python), meskipun saya tidak akan keberatan memiliki tipe "buffer string yang dapat diubah" juga. (dan idealnya dengan kemudahan penggunaan yang lebih baik daripada "string buffer" Java sendiri); dan saya tidak memberikan penilaian ini karena terbiasa - sebelum mempelajari Java, selain dari bahasa pemrograman fungsional di mana orang-orang yang menilai berdasarkan apa yang sudah mereka kenal mungkin berpikir ini adalah nilai tambah untuk Ruby (kecuali mereka akrab dengan Java atau C #, tentu saja :-). Saya, saya pikir string tidak dapat diubah adalah ide yang bagus (dan saya tidak terkejut bahwa Java, secara independen saya pikir, menemukan kembali ide yang sudah di Python), meskipun saya tidak akan keberatan memiliki tipe "buffer string yang dapat diubah" juga. (dan idealnya dengan kemudahan penggunaan yang lebih baik daripada "string buffer" Java sendiri); dan saya tidak memberikan penilaian ini karena terbiasa - sebelum mempelajari Java, selain dari bahasa pemrograman fungsional di mana Saya pikir string yang tidak dapat diubah adalah ide yang bagus (dan saya tidak terkejut bahwa Java, secara independen saya pikir, menemukan kembali ide yang sudah ada di Python), meskipun saya tidak akan keberatan memiliki tipe "buffer string yang dapat diubah" juga (dan idealnya dengan kemudahan penggunaan yang lebih baik daripada "string buffer" Java sendiri); dan saya tidak memberikan penilaian ini karena terbiasa - sebelum mempelajari Java, selain dari bahasa pemrograman fungsional di mana Saya pikir string tidak dapat diubah adalah ide yang bagus (dan saya tidak terkejut bahwa Java, secara independen saya pikir, menemukan kembali ide yang sudah di Python), meskipun saya tidak akan keberatan memiliki tipe "buffer string yang dapat diubah" juga (dan idealnya dengan kemudahan penggunaan yang lebih baik daripada "string buffer" Java sendiri); dan saya tidak memberikan penilaian ini karena terbiasa - sebelum mempelajari Java, selain dari bahasa pemrograman fungsional di manasemua data tidak dapat diubah, semua bahasa yang saya tahu memiliki string yang dapat berubah - namun ketika saya pertama kali melihat ide string yang tidak dapat diubah di Jawa (yang saya pelajari dengan baik sebelum saya belajar Python), itu langsung mengejutkan saya sebagai sangat baik, sangat cocok untuk referensi-semantik dari bahasa pemrograman tingkat yang lebih tinggi (sebagai lawan dari nilai-semantik yang paling cocok dengan bahasa yang lebih dekat ke mesin dan lebih jauh dari aplikasi, seperti C) dengan string sebagai kelas, built-in (dan cantik) penting) tipe data.
Ruby memang memiliki beberapa keunggulan dalam semantik dasar - misalnya, penghapusan "daftar vs tupel" Python yang membedakannya sangat halus. Tetapi sebagian besar nilainya (seperti yang saya simpan, dengan kesederhanaan nilai tambah yang besar dan halus, pandai minus yang penting) bertentangan dengan Ruby (misalnya, memiliki interval tertutup dan setengah terbuka, dengan notasi a..b dan .. .b [ada yang mau mengklaim bahwa itu jelas yang mana? -)], konyol - IMHO, tentu saja!). Sekali lagi, orang-orang yang menganggap memiliki banyak hal yang mirip tetapi agak berbeda pada inti suatu bahasa PLUS, daripada MINUS, tentu saja akan menghitung "sebaliknya" dari cara saya menghitungnya :-).
Jangan disesatkan oleh perbandingan ini dengan berpikir bahwa kedua bahasa itu
sangatberbeda, ingatlah kamu. Mereka bukan. Tetapi jika saya diminta untuk membandingkan "capelli d'angelo" dengan "spaghettini", setelah menunjukkan bahwa kedua jenis pasta ini hampir tidak dapat dibedakan dengan siapa pun dan dapat dipertukarkan dalam hidangan apa pun yang mungkin ingin Anda siapkan, maka saya pasti akan memiliki untuk pindah ke pemeriksaan mikroskopis tentang bagaimana panjang dan diameter berbeda secara kasat mata, bagaimana ujung-ujung untaian meruncing dalam satu kasus dan tidak dalam yang lain, dan seterusnya - untuk mencoba dan menjelaskan mengapa saya, secara pribadi, lebih suka memiliki capelli. 'angelo sebagai pasta dalam segala jenis kaldu, tetapi akan lebih suka spaghettini daripada pastasciutta dengan saus yang cocok untuk bentuk pasta tipis yang panjang (minyak zaitun, bawang putih cincang, paprika merah cincang, dan ikan teri yang digiling halus, misalnya - tetapi jika Anda mengiris bawang putih dan paprika alih-alih mencincangnya, maka Anda harus memilih tubuh spageti yang lebih sehat daripada spaghettini yang lebih tipis, dan disarankan untuk tidak lagi menggunakan acoview dan menambahkan basil musim semi segar [ atau bahkan - Saya seorang bidat ...! - cahaya mint ...] pergi - pada saat terakhir sebelum menyajikan hidangan). Ooops, maaf, ini menunjukkan bahwa saya bepergian ke luar negeri dan belum memiliki pasta untuk sementara waktu, saya kira. Tapi analoginya masih cukup bagus! -) dan akan sangat disarankan untuk melepaskan achoview dan menambahkan beberapa basil musim semi segar [atau bahkan - saya seorang bidat ...! - cahaya mint ...] pergi - pada saat terakhir sebelum menyajikan hidangan). Ooops, maaf, ini menunjukkan bahwa saya bepergian ke luar negeri dan belum memiliki pasta untuk sementara waktu, saya kira. Tapi analoginya masih cukup bagus! -) dan akan sangat disarankan untuk melepaskan achoview dan menambahkan beberapa basil musim semi segar [atau bahkan - saya seorang bidat ...! - cahaya mint ...] pergi - pada saat terakhir sebelum menyajikan hidangan). Ooops, maaf, ini menunjukkan bahwa saya bepergian ke luar negeri dan belum memiliki pasta untuk sementara waktu, saya kira. Tapi analoginya masih cukup bagus! -)
Jadi, kembali ke Python dan Ruby, kita sampai pada dua biggies (dalam hal bahasa yang tepat - meninggalkan perpustakaan, dan pendukung penting lainnya seperti alat dan lingkungan, cara menyematkan / memperluas setiap bahasa, dll, dll, dari untuk saat ini - mereka tidak akan berlaku untuk semua IMPLEMENTASI dari setiap bahasa, misalnya, Jython vs Classic Python menjadi dua implementasi dari bahasa Python!):
Iterator dan codeblock Ruby vs iterator dan generator Python;
TOTAL Ruby, "dinamisitas" yang tak terkendali, termasuk kemampuan untuk "membuka kembali" setiap kelas yang ada, termasuk semua kelas bawaan, dan mengubah perilakunya pada saat run-time - vs dinamisitas Python yang luas tetapi terbatas
, yang tidak pernah mengubah perilaku yang ada kelas bawaan dan instance mereka.
Secara pribadi, saya menganggap 1 pembasuhan (perbedaannya sangat dalam sehingga saya dapat dengan mudah melihat orang-orang membenci salah satu pendekatan dan menghormati yang lain, tetapi pada skala pribadi SAYA nilai plus dan minusnya hampir merata); dan [2] masalah penting - yang membuat Ruby jauh lebih cocok untuk "bermain-main", TETAPI Python lebih cocok untuk digunakan dalam aplikasi produksi besar. Dalam hal ini lucu, karena kedua bahasa jauh JAUH lebih dinamis daripada kebanyakan bahasa lainnya, bahwa pada akhirnya perbedaan utama antara mereka dari POV saya harus bergantung pada itu - bahwa Ruby "pergi ke sebelas" dalam hal ini (referensi di sini adalah "Tap Spinal", tentu saja). Di Ruby,AKU BISA MELAKUKANNYA ! Yaitu, saya dapat secara dinamis mengubah kelas string bawaan
a = "Hello World"
b = "halo dunia"
jika a == b
cetak "sama! \ n"
lain
cetak "berbeda! \ n"
akhir
AKAN mencetak "sama". Dengan python, TIDAK ada cara saya bisa melakukan itu. Untuk keperluan metaprogramming, mengimplementasikan framework eksperimental, dan sejenisnya, kemampuan dinamis Ruby yang menakjubkan ini sangat luar biasa
menarik. TETAPI - jika kita berbicara tentang aplikasi besar, dikembangkan oleh banyak orang dan dikelola oleh lebih banyak lagi, termasuk semua jenis perpustakaan dari berbagai sumber, dan perlu untuk masuk ke produksi di situs klien ... well, saya tidak MAU bahasa yang SANGAT dinamis, terima kasih banyak. Saya benci gagasan beberapa perpustakaan tanpa disadari melanggar yang tidak terkait lainnya yang bergantung pada string yang berbeda - itu adalah jenis "saluran" yang dalam dan sangat tersembunyi, antara potongan-potongan kode yang TERLIHAT terpisah dan HARUS terpisah, yang menandakan kematian dalam pemrograman skala besar. Dengan membiarkan modul apa pun memengaruhi perilaku "diam-diam" lainnya,
Jika saya harus menggunakan Ruby untuk aplikasi sebesar itu, saya akan mencoba untuk mengandalkan pembatasan gaya pengkodean, banyak tes (untuk dijalankan kembali setiap kali perubahan APA SAJA - bahkan apa yang seharusnya sama sekali tidak berhubungan ...), dan sejenisnya, untuk melarang penggunaan fitur bahasa ini. Tapi BUKAN memiliki fitur di tempat pertama bahkan lebih baik, menurut saya - sama seperti Python itu sendiri akan menjadi bahasa yang lebih baik untuk pemrograman aplikasi jika sejumlah built-in dapat "dipatahkan", jadi saya TAHU itu , misalnya,
len("ciao")adalah 4 (daripada harus khawatir secara subliminal tentang apakah seseorang mengubah pengikatan nama lendalam __builtins__
modul ...). Saya berharap bahwa akhirnya Python "memakukan" bawaannya.
Tapi masalahnya kecil, karena memberontak built-in cukup usang dan juga merupakan praktik yang jarang terjadi di Python. Di Ruby, itu menurut saya penting - seperti
fasilitas makro terlalu kuat dari bahasa lain (seperti, katakanlah, Dylan) menghadirkan risiko serupa menurut pendapat saya sendiri (saya berharap bahwa Python tidak pernah mendapatkan sistem makro yang begitu kuat, tidak ada peduli daya pikat "membiarkan orang menentukan sendiri bahasa kecil khusus domain mereka yang tertanam dalam bahasa itu sendiri" - itu akan, IMHO, merusak kegunaan luar biasa Python untuk pemrograman aplikasi, dengan menghadirkan "gangguan yang menarik" kepada calon penjahat yang bersembunyi di hati setiap programmer ...).
Alex