Apakah sintaks benar-benar penting dalam bahasa pemrograman? [Tutup]


41

Salah satu profesor saya mengatakan "sintaksnya adalah UI dari bahasa pemrograman", bahasa seperti Ruby memiliki keterbacaan yang tinggi dan terus berkembang, tetapi kami melihat banyak programmer produktif dengan C \ C ++, sehingga ketika programmer benar-benar peduli bahwa sintaksis harus bisa diterima?

Saya ingin mengetahui pendapat Anda tentang hal itu.

Penafian: Saya tidak mencoba memulai argumen. Saya pikir ini adalah topik diskusi yang bagus.

Pembaruan: Ini ternyata menjadi topik yang bagus. Saya senang Anda semua berpartisipasi di dalamnya.


16
Hmm, ini tampaknya menganggap bahwa sintaks C / C ++ buruk? Tentu saja beberapa elemen template C ++ jelek, tetapi sejauh bahasa pergi (secara historis), C / C ++ masih sangat, sangat mudah dibaca.
Macneil

2
baik saya tahu banyak programmer yang tidak setuju tentang itu, sebagian besar dari komunitas ruby, lebih mudah dibaca daripada lisp sejauh yang saya tahu :)
Saif al Harthi

9
Apakah ini kursus teoretis? Ingat: profesor sering merupakan programmer yang terburuk. Mereka tidak tahu bagaimana rasanya di luar sana di alam liar.
Pekerjaan

2
Keterbacaan ada di mata yang melihatnya :).
MAK

8
Sintaksis yang baik tidak dapat membuat bahasa yang lebih buruk menjadi lebih baik. Tetapi sintaksis yang menyedihkan dapat memperburuk bahasa yang baik;)
Dario

Jawaban:


65

Ya itu. Jika Anda ragu, gunakan APL , atau J , atau Brainfuck , atau bahkan Lisp atau Forth yang sederhana dan sederhana, dan cobalah untuk memahami program yang tidak sepenuhnya sepele di dalamnya. Kemudian bandingkan dengan eg Python.

Kemudian bandingkan Python yang sama (atau Ruby, atau bahkan C #) dengan hal-hal seperti Cobol atau VB6.

Saya tidak mencoba mengatakan bahwa sintaksis rambut itu buruk dan sintaksis seperti bahasa alami itu baik dalam semua keadaan. Tapi sintaksis obrolan memang membuat perbedaan besar. Semua dalam semua, semua yang dapat Anda tulis dalam bahasa pemrograman yang paling indah, Anda juga dapat menulis sebagai program mesin Turing - tetapi Anda biasanya tidak mau, bukan?


26
Gangguan pasti dimengerti.
cbrandolino

65
+1 untuk menyertakan Lisp dalam daftar bahasa yang tidak dapat dibaca.
asmeurer

65
-1 untuk memasukkan Lisp dalam daftar bahasa yang tidak dapat dibaca.
Paul Nathan

27
Pemrograman secara umum tidak dapat dibaca oleh orang yang belum tahu. Seperti notasi musik dan denah arsitektur. (= XY) sama mudahnya dengan X == Y, untuk seseorang yang tahu cara membaca.
Paul Nathan

6
Saya suka APL, dan kecuali kode itu sengaja ditulis untuk mengaburkan (sangat mudah dilakukan), itu cukup mudah dibaca. Kekuatan sintaksnya adalah Anda dapat memprogram algoritma dalam 2 atau 3 baris kode APL yang akan membutuhkan puluhan atau ratusan baris C, Fortran, atau COBOL. Keringkasan dan kekuatan bahasa seperti APL penting untuk diskusi ini karena mencoba membaca ratusan baris kode bahasa lain sama frustasinya dengan menguraikan elemen-elemen APL yang tidak jelas.
oosterwal

11

Dalam praktiknya saya pikir itu penting. Keterbacaan sudah dibahas di atas. Masalah lain mungkin berapa banyak penekanan tombol yang diperlukan untuk mengekspresikan ide / algotithm? Namun masalah lain adalah betapa mudahnya untuk kesalahan ketik yang sederhana menjadi sulit bagi mata manusia untuk ditangkap, dan berapa banyak kerusakan yang dapat ditimbulkannya.

Saya juga merasa berguna dalam beberapa konteks untuk menganalisis, dan / atau untuk menghasilkan fragmen kode melalui program komputer lain. Kesulitan menguraikan bahasa, dan / atau menghasilkan kode yang benar maka secara langsung berdampak pada berapa banyak upaya yang diperlukan untuk membuat / memelihara alat tersebut.


Pengamatan bagus tentang kesalahan ketik yang mudah dibedakan.

7
Namun secara teori tidak ada perbedaan antara teori dan praktik.
Pekerjaan

10

Saya percaya profesor Anda mengacu pada gula sintaksis .

Gula sintaksis adalah istilah ilmu komputer yang mengacu pada sintaksis dalam bahasa pemrograman yang dirancang untuk membuat segala sesuatu lebih mudah dibaca atau diungkapkan, sementara cara-cara alternatif untuk mengekspresikannya ada .

Jadi apa yang disiratkan profesor Anda, adalah bahwa kode / sintaksis apa pun yang ditulis dalam satu bahasa pemrograman, dapat diekspresikan dalam bahasa lain yang sama - atau bahkan bahasa yang sama.

Robert Martin, menarik dari teorema Pemrograman Terstruktur , mengabstraksikan apa yang dilakukan oleh para programmer secara mendasar dengan bahasa pemrograman pada keynote utamanya di RailsConf 2010: Robert Martin (video youTube, lihat setelah tanda 14 menit, meskipun saya merekomendasikan semuanya):

  • Urutan (tugas)
  • Seleksi (jika pernyataan)
  • Iterasi (lakukan loop)

Itulah yang dilakukan oleh semua programmer, dari satu bahasa pemrograman ke yang lain, hanya dalam sintaks yang berbeda atau antarmuka pengguna (UI). Ini yang saya duga adalah maksud profesor Anda, jika dia berbicara secara abstrak tentang bahasa pemrograman.

Jadi intinya , sintaksis tidak masalah . Tetapi jika Anda ingin lebih spesifik, maka jelas bahasa dan sintaksis tertentu lebih cocok untuk tugas-tugas tertentu daripada yang lain, di mana Anda bisa berpendapat bahwa sintaksis penting.


Apakah Anda menyebut C hanya gula sintaksis untuk assembler?
Goran Jovic

1
Saya akan. Tapi saya mengklaim masalah sintaksis. ;)
Lennart Regebro

2
"... Robert Martin mengabstraksikan apa yang dilakukan oleh programmer secara mendasar ..." Robert Martin? Robert Martin ?? Anda mungkin benar-benar ingin mempertimbangkan makalah ini: C. Böhm, G. Jacopini, "Diagram alir, Mesin Turing dan Bahasa dengan hanya Dua Aturan Formasi", Comm. dari ACM, 9 (5): 366-371,1966. yang biasanya dikreditkan sebagai sumber 'Teorema Program Terstruktur'. en.wikipedia.org/wiki/Structured_program_theorem
leed25d

@ lee25d Saya tidak bermaksud memuji Paman Bob sebagai pencetus abstraksi, tetapi sebagai sumber di mana saya mendengarnya baru-baru ini (dan ditautkan dengan). Tetapi terima kasih atas tautannya, saya akan memperbarui jawaban saya untuk mencerminkan tautan Anda.
Spong

Sepotong Wikipedia yang terhubung di atas tidak cukup memahami sejarah "teorema Pemrograman Terstruktur". Gagasan itu mendahului Bohm & Jacopini. Kontribusi Bohm & Jacopini menunjukkan bahwa itu adalah teorema, bukan hanya dugaan, yaitu, mereka memberikan bukti formal yang ketat.
John R. Strohm

7

Iya dan tidak.

Ada beberapa aspek berbeda untuk sintaksis.

  • keterbacaan
  • ekspresivitas
  • sifat parsabilitas

Keterbacaan telah disebutkan.

Ekspresivitas adalah kasus yang menarik. Saya akan menggunakan fungsi-lewat sebagai contoh, karena itu semacam titik belok rasa sakit semantik / sintaksis.

Mari kita ambil C ++ sebagai contoh. Saya dapat membuat fungsi urutan pertama setelah mode ini:

class funcClass
{
  int operator()(int);
}
funcClass fun;

void run_func(funcClass fun)
{
   fun();
}

Ungkapan khusus ini biasanya digunakan dalam Elemen - elemen Pemrograman Stepanov .

Di sisi lain, saya bisa meniru itu di Common Lisp dengan sesuatu seperti ini :

(defun myfunc() )

(defun run_func(fun)
  (fun))

Atau, di Perl -

   sub myfunc
   {
   }

   sub run_func
   {
      my $func = shift;
      $func->();          #syntax may be a little off.
   }

Atau, dengan Python -

def myfunc():
    pass

def run_func(f):
    f()

Ini semua memiliki - pada dasarnya - konten semantik yang sama, meskipun contoh C ++ membawa beberapa jenis metadata. Bahasa mana yang mengekspresikan ide untuk melewati fungsi tingkat tinggi yang terbaik? Lisp umum nyaris tidak membuat variasi sintaksis. C ++ membutuhkan kelas yang akan dibuat hanya untuk 'membawa' fungsi. Perl cukup mudah membuat beberapa tingkat diferensiasi. Begitu juga dengan Python.

Pendekatan mana yang paling sesuai dengan domain masalah? Pendekatan mana yang terbaik yang bisa mengekspresikan pikiran di kepala Anda dengan paling sedikit 'ketidakcocokan impedansi'?

Parsability adalah - dalam pikiran saya - masalah besar. Secara khusus, saya merujuk pada kemampuan IDE untuk mengurai dan memotong bahasa tanpa membuat kesalahan. Memformat ulang bermanfaat. Bahasa yang dibatasi tanda cenderung mengurai dengan baik - ruby ​​/ c / pascal, dll.

Pertimbangkan juga - sistem utama dari segala jenis telah dibuat dengan setiap bahasa yang serius untuk menyelesaikan masalah dunia nyata. Meskipun sintaks adalah penghalang untuk mengekspresikan beberapa hal, itu adalah penghalang yang bisa diatasi. Turing kesetaraan dan semua itu.


5

Sintaks jelas penting, meskipun Anda cenderung lebih memperhatikannya ketika itu tidak intuitif dan mendorong bug. Misalnya, lelucon "bug terakhir dunia" yang terkenal:

if (AlertCode = RED)
   {LaunchNukes();}

2
+1: Menarik, saya belum pernah melihat (atau mengakui) lelucon "bug terakhir dunia" yang terkenal ini. Tetapi saya dapat melihat bagaimana, tergantung pada sintaks suatu bahasa (atau bahkan semantik), hasil dari kode semu itu bisa berupa apa saja. Mengingat sudut semantik juga, ini benar-benar dapat dihubungkan dengan kasus klasik miskomunikasi budaya.
Stephen Swensen

Inilah sebabnya mengapa Anda harus menggunakan kondisional Yoda, yaitu if(RED = AlertCode)tidak boleh dikompilasi karena RED konstan (atau seharusnya!)
Malfist

4
@Malfist: Dan dengan demikian kita melihat bahwa sintaks yang buruk mengarah pada sintaks yang lebih buruk untuk mengkompensasi. Kondisional Yoda jelek dan sulit dibaca karena itu bukan cara orang berpikir tentang konsep yang terkait. Maksud saya lebih seperti "ini (salah satu dari banyak alasan) mengapa Anda harus menghindari keluarga C bila memungkinkan."
Mason Wheeler

1
Untungnya, kode itu memiliki dua bug. Tentu, itu akan selalu memasuki kondisi, tetapi di sana, itu hanya mendapatkan referensi ke LaunchNukesprosedur, dan tidak pernah memohonnya. Krisis dihindari!
murah hati

3
Tergantung apa RED. Jika 0, maka LaunchNukes()tidak akan pernah dipanggil.
dan04

5

Sintaks memang penting, dan saya bisa memberi Anda dua contoh pendukung: Dylan, yang merupakan Lisp dengan sintaksis yang lebih konvensional, dan Liskell, yang Haskell dengan sintaks mirip Lisp. Dalam setiap kasus, varian bahasa diusulkan yang memiliki semantik yang sama persis, tetapi sintaksisnya sangat berbeda.

Dalam kasus Dylan, dianggap bahwa menjatuhkan ekspresi-s demi sesuatu yang lebih konvensional akan membantu menarik lebih banyak programmer. Ternyata sintaksis bukan satu-satunya hal yang mencegah programmer menggunakan Lisp.

Dalam kasus Liskell, diperkirakan bahwa menggunakan ekspresi-s akan memungkinkan penggunaan makro yang lebih mudah. Ternyata makro benar-benar tidak diperlukan di Haskell, sehingga percobaan tidak berhasil.

Begini masalahnya: jika sintaks tidak masalah bagi siapa pun, percobaan tidak akan dicoba.


1
Dylan terlalu sedikit, terlalu terlambat untuk bahasa lain. Apa yang dimilikinya tidak dapat menebusnya. Kita tidak bisa lagi berasumsi itu adalah kegagalan sintaksis daripada kegagalan dalam penamaan.
Macneil

@ Macneil: Anda benar tentang hal yang terlalu kecil, terlalu terlambat. Menjatuhkan sintaks Lisp hanyalah paku terakhir di peti mati. Saya tidak berpikir itu adalah alasan utama kegagalan Dylan, tetapi saya tidak yakin bagaimana mengatakan kembali jawaban yang paling tepat untuk mencerminkan hal itu.
Larry Coleman

Menarik, saya tidak tahu mereka memiliki sintaks Lisp di versi yang lebih awal ... Apakah saat itu bernama Ralph? Pad Pesan Newton awalnya akan memiliki Dylan pada intinya. 15 tahun kemudian, kami memiliki iOS dengan Objective-C pada intinya, bahasa yang lebih rendah dari keduanya, IMHO.
Macneil

Saya tidak ingat detail pastinya tentang kapan Dylan kehilangan ekspresi-s. Saya telah mengintai comp.lang.lisp untuk waktu yang lama, dan ingat topik yang muncul di salah satu flamewar periodik mereka di atas tanda kurung.
Larry Coleman

Dylan mendahului Java, dan saya kira tidak ada banyak C ++ saat itu.
Tom Hawtin - tackline

3

Jawabannya mungkin dalam memisahkan apa yang "penting" menjadi faktor komputer dan faktor manusia . Ada banyak faktor manusia dalam sintaksis:

  • Keterbacaan
  • Kekompakan
  • Maintabilitas
  • Pedagogi
  • Pencegahan kesalahan
  • Kesesuaian untuk tujuan - apakah itu bahasa REPL, bahasa skrip, atau bahasa sistem besar?

Sejauh menyangkut komputer, satu-satunya masalah sintaksis adalah apakah ada ambiguitas yang perlu diselesaikan, dan berapa banyak waktu yang diperlukan untuk tokenize / parse kode pada saat kompilasi / interpretasikan - dan itu hanya dalam kasus ini dari yang terakhir di mana overhead parsing adalah masalah yang signifikan.

Mungkin itulah sebabnya Anda akan selalu mendapat jawaban "ya dan tidak" untuk pertanyaan ini - karena ada dua aspek di dalamnya.


1

Tanpa sintaksis, kita tidak akan memiliki "templat" yang sama untuk berkomunikasi, pada tingkat manusia, maksud dari blok kode. Sintaks menyediakan kerangka kerja umum dari mana penyusun dapat distandarisasi; metode dapat dibagikan; pemeliharaan dapat disederhanakan.


Mengapa jawaban saya tidak dipilih?
IAbstract

1

Saya pikir apa yang benar-benar penting adalah akses API , dan ketersediaan fungsi tingkat rendah (seperti kontrol memori dan penguncian) bila diperlukan. Sebagian besar bahasa lain dilengkapi dengan fitur-fitur ini. Masalahnya adalah, ketika Anda membutuhkan fungsionalitas tambahan, Anda sering harus menggunakan bahasa seperti C untuk mengimplementasikannya. Dan itu adalah antarmuka C rumit dengan bahasa yang Anda gunakan.

Untuk semuanya kecuali pengembangan web (dan matematika) saya telah menemukan bahwa C / C ++ masih merupakan bahasa sistem operasi dan aplikasi. Inilah yang didukung sebagian besar waktu untuk pengembangan aplikasi lintas-platform multi-threaded, preforming, dan benar. Dan sintaks C tidak apa-apa. Sangat sederhana dan relatif bertele-tele. Sintaks yang luar biasa tidak terlalu penting. Ketersediaan daya dan API tidak. Kita semua perlu berinteraksi dengan kode orang lain (yang sebagian besar waktu ditulis dalam C atau turunannya).


Saya tidak ragu dengan C, tetapi kerumunan ML / Haskell mungkin akan mengatakan sesuatu tentang threading.
Rei Miyasaka

+1 untuk "Akses API": Saya pikir ini bahkan bisa lebih penting daripada fitur bahasa.
Giorgio

1

Sintaks jelas penting. Ini sangat berharga jika sintaks bahasanya cukup fleksibel untuk memungkinkan Anda membuat Bahasa Khusus Domain yang mudah dibaca untuk aplikasi Anda. Jika Anda meragukan hal ini, bayangkan saja melakukan masalah aljabar dalam bahasa Latin prosa, seperti yang dilakukan sebelum abad ke-18, atau bayangkan melakukan kalkulus tanpa notasi Leibniz yang sekarang dikenal. Tentu, teks kalkulus tidak dapat dibaca oleh seorang pemula, tetapi dengan latihan kita dapat menggunakan kalkulus dan notasi Leibniz untuk dengan cepat menyelesaikan kelas masalah yang membutuhkan halaman matematika dengan metode klasik. Pemrograman hanyalah sedikit matematika. Notasi yang mudah digunakan, dekat dengan domain masalah, dapat membuat perbedaan besar dalam produktivitas.


DSL tidak semuanya tentang gula sintaksis. Semantik adalah bagian yang jauh lebih berharga. Tidak masalah untuk mendesain eDSL yang tidak akan menambahkan apa pun ke sintaks yang ada.
SK-logic

@ SK: tentu, tetapi semantik berada di bawah kendali penuh programmer. Sintaks dibatasi oleh bahasa dasar. Kita dapat membangun DSL yang nyaman dalam Groovy dan bahasa lain, tetapi tidak begitu banyak di Jawa.
kevin cline

1

Berikut adalah program yang menghitung fakultas 6:

S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))

Sintaksnya minimal:

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I' 

Tampaknya ada kepercayaan umum bahwa sintaks yang membuat bahasa sulit. Seperti yang sering dipercaya oleh orang banyak, justru kebalikannya yang benar.

Perhatikan bahwa sintaks LISP hanya dapat dibaca (jika ada) karena memiliki lebih banyak sintaks daripada yang di atas. Jadi, jika penggemar LISP memberi tahu Anda bahwa "sintaksis tidak penting", minta mereka untuk konsekuen dan coba kalkulus SKI. Mereka harus mengakui bahwa sintaks sedikit tidak terlalu buruk.


Saya tidak bisa mengerti suara turun. Ini jawaban yang sangat mendalam. +1
scravy

0

Saya tidak berpikir itu penting di luar preferensi pribadi. Semua hal (kinerja, kemampuan, dll) sama, maka saya bisa melihat mengapa orang lebih menekankan sintaksis bahasa tetapi memilih untuk melewati kinerja bahasa seperti c / c ++ atau bahasa lain yang lebih cocok untuk pekerjaan itu hanya karena sintaks akan tampak seperti ide yang buruk di sekitar.


6
Bagaimana dengan "waktu ke pasar", "biaya untuk mendapat manfaat", dll.?
Pekerjaan

0

Ya, sintaks penting, meskipun sebenarnya hanya untuk keterbacaan. Membandingkan:

for i in range(10):
   print(i)

(Ya itu Python) dengan

FOR(i<-RNG-<10){PRN<-i}

(Ya, itu bahasa yang baru saya buat) Keduanya akan melakukan hal yang persis sama, dengan cara yang sama, tetapi sintaksnya berbeda, dan Python lebih mudah dibaca. Jadi ya, sintaks jelas penting. Bahkan "gula sintaksis" penting.

 @property
 def year(self):
     return self._date.year

Lebih mudah dibaca daripada

 def year(self):
     return self._date.year
 year = property(year)

0

Ya tentu.

Jika Anda ingin menyalakan api besar, tanyakan pada orang-orang, di mana mereka meletakkan gelang pembuka dalam bahasa C-like. maksudku

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

atau bahkan VS

void foo() 
{ // blah
}

Dan ini hanya bahasa yang sama! Juga, tanyai mereka tentang spasi, tempat mereka meletakkannya (nama fungsi dan gelang, operator, dll.).

1000 jawaban dijamin!


saya tidak ingin memulai nyala & sejauh ini saya mendapat tanggapan yang baik & saya berterima kasih kepada mereka semua karena telah berpartisipasi & menambah pengetahuan saya & saya yakin orang lain menganggap ini membantu
Saif al Harthi

0

Sintaks memang penting. Namun di hari ini dan usia saya akan mengatakan itu penting hampir seluruhnya karena keterbacaan dan tidak benar-benar dalam hal jumlah penekanan tombol yang dibutuhkan. Mengapa?

  • Kecuali jika Anda benar-benar menulis sesuatu yang sederhana, jika jumlah tombol yang Anda tekan adalah faktor pembatas dalam menulis sebuah program, maka Anda benar-benar tidak bisa mengetik atau berpikir banyak, terlalu cepat.
  • Semua IDE yang layak akhir-akhir ini memiliki banyak pintasan yang berarti Anda tidak perlu mengetik semua karakter yang paling sering Anda gunakan.

Yang mengatakan, jika terlalu bertele-tele maka itu bisa sampai pada titik di mana itu mempengaruhi keterbacaan. Saya lebih suka melihat sesuatu seperti:

foreach (String dalam stringList)

Untuk:

untuk setiap String yang ada dalam daftar sebagaimana dirujuk oleh variabel stringlist

... kapan saja!


0

Sintaks penting bagi mereka yang mempelajarinya, semakin rendah penghalang untuk masuk bahasa yang lebih populer mungkin awalnya. Tetapi jika bahasa itu sulit atau tidak mungkin untuk mengekspresikan diri Anda dengan kaya dan ringkas itu akan mulai layu dalam popularitas.

Sangat singkat dan buram (Perl) sama buruknya dengan terlalu banyak bertele-tele dan bertele-tele (AppleScript).

Perlu ada keseimbangan, hambatan masuk yang lebih rendah, produktivitas tinggi, dan perawatan yang mudah.


-2

Hal lain yang perlu dipertimbangkan adalah bahwa bahasa pemrograman dengan sintaksis yang lebih baik lebih mudah diurai, sehingga membuat kompiler lebih mudah untuk menulis, lebih cepat, dan lebih tidak rentan terhadap bug.


3
Umm ... 10.000 SLOC parse.ydi dalam Ruby tidak setuju. Ada alasan mengapa setiap satu dari 7 implementasi Ruby siap-pakai atau segera produksi menggunakan parser yang sama , dan setiap implementasi Ruby tunggal yang pernah mencoba mengembangkan parser mereka sendiri telah gagal.
Jörg W Mittag

Dan kemudian ada bahasa ADA yang terkenal. Seiring dengan spesifikasi bahasa ada 100 program yang harus berjalan dengan benar untuk mengesahkan kompiler. Ada beberapa hal yang sangat halus tentang sintaksis. Untuk membuat cerita panjang pendek, SETIAP kompiler ADA awal dibangun gagal beberapa program ini. Dan itu bukan masalah sederhana memperbaiki bug, tetapi mereka harus memulai dari awal lagi. Meskipun memiliki dukungan pemerintah yang besar (semua kontrak DOD diamanatkan ADA), ia meninggal secara menyedihkan.
Omega Centauri

-2

Sederhananya: sintaksis seperti itu tidak masalah. Semantik yang bisa Anda ungkapkan lewat itu penting.


5
Sebagai latihan, tulis parser kompleks di C, dan kemudian driver perangkat di Haskell. Apakah sintaks membantu Anda? Kemudian lakukan sebaliknya, dengan ketat menjaga semantik kedua program. </irony>
9000

1
@ 9000: Saya telah melihat beberapa driver perangkat di Haskell. Saya tidak bisa melihat ada yang salah dengan mereka. Peduli untuk menguraikan?
Jörg W Mittag

2
@ 9000, mengingat betapa sulitnya untuk mendapatkan driver perangkat tepat di C saya tidak yakin Anda telah memilih contoh yang baik.

1
@ 9000: Itulah maksud saya. Sifat konkret dari konstruksi sintaksis tidak masalah, itu adalah apa yang Anda ungkapkan dengannya. Bahasa pemrograman dengan sintaksis Haskell yang tepat , tetapi yang menggunakan strategi evaluasi yang berbeda akan membuat banyak Haskell berkinerja sangat buruk atau bahkan terjebak dalam loop tak terbatas. Ketika datang ke konstruksi sintaksis (atau lebih luas: fitur bahasa), itu bukan sintaks konkret mereka yang penting, tetapi semantik mereka, yaitu apa yang dapat Anda ungkapkan dengan mereka.
back2dos

@ 9000, tidak akan menjadi masalah untuk menulis parser di Haskell dengan sintaks seperti C (atau driver, menggunakan C dengan sintaks mirip Haskell).
SK-logic
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.