Mengapa bahasa pemrograman lama terus direvisi?


46

Pertanyaan ini bukan, "Mengapa orang masih menggunakan bahasa pemrograman lama?" Saya mengerti itu dengan cukup baik. Sebenarnya dua bahasa pemrograman yang saya tahu paling baik adalah C dan Skema, yang keduanya berasal dari tahun 70-an.

Baru-baru ini saya membaca tentang perubahan C99 dan C11 versus C89 (yang tampaknya masih menjadi versi C yang paling banyak digunakan dalam praktik dan versi yang saya pelajari dari K&R). Melihat sekeliling, sepertinya setiap bahasa pemrograman yang banyak digunakan mendapat spesifikasi baru setidaknya sekali dalam satu dekade. Bahkan Fortran masih mendapatkan revisi baru, terlepas dari kenyataan bahwa kebanyakan orang menggunakannya masih menggunakan FORTRAN 77.

Bandingkan ini dengan pendekatan, katakanlah, sistem pengaturan huruf TeX. Pada tahun 1989, dengan rilis TeX 3.0, Donald Knuth menyatakan bahwa TeX adalah fitur-lengkap dan rilis masa depan hanya akan berisi perbaikan bug. Bahkan lebih dari ini, ia telah menyatakan bahwa setelah kematiannya, "semua bug yang tersisa akan menjadi fitur" dan sama sekali tidak ada pembaruan lebih lanjut akan dibuat. Yang lain bebas untuk memotong TeX dan telah melakukannya, tetapi sistem yang dihasilkan diganti namanya untuk menunjukkan bahwa mereka berbeda dari TeX resmi. Ini bukan karena Knuth menganggap TeX itu sempurna, tetapi karena ia memahami nilai sistem yang stabil dan dapat diprediksi yang akan melakukan hal yang sama dalam lima puluh tahun seperti yang dilakukannya sekarang.

Mengapa sebagian besar perancang bahasa pemrograman tidak mengikuti prinsip yang sama? Tentu saja, ketika suatu bahasa relatif baru, masuk akal bahwa itu akan melalui periode perubahan yang cepat sebelum menetap. Dan tidak ada yang bisa benar-benar keberatan dengan perubahan kecil yang tidak melakukan lebih dari kodifikasi standar pseudo yang ada atau mengoreksi pembacaan yang tidak diinginkan. Tetapi ketika suatu bahasa tampaknya masih perlu perbaikan setelah sepuluh atau dua puluh tahun, mengapa tidak hanya garpu atau mulai lagi, daripada mencoba mengubah apa yang sudah digunakan? Jika beberapa orang benar-benar ingin melakukan pemrograman berorientasi objek di Fortran, mengapa tidak membuat "Objective Fortran" untuk tujuan itu, dan meninggalkan Fortran sendiri?

Saya kira orang bisa mengatakan bahwa, terlepas dari revisi di masa depan, C89 sudah menjadi standar dan tidak ada yang menghentikan orang untuk terus menggunakannya. Ini agak benar, tetapi konotasi memang memiliki konsekuensi. GCC akan, dalam mode pedantic, memperingatkan tentang sintaksis yang sudah usang atau memiliki makna yang agak berbeda di C99, yang berarti programmer C89 tidak bisa sepenuhnya mengabaikan standar baru. Jadi harus ada beberapa manfaat dalam C99 yang cukup untuk memaksakan overhead ini pada semua orang yang menggunakan bahasa

Ini adalah pertanyaan nyata, bukan undangan untuk berdebat. Jelas saya memang memiliki pendapat tentang ini, tetapi saat ini saya hanya mencoba untuk memahami mengapa ini bukan hanya bagaimana hal sudah dilakukan. Saya kira pertanyaannya adalah:

Apa keuntungan (nyata atau yang dirasakan) dari memperbarui standar bahasa, sebagai lawan dari menciptakan bahasa baru berdasarkan yang lama?


2
Banyak kompiler yang dapat dipanggil dengan sakelar yang akan menegakkan standar yang lebih lama (mis. --std=xSakelar GCC ), jadi bukan berarti menciptakan hasil standar yang lebih baru pada alat yang membuat kestabilan kode lama.
Blrfl

2
Bagaimana Anda mendefinisikan "bahasa baru berdasarkan yang lama"? Saya berpendapat Fortran 90 adalah "bahasa baru" berdasarkan F77 lama. Itu benar-benar mengubah cara Anda memprogram - memperbaiki vs sumber bebas, dinamis vs memori statis, dll. Anda juga bisa berpendapat bahwa Fortran 2003 adalah "bahasa baru" berdasarkan F90 - ia menambahkan pemrograman berorientasi objek sambil mempertahankan kompatibilitas dengan F90. Kedengarannya seperti hubungan antara C ++ dan C.
tpg2114

1
Saya pikir pertanyaan ini sangat penting dan saya tidak mengerti mengapa beberapa orang ingin menutupnya. Ini adalah fenomena yang sangat menarik yang mungkin memiliki beberapa penjelasan. Beberapa (20?) Tahun yang lalu saya membaca tentang fitur-fitur baru dari Fortran dan bertanya pada diri saya: jika programmer Fortran membutuhkan fitur-fitur ini, mengapa mereka tidak beralih ke C? Baru-baru ini saya memiliki pertimbangan serupa mengenai C ++: jika pengembang C ++ ingin menggunakan lambdas, mengapa tidak beralih ke, katakanlah, OCaml ( linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php )? Mengapa mereka lebih suka membuat bahasa baru dan masih menyebutnya C ++?
Giorgio

3
@ tpg2114 Perbedaan antara (FORTRAN 77: Fortran 90) dan (C: C ++) adalah bahwa Fortran 90 dianggap telah menggantikan FORTRAN 77, ke titik di mana orang diberitahu, "Jika Anda ingin belajar Fortran, pelajari Fortran 2003 atau setidaknya 90, karena itu standar sekarang. " Tidak ada yang akan mengatakan sesuatu seperti, "Jika Anda ingin belajar C, pelajari C ++ karena itu standar baru," karena mereka disajikan sebagai dua bahasa yang berbeda. Seperti yang saya katakan, konotasi memang memiliki konsekuensi.

6
KARENA C TIDAK PERNAH MATI
Adel

Jawaban:


13

Saya pikir motivasi bagi perancang bahasa untuk merevisi bahasa yang ada adalah untuk memperkenalkan inovasi sambil memastikan bahwa komunitas pengembang target mereka tetap bersama dan mengadopsi bahasa baru: memindahkan komunitas yang ada ke revisi baru bahasa yang ada lebih efektif daripada menciptakan komunitas baru sekitar bahasa baru. Tentu saja, ini memaksa beberapa pengembang untuk mengadopsi standar baru bahkan jika mereka baik-baik saja dengan yang lama: dalam suatu komunitas Anda kadang-kadang harus memaksakan keputusan tertentu pada minoritas jika Anda ingin menyatukan komunitas.

Juga, pertimbangkan bahwa bahasa tujuan umum mencoba melayani sebanyak mungkin programmer, dan sering diterapkan di daerah baru yang tidak dirancang untuknya. Jadi, alih-alih mengusahakan kesederhanaan dan stabilitas desain, komunitas dapat memilih untuk memasukkan ide-ide baru (bahkan dari bahasa lain) saat bahasa bergerak ke area aplikasi baru. Dalam skenario seperti itu, Anda tidak bisa berharap untuk melakukannya dengan benar pada upaya pertama.

Ini berarti bahwa bahasa dapat mengalami perubahan besar selama bertahun-tahun dan revisi terbaru mungkin terlihat sangat berbeda dari yang pertama. Nama bahasa tidak disimpan karena alasan teknis, tetapi karena komunitas pengembang setuju untuk menggunakan nama lama untuk bahasa baru. Jadi nama bahasa pemrograman mengidentifikasi komunitas penggunanya daripada bahasa itu sendiri.

IMO motivasi mengapa banyak pengembang menemukan ini dapat diterima (atau bahkan diinginkan) adalah bahwa transisi bertahap ke bahasa yang sedikit berbeda lebih mudah dan kurang membingungkan daripada melompat ke bahasa yang sama sekali baru yang akan membawa mereka lebih banyak waktu dan upaya untuk menguasainya. Pertimbangkan bahwa ada sejumlah pengembang yang memiliki satu atau dua bahasa favorit dan tidak terlalu tertarik mempelajari bahasa baru (sangat berbeda). Dan bahkan untuk orang-orang yang suka belajar hal-hal baru, belajar bahasa pemrograman baru selalu merupakan kegiatan yang sulit dan memakan waktu.

Juga, lebih disukai menjadi bagian dari komunitas besar dan ekosistem yang kaya daripada komunitas yang sangat kecil menggunakan bahasa yang kurang dikenal. Jadi, ketika komunitas memutuskan untuk pindah, banyak anggota memutuskan untuk mengikuti untuk menghindari isolasi.

Sebagai komentar sampingan, saya berpikir bahwa argumen yang memungkinkan evolusi sambil mempertahankan kompatibilitas dengan kode lama agak lemah: Java dapat memanggil kode C, Scala dapat dengan mudah diintegrasikan dengan kode Java, C # dapat berintegrasi dengan C ++. Ada banyak contoh yang menunjukkan bahwa Anda dapat dengan mudah berinteraksi dengan kode lama yang ditulis dalam bahasa lain tanpa perlu kompatibilitas kode sumber.

CATATAN

Dari beberapa jawaban dan komentar, saya tampaknya mengerti bahwa beberapa pembaca telah menafsirkan pertanyaan itu sebagai "Mengapa bahasa pemrograman perlu berevolusi."

Saya pikir ini bukan poin utama dari pertanyaan, karena jelas bahwa bahasa pemrograman perlu berevolusi dan mengapa (persyaratan baru, ide-ide baru). Pertanyaannya adalah "Mengapa evolusi ini harus terjadi di dalam bahasa pemrograman alih-alih melahirkan banyak bahasa baru?"


Jawaban ini paling masuk akal bagi saya dari apa pun yang saya lihat di sini: memperbarui bahasa memungkinkan Anda untuk mewarisi (setidaknya beberapa) komunitas yang ada, perpustakaan, dll. Saya ingat pernah membaca bahwa masalah terbesar Lisp adalah banyaknya dialek-dialek yang tidak cocok yang menyulitkan memelihara komunitas; memperbarui bahasa yang ada bisa menjadi cara untuk menghindari memecah-belah komunitas lain dengan cara yang sama.

@SunAvatar: Sejauh yang saya tahu Lisp memiliki beberapa dialek tetapi beberapa lebih sukses daripada yang lain (Common Lisp, Scheme, Racket, Clojure). Setiap kali Anda memulai bahasa baru, Anda mengambil risiko bahwa hanya komunitas yang sangat kecil akan berkumpul di sekitarnya. Dalam komunitas Lisp ini tampaknya praktik umum: jika seseorang memiliki ide baru, mereka bercabang dan melihat apa yang terjadi. Bagi pembuat bahasa lain, kehilangan komunitas bukanlah suatu pilihan.
Giorgio

@SunAvatar: Saya tidak melihat mewarisi perpustakaan yang ada sebagai argumen yang kuat. Anda tidak perlu kompatibilitas kode sumber untuk itu. Lihat misalnya bagaimana Clojure dan Scala dapat menggunakan kode Java.
Giorgio

1
Bahasa tidak mati, hanya programmer yang menggunakannya.
Evan Plaice

@SunAvatar: Ada juga komunitas yang mencoba mengikuti kebijakan yang berbeda: nama mengidentifikasi bahasa, dan jika bagian dari komunitas membuat dialek yang terlalu banyak berbeda, mereka menggunakan nama baru untuk menghindari kebingungan. Lihat misalnya racket-lang.org/new-name.html
Giorgio

21

Backward Compatibility adalah jawaban Anda. Bahasa tertentu, khususnya yang banyak digunakan seperti C mungkin memiliki kode yang beroperasi, tidak berubah, selama beberapa dekade. Jika perlu pemeliharaan, akan membantu jika ada kompiler yang masih dapat menargetkan platform semacam itu sambil berjalan pada sistem modern untuk pekerjaan pengembangan. Standardisasi dan pembaruan versi bahasa membantu menjaga praktik pemrograman tetap mutakhir sambil memberikan rasa keakraban bagi para programmer veteran yang mungkin resisten untuk mempelajari bahasa "baru" secara keseluruhan.

Ingatlah bahwa banyak bahasa yang diperbarui kurang diperbarui sebanyak "perbarui bit baru yang berkilau". Binatang buas dahulu kala masih bersembunyi di dalam.

Sejauh Knuth pergi, ingat bahwa ia adalah seorang akademisi dan bahwa TeX hanya terbukti benar, tidak diperbarui.


14
Domain masalah Tex = format teks karya ilmiah, tidak banyak berubah. Domain bahasa pemrograman = temukan kegunaan baru untuk komputer baru, lebih ekspansif. Itu alasan yang sama bahwa bahasa Latin tidak menambahkan begitu banyak kata-kata baru sebagai bahasa Inggris
Martin Beckett

Saya tidak berpikir bahwa kompatibilitas ke belakang adalah alasan yang valid: Scala dapat dengan mudah diintegrasikan dengan kode Java yang ada tetapi itu bukan super-set Java. Jadi saya pikir secara umum tidak perlu untuk bahasa baru agar kompatibel dengan yang lama di tingkat kode sumber. Cukup untuk memiliki mekanisme yang jelas untuk memanggil kode lama dari kode baru.
Giorgio

@ Martin Beckett: "Domain masalah dari Tex = memformat teks karya ilmiah, tidak banyak berubah.": Saya pikir Anda kehilangan inti pertanyaan. OP tidak bertanya apakah harus ada inovasi dalam bahasa pemrograman (tidak ada yang bisa menyangkal bahwa inovasi diperlukan) tetapi mengapa bahasa lama direvisi alih-alih membuat yang baru.
Giorgio

Sistem dibangun berdasarkan investasi waktu, uang, dan keahlian (pengalaman diperoleh dalam bahasa tertentu). Upaya baru harganya jauh lebih mahal daripada upaya pemeliharaan (dalam ketiga kategori). Tanpa perbaikan pada bahasa dan platform secara umum, biaya pemeliharaan naik, dan kemudian biaya sistem baru lebih menarik dan rehosting asli bahwa aplikasi COBOL ke platform yang sama sekali berbeda untuk kedelapan kalinya dalam hidupnya mungkin tidak tampak seperti banyak lagi.
JustinC

Jika bukan karena standar terbaru dari bahasa COBOL dan pelaksana alat COBOL menambahkan fitur unik mereka sendiri di sepanjang jalan, yang meningkatkan bahasa, dan meningkatkan kemampuan untuk beroperasi pada platform yang lebih luas, arus utama, dan modern; aplikasi tidak akan bertahan 60 tahun. Sementara biaya relatif tentu saja naik kemudian dalam kehidupannya, karena kelangkaan keahlian yang meningkat, upaya secara keseluruhan adalah uang pada dolar dibandingkan dengan penulisan ulang reguler ketika bahasa saat itu muncul.
JustinC

5

Saya pikir jawaban yang jelas adalah bahwa kemajuan masih dibuat dalam desain bahasa dan arsitektur sistem, dan cukup banyak orang peduli dengan bahasa yang lebih tua sehingga mereka ingin mengambil keuntungan dari teknik yang lebih baru (beberapa core, threading yang lebih baik atau model memori) yang mereka dapatkan. atau dimasukkan ke dalam standar bahasa. Ini juga membantu untuk memiliki "satu cara sejati" untuk melakukan hal-hal (misalnya, parsing XML, akses DB) yang dapat Anda andalkan untuk berada di sana tidak peduli apa pun kompiler atau platform yang Anda gunakan, sebagai lawan dari bergantung pada beberapa pihak ketiga perpustakaan yang mungkin atau mungkin tidak diinstal (dan mungkin atau mungkin bukan versi yang Anda butuhkan, dll).


Jadi jika "cukup banyak orang peduli dengan bahasa yang lebih tua" adalah alasannya, akankah Anda mengatakan jawaban Anda dapat diulangi sebagai "keterikatan sentimental dengan bahasa yang ada"? Saya tidak mengatakan itu dengan kasar, hanya mencoba memahami jawaban Anda.
Avner Shahar-Kashtan

Tidak, maksud saya bahasa masih digunakan secara aktif, dan digunakan oleh orang-orang yang ingin memanfaatkan teknik terbaru. Saya tidak berpikir ada orang yang akan menambahkan dukungan multithreading ke ALGOL karena (AFAIK) itu tidak sedang digunakan secara aktif. FORTRAN dan COBOL, masih digunakan untuk mengembangkan sistem baru, sehingga spesifikasi bahasa mereka diperbarui secara berkala untuk memasukkan teknik dan teknologi baru.
TMN

1

Konsep atau tujuan dasar yang digunakan bahasa tujuan umum tidak kehilangan relevansi; namun perubahan kecil dalam lingkungan kerja atau perangkat keras menuntut agar pembaruan atau fitur kecil ditambahkan ke bahasa.

Cara algoritma diekspresikan dalam bahasa tidak akan berubah, meskipun mungkin membutuhkan dukungan yang lebih bersih untuk jenis 64 bit, atau lebih banyak dukungan ekspresi reguler standar, atau dukungan yang lebih kuat untuk jenis baru sistem file.

Ada beberapa kasus di mana fitur 'baru' ditambahkan ke bahasa yang sudah ada, tetapi dalam banyak kasus perubahan itu menyederhanakan hal-hal yang sudah dilakukan orang dengan cara yang sulit. (Lihat C ++ menggunakan fungsi urutan tinggi alih-alih fungsi pointer dan fungsi.)


1
Perubahan yang Anda jelaskan di paragraf kedua cukup tidak dapat ditolak (maksud saya bukan hanya saya tidak keberatan, tetapi tidak ada yang bisa dengan serius menolak). Sedangkan untuk lambdas, saya tidak bisa berkomentar tentang kegunaannya dalam C ++, tapi mengapa repot-repot menambahkannya jika tidak mengubah cara algoritma diungkapkan?

Oh, mereka sangat berguna. Jangan salah sangka. Mereka adalah tambahan paling penting dalam C ++ (IMO). Saya pikir saya tidak jelas tentang apa yang saya maksudkan di sana. Orang biasanya memilih C ++ untuk memiliki akses langsung ke memori, kinerja deterministik, dan potensi optimasi yang tinggi. Itu tidak berubah dengan penambahan terbaru. Kami menyederhanakan banyak tugas pemrograman lain di sekitar mengapa Anda memilih C ++, tetapi C ++ masih valid dan berguna untuk alasan yang sama. Skema diperbarui dengan keteraturan, tetapi kode-sebagai-data dan lispy-ness tidak berubah, jadi Anda memilih skema untuk alasan yang sama hari ini seperti 20 tahun yang lalu.
Ben

"Sedangkan untuk lambdas, saya tidak bisa mengomentari kegunaannya dalam C ++, tapi mengapa repot-repot menambahkannya jika tidak mengubah cara algoritma diekspresikan?": Saya melangkah lebih jauh: mengapa menambahkannya ke C ++ alih-alih beralih ke bahasa yang sudah sejak awal?
Giorgio

2
@Giorgio Untuk memiliki kontrol atas fitur cache dan abstraksi dalam bahasa. Jika tidak ada bahasa yang menyediakan keduanya, maka Anda tidak dapat berganti bahasa tanpa mengorbankan bahasa. Anda harus memodifikasi bahasa atau membuat yang baru.
mike30

@ Mike: Apa yang Anda maksud dengan "fitur cache"?
Giorgio

-2

Ini agak seperti pertimbangan bahasa lisan.

Di masa lalu ada tempat kata-kata yang tidak digunakan sesering sekarang (atau digunakan untuk makna yang berbeda).

misalnya. nice: dalam (sangat tua) bahasa Inggris memiliki makna yang hampir terbalik dengan apa yang kita gunakan saat ini, terutama ketika digunakan untuk menggambarkan karakter someones.

Buruk: beberapa waktu yang lalu buruk hanya memiliki satu makna, sekarang ini dapat berarti sesuatu yang "sangat menakjubkan" (digunakan dengan cara fesicous (saya mungkin melewatkan ejaan fesicous)!

perkembangan baru lainnya adalah ponsel 'Bicara teks' untuk bahasa tertulis.

Saya pribadi tidak melihat mengapa bahasa pemrograman tidak akan berkembang dengan cara yang sama, kata-kata dan fungsi telah menentukan makna / tindakan, dan itu diperlukan untuk berubah sehingga dapat memasukkan ide-ide baru, metodologi baru.

Saya kenal orang-orang yang berbicara banyak bahasa yang berbeda, dan mereka sering menyarankan bahwa setelah 3 atau 4 menjadi lebih mudah untuk belajar yang baru.

Saya tidak tahu apakah ada programmer yang memiliki pengalaman serupa, saya tidak akan terkejut jika ada.

Saya tahu bahwa saya merasakan kebahagiaan pemrograman dalam JAWA (sama seperti saya merasa bahagia berbicara dalam bahasa Inggris) Ini tidak berarti saya tidak dapat berkomunikasi dalam 'bahasa Inggris Amerika' atau 'bahasa Inggris Australia' walaupun ada beberapa 'gotcha' yang harus diperhatikan . Sama seperti pergi dari Jawa ke PHP ke Perl, konstruksinya mirip, tetapi ada sedikit gotcha untuk menangkap saya dan membuat saya memukul kepala saya ke dinding.

Ini berbeda dengan pindah dari Inggris ke Prancis, atau Jawa ke SAS. ini sangat berbeda sehingga butuh waktu cukup lama untuk menjadi mahir pada mereka.

Bagaimanapun itu adalah pendapat saya tentang ini.


Saya pikir Anda berpikir tentang "jenaka".
uliwitness
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.