Mengapa sebagian besar bahasa imperatif / OO “terkenal” memungkinkan akses tidak terkendali ke tipe yang dapat mewakili nilai 'tidak ada'?

Saya telah membaca tentang kenyamanan (bukan) memiliki nullalih-alih (misalnya) Maybe. Setelah membaca artikel ini , saya yakin akan jauh lebih baik menggunakanMaybe (atau yang serupa). Namun, saya terkejut melihat bahwa semua "terkenal" imperatif atau bahasa pemrograman berorientasi objek masih menggunakan null(yang memungkinkan akses tidak dicentang ke jenis yang dapat mewakili nilai 'tidak ada'), dan yang Maybesebagian besar digunakan dalam bahasa pemrograman fungsional.

Sebagai contoh, lihat kode C # berikut:

void doSomething(string username)
{
    // Check that username is not null
    // Do something
}

Ada yang baunya tidak enak di sini ... Mengapa kita harus memeriksa jika argumennya nol? Bukankah kita seharusnya mengasumsikan bahwa setiap variabel berisi referensi ke suatu objek? Seperti yang Anda lihat, masalahnya adalah bahwa menurut definisi, hampir semua variabel dapat berisi referensi nol. Bagaimana jika kita dapat memutuskan variabel mana yang "nullable" dan mana yang tidak? Itu akan menyelamatkan kita dari banyak upaya saat debugging dan mencari "NullReferenceException". Bayangkan, secara default, tidak ada tipe yang bisa berisi referensi nol . Alih-alih itu, Anda akan menyatakan secara eksplisit bahwa variabel dapat berisi referensi nol , hanya jika Anda benar-benar membutuhkannya. Itulah ide di balik Maybe. Jika Anda memiliki fungsi yang dalam beberapa kasus gagal (misalnya pembagian dengan nol), Anda dapat mengembalikan aMaybe<int>, menyatakan secara eksplisit bahwa hasilnya mungkin int, tetapi juga bukan apa-apa! Ini adalah salah satu alasan untuk memilih Mungkin daripada nol. Jika Anda tertarik pada lebih banyak contoh, maka saya sarankan untuk membaca artikel ini .

Faktanya adalah bahwa, meskipun ada kelemahan membuat sebagian besar tipe dapat dibatalkan secara default, sebagian besar bahasa pemrograman OO benar-benar melakukannya. Itu sebabnya saya bertanya-tanya tentang:

• Argumen seperti apa yang harus Anda terapkan nulldalam bahasa pemrograman Anda, bukan Maybe? Apakah ada alasan atau hanya "bagasi bersejarah"?

Harap pastikan Anda memahami perbedaan antara nol dan Mungkin sebelum menjawab pertanyaan ini.

Saya percaya ini adalah bawaan sejarah.

Bahasa yang paling menonjol dan tertua nulladalah C dan C ++. Tapi di sini, nullmemang masuk akal. Pointer masih cukup numerik dan konsep tingkat rendah. Dan bagaimana orang lain berkata, dalam pola pikir programmer C dan C ++, harus secara eksplisit mengatakan bahwa pointer nullitu tidak masuk akal.

Baris kedua adalah Java. Mempertimbangkan pengembang Java sedang berusaha mendekati C ++, sehingga mereka dapat membuat transisi dari C ++ ke Java lebih sederhana, mereka mungkin tidak ingin mengacaukan konsep inti bahasa tersebut. Selain itu, penerapan eksplisit nullakan membutuhkan lebih banyak upaya, karena Anda harus memeriksa apakah referensi non-nol benar-benar ditetapkan dengan benar setelah inisialisasi.

Semua bahasa lain sama dengan Java. Mereka biasanya menyalin cara C ++ atau Java melakukannya, dan mempertimbangkan bagaimana konsep inti nulldari jenis referensi implisit , menjadi sangat sulit untuk merancang bahasa yang menggunakan eksplisit null.

Sebenarnya, nullitu ide bagus. Diberikan pointer, kami ingin menunjukkan bahwa pointer ini tidak mereferensikan nilai yang valid. Jadi kami mengambil satu lokasi memori, menyatakan itu tidak valid, dan tetap pada konvensi itu (konvensi yang kadang-kadang diberlakukan dengan segfault). Sekarang setiap kali saya memiliki pointer saya dapat memeriksa apakah itu berisi Nothing( ptr == null) atau Some(value)( ptr != null, value = *ptr). Saya ingin Anda mengerti bahwa ini setara dengan Maybetipe.

Masalah dengan ini adalah:

1. Dalam banyak bahasa, sistem tipe tidak membantu di sini untuk menjamin referensi yang tidak nol.

   Ini adalah muatan historis, karena banyak bahasa arus utama imperatif atau OOP hanya memiliki kemajuan tambahan dalam sistem tipenya jika dibandingkan dengan pendahulunya. Perubahan kecil memiliki keuntungan bahwa bahasa baru lebih mudah dipelajari. C # adalah bahasa utama yang telah memperkenalkan alat tingkat bahasa untuk menangani nulls dengan lebih baik.

2. Desainer API mungkin kembali nullpada kegagalan, tetapi tidak merujuk pada hal yang sebenarnya pada kesuksesan. Seringkali, benda (tanpa referensi) dikembalikan secara langsung. Perataan satu tingkat penunjuk ini memungkinkan untuk digunakan nullsebagai nilai.

   Ini hanya kemalasan di sisi desainer dan tidak dapat membantu tanpa menegakkan sarang yang tepat dengan sistem tipe yang tepat. Beberapa orang mungkin juga mencoba untuk membenarkan ini dengan pertimbangan kinerja, atau dengan adanya pemeriksaan opsional (koleksi mungkin kembali nullatau barang itu sendiri, tetapi juga menyediakan containsmetode).

3. Di Haskell ada pandangan rapi ke Maybetipe sebagai monad. Ini membuatnya lebih mudah untuk menyusun transformasi pada nilai yang terkandung.

   Di sisi lain, bahasa tingkat rendah seperti C nyaris tidak memperlakukan array sebagai tipe terpisah, jadi saya tidak yakin apa yang kami harapkan. Dalam bahasa OOP dengan polimorfisme parameter, Maybetipe yang diperiksa runtime agak sepele untuk diterapkan.

Pemahaman saya adalah nullkonstruksi yang diperlukan untuk abstrak bahasa pemrograman di luar perakitan. ¹ Programmer membutuhkan kemampuan untuk menunjukkan bahwa pointer atau nilai register adalah not a valid valuedan nullmenjadi istilah umum untuk makna itu.

Memperkuat poin yang nullhanya konvensi untuk mewakili konsep, nilai aktual untuk nulldapat / dapat bervariasi berdasarkan bahasa dan platform pemrograman.

Jika Anda merancang bahasa baru dan ingin menghindari nulltetapi menggunakan maybesebagai gantinya, maka saya akan mendorong istilah yang lebih deskriptif seperti not a valid valueatau navvuntuk menunjukkan maksudnya. Tetapi nama yang tidak bernilai itu adalah konsep yang terpisah dari apakah Anda harus membiarkan nilai yang tidak ada itu ada dalam bahasa Anda.

Sebelum Anda dapat memutuskan salah satu dari dua poin tersebut, Anda perlu menentukan apa arti dari maybearti bagi sistem Anda. Anda mungkin menemukan itu hanya mengubah nama nullmakna not a valid valueatau Anda mungkin menemukan itu memiliki semantik yang berbeda untuk bahasa Anda.

Demikian juga, keputusan apakah akan memeriksa akses terhadap nullakses atau referensi adalah keputusan desain lain dari bahasa Anda.

Untuk memberikan sedikit sejarah, Cmemiliki asumsi implisit bahwa programmer memahami apa yang mereka coba lakukan ketika memanipulasi memori. Karena itu adalah abstraksi yang unggul untuk perakitan dan bahasa-bahasa penting yang mendahuluinya, saya berani mengatakan bahwa pemikiran untuk melindungi para programmer dari referensi yang salah tidak muncul di benak mereka.

Saya percaya bahwa beberapa kompiler atau alat tambahan mereka dapat memberikan ukuran pemeriksaan terhadap akses pointer yang tidak valid. Jadi orang lain telah mencatat masalah potensial ini dan mengambil langkah-langkah untuk melindunginya.

Apakah Anda mengizinkan atau tidak tergantung pada apa yang Anda ingin capai dalam bahasa Anda dan tingkat tanggung jawab apa yang ingin Anda sampaikan kepada pengguna bahasa Anda. Ini juga tergantung pada kemampuan Anda membuat kompiler untuk membatasi jenis perilaku itu.

Jadi untuk menjawab pertanyaan Anda:

1. "Argumen seperti apa ..." - Yah, itu tergantung pada apa yang Anda ingin bahasa itu lakukan. Jika Anda ingin mensimulasikan akses bare-metal maka Anda mungkin ingin mengizinkannya.

2. "Apakah ini hanya bagasi bersejarah?" Mungkin, mungkin juga tidak. nulltentu memiliki / memiliki arti untuk sejumlah bahasa dan membantu mengarahkan ekspresi bahasa-bahasa tersebut. Preseden historis mungkin telah memengaruhi bahasa yang lebih baru dan memungkinkannya nulltetapi agak berlebihan untuk melambaikan tangan Anda dan mendeklarasikan konsep bagasi historis yang tidak berguna.

¹ Lihat artikel Wikipedia ini meskipun kredit diberikan untuk Hoare untuk nilai-nilai nol dan bahasa berorientasi objek. Saya percaya bahasa imperatif berkembang di sepanjang silsilah keluarga yang berbeda dari Algol.

Jika Anda melihat contoh di artikel yang Anda kutip, sebagian besar waktu menggunakan Maybetidak mempersingkat kode. Itu tidak meniadakan kebutuhan untuk memeriksa Nothing. Satu-satunya perbedaan adalah itu mengingatkan Anda untuk melakukannya melalui sistem tipe.

Catatan, saya katakan "ingatkan," bukan paksaan. Pemrogram malas. Jika seorang programmer yakin suatu nilai tidak mungkin Nothing, mereka akan melakukan dereferensi Maybetanpa memeriksanya, seperti halnya mereka men-decereer null pointer sekarang. Hasil akhirnya adalah Anda mengubah pengecualian penunjuk nol menjadi pengecualian "mungkin kosong".

Prinsip yang sama dari sifat manusia berlaku di bidang lain di mana bahasa pemrograman mencoba memaksa pemrogram untuk melakukan sesuatu. Sebagai contoh, perancang Java mencoba memaksa orang untuk menangani sebagian besar pengecualian, yang menghasilkan banyak pelat baja yang mengabaikan secara diam-diam atau menyebarkan pengecualian secara membuta.

Apa yang membuat Maybeitu menyenangkan adalah ketika banyak keputusan dibuat melalui pencocokan pola dan polimorfisme alih-alih pemeriksaan eksplisit. Misalnya, Anda dapat membuat fungsi terpisah processData(Some<T>)dan processData(Nothing<T>)yang tidak dapat Anda lakukan null. Anda secara otomatis memindahkan penanganan kesalahan Anda ke fungsi yang terpisah, yang sangat diinginkan dalam pemrograman fungsional di mana fungsi diedarkan dan dievaluasi dengan malas daripada selalu dipanggil secara top-down. Dalam OOP, cara yang lebih disukai untuk memisahkan kode penanganan kesalahan Anda adalah dengan pengecualian.

Maybeadalah cara berpikir masalah yang sangat fungsional - ada sesuatu, dan itu mungkin atau mungkin tidak memiliki nilai yang didefinisikan. Namun, dalam pengertian berorientasi objek, kami mengganti gagasan tentang suatu hal (tidak peduli apakah itu memiliki nilai atau tidak) dengan suatu objek. Jelas, suatu objek memiliki nilai. Jika tidak, kita mengatakan objeknya null, tetapi yang kita maksud sebenarnya adalah bahwa tidak ada objek sama sekali. Referensi yang kita miliki ke objek tidak menunjukkan apa-apa. Menerjemahkan Maybeke dalam konsep OO tidak melakukan apa-apa novel - pada kenyataannya, itu hanya membuat kode lebih berantakan. Anda masih harus memiliki referensi nol untuk nilaiMaybe<T>. Anda masih harus melakukan pemeriksaan nol (pada kenyataannya, Anda harus melakukan lebih banyak pemeriksaan nol, mengacaukan kode Anda), bahkan jika sekarang disebut "mungkin cek". Tentu, Anda akan menulis kode yang lebih kuat seperti yang diklaim oleh penulis, tetapi saya berpendapat bahwa ini hanya masalahnya karena Anda telah membuat bahasanya jauh lebih abstrak dan tumpul, membutuhkan tingkat pekerjaan yang tidak perlu dalam kebanyakan kasus. Saya rela mengambil NullReferenceException sesekali daripada berurusan dengan kode spaghetti melakukan pemeriksaan Mungkin setiap kali saya mengakses variabel baru.

Konsep nulldapat dengan mudah ditelusuri kembali ke C tetapi tidak di situlah masalahnya.

Bahasa pilihan sehari-hari saya adalah C # dan saya akan tetap nulldengan satu perbedaan. C # memiliki dua jenis tipe, nilai dan referensi . Nilai tidak pernah bisa null, tetapi ada saatnya saya ingin bisa menyatakan bahwa tidak ada nilai yang baik-baik saja. Untuk melakukan ini C # menggunakan Nullabletipe sehingga intakan menjadi nilai dan int?nilai nullable. Ini adalah bagaimana saya pikir tipe referensi harus bekerja juga.

Lihat juga: Referensi kosong mungkin bukan kesalahan :

Referensi kosong sangat membantu dan terkadang sangat diperlukan (pertimbangkan berapa banyak masalah jika Anda dapat atau tidak mengembalikan string dalam C ++). Kesalahannya sebenarnya bukan pada keberadaan pointer nol, tetapi pada bagaimana sistem jenis menangani mereka. Sayangnya sebagian besar bahasa (C ++, Java, C #) tidak menanganinya dengan benar.

Saya pikir ini karena pemrograman fungsional lebih memperhatikan tipe , terutama tipe yang menggabungkan tipe lain (tuple, fungsi sebagai tipe kelas satu, monad, dll.) Daripada pemrograman berorientasi objek (atau paling tidak pada awalnya memang demikian).

Versi modern dari bahasa pemrograman yang saya pikir Anda bicarakan (C ++, C #, Java) semuanya didasarkan pada bahasa yang tidak memiliki bentuk pemrograman generik (C, C # 1.0, Java 1). Tanpa itu, Anda masih dapat memanggang beberapa jenis antara objek nullable dan non-nullable ke dalam bahasa (seperti referensi C ++, yang tidak bisa null, tetapi juga terbatas), tetapi itu jauh kurang alami.

Saya pikir alasan mendasar adalah bahwa relatif sedikit pemeriksaan nol diperlukan untuk membuat program "aman" terhadap korupsi data. Jika suatu program mencoba menggunakan konten elemen array atau lokasi penyimpanan lain yang seharusnya ditulis dengan referensi yang valid tetapi tidak, hasil kasus terbaik adalah pengecualian yang akan dibuang. Idealnya, pengecualian akan menunjukkan dengan tepat di mana masalah terjadi, tetapi yang penting adalah beberapa jenis pengecualian dilemparkan sebelum referensi nol disimpan di suatu tempat yang dapat menyebabkan korupsi data. Kecuali suatu metode menyimpan suatu objek tanpa mencoba menggunakannya terlebih dahulu, suatu upaya untuk menggunakan suatu objek akan - dengan sendirinya - merupakan semacam "pemeriksaan kosong".

Jika seseorang ingin memastikan bahwa referensi nol yang muncul di tempat yang seharusnya tidak menyebabkan pengecualian khusus selain NullReferenceException, sering kali perlu menyertakan cek nol di semua tempat. Di sisi lain, hanya memastikan bahwa beberapa pengecualian akan terjadi sebelum referensi nol dapat menyebabkan "kerusakan" di luar apa pun yang telah dilakukan akan sering memerlukan tes yang relatif sedikit - pengujian umumnya hanya diperlukan dalam kasus di mana suatu objek akan menyimpan referensi tanpa mencoba menggunakannya, dan baik referensi nol akan menimpa yang valid, atau akan menyebabkan kode lain salah menafsirkan aspek lain dari keadaan program. Situasi seperti itu ada, tetapi tidak terlalu umum; kebanyakan referensi nol yang tidak disengaja akan tertangkap dengan sangat cepatapakah orang memeriksa mereka atau tidak .

" Maybe," seperti yang tertulis, adalah konstruk tingkat yang lebih tinggi daripada nol. Menggunakan lebih banyak kata untuk mendefinisikannya, Mungkin adalah, "pointer ke salah satu hal, atau pointer ke tidak ada, tetapi kompiler belum diberi informasi yang cukup untuk menentukan yang mana." Ini memaksa Anda untuk secara eksplisit memeriksa setiap nilai secara konstan, kecuali jika Anda membangun spesifikasi kompiler yang cukup pintar untuk mengikuti kode yang Anda tulis.

Anda dapat membuat implementasi Maybe dengan bahasa yang memiliki null dengan mudah. C ++ memiliki satu dalam bentuk boost::optional<T>. Membuat yang setara dengan null dengan Maybe sangat sulit. Secara khusus, jika saya memiliki Maybe<Just<T>>, saya tidak dapat menetapkannya ke nol (karena konsep seperti itu tidak ada), sedangkan T**dalam bahasa dengan nol sangat mudah untuk menetapkan ke nol. Ini memaksa seseorang untuk menggunakan Maybe<Maybe<T>>, yang benar-benar valid, tetapi akan memaksa Anda untuk melakukan lebih banyak pemeriksaan untuk menggunakan objek itu.

Beberapa bahasa fungsional menggunakan Mungkin karena null memerlukan perilaku yang tidak terdefinisi atau penanganan perkecualian, yang keduanya tidak merupakan konsep yang mudah untuk dipetakan ke dalam sintaksis bahasa fungsional. Mungkin mengisi peran jauh lebih baik dalam situasi fungsional seperti itu, tetapi dalam bahasa prosedural, null adalah raja. Ini bukan masalah benar dan salah, hanya masalah apa yang membuatnya lebih mudah untuk memberitahu komputer untuk melakukan apa yang Anda inginkan.