Bagaimana beberapa komunitas bahasa (misalnya, Ruby dan Python) dapat mencegah fragmentasi sementara yang lain (misalnya, Lisp atau ML) tidak?

67

Istilah "Lisp" (atau "Lisp-like") adalah payung untuk banyak bahasa yang berbeda, seperti Common Lisp, Scheme, dan Arc. Ada fragmentasi serupa di komunitas bahasa lain, seperti di ML.

Namun, Ruby dan Python sama-sama berhasil menghindari nasib ini, di mana inovasi lebih banyak terjadi pada implementasi (seperti PyPy atau YARV) daripada membuat perubahan pada bahasa itu sendiri.

Apakah komunitas Ruby dan Python melakukan sesuatu yang istimewa untuk mencegah fragmentasi bahasa?

programming-languages language-design chrisaycock
sumber
10
Anda mengatakan fragmentasi seperti itu adalah hal yang buruk.
Sonia
21
@Onia Dari perspektif pangsa pasar, fragmentasi sering kali merupakan bencana.
chrisaycock
5
Apakah bahasa saling bersaing?
Barry Brown
32
@Onia Ini bisa menjadi hal yang buruk. Misalnya, perpustakaan yang ditulis untuk Python hampir pasti tidak bergantung pada implementasinya, sedangkan perpustakaan yang ditulis untuk Lisp mungkin tidak berfungsi dalam Skema.
Kris Harper
2
@ Barry Brown: Poin bagus! Bahasa tidak boleh saling bersaing dalam pasar. Tetapi vendor bahasa dan ini sering mempengaruhi desain bahasa (saya tidak berpikir ini adalah kasus Ruby, Python, Lisp, ML, meskipun).
Giorgio

Jawaban:

77

Ruby dan Python sama-sama memiliki diktator yang baik hati . Mereka adalah bahasa yang mengakar dalam keprihatinan pragmatis. Itu mungkin faktor yang paling signifikan menghambat fragmentasi. Lisp dan ML, di sisi lain, lebih seperti bahasa "desain oleh komite", dikandung dalam dunia akademis, untuk tujuan teoretis.

Lisp pada awalnya dirancang oleh John McCarthy sebagai notasi matematika praktis untuk program komputer. Dia tidak pernah mengimplementasikannya sebagai bahasa pemrograman aktual; implementasi pertama dikembangkan oleh Steve Russell , tetapi dia bukan diktator yang baik hati. Seiring waktu, banyak implementasi Lisp yang berbeda muncul; Common Lisp adalah upaya untuk menstandarkan mereka.

Lisp lebih dari "keluarga" bahasa. Begitu juga ML, yang mengikuti jalur evolusi yang mirip dengan Lisp.

Robert Harvey
sumber
4
Hmm, saya pasti melihat status diktator di antara komunitas bahasa yang homogen seperti Objective-C (untuk aplikasi iOS) dan Ada (untuk kontrak Departemen Pertahanan). Dalam kasus ini, daya yang lebih tinggi menuntut kepatuhan, yang diikuti pengembang hanya untuk dapat menjual barang mereka. Tapi saya tidak pernah diminta untuk kode dalam Python (proyek hobi) dalam arti yang sama bahwa saya mungkin diminta untuk kode dalam C # (komponen .Net). Yaitu, saya bisa lebih mudah melarikan diri dari Python daripada, katakanlah, C. Tanpa ancaman menggunakannya atau Anda tidak akan membuat penjualan , bagaimana bisa seorang diktator memegang kawanan domba? Itu mungkin pertanyaan terpisah.
chrisaycock
1
Dengan "diktator yang baik hati," maksud saya bahwa semua perubahan bahasa harus melalui satu orang yang memiliki visi untuk menjaga bahasa tetap murni. Orang-orang tetap dengan Python karena alasan pragmatis; mereka suka bahasa, dan produktif di dalamnya. Tapi tidak semua orang dan saudara mereka diizinkan untuk bercabang, dan masih menyebutnya Python.
Robert Harvey
4
@HenrikHansen Haskell adalah standar, seperti yang disebutkan oleh Robert. Jadi kompiler HUGS harus kompatibel dengan GHC karena keduanya menyebut diri mereka "Haskell". Perlindungan berbasis standar yang sama meluas ke C dan C ++, itulah sebabnya GCC dan Visual Studio harus kompatibel (dengan asumsi tidak ada penggunaan ekstensi eksklusif). Keingintahuan adalah apa yang terjadi pada Lisp, di mana sudah ada standar (Common Lisp) dan masih ada banyak Lisps lainnya. ML memiliki masalah yang sama di mana ada ML Standar dan ML lainnya.
chrisaycock
4
"Common Lisp dikembangkan untuk menstandarkan varian divergen Lisp yang mendahuluinya" - en.wikipedia.org/wiki/Common_Lisp . Dengan kata lain, sudah ada fragmentasi sebelum standar dikembangkan.
Robert Harvey
3
Saya bahkan akan mengatakan ML dan Lisp bukan bahasa seperti Python dan Ruby. Lisp dan ML lebih seperti "konsep", diimplementasikan oleh beberapa bahasa yang berbeda.
BenjaminB
29

Salah satu faktor yang mungkin adalah usia. Lisp dan ML jauh lebih tua dari Python dan Ruby:

  • Lisp: 1958

  • ML: 1973

  • Python: 1991

  • Ruby: 1995

Lisp dan ML jelas telah melihat perubahan yang jauh lebih besar dalam kemampuan perangkat keras, lebih banyak tren dalam ilmu komputer, dan banyak lagi mahasiswa Ph.D mencari sesuatu untuk dikerjakan.

Caleb
sumber
7
Mungkin, tapi saya tidak ingat Fortran memiliki tingkat forking seperti ini. (Ada hal-hal seperti Fortran D, tetapi kebanyakan Fortrans telah melalui standarisasi.) Saya kira mungkin usia penggabungan mungkin menjadi faktor.
chrisaycock
2
AFAIK, Fortran memiliki banyak ketidakcocokan dan ekstensi non-standar dan implementasi yang berbeda sampai komite standar secara bertahap menuntaskannya, mungkin karena itu lebih luas daripada Lisp dan ML.
erjiang
@erjian: FORTRAN mengalami inkompatibilitas karena ada insentif serius untuk: penggunaan bisnis. LISP, kebanyakan digunakan di bidang akademik, tidak pernah memiliki kemewahan itu. Yaitu bukan seberapa luas penggunaannya, tetapi seberapa makmur penggunanya.
MSalters
2
Atau, secara bergantian, varian tidak disebut FORTRAN. BASIC, ketika keluar, pasti terlihat seperti FORTRAN yang disederhanakan.
David Thornley
1
@Malters Common Lisp sebenarnya adalah upaya (cukup sukses IMO) untuk menuntaskan ketidakcocokan dalam berbagai dialek maclisp yang didikte antara lain oleh penggunaan bisnis (dan juga DARPA ingin semua laboratorium penelitian yang didanai untuk dapat berbagi kode lebih mudah) . Saat ini selain skema, clojure dan common lisp, tidak ada lisps tujuan umum yang praktis, dan ketiganya cukup berbeda, memiliki komunitas yang sangat terpisah dengan budaya dan sejarah yang terpisah untuk tidak menghitungnya sebagai dialek dengan bahasa yang sama lagi daripada java dan C ++. .
Pavel Penev
24

Mereka pada dasarnya semua bahasa yang didefinisikan implementasi

Ketika mudah untuk membuat implementasi baru dari suatu bahasa yang sebagian besar kompatibel dengan kode yang ada, kemudian peretas menjadi peretas, mereka melanjutkan dan melakukannya. Semua orang menulis implementasi Lisp di beberapa titik. Kompiler ML hampir wajib untuk mahasiswa pascasarjana dalam desain bahasa - bahasa ini didokumentasikan dengan baik .

Di sisi lain, kami memiliki bahasa ad hoc dan implementasi yang ditentukan. Atau bahasa yang begitu kompleks sehingga merupakan penghalang yang signifikan untuk menghasilkan implementasi alternatif yang layak:

  • rubi; perl; python - terlalu implementasi-didefinisikan untuk menghasilkan alternatif yang layak
  • ghc haskell dan erlang - terdefinisi dengan baik, tetapi sangat sulit untuk melakukan apa pun yang bersaing dengan ghc (atau erlang) sehingga orang biasanya tidak repot

Kelemahan yang tampaknya - bahasa yang terlalu sulit untuk menghasilkan alternatif yang layak untuk, memiliki sisi besar : sumber daya pengembang langka terkonsentrasi pada satu implementasi yang benar.

Sebagai catatan sejarah, beberapa di komunitas Haskell aktif melakukan merger dan konsentrasi upaya dev, mengakui bahwa setiap pemecah-belah komunitas dev akan berarti kita tidak akan berhasil. GHC dipilih dan diperjuangkan.

Don Stewart
sumber
2
Saya ingin tahu lebih banyak tentang "merger dan konsentrasi yang diupayakan secara aktif".
Sam Tobin-Hochstadt
Fragmentasi itu alami. Bahasa seperti Python dan Ruby adalah anomali yang kebetulan tidak terpecah pada main, jika Anda tidak menghitung varian yang tidak digunakan, misal ChinesePython, dan varian stagnan pada versi sebelumnya, misalnya Jython. Ada juga bias survivorship di sini, karena sebagian besar bahasa dengan diktator tidak menjadi sangat populer, misalnya Nermerle, Groovy, Beanshell, Boo, bahkan mungkin ada ribuan dari mereka.
Vorg van Geir
1
Meski begitu, Haskell masih bisa lebih praktis untuk mencapai status kedewasaan Python / Ruby. Haskell's cabalbukan alat yang menyenangkan untuk digunakan dan lebih mudah untuk di break :. Bahkan Yesod mengakuinya: yesodweb.com/blog/2012/04/cabal-meta Python dan Ruby jauh lebih baik dalam hal manajemen paket.
Ehtesh Choudhury
1
@Shurane Python dan Ruby jangan mengetik periksa paket Anda sebelum integrasi ...
Don Stewart
2
-1: untuk "ruby; perl; python - terlalu implementasi-didefinisikan untuk menghasilkan alternatif yang layak" Jython, IronPython, JRuby, IronRuby, PyPy, Stackless membuktikan Anda salah untuk implementasi (dan ini hanya yang utama). Juga, CPython adalah implementasi referensi, tetapi bukan definisi bahasa, ini
vartec
12

Saya akan mengatakan satu faktor adalah platform yang menentukan . Untuk Haskell platformnya adalah standar Haskell dan GHC (saya bayangkan). Untuk Ruby itu adalah Ruby on Rails yang "mendefinisikan" platform pengembangan Ruby. Untuk C itu adalah Unix.

Bandingkan dengan Lisp, di mana tidak ada platform kick-ass asli yang mendefinisikan seperti apa bahasa itu. Jika saya ingat dengan benar, setiap mesin Lisp memiliki sedikit perbedaan tergantung pada model dan pabrikannya. Lisp umum untuk beberapa alasan tidak mendefinisikan. Mungkin karena terlalu banyak kompetisi dan keengganan untuk pindah ke platform lain.

Ini, tentu saja, sepenuhnya spekulasi dari pihak saya. Pikiran itu berasal dari komentar balasan pada jawaban Harvey. Namun, tampaknya platform pendefinisian datang dalam banyak bentuk, tetapi properti yang umum tampaknya adalah yang mendapatkan popularitas.

Henrik Hansen
sumber
Saya sebenarnya suka ide ini. Saya dapat menggunakan banyak bentuk Lisp karena tidak ada yang memiliki "kerangka kerja pembunuh", tetapi jika saya ingin menggunakan Rails, saya harus tetap menggunakan Ruby kanonik. Tentu saja itu bukan satu-satunya jawaban, tapi saya suka hipotesis Anda.
chrisaycock
saya akan setuju pada bagian platform . Jika Anda memiliki satu penerjemah yang mampu menjalankan bahasa - tidak akan ada banyak fragmentasi.
c69
Cisp umum tidak menyelesaikan definisi tunggal lebih awal karena orang memiliki pendapat yang kuat tentang hal-hal tertentu, misalnya makro higienis.
Robert Harvey
Saya setuju dan tidak setuju dengan ini. Saya setuju karena 'kerangka kerja pembunuh' menambal bahasa inti dengan fungsionalitas yang berharga, mendorong pertumbuhan, dan memungkinkan inovasi cepat di luar spesifikasi standar. Saya tidak setuju karena, jika pengelola kerangka tidak terlalu berhati-hati, peningkatan inovasi yang cepat dapat menyebabkan banyak penggembungan dan / atau abstraksi bocor yang dapat membuatnya tidak stabil.
Evan Plaice
1
(lanjutan) Kerangka kerja seperti jQuery yang memperluas fungsionalitas inti bahasa idealnya akan mati di masa depan karena kontribusi paling berharga yang diberikan oleh kerangka kerja tersebut distandarisasi dan dimasukkan ke dalam inti. IMHO, kerangka kerja cenderung mati tercepat karena pengembang umumnya lebih suka untuk mengurangi / menghilangkan dependensi sebagai basis kode stabil. Jika pengembang bahasa ingin tetap relevan, mereka akan membuat proses itu lebih mudah dengan mengadaptasi dan mengadopsi fungsionalitas kerangka kerja, dan mendorong pengguna mereka untuk mengurangi ketergantungan pada kerangka kerja pihak ketiga.
Evan Plaice
7

Jangan lupa menimbang budaya yang mendorong perkembangan bahasa

Saya juga akan mempertimbangkan fakta bahwa pengembangan python / php secara aktif dilakukan di depan umum. Anda memiliki satu kelompok individu yang menetapkan spesifikasi standar yang tersedia secara bebas untuk siapa saja / semua orang.

Sama seperti W3C lakukan dengan standar HTML / CSS. Anda memiliki sekelompok kecil individu termotivasi yang mengontrol detail yang lebih halus dari apa yang dirancang untuk dicapai oleh bahasa tersebut. Semuanya masuk ke spesifikasi yang jelas sebelum dirilis ke publik.

OTOH, bahasa seperti LISP bercabang secara tertutup oleh profesor atau individu lain yang benar-benar percaya bahwa perspektif mereka tentang 'penggunaan terbaik' dari bahasa itu benar. Mereka mungkin secara simultan benar dan salah pada saat yang sama karena beberapa implementasi hebat dalam hal-hal tertentu; sementara tidak ada yang terbaik dalam segala hal.

Itu tidak selalu merupakan hal yang buruk karena keragaman melahirkan inovasi. Bahasa seperti LISP, dan akan tetap menjadi bahasa yang bagus untuk pembelajaran dan penelitian karena mereka mendorong batas-batas pemahaman.

Tetapi kualitas yang membuat lingkungan bagus untuk inovasi tidak selalu bermanfaat untuk stabilitas; sebaliknya, kualitas yang membuat lingkungan bagus untuk stabilitas tidak selalu bagus untuk kreativitas.

Ketika pengembangan didasarkan pada kolaborasi aktif, kadang-kadang individu terpaksa menyerah untuk kepentingan keseluruhan yang lebih besar. Buruk untuk penelitian / bagus untuk konsistensi.

Faktanya adalah, kita masih hidup di barat-liar pengembangan bahasa pemrograman. Masalah mendesain 'bahasa ideal' begitu hebat sehingga, meski ada upaya monumental, tidak ada yang bisa menyelesaikannya.

Di sektor penelitian / akademisi, masih ada banyak ruang untuk perbaikan dan inovasi. Di sektor komersial, di mana ada pertumbuhan eksponensial dari perangkat lunak yang digunakan dalam aplikasi praktis dan kekuatan pendorongnya adalah kesederhanaan dan konsistensi.

Beberapa bahasa mengkhususkan pada yang pertama, beberapa mengkhususkan pada yang kedua. Mereka yang mencoba untuk mengkhususkan pada keduanya biasanya tidak melakukan dengan sangat baik dan mati.

Dengan keduanya, saya mengacu pada bahasa monolitik seperti VB / C # / Java. Masih terlalu dini untuk mengatakannya tetapi saya ingin melihat seperti apa tampilan C # dan Python dalam 10 tahun. Pada kecepatan saat ini, C # meningkatkan fungsionalitas dan ketidakkonsistenan pada tingkat yang membuatnya terlihat sangat suram. Bahkan dengan dokumentasi yang bagus, terlalu merepotkan untuk mengingat semua detail halus dan keanehan yang termasuk dalam bahasa. Ini bagus untuk satu pengembang tetapi segera setelah Anda memasukkan lebih banyak pengembang dengan gaya yang unik, ketidakkonsistenan dalam basis kode bertambah, kualitas menderita, dan tidak ada yang menang. Saya pikir ada banyak yang harus dipelajari dari kesulitan yang dihadirkan Perl dalam lingkungan produksi.

Evan Plaice
sumber
Tangga? Apakah maksud Anda yang terakhir?
Giorgio
@Iorgio Ya, saya benci kalau saya salah mengeja itu.
Evan Plaice
2

Saya tidak berpikir itu benar untuk mengatakan bahwa bahasa-bahasa seperti Python dan Ruby tidak terfragmentasi. Kami sudah mulai melihat beberapa efek fragmentasi. Sebagai contoh, Python 3 tidak sepenuhnya kompatibel dengan Python 2, sehingga kedua versi perlu dipertahankan dan banyak kode yang ada hanya bekerja dengan Python 2. Ada juga beberapa spin-off Python, termasuk PyPy.

Faktor lain adalah usia bahasa. Yang paling banyak mengalami fragmentasi adalah bahasa-bahasa yang lebih tua dan karenanya tunduk pada tekanan evolusi dan revisi. Lisp diciptakan beberapa dekade yang lalu, jadi ada cukup waktu untuk mengambil beberapa idenya dan menggabungkannya ke dalam bahasa baru. C adalah contoh lain dari bahasa yang terfragmentasi. Sementara C hanya memiliki satu revisi besar untuk bahasa itu sendiri (K&R ke ANSI), ada banyak spin-off termasuk C ++, Not Quite C, dan semua yang lain yang menggunakan sintaksis mirip-C.

Ruby itu sendiri adalah "fragmentasi" (jika Anda mau) dari bahasa sebelumnya. Karena menggabungkan ide-ide dari C, Smalltalk, dan Perl (antara lain), saat ini bahasa yang melakukan fragmentasi. Saya tidak melihat mengapa kita mungkin tidak melihat lilitan Ruby selanjutnya dengan bahasa lain di masa depan.

Barry Brown
sumber
6
-1 karena: (1) Python 3.x bukan fragmentasi. Itu hanya langkah selanjutnya dalam evolusi bahasa; Python 2.x akan dihapus seluruhnya dalam beberapa tahun. (2) Implementasi bahasa lain yang 99% kompatibel (1% detail implementasi dan sebagian besar agak tidak jelas) dan secara aktif menolak mengambil bagian dalam mendefinisikan bahasa bukan fragmentasi. (3) Bahasa yang sangat berbeda yang berbagi kesamaan dan agak kompatibel (C ++ ke C) hampir tidak fragmentasi. (4) Menerima ide dari bahasa yang ada bukanlah fragmentasi, itu satu-satunya cara seseorang mendesain bahasa.
2
@delnan: Python 2.x akan dihapus seluruhnya dalam beberapa tahun? Itu agak konyol untuk dikatakan, ketika COBOL dan Fortran masih ada!
Mason Wheeler
3
@MasonWheeler saya berbicara tentang pengembangan. VCS akan tetap memiliki kode lama yang diarsipkan, unduhan biner tidak resmi mungkin akan bertahan selama beberapa dekade, dan beberapa toko mungkin menghindari porting. Tapi saya berharap bahwa suatu hari nanti tidak terlalu jauh, sebagian besar pemrograman Python terjadi di Python 3. Lagipula, pengembangan fitur 2.x berhenti beberapa saat yang lalu (dan tidak akan dilanjutkan kecuali Anda mencuci otak python-dev) , perbaikan bug / pembaruan keamanan tidak seharusnya dilanjutkan selamanya, dan sebagian besar pustaka dipindahkan ke Python 3 dengan sebagian besar yang lain menantikan (mis. Djano) atau tidak dirawat.
1
@MasonWheeler Oh, dan untuk Fortran dan COBOL: Fortran mendapat revisi standar baru 2008, dan COBOL mendapatkannya pada tahun 2002 dengan beberapa laporan teknis sejak itu.
@MasonWheeler Tahukah Anda bahwa COBOL modern memungkinkan pemrograman berorientasi objek?
2

Lisp terfragmentasi karena model yang begitu kuat, bahasa yang paling menakjubkan yang pernah dikandung. Sebagian besar bahasa saat ini meminjam hal-hal yang pertama kali diterapkan di Lisp, sehingga Anda dapat mengatakan bahwa setiap bahasa adalah bagian dari fragmentasi khusus ini. Smalltalk misalnya sangat terinspirasi oleh Lisp, dan Ruby sangat terinspirasi oleh Smalltalk. JavaScript adalah Lisp dalam penyamaran Java, dan sebagainya .. Semuanya terhubung, dan setiap penemu bahasa memilih karya favoritnya dari bahasa lain.

Faktor lain adalah bahwa Lisp mungkin adalah konsep pemrograman yang paling mudah untuk diterapkan - itulah sebabnya mengapa hal itu dilakukan berulang kali.

Torbjørn
sumber
1

Bahasa-bahasa seperti cebol terlalu mendasar dan teoretis untuk diubah secara dramatis. Perubahan tata bahasa (saya tidak bermaksud hanya mengubah nama-nama perintah) tidak akan cocok dengan teori pemrograman fungsional di belakangnya.

Tetapi fakta bahwa ada bahasa seperti lisp menunjukkan bahwa "perubahan" sudah dibuat menjadi lisp. Dengan kata lain, ada bahasa yang dibuat oleh orang-orang yang terinspirasi oleh lisp atau teorinya di baliknya dan membuat bahasa baru yang mirip dengan cara yang sama.

Ada juga banyak bahasa yang terinspirasi oleh Python. Misalnya Julia, CoffeeScript, dll. Yang akan membentuk keluarga mereka sendiri dari bahasa berorientasi objek spasi-putih.

Saya pikir, dasar-dasar dasar bahasa seperti Python tidak akan pernah benar-benar berubah. Python berorientasi objek dan karena itu memiliki kesamaan dengan C ++ dan Java tetapi dinamis dan karenanya juga mirip dengan banyak bahasa skrip.

Nah siapa sebenarnya yang peduli dengan bahasa? Yang penting adalah tujuannya: Bahasa Perancis mirip dengan bahasa Latin tetapi gadis-gadis yang mengerti bahasa Prancis jauh lebih panas;)

PSchwede
sumber