Membimbing filsafat
1. Memprogram bahasa untuk orang
Bahasa pemrograman adalah cara orang berbicara dengan komputer. Komputer akan senang berbicara bahasa apa pun yang tidak ambigu. Alasan mengapa kami memiliki bahasa tingkat tinggi adalah karena orang tidak dapat menangani bahasa mesin. Inti dari bahasa pemrograman adalah untuk mencegah otak manusia kita yang rapuh dari kelebihan beban dengan banyak detail.
Arsitek tahu bahwa beberapa masalah desain lebih biasa daripada yang lain. Salah satu masalah desain yang paling jelas dan paling abstrak adalah desain jembatan. Dalam hal ini, tugas Anda adalah untuk menutupi jarak yang diperlukan dengan bahan sesedikit mungkin. Di ujung lain dari spektrum adalah desain kursi. Desainer kursi harus meluangkan waktu untuk memikirkan penilaian manusia.
Pengembangan perangkat lunak memiliki perbedaan yang serupa. Merancang algoritma untuk merutekan data melalui jaringan adalah masalah abstrak yang bagus, seperti merancang jembatan. Sedangkan mendesain bahasa pemrograman seperti mendesain kursi: Anda harus mengatasi kelemahan manusia.
Sebagian besar dari kita kesulitan menyadari hal ini. Merancang sistem matematika yang elegan terdengar jauh lebih menarik bagi kebanyakan dari kita daripada memanjakan kelemahan manusia. Peran keanggunan matematis adalah bahwa beberapa tingkat keanggunan membuat program lebih mudah dipahami. Namun semuanya tidak terbatas pada keanggunan.
Dan ketika saya mengatakan bahwa bahasa harus dirancang untuk memperhitungkan kelemahan manusia, saya tidak bermaksud bahwa bahasa harus dirancang untuk programmer yang buruk. Bahkan, Anda harus merancang perangkat lunak untuk programmer terbaik, tetapi bahkan programmer terbaik pun memiliki batasan. Saya tidak berpikir bahwa setidaknya seseorang akan suka memprogram dalam bahasa di mana semua variabel akan dilambangkan dengan huruf "x" dengan indeks integer.
2. Desain untuk diri sendiri dan teman-teman Anda
Jika Anda melihat sejarah bahasa pemrograman, sebagian besar bahasa terbaik telah dirancang untuk digunakan oleh penulis mereka sendiri, dan sebagian besar yang terburuk telah dirancang untuk orang lain.
Ketika bahasa dirancang untuk orang lain, itu selalu merupakan kelompok orang tertentu: orang tidak sepintar pencipta bahasa. Jadi Anda mendapatkan bahasa yang berbicara merendahkan Anda. Cobol adalah contoh paling jelas, tetapi sebagian besar bahasa dipenuhi dengan semangat ini.
Ini tidak ada hubungannya dengan seberapa tinggi tingkat bahasanya. Tingkat C cukup rendah, tetapi diciptakan untuk digunakan oleh penulisnya, itulah sebabnya peretas menyukainya.
Argumen untuk mendesain bahasa untuk programmer buruk adalah bahwa ada lebih banyak programmer buruk daripada yang baik. Mungkin memang begitu. Tetapi sejumlah kecil programmer yang baik menulis lebih banyak perangkat lunak secara tidak proporsional.
Saya tertarik dengan pertanyaan tentang bagaimana membuat bahasa yang disukai peretas terbaik. Tampak bagi saya bahwa pertanyaan ini identik dengan pertanyaan tentang bagaimana membuat bahasa pemrograman yang baik?, Tetapi bahkan jika tidak, maka setidaknya itu adalah pertanyaan yang menarik.
3. Berikan programmer sebanyak mungkin kendali
Banyak bahasa (terutama yang dibuat untuk orang lain) berperilaku seperti pengasuh: mereka mencoba memperingatkan Anda dari hal-hal yang, menurut mereka, tidak akan berguna bagi Anda. Saya memiliki pendapat yang berlawanan: berikan programmer sebanyak yang Anda bisa.
Ketika saya pertama kali mempelajari Lisp, yang paling saya sukai adalah bahwa kami berbicara dengan persyaratan yang sama. Dalam bahasa lain yang saya pelajari pada waktu itu, ada bahasa, dan ada program saya dalam bahasa itu, dan mereka ada secara terpisah. Namun dalam Lisp, fungsi dan makro yang saya tulis sama dengan bahasa yang digunakan. Saya bisa menulis ulang bahasa itu sendiri jika saya mau. Itu memiliki daya tarik yang sama dengan perangkat lunak open source.
4. Singkatnya - saudara perempuan dari talenta
Brevity diremehkan dan bahkan dihina. Tetapi jika Anda melihat ke hati para peretas, Anda akan melihat bahwa mereka sangat menyukai singkatnya. Berapa kali Anda mendengar para peretas dengan penuh kasih mengatakan bahwa, katakanlah, dalam APL, mereka dapat melakukan hal-hal menakjubkan hanya dengan beberapa baris kode? Saya percaya bahwa orang yang sangat pintar sangat suka memperhatikan ini.
Saya percaya bahwa hampir semua yang membuat program lebih pendek adalah baik. Seharusnya ada banyak fungsi perpustakaan, semua yang bisa implisit - seharusnya begitu; sintaksisnya harus lebih ringkas; bahkan nama entitas harus pendek.
Dan tidak hanya program harus pendek. Manual juga harus pendek. Bagian yang baik dari manual diisi dengan penjelasan, penafian, peringatan dan kasus khusus. Jika Anda perlu mempersingkat manual, opsi terbaik adalah memperbaiki bahasa yang membutuhkan banyak penjelasan.
5. Kenali apa itu peretasan.
Banyak orang ingin meretas menjadi matematika, atau setidaknya sesuatu yang mirip dengan ilmu alam. Saya pikir peretasan lebih seperti arsitektur. Arsitektur terkait dengan fisika, dalam arti bahwa arsitek perlu merancang bangunan yang tidak akan jatuh, tetapi tujuan nyata arsitek adalah menciptakan bangunan yang hebat, dan tidak membuat penemuan di bidang statika.
Yang disukai peretas adalah menciptakan program-program hebat. Dan saya pikir, setidaknya dalam pikiran kita sendiri, kita harus ingat bahwa menulis program yang hebat itu luar biasa, bahkan ketika karya ini tidak mudah diterjemahkan ke dalam mata uang intelektual biasa karya ilmiah. Dari sudut pandang intelektual, sama pentingnya bagaimana mengembangkan bahasa yang akan disukai oleh programmer, dan untuk menciptakan bahasa yang mengerikan yang mewujudkan gagasan tentang mana Anda dapat menerbitkan sebuah artikel.
Masalah terbuka
1. Bagaimana cara mengatur perpustakaan besar?
Perpustakaan menjadi bagian penting dari bahasa pemrograman. Mereka menjadi sangat besar sehingga bisa berbahaya. Jika butuh lebih banyak waktu untuk menemukan fungsi di perpustakaan yang melakukan apa yang Anda butuhkan, daripada menulis sendiri fungsi ini, maka semua kode tidak melakukan apa pun selain mengentalkan manual Anda. (Manual simbolik adalah contohnya.) Jadi kita harus menyelesaikan masalah pengorganisasian perpustakaan. Idealnya, desain mereka sehingga programmer dapat menebak fungsi perpustakaan mana yang cocok.
2. Apakah orang benar-benar takut dengan sintaks awalan?
Ini adalah masalah terbuka dalam arti bahwa saya telah memikirkannya selama beberapa tahun dan masih belum tahu jawabannya. Sintaks awalan tampaknya sepenuhnya alami bagi saya, mungkin selain menggunakannya dalam matematika. Tetapi mungkin sebagian besar ketidaksamaan Lisp hanyalah karena sintaksis yang tidak dikenal ... Apakah ada hubungannya dengan ini, jika itu benar, ini adalah pertanyaan lain.
3. Apa yang Anda butuhkan untuk perangkat lunak server?
Saya pikir sebagian besar aplikasi yang akan ditulis dalam dua puluh tahun ke depan akan menjadi aplikasi web, dalam arti bahwa program akan berlokasi di server dan akan berkomunikasi dengan Anda melalui browser web. Dan untuk menulis aplikasi seperti itu kita perlu hal-hal baru.
Salah satunya adalah mendukung cara baru untuk merilis aplikasi server. Alih-alih satu atau dua rilis utama per tahun, seperti perangkat lunak desktop, perangkat lunak server akan dirilis dalam serangkaian perubahan kecil. Anda dapat memiliki lima atau sepuluh rilis per hari. Dan setiap orang akan selalu memiliki versi terbaru.
Apakah Anda tahu cara merancang program yang akan didukung? Perangkat lunak server harus dirancang agar dapat beradaptasi. Anda harus dapat mengubahnya dengan mudah, atau setidaknya tahu apa arti perubahan kecil dan apa yang penting.
Hal lain yang dapat berguna dalam perangkat lunak server adalah, tiba-tiba, kesinambungan pengiriman. Dalam aplikasi web, Anda dapat menggunakan sesuatu seperti
CPS untuk mendapatkan efek rutinitas dalam dunia sesi web tanpa kewarganegaraan. Semoga kontinuitas pengiriman tidak sia-sia jika peluang ini tidak terlalu mahal.
4. Abstraksi baru apa yang dibiarkan terbuka?
Saya tidak yakin seberapa masuk akal harapan ini, tetapi secara pribadi saya benar-benar ingin menemukan abstraksi baru - sesuatu yang bisa sama pentingnya dengan fungsi atau rekursi kelas satu, atau setidaknya parameter default. Mungkin ini adalah mimpi yang mustahil. Hal-hal semacam itu seringkali tidak terbuka. Tapi saya tidak kehilangan harapan.
Rahasia yang tidak banyak diketahui
1. Anda dapat menggunakan bahasa apa pun yang Anda inginkan
Sebelumnya, pembuatan aplikasi berarti pembuatan perangkat lunak desktop. Dan dalam perangkat lunak desktop ada bias besar terhadap penulisan aplikasi dalam bahasa yang sama dengan sistem operasi. Jadi sepuluh tahun yang lalu, menulis perangkat lunak secara keseluruhan berarti menulis perangkat lunak dalam C. Pada akhirnya, tradisi telah 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 telah mempelajari ini.
Perangkat lunak server menghancurkan model ini sepenuhnya. Dengan perangkat lunak server, Anda dapat mengambil bahasa apa pun yang Anda inginkan. Hampir tidak ada orang yang memahami hal ini (terutama manajer dan pemodal ventura). Tetapi beberapa peretas memahami ini, itulah sebabnya kami telah 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 dalam merancang bahasa pemrograman, bahwa ada audiens potensial untuk pekerjaan kami.
2. Kecepatan berasal dari profiler
Pengembang bahasa, atau setidaknya pelaksana, suka menulis kompiler yang menghasilkan kode cepat. Tapi saya pikir ini bukan apa yang membuat bahasa cepat bagi pengguna. Knut telah lama memperhatikan bahwa kecepatan hanya tergantung pada beberapa kemacetan. Dan siapa pun yang mencoba mempercepat program tahu bahwa Anda tidak bisa menebak kemacetannya. Profiler adalah jawabannya.
Pengembang bahasa sedang memecahkan masalah yang salah. Pengguna tidak perlu tolok ukur untuk bekerja dengan cepat. Mereka membutuhkan bahasa yang dapat menunjukkan bagian mana dari program mereka yang harus ditulis ulang. Pada titik ini, kecepatan diperlukan dalam latihan. Jadi mungkin lebih baik jika pelaksana bahasa menghabiskan setengah dari waktu yang mereka habiskan untuk mengoptimalkan kompiler dan menghabiskannya menulis profiler yang baik.
3. Anda memerlukan aplikasi yang membuat bahasa Anda berkembang
Mungkin ini bukan kebenaran tertinggi, tetapi sepertinya bahasa terbaik telah dikembangkan bersama dengan aplikasi yang digunakan. C ditulis oleh orang-orang yang membutuhkan pemrograman sistem. Lisp dirancang sebagian untuk diferensiasi simbolik, McCarthy sangat bersemangat untuk memulai sehingga ia mulai menulis program diferensiasi bahkan dalam dokumen Lisp pertama pada 1960.
Ini sangat baik jika aplikasi Anda memecahkan beberapa masalah baru. Ini mendorong bahasa Anda untuk memiliki fitur baru yang dibutuhkan programmer. Secara pribadi, saya tertarik untuk menulis bahasa yang baik untuk aplikasi server.
[Selama diskusi, Guy Steele juga menyatakan ide ini, menambahkan bahwa aplikasi tersebut tidak boleh terdiri dari menulis kompiler untuk bahasa Anda, kecuali bahasa Anda dimaksudkan untuk menulis kompiler.]
4. Bahasa tersebut harus sesuai untuk menulis program satu kali.Anda tahu apa arti program satu kali: ini saatnya Anda perlu dengan cepat menyelesaikan beberapa masalah terbatas. Saya percaya bahwa jika Anda melihat-lihat, Anda akan menemukan banyak program serius yang dimulai sebagai program satu kali. Saya tidak akan terkejut jika sebagian besar program dimulai hanya satu kali. Jadi, jika Anda ingin membuat bahasa yang cocok untuk menulis perangkat lunak secara umum, maka itu harus cocok untuk menulis program satu kali, karena ini adalah tahap awal dari banyak program.
5. Sintaks terkait dengan semantik
Secara tradisional diyakini bahwa sintaks dan semantik adalah hal yang sangat berbeda. Ini mungkin terdengar mengejutkan, tetapi tidak. Saya pikir apa yang ingin Anda dapatkan dalam program Anda terkait dengan bagaimana Anda mengekspresikannya.
Saya baru-baru ini berbicara dengan Robert Morris, dan dia memperhatikan bahwa kelebihan operator adalah nilai tambah dalam memenangkan bahasa dengan sintaks infiks. Dalam bahasa dengan sintaks awalan, fungsi apa pun yang Anda tetapkan sebenarnya adalah operator. Jika Anda ingin menjumlahkan tipe angka baru yang Anda buat, Anda bisa mendefinisikan 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 fungsi.
Gagasan yang muncul seiring waktu
1. Bahasa pemrograman baru
Melihat kembali pada tahun 1970-an, itu adalah mode untuk mengembangkan bahasa pemrograman baru. Sekarang tidak demikian. Tetapi saya percaya bahwa perangkat lunak server akan kembali membuat mode untuk menciptakan bahasa baru. Dengan perangkat lunak server, Anda dapat menggunakan bahasa apa pun yang Anda inginkan, jadi jika seseorang membuat bahasa yang tampaknya lebih baik daripada yang lain, akan ada orang yang memutuskan untuk menggunakannya.
2. Berbagi waktu
Richard Kelsey mengajukan gagasan ini, waktu yang telah datang lagi, dan saya sepenuhnya mendukungnya. Dugaan saya (dan Microsoft juga) adalah bahwa banyak perhitungan akan berpindah dari desktop ke server jarak jauh. Dengan kata lain, pembagian waktu telah kembali. Saya pikir Anda akan membutuhkan dukungan di tingkat bahasa. Misalnya, Richard dan Jonathan Reeves melakukan banyak pekerjaan untuk mengimplementasikan perencanaan proses dalam Skema 48.
3. Efisiensi
Baru-baru ini sepertinya komputer sudah cukup cepat. Semakin banyak kita mendengar tentang bytecode, yang setidaknya bagi saya berarti kita memiliki kekuatan dalam persediaan. Tapi saya pikir dengan perangkat lunak server, kami tidak memilikinya. Seseorang harus membayar untuk server yang menjalankan perangkat lunak, dan jumlah pengguna yang dapat ditahan server per mesin akan menjadi pembagi biaya modal mereka.
Saya pikir efisiensi itu penting, setidaknya dalam hambatan komputasi. Ini akan sangat penting untuk operasi I / O, karena aplikasi server melakukan banyak operasi seperti itu.
Pada akhirnya, mungkin ternyata bytecode bukan opsi. Sun dan Microsoft saat ini tampaknya akan bertatap muka di bidang bytecode. Tetapi mereka melakukan ini karena bytecode adalah tempat yang nyaman untuk menanamkan diri dalam proses, dan bukan karena bytecode saja adalah ide yang baik. Mungkin ternyata seluruh pertempuran ini akan luput dari perhatian. Itu akan lucu.
Perangkap dan perangkap
1. Pelanggan
Ini hanya asumsi, tetapi hanya aplikasi-aplikasi yang sepenuhnya menjadi sisi-server yang akan diuntungkan. Merancang perangkat lunak yang berfungsi dengan asumsi bahwa setiap orang akan memiliki klien Anda seperti menciptakan masyarakat berdasarkan asumsi bahwa setiap orang akan jujur. Pasti akan nyaman, tetapi Anda harus berasumsi bahwa itu tidak akan pernah terjadi.
Saya pikir akan ada peningkatan cepat dalam perangkat dengan akses ke web, dan kita dapat berasumsi bahwa mereka akan mendukung html dan formulir dasar. Apakah Anda memiliki browser di ponsel Anda? Apakah akan ada telepon di PalmPilot Anda? Apakah blackberry Anda memiliki layar lebih besar? Apakah Anda memiliki kesempatan untuk online dari gameboy Anda? Dari jam tangan Anda? Saya tidak tahu. Dan saya tidak perlu mencari tahu apakah saya yakin semuanya akan ada di server. Ini jauh lebih dapat diandalkan untuk memiliki semua otak di server. .
2. Pemrograman Berorientasi Objek
Saya mengerti bahwa ini adalah pernyataan yang kontroversial, tetapi saya tidak berpikir bahwa OOP adalah sesuatu yang penting. Saya pikir ini adalah paradigma yang cocok untuk aplikasi spesifik yang membutuhkan struktur data tertentu, seperti sistem jendela, simulasi, sistem CAD. Tapi saya tidak mengerti mengapa itu harus cocok untuk semua program.
Saya pikir orang-orang di perusahaan besar menyukai OOP, sebagian karena itu memberikan banyak hal yang tampak seperti pekerjaan. Apa, tentu saja, dapat direpresentasikan sebagai, katakanlah, daftar bilangan bulat, sekarang dapat direpresentasikan sebagai kelas dengan semua jenis perancah, dengan kebisingan dan kesibukan.
Fitur lain yang menarik dari OOP adalah bahwa metode memberi Anda efek tertentu dari fungsi kelas satu. Tapi ini bukan berita untuk programmer Lisp. Ketika Anda memiliki fungsi nyata dari kelas pertama, Anda bisa menggunakannya dengan cara apa pun yang sesuai dengan tugas, alih-alih memasukkan semuanya ke templat dari kelas dan metode.
Saya pikir ini berarti untuk desain bahasa yang Anda tidak boleh menanamkan OOP terlalu dalam ke dalamnya. Mungkin jawabannya adalah untuk menawarkan hal-hal yang lebih umum, mendasar, dan memungkinkan orang untuk merancang sistem objek apa pun dalam bentuk perpustakaan.
3. Desain oleh panitia
Jika bahasa Anda sedang dirancang oleh sebuah komite, maka Anda terjebak, dan tidak hanya karena alasan yang diketahui semua orang. Semua orang tahu bahwa komite cenderung membuat desain bahasa yang kental dan tidak konsisten. Tapi saya pikir bahayanya adalah mereka tidak mengambil risiko. Ketika seseorang berada di kepala, dia mengambil risiko yang tidak akan disetujui oleh komite.
Haruskah saya mengambil risiko untuk menciptakan bahasa yang baik? Banyak orang mungkin curiga bahwa mendesain bahasa adalah tempat Anda harus tetap dekat dengan kearifan tradisional. Saya yakin tidak. Dalam segala hal lain yang dilakukan orang, hadiah sebanding dengan risiko. Jadi mengapa desain bahasa harus berbeda?