Haruskah bahasa pemrograman ketat atau longgar? [Tutup]

Dalam Python dan JavaScript, semi-titik dua adalah opsional.

Dalam PHP, tanda kutip di sekitar kunci-array adalah opsional ( $_GET[key]vs $_GET['key']), meskipun jika Anda menghilangkannya, pertama-tama akan mencari konstanta dengan nama itu. Ini juga memungkinkan 2 gaya berbeda untuk blok (kolon, atau dibatasi kurung).

Saya membuat bahasa pemrograman sekarang, dan saya mencoba memutuskan seberapa ketat saya harus membuatnya. Ada banyak kasus di mana karakter tambahan tidak benar-benar diperlukan dan dapat ditafsirkan secara ambigu karena prioritas, tetapi saya bertanya-tanya apakah saya harus tetap menegakkan mereka atau tidak untuk mendorong konsistensi.

Bagaimana menurut anda?

Oke, bahasa saya bukan bahasa pemrograman seperti bahasa templating yang mewah. Semacam persilangan antara template Haml dan Django . Dimaksudkan untuk digunakan dengan kerangka kerja C # saya, dan seharusnya sangat bisa dikembangkan.

Berbagai jenis bahasa memiliki kegunaan yang berbeda, jadi jawaban untuk pertanyaan ini sangat tergantung pada apa yang akan Anda gunakan.

Sebagai contoh, Perl adalah bahasa yang sangat longgar, dan saya merasa sangat berguna untuk menulis skrip perbaikan cepat atau angka. Untuk proyek padat yang kokoh saya menggunakan C #.

Anda perlu mendapatkan keseimbangan yang tepat untuk penggunaan target. Semakin ketat, semakin lama Anda harus menghabiskan waktu menulis kode, tetapi Anda mendapatkan ketahanan yang lebih besar, usabilitas ulang, dan lebih mudah untuk mempertahankannya.

Apa yang saya cari dalam bahasa pemrograman (bukan bahasa scripting) adalah konsistensi dan pengetikan yang kuat.

Dalam bahasa pemrograman saat ini dimungkinkan untuk menghilangkan titik koma misalnya di tempat-tempat tertentu tanpa menjadi ambigu (ekspresi terakhir dalam satu {}blok adalah satu). Jika bahasa pemrograman memungkinkan Anda menghilangkan karakter dalam kasus ini, seorang programmer sekarang memiliki masalah tambahan; di atas sintaksis bahasa umum dia sekarang harus tahu dalam hal apa diizinkan juga untuk menghilangkan sebagian sintaksis.

Pengetahuan ekstra ini bukan masalah bagi programmer yang menulis kode, tetapi itu menjadi beban bagi siapa saja yang harus menafsirkan kode yang ada di kemudian hari (termasuk penulis asli setelah beberapa saat).

Contoh PHP Anda membuka kemungkinan bug halus dalam sebuah program ketika konstanta keyakan ditambahkan dalam konteks yang sama. Kompiler tidak memiliki cara untuk mengetahui bahwa itu bukan apa yang dimaksudkan, jadi masalahnya hanya menjadi jelas pada saat runtime daripada waktu kompilasi.

Setiap tempat di mana ada beberapa ambiguitas, kompiler perlu memiliki beberapa cara untuk menebak apa yang sebenarnya dimaksud oleh programmer. Setiap kali ini terjadi, ada kemungkinan bahwa programmer benar-benar berarti sesuatu yang berbeda, tetapi tidak memiliki aturan ambiguitas resolusi.

Menulis kode yang benar secara logis sudah cukup sulit. Menambahkan ambiguitas sintaksis mungkin tampak "bersahabat" di permukaan, tetapi ini merupakan undangan terbuka untuk memperkenalkan bug baru yang tidak terduga, sulit di-debug ke dalam basis kode. Intinya, seketat mungkin.

Dari contoh Anda, Anda menyebutkan bahwa titik koma adalah opsional dalam Python dan JavaScript. Untuk Javascript, setidaknya, ini tidak sepenuhnya benar. Titik koma sama seperti yang disyaratkan dalam JS seperti dalam bahasa keluarga C lainnya. Tetapi parser JavaScript diperlukan oleh spesifikasi bahasa untuk menyisipkan titik koma yang hilang dalam kondisi tertentu. Ini secara luas dianggap sebagai hal yang sangat buruk karena cenderung membuat niat Anda salah dan mengacaukan kode Anda.

Jawaban untuk seberapa longgar Anda harus membuat bahasa Anda sama dengan jawaban dari pertanyaan yang dikatakan dalam aksen Texas "Seberapa beruntung perasaan Anda, punk?".

Semua orang tidak perlu bekerja keras untuk konsistensi pengkodean jika bahasa tidak memiliki banyak variasi. Kami tidak suka jika pengguna membuat permintaan yang tidak perlu meningkatkan kompleksitas, jadi mengapa harus ditanyakan tentang bahasa pengembangan kami?

Preferensi pribadi saya adalah kemampuan untuk memiliki keketatan yang cukup untuk menangkap kesalahan ketik saya, tetapi dengan pelat tambahan sesedikit mungkin. Saya berbicara tentang masalah ini di http://www.perlmonks.org/?node_id=755790 .

Yang mengatakan, Anda sedang merancang bahasa Anda untuk diri sendiri. Anda harus membuatnya menjadi apa pun yang Anda inginkan.

Saya suka bahasa saya untuk melakukan apa yang saya maksud. Umumnya yang bersandar cukup keras menuju longgar. Saya juga ingin dapat menandai "ketat" pada elemen atau blok untuk dapat men-debug / menganalisis area terbatas itu.

Saya biasanya cenderung jatuh ke sisi "Apa yang akan membuatnya lebih mudah bagi saya sebagai seorang programmer". Tentu saja itu bisa berarti lebih dari satu hal. Di Javascript hampir tidak ada pengecekan tipe, yang berfungsi dengan baik sampai Anda menemukan bug aneh. Di sisi lain di Haskell ada banyak jenis pengecekan yang menempatkan lebih banyak pekerjaan di depan tetapi clobbers beberapa kelas bug.

Sejujurnya saya akan memeriksa banyak bahasa untuk melihat apa yang mereka lakukan dan mencoba untuk menemukan ceruk yang tidak ada satupun yang berhasil!

Saya tidak berpikir ada satu cara yang jelas benar untuk melakukannya, atau setidaknya jika tidak ada sesuatu yang orang telah menemukan konsensus. Jadi dengan menciptakan bahasa dengan sistem tipe yang berbeda, kami belajar.

Semoga berhasil.

Saya akan menyarankan bahwa bahasa pemrograman yang baik harus memiliki aturan yang ketat, implementasi mana yang diharapkan akan ditegakkan secara konsisten, tetapi aturan tersebut harus ditulis sedemikian rupa sehingga dapat membantu. Saya lebih lanjut menyarankan bahwa seseorang harus mempertimbangkan merancang bahasa untuk menghindari kasus-kasus di mana "jarak Hamming" antara dua program yang secara substansial berbeda hanya satu. Jelas seseorang tidak dapat mencapai hal seperti itu dengan numerik atau string literal (jika seorang programmer yang berarti 123 bukan tipe 1223 atau 13, kompiler tidak dapat mengetahui apa yang dimaksud dengan program tersebut). Di sisi lain, jika bahasa digunakan :=untuk penugasan dan ==untuk perbandingan kesetaraan, dan tidak menggunakan satu= untuk tujuan hukum apa pun, maka akan sangat mengurangi kemungkinan untuk penugasan yang tidak disengaja yang seharusnya menjadi perbandingan, dan perbandingan tidak melakukan apa-apa yang disengaja yang seharusnya menjadi penugasan.

Saya akan menyarankan bahwa sementara ada tempat-tempat yang berguna bagi penyusun untuk menyimpulkan hal-hal, kesimpulan seperti itu seringkali paling berharga dalam kasus-kasus yang paling sederhana, dan kurang berharga dalam kasus-kasus yang lebih rumit. Misalnya, memungkinkan penggantian:

  Kamus <rumitType1, rumitType2> item =
    Kamus baru <komplikasiType1, rumitType2 ()>;

dengan

  var item = Kamus baru <komplikasiType1, rumitType2 ()>;

tidak memerlukan jenis inferensi yang rumit, tetapi membuat kode jauh lebih mudah dibaca (antara lain, menggunakan sintaksis yang lebih banyak hanya dalam skenario di mana itu diperlukan, misalnya karena jenis lokasi penyimpanan tidak tepat sesuai dengan jenis ekspresi menciptakannya, akan membantu menarik perhatian ekstra ke tempat-tempat yang mungkin memerlukannya).

Satu kesulitan utama dalam mencoba inferensi tipe yang lebih canggih adalah bahwa situasi ambigu mungkin muncul; Saya akan menyarankan bahwa bahasa yang baik harus memungkinkan seorang programmer untuk memasukkan informasi ke kompiler dapat digunakan untuk menyelesaikan ambiguitas seperti itu (misalnya dengan menganggap beberapa typecast lebih disukai daripada yang lain), menentukan bahwa mereka tidak masalah (misalnya karena meskipun ada dua kemungkinan overload dapat mengeksekusi kode yang berbeda, programmer telah menunjukkan bahwa mereka harus berperilaku identik dalam kasus-kasus di mana salah satu dapat digunakan), atau menandai mereka (dan hanya mereka) yang tidak dapat ditangani dengan salah satu cara di atas.

Bagi saya, keterbacaan adalah yang paling penting.

Bagi seseorang yang berpengalaman dengan bahasa tersebut, makna sebuah fragmen kode harus jelas tanpa harus menganalisis konteksnya secara mendalam.

Bahasa harus mampu menandai kesalahan sesering mungkin. Jika setiap urutan karakter acak membuat program yang benar secara sintaksis, itu tidak membantu. Dan jika variabel secara otomatis dibuat pertama kali mereka digunakan, maka salah mengeja clientkarena cleinttidak akan memberi Anda kesalahan kompilasi.

Selain sintaks, bahasa harus memiliki semantik yang jelas, dan mungkin itu lebih sulit daripada memutuskan sintaksis yang layak ...

Contoh yang bagus:

• Di Jawa, "1"adalah string, 1int, 1.0ganda, dan 1Lpanjang. Sekali lihat dan Anda tahu apa itu.

• Di Jawa, =adalah tugas. Ini memberikan nilai untuk tipe primitif dan referensi untuk tipe referensi. Itu tidak pernah menyalin data yang kompleks atau membandingkan.

• Di Jawa, memanggil metode membutuhkan tanda kurung dan cara ini jelas dibedakan dari variabel - jadi, jika tidak ada tanda kurung, Anda tidak perlu mencari definisi metode, itu hanya membaca data.

Contoh buruk:

• Di Jawa, simbol seperti clientbisa hampir apa saja: elemen jalur paket, nama kelas atau antarmuka, nama kelas dalam, nama bidang, nama metode, variabel lokal, dan bahkan lebih. Terserah kepada pengguna untuk memperkenalkan atau mematuhi konvensi penamaan atau tidak.

• Di Jawa, titik .terlalu banyak digunakan. Itu bisa menjadi pemisah dalam nama paket, pemisah antara paket dan kelas, pemisah antara kelas luar dan dalam, konektor antara instance instance dan metode yang akan dipanggil pada instance, dan banyak lagi.

• Dalam banyak bahasa, kurung kurawal dari ifblok adalah opsional, yang mengarah ke kesalahan buruk jika seseorang menambahkan satu pernyataan lagi ke blok (tidak benar-benar ada).

• Operator infiks: kadang-kadang saya harus berhenti pada ekspresi numerik dan berpikir keras apa artinya, langkah demi langkah. Kita semua terbiasa menulis ekspresi matematika dalam notasi infix like a * b / c * d + e. Sebagian besar waktu kita ingat diutamakan multiplikasi dan pembagian daripada penambahan dan pengurangan (tetapi apakah Anda menyadari bahwa kita tidak membaginya dengan c*d, tetapi membaginya hanya dengan cdan kemudian mengalikan dengan d?). Tetapi ada begitu banyak operator infiks tambahan dengan aturan prioritas mereka sendiri dan dalam beberapa bahasa kelebihan sehingga sulit untuk dilacak. Mungkin menegakkan penggunaan tanda kurung adalah pendekatan yang lebih baik ...

Anda mungkin mempertimbangkan analogi dengan bahasa alami. Dalam email, apakah Anda seorang Tata Bahasa Nazi? Atau apakah Anda baik-baik saja dengan beberapa kesalahan tata bahasa, seperti membagi infinitif, konjungsi yang hilang, atau pengubah salah tempat. Jawabannya bermuara pada preferensi pribadi.