Tragedi Common Lisp: mengapa bahasa populer membengkak dalam kompleksitas

Diadaptasi dari diskusi pada tahun 2015 . Di sini, Common Lisp hanyalah salah satu dari banyak contoh bagus.


Masa depan JavaScript?

Saya telah bekerja di Komite Standar JavaScript (TC39) sejak 2007. Kami menghargai kesederhanaan bahasa, tetapi seiring waktu kehilangan kewaspadaan. Kompleksitas mulai tumbuh tak terkendali. Kita harus mencari tahu mengapa ini terjadi secara alami, berapa harga dan apa yang harus dilakukan. Artikel ini ditujukan tidak hanya untuk rekan kerja dari TC39, tetapi juga untuk semua orang yang ingin memengaruhi jalur pengembangan JavaScript atau standar apa pun yang menghadapi tekanan serupa. Belajarlah dari kesalahan kita!

Algol, Smalltalk, Pascal dan Skema awal dicintai sebagai bahasa kecil dan indah. Awal C dan JavaScript benar dikritik karena banyak dan jarang disebut cantik. Tetapi mereka juga kecil, dan itu sangat dihargai. Ketika bahasanya kecil, penilaian kami sering ditentukan oleh perasaan: "Saya bisa belajar segalanya dan menguasainya" , dan kemudian: "Saya tahu segalanya. Saya suka bahwa tidak ada detail yang tidak diketahui yang tersisa . " Tetapi dalam kasus C dan JavaScript, tidak mungkin ada orang yang memiliki rasa penguasaan bahasa yang lengkap, karena detailnya sebenarnya sangat rumit. Namun demikian, perasaan "bahasa kecil" dalam banyak hal menentukan kepuasan penggunaan sehari-hari.

Estetika minimalisme JavaScript telah dipertahankan dalam standar EcmaScript-5. Saya aktif berpartisipasi dalam pengembangan EcmaScript-5 dan EcmaScript-2015, dan dalam kedua kasus saya bangga dengan kontribusi saya. EcmaScript-2015 telah tumbuh secara signifikan dalam ukuran, tetapi telah membawa perbaikan dengannya. Mengingat dari mana kami mulai, tidak mungkin untuk meningkatkan JavaScript tanpa peningkatan ukuran. Saya tidak menyesal sebagian besar add-on yang menyebabkan mengembang EcmaScript-5 ke EcmaScript-2015. Jika Anda kembali, mungkin dalam banyak kasus saya akan menyarankan penambahan serupa.

Setiap penambahan harus mengatasi bilah yang sangat tinggi. Secara psikologis, ini masuk akal, karena kami melihat minimalisme EcmaScript-5. Ketika bahasanya kecil, setiap fungsi tambahan secara intuitif dirasakan sebagai persentase peningkatan yang signifikan dalam ukuran bahasa. Manfaat spesifik dari suatu fitur selalu terlihat oleh para pendukungnya. Untuk bahasa yang kecil, kontribusi fitur baru terhadap peningkatan total juga masih terlihat oleh semua orang.

Segera setelah suatu bahasa melampaui kompleksitas tertentu - katakanlah, LaTeX, Common Lisp, C ++, PL / 1, Java modern - pemrograman menjadi lebih seperti memotong subset fungsi untuk penggunaan pribadi dari lautan fungsi yang tak terbatas, yang sebagian besar tidak akan kita kuasai dan rekonsiliasi dengan itu. Setelah bahasa dianggap "tak terbatas," manfaat spesifik dari fitur baru masih dipahami. Tetapi biaya keseluruhan yang terkait dengan kompleksitas tambahan tidak lagi jelas. Mereka tidak lagi dirasakan oleh mereka yang mendiskusikan fitur baru.

$$ .

Bahkan $$ .

Ini adalah kematian dari seribu luka, yang membuat monster ini tumbuh tanpa batasan.

Oleh karena itu, saya meminta semua orang yang memengaruhi bahasa untuk mempertimbangkan standar yang lebih tinggi ketika mempertimbangkan fungsi baru daripada "itu baik untuk memiliki kesempatan seperti itu, bukan?" Saya percaya bahwa EcmaScript-2015 terletak di wilayah perbatasan di mana pertumbuhan yang merajalela masih dapat dicegah, tetapi hanya jika kita mulai saling mengekang dengan standar tinggi untuk setiap fitur baru yang diusulkan. Sebagai sebuah komunitas, kita perlu kepanikan yang lebih umum tentang ukuran yang telah dicapai EcmaScript 2015. Idealnya, dengan pertumbuhan lidah, ketika ukuran mendekati titik tidak bisa kembali, kepanikan akan meningkat, bukan menurun.

Beberapa perbedaan

Jaga agar tekanan minimum tidak merata

Relevansi minimalis berkurang ketika kita beralih dari bahasa dasar ke perpustakaan. Bahasa standar secara keseluruhan dapat direpresentasikan sebagai struktur berikut:

• Sintaks dasar : bentuk khusus yang tidak dapat secara akurat diungkapkan oleh ekstensi lokal ke sintaks lain.
  
• Keadaan semantik : keadaan yang dimanipulasi oleh perhitungan.
  
• Kernel bawaan: Bagian dari pustaka bawaan yang menyediakan fungsionalitas yang tidak dapat disediakan oleh kode khusus sendiri.
  
• Non-kernel intrinsics: built-in library yang dapat diimplementasikan dalam JavaScript, tetapi status semantik atau modul yang dibangun ke dalam kernel bergantung padanya. Misalnya, melalui proksi, Anda bisa mengimplementasikan array dalam kode pengguna. Tetapi modul-modul lain yang dibangun di dalam kernel sudah memiliki ketergantungan pada Array, yang memberikan array istimewa ini posisi istimewa atas setiap penggantian yang diusulkan.
  
• Gula sintaksis : sintaksis yang dapat diekspresikan oleh ekstensi lokal ke sintaksis dasar.
  
• Pustaka global untuk kenyamanan : dapat diimplementasikan dengan kode pengguna tidak terprivat, tetapi dengan mempertimbangkan jalur penamaan global standar dalam ruang nama global asli.
  
• Modul standar untuk kenyamanan : modul yang dikembangkan masyarakat disetujui sebagai standar.

Saya mendaftarkannya sesuai dengan keinginan saya untuk meningkatkan biaya pertumbuhan dan kebutuhan mendesak akan minimalis. Semua ini membutuhkan disiplin. Hanya pada poin terakhir kita dapat memungkinkan pertumbuhan tanpa batas, tetapi disarankan agar kandidat diuji oleh komunitas dan diterima secara de facto terlebih dahulu. Idealnya, komite TC39 akan berhenti menjadi hambatan, karena proses eksternal de facto dan de jure akan dapat secara mandiri mengembangkan modul standar untuk kenyamanan.