Mengapa bahasa lebih suka lekukan daripada penanda eksplisit untuk blok?


11

Saya belajar Haskell, dan saya sedang mencari alat lekukan otomatis. Saya tidak terlihat banyak, dan mengetahui bahwa di Haskell (seperti dalam Python), lekukan menandakan sebuah blok. Akibatnya, saya menduga bahwa tidak mungkin membuat alat pemformatan otomatis, sekuat dalam bahasa lain dalam keluarga C, yang menggunakan penanda eksplisit, seperti {} (kurung kurawal) atau begin endkata kunci.

Saya tidak keberatan bahasa yang membuat lekukan agar mudah dibaca, tetapi saya tidak dapat memahami manfaat dari kedua penguatan lekukan dan memiliki beberapa penanda eksplisit, sehingga alat otomatis, dapat memahami apa yang termasuk dalam blok mana.

Jika preferensi lekukan menandai suatu blok, adalah agar kode terlihat lebih baik, maka saya masih tidak mengerti keuntungannya. Mengingat bahwa tab dan spasi diwakili secara berbeda dalam editor dan font yang berbeda (font mono-ruang misalnya terlihat lebih rapi), tidak mungkin mengharapkan programmer untuk menyajikan kode dengan sopan. Alat yang dapat memperhitungkan editor teks saat ini, akan jauh lebih tepat untuk memformat kode dengan benar.

Mengapa perancang bahasa memilih indentasi daripada marker blok eksplisit?


8
Bukan jawaban, tetapi Haskell membuat sensitivitas spasi putih jauh lebih opsional daripada python. Anda dapat menggunakan titik koma untuk sebagian besar hal, dan membungkus balok dalam kurung kurawal jika diinginkan. let x =1; y = 2; z = 3sepenuhnya valid, sebagaimana adanya do { putStrLn $ show x; putStrLn $ show y; putStrLn $ show z; }. Mereka tidak perlu berada di jalur yang sama.
KChaloux

8
"Tidak mungkin membuat alat pemformatan otomatis" - sebenarnya, tidak perlu alat pemformatan otomatis seperti itu di Python karena aturan indentasi.
Doc Brown

13
Um, meningkatkan indentasi adalah penanda blok eksplisit.
Karl Bielefeldt

3
@ K.Gkinis: Sumber terbaik untuk motivasi yang tepat di balik keputusan desain bahasa adalah perancang bahasa itu sendiri.
Robert Harvey

3
Pertanyaan ini sebenarnya bukan subyektif. Ia bertanya mengapa beberapa perancang bahasa memilih sintaksis tertentu. Ini bisa dijawab. Jika pertanyaan itu menanyakan sintaksis mana yang terbaik , itu akan bersifat subyektif.
JacquesB

Jawaban:


13

Guido Von Rossum

Dari wawancara dengan Guido Van Rossum , yang dapat dilihat dalam teks lengkap dengan books.google.com (penekanan milik saya):

Pilihan indentasi untuk pengelompokan bukan konsep baru dengan Python; Saya mewarisi ini dari ABC , tetapi juga terjadi di occam, bahasa yang lebih tua. Saya tidak tahu apakah penulis ABC mendapatkan ide dari occam, atau menciptakannya secara independen, atau apakah ada leluhur yang sama. Tentu saja, saya bisa memilih untuk tidak mengikuti jejak ABC, seperti yang saya lakukan di daerah lain (misalnya, ABC menggunakan huruf besar untuk kata kunci bahasa dan nama prosedur, sebuah ide yang tidak saya salin), tetapi saya menyukai fitur ini cukup banyak. sedikit saat menggunakan ABC, karena sepertinya menyingkirkan jenis tertentu dari perdebatan sia-sia yang umum di antara pengguna C pada saat itu, tentang di mana menempatkan kurung kurawal .

Von Rossum sangat terinspirasi dari ABC , dan meskipun ia tidak harus menyalin semua itu, penggunaan lekukan tetap dipertahankan karena itu bisa bermanfaat dalam menghindari perang agama.

Saya juga sangat menyadari bahwa kode yang dapat dibaca menggunakan indentasi secara sukarela untuk menunjukkan pengelompokan, dan saya telah menemukan bug yang halus dalam kode di mana lekukan tidak setuju dengan pengelompokan sintaksis menggunakan kurung kurawal — programmer dan setiap pengulas telah mengasumsikan bahwa lekukan cocok dengan pengelompokan tersebut. dan karena itu tidak melihat bug. Sekali lagi, sesi debugging panjang mengajarkan pelajaran yang berharga.

Rossum juga menyaksikan bug karena ketidakkonsistenan antara pengelompokan dan indentasi, dan tampaknya meskipun mengandalkan indentasi hanya untuk menyusun kode akan lebih aman dari kesalahan pemrograman 1 .

Donald E. Knuth & Peter J. Landin

Dalam wawancara yang direferensikan, Guido menyebutkan ide Don Knuth menggunakan indentasi. Ini dirinci dalam Kutipan Indentasi Knuth yang ditemukan kembali , yang mengutip Pemrograman Terstruktur dengan Pernyataan goto . Knuth juga mereferensikan 700 bahasa pemrograman Peter John Landin berikutnya (lihat bagian Diskusi tentang lekukan). Landin mendesain ISWIM yang terlihat seperti bahasa pertama dengan lekukan alih-alih blok awal / akhir. Makalah-makalah itu lebih tentang kelayakan menggunakan indentasi untuk menyusun program daripada argumen aktual yang mendukung melakukannya.


1. Saya pikir ini sebenarnya adalah argumen yang mendukung kedua konstruksi pengelompokan dan pemformatan otomatis, untuk menangkap dan memulihkan dari kesalahan pemrograman, yang pasti akan terjadi. Jika Anda mengacaukan lekukan Anda dengan Python, orang yang mendebug kode Anda harus menebak yang mana yang benar:

if (test(x)):
  foo(x)
  bar(x)

Haruskah barselalu dipanggil atau hanya jika tes berhasil?

Konstruksi pengelompokan menambahkan tingkat redundansi yang membantu Anda menemukan kesalahan ketika Anda secara otomatis indentasi kode Anda. Di C, kode yang setara dapat diindentasi otomatis sebagai berikut:

if (test(x))
  foo(x);
bar(x);

Jika saya bermaksud barberada pada level yang sama dengan foo, maka indentasi otomatis berdasarkan struktur kode biarkan saya melihat bahwa ada sesuatu yang salah yang dapat diperbaiki dengan menambahkan kawat gigi di sekitar foodan bar.

Dalam Python: Mitos tentang Indentasi , ada contoh yang seharusnya buruk dari C:

/*  Warning:  bogus C code!  */

if (some condition)
        if (another condition)
                do_something(fancy);
else
        this_sucks(badluck);

Itu kasus yang sama seperti di atas, di Emacs, saya menyorot seluruh blok / fungsi, tekan Tab, dan kemudian semua kode dihidupkan kembali. Perbedaan antara lekukan manusia dan struktur kode memberi tahu saya ada yang tidak beres (itu dan komentar sebelumnya!).

Selain itu, kode perantara di mana lekukan dimatikan dalam C tidak membuatnya melalui cabang utama, semua cek gaya di tempat akan membuat GCC / Jenkins berteriak padaku. Saya baru-baru ini memiliki masalah yang mirip dengan yang dijelaskan di atas dalam Python, dengan pernyataan off oleh satu tingkat indentasi. Kadang-kadang saya memiliki kode dalam C yang melampaui penjepit penutupan, tetapi kemudian saya menekan Tab dan kode indentasi "salah": itu satu lagi kesempatan untuk melihat bug.


3
"Untuk menghindari perang agama ..." Aku terkejut bahwa alasan sebenarnya sangat sepele.
Robert Harvey

1
@RobertHarvey: Penekanan pada frasa itu adalah dengan coredump, bukan oleh van Rossum. Itu bukan alasan utama jika Anda membaca kutipan van Rossum dalam konteks.
JacquesB

@ JacquesB Tolong beritahu saya konteks apa yang hilang dari kutipan, sehingga saya dapat mengedit jawabannya.
coredump

4
Saya tidak mendapatkan komentar pribadi Anda: Jika Anda mengacaukan indentasi dengan Python, maka Anda memiliki bug. Jika Anda mengacaukan kawat gigi di C Anda memiliki bug. Jika Anda menggunakan indentasi otomatis, kedua bahasa itu persis sama. Dan jika Anda tidak menggunakan indentasi otomatis, bug dapat disembunyikan secara tersembunyi di C dengan cara yang tidak mungkin dilakukan dengan Python.
JacquesB

2
@ JacquesB karena mengetikkan kurung kurawal adalah sesuatu yang Anda lakukan secara aktif; tidak cukup menjorok adalah sesuatu yang bisa Anda lupa lakukan. Tentu saja Anda bisa lupa untuk menutup penyangga pada waktu yang tepat, tetapi Anda harus melakukannya pada akhirnya dan mendapatkan kesempatan lain untuk memikirkannya. Saya kira python berfungsi baik untuk pemula karena memaksa perhatian ke lekukan.
marstato

7

Ini sangat subyektif dan menyebabkan banyak perang api. Namun:

Memiliki simbol yang membatasi blok dan lekukan melanggar prinsip KERING , karena Anda mengekspresikan informasi yang sama dengan dua cara berbeda. Keberadaan alat indentasi otomatis adalah gejala dari pelanggaran KERING ini: Bahwa Anda dapat secara otomatis menghasilkan indentasi menunjukkan bahwa itu adalah informasi yang berlebihan, dan itu berarti lekukan dan simbol mungkin keluar dari sinkronisasi yang mengarah pada kode menyesatkan.

FAQ Desain dan Sejarah Python menyatakan ini dengan sangat jelas:

Mengapa Python menggunakan lekukan untuk pengelompokan pernyataan?

Guido van Rossum percaya bahwa menggunakan lekukan untuk pengelompokan sangat elegan dan berkontribusi banyak pada kejelasan program Python rata-rata. Kebanyakan orang belajar menyukai fitur ini setelah beberapa saat.

Karena tidak ada tanda kurung mulai / ujung, tidak mungkin ada ketidaksepakatan antara pengelompokan yang dirasakan oleh pengurai dan pembaca manusia.

Memang benar bahwa Anda tidak dapat membuat alat lekukan otomatis untuk Python, tetapi ini adalah hal yang baik: Itu berarti Anda tidak memiliki redudansi dalam sintaksis yang Anda perlukan alat otomatis untuk melakukan rekonsiliasi.

Tab vs spasi adalah masalah sah dalam Python, dan disarankan untuk tidak pernah mencampur tab dan spasi (untuk indentasi) dalam basis kode yang sama.

Python mewarisi indentasi signifikan dari bahasa pendahulunya (sekarang usang) ABC. ABC adalah salah satu dari sedikit bahasa pemrograman yang telah menggunakan pengujian kegunaan untuk mengarahkan desain. Jadi, sementara diskusi tentang sintaksis biasanya mengarah pada pendapat subyektif dan preferensi pribadi, pilihan indentasi yang signifikan sebenarnya memiliki dasar yang lebih kuat.


6
Akuntansi entri ganda juga melanggar KERING. Redundansi terkadang merupakan fitur.
coredump

3
@coredump: Benar, tapi itu adalah redundansi yang dirancang dengan sengaja. Sebagian besar bahasa pemrograman, termasuk Python, berisi redudansi yang dipilih secara sengaja - mis. passKata kunci yang dapat disimpulkan secara otomatis, tetapi mengharuskannya secara eksplisit membantu menemukan kesalahan. Redundansi yang tidak disengaja memiliki kedua simbol awal / akhir (untuk kompiler) dan lekukan (untuk pembaca manusia) tampaknya menyebabkan lebih banyak kesalahan daripada yang ditangkap. Setidaknya ini tampaknya menjadi pandangan van Rossum.
JacquesB

@coredump - Sekarang saya tahu mengapa saya bukan seorang akuntan.
JeffO

3
@coredump Anda merindukan COBOL PROCEDURE DIVISION.juga? Saya tidak pernah tahu di mana DATA DIVISIONujung dan prosedurnya dimulai dalam bahasa-bahasa baru ini.
msw

2
@coredump: "melihat indentasi bertentangan dengan apa yang ada dalam pikiran saya sudah cukup untuk mencegah kesalahan" - tepatnya.
JacquesB

2

Desainer bahasa memilih spasi putih yang signifikan secara sintaksis karena mereka percaya (atau setidaknya berpikir bahwa pengguna potensial mereka percaya) bahwa semi-titik dua dan kawat gigi menambah kebisingan ketika membaca kode, merusak produktivitas. Alasan umum lainnya adalah gaya pengkodean yang buruk / tidak konsisten merusak keterbacaan - dengan memaksakan skema indentasi yang umum, bahasa tersebut memiliki keterbacaan yang lebih baik secara keseluruhan. Alasan yang kemudian menjadi kurang penting sekarang karena IDE pemformatan otomatis lebih umum, tetapi masih dapat diterapkan.


1
Saya bisa melihat mengapa orang akan mempertimbangkan titik koma dan keriting kawat gigi kebisingan. Tapi bukankah kurang produktif harus mengetik ruang 4/8/12 kali? Dan jika Anda melewatkan satu (karena mereka tidak terlihat) Anda dalam kesulitan.
Pasang kembali Monica

5
Itu sebabnya Anda menggunakan tab alih-alih spasi, atau IDE yang memahami cara mengubah tab menjadi blok empat ruang.
Robert Harvey

@ K.Gkinis: Indentasi tidak terlihat. Hanya spasi putih di ujung garis yang tidak terlihat, tetapi ini tidak signifikan dalam bahasa apa pun. Hanya jika Anda mencampur tab dan spasi Anda akan mendapat masalah. Jadi jangan lakukan itu.
JacquesB

@ JacquesB: masalah dengan visibilitas / invisibilitas indentasi adalah bahwa sebagai manusia Anda sering tidak dapat membedakan antara spasi dan tab, sedangkan komputer dapat dan sering melakukannya. Jadi, sementara lekukan terlihat, cara komputer menginterpretasikan lekukan bisa berbeda. Itulah masalah sebenarnya: ketika komputer memperlakukan karakter yang tak terlihat berbeda dari manusia. Manusia mengukur lekukan sebagai jarak pada layar, komputer dapat mengukurnya sebagai jumlah karakter literal. itulah bagian yang tidak terlihat.
Bryan Oakley

@BryanOakley: Ya, inilah mengapa Anda tidak harus mencampur tab dan spasi di lekukan.
JacquesB
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.