Filosofi Pembimbing
1. Bahasa pemrograman untuk manusia
Bahasa pemrograman adalah cara orang berbicara dengan komputer. Komputer akan dengan senang hati berbicara dalam bahasa apa pun yang tidak ambigu. Alasan kami memiliki bahasa tingkat tinggi adalah karena manusia tidak dapat menangani bahasa mesin. Inti dari bahasa pemrograman adalah untuk mencegah otak manusia kita yang malang dan rapuh agar tidak kewalahan oleh terlalu banyak detail.
Arsitek tahu bahwa beberapa masalah desain lebih biasa dibandingkan masalah lainnya. Salah satu masalah desain yang paling jelas dan abstrak adalah desain jembatan. Dalam hal ini, tugas Anda adalah menempuh jarak yang diperlukan dengan material sesedikit mungkin. Di ujung lain spektrum adalah desain kursi. Perancang kursi harus meluangkan waktunya memikirkan bokong orang.
Pengembangan perangkat lunak memiliki perbedaan serupa. Merancang algoritma untuk merutekan data melalui jaringan adalah masalah abstrak yang bagus, seperti merancang jembatan. Padahal mendesain bahasa pemrograman itu seperti mendesain kursi: harus berhadapan dengan kelemahan manusia.
Hal ini sulit disadari oleh sebagian besar dari kita. Merancang sistem matematika yang elegan terdengar jauh lebih menarik bagi sebagian besar dari kita daripada menjadi kaki tangan kelemahan manusia. Peran keanggunan matematis adalah bahwa tingkat keanggunan tertentu membuat program lebih mudah dipahami. Tapi ini bukan soal keanggunan.
Dan ketika saya mengatakan bahwa bahasa harus dirancang untuk mengakomodasi kelemahan manusia, saya tidak bermaksud bahwa bahasa harus dirancang untuk pemrogram yang buruk. Pada kenyataannya, Anda harus merancang perangkat lunak untuk pemrogram terbaik, tetapi pemrogram terbaik pun memiliki keterbatasan. Saya tidak berpikir ada orang yang akan menikmati pemrograman dalam bahasa di mana semua variabel dilambangkan dengan huruf "x" dengan subskrip bilangan bulat.
2. Desain untuk diri sendiri dan teman Anda
Jika Anda melihat sejarah bahasa pemrograman, sebagian besar bahasa terbaik dirancang untuk digunakan oleh penulisnya sendiri, dan sebagian besar bahasa terburuk dirancang untuk digunakan oleh orang lain.
Ketika bahasa dirancang untuk orang lain, itu selalu merupakan sekelompok orang tertentu: orang tidak secerdas pencipta bahasa tersebut. Inilah cara Anda mendapatkan lidah yang merendahkan Anda. Cobol adalah contoh yang paling menonjol, tetapi sebagian besar bahasa memiliki semangat ini.
Ini tidak ada hubungannya dengan seberapa tinggi tingkat bahasanya. C adalah level yang cukup rendah, tetapi diciptakan untuk digunakan oleh pembuatnya, itulah sebabnya para peretas menyukainya.
Argumen merancang bahasa untuk pemrogram yang buruk adalah bahwa terdapat lebih banyak pemrogram yang buruk daripada yang baik. Mungkin memang demikian. Namun sejumlah kecil pemrogram yang baik ini menulis lebih banyak perangkat lunak secara tidak proporsional.
Pertanyaan saya adalah, bagaimana Anda membuat bahasa yang menarik bagi para peretas terbaik? Bagi saya, pertanyaan ini identik dengan pertanyaan bagaimana cara membuat bahasa pemrograman yang baik?, namun meskipun tidak, setidaknya ini adalah pertanyaan yang menarik.
3. Berikan kendali sebanyak mungkin kepada programmer
Banyak bahasa (terutama yang dirancang untuk orang lain) bertindak seperti pengasuh: mereka mencoba memperingatkan Anda untuk menghindari hal-hal yang menurut mereka tidak berguna bagi Anda. Saya mengambil pandangan sebaliknya: berikan kendali sebanyak yang Anda bisa kepada programmer.
Ketika saya pertama kali mempelajari Lisp, yang paling saya sukai adalah kami berbicara secara setara. Dalam bahasa lain yang telah saya pelajari pada saat itu, ada sebuah bahasa, dan ada program saya dalam bahasa itu, dan keduanya ada secara terpisah. Namun di Lisp, fungsi dan makro yang saya tulis sama dengan bahasa penulisannya. Saya bisa menulis ulang bahasanya sendiri jika saya mau. Itu memiliki daya tarik yang sama dengan perangkat lunak sumber terbuka.
4. Singkatan adalah saudara perempuan dari bakat
Brevity diremehkan dan bahkan dibenci. Namun jika Anda melihat ke dalam hati para peretas, Anda akan melihat bahwa mereka sangat menyukai keringkasan. Berapa kali Anda mendengar para peretas berbicara tentang bagaimana, katakanlah, APL, mereka dapat melakukan hal-hal menakjubkan hanya dengan beberapa baris kode? Saya rasa orang yang sangat pintar sebenarnya suka memperhatikan hal ini.
Saya percaya bahwa hampir semua hal yang mempersingkat program adalah hal yang baik. Fungsi perpustakaan harus banyak, segala sesuatu yang tersirat harus demikian; sintaksisnya harus lebih ringkas; bahkan nama entitas harus pendek.
Dan tidak hanya programnya yang harus pendek. Manual juga harus pendek. Sebagian besar manual ini berisi penjelasan, penafian, peringatan, dan kasus khusus. Jika Anda perlu mempersingkat panduan ini, pilihan terbaik adalah memperbaiki bahasa yang memerlukan banyak penjelasan.
5. Kenali apa itu peretasan
Banyak orang ingin hacking menjadi matematika, atau setidaknya sesuatu yang mirip dengan sains. Saya pikir peretasan lebih seperti arsitektur. Arsitektur adalah tentang fisika di mana seorang arsitek perlu merancang sebuah bangunan yang tidak akan runtuh, namun tujuan sebenarnya dari seorang arsitek adalah menciptakan sebuah bangunan yang hebat, bukan membuat penemuan-penemuan di bidang statika.
Yang disukai para peretas adalah membuat program yang hebat. Dan menurut saya, setidaknya dalam pemikiran kita sendiri, kita harus ingat bahwa menulis program yang hebat adalah hal yang luar biasa, bahkan ketika karya tersebut tidak dengan mudah diterjemahkan ke dalam mata uang intelektual yang biasa berupa makalah ilmiah. Dari sudut pandang intelektual, merancang bahasa yang disukai pemrogram sama pentingnya dengan merancang bahasa buruk yang mewujudkan gagasan yang dapat Anda terbitkan dalam makalah.
Masalah Terbuka
1. Bagaimana cara mengatur perpustakaan besar?
Perpustakaan menjadi bagian penting dari bahasa pemrograman. Mereka menjadi sangat besar sehingga bisa berbahaya. Jika diperlukan waktu lebih lama untuk menemukan fungsi di perpustakaan yang melakukan apa yang Anda perlukan daripada menulis fungsi itu sendiri, maka semua kode tidak akan menghasilkan apa-apa selain membuat manual Anda lebih tebal. (Manual Simbolik adalah contohnya.) Jadi kita harus menyelesaikan masalah pengorganisasian perpustakaan. Idealnya, rancanglah sehingga pemrogram dapat menebak fungsi perpustakaan mana yang cocok.
2. Apakah orang benar-benar takut dengan sintaksis awalan?
Ini adalah masalah terbuka dalam artian saya sudah memikirkannya selama beberapa tahun dan masih belum mengetahui jawabannya. Sintaks awalan tampak alami bagi saya, kecuali mungkin untuk penggunaannya dalam matematika. Tapi mungkin sebagian besar ketidakpopuleran Lisp hanya disebabkan oleh sintaksis yang asing... Apakah kita harus melakukan sesuatu, jika benar, adalah masalah lain.
3. Apa yang Anda perlukan untuk perangkat lunak server?
Saya rasa sebagian besar aplikasi yang akan ditulis dalam dua puluh tahun ke depan adalah aplikasi web, dalam artian program akan berada di server dan berkomunikasi dengan Anda melalui browser web. Dan untuk menulis aplikasi seperti itu kita memerlukan hal-hal baru.
Salah satunya adalah dukungan terhadap cara baru untuk merilis aplikasi server. Daripada satu atau dua rilis besar per tahun, seperti perangkat lunak desktop, perangkat lunak server akan dirilis dalam serangkaian perubahan kecil. Anda mungkin memiliki lima atau sepuluh rilis sehari. Dan setiap orang akan selalu memiliki versi terbaru.
Tahukah Anda bagaimana merancang program agar dapat dipelihara? Perangkat lunak server harus dirancang agar dapat diubah. Anda harus bisa mengubahnya dengan mudah, atau setidaknya mengetahui apa arti perubahan kecil dan apa yang penting.
Hal lain yang dapat berguna dalam perangkat lunak server adalah, secara tiba-tiba, kontinuitas pengiriman. Dalam aplikasi web Anda dapat menggunakan sesuatu seperti untuk mendapatkan efek rutinitas di dunia sesi web tanpa kewarganegaraan. Memiliki kontinuitas pasokan mungkin bermanfaat jika fitur tersebut tidak terlalu mahal.
4. Abstraksi baru apa yang masih perlu ditemukan?
Saya tidak yakin seberapa masuk akal harapan itu, tetapi secara pribadi saya sangat ingin menemukan abstraksi baru - sesuatu yang bisa bermakna seperti fungsi kelas satu atau rekursi atau setidaknya parameter default. Mungkin ini adalah mimpi yang mustahil. Hal-hal seperti itu seringkali tidak ditemukan. Tapi saya tidak kehilangan harapan.
Rahasia yang jarang diketahui
1. Anda dapat menggunakan bahasa apa pun yang Anda inginkan
Sebelumnya, pembuatan aplikasi berarti pembuatan perangkat lunak desktop. Dan dalam perangkat lunak desktop terdapat bias besar terhadap penulisan aplikasi dalam bahasa yang sama dengan sistem operasi. Jadi sepuluh tahun yang lalu, menulis perangkat lunak secara umum berarti menulis perangkat lunak dalam C. Akhirnya, tradisi tersebut berkembang: aplikasi tidak boleh ditulis dalam bahasa yang tidak biasa. Dan tradisi ini telah berkembang begitu lama sehingga orang-orang non-teknis seperti manajer dan pemodal ventura juga mempelajarinya.
Perangkat lunak server menghancurkan model ini sepenuhnya. Dengan perangkat lunak server Anda dapat menggunakan bahasa apa pun yang Anda inginkan. Hampir belum ada yang memahami hal ini (terutama manajer dan pemodal ventura). Tetapi beberapa peretas memahami hal ini, itulah sebabnya kita mendengar tentang bahasa indy seperti Perl dan Python. Kami tidak mendengar tentang Perl dan Python karena orang menggunakannya untuk menulis aplikasi Windows.
Apa artinya ini bagi kami, orang-orang yang tertarik dengan desain bahasa pemrograman, bahwa ada audiens potensial untuk karya kami.
2. Kecepatan berasal dari profiler
Pengembang bahasa, atau setidaknya pelaksana bahasa, suka menulis kompiler yang menghasilkan kode cepat. Namun menurut saya bukan itu yang membuat bahasa menjadi cepat bagi pengguna. Knuth telah lama mencatat bahwa kecepatan hanya bergantung pada beberapa hambatan. Dan siapa pun yang telah mencoba mempercepat suatu program tahu bahwa Anda tidak dapat menebak di mana hambatannya. Profiler adalah jawabannya.
Pengembang bahasa memecahkan masalah yang salah. Pengguna tidak memerlukan benchmark untuk berjalan dengan cepat. Mereka membutuhkan bahasa yang dapat menunjukkan bagian mana dari program mereka yang perlu ditulis ulang. Pada titik ini, kecepatan sangat dibutuhkan dalam latihan. Jadi mungkin akan lebih baik jika pelaksana bahasa menghabiskan separuh waktu yang mereka habiskan untuk mengoptimalkan kompiler dan menghabiskannya untuk menulis profiler yang baik.
3. Anda memerlukan aplikasi yang membuat bahasa Anda berkembang
Ini mungkin bukan kebenaran yang hakiki, tetapi tampaknya bahasa terbaik berevolusi seiring dengan aplikasi yang menggunakannya. C ditulis oleh orang-orang yang membutuhkan pemrograman sistem. Lisp dirancang sebagian untuk diferensiasi simbolis, dan McCarthy sangat bersemangat untuk memulai sehingga ia bahkan mulai menulis program diferensiasi di makalah Lisp pertama pada tahun 1960.
Ini sangat bagus jika aplikasi Anda memecahkan beberapa masalah baru. Hal ini mendorong bahasa Anda untuk memiliki fitur-fitur baru yang diinginkan pemrogram. Secara pribadi, saya tertarik untuk menulis bahasa yang cocok untuk aplikasi server.
[Selama diskusi, Guy Steele juga menyampaikan hal ini, menambahkan bahwa aplikasi tidak boleh terdiri dari penulisan kompiler untuk bahasa Anda, kecuali bahasa Anda dirancang untuk menulis kompiler.]4. Bahasanya harus sesuai untuk menulis program satu kali.
Anda tahu apa yang dimaksud dengan program one-shot: yaitu saat Anda perlu menyelesaikan beberapa masalah terbatas dengan cepat. Saya yakin jika Anda melihat-lihat, Anda akan menemukan banyak program serius yang awalnya hanya program satu kali saja. Saya tidak akan terkejut jika sebagian besar program dimulai hanya sekali. Oleh karena itu, jika Anda ingin membuat bahasa yang cocok untuk menulis perangkat lunak secara umum, maka bahasa tersebut juga harus cocok untuk menulis program satu kali, karena ini adalah tahap awal dari banyak program.
5. Sintaks berkaitan dengan semantik
Secara tradisional diyakini bahwa sintaksis dan semantik adalah hal yang sangat berbeda. Ini mungkin terdengar mengejutkan, tapi sebenarnya tidak. Saya pikir apa yang ingin Anda capai dalam program Anda berkaitan dengan cara Anda mengekspresikannya.
Saya baru-baru ini berbicara dengan Robert Morris dan dia mencatat bahwa kelebihan operator merupakan nilai tambah yang besar bagi kemenangan bahasa dengan sintaksis infiks. Dalam bahasa dengan sintaks awalan, fungsi apa pun yang Anda definisikan sebenarnya adalah operator. Jika Anda ingin menambahkan tipe angka baru yang Anda buat, Anda cukup menentukan fungsi baru untuk menambahkannya. Jika Anda melakukan ini dalam bahasa dengan sintaks infix, Anda akan melihat bahwa ada perbedaan besar antara menggunakan operator yang kelebihan beban dan memanggil suatu fungsi.
Ide yang muncul kembali seiring berjalannya waktu
1. Bahasa pemrograman baru
Melihat kembali ke tahun 1970-an, pengembangan bahasa pemrograman baru merupakan hal yang populer. Hal ini tidak terjadi sekarang. Namun saya yakin perangkat lunak server akan kembali mengembalikan mode dalam menciptakan bahasa baru. Dengan perangkat lunak server Anda dapat menggunakan bahasa apa pun yang Anda inginkan, jadi jika seseorang menciptakan bahasa yang tampaknya lebih baik dari yang lain, akan ada orang yang memutuskan untuk menggunakannya.
2. Pembagian waktu
Richard Kelsey mengemukakan ide ini yang waktunya telah tiba dan saya mendukung penuhnya. Dugaan saya (dan juga Microsoft) adalah banyak komputasi akan berpindah dari desktop ke server jarak jauh. Dengan kata lain, pembagian waktu telah kembali. Saya pikir ini memerlukan dukungan di tingkat bahasa. Misalnya, Richard dan Jonathan Reeves telah melakukan banyak pekerjaan untuk mengimplementasikan penjadwalan proses pada Skema 48.
3. Efisiensi
Belakangan ini tampaknya komputer sudah cukup cepat. Kita semakin sering mendengar tentang bytecode, yang setidaknya bagi saya berarti kita mempunyai cadangan daya. Namun menurut saya dengan perangkat lunak server, kami tidak memilikinya. Seseorang harus membayar untuk server yang menjalankan perangkat lunak, dan jumlah pengguna yang dapat didukung oleh server per mesin akan menjadi pembagi biaya modal mereka.
Saya pikir efisiensi akan menjadi hal yang penting, setidaknya dalam mengatasi kemacetan komputasi. Hal ini terutama penting untuk operasi I/O, karena aplikasi server melakukan banyak operasi seperti itu.
Pada akhirnya, bytecode mungkin bukanlah jawabannya. Sun dan Microsoft tampaknya akan saling berhadapan dalam bidang bytecode saat ini. Namun mereka melakukan ini karena bytecode adalah tempat yang nyaman untuk menanamkan dirinya ke dalam suatu proses, bukan karena bytecode itu sendiri adalah ide yang bagus. Mungkin saja seluruh pertempuran ini luput dari perhatian. Itu akan lucu.
Jerat dan jerat
1. Klien
Ini hanyalah tebakan, tetapi satu-satunya aplikasi yang akan diuntungkan adalah aplikasi yang sepenuhnya berada di sisi server. Merancang perangkat lunak yang beroperasi dengan asumsi bahwa setiap orang akan memiliki pelanggan sama seperti merancang masyarakat berdasarkan asumsi bahwa setiap orang akan jujur. Ini pasti nyaman, tetapi Anda harus berasumsi bahwa itu tidak akan pernah terjadi.
Saya pikir akan ada peningkatan pesat pada perangkat yang mendukung web, dan kita dapat berasumsi bahwa perangkat tersebut akan mendukung html dan formulir dasar. Apakah Anda memiliki browser di ponsel Anda? Akankah PalmPilot Anda memiliki telepon? Akankah blackberry Anda memiliki layar yang lebih besar? Apakah Anda dapat mengakses Internet dari gameboy Anda? Dari jam tanganmu? Aku tidak tahu. Dan saya tidak perlu mencari tahu apakah saya yakin semuanya akan ada di server. Jauh lebih dapat diandalkan jika semua otak ada di server. .
2. Pemrograman berorientasi objek
Saya menyadari ini adalah pernyataan kontroversial, tapi menurut saya OOP tidak begitu penting. Saya rasa ini adalah paradigma yang cocok untuk aplikasi spesifik yang memerlukan struktur data spesifik, seperti sistem windowing, simulasi, sistem CAD. Tapi saya tidak mengerti kenapa harus cocok untuk semua program.
Saya pikir orang-orang di perusahaan besar menyukai OOP, karena OOP membuat banyak hal tampak seperti pekerjaan. Apa yang biasanya direpresentasikan sebagai, katakanlah, daftar bilangan bulat, kini dapat direpresentasikan sebagai ruang kelas dengan segala macam perancah, hiruk pikuk.
Fitur menarik lainnya dari OOP adalah metodenya memberi Anda beberapa efek fungsi kelas satu. Tapi ini bukan berita baru bagi programmer Lisp. Ketika Anda memiliki fungsi kelas satu yang sebenarnya, Anda bisa menggunakannya dengan cara apa pun yang sesuai dengan tugas yang ada, alih-alih memasukkan semuanya ke dalam kelas dan metode boilerplate.
Saya pikir apa artinya ini bagi desain bahasa adalah Anda tidak boleh menyematkan OOP terlalu dalam ke dalamnya. Mungkin jawabannya adalah dengan menawarkan hal-hal yang lebih umum dan mendasar, dan membiarkan orang merancang sistem objek apa pun sebagai perpustakaan.
3. Desain oleh panitia
Jika bahasa Anda dirancang oleh sebuah komite, maka Anda terjebak, dan bukan hanya karena alasan yang diketahui semua orang. Semua orang tahu bahwa komite cenderung membuat desain bahasa yang tidak konsisten dan tidak konsisten. Namun menurut saya bahaya terbesarnya adalah mereka tidak mengambil risiko. Ketika satu orang memimpin, dia mengambil risiko yang tidak akan pernah disetujui oleh komite.
Apakah Anda perlu mengambil risiko untuk menciptakan bahasa yang baik? Banyak orang mungkin menduga bahwa desain bahasa adalah sesuatu yang harus tetap dekat dengan kearifan tradisional. Saya yakin bukan itu masalahnya. Dalam segala hal yang dilakukan orang, imbalannya sebanding dengan risikonya. Jadi mengapa desain bahasa harus berbeda?
Sumber: www.habr.com