Jaga agar bahasa pemrograman tetap kompatibel dan tidak memperbaiki kekurangannya

Pertama, beberapa konteks (hal-hal yang sebagian besar dari Anda tahu):

Setiap bahasa pemrograman populer memiliki evolusi yang jelas, sebagian besar waktu ditandai oleh versinya: Anda memiliki Java 5, 6, 7 dll., PHP 5.1, 5.2, 5.3 dll. Melepaskan versi baru membuat API baru tersedia, memperbaiki bug, menambahkan fitur baru, kerangka kerja baru dll. Jadi semuanya: bagus.

Tapi bagaimana dengan masalah bahasa (atau platform)? Jika dan ketika ada sesuatu yang salah dalam suatu bahasa, pengembang menghindarinya (jika mereka bisa) atau mereka belajar untuk hidup dengannya.

Sekarang, para pengembang bahasa tersebut mendapatkan banyak umpan balik dari para programmer yang menggunakannya. Jadi masuk akal bahwa, seiring berjalannya waktu (dan nomor versi), masalah-masalah dalam bahasa-bahasa itu perlahan-lahan akan hilang. Yah, tidak juga. Mengapa? Kompatibilitas mundur, itu sebabnya. Tetapi mengapa demikian? Baca di bawah untuk situasi yang lebih konkret.

Cara terbaik saya bisa menjelaskan pertanyaan saya adalah dengan menggunakan PHP sebagai contoh:

PHP dicintai, dan dibenci oleh ribuan orang. Semua bahasa memiliki kekurangan, tetapi ternyata PHP itu spesial. Lihat posting blog ini . Ini memiliki daftar yang sangat panjang dari kekurangan yang disebut dalam PHP. Sekarang, saya bukan pengembang PHP (belum), tetapi saya membaca semua itu dan saya yakin bahwa sebagian besar daftar itu memang masalah nyata. (Tidak semuanya, karena berpotensi subyektif).

Sekarang, jika saya adalah salah satu dari orang-orang yang secara aktif mengembangkan PHP, saya pasti ingin memperbaiki masalah itu, satu per satu. Namun, jika saya melakukan itu, maka kode yang bergantung pada perilaku bahasa tertentu akan rusak jika berjalan pada versi baru. Ringkasnya dalam 2 kata: kompatibilitas ke belakang.

Yang tidak saya mengerti adalah: mengapa saya harus menjaga agar PHP tetap kompatibel? Jika saya merilis PHP versi 8 dengan semua masalah tersebut telah diperbaiki, tidak bisakah saya memberikan peringatan besar dengan mengatakan: "Jangan jalankan kode lama pada versi ini!"?

Ada hal yang disebut penghinaan. Kami memilikinya selama bertahun-tahun dan berhasil. Dalam konteks PHP: lihat bagaimana orang-orang saat ini secara aktif mencegah penggunaan mysql_*fungsi (dan sebagai gantinya merekomendasikan mysqli_*dan PDO). Penghentian bekerja. Kita bisa menggunakannya. Kita harus menggunakannya. Jika berfungsi untuk fungsi, mengapa itu tidak berfungsi untuk seluruh bahasa?

Katakanlah saya (pengembang PHP) melakukan ini:

• Luncurkan versi baru PHP (misalkan 8) dengan semua kekurangan itu diperbaiki
• Proyek-proyek baru akan mulai menggunakan versi itu, karena jauh lebih baik, lebih jelas, lebih aman, dll.
• Namun, agar tidak meninggalkan versi PHP yang lebih lama, saya terus merilis pembaruan untuk itu, memperbaiki masalah keamanan, bug dll. Ini masuk akal karena alasan saya tidak mendaftar di sini. Ini praktik umum: lihat misalnya bagaimana Oracle terus memperbarui versi 5.1.x dari MySQL, meskipun sebagian besar berfokus pada versi 5.5.x.
• Setelah sekitar 3 atau 4 tahun, saya berhenti memperbarui versi PHP lama dan membiarkannya mati. Ini bagus, karena dalam 3 atau 4 tahun itu, sebagian besar proyek akan beralih ke PHP 8.

Pertanyaan saya adalah: Apakah semua langkah ini masuk akal? Apakah akan sangat sulit untuk dilakukan? Jika itu bisa dilakukan, lalu mengapa itu tidak dilakukan?

Ya, sisi buruknya adalah Anda merusak kompatibilitas. Tapi bukankah itu harga yang pantas dibayar? Sebagai terbalik, dalam 3 atau 4 tahun Anda akan memiliki bahasa yang memiliki 90% dari masalahnya diperbaiki .... bahasa yang jauh lebih menyenangkan untuk digunakan. Namanya akan memastikan popularitasnya.

EDIT : OK, jadi saya tidak menyatakan diri dengan benar ketika saya mengatakan bahwa dalam 3 atau 4 tahun orang akan pindah ke hipotesis PHP 8. Apa yang saya maksudkan adalah: dalam 3 atau 4 tahun, orang akan menggunakan PHP 8 jika mereka memulai proyek baru.

Kedengarannya bagus, tetapi jarang berhasil dalam praktik; orang sangat enggan untuk mengubah kode yang sedang berjalan, dan bahkan untuk proyek lapangan hijau yang baru, mereka sangat enggan untuk beralih dari bahasa / versi yang sudah mereka ketahui.

Mengubah kode yang sudah ada dan berjalan yang "berfungsi dengan baik" bukanlah sesuatu yang berperingkat tinggi dalam daftar prioritas proyek mana pun. Alih-alih menerapkan upaya untuk hal-hal yang menurut manajer sudah dibayar, hanya untuk dapat meningkatkan ke rilis bahasa atau platform yang lebih baru, mereka akan memutuskan bahwa pengembang harus tetap pada rilis lama "untuk saat ini". Anda dapat mencoba memikat pengguna Anda dengan fitur-fitur hebat yang hanya tersedia di rilis baru, tetapi ini adalah pertaruhan di mana Anda berisiko mengurangi basis pengguna Anda tanpa ada keuntungan yang jelas untuk bahasa tersebut; keren, fitur modern tidak dapat dengan mudah ditimbang terhadap harga basis instalasi yang terfragmentasi dalam pendapat populer, dan Anda berisiko mendapatkan reputasi sebagai "upgrade treadmill"

(Jelas, sebagian besar ini tidak berlaku untuk proyek-proyek yang ditulis oleh penggemar hanya untuk kesenangan mereka sendiri. Namun (di sini ada flamebait ...) PHP secara tidak proporsional jarang dipilih oleh peretas karena itu adalah kesenangan untuk menulis. )

Anda meremehkan dampak kompatibilitas mundur; perkiraan Anda bahwa semua proyek aktif akan bermigrasi dalam 3 atau 4 tahun terlalu optimis.

Misalkan saya seorang pengembang PHP. PHP memiliki kekurangan, tapi saya tahu bagaimana mengatasi kekurangan itu - itulah bagian dari alasan mengapa saya dibayar sebagai pengembang PHP. Sekarang anggaplah PHP 8 keluar dan memperbaiki kekurangan itu, tetapi itu tidak kompatibel. Hasil dari:

• Saya harus menghabiskan waktu memperbarui kode untuk PHP 8. Saat itu saya bisa menghabiskan waktu menanggapi permintaan pelanggan, mengimplementasikan fitur-fitur baru, mengikuti kompetisi.
• Bahkan setelah saya melakukan ini , ada peluang bagus bahwa saya melewatkan beberapa kasus sudut atau masalah kompatibilitas yang tidak terduga, memperkenalkan bug dalam kode saya.

Mengingat hal ini, ada insentif kuat untuk tidak pernah bermigrasi ke PHP 8, meskipun itu "lebih baik, lebih jelas, lebih aman, dll." Diperkirakan masih ada milyaran garis COBOL (!) - walaupun jelas ada teknologi yang lebih baik, biaya pembaruan, dikombinasikan dengan risiko bug, hanya saja tidak membuatnya sepadan.

Kedua, bahkan jika saya memutuskan untuk memigrasi kode saya sendiri, aplikasi nontrivial apa pun bergantung pada perpustakaan pihak ketiga, dan tidak ada jaminan bahwa perpustakaan pihak ketiga akan bermigrasi. Misalnya, Python 3 dirilis pada Desember 2008, tetapi Django (mungkin kerangka kerja web Python terkemuka) tidak memiliki dukungan Python 3 yang stabil dan siap-produksi selama hampir lima tahun (lihat di sini dan di sini ).

Anda membuat banyak asumsi tentang perilaku manusia. Jika Anda mengubahnya terlalu banyak, orang akan mengevaluasi pesaing Anda, karena mereka akan tetap harus menghabiskan banyak upaya untuk beralih. Untuk bahasa open source, orang hanya akan menggunakan versi lama.

Lihatlah python sebagai contoh. 3.x telah tersedia selama empat tahun, dan masih belum diadopsi secara luas. Orang-orang mencoba menggunakannya untuk proyek-proyek baru, tetapi saya pikir Anda meremehkan berapa banyak pekerjaan kode pemeliharaan.

Tentu saja, kebanyakan orang tidak menganggap python 2.x sebagai "cacat." Mereka tidak memiliki keluhan seperti pengguna php. Php berada dalam posisi yang jauh lebih berbahaya, karena banyak orang hanya bertahan dengan itu karena basis kode yang ada yang besar. Jika Anda kehilangan kompatibilitas ke belakang, banyak orang akan mengambil kesempatan yang telah mereka tunggu untuk pindah ke python.

Untuk bahasa apa pun selain PHP saya akan mengatakan, ya, itu benar-benar masuk akal! Itulah yang dilakukan Python dengan beralih ke Python 3.

Namun, masalah dengan PHP adalah bahwa ada terlalu banyak kekurangan dengan desain bahasa itu sendiri, sehingga apa yang Anda sebut "PHP 8" akan menjadi bahasa yang sama sekali berbeda. Dan jika Anda harus beralih ke bahasa yang berbeda, mengapa Anda tetap menggunakan PHP baru, daripada alternatif yang ada dan stabil saat ini?

Komunitas PHP juga sangat lambat untuk mengadaptasi hal baru. Lihat saja berapa lama untuk dihilangkan register_globals. Sudah diketahui sebagai risiko keamanan sejak tahun 2000. Itu baru akhirnya dihapus 12 tahun kemudian. Contoh lain, ketika PHP5 diperkenalkan, ini merupakan peningkatan besar dibandingkan PHP4, namun komunitas tidak mengadaptasinya. Saya mengambil 4 tahun dan tindakan besar seperti GoPHP5 untuk memulai adopsi. Dan itu bahkan tidak memiliki sejumlah besar perubahan yang tidak kompatibel mundur.

Penafian: Saya mengelola grup pengguna ColdFusion.

ColdFusion menderita masalah yang sama: dicintai oleh banyak orang, dibenci oleh banyak orang. Selain itu, berton-ton FUD berdasarkan versi pra-Jawa. ColdFusion 10 keluar tahun lalu, adalah penjual besar dan minggu lalu saya mendaftar untuk menguji pra-rilis versi 11. Juga, ada dua alternatif sumber terbuka utama, satu didukung oleh JBoss.

Ada BANYAK fungsi baru di CF10 yang ingin saya terapkan, tetapi bermigrasi dari CF 7 atau 8 bisa sulit tergantung pada ukuran basis kode Anda, jumlah proyek yang akan datang dan sumber daya yang Anda miliki untuk regresi menguji semuanya setelah Anda sedang di versi terbaru. Saya telah mengalami sejumlah perbedaan sintaksis kecil antara 8 dan 9, serta kasus tepi di mana kode tidak mengkompilasi dengan cara yang sama. Setelah ditemukan, saya mendokumentasikannya ke dalam Standar Pengkodean kami sehingga tidak digunakan dalam proyek mendatang atau oleh pengembang baru.

Yang mengatakan, jika ColdFusion 11 (atau bahasa pemrograman apa pun) sepenuhnya menolak fungsi dan sintaksis tertentu, tingkat upaya untuk menemukan dan mengganti fungsionalitas bisa sangat besar. Upaya pengujian bisa jadi sangat besar. Akankah perusahaan membayar pengembang mereka, QA dan manajer proyek untuk menemukan, mengganti, dan menguji semua hal yang sudah usang itu? Diragukan.

Jika versi terbaru dari suatu bahasa kompatibel ke belakang, tetapi memperkenalkan peningkatan kinerja tanpa perubahan kode (CF9 sekitar 30% lebih cepat dari CF8 dan CF10 jauh lebih cepat dari CF9), siapa yang peduli dengan perubahan panggilan fungsi jika masih berfungsi?

Sebagai perusahaan, kita harus khawatir tentang menyenangkan klien kita dan memenuhi kebutuhan mereka untuk menagih layanan, membangun bisnis dan merekrut lebih banyak klien.

FWIW, saya ingin membawa kita ke versi terbaru jQuery di beberapa titik, tetapi karena fungsi-fungsi tertentu tidak digunakan lagi beberapa versi setelah apa yang kita gunakan, dan mengingat volume JavaScript yang kita miliki dalam sistem, saya tidak tahu caranya kita akan melakukan itu.

Ada kompromi di sini; beberapa bug BENAR-BENAR perlu diperbaiki, tetapi beberapa hal tidak dapat diubah tanpa merusak kode seseorang di suatu tempat. Sepertinya saya ingat seseorang yang menyatakan sebagai "aturan" bahwa setiap perbaikan bug akan merusak proyek seseorang, tidak peduli seberapa jelas atau rusaknya bug itu, seseorang akan menggunakannya untuk sesuatu. Begitulah sifat programmer.

Inilah (menurut saya) perbedaan antara rilis utama, rilis minor, dan revisi. Sebagai prinsip umum:

• Rilis besar diasumsikan mengandung perubahan yang melanggar.
• Rilis minor mungkin sedikit mengubah perilaku.
• Revisi harus cukup kompatibel lintas.

Sebagai contoh, jika saya menulis sesuatu dalam v2.3 bahasa, saya tidak akan berharap untuk melihat perbedaan jika saya meningkatkan ke v2.3.2. Jika saya memutakhirkan ke v2.4, maka beberapa hal mungkin berubah - tweak sintaks kecil, beberapa fungsi berperilaku sedikit berbeda sehingga saya harus mengubah logika, dll. Jika saya memutakhirkan ke v3.0, saya tidak akan terkejut jika rusak sepenuhnya - fungsi yang ditinggalkan atau hilang, operasi tidak didukung atau berubah begitu banyak sehingga saya tidak bisa hanya men-tweak kembali ke jalur, saya benar-benar harus menulis ulang beberapa fungsi untuk memperhitungkan perubahan baru.

Sunting:

Makalah Steve Vance Advanced SCM Branching Strategies mengatakan:

Biasanya, ada dua atau tiga tingkat rilis, dinamai dengan angka yang terhubung dengan titik (mis 1.2.2). [...] Dalam struktur ini angka pertama dikaitkan dengan versi utama, yang menunjukkan bahwa ia memiliki fitur signifikan dan peningkatan fungsional dari sebelumnya; mungkin juga ada ketidaksesuaian yang signifikan yang memerlukan migrasi. Angka kedua merupakan versi minor, yang berisi peningkatan fitur dan fungsi yang lebih sedikit, sejumlah besar perbaikan bug, dan tidak ada yang tidak kompatibel. Angka ketiga mengacu pada tingkat tambalan, menandakan hampir secara eksklusif kumpulan perbaikan bug; tidak ada peningkatan fitur atau fungsi dan tidak ada ketidakcocokan yang diizinkan antara tingkat tambalan.

Satu-satunya perubahan yang saya buat untuk ini adalah prinsip yang disebutkan di atas bahwa programmer sering menemukan cara untuk "menggunakan" bug, jadi versi minor dengan "sejumlah besar perbaikan bug, dan tidak ada ketidaksesuaian" mungkin sulit, karena kemungkinan bahwa bug akan merusak sesuatu yang menggunakannya, atau akan menyebabkan solusi menjadi tidak perlu dan mulai menyebabkan masalah.

Itu benar-benar tergantung pada apa target bahasa - jenis aplikasi apa yang dimaksudkan untuk dibangun dengan bahasa.

Misalnya, mengabaikan Android, Java sebagian besar digunakan dalam sistem perusahaan besar dan perangkat menengah; jenis aplikasi ini cenderung menjadi sangat besar baik dalam ukuran maupun waktu. Ini memiliki beberapa implikasi; bayangkan sebuah sistem dengan 500K + LoC di mana pekerja 50+ insinyur dalam fase pengembangan. Biasanya jenis sistem ini masuk dalam pemeliharaan setelah ini dengan mengatakan 10 pengembang; sekarang jika bahasa berubah dan perubahan tidak kompatibel ke belakang proyek tidak dapat dengan mudah dimigrasi ke versi baru karena programmer yang menulis beberapa bagian hilang dan tidak ada yang mau menyentuhnya. Ini adalah masalah yang lebih kecil, masalah yang lebih besar terdiri dari kenyataan bahwa agak mahal untuk mengadaptasi aplikasi 500 LoC ke kendala bahasa baru. Sebagai contoh jika obat generik tidak diimplementasikan dengan tipe erasure danList list = new List(); tidak akan mengkompilasi jutaan baris kode yang perlu ditulis ulang - yang merupakan biaya besar.

Di sisi lain PHP cenderung digunakan di web untuk aplikasi yang lebih sederhana; biasanya ini dikembangkan oleh programmer tunggal atau tim kecil. Idenya adalah bahwa pengembang semacam tahu seluruh proyek dengan cukup baik dapat mengintegrasikan perubahan bahasa dengan lebih mudah. Juga tujuannya adalah untuk membangun sebuah situs yang sangat cepat, dan semakin cepat semakin baik sehingga jika fitur bahasa baru dapat melakukan ini dengan lebih baik maka itu diterapkan bahkan pada beberapa biaya kompatibilitas ke belakang.

Orang dapat berargumen bahwa Microsoft melakukan perubahan yang serupa dengan ASP.NET (sebagai penerus ASP klasik) atau dengan VB.NET (meskipun mereka membuat begitu banyak konsesi dengan yang terakhir sehingga sebagian besar manfaat "me-reboot" bahasa hilang).

Bagaimanapun, jika ada yang ingat mimpi buruk dari migrasi kode VB6 ke VB.NET bahkan dengan bantuan alat migrasi, mereka akan langsung setuju bahwa alat migrasi bahasa tidak bekerja dengan sangat baik untuk pembaruan bahasa utama.

Dimungkinkan untuk menggerakkan platform ke depan tetapi, Anda harus tetap memberikan dukungan untuk API yang "tidak digunakan" melalui setidaknya beberapa revisi.

Banyak "kekurangan" yang diteriaki orang-orang dalam bahasa pemrograman populer bukan, itu adalah hal-hal mainan favorit screamer pada saat itu yang tidak memiliki bahasa itu, OLEH KARENA ITU bahwa bahasa pada dasarnya cacat karena kekurangan itu.
Hype berikutnya muncul, bahasa tiba-tiba cacat karena tidak mematuhi hype itu.

Kurangnya penutupan di Jawa adalah contoh klasik. Itu bukan cacat dalam bahasa sama sekali, dan mengubah bahasa (seperti yang sayangnya dalam agenda) untuk memasukkan mereka akan secara mendasar melumpuhkan IMO atau setidaknya membuatnya lebih sulit untuk dibaca dan dipahami.

Apa yang terlalu banyak orang lupakan adalah bahwa setiap bahasa memiliki kekuatan dan kelemahannya dan bahwa mencoba untuk menciptakan sesuatu yang menggabungkan kekuatan dari segala hal sambil menghindari setiap kelemahan hanya akan menciptakan monster yang sama sekali tidak dapat digunakan yang bagus dalam hal apa pun, sangat sulit digunakan, tidak mungkin untuk gunakan secara efektif.

Tambahkan, seperti yang orang lain tunjukkan, bahwa kompatibilitas ke belakang sangat penting untuk mempertahankan pengguna yang sudah ada, banyak dari mereka TIDAK akan menghabiskan ribuan jam dan jutaan dolar / Euro untuk memperbaiki jutaan basis kode baris mereka ke apa pun yang Anda anggap "lebih baik" daripada versi bahasa yang telah mereka gunakan selama bertahun-tahun, dan Anda memiliki sejumlah argumen yang sangat bagus untuk dibiarkan begitu saja dan jika Anda ingin bermain dengan beberapa ide overhyped baru yang seharusnya menjadi "java killer" berikutnya, Anda ' Saya lebih baik bermain dengan mainan itu daripada berteriak bahwa "Java iz ded" kecuali "diperbaiki" untuk menjadi klon dari mainan itu.

Saya akan menyarankan bahwa versi bahasa yang lebih baru harus berusaha untuk memastikan bahwa 99,99999% kode yang mengkompilasi dalam versi bahasa lama dan baru harus bekerja secara identik di keduanya kecuali itu sengaja dirancang untuk tidak melakukannya, dan sebagian besar waktu ketika versi baru menolak kode yang dikompilasi di bawah versi lama, itu karena kode itu - paling-paling - cerdik, dan seharusnya ditulis dengan cara yang berbeda yang akan dikompilasi di bawah kompiler lama dan baru.

Misalnya, jika saya mendesain bahasa baru yang mirip dengan Java atau C #, saya akan melarang konversi tipe implisit dalam beberapa konteks di mana bahasa tersebut memungkinkan mereka. Sebagai contoh sederhana dalam C #, diberikan

int someInt;
double someDouble;

ekspresi someInt.Equals(someDouble)dijamin menghasilkan false, terlepas dari isi variabel. Itu mengkompilasi karena doubledapat dikonversi ke Object, dan intmemiliki Equalskelebihan untuk jenis itu, sehingga kompiler melakukan konversi dan membuat panggilan. Jika saya merancang versi baru C # dan .NET Framework, saya akan melarang konversi tinju karena tidak mungkin melakukan hal yang berguna. Mungkin saja ada beberapa program yang melakukan perbandingan sedemikian rupa dengan cara yang tidak berguna tetapi tidak berbahaya, dan membuat kompiler menolak kode seperti itu dapat merusak program itu, tetapi memperbaiki atau menghapus kode yang tidak berguna tersebut akan menjadi peningkatan.

Sebagai contoh yang kurang jelas, asumsikan

float f=16777216f;
int i=16777217;

dan pertimbangkan ungkapannya f==i. Ada kemungkinan bahwa beberapa kode melakukan perbandingan float / integer dan bekerja dengan benar, tetapi kode harus ditulis ulang sebagai baik f==(float)i, (double)f==i;atau (double)f==(double)i;[ intuntuk doublepromosi adalah lossless, sehingga dua terakhir akan setara]. Beberapa kode yang secara langsung membandingkan floatdan integernilai - nilai mungkin selalu berurusan dengan angka-angka yang cukup kecil sehingga floatdan doubleperbandingan akan berperilaku identik, tetapi kompiler umumnya tidak dapat mengetahuinya; kode harus memperjelas perbandingan apa yang dibutuhkan, daripada berharap aturan bahasa akan cocok dengan niat programmer.

Yang terbaik adalah tidak pernah merusak kompatibilitas.

Microsoft mengganti bahasa pemrograman VB6 dengan bahasa baru yang benar-benar merusak kompatibilitas. Jadi bahkan hari ini VB6 yang berusia 16 tahun masih lebih populer daripada versi dotNet (indeks Tiobe Agustus 2014). Dan Gartner memperkirakan ada 14 miliar baris kode VB6 yang masih digunakan.

Pada 2014 Microsoft sekali lagi harus mengumumkan mereka tidak akan memperbarui atau open source VB6 meskipun ada tuntutan dari komunitas pemrograman Visual Basic. Tetapi mereka telah memperpanjang dukungan VB6 hingga 'setidaknya' 2024, dan berfungsi baik pada Windows 7 dan 8. Itu akan lebih dari 26 tahun dukungan untuk versi VB6 yang sama.

Mengapa perangkat lunak yang ada harus ditulis ulang, bahkan Microsoft tidak pernah "memperbarui" Office untuk menggunakan dotNet?

Ada beberapa masalah dengan pemecahan kompatibilitas. Beberapa masalah berasal dari kenyataan bahwa sebagian besar bahasa pemrograman juga platform (juru bahasa / runtime), masalah lain berasal dari asumsi sifat manusia.

A. Kode yang ditulis dalam versi yang lebih lama tidak akan mendapatkan manfaat dari rilis baru yang meningkatkan kinerja, keamanan, atau fitur. Anda dapat mengurangi masalah ini dengan mendukung beberapa versi utama dari kompiler / juru bahasa, tetapi itu adalah sumber daya yang sangat besar (yaitu mahal atau membutuhkan waktu lama, dan itu menyebalkan).

B. Kode yang ditulis untuk versi yang lebih baru mungkin tidak kompatibel dengan kode yang ditulis dalam versi yang lebih lama. Anda dapat mengatasi ini dengan memiliki juru bahasa / kompiler yang dapat menangani beberapa versi utama bahasa, tetapi ini lebih menyebalkan daripada mendukung penerjemah / kompiler yang terpisah (solusi untuk A).

C. Perubahan besar, jika itu terjadi terlalu sering / cepat juga hanya membuat bahasa lebih sulit untuk digunakan, karena Anda harus lebih banyak belajar dan melepaskan pelajaran. Perubahan pada suatu bahasa mungkin mendorong orang-orang di tepi untuk beralih ke bahasa baru, atau mungkin menyebabkan orang untuk terus menggunakan versi bahasa yang sudah ketinggalan zaman dan tidak pernah beralih ke versi yang baru (seperti yang terjadi dengan python). Kemudian lagi, perubahan juga dapat menarik pengguna baru dan membangkitkan yang lama.

D. Dokumentasi baru perlu disimpan dan dipelihara. Selalu merupakan pengalaman yang agak membingungkan untuk mencari hal-hal di google dan menemukan bahwa Anda membaca dokumen untuk versi yang berbeda dari yang saat ini Anda gunakan.

Pada umumnya, jika Anda membuat bahasa pemrograman di mana modul-modul eksternal tidak harus peduli versi apa yang Anda gunakan, memecah kompatibilitas ke belakang untuk alasan yang tepat (untuk memperbaiki kekurangan utama dalam bahasa) hampir pasti adalah hal yang tepat untuk dilakukan . Kemungkinan alasan utama ini tidak dilakukan adalah bahwa desainer bahasa pemrograman melebih-lebihkan ( untuk bertentangan dengan jawaban orang lain ) biaya melanggar kompatibilitas, terutama sejak awal. Faktanya adalah, masalah pemecahan kompatibilitas dapat diselesaikan atau diberdayakan oleh pengguna bahasa itu. Dan ini tidak hanya berlaku untuk bahasa pemrograman; ini berlaku untuk API, antarmuka pengguna - benar-benar antarmuka apa pun dalam situasi apa pun.

Facebook menjengkelkan orang-orang ketika ia mengubah UI-nya, atau API pengembangnya. Di masa lalu, ini membuat platform sulit untuk dikerjakan. Dalam beberapa kasus, API berhenti bekerja secara tiba-tiba. Tetapi orang-orang terus menggunakannya, dan sekarang API dan UI lebih cepat daripada 5 tahun yang lalu. Orang akan mengeluh tentang perubahan apakah itu baik atau buruk bagi mereka, tetapi itu (mengeluh) bukan alasan yang baik untuk melupakan perubahan itu. Sayangnya, pengembang bahasa pemrograman menggunakan ini sebagai alasan untuk menjaga masalah bahasa mereka tetap utuh.

Jadi, beberapa alasan lain untuk bahasa yang tidak membuat perubahan untuk memperbaiki diri adalah:

E. Pengembang bahasa berpikir bahwa pengguna mereka takut akan perubahan adalah alasan yang bagus untuk menghentikan bahasa mereka

F. Pengembang bahasa agak menyukai bahasa mereka ketika mereka membuatnya, dan mereka mungkin berpikir itu baik-baik saja dengan kekurangannya.

G. Bahasa seiring bertambahnya usia biasanya tidak lagi memiliki sekelompok kecil pengembang inti, dan berubah menjadi lebih banyak binatang buas yang dibangun oleh komite. Ini berarti keputusan tentang bahasa-bahasa itu lambat dan seringkali konservatif dan tidak kreatif.

H. Alasan terakhir adalah bahwa beberapa perubahan pemecah memerlukan evaluasi ulang yang signifikan terhadap keputusan desain yang dibuat untuk juru bahasa / runtime. Terkadang perbaikan bahasa hanya membutuhkan kerja terlalu banyak untuk dapat dilakukan. Saya kira ini adalah masalah yang lebih jarang daripada kebanyakan tho.

Seringkali, perancang bahasa tidak harus perancang alat, sehingga mereka tidak memikirkan solusi yang baik untuk masalah ini, atau mereka tidak menjalankannya dengan baik. Berikut adalah beberapa solusi yang dapat saya pikirkan untuk memecahkan masalah pemecahan-perubahan:

1. Jelekkan hal-hal di depan saat mereka akan dihapus

2. Menyediakan baik , alat converter standar. Python menyediakan alat 2to3, tapi itu tidak diiklankan dengan baik, tidak datang standar dengan python 3 seperti yang saya ingat, dan bahkan tidak bekerja dengan baik (saya ingat harus secara manual melalui program yang dihasilkan oleh 2to3 untuk memperbaiki masalah itu tidak memperbaiki). Alat konverter ini bahkan dapat dijalankan secara otomatis jika kompiler / juru bahasa Anda mendeteksi versi yang lebih lama. Apa yang bisa lebih mudah?

Saya tidak tahu apakah itu masalah untuk kode PHP, tetapi dalam banyak bahasa lama, kode lama tidak pernah diperbarui setelah bertahun-tahun atau, kadang-kadang, bahkan beberapa dekade, karena berfungsi, sangat penting untuk bisnis yang menjalankannya dan terlalu besar (katakanlah jutaan SLOC), jadi tidak masuk akal untuk menulis ulang. Itulah alasan mengapa java membuat keterbelakangan-belakang menjadi isu yang hampir religius, meskipun tahu masalah lama, terutama di perpustakaan (bahkan jika mereka lebih mudah diperbarui). Saya kira banyak kode dari kernel Linux tidak diperbarui selama beberapa dekade juga, meskipun adopsi standar seperti C99 dan C11.

Bahkan dalam bahasa yang kurang "berwirausaha", melanggar kode fungsional lama bisa menjadi masalah. Itulah yang terjadi dengan Python 2 -> 3. Sejumlah perpustakaan dan skrip sistem stabil dan tidak dipelihara lagi, bukan karena mereka ditinggalkan tetapi karena mereka stabil dan melakukan pekerjaan mereka. Mengadaptasi mereka membutuhkan waktu beberapa tahun. Jadi, sebagai pengembang, Anda tidak dapat langsung beralih ke python 3 jika pustaka favorit Anda belum pindah, jadi kode Anda sendiri tidak akan berfungsi di bawah python 3, sehingga mengakibatkan fragmentasi komunitas.

Masalahnya terletak pada masalah kompatibilitas ke belakang. Sebagian besar skrip PHP yang saya jalankan dijalankan pada server RedHat yang lebih lama. Jika saya menggunakan versi bahasa yang lebih baru untuk skrip yang akan datang, maka saya harus memperbarui PHP di server ini - dan menjalankan risiko rusaknya skrip lama saya / harus menghabiskan waktu berjam-jam untuk menulis ulang semua kode lama dengan standar baru. Plus, semua pengembang saya terbiasa dengan PHP bereaksi dengan cara tertentu (apakah cara itu 'rusak' atau tidak). Jika tidak lagi bereaksi seperti itu, itu bisa menjadi rintangan utama untuk produktivitas, karena pengembang mungkin harus mengajar ulang diri mereka sendiri pada PHP.