Penulis artikel ini membahas masalah-masalah bahasa pemrograman modern dan tentang cara-cara untuk memperbaiki kekurangan.Selama 18 tahun terakhir saja, orang telah menciptakan banyak bahasa, di antaranya mungkin yang paling populer adalah Swift, Kotlin dan Go. Pada saat yang sama, fitur yang membedakan bahasa pemrograman abad ke-21 adalah tidak adanya fitur khusus. Hal yang paling menyenangkan dalam bekerja dengan bahasa seperti itu adalah Anda dapat menghabiskan akhir pekan mempelajari salah satu dari mereka dan akhirnya mengatakan bahwa Anda berhasil mempelajari hal baru yang populer, tetapi sebenarnya Anda belum mempelajari hal baru. Mereka benar-benar bukan hal baru. Semua bahasa modern dibuat atas dasar beberapa formula yang benar dan terbukti, nama yang kemungkinan besar adalah Objective-C, Java atau C.
"Kurangnya kebaruan" dapat dianggap fitur yang berharga, tetapi situasi ini menimbulkan satu pertanyaan. Apakah kita benar-benar menghadapi bahasa abad ke-21 yang baru, atau apakah semua ini hanya cerminan dari kebiasaan pemrograman yang buruk di abad ke-20?
Jika saya menemukan bahasa, saya tidak akan mencoba untuk memperbaiki masa lalu, tetapi akan mencoba untuk menciptakan sesuatu yang akan bekerja dengan baik dalam kondisi modern, tetapi juga dapat mengembangkan dan menahan ujian waktu. Jika ini membutuhkan solusi konstruktif radikal, maka jadilah itu.
Turun dengan sintaks!
Sintaksis bahasa modern mencerminkan upaya untuk memeras kebebasan kapur tulis dan papan tulis ke dalam belenggu ASCII. Beberapa elemen catatan, seperti tanda-tanda aritmatika atau tanda kurung, dirasakan lebih atau kurang secara alami. Tetapi sejumlah sebutan lain hanya dibenarkan dengan upaya penghematan saat menekan tombol teletype.
Memasukkan teks dari keyboard tidak lagi sulit. Kita tidak diharuskan untuk menempatkan diri kita pada posisi di mana kita perlu menebak arti sintaksis. Potongan seperti
(($: @ (<# [), (= # [), $: @ (> # [)) ({~? @ #)) ^: (1 <#) - format perekaman yang sangat singkat dan luas (ini, omong-omong, adalah bagian nyata dari kode dalam
bahasa nyata ), tetapi tidak meningkatkan keterbacaan dengan cara apa pun. Dan, yang lebih penting, sulit untuk "google" atau menemukannya di stackoverflow.
Hal yang sama dapat dikatakan tentang nama-nama fungsi yang misterius, konvensi kode kembali dan atribut dengan makna yang tidak jelas. Mereka melayani dengan baik di masa lalu, menghemat banyak ruang pada kartu punch, tetapi hari ini saatnya untuk istirahat yang memang layak.
Sesuatu seperti
FILE * test_file = fopen("/tmp/test.txt", "w+");harus diubah menjadi
create file /tmp/test.txt for input and output as test_fileKita tidak membutuhkan semua tanda kurung, tanda kutip, tanda bintang, dan titik koma ini (kecuali, tentu saja, mereka benar-benar tidak menyampaikan gagasan dengan lebih jelas). Penyorotan sintaksis cukup mampu sepenuhnya menggantikan notasi sintaksis.
Beberapa hal berlimpah tersedia di abad ke-21: misalnya, kecepatan parsing, memori komputer, pencarian online. Sumber daya lainnya masih mahal: waktu pengembangan, memori programmer, usaha yang dihabiskan untuk mempelajari fitur-fitur bahasa. Perubahan pada aturan penulisan kode harus mengalihkan fokus ke sumber daya yang lebih murah dan menghemat yang lebih mahal.
Turun dengan tipe bawaan!
Anda mungkin akrab dengan
paradoks JavaScript . Misalnya, seperti:
> 10.8 / 100
0.10800000000000001Hasil ini tidak unik untuk JavaScript. Dan ini bukan paradoks sama sekali, tetapi contoh kepatuhan yang benar-benar benar terhadap standar IEEE 754 yang disegani. Implementasi yang sama dari angka floating-point ditemukan di hampir semua arsitektur. Dan itu tidak terlalu buruk, mengingat bahwa kami mencoba menjejalkan angka nyata dalam jumlah tak terbatas menjadi 32, 64, atau 256 bit.
Apa yang dianggap matematikawan mustahil, insinyur mewujudkan melalui penolakan akal sehat demi implementasi praktis. Angka floating point dalam interpretasi IEEE bukan angka sama sekali. Matematika membutuhkan asosiatif dari operasi penambahan mereka. Tipe float dan double tidak selalu menyimpan properti ini. Matematika mensyaratkan bahwa himpunan bilangan real termasuk bilangan bulat, tetapi persyaratan ini tidak terpenuhi bahkan untuk float dan uint32_t dengan ukuran yang sama. Matematika mengharuskan bilangan real memiliki elemen nol. Nah, dalam hal ini, standar IEEE melebihi semua harapan, karena angka floating point memiliki dua elemen nol, bukan satu.
Tidak hanya angka floating point memiliki fitur serupa. Bilangan bulat tertanam tidak lebih baik diimplementasikan. Apakah Anda tahu apa yang terjadi jika Anda mencoba menambahkan dua angka 16-bit seperti itu?
0xFFFF + 0x0001Tidak ada yang akan memberikan jawaban yang pasti. Insting memberi tahu kita bahwa luapan akan memberikan 0x0000. Namun, hasil seperti itu tidak didokumentasikan dalam standar internasional apa pun. Dalam menangani operasi ini, semua orang dipandu oleh pendekatan C dan keluarga prosesor x86. Atau, itu dapat mengakibatkan 0xFFFF, atau interupsi akan dipicu, atau beberapa bit khusus yang mengindikasikan overflow akan disimpan di tempat khusus.
Saat-saat seperti itu umumnya tidak dipertimbangkan di mana pun, dan aturan untuk memproses operasi semacam itu berbeda dari satu bahasa ke bahasa lainnya. Jika keanehan floating point setidaknya ditetapkan oleh standar, maka pertanyaan terakhir yang diajukan, pada prinsipnya, tidak dapat diprediksi.
Sebagai gantinya, untuk perhitungan numerik, saya akan menyarankan untuk memperkenalkan tipe data dari nilai yang dapat didefinisikan dengan titik tetap dan dengan perilaku standar jika kehilangan keakuratan atau melampaui batas atas atau bawah. Sesuatu seperti ini:
1.000 / 3.000 = 0.333
0001 + 9999 = overflowed 9999
0.001 / 2 = underflowed 0Tidak perlu menambahkan semua nol tambahan: keberadaan mereka harus tersirat oleh definisi tipe data. Tetapi penting untuk dapat memilih sendiri batas maksimum dan minimum, dan tidak bergantung pada arsitektur prosesor.
Bukankah perhitungan seperti itu akan bekerja lebih lambat? Ya mereka akan. Tetapi tanyakan pada diri Anda: seberapa sering Anda harus memprogram komputasi berkinerja tinggi? Saya percaya bahwa jika Anda bukan ahli dalam bidang ini, maka sangat jarang. Dan jika Anda terlibat dalam tugas seperti itu, maka Anda menggunakan peralatan dan kompiler khusus untuk tujuan ini. Sejauh yang saya tahu, seorang programmer abad ke-21 jarang menyelesaikan persamaan diferensial.
Meskipun demikian, tidak ada yang mencegah penggunaan tipe bawaan yang cepat, kompleks, dan tidak dapat diprediksi dari masa lalu sebagai alternatif, alih-alih sebagai opsi default.
Turun dengan praktik bahasa logam!
Ada bahasa yang luar biasa yang diciptakan bukan untuk melakukan tugas, tetapi untuk membuat bahasa yang mampu melakukannya. Racket, Rebol, dan Forth hanyalah beberapa contoh. Saya suka mereka semua, bermain dengan mereka adalah kesenangan murni. Tetapi, seperti yang mungkin Anda tebak, kesenangan yang diterima dari bekerja dengan bahasa bukan kriteria utama yang membuat bahasa universal dan populer.
Kemampuan untuk membuat bahasa baru dalam suatu bahasa untuk melakukan tugas tertentu adalah alat yang sangat kuat yang terbayar penuh selama pekerjaan penelitian independen. Sayangnya, jika kode harus jelas tidak hanya untuk penulis, maka selain yang utama, Anda harus mengajar orang lain dan bahasa internal yang baru. Dan di sini masalahnya dimulai.
Orang ingin menyelesaikan tugas, dan tidak belajar bahasa yang akan membantu melakukan pekerjaan itu sekali saja, dan setelah itu mereka tidak akan berguna. Untuk orang luar, gagasan menguasai bahasa Anda adalah investasi yang tidak mungkin berhasil. Tetapi mempelajari sesuatu yang terstandarisasi adalah investasi seumur hidup. Oleh karena itu, mereka akan menulis ulang kode Anda lagi dan baru kemudian akan mempelajarinya. Dengan demikian, dialek yang tak terhitung jumlahnya muncul untuk satu bidang yang diterapkan. Orang-orang berdebat tentang estetika, ideologi, arsitektur, dan hal-hal tidak penting lainnya. Dan jutaan baris kode ditulis untuk dilupakan dalam beberapa bulan.
Orang-orang Lisp melewati ini di tahun 80-an. Mereka menyadari bahwa semakin banyak elemen bahasa yang terstandarisasi, semakin baik. Maka muncullah Common Lisp.
Dan dia sangat besar. Standar INCITS 226–1994 memiliki 1.153 halaman. Catatan ini 17 tahun kemudian dipecahkan hanya oleh C ++ dengan standar ISO / IEC 14882: 2011 (1338 halaman). C ++ harus menyeret warisan yang tak tertahankan, meskipun tidak selalu sebesar ini. Lisp umum dibuat sebagian besar dari awal.
Bahasa pemrograman seharusnya tidak begitu besar. Ini tidak perlu. Dia hanya membutuhkan perpustakaan standar yang baik, diisi dengan segala macam hal yang berguna, sehingga orang tidak harus menemukan kembali roda.
Tentu saja, menjaga keseimbangan antara ukuran dan kesesuaian aplikasi tidaklah mudah. Pengalaman C ++ dalam praktiknya menunjukkan betapa sulitnya itu. Saya percaya bahwa untuk mencapai keseimbangan yang diperlukan, bahasa abad ke-21 harus dipertajam secara kondisional di bawah bidang terapan tertentu. Karena sebagian besar masalah sekarang muncul tepat di bidang aplikasi bisnis, bahasanya mungkin harus fokus pada masalah bisnis, dan bukan pada pengembangan game atau desain web.
Jadi ...
Bahasa abad ke-21 harus berorientasi bisnis, menggunakan ekspresi bahasa yang jelas dan tidak tergantung pada tipe bawaan. Sangat bagus bahwa bahasa seperti itu sudah ada! Apa yang Anda pikirkan, apa yang kita bicarakan?
Ya, ini COBOL.
Ini adalah salah satu bahasa tingkat tinggi pertama, yang saat ini kebanyakan dilupakan. Saya harus mengakui bahwa saya dengan sengaja menggambarkan fitur COBOL kuno sebagai sangat modern dan sangat menjanjikan. Dan saya melakukannya untuk menunjukkan satu hal. Kode ini ditulis bukan oleh fitur bahasa. Kamu melakukannya.
Adalah naif untuk berpikir bahwa bahasa bertanggung jawab atas kualitas kode, dan bahwa menambahkan beberapa gadget (atau menghapusnya) dapat secara otomatis meningkatkan semuanya. Pada suatu waktu, programmer tidak menyukai Fortran dan COBOL, oleh karena itu, mereka menemukan C ++ dan Java, untuk akhirnya sampai pada situasi di mana, 20 atau 30 tahun kemudian, mereka juga tidak menyukai semua orang.
Menurut perasaan saya, akar masalahnya terletak pada bidang sosiologi dan psikologi, tetapi bukan pemrograman. Apakah kita benar-benar tidak menyukai bahasa? Dan apakah kita puas dengan lingkungan tempat kita bekerja? Windows rentan, Visual Studio terlalu lambat, tidak mungkin untuk keluar dari Vim. Bahkan, hal-hal inilah yang menyebabkan ketidakpuasan, dan bukan proses kreatif itu sendiri.
Tetapi Anda harus selalu menemukan orang yang patut disalahkan. Sebagai insinyur perangkat lunak, yang sebagian bertanggung jawab atas betapa buruknya program, kami tidak akan menyalahkan diri sendiri, bukan? Oleh karena itu, kami mencari kekurangan pada alat tersebut. Mari kita ciptakan COBOL baru sampai suatu hari matahari mulai bersinar lebih terang, burung-burung tidak bernyanyi lebih keras, dan Windows mulai memuat dalam 2 detik.
Tetapi kemungkinan besar hari ini tidak akan pernah datang.
Oleh karena itu, jika saya ingin menciptakan bahasa pemrograman abad ke-21, sebagai gantinya saya akan mencoba menemukan pendekatan baru terhadap tanggung jawab. Atau cara baru untuk lebih menguasai alat yang ada. Saya akan mencoba untuk lebih memperhatikan detail-detail penting dan tanpa ampun menyingkirkan kerumitan yang tidak perlu. Alih-alih bahasa yang masuk dan keluar dari mode, selalu ada beberapa hal mendasar yang pantas dipikirkan kembali.
