Mengapa banyak bahasa pemrograman dinamis bebek-mengetik menggunakan pendekatan berbasis kelas daripada OOP berbasis prototipe?

23

Karena cukup banyak bahasa pemrograman dinamis memiliki fitur mengetik bebek , dan mereka juga dapat membuka dan memodifikasi metode kelas atau contoh kapan saja (seperti Ruby dan Python ), maka ...

Pertanyaan 1) Apa perlunya kelas dalam bahasa yang dinamis? Mengapa bahasa dirancang sedemikian rupa untuk menggunakan kelas sebagai semacam "template" alih-alih melakukannya dengan cara prototipe dan hanya menggunakan objek?

Juga JavaScript berbasis prototipe, tetapi CoffeeScript (versi JavaScript yang disempurnakan) memilih cara berbasis kelas. Dan itu berjalan sama untuk Lua (berbasis prototipe) dan MoonScript (berbasis kelas). Selain itu, ada kelas di ES 6. Jadi ...

Pertanyaan 2) Apakah ini menunjukkan bahwa jika Anda mencoba untuk meningkatkan bahasa berbasis prototipe, antara lain, Anda harus mengubahnya ke berbasis kelas? Jika tidak, mengapa itu dirancang seperti itu?

— iceX
sumber

9

Banyak programmer tidak mau repot mempelajari sesuatu yang baru. (Ini terlalu asing dan "sulit"). Oleh karena itu semua perpustakaan dan bahasa berbasis kelas yang mengkompilasi untuk mereka.

— Thomas Eding

1

Saya setuju dengan Thomas, tetapi yang lucu adalah bahwa setelah Anda mempelajari pendekatan dinamis, sebenarnya lebih mudah (bukan lebih sulit). Konsep objek masih ada, hanya saja objek dapat diubah tanpa mengkompilasi ulang beberapa "cetak biru" bodoh terlebih dahulu. Jika saya ingin meletakkan kaki ke-5 di kursi, saya tidak ingin harus mengubah cetak biru terlebih dahulu, saya hanya ingin menambahkan kaki. Bahasa yang dinamis lebih dekat memodelkan realitas menurut pendapat saya.

— Lonnie Best

1

OOP ditemukan dalam konteks yang diketik secara statis, di mana jenis harus dideklarasikan. Di sana, kelas adalah langkah maju yang masuk akal dari catatan dan modul. OOP berbasis prototipe hanya pernah menjadi topik penelitian yang menarik untuk bahasa Self, dan entah bagaimana membuatnya menjadi JavaScript sebagai cara paling sederhana untuk menandai buzzword "OOP" untuk bahasa yang pada dasarnya fungsional. Yang menyenangkan adalah Anda dapat mengimplementasikan kelas di atas prototipe. Sementara saya suka metaobjects, memisahkan kelas dari instance mereka membuatnya lebih mudah untuk menulis kode yang diperhitungkan dengan baik, sederhana, dan longgar.

— amon

3

Hal pertama yang pertama: JavaScript sendiri mendukung classkata kunci pada standar ECMAScript berikutnya (ECMAScript 6). Dukungan untuk kelas dalam JavaScript telah direncanakan sejak lama. Sekarang untuk apa itu - kelas hanya gula sintaksis, alasan yang lebih mudah tentang model untuk objek dari jenis yang sama. Ini dengan cara ini di JS dan ini dengan cara di Python dan bahasa dinamis lainnya.

— Benjamin Gruenbaum

1

@BenjaminGruenbaum "... kelas hanyalah gula sintaksis ..." wow, ini agak ide yang cukup baru bagi saya, sungguh, untuk bahasa seperti ruby dan python, sepertinya tidak masalah apakah akan menggunakan objek atau kelas sebagai templat —- bagaimanapun juga dapat dimodifikasi dengan cepat. Dan tidak masalah bagaimana mereka menangani warisan juga. Jadi, mungkin tidak perlu membedakan antara pendekatan berbasis kelas dan pendekatan berbasis prototipe untuk bahasa yang dinamis :)

— iceX

12

Pertanyaan 1) Apa perlunya Kelas dalam bahasa yang dinamis? Mengapa bahasa dirancang sedemikian rupa untuk menggunakan kelas sebagai semacam "templat" alih-alih melakukannya dengan cara prototipe dan hanya menggunakan objek?

Bahasa OO pertama (meskipun itu tidak disebut "OO"), Simula, tidak memiliki warisan. Warisan ditambahkan dalam Simula-67, dan didasarkan pada kelas.

Sekitar waktu yang sama, Alan Kay mulai bekerja pada idenya tentang paradigma pemrograman baru, yang kemudian dia beri nama "Orientasi Objek". Dia benar-benar menyukai warisan dan ingin memilikinya dalam bahasanya, tetapi dia juga sangat tidak suka kelas. Namun, dia tidak dapat menemukan cara untuk memiliki warisan tanpa kelas, dan karena itu dia memutuskan bahwa dia tidak menyukai kelas lebih daripada dia menyukai warisan dan merancang versi pertama Smalltalk, Smalltalk-72 tanpa kelas dan dengan demikian tanpa warisan.

Beberapa bulan kemudian, Dan Ingalls datang dengan desain kelas, di mana kelas itu sendiri adalah objek, yaitu contoh dari metaclasses. Alan Kay menemukan desain ini sedikit kurang menarik daripada yang lama, sehingga Smalltalk-74 dirancang dengan kelas dan dengan warisan berdasarkan kelas.

Setelah Smalltalk-74, Alan Kay merasa bahwa Smalltalk bergerak ke arah yang salah dan tidak benar-benar mewakili apa yang dimaksud dengan OO, dan ia mengusulkan agar tim meninggalkan Smalltalk dan mulai segar, tetapi ia kalah suara. Dengan demikian mengikuti Smalltalk-76, Smalltalk-80 (versi pertama Smalltalk akan dirilis kepada peneliti), dan akhirnya Smalltalk-80 V2.0 (versi pertama akan dirilis secara komersial, dan versi yang menjadi dasar untuk ANSI Smalltalk) .

Karena Simula-67 dan Smalltalk-80 dianggap sebagai kakek-nenek dari semua bahasa OO, hampir semua bahasa yang mengikuti, secara acak menyalin desain kelas dan pewarisan berdasarkan kelas. Beberapa tahun kemudian, ketika ide-ide lain seperti warisan didasarkan pada mixin, bukan kelas, dan delegasi berdasarkan objek bukan warisan berdasarkan kelas yang muncul, warisan berbasis kelas sudah menjadi terlalu mengakar.

Cukup menarik, bahasa Alan Kay saat ini didasarkan pada delegasi prototipe.

— Jörg W Mittag
sumber

"... Bahasa Alan Kay saat ini ..." yang mana ...?

— Javier

@ Javier: Saya rasa itu tidak memiliki nama, dan nama sistem terus berubah.

— Jörg W Mittag

Ini harus menjadi jawaban yang baik untuk menunjuk ke waktu berikutnya seseorang daftar warisan sebagai persyaratan untuk OO :)

— Hei

1

@iceX: Alan Kay mendirikan Viewpoints Research Institute untuk mengerjakan gagasannya. Sayangnya, informasi benar-benar tersebar di situs web.

— Jörg W Mittag

3

Alan Kay mengutip pada OO: "OOP bagi saya hanya berarti pengiriman pesan, penyimpanan lokal dan perlindungan dan menyembunyikan proses-negara, dan sangat mengikat semua hal. Ini dapat dilakukan di Smalltalk dan di LISP. Mungkin ada sistem lain di yang ini mungkin, tapi saya tidak menyadarinya. "

— Joeri Sebrechts

23

Banyak programmer lebih suka bekerja dengan kelas. Ini adalah konsep yang sangat mudah dipahami yang merupakan model yang baik dari proses pemikiran manusia tentang dunia (yaitu, kita secara naluriah menghubungkan objek nyata dengan kelompok abstrak barang-barang yang kita anggap milik mereka, yang merupakan kelas) . Juga, kelas membuat alasan tentang jenis objek lebih mudah: dalam bahasa berbasis kelas, menerapkan prinsip-prinsip seperti substitusi Liskov lebih sederhana daripada dalam bahasa di mana kita hanya memiliki objek yang mungkin memiliki metode yang berbeda, atau yang tipenya bahkan dapat berubah pada saat dijalankan , seperti halnya dalam JavaScript.

Perhatikan bahwa bahkan dalam JavaScript, banyak sekali kode hanya menggunakan fasilitas prototipe untuk meniru kelas. Ini sebagian besar karena banyak programmer lebih suka berpikir seperti itu.

Ada juga alasan lain mengapa bahasa berbasis kelas lebih disukai: lebih mudah untuk mengkompilasinya ke kode yang efisien. JavaScript VMs yang paling efisien secara efektif membuat kelas untuk mewakili jenis objek JavaScript saat metode dan prototipe mereka berubah. Lihat deskripsi implementasi V8 ini untuk alasan mengapa hal ini dilakukan.

— Jules
sumber

4

Paragraf terakhir Anda sebenarnya mendukung kebalikan dari apa yang Anda katakan: V8 membuktikan bahwa Anda tidak memerlukan kelas dalam bahasa untuk mengkompilasi kode berbasis kelas yang efisien.

— Jörg W Mittag

4

Ya, Anda tidak membutuhkannya - tetapi fakta bahwa V8 (dan mungkin Self, walaupun saya belum banyak membaca tentang desain sistem itu) secara efektif menciptakan kelas virtual yang berarti mulai dari bahasa yang secara native menggunakan kelas hampir tentu lebih mudah, dan karena itu mungkin akan berakhir dengan JIT yang perlu menghabiskan lebih sedikit waktu untuk menyusun kode.

— Jules

11

Tentu, dan fakta bahwa V8 secara efektif membuat GOTOs dan register berarti bahwa melepaskan semua abstraksi dan menulis secara langsung hampir pasti lebih mudah, dan karena itu mungkin akan berakhir dengan JIT yang perlu menghabiskan lebih sedikit waktu untuk menyusun kode. Ini tugas kompiler untuk mendukung abstraksi level yang lebih tinggi.

— Jörg W Mittag

1

Ya, tetapi ini merupakan trade-off, karena abstraksi tingkat yang lebih tinggi dalam banyak kasus lebih sulit untuk diimplementasikan dan seringkali memiliki penalti kinerja run-time, terutama ketika bekerja dengan JIT daripada kompiler AOT. Saya menduga bahwa banyak perancang bahasa memilih struktur berbasis kelas untuk satu atau kedua alasan tersebut; Saya tahu itu sebabnya saya memilih kelas dengan anggota tetap untuk bahasa (jika tidak dinamis) yang saya kerjakan, tetapi hanya bisa berspekulasi tentang bahasa lain.

— Jules

1

Saya berpendapat bahwa satu-satunya cara programmer lebih suka "berpikir di kelas" adalah karena itulah sebagian besar dari kita diajarkan. Saya pasti dapat mengingat banyak rekan mahasiswa saya di perguruan tinggi yang kesulitan memahami dan memahami beberapa konsep Berorientasi Objek yang benar-benar mendasar selama beberapa tahun. Tampaknya hanya jelas dan mudah di belakang.

— KChaloux

3

Saya pernah mendengar bahwa pada proyek-proyek besar, di mana tim orang bekerja bersama pada kode yang sama, bahwa bahasa yang fleksibel (di mana Anda dapat memodifikasi properti dan metode objek selama waktu berjalan) adalah kebebasan yang tidak diinginkan oleh anggota tim lain untuk Anda memiliki.

Mereka ingin tahu, ketika mereka berhadapan dengan suatu objek, bahwa objek tersebut akan bertindak seperti cetak biru katakan, dan bukan cara morf yang beberapa pengembang ambisius memutuskan untuk mengubahnya untuk menyelesaikan tugasnya sendiri.

Jadi, satu-satunya alasan saya bisa membayangkan, bahwa seseorang tidak ingin fleksibilitas yang ditawarkan oleh bahasa dinamis yang mengagumkan ini, adalah karena mereka ingin menyederhanakan pengembangan tim, debugging, dan dokumentasi otomatis.

Secara pribadi, saya telah mengembangkan aplikasi dalam kedua metodologi, dan saya menyelesaikan berbagai hal dengan lebih cepat dengan bahasa yang dinamis. Saya tidak menggunakan kerangka kerja ini yang dirancang untuk mengubah bahasa dinamis saya kembali menjadi bahasa berbasis kelas lagi. Hal-hal semacam itu merupakan kemunduran bagi selera saya.

— Lonnie Best
sumber

1

OOP bagi saya berarti hanya olahpesan, penyimpanan lokal dan perlindungan dan menyembunyikan proses negara, dan sangat mengikat semua hal - Alan Kay

Jadi yang dia katakan di sini adalah bahwa OO adalah tentang membuat kotak hitam yang menanggapi pesan. Di satu sisi REST adalah sistem OO utama dalam hal itu menggunakan kata kerja (yaitu pesan) dan sumber daya (yaitu kotak buram yang berisi beberapa data).

Jadi pertanyaan mengapa beberapa berbasis kelas dan yang lain berdasarkan prototipe kehilangan titik bahwa itu benar-benar tidak masalah, mereka berdua hanyalah implementasi. Sistem yang hanya menggunakan pengiriman pesan alih-alih panggilan metode sama seperti OO seperti dua contoh yang Anda sebutkan.

— gbjbaanb
sumber