🌅 💅 🛫 Paul Graham: Brevity = Kekuatan 👨🏻‍🔬 🚙 💕

Hari ini di HackerNews kami mengangkat diskusi tentang artikel Paul Graham pada tahun 2002 dan kami memutuskan untuk menghidupkan kembali terjemahannya dari tidak ada.

"Jumlah makna yang dikompres menjadi ruang kecil
oleh tanda-tanda aljabar, adalah keadaan lain yang memfasilitasi
penalaran yang biasa kita lakukan dengan bantuan mereka."
- Charles Babbage (1791-1871)

Dalam sebuah diskusi di sekitar LL1 Dendam artikel pada daftar LL1 mailing, Paul Prescod menyatakan ide yang tidak meninggalkan pikiran saya.

Tujuan Python adalah keteraturan dan keterbacaan, tetapi tidak singkat.

Pada pandangan pertama, bahasa pemrograman mungkin tidak seharusnya diklaim. Seperti yang saya pahami, singkatnya (ringkas, ringkas, padat) = kekuatan. Dan jika demikian, maka melakukan substitusi, kita mendapatkan:

Tujuan Python adalah keteraturan dan keterbacaan, tetapi bukan kekuatan.

yang, pada gilirannya, bukan kompromi yang sangat baik (jika itu benar-benar kompromi), yang layak untuk dibuat. Sepertinya jika Anda mengatakan: tujuan bahasa Python bukan untuk menjadi bahasa pemrograman yang efektif.

Apakah singkat = kekuatan? Ini sepertinya pertanyaan penting, mungkin pertanyaan paling penting bagi mereka yang terlibat dalam pengembangan bahasa. Saya belum yakin bahwa jawabannya adalah "ya", tetapi untuk awalnya ini adalah hipotesis yang bagus.

Hipotesa

Hipotesis saya adalah bahwa singkatnya adalah kekuatan, atau mereka sangat dekat sehingga, dengan pengecualian kasus patologis, Anda dapat mengambilnya untuk sesuatu yang identik.

Brevity, bagi saya, adalah untuk apa bahasa pemrograman diciptakan. Komputer akan sama bahagia jika mereka diberi instruksi langsung dalam bahasa mesin. Saya pikir alasan utama kita akan mengembangkan bahasa tingkat tinggi adalah untuk mendapatkan keuntungan dari mengekspresikan (dan yang lebih penting, berpikir) sepuluh baris dalam bahasa tingkat tinggi, yang akan membutuhkan 1000 baris kode mesin. Dengan kata lain, tujuan utama bahasa tingkat tinggi adalah untuk membuat kode sumber lebih pendek.

Jika kode sumber yang lebih pendek adalah tujuan dari bahasa tingkat tinggi, dan kekuatan sesuatu adalah ukuran seberapa baik tujuan tercapai, maka kekuatan bahasa pemrograman adalah seberapa banyak mengurangi program Anda.

Sebaliknya, bahasa yang tidak membuat program Anda lebih kecil melakukan pekerjaan yang buruk dari bahasa pemrograman, seperti pisau yang memotong dengan buruk, atau pencetakan yang tidak terbaca.

Metrik

Dan dalam hal apa kurang? Ukuran paling umum dari ukuran kode sumber adalah jumlah baris. Tetapi ukuran ini umum hanya karena kesederhanaan pengukuran, dan saya tidak berpikir bahwa ada yang percaya bahwa ini adalah ujian yang baik untuk ukuran program. Bahasa memiliki konvensi yang berbeda tentang apa yang dapat ditempatkan pada satu baris; beberapa baris dalam C mungkin hanya memiliki satu atau dua pemisah.

Tes sederhana lain adalah jumlah karakter dalam program, tetapi yang ini tidak terlalu bagus; beberapa bahasa (seperti Perl) memiliki pengidentifikasi lebih pendek daripada yang lain.

Saya pikir ukuran terbaik dari ukuran suatu program dapat berupa jumlah elemen, di mana elemen tersebut adalah sesuatu yang bisa menjadi simpul terpisah di pohon sumber. Nama variabel atau fungsi adalah elemen; bilangan bulat atau bilangan real adalah elemen; segmen teks teks adalah elemen; elemen dari suatu pola atau format format adalah elemen. Ada kasus batas (apakah "-5" satu atau dua elemen?), Tapi saya pikir kebanyakan dari mereka adalah sama dalam semua bahasa, sehingga mereka tidak akan terlalu mempengaruhi perbandingan.

Ukuran ini harus dikonkretkan, dan mungkin memerlukan interpretasi tambahan dalam kasus beberapa bahasa tertentu, tetapi bagi saya tampaknya itu mencoba untuk mengukur hal yang benar: jumlah bagian dari program. Pohon sumber adalah apa yang Anda gambar dalam pikiran Anda untuk mewakili program, dan dengan demikian ukuran pohon ini sebanding dengan jumlah pekerjaan yang dibutuhkan untuk menulis atau membacanya.

Rancangan

Ukuran ini memungkinkan kami untuk membandingkan berbagai bahasa, tetapi ini bukan, setidaknya bagi saya, nilai dasarnya. Dan nilai tes singkatnya adalah panduan untuk merancang bahasa. Perbandingan bahasa yang paling berguna adalah membandingkan dua variasi yang mungkin dari bahasa yang sama. Apa yang bisa saya lakukan dalam bahasa untuk membuat program lebih pendek?

Jika beban konseptual suatu program sebanding dengan kompleksitasnya, dan pemrogram tertentu dapat menahan beban konseptual tertentu, maka ini sama dengan bertanya: bagaimana bisa membantu pemrogram melakukan lebih banyak? Dan ini, menurut saya, sama dengan bertanya: bagaimana merancang bahasa yang baik?

(Ngomong-ngomong, kepalsuan ini sudah berjanggut mengatakan "semua bahasa adalah setara" paling jelas terlihat ketika merancang bahasa. Ketika Anda membuat bahasa baru, Anda terus-menerus membandingkan dua bahasa - satu di mana saya akan membuat X, dan yang lain di mana saya tidak akan - sehingga putuskan apa yang lebih baik. Jika itu adalah pertanyaan yang tidak ada gunanya, Anda bisa melempar koin dengan baik.)

Memiliki tujuan singkat sepertinya cara yang baik untuk menemukan ide-ide baru. Jika Anda menemukan cara untuk membuat program lebih pendek, maka ini bukan kebetulan: Anda mungkin menemukan abstraksi baru yang bermanfaat. Anda bahkan dapat menulis sebuah program yang akan mengambil potongan berulang dalam kode sumber. Gagasan baru dapat ditemukan di antara bahasa yang memiliki reputasi ringkas: Keempat, Sukacita, Ikon.

Perbandingan

Yang pertama menulis tentang hal-hal ini adalah, sejauh yang saya tahu, Fred Brooks dengan bukunya Mythical Man-Month. Dia menulis bahwa programmer menghasilkan jumlah kode yang sama terlepas dari bahasa. Ketika saya pertama kali membacanya di usia 20-an, itu adalah kejutan besar, dan bagi saya sepertinya ini memiliki konsekuensi besar. Ini berarti bahwa (a) satu-satunya cara untuk menulis program lebih cepat adalah dengan menggunakan bahasa yang lebih pendek, dan (b) orang yang peduli untuk melakukan ini akan meminta pukulan kepada pesaing yang tidak.

Dugaan Brooks, jika benar, mungkin merupakan inti dari peretasan. Sejak itu, selama bertahun-tahun, saya telah memperhatikan segala sesuatu yang akan relevan dengan masalah ini: dari studi teoretis hingga cerita tentang proyek individu. Saya tidak melihat apa pun yang akan bertentangan dengan hipotesis ini.

Tetapi saya belum melihat bukti yang jelas, dan saya tidak berharap untuk melihatnya. Studi seperti membandingkan bahasa pemrograman Lutz Prekelt, meskipun mereka menghasilkan hasil yang diharapkan, mereka cenderung menggunakan tugas-tugas yang terlalu kecil untuk tes yang bermakna. Tes terbaik untuk suatu bahasa adalah apa yang terjadi dalam program yang ditulis dalam sebulan. Dan jika Anda yakin, seperti saya, bahwa tujuan utama bahasa adalah untuk menjadi bahasa yang baik yang mereka pikirkan (alih-alih bahasa tempat mereka memberikan instruksi kepada komputer setelah Anda memikirkannya), maka ujian sebenarnya untuk bahasa tersebut adalah apa yang baru bisa Anda tulis di sana. Jadi, membandingkan bahasa berdasarkan spesifikasi yang telah ditentukan agak salah.

Tes sebenarnya untuk bahasa tersebut adalah seberapa baik Anda dapat menemukan dan memecahkan masalah baru, tetapi bukan tugas yang dirumuskan oleh orang lain. Ini adalah kriteria yang berbeda. Dalam seni, alat-alat seperti bordir dan mosaik berfungsi baik jika Anda tahu sebelumnya apa yang ingin Anda dapatkan, tetapi benar-benar tidak senonoh jika Anda tidak tahu. Jika Anda ingin mengungkapkan gambar dalam proses penulisan gambar (apa yang harus Anda lakukan ketika mengungkapkan hal-hal rumit seperti, misalnya, gambar seseorang), maka Anda harus menggunakan alat yang lebih fleksibel seperti pensil, tinta atau cat minyak. Tentu saja, permadani dan mosaik dibuat begitu saja: pertama gambar dibuat, dan kemudian hanya disalin.

Ini berarti bahwa kita tidak mungkin memiliki perbandingan yang tepat dari kekuatan relatif bahasa pemrograman. Kami akan memiliki perbandingan yang tepat, tetapi tidak yang benar. Secara khusus, studi yang secara eksplisit ditujukan pada perbandingan bahasa cenderung menggunakan tugas-tugas kecil dan tentu saja akan menggunakan serangkaian tugas yang telah ditentukan, dan karena itu akan cenderung meremehkan bahasa yang paling kuat.

Laporan dalam bidang ini, meskipun mereka akan kurang akurat daripada studi "ilmiah", cenderung lebih bermakna. Sebagai contoh, Ulf Wieger dari Ericsson melakukan penelitian dan sampai pada kesimpulan bahwa Erlang 4-10 kali lebih pendek dari C ++, dan kecepatan pengembangan perangkat lunak secara proporsional lebih tinggi:

Perbandingan proyek-proyek internal di Ericsson mengungkapkan produktivitas yang sama dalam garis kode per jam, termasuk semua fase pengembangan, terlepas dari bahasa yang digunakan (Erlang, PLEX, C, C ++ atau Java). Perbedaan dalam bahasa - hanya dalam jumlah total kode sumber.

Studi ini juga dengan jelas menunjukkan bahwa itu tidak muncul dalam buku Brooks (karena hanya mengukur garis-garis kode debug): program yang ditulis dalam bahasa yang lebih kuat cenderung mengandung lebih sedikit kesalahan. Ini sudah cukup, dan mungkin dalam tugas-tugas seperti switch jaringan, ini lebih penting daripada kinerja programmer.

Rasanya

Pada akhirnya, Anda bisa mempercayai insting Anda. Apa pemrograman dalam bahasa ini? Saya pikir bahwa untuk menciptakan bahasa yang lebih baik Anda harus menjadi hipersensitif terhadap seberapa baik bahasa memungkinkan Anda untuk berpikir di dalamnya, dan kemudian memilih atau mengembangkan bahasa yang tampaknya paling cocok untuk Anda. Jika ada properti bahasa yang merepotkan atau membatasi - jangan khawatir, Anda akan mengetahuinya.

Tetapi hipersensitivitas seperti itu akan mengakibatkan bahasa yang canggung menjadi tak tertahankan bagi Anda. Saya menemukan pemrograman dalam bahasa yang tidak memiliki makro yang sangat ketat, seperti halnya seseorang yang terbiasa dengan pengetikan dinamis akan mempertimbangkan pembatasan yang tidak tertahankan untuk kembali ke bahasa, di mana jenis harus dideskripsikan untuk setiap variabel yang dideklarasikan dan tidak mungkin untuk mendeklarasikan daftar yang terdiri dari elemen. berbagai jenis.

Dan saya tidak sendiri. Saya tahu banyak peretas Lisp dengan siapa hal serupa terjadi. Bahkan, ukuran yang paling akurat dari kekuatan relatif bahasa pemrograman bisa menjadi proporsi programmer yang tahu bahasa tertentu yang akan melakukan pekerjaan apa pun di mana bahasa ini harus digunakan, terlepas dari area subjek.

Keterbatasan

Mungkin banyak peretas tahu bagaimana rasanya ketika bahasa itu tampak membatasi. Ini mungkin perasaan yang sama seperti ketika Anda terjebak dalam kemacetan lalu lintas di jalan yang ingin Anda lalui dan Anda harus mengambil jalan memutar yang panjang. Anda ingin mengatakan sesuatu dan bahasa tidak memungkinkan Anda untuk melakukan ini.

Faktanya, bahasa pembatas bukanlah bahasa yang ringkas. Masalahnya bukan bahwa Anda tidak dapat mengekspresikan sesuatu, tetapi bahwa jalan memutar yang memaksa bahasa ini untuk Anda buat terlalu lama. Lakukan eksperimen pemikiran ini: Anda ingin menulis semacam program, dan bahasanya tidak memungkinkan Anda untuk melakukannya dengan cara yang Anda rencanakan, tetapi sebaliknya membuat Anda membuatnya lebih pendek. Setidaknya bagi saya ini tidak akan terlalu membatasi. Seolah-olah seorang polisi akan mengarahkan Anda dari kemacetan lalu lintas ke jalan yang lebih pendek daripada jalan memutar yang panjang. Wow!

Menurut saya, perasaan keterbatasan pada dasarnya (sebesar 90 persen?) Berasal dari kenyataan bahwa Anda terpaksa membuat program lebih lama dalam bahasa yang Anda tulis, dibandingkan dengan bahasa yang Anda pikirkan. Keterbatasan pada dasarnya tidak cukup singkat, jadi ketika suatu bahasa tampaknya membatasi, itu berarti bahwa itu tidak cukup pendek.

Keterbacaan

Kutipan yang saya mulai dengan juga menyebutkan dua kualitas lain: keteraturan dan keterbacaan. Saya tidak benar-benar mengerti apa itu keteraturan, dan apa manfaat kode reguler dan dapat dibaca dibandingkan dengan kode yang hanya bisa dibaca. Tapi saya rasa saya tahu apa yang dimaksud dengan keterbacaan, dan juga bagi saya ini berkaitan dengan singkatnya.

Di sini kita harus berhati-hati dengan konsep keterbacaan satu baris kode dan keterbacaan program secara keseluruhan. Hanya yang terakhir yang penting. Saya setuju bahwa satu baris pada BASIC kemungkinan besar lebih mudah dibaca daripada satu baris pada Lisp, tetapi sebuah program yang ditulis dalam BASIC akan memiliki lebih banyak baris daripada program yang sama yang ditulis dalam Lisp. Membaca program BASIC akan membutuhkan lebih banyak usaha.

usaha total = usaha membaca satu baris * jumlah baris

Saya tidak begitu yakin bahwa keterbacaan sebanding dengan singkatnya, tetapi jelas singkatnya adalah faktor dalam keterbacaan (lihat rumus di atas). Jadi hampir tidak masuk akal untuk mengatakan bahwa tujuan dari bahasa adalah keterbacaan, tetapi tidak singkat.

Untuk pengguna yang melihat bahasa tertentu untuk pertama kalinya, keterbacaan baris demi baris berarti bahwa bahasa ini akan tampak tidak berbahaya baginya. Dengan demikian, keterbacaan baris demi baris dapat menjadi keputusan pemasaran yang baik, meskipun itu adalah keputusan desain yang buruk. Ini isomorfik berkenaan dengan metode pembayaran dalam angsuran: alih-alih diintimidasi oleh setoran besar, Anda menawarkan kepada pembeli pembayaran bulanan kecil. Pembayaran dalam bagian-bagian pada akhirnya tidak menguntungkan baginya, serta keterbacaan baris demi baris - untuk programmer. Pembeli harus melakukan banyak pembayaran kecil, sama seperti programmer harus membaca banyak baris yang dapat dibaca secara terpisah.

Rasio ini ada bahkan sebelum munculnya bahasa pemrograman. Jika Anda membaca novel dan artikel surat kabar, maka pengalaman pertama Anda membaca artikel dalam matematika bisa menakutkan: membaca satu halaman membutuhkan waktu setengah jam. Namun demikian, saya yakin bahwa masalahnya bukan pada notasi, seperti yang terlihat pada pandangan pertama. Artikel dalam matematika sulit dibaca karena ide-idenya sendiri kompleks. Jika Anda mengekspresikan ide yang sama dalam bentuk prosa (seperti yang dilakukan ahli matematika sebelum mereka memikirkan notasi singkat), maka membacanya tidak akan lebih mudah, karena satu halaman ini akan berubah menjadi buku yang utuh.

Dalam derajat apa?

Beberapa tidak setuju dengan gagasan singkat = kekuatan. Saya pikir, alih-alih berdebat apakah ini benar, akan lebih berguna untuk bertanya sejauh mana singkatnya kekuatan? Karena jelas bahwa singkatnya adalah salah satu tujuan utama bahasa pemrograman. Dan jika tidak, apa tujuannya, dan seberapa pentingkah fungsi-fungsi lainnya?

Saya mengusulkan ini untuk tidak membuat diskusi lebih sopan. Saya benar-benar ingin tahu jawabannya. Kapan, jika ini terjadi sama sekali, apakah bahasanya menjadi cukup ringkas?

Hipotesis yang saya mulai adalah bahwa, tidak termasuk beberapa kasus patologis, singkatnya identik dengan kekuatan. Maksud saya, mereka akan identik dalam bahasa apa pun yang dikembangkan oleh seseorang, tetapi jika seseorang ingin membuat bahasa yang khusus untuk membantah hipotesis ini, maka itu mungkin akan berhasil. Tapi aku juga tidak begitu yakin tentang itu.

Bahasa Tapi Bukan Program

Harus diperjelas bahwa kita berbicara tentang singkatnya bahasa, bukan program individual. Tentu saja, beberapa program dapat ditulis dengan sangat ketat.

Saya menulis tentang ini di buku "About Lisp". Agar makro dapat membenarkan dirinya sendiri, ia harus menghemat banyak kali lebih banyak ruang dalam kaitannya dengan panjangnya sendiri. Jika beberapa makro besar menyimpan sepuluh baris kode setiap kali Anda menggunakannya, dan makro itu sendiri terdiri dari sepuluh baris, maka Anda akan mendapatkan penghematan dalam garis jika Anda menggunakannya lebih dari dua kali. Tapi ini masih langkah yang buruk, karena definisi makro lebih sulit dibaca daripada kode biasa. Anda mungkin perlu menggunakan makro 10 atau 20 kali sebelum keterbacaan meningkat.

Saya yakin bahwa dalam bahasa apa pun kompromi seperti itu dimungkinkan (walaupun saya curiga taruhannya dinaikkan dalam bahasa yang kuat). Setiap programmer pernah melihat kode yang sangat singkat karena teknik pemrograman yang meragukan.

Dengan demikian, tidak dapat dibantah - setidaknya bagi saya - bahwa program bisa cukup ringkas. Pertanyaannya adalah, bisakah bahasa itu sendiri pendek? Bisakah bahasa memaksa programmer untuk menulis secara singkat (dalam elemen) dengan biaya keterbacaan?

Salah satu alasan sulit untuk membayangkan bahasa yang terlalu ringkas adalah bahwa jika ada cara yang terlalu kompak untuk mengekspresikan sesuatu, maka mungkin akan ada cara yang lebih lama. Misalnya, jika Anda menggunakan makro atau fungsi tingkat tinggi di Lisp terlalu padat, Anda dapat menulis kode yang isomorfis ke Pascal. Jika Anda tidak ingin mengekspresikan faktorial dalam bahasa Arc sebagai panggilan ke fungsi tingkat tinggi,

(rec zero 1 * 1-)

maka Anda juga dapat menulis definisi rekursif:

(rfn fact (x) (if (zero x) 1 (* x (fact (1- x)))))

Meskipun saya tidak dapat memberikan contoh dengan segera, saya tertarik pada pertanyaan: apakah bahasanya terlalu pendek? Adakah bahasa yang memaksa Anda untuk menulis kode yang tidak terbaca? Jika ada yang punya contoh, saya akan senang melihatnya.

(Ingat: Saya tertarik pada program yang memiliki kepadatan tinggi sesuai dengan ukuran "elemen" yang dijelaskan di atas, tetapi bukan program yang pendek hanya karena pemisah dapat dihilangkan di dalamnya dan semuanya memiliki nama yang panjangnya satu karakter.)

Pertama kali dipublikasikan di sini .

Pelajari detail tentang cara mendapatkan profesi yang dicari dari awal atau Tingkatkan keterampilan dan gaji dengan mengambil kursus online SkillFactory:

Paul Graham: Brevity = Kekuatan