Apakah ada mekanisme untuk membuat bahasa pemrograman lebih stabil (kompatibel) untuk perubahan?

Ada sejumlah besar bahasa pemrograman. Beberapa dari mereka tumbuh dan menjadi sangat populer. Orang-orang menggunakan bahasa seperti itu semakin sering. Pendiri bahasa tersebut (atau organisasi / komunitas pendiri) dapat mencoba menerapkan perubahan untuk menjadikan bahasa lebih baik. Tetapi kadang-kadang sulit untuk membuat beberapa perubahan karena kompatibilitas ke belakang dan hal-hal buruk seperti itu sudah ada dalam bahasa selama bertahun-tahun, dan digunakan oleh banyak pengguna.

Apakah ada prinsip atau langkah arsitektur, selama fase desain bahasa, yang dapat membantu membuatnya lebih stabil sehingga perancang bahasa tidak akan takut untuk merusak kompatibilitas ke belakang?

Stabilitas bahasa bukanlah keputusan teknis. Ini adalah kontrak antara penulis bahasa dan pengguna.

Penulis mengiklankan versi yang diberikan kurang lebih stabil. Semakin kurang stabil suatu bahasa, semakin banyak perubahan yang dapat penulis lakukan. Setiap pengguna yang tertarik dengan bahasa tersebut dapat memutuskan apakah ia ingin menginvestasikan waktu di dalamnya untuk mempelajari fitur baru atau mengembangkan aplikasi yang mungkin rusak oleh pembaruan bulan depan.

Menggunakan bahasa yang tidak stabil dapat menarik karena Anda tertarik dengan konsep baru, atau Anda ingin membantu dengan memberikan umpan balik. Jika Anda seorang bisnis, Anda mungkin lebih suka menunggu teknologi menjadi lebih stabil sebelum menginvestasikan waktu Anda di dalamnya. Anda lebih peduli tentang hal-hal seperti waktu ke pasar, dan pengalaman pengguna.

Jadi ini adalah masalah komunikasi & kepercayaan. Lihatlah perkembangan bahasa karat. Mereka sangat jelas tentang apa yang mereka ubah dan apa yang mereka pertahankan. Ketika mereka ingin menunda keputusan tentang fitur yang diberikan, mereka menggunakan apa yang mereka sebut gerbang fitur. Di sisi lain, tim sudut menghadapi banyak kemarahan atas pengumuman 2.0 mereka karena perubahan lebih besar dari yang diharapkan.

Bahkan penulis perpustakaan harus berkomunikasi tentang stabilitas apis mereka. Hampir semua teknologi yang digunakan oleh orang lain harus mencapai keseimbangan antara stabilitas dan kesempurnaan. Pembuat mobil tidak dapat mengubah posisi pedal, dan perancang laptop tidak akan menemukan tata letak keyboard baru karena alasan yang sama: Anda tidak membantu pengguna Anda jika Anda tidak dapat membuat keputusan tentang cara mereka akan menggunakan produk Anda.

• Ketahuilah bahwa bahasa berubah sepanjang hidup mereka, terlepas dari seberapa baik bahasa itu dirancang di muka. Alih-alih mencoba untuk segera mengirimkan bahasa yang paling mengagumkan di dunia, pertama-tama cobalah untuk menjadi berguna dan dapat dikembangkan. Bahasa yang biasa-biasa saja yang saya benar-benar dapat gunakan bernilai lebih dari bahasa pemrograman indah yang hanya ada dalam teori.

• Pertimbangkan fasilitas untuk membuat sintaksis dapat diperluas, misalnya makro. Makro tidak secara otomatis merupakan hal yang baik dan dapat menjadi terlalu kuat. Beberapa bahasa memiliki sintaks yang sangat fleksibel sejak awal yang mengurangi kebutuhan makro. Beberapa skenario untuk dipertimbangkan:

  • Bisakah saya memperkenalkan operator baru seperti |>tanpa meninggalkan bahasa? Bisakah saya memilih prioritas dan asosiasi untuk operator ini?
  • Berapa banyak upacara yang harus saya lalui untuk fungsi inline / lambda / closure?
  • Bisakah saya menggunakan sintaks bahasa yang ada untuk mengimplementasikan sintaks foreach loop? Misalnya Ruby dan Scala dapat melakukan ini melalui sintaksis metode panggilan fleksibel mereka dengan lambdas.

• Pertimbangkan fasilitas untuk menjaga semantik tetap dapat diperluas. Kebutuhan umum adalah:

  • Operator overloading, di mana tipe yang ditentukan pengguna dapat memberikan artinya sendiri kepada operator yang ada. Hal ini membuat bahasa menjadi jauh lebih menyenangkan dalam aplikasi matematika yang berat.
  • Kelebihan muatan literal. Bisakah saya membuat string literal menjadi tipe string saya sendiri? Bisakah saya membuat semua literal angka dalam lingkup saat ini menjadi bignum?
  • Protokol metobject. Jika bahasa tidak memiliki sifat, dapatkah saya menerapkannya di dalam sistem objek saat ini? Bisakah saya menerapkan urutan resolusi metode yang berbeda? Dapatkah saya menukar cara benda disimpan atau bagaimana metode dikirim?
• Lakukan tes regresi. Banyak tes. Tidak hanya ditulis oleh perancang bahasa, tetapi juga oleh pengguna. Saat menambahkan fitur, hentikan pengujian ini, pertimbangkan dengan cermat manfaat fitur tersebut dibandingkan dengan manfaat kompatibilitas mundur.
• Versi bahasa Anda. Tidak hanya dalam dokumentasi Anda, tetapi juga dalam kode sumber itu sendiri. Setelah Anda melakukannya, satu-satunya bagian dari bahasa Anda yang tidak dapat diubah adalah sintaksis pragma versi ini. Contoh: Racket memungkinkan Anda menentukan dialek. Perl memungkinkan Anda untuk use v5.20, yang memungkinkan semua fitur Perl v5.20 yang tidak kompatibel ke belakang. Anda juga dapat memuat satu fitur yang disukai secara eksplisit use feature 'state'. Mirip: Python from __future__ import division.
• Pertimbangkan mendesain bahasa Anda sedemikian rupa sehingga menghasilkan beberapa kata yang dilindungi. Hanya karena classmemperkenalkan kelas tidak menyiratkan bahwa saya tidak akan dapat memiliki variabel lokal bernama class. Dalam praktiknya, ini menghasilkan kata kunci yang memperkenalkan deklarasi variabel atau metode, berlawanan dengan tradisi C-like menggunakan nama jenis untuk memperkenalkan deklarasi. Alternatif lain adalah menggunakan sigils untuk Anda $variables, seperti di Perl dan PHP.

Sebagian dari jawaban ini dipengaruhi oleh ucapan Guy Steele “Growing a Language” (1998) ( pdf ) ( youtube ).

Saya pikir langkah yang cukup penting adalah mempromosikan manajer paket yang juga dapat mengelola versi bahasa itu sendiri.

Misalnya, saya menggunakan SBT untuk Scala atau Leiningen untuk Clojure. Keduanya izinkan saya menyatakan versi bahasa yang ingin saya gunakan, per proyek . Jadi, cukup mudah untuk memulai proyek ramah lingkungan dalam versi bahasa terbaru, sambil meningkatkan proyek yang ada dengan langkah yang lebih nyaman, jika pernah.

Tentu saja, tergantung pada bahasanya, ini mungkin masih meninggalkan Anda dengan kebutuhan untuk menunggu pustaka yang relevan untuk diangkut ke versi yang Anda butuhkan (ini terjadi, misalnya, di Scala), tetapi tetap membuat segalanya menjadi lebih mudah.