Bisakah Anda menulis spesifikasi yang tidak ambigu dalam bahasa alami seperti bahasa Inggris?

Tampak bagi saya bahwa Anda tidak mungkin dapat menulis spesifikasi perangkat lunak dalam bahasa Inggris yang sepenuhnya bebas dari ambiguitas, hanya karena sifat informal bahasa alami - dan oleh karena itu spesifikasi yang benar-benar jelas harus mencakup kode yang ditulis dalam bahasa yang ditentukan secara formal.

Apakah ini hasil yang diketahui atau saya kehilangan sesuatu?

Bukankah ini yang selalu dilakukan pengacara untuk menghindari ambiguitas?

Hasilnya adalah mereka menulis dengan cara yang paling tidak wajar, mencoba membaca makalah mereka lebih sulit dari sebelumnya, dan meskipun demikian selalu ada ketidakkonsistenan dan ambiguitas.

Anda benar, Anda tidak dapat menulis spesifikasi perangkat lunak yang sepenuhnya bebas dari ambiguitas, tetapi Anda tidak akan bisa melakukannya dengan menerapkan bahasa yang ditentukan secara formal.

Ini juga mengapa kami mendokumentasikan kode kami, karena kadang-kadang sulit untuk membaca untuk pikiran kita.

Tidak ada gunanya mendokumentasikan kode dengan kode lain.

Mustahil? Mari kita bertanya apakah itu diinginkan terlebih dahulu. Jika kami setuju bahwa itu tidak mungkin, dan masih ada banyak perangkat lunak yang berguna di luar sana, maka tujuan dari spesifikasi yang tidak ambigu tampaknya bersifat akademis.

Saya akan mengatakan bahwa tidak mungkin untuk membuktikan bahwa semuanya sempurna dan tidak ambigu, baik untuk spesifikasi dan perangkat lunak.

Saya pikir itu tergantung pada ukuran masalahnya. Jika masalahnya cukup kecil, sifatnya matematis, dan mungkin beberapa kriteria lain yang saya lewatkan, saya katakan mungkin untuk menulis spesifikasi yang bisa diterapkan.

Semakin besar masalah, semakin luas audiensnya, semakin sulit untuk dilakukan.

Tapi avionik dan masalah kompleks lainnya menunjukkan bahwa mungkin untuk menulis spesifikasi "cukup baik" dalam bahasa Inggris untuk memecahkan masalah besar.

baik .. spesifikasi masalah yang sama sekali tidak ambigu adalah kode aktualnya sendiri :)

Ini adalah masalah yang diketahui dan untuk sistem kritis misi khusus wajib untuk menulis spesifikasi yang tidak ambigu dalam bahasa formal (pemrograman) dan kemudian mengubahnya menjadi kode yang dapat dibuktikan melakukan apa yang dikatakan spesifikasi. Ini adalah bidang yang sangat sempit, 99,999% pengembang tidak pernah harus melakukan tugas seperti ini, tapi saya pernah berbicara dengan seorang pria yang melakukan ini untuk sistem pengendali lalu lintas / kereta api.

Saya seorang pengikut W3C, dan saya cenderung menulis artikel berdasarkan spesifikasinya. Pengalaman saya memberi tahu saya bahwa membaca spesifikasi apa pun tanpa kode contoh tertulis, hanyalah sakit kepala.

Saya sepenuhnya setuju dan saya pikir alasan utamanya adalah, pengembang cenderung membaca dan memahami kode dengan lebih baik. Bayangkan saja Anda mendapatkan kertas matematika tanpa formula.

To calculate the result, simply add variable x to variable y, 
and then divide that by the b factor.

atau:

result = (x + y) / b

Yang mana yang lebih pendek? Mana yang lebih mudah dibaca? Yang mana yang lebih memahaminya?

Hal yang sama berlaku untuk spesifikasi. Sering kali, ketika Anda sampai ke bagian teknis, menulis satu baris kode dapat memperjelas paragraf penjelasan yang panjang.

Asumsikan ada bahasa formal yang memungkinkan untuk menulis spesifikasi yang tidak ambigu. Kemudian saya mengusulkan bahwa harus ada pemetaan bijektif ke subset dari bahasa Inggris. Oleh karena itu, mungkin untuk menulis spesifikasi yang tidak ambigu jika Anda tetap pada subset ini.

Tetapi bahasa formal apa pun yang cukup ekspresif untuk melakukan sesuatu yang menarik tidak akan bebas dari ketidakkonsistenan (ketidaklengkapan Gödel).

Spesifikasi tidak jelas dan tidak tepat karena orang tidak jelas dan tidak tepat. Temukan orang yang tepat dan mungkin Anda bisa mendapatkan spesifikasi yang sempurna.

Bahasa Inggris, Swahili, Sanskerta atau Babel tidak ada bedanya.

Ambiguitas sebenarnya merupakan kekuatan dalam konteks ini.

Untuk menjelaskan mengapa, mari kita asumsikan sejenak bahwa adalah mungkin untuk menggunakan bahasa Inggris dengan cara yang benar-benar jelas, sehingga setiap masalah yang bisa diselesaikan pemrograman dapat dinyatakan lengkap dan jelas. Jika kita menggunakan varian bahasa Inggris ini, dan deskripsi kita memang menggambarkan program yang akan ditulis secara lengkap dan tidak ambigu, maka secara logis berikut ini adalah mungkin untuk melakukan terjemahan otomatis ke dalam bahasa pemrograman target - dengan kata lain, varian dari Bahasa Inggris yang kami pahami sebenarnya adalah bahasa pemrograman itu sendiri.

Orang-orang yang membaca dokumen desain (terutama desain fungsional) sebenarnya tidak menginginkan tingkat detail seperti ini - membaca sumber program, baik dalam bahasa C ++, Java, atau Bahasa Inggris yang Tidak Rancu, jauh di atas rata-rata kepala non-programmer. Di sinilah bahasa alami masuk: mereka memungkinkan penulis spesifikasi meluncur dengan cara baik pada skala detail, memindahkan detail implementasi yang tidak relevan ke dalam subteks, atau membiarkannya tidak ditentukan sepenuhnya. Bahasa alami penuh dengan perangkat untuk menyampaikan makna secara relatif jelas meskipun Anda tidak memberikan definisi yang tepat (yang merupakan bagian dari apa yang membuat terjemahan otomatis menjadi sangat sulit).

Jadi tujuannya biasanya bukan spesifikasi yang lengkap, benar dan tidak ambigu; tujuannya adalah untuk menulis spec yang menggambarkan dengan jelas, untuk manusia, apa yang akan Anda bangun.

Kapan pun Anda membutuhkan yang benar dan tidak ambigu, dan segala sesuatunya menjadi teknis, pseudocode seringkali lebih berharga daripada bahasa alami atau bahasa formal yang kaku - ia masih dapat meninggalkan detail yang tidak relevan (dengan memanggil fungsi / proses yang tidak ditentukan), tetapi strukturnya tidak ambigu. .

Anda tidak melewatkan apa pun, kecuali dokumentasi yang ditulis untuk dibaca manusia. Beberapa ambiguitas diharapkan, dan bahkan diterima, karena teks singkat sulit dibaca (= tidak untuk manusia).

Menentukan dokumentasi untuk bahasa formal dalam bahasa formal lain akan menjadi semacam masalah ayam-dan-telur.

Jika Anda benar-benar membutuhkan spesifikasi formal, maka ada cara formal untuk memeriksa model . Ini adalah bidang penelitian yang aktif dan sangat menarik, tetapi "pengguna" akhir di sini adalah mesin, bukan manusia.

(Beberapa poin saya telah disinggung oleh jawaban lain, tetapi saya merasa bahwa saya memberikan perspektif yang cukup berbeda untuk membuat ini bernilai jawaban daripada komentar.)

Sebelum kita membahas masalah apakah suatu spesifikasi dapat benar-benar dan sama sekali tidak ambigu, kita harus menjawab pertanyaan apakah itu harus jelas, setidaknya pada tingkat yang Anda tanyakan.

Biarkan saya mendekati ini dari sudut pandang manajer program yang mengerjakan proyek berukuran kecil hingga menengah, atau fitur sebagai bagian dari proyek yang lebih besar. Biasanya ada dua jenis spesifikasi yang akan ditulis untuk proyek semacam itu: spesifikasi Fungsional (atau PM) dan spesifikasi Desain (atau Dev):

• Spesifikasi Fungsional bertugas menjelaskan apa yang harus dilakukan oleh proyeksi atau fitur, seringkali dari sudut pandang pelanggan. Seharusnya tidak, secara umum, menggambarkan bagaimana ini harus dilakukan. Bergantung pada jenis proyek, pelanggan mungkin peduli seperti apa API yang menghadap eksternal, tetapi apakah pelanggan peduli apakah kelas A mewarisi dari kelas B atau mengimplementasikan antarmuka C? Dia seharusnya tidak. Dan spesifikasi fungsional juga tidak harus. Ini sudah memperkenalkan satu tingkat ambiguitas: desain teknis.
• Spesifikasi Desain memiliki tugas untuk menggambarkan bagaimana persyaratan fungsional harus dipenuhi, dari perspektif arsitek atau perancang teknis fitur atau proyek. Hal ini dimaksudkan untuk menyelesaikan ambiguitas desain teknis tingkat tinggi. Ini akan berisi perincian yang tidak Anda inginkan dalam spesifikasi fungsional, seperti arsitektur solusi, termasuk struktur kelas, pewarisan, bahkan mungkin fungsi dan metode individual, tergantung pada ruang lingkup dan skala proyek. Apakah arsitek peduli apa yang Anda sebut variabel sementara Anda atau apakah Anda menggunakan daftar atau array untuk tipe data internal? Dengan asumsi dia mempercayai pengembangnya, dia seharusnya tidak, dan spesifikasi desain juga tidak. Ini memperkenalkan ambiguitas tingkat kedua: implementasi.

Secara umum, rincian tingkat implementasi ini tidak ditangkap dalam dokumen formal, melainkan didokumentasikan, pada dasarnya , dalam kode itu sendiri, termasuk komentar. Tingkat ambiguitas ini memungkinkan pengembang yang baik untuk menggunakan keahliannya sendiri dan membuat keputusan teknis berorientasi detail yang merupakan ciri khas dari pengembang individu yang baik. Karena itu, saya tidak akan ragu untuk mengatakan bahwa ambiguitas dalam spesifikasi, pada kenyataannya, adalah hal yang baik: memungkinkan pengembang untuk melakukan pekerjaan mereka, dan mengangkat mereka di atas sekadar "kode monyet".

Namun, ini tidak berarti bahwa harus ada ambiguitas di seluruh dokumen. Pada level tinggi, seharusnya tidak ada ambiguitas tentang antarmuka dengan pelanggan. Jika fitur memiliki API yang menghadap publik, itu harus ditentukan secara ketat. Jika sistem mengharuskan tanggal untuk dilewati untuk melakukan tugasnya, haruskah tanggal ini berada di zona waktu setempat atau UTC? Format apa yang dibutuhkan? Apakah perlu akurat hingga milidetik, atau apakah menit itu baik-baik saja?

Kembali ke pertanyaan apakah bahasa alami dapat digunakan untuk membuat spesifikasi yang tidak ambigu, memang benar bahwa tidak terlalu bagus dalam menangkap tingkat kejelasan ini. Saya telah melihatnya dilakukan dalam keadaan terbatas tertentu, tetapi itu kemungkinan pengecualian unik yang tidak dapat kita terapkan secara universal. Paling sering, ambiguitas diselesaikan dengan bantuan jargon teknis, diagram, atau bahkan kodesemu. Setelah Anda mulai meminta bantuan alat-alat tersebut, bahasa alami tidak lagi menjadi deskriptor tunggal. Karena alat-alat ini dapat membuat spesifikasi yang sepenuhnya ambigu secara fungsional jauh lebih jelas, saya berani mengatakan bahwa upaya semacam itu seharusnya tidak dicoba.

Karena itu, karena bahasa alami pada umumnya dilengkapi dengan alat-alat ini untuk membuatnya berfungsi secara ambigu, itu adalah pendapat profesional saya bahwa tidak, bahasa alami saja tidak cukup untuk membuat spesifikasi yang tidak ambigu dalam semua kasus.

Seseorang dapat membuat bahasa alami relatif tidak ambigu, tetapi hanya dengan kesulitan besar.

Profesi hukum sangat membutuhkan bahasa untuk menjadi tidak ambigu mungkin. Sementara banyak tentang bagaimana hukum diterapkan mungkin terbuka untuk interpretasi, apa artinya kata-kata tidak boleh.

Kebutuhan ini mengarah pada penemuan legalese. Seberapa jauh Anda mau pergi?

Ada sejumlah spesifikasi oleh kelompok terbuka, ISO, IETF dan ITU yang cukup jelas untuk perusahaan yang sangat kompetitif untuk beroperasi dengan cukup sukses. Ada sejumlah spesifikasi yang menjadi dasar kontrak atau hukum di mana jutaan dolar dipertaruhkan.

Jadi spesifikasinya mungkin tidak "sempurna". Namun itu karena manusia tidak sempurna. Misalnya, tidak ambigu bahwa HTTP harus menggunakan tajuk "Perujuk" - ejaan yang benar sebenarnya adalah "Perujuk".

Bahasa Inggris mampu menjadi tidak ambigu, tetapi manusia mampu membuat kesalahan - termasuk ambiguitas.

Selain itu mungkin berguna untuk secara ambigu sengaja untuk detail yang belum selesai atau mungkin perlu diperbarui di masa depan. Misalnya spesifikasi dapat menentukan "hash" daripada secara spesifik menentukan md5, sha1, crc32 dll.

Saya percaya jawaban yang benar adalah negatif. Penting untuk membedakan pertanyaan-pertanyaan berikut:

1. Apakah mungkin untuk menulis spesifikasi perangkat lunak dalam bahasa alami yang tidak mengandung ambiguitas?
2. Apakah mungkin untuk menulis perangkat lunak dalam bahasa alami yang tidak mengandung ambiguitas?

Perbedaan antara pertanyaan pertama dan kedua menyangkut tingkat perincian yang terlibat, jumlah penafsiran yang diperlukan, dan aturan yang dikenakan pada konstruksi kalimat dalam bahasa alami untuk keperluan penulisan perangkat lunak atau spesifikasi perangkat lunak.

Jawaban untuk pertanyaan kedua adalah afirmatif. Mengingat subset terbatas dari bahasa alami dengan aturan yang disepakati untuk konstruksi kalimat dan makna, kode dapat ditulis dalam kalimat bahasa tata bahasa Inggris. Sebagai contoh, bahasa berikut jelas memungkinkan pernyataan tugas penugasan:

Variables: x,y,z,...
Constants: 1,2,3,...
Rules: (1) if x is a variable and n a constant, then
           "The variable x contains the number n" is a sentence.
       (2) if x is a variable and n a constant, then
           "Assign the number n to the variable x" is a sentence.

Artinya, kita dapat secara sistematis menerjemahkan kode yang ditulis dalam bahasa pemrograman formal ke bahasa alami dengan menjelaskan setiap prosedur. Di sisi lain, spesifikasi perangkat lunak seringkali membutuhkan interpretasi. Dengan demikian, apakah spesifikasi perangkat lunak dapat diberikan secara jelas tergantung pada tingkat detail yang terlibat dalam spesifikasi. Namun, mengingat domain yang dipilih di mana rentang spesifikasi, dengan operasi tertentu pada domain ini dipilih, proses penerjemahan serupa dapat dilakukan. Contohnya:

Over the domain D supporting operations f,g,h over elements a,b,c in relations
P,R,Q with properties φ,ψ,θ, design a program that does X,Y,Z.

di mana laporan X, Y, Zhanya berisi item-item yang disebutkan dalam kata pengantar spesifikasi dan ditulis dalam sesuai formal dan disepakati subset dari bahasa alami. Ambiguitas kemudian akan menyangkut bagaimana menerapkan spesifikasi - tetapi ini akan diharapkan.

Tidak

Spesifikasi komputer yang tidak ambigu adalah program komputer.