Mengapa arus utama pemrograman tidak melek huruf? [Tutup]


32

Pemrograman melek huruf memiliki cita-cita yang baik. Menurut Anda mengapa ini bukan arus utama? Apakah karena gagal mengirim?


2
Karena alat yang dikembangkan untuk itu masih cukup lemah. Microsoft mungkin memiliki peluang memimpin dalam hal ini.
Ayub

3
Ketika mendekati masalah baru, saya sering menggunakan steno 'Literate Programming' saya sendiri menggunakan pensil dan kertas. Ini memungkinkan saya untuk mengabaikan semantik bahasa dan bercampur dalam bahasa manusia untuk menggambarkan hal-hal yang akan disebut fungsi, dll.
oosterwal

1
Bahkan Knuth tidak lagi meyakini konsep ini: "Dan kami meninggalkan gagasan lama tentang" pemrograman melek huruf "yang saya gunakan ketika mengembangkan TEX82, karena dokumentasi telah terbukti terlalu merepotkan." tug.org/TUGboat/tb31-2/tb98knut.pdf .
h0b0

6
Bagi mereka yang tidak terbiasa dengan TeX dan filosofinya, harus disebutkan bahwa kutipan Knuth kemungkinan besar berarti ironis.

3
@ h0b0 & user1249: Seluruh artikel oleh Knuth adalah ironi, karena Anda bisa mengetahuinya hanya dengan membaca sekilas saja. Ia juga mengejek Steve Jobs, web, Agile, refactoring, OOP, AOP, dan banyak hal lainnya. Itu lelucon!
Andres F.

Jawaban:


35

Saya pertama kali melihatnya di buku tulisan-tulisan Knuth, dan berpikir itu terlihat rapi. Kemudian saya mencoba menggunakan tampilan pemrograman sastra untuk memahami apa yang sedang terjadi dalam program, dan ternyata lebih sulit daripada yang terlihat. Mungkin saya sudah terlalu terbiasa membaca daftar program, tapi sepertinya membingungkan.

Lalu saya melihat kode sumber, dan itu mematikan saya saat itu juga. Saya harus belajar menulis program dengan cara yang sama sekali baru, dengan lebih sedikit korespondensi antara teks program dan apa yang dilihat kompiler, dan tidak melihat manfaat yang sesuai.

Selain itu, orang dapat menulis argumen yang panjang dan meyakinkan bahwa kode tersebut melakukan X ketika itu benar-benar melakukan Y, dan saya telah mengalami banyak komentar yang menyesatkan. Saya mengembangkan kesukaan untuk membaca kode untuk melihat apa yang dilakukannya cukup awal. Pemrograman melek adalah antitesis dari itu.


4
Pemrograman melek huruf, serta komentar pada umumnya, bukan tentang apa yang dilakukan kode Anda. Anda dapat membacanya dari kode itu sendiri. Ini semua tentang mengapa dan bagaimana , dan informasi penting ini hampir selalu hilang tanpa pemrograman melek huruf yang tepat. Tak perlu disebutkan bahwa bagian " mengapa? " Cukup sering melibatkan matematika yang rumit dan rumit, kadang-kadang plot dan tabel, kadang-kadang diagram. Alat pemrograman yang melek huruf diperlukan untuk menjaga komentar seperti itu dengan cara yang mudah dibaca.
SK-logic

1
@ SK-logic fair, tapi intinya yang dibuat David Thornley adalah bahkan MENGAPA bisa berubah menjadi kebohongan yang menyesatkan (yang sebenarnya lebih sulit untuk dipahami).
MrFox

1
+1 Knuth menulis kembali di pemrograman liar barat (tematik) ketika bekerja dalam bahasa "maju" berarti menulis "C" hampir di atas logam alih-alih menggunakan kode mesin. Memori adalah variabel yang sangat ketat dan nama-nama lain biasanya hanya huruf tunggal, sering digunakan kembali dari satu cakupan ke cakupan yang lain. Sebagian besar program di mana turn-key satu bidikan ditulis dan dikelola oleh satu orang masing-masing dengan gaya eksentrik sendiri. Harus mengambil alih basis kode lebih baik mendekripsi daripada membaca. Tidak ada kontrol sumber dll untuk membantu.
TechZen

1
Knuth sedang mencari jalan, 30 tahun yang lalu hari ini. Dia tahu program akan menjadi lebih besar, lebih rumit, ditulis oleh tim dengan anggota yang berpindah, akan berjalan selama bertahun-tahun atau puluhan tahun dan membutuhkan masukan, penilaian, dan akhirnya penerimaan dari bukan pemrogram. Pemrograman melek huruf adalah ide untuk mengatasi semua itu. Dia mencari tahu apa yang hari ini kita sebut logika bisnis dan BDD. Gagasan intinya adalah bahwa programmer akan tahu apa yang harus dilakukan dan non-programmer dapat mengikuti. Sebagaimana dicatat, gagasan itu gagal karena tidak ada mekanisme untuk menegakkan hubungan antara teks "melek" dan kode.
TechZen

BTW: Inilah sebabnya saya suka bahasa "mendokumentasikan diri sendiri" seperti Objective-C. Pada awalnya, kode tersebut terlihat berantakan dengan nama metode yang panjang, tetapi bahkan seorang programmer yang tidak tahu bahasa atau API dapat dengan cepat mencari tahu apa yang dilakukan kode. Yang terbaik dari semuanya, ubah kode dan "komentar" berubah secara otomatis. Tentu saja, itu sebabnya Objective-C ditulis dengan autocomplete bawaan. Tanpa itu, menulis Objective-C cukup neraka.
TechZen

13

Saya akan menyalahkan efek jaringan . Agar orang lain mengedit kode dan dokumentasi Anda, mereka harus dapat memahaminya.

Ini mendorong orang menjauh dari sesuatu seperti cweb / noweb, karena menggunakan mereka akan mengharuskan Anda untuk belajar TeX dan sintaks khusus program di atas bahasa pemrograman yang Anda gunakan untuk proyek. Ini bisa dilihat sebagai pemborosan waktu, terutama jika mereka tidak memerlukan pengaturan huruf matematika yang merupakan pengundian besar bagi TeX. (Dan bagi banyak pemrogram aplikasi, mereka benar-benar tidak akan membutuhkannya.) Sebaliknya mereka lebih suka sesuatu seperti komentar XML Visual Studio, karena itu sudah populer dan mapan.

Tempat saya telah melihat lepas landas pemrograman dalam komputasi ilmiah / statistik, di mana sebagian besar programmer memiliki pelatihan yang signifikan (alias PhD) dalam matematika, CS, atau statistik, dan dengan demikian sudah akrab dengan LaTeX. Dokumentasi yang mereka tulis lebih cenderung mencakup banyak formula rumit yang paling baik ditulis dalam TeX, dan mereka lebih cenderung pemrograman dalam R. Proporsi programmer R yang tahu tentang SWeave jelas jauh lebih tinggi daripada, katakanlah, Proporsi programmer C yang tahu tentang cweb.


2
Jawaban ini tampaknya menganggap bahwa semua alat pemrograman melek menggunakan LaTeX. Apakah ini benar? Sepertinya tidak ada apa-apa tentang konsep yang mengharuskannya.
AShelly

@ AShelly: Tidak perlu - Saya tahu bahwa sekarang, setidaknya, memungkinkan Anda menggunakan HTML. Namun dalam praktiknya, orang-orang yang menulis dokumentasi HTML akan menggunakan javadoc dan sejenisnya alih-alih alat pemrograman yang melek huruf.
Larry Wang

1
@ Ashelly, agar pemrograman melek bekerja, Anda harus dapat menghasilkan dokumen yang akan dicetak. Ini jauh, jauh lebih mudah ketika formatnya berbasis teks, dan setahu saya formatter dokumen berbasis teks yang paling kuat adalah TeX, dan cara termudah untuk bekerja dengan TeX adalah menggunakan LaTeX.

@ Mungkin Anda mungkin ingin melihat pada org-modedukungan untuk pemrograman melek . Ini cukup praktis, dan saya merasa jauh lebih mudah untuk dipahami (belum lagi mengelola ) daripada WEB atau NOWEB saja. Aspek penting dari kode adalah keterbacaan, dan ini dapat dibaca. (cf github.com/vermiculus/stack-mode )
Sean Allred

12

Saya terpesona dengan konsep Pemrograman Literate di akhir 90-an saat belajar, dan saya masih tertarik dengan pendekatan Knuths untuk pemrograman, dan penyusunan huruf. Tidak ada yang terbaik selain yang akan dilakukan.

Sistem Pemrograman Aksara yang dirancang Knuth melakukan banyak hal, lebih dari yang langsung terlihat, yaitu mengatasi banyak kekurangan dalam bahasa pemrograman yang mendasarinya yang dihasilkan oleh alat pembuat kode dari dokumen sumber Knuths, yaitu standar Pascal.

Bagi mereka yang cukup beruntung belum mencoba Standard Pascal, berikut adalah beberapa hal menarik.

  • Untuk membuatnya lebih mudah untuk memiliki kompiler single-pass, spesifikasi bahasa mengatakan bahwa semua deklarasi harus datang dalam urutan tertentu. Dari halaman wikipedia: "Setiap prosedur atau fungsi dapat memiliki deklarasi sendiri tentang label goto, konstanta, tipe, variabel, dan prosedur dan fungsi lainnya, yang semuanya harus dalam urutan itu." Ini berarti Anda tidak dapat mengelompokkan barang-barang Anda secara logis dalam file sumber.
  • Penanganan string lebih membosankan daripada di dataran C.
  • Pengidentifikasi tidak boleh memiliki panjang sewenang-wenang.
  • Banyak hal yang tidak dapat saya ingat lagi.

Semua hal ini pada dasarnya berarti bahwa Knuth membutuhkan bahasa pemrograman yang lebih baik (jadi dia menciptakannya) dan menggunakan Pascal sebagai bahasa rakitannya.

Kebanyakan bahasa modern dapat melakukan hal-hal ini tanpa banyak usaha, oleh karena itu menghapus sebagian besar pekerjaan yang harus dipecahkan Pemrograman Sastra.

Juga bahasa modern lebih ekspresif yang memungkinkan lebih banyak pemikiran untuk dimasukkan ke dalam kode itu sendiri.

Jadi, apa yang tersisa? Kemampuan untuk menghasilkan bentuk kumpulan dokumen dari kode sumber, dan BAHWA ada saat ini.

Bayangkan saja JavaDoc - Java runtime API mungkin adalah bagian terbesar dari Programming Literate yang tersedia saat ini (kecuali bahwa kode tersebut tidak benar-benar disajikan, tetapi BISA saja jika Java terbuka bersumber dari awal). Lihat misalnya presentasi kerangka koleksi di http://download.oracle.com/javase/6/docs/api/java/util/Collection.html

Saya percaya sistem serupa ada untuk .NET dan program utama lainnya.


To make it possible to have a single-pass compiler, all declarations had to come in a certain order. Perintah deklarasi seperti itu tentu menyederhanakan desain kompiler, tetapi itu tidak mengaktifkan / mencegah kompilasi single-pass. Delphi, misalnya, tidak memiliki batasan pesanan itu, tetapi itu masih merupakan kompiler Pascal single-pass.
Mason Wheeler

Sepakat. Turbo Pascal juga tidak memiliki batasan ini. Perhatikan, bagaimanapun, bahwa pembatasan ini dalam definisi Pascal sejak awal.

1
Tidak, Knuth beralih ke CWEB sejak lama, ini bukan tentang memperbaiki kekurangan Pascal. Tidak, JavaDoc tidak ada hubungannya dengan "pemrograman melek huruf" Knuth - dia berbicara tentang mengubah secara mendasar bagaimana dia membuat kode, dan mengklaim itu memungkinkan dia untuk mengatasi kompleksitas yang dia nyatakan tidak akan mungkin baginya atau orang lain untuk melanjutkan.
Ron Burk

@RonBurk CWEB hanya mengkompilasi ke "bahasa assembly" yang lebih baik. Ini tidak membatalkan keputusan desain aslinya.
Thorbjørn Ravn Andersen

5

Satu hal yang saya temukan ketika saya bergaul dengan pemrograman terpelajar di tahun 90-an adalah bahwa hal itu menarik orang-orang yang sangat bersemangat yang ingin melakukan Exactly The Right Thing - dan itu melibatkan penulisan sistem pemrograman literasi mereka sendiri karena tidak ada yang cukup baik untuk mereka. noweb adalah upaya yang baik untuk memotong itu dengan menyediakan penyebut yang cukup umum paling baik untuk semua orang, meskipun bahkan kemudian, saya menghabiskan sebagian besar waktu LP saya mengembangkan printer-cantik untuk itu ...

Masalah lain adalah bahwa itu benar-benar anti-gesit. Dalam beberapa hal, diperlambat itu baik karena memaksa Anda untuk berpikir lebih awal dan memperbaiki keadaan saat pertama kali. Di sisi lain, mendokumentasikan dengan cermat saat Anda pergi berarti ada hambatan besar untuk refactoring kode Anda. Dan jika Anda menunggu sampai kode Anda dikeraskan sebelum LP-ify itu, Anda berakhir dengan tugas dokumentasi multi-hari, yang benar-benar dapat menghentikan Anda di trek Anda.


Setelah bereksperimen saya telah menemukan bahwa sweet spot LP untuk kita semua, mungkin dalam mendokumentasikan keputusan desain dan detail arsitektur tepat di sebelah kode yang sebenarnya. Saya setuju dengan LP yang lebih sulit untuk refactor. Ini adalah pemahaman saya bahwa Knuth melakukan desain awal di atas kertas dan hanya ketika puas memulai implementasi yang sebenarnya. Ini kemungkinan besar adalah situasi yang sama yang saya temukan bermanfaat bagi saya.
Thorbjørn Ravn Andersen

3

Menurut pendapat saya yang sederhana, banyak perusahaan memiliki budaya yang berlawanan dengan tujuan Pemrograman Literate: mereka menginginkan hasil yang lebih cepat (mereka hanya menangis tentang kualitas ketika aplikasi sedang dalam produksi). Dalam pengalaman saya sendiri, bos saya telah menolak untuk memahami bahwa hasil yang lebih cepat tidak berarti "sebuah program yang dapat dijalankan sehari setelah saya memintanya." Bagi mereka, jika seorang pengembang tidak sibuk mengetik di atas keyboard-nya, ia tidak bekerja, "membuang-buang waktu dalam desain-tidak masuk akal". Ya, saya tahu, bos saya adalah gudang senjata.


Kemudian dengan Pemrograman Literate mereka mungkin berpikir Anda sibuk untuk menulis Sci-Fi Book daripada perangkat lunak lain! : D
Mahdi

Perusahaan seperti itu tidak mengerti bahwa perangkat lunak yang baik hidup sangat lama dan dokumentasi yang lebih baik semakin bernilai sumbernya.
Thorbjørn Ravn Andersen

2

Coder menulis kode bukan bahasa Inggris.

Coder tidak suka menulis dokumentasi karena itu tidak membantu menjalankan kode.

Coder tidak pandai menulis dokumentasi karena media yang buruk untuk mengekspresikan ide-ide mereka.

Pemrograman melek huruf tampaknya menjadi ide untuk membawa dokumentasi ke tingkat berikutnya di mana kode lebih merupakan pemikiran setelahnya. Mungkin itu akan berhasil, tetapi bagi kebanyakan coder sepertinya dokumentasi yang menjengkelkan.


29
Coders yang mematuhi poin yang Anda jelaskan bukan coders, saya ingin bekerja dengan saya.
Paul Nathan

1
@ Paul, diberikan. Tapi itulah yang sebenarnya ada di sana. Tapi menurut saya lebih banyak dokumentasi belum tentu lebih baik.
Winston Ewert

1
cukup mungkin yang terbaik
mlvljr

6
programmer berpengalaman tahu mereka PERLU untuk menulis dokumentasi karena di situlah "MENGAPA saya melakukannya seperti itu" pergi.

1
@ Thorbjørn Ravn Andersen, ya itu benar. Tapi pemrograman melek huruf, (seperti yang saya mengerti) menyarankan Anda menulis kode dengan dokumentasi Anda, bukan dokumentasi dengan kode Anda. Apakah banyak dokumentasi yang sangat membantu?
Winston Ewert

2

Terutama karena orang itu SANGAT BODOH. Kesaksian yang jelas yang merupakan aliran tebakan dan kesalahpahaman yang tak berujung yang diungkapkan oleh kaum muda tentang sifat teknik sederhana ini.

Orang-orang menganggap LP sebagai: (a) metode dokumentasi (b) metode penulisan beberapa esai yang dipoles yang memerlukan beberapa keterampilan atau bakat khusus (c) sama sekali tidak memiliki petunjuk - sebagai pencipta editor pemrograman Leo, dengan pengakuannya sendiri dll. dll.

Namun LP hanya: (1) menulis program dalam campuran kode dan frasa dalam bahasa manusia (= apa saja), di mana yang terakhir berdiri untuk potongan kode lain dan / atau frasa yang disertakan. Inilah yang dilakukan oleh penulis buku teks pemrograman yang tak terhitung jumlahnya .. dan (2) itu adalah preprocessor sederhana yang memperluas frasa-frasa itu pada manusia (yang menjadi seolah-olah nama-nama subrutin yang disertakan) untuk mengurai hasilnya DALAM PESANAN YANG DIBUTUHKAN OLEH KOMPILER (atau penerjemah). Kalau tidak, seseorang dapat memperluas teks tertulis dengan utilitas kecil lain untuk memasukkan simbol pemformatan untuk mengubah "sumber melek" menjadi teks yang dapat dibaca dan diformat dengan baik.

Orang muda tidak pernah mencoba ide yang sangat sederhana ini - dan berfantasi atau membayangkan alasan palsu mengapa mereka tidak akan pernah mencoba atau melakukannya.

Pada dasarnya ide utama pemrograman "dalam pseudocode" ditulis dalam bahasa manusia dan kemudian mengembangkannya dengan utilitas preprosesor sederhana. BANTUAN MENGELOLA PERHATIAN (terbatas, kesulitan utama untuk setiap program gondrong), cukup mirip dengan pelipatan kode atau pembagian aliran program Anda ke dalam fungsi / subrutin, diperlukan agar Anda tidak kehilangan diri sendiri dalam detail, tetapi sepenuhnya tidak perlu untuk eksekusi mesin.


3
Anda melewatkan satu bagian penting: (3) cara untuk memesan ulang kode dalam bahasa apa pun ke dalam urutan yang paling mudah dibaca dan alami, yang tidak harus sama dengan urutan yang harus ditangani oleh kompiler. Ini termasuk menyembunyikan detail implementasi dalam catatan kaki atau di mana pun jauh dari garis besar kode.
SK-logic

1

Ada 2 aspek program melek huruf yang saya lakukan keinginan dimasukkan ke dalam program utama - tertanam citra (misalnya, diagram desain) dan pointer ke usaha-usaha sebelumnya dan alternatif (misalnya, "Alasan itu seperti ini karena saya mencoba cara lain ini dan itu tidak berhasil karena ... "). Kedua aspek tersebut dapat ditangani dengan komentar dokumen dan URI.


1

Karena logika program tidak bekerja sama dengan yang kita bicarakan. Suatu program memiliki aliran yang ditentukan dengan baik, dan kondisi, dan loop.

Setelah memiliki banyak kode, saya BERPIKIR dalam istilah ini. Otak saya mengubah masalah menjadi domain target dari kode yang dapat dieksekusi. Dan jauh lebih efisien bagi saya untuk menuliskan ini dalam bahasa pemrograman yang biasa, daripada harus melakukan langkah transformasi ekstra untuk membuat program saya melek.

Bahkan, saya percaya program saya sudah melek ... pengenal berbicara, nama fungsi yang baik, komentar di mana saya melakukan beberapa hackery yang saya tidak akan langsung mengerti setelah beberapa bulan.

Untuk menyimpulkan: Kode Java saya lebih melek dengan sendirinya seperti yang diinginkan oleh setiap pemrograman "melek".


2
Kode Java tidak dapat melek huruf. "Pengidentifikasi berbicara" Anda tidak akan pernah menjelaskan mengapa Anda memilih algoritme khusus ini daripada yang lain, berapa batasannya, apa yang diharapkan oleh profil kinerja Anda, dll. Program melek huruf saya kebanyakan dibuat dari rumus, diagram, dan grafik, dan tidak sebanyak itu. teks bahasa inggris. Tetapi semua itu tidak bisa diekspresikan dalam kode dan terlihat jelek di dalam komentar sederhana.
SK-logic

1

Saya datang ke pemrograman melek sebaliknya - saya bermimpi memiliki kode yang diatur sesuai dengan pikiran saya, bukan sebagai kompiler membutuhkannya. Saya menemukan Leo hampir ideal untuk tujuan ini. Ini juga mendukung melacak file yang diubah di luar. File-file ini tidak harus mengandung markup khusus, jadi saya bisa menggunakan Leo untuk diri saya sendiri tanpa perlu orang lain di tim tahu. Fitur ini - "@shadow trees" - sangat menjanjikan, meskipun masih sedikit buggy, membutuhkan lebih banyak bola mata. Dan itu juga memperbaiki masalah "oh tidak, semuanya dalam satu file besar" dengan mengatur semuanya menjadi garis besar pohon dan dengan dukungan untuk file eksternal.

Bagi saya, bertentangan dengan namanya, "pemrograman melek huruf" bukan tentang dokumentasi sama sekali. Saya tidak memiliki lebih banyak dokumentasi dari sebelumnya. Ini tentang memiliki struktur yang membantu saya untuk tidak menjadi tersesat . Saya bersumpah terutama ketika mengelola file JSP raksasa (dan bahwa meskipun Leo awalnya ditujukan terutama untuk Python dan tidak memiliki dukungan untuk bahasa JSP - saya harus membagi file ke pohon Leo secara manual!).


0

Saya melihatnya sebagai alat pengajaran yang berharga, di mana disertasi tentang kode dapat ditulis, dan kemudian potongan-potongan kode kerja disisipkan di dalamnya untuk mengajar pembaca tentang bagaimana, apa, dan mengapa kode itu.

Di luar lingkungan pendidikan yang murni, saya pikir hanya Knuth yang benar-benar mengerti cara terbaik untuk menggunakannya.


-4

Ini adalah yang terburuk dari semua dunia - Anda harus menulis program komputer yang sangat benar, sangat spesifik dalam bahasa yang sangat tidak spesifik = bahasa Inggris. Jadi Anda harus hati-hati menulisnya menggunakan frasa yang tepat - jadi Anda sebaiknya menulis kode saja.


3
Anda tidak boleh mengulangi kode Anda dalam bahasa Inggris. Komentar harus menjelaskan alasan mengapa kode itu ada, bukan apa yang dilakukannya. Saya sering memasukkan grafik, diagram, dan plot ke dalam komentar saya yang melek, dan sangat membantu untuk memahami kodenya.
SK-logic

Jika komentar tidak mengatakan apa yang dilakukan kode, lalu bagaimanakah melek pemrograman - itu hanya pemrograman biasa dengan komentar. Saya pikir inti dari pemrograman melek huruf adalah untuk menggambarkan program dalam dokumen dan apakah sistem menghasilkan kode dari dokumentasi?
Martin Beckett

3
coba baca "TeX, programnya". Kode tidak pernah diulang dalam komentar di sana. Komentar menjelaskan mengapa kode ditulis seperti itu, dan menjelaskan arsitekturnya.
SK-logic

3
@ MartinBeckett Yang Anda gambarkan bukan LP.
Andres F.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.