Mengapa programmer mengabaikan standar ISO? [Tutup]

Salah satu hal yang sering saya temui adalah masalah yang disebabkan oleh program yang tidak sesuai dengan standar ISO.

Salah satu contoh tidak akan menggunakan tabel negara ISO tetapi membuat singkatan mereka sendiri, yang berlaku baik untuk Amerika Serikat (AS), atau Belanda (NL) tetapi berjalan sangat salah untuk Inggris (GB, bukan Inggris) atau Spanyol (ES, bukan SP) dan banyak negara lain.

Sebagai contoh lain, notasi tanggal internal. Mengapa ada yang menyimpan tanggal sebagai 01/02/2014? Sama sekali tidak jelas apakah itu tanggal 1 Februari atau 2 Januari, sedangkan jika Anda menggunakan standar ISO, Anda hanya menyimpan 2014-02-01 * dan ini jelas tanggal 1 Februari.

Pertanyaan saya: Kapan dan mengapa seorang programmer membuat konstruksi sendiri ketika ada standar ISO yang tersedia?

_{* Simpan 2014-02-01, dan format tanggal sesuai saat ditampilkan ke pengguna akhir.}

Jangan pernah mengaitkan dengan kedengkian yang dijelaskan dengan cukup oleh kebodohan. - Robert J Hanlon .

Itu, dan kurangnya komunikasi.

Jadi, ini bukan konspirasi sentimen anti-ISO yang membuat orang berpikir "Saya tahu, saya akan menggunakan Inggris, bukan GB", juga bukan kecenderungan bahwa "mereka tahu lebih baik", atau bahkan perasaan bahwa standarnya tidak baik . Itu akan sepenuhnya karena mereka tidak tahu itu ada di sana, dan mereka harus menggunakannya.

Maksudku, bagi sebagian orang, jika itu tidak dimasukkan ke dalam Visual Studio , mungkin juga tidak ada. Bagi sebagian yang lain, mungkin mereka hanya tidak menginginkan set lengkap atau terlalu sulit untuk mengambil daftar definitif, jadi mereka hanya membuat sub-set mereka sendiri untuk menyelesaikan situasi langsung mereka. Bagi yang lain, standarnya adalah apa yang digunakan - jadi pemformatan tanggal tidak "diformat dalam ISO, atau bahkan negara lokal", itu "diformat dalam apa pun yang keluar" dan jika itu sesuai dengan mereka, maka itu pekerjaan yang dilakukan (ini biasanya merupakan kritik terhadap programmer Amerika).

Ketika saya memprogram di Ruby, saya biasanya selalu mengabaikan standar ISO Ruby. Mengapa? Karena ini sangat membatasi! ISO Ruby adalah subset minimal dari persimpangan Ruby 1.8 dan Ruby 1.9. Versi Ruby saat ini, yang didukung oleh semua implementasi Ruby (atau setidaknya akan segera) adalah Ruby 2.1, dan memiliki banyak fitur yang membuat pemrograman lebih mudah. Pemrograman dalam ISO Ruby adalah PITA.

Ketika saya memprogram dalam C #, saya juga mengabaikan ISO C #, yang merupakan subset dari C # 2.0 (dan yang lebih penting, ISO Class Library adalah subset yang sangat kecil dari .NET BCL), dan sebaliknya saya memprogram di C # 5.0 dan saya tidak dapat membatasi diri saya untuk hanya menggunakan perpustakaan yang ditentukan dalam ISO CLI, sebagai gantinya saya menggunakan subset umum perpustakaan yang tersedia di .NET 4.5.2 dan Mono 3.4.0.

Dan ketika melakukan desain web, saya lebih suka menggunakan HTML5 daripada ISO HTML (yang merupakan bagian kecil dari HTML 4.01 Strict), sekali lagi, karena HTML5 jauh lebih kaya fitur daripada subset terbatas dari versi HTML kuno.

Jadi, ada alasan bagus untuk mengabaikan standar ISO.

Per contoh Anda, "GB" adalah kode negara untuk Britania Raya. Namun, "Inggris" pada waktu itu adalah kode standar MARC (Perpustakaan AS Kongres), meskipun saya percaya itu sudah usang. Dan IANA digunakan .ukuntuk domain tingkat atas untuk Britania Raya.

Jadi, jika sesuatu tidak sesuai dengan standar ISO, itu tidak berarti bahwa tidak ada standar yang digunakan; itu bisa berarti bahwa standar yang berbeda sedang digunakan. (Sebagaimana dicatat oleh @ Jörg dalam komentar, hal yang menyenangkan tentang standar adalah bahwa ada begitu banyak untuk dipilih.) Dalam hal ini pertanyaannya benar-benar menjadi standar mana yang paling sesuai untuk domain masalah, lingkungan, dll ?

Respons terhadap pertanyaan itu mungkin sebagian besar akan didasarkan pada opini dan dengan cepat berubah menjadi debat "agama". Tetapi kesesuaian standar ISO tidak selalu selalu merupakan jawaban terbaik. Misalnya, jika perangkat lunak perlu berinteraksi dengan database perpustakaan, standar MARC mungkin merupakan pilihan yang lebih tepat daripada ISO. Jika sebagian besar perangkat lunak organisasi Anda melakukan sesuatu dengan cara tertentu, Anda mungkin ingin tetap dengan pendekatan itu, setidaknya dalam jangka pendek - itu "standar" organisasi Anda.

Juga, standar berkembang / berubah. Apa yang konforman kemarin mungkin bukan hari ini.

Dan, sementara saya tidak ingin mengesampingkan ketidaktahuan dan / atau kemalasan sebagai penyebab masalah yang Anda tunjukkan ... pengembang mungkin tidak punya cukup waktu untuk mengatasinya.

Kepatuhan dengan standar ISO tidak selalu merupakan kegiatan yang bebas biaya. Jika standar tertentu belum diterapkan dalam toolkit yang ia gunakan, seorang programmer dihadapkan pada pilihan yang diperlukan: Apakah lebih murah untuk mengimplementasikan ini dengan benar sekarang, atau tidak mengimplementasikan standar dan menangani konversi nanti?

Mudah mengatakan "hei, Anda harus selalu menerapkan standar", tetapi semuanya memiliki biaya. Dan ada beberapa alasan bagus mengapa seorang programmer mungkin tidak ingin menerapkan standar ISO.

• Pelanggan mungkin mengikuti standar kepemilikan atau non-ISO. Lebih baik mengikuti standar yang diharapkan pelanggan daripada meninggalkan sakit kepala yang tidak diinginkan untuk penerus Anda dengan menyembunyikan implementasi tambahan selain apa yang diinginkan pelanggan dan bahasa Anda.
• Mungkin ada banyak data yang ada, dan konversi atau format-break mungkin belum layak. Jika Anda memiliki dua puluh tahun kontak pelanggan dan kontrak yang dikunci dengan waktu tanggal lokal, Anda tidak perlu ingin mengubah semua ratusan juta bidang menjadi tanggal standar ISO hingga Anda dapat melakukannya dengan benar.
• Kepatuhan terhadap standar dapat membebankan biaya yang lebih besar daripada manfaat yang diberikan. Jika Anda berurusan dengan entri sepenuhnya di Amerika Serikat, misalnya, lima karakter kode ISO-3166-2 (US-NY) adalah tiga karakter yang tidak dibutuhkan di atas kode pos AS (NY) standar.

Dalam kasus programmer / perancang basis data yang tidak berpengalaman , itu karena tidak mengetahui. Mereka cenderung menemukan kembali roda karena mereka tidak tahu sekelompok orang yang mencakup industri, sudah membahas masalah ini dan muncul dengan standar yang disetujui oleh semua yang berpartisipasi, seringkali setelah diskusi yang sangat panjang, revisi, dll. Baru-baru ini seorang rekan kerja saya menunjukkan keraguan ketika saya mengatakan kepadanya bahwa ada standar ISO tentang apakah minggu tertentu dianggap sebagai minggu terakhir dalam setahun atau yang pertama pada tahun berikutnya ( ISO 8601 ). Dia tidak percaya ada standar tentang sesuatu yang begitu spesifik. Saya mengatakan kepadanya bahwa kebenaran banyak aplikasi bergantung pada standar itu.

Dalam kasus programmer / perancang basis data yang berpengalaman , ini mengabaikan yang disebabkan oleh "mengetahui lebih baik" , sindrom yang tidak ditemukan di sini, dan / atau kebesaran. Mereka tidak mempercayai ISO atau badan standar lainnya karena mereka menganggap kode ISO "tidak cukup stabil" , yang berarti suatu hari akan berubah. Jadi mereka membuat kode / pengidentifikasi mereka sendiri, diciptakan di sini atau otomatis yang menghalangi interoperabilitas, yang juga mereka abaikan. Lihat pertanyaan serupa ini , meskipun desain database cenderung. Mereka memberi alasan seperti:

Saya mungkin tidak ingin desain database saya bergantung pada sekelompok pihak ketiga (IATA, ISO), terlepas dari seberapa stabil standar mereka. Atau, saya mungkin tidak ingin bergantung pada standar tertentu sama sekali.

Anehnya mereka yang mengabaikan standar menggunakan port USB standar, membeli DVD dan BluRays berukuran standar, dan mengendarai mobil dengan ban yang sesuai dengan standar.

Nah, orang cenderung mengabaikan standar ISO: misalnya, Anda menulis

jika Anda menggunakan standar ISO Anda hanya menyimpan 20140201 * dan itu jelas 1 Februari.

tetapi rendisi yang sepenuhnya sesuai ISO8601 sebenarnya 2014-02-01 . (lihat juga xkcd 1179 )

Salah satu alasannya adalah bahwa domain aplikasi dan pengguna mungkin tidak menggunakan standar ini sendiri. Bahkan ketika beberapa domain menggunakan beberapa standar, beberapa dari mereka mungkin telah membuat pilihan yang berbeda dari standar ISO, seringkali karena alasan historis.

Jika pengguna Anda sudah menggunakan "UK" dalam prosedur mereka yang ada ⁽¹⁾ untuk merujuk ke "Kerajaan Inggris Raya dan Irlandia Utara", itu tidak selalu masuk akal untuk menggunakan "GB" dalam struktur data mereka (terutama jika apa yang Anda maksud dengan negara bukanlah negara "ISO", misalnya memisahkan negara-negara Inggris atau memiliki perbedaan halus dengan Kepulauan Channel dan sebagainya). Tentu saja, Anda dapat memiliki pemetaan antara penyimpanan internal presentasi, tetapi kadang-kadang, itu sedikit di atas. Anda jarang pemrograman demi pemrograman, Anda sering harus beradaptasi dengan lingkungan Anda. ⁽²⁾

Anda juga harus ingat bahwa standar-standar ini telah berkembang secara paralel dengan perangkat lunak. Anda sering harus mengembangkan dalam konteks perangkat lunak lain, beberapa di antaranya mungkin dirancang secara tidak sempurna, beberapa di antaranya mungkin masih dipengaruhi oleh keputusan lama.

Bahkan jika Anda melihat format penyimpanan data internal, beberapa ambiguitas sulit untuk diselesaikan. Sebagai contoh, sejauh yang saya tahu, Excel menggunakan angka desimal untuk mewakili cap waktu: ia menggunakan bilangan bulat sebagai jumlah hari sejak tanggal referensi, lalu apa yang setelah desimal mewakili fraksi 24 jam untuk memberikan Anda jam. .. Masalahnya adalah ini mencegah Anda dari mempertimbangkan zona waktu akun atau waktu musim panas (23 jam atau 25 jam dalam sehari), dan Excel akan mengonversi tanggal / waktu apa pun ke format internal secara default. Apakah Anda ingin menggunakan format ISO atau tidak menjadi tidak relevan jika perangkat lunak lain yang harus Anda gunakan tidak memberikan Anda pilihan.

_{(1) Saya tidak bermaksud "prosedur pemrograman" di sini.}

_{(2) Jangan tanya saya mengapa orang juga tidak menggunakan standar itu dalam kehidupan sehari-hari mereka. Maksud saya YYYYmmdd jelas, dd / mm / YYYY jelas, tetapi memesan tanggal dengan granularity menengah, kecil, besar seperti mm / dd / YYYY, itu tidak masuk akal :-).}

Mengapa saya tidak menggunakan kode negara ISO 3166-1 alpha-2 ?

Karena saya menggunakan kode negara STANAG 1059 ... dan Inggris adalah kode untuk Inggris Raya (bukan GB sesuai ISO 3166-1).

Atau saya bisa menggunakan kode negara FIPS - lagi Inggris adalah kode negara untuk Inggris.

Ada banyak standar (ISO dan non-ISO) dan kadang-kadang domain tertentu menggunakan / menuntut standar yang tidak sesuai dengan standar ISO.

Menyimpan 20140201 sama sekali tidak ambigu. Hanya ketika Anda memasukkan pengetahuan yang mengikuti standar ISO apakah itu menjadi tidak ambigu. Hal yang sama berlaku untuk 01/02/2014: ketika Anda memasukkan pengetahuan bahwa formatnya adalah mm / hh / tttt juga sangat jelas.

Selama aplikasi tidak harus berinteraksi dengan aplikasi lain, standar apa pun yang didokumentasikan dengan baik dapat berfungsi dengan baik.

Ada tradeoff antara apa yang mudah bagi manusia (saya cenderung menggunakan 1-2-2014) dan komputer (yang bahkan akan lebih baik dengan representasi biner daripada ISO). Pemrogram pemula cenderung untuk tetap dengan apa yang mereka dapat dengan mudah memahami, lebih banyak pengalaman pemrogram mulai melihat keuntungan dari penyimpanan berorientasi komputer.

Poin yang tidak diangkat sejauh ini adalah kesesuaian budaya standar internasional.

Pertimbangkan standar internasional untuk pengukuran. Mari sajikan kepada pengguna di Amerika Serikat. Saya tidak yakin semua pengguna AS Anda akan senang tentang kilometer, kilogram, dan liter.

Pertimbangkan bahwa standar internasional ditulis oleh pemerintah. Jika pemerintah Spanyol memilih untuk tidak mengenali bahasa Basque maka bagaimana cara mendapatkan spesifikasi ISO? Ini khususnya masalah dengan dialek dan kreol kelompok-kelompok yang terpinggirkan.

Bahkan kode negara bisa bermasalah: apakah Krimea sekarang mendapatkan kode negara sendiri? Formula akhirnya ditemukan (mis., "Bekas Republik Yugoslavia Makedonia") tetapi aplikasi Anda mungkin perlu menunggu sampai diplomasi atau perang berakhir.

Pertimbangkan bahwa standar internasional ditulis dengan mempertimbangkan aplikasi tertentu. Ini mungkin tidak sepenuhnya sesuai dengan aplikasi Anda. Misalnya, jika Anda menyimpan bahasa dengan maksud untuk mengirim surat maka Anda mungkin ingin memberi kode pada orang buta secara jelas, bahkan jika mereka mahir dalam berbicara, katakanlah, US English. Organisasi statistik sangat menyadari perlunya menentukan makna yang pasti dari suatu variabel (alias "data meta" variabel) karena mereka menghadapi setiap kasus tepi yang mungkin selama sensus populasi. Beberapa kekakuan itu bermanfaat untuk bidang basis data.

Poin terakhir adalah bahwa dalam membuat pilihan semacam ini, program Anda mungkin membuat pernyataan politik. Kenyataan ini dapat mengacaukan dengan kode terbaik (misalnya, Anda mungkin perlu beberapa nama bahasa untuk bahasa yang sama).

Dalam pengalaman saya, pemrogram gagal menggunakan standar ISO untuk berbagai alasan yang dinyatakan, misalnya:

• "Saya tidak tahu bahwa ada standar ISO" (tidak lagi menjadi alasan yang sah begitu Anda diberitahu!)
• "Standar tidak dapat diakses (tidak dapat menemukan / membeli salinan)" (sungguh ??)
• "Standar ini terlalu ketat" (biasanya jika standar mengatakan "jangan" maka ada alasan yang bagus. Abaikan saja, Anda dan pelanggan Anda, bahaya!)
• "Standar tidak termasuk fungsionalitas / pustaka terbaru" (tidak ada standar yang mencakup setiap perpustakaan yang ingin Anda gunakan jadi patuhi standar untuk hal-hal yang TIDAK termasuk / tercakup dan konsisten dengan standar untuk hal-hal tersebut. itu tidak)
• "Standar ini terlalu rumit untuk diterapkan" (alasan penggunaan berlebihan tetapi lihat di bawah)

Satu-satunya alasan yang saya terima dari staf saya, karena tidak menjadi alasan yang lemah, adalah "standarnya benar-benar tidak cocok '" - didukung oleh bukti. Terkadang kompleksitas standar ISO yang berlaku tidak sebanding dengan masalah / solusi. Terkadang konteks di mana Anda akan menerapkan solusi Anda sangat berbeda dari yang diasumsikan oleh standar. Dan kadang-kadang standar dapat ditingkatkan - itulah bagaimana kemajuan terjadi.

Lebih sering daripada tidak, kegagalan untuk menggunakan standar ISO dapat dikaitkan dengan kurangnya pengalaman, kemalasan atau kesombongan. Saya menyesal mengatakan bahwa pemrogram yang berbahasa Inggris secara khusus bersalah karena malas dalam hal internasionalisasi dan bahwa kolega AS kami cenderung menganggap ISO sebagai "hal Eropa yang tidak relevan" (permintaan maaf kepada minoritas kepada siapa hal ini tidak berlaku).

ISO memiliki banyak standar. Seperti yang dilakukan CCITT / ITU. Beberapa standar ini adalah standar "aspirasional", sementara yang lain adalah fungsionalitas minimum yang diperlukan. Tidak sering jelas yang mana.

Saya ingat pada 1980-an bertanya mengapa beberapa vendor peralatan menerapkan satu subset standar sementara vendor lain menerapkan subset yang berbeda. Saat itulah keluar bahwa standar sering ditetapkan sebelum sesuatu bekerja. Dan vendor sering dengan sengaja memilih untuk tidak menerapkan standar sehingga mereka dapat menghambat interoperabilitas, yang kemudian memberi mereka keuntungan.

Itu sebabnya saya suka RET IETF. Mereka bahkan tidak menjadi RFC sampai ada 3 implementasi independen dari RFC.

Jika saya sedang membangun database Oracle, dan saya ingin menyimpan tanggal, saya akan menggunakan datatype Oracle DATE. Saya tidak akan tahu, atau peduli, apakah Oracle memenuhi standar ISO atau tidak. Ini benar-benar kasus kesesuaian saya dengan standar yang berbeda (yang Oracle) dan tidak begitu jauh dari standar ISO. Lihat tanggapan @ David.

Dalam beberapa kasus, pada saat saya menyadari ada standar ISO untuk sesuatu yang saya rancang, biaya untuk kembali dan mendesain ulang akan menjadi penghalang, atau setidaknya terlihat seperti itu.

Dalam jangka pendek, lebih banyak kode kerja dihasilkan dengan menggunakan standar yang tersedia atau dengan menciptakan yang baru dari pada penelitian yang cermat terhadap standar yang ada. Downside terjadi ketika integrasi skala besar membutuhkan interoperabilitas. Ini hampir selalu terjadi dalam konteks proyek selanjutnya.