Perché i programmatori ignorerebbero gli standard ISO? [chiuso]

Never attribute to malice that which is adequately explained by stupidity. -- Robert J Hanlon.

Questo e una mancanza di comunicazione.

Quindi, non è una cospirazione del sentimento anti-ISO che fa pensare alla gente "Lo so, userò il Regno Unito invece di GB", né è inclinazione a "loro sanno che è meglio", o addirittura a capire che lo standard non va bene Sarà interamente perché semplicemente non sanno che è lì, e dovrebbero usarlo.

Voglio dire, per alcune persone, se non è raggruppato in Visual Studio , potrebbe anche non esistere. Per alcuni altri, forse semplicemente non vogliono il set completo o è troppo difficile recuperare l'elenco definitivo, quindi si limitano a creare il proprio sotto-set per risolvere la loro situazione immediata. Per gli altri, il default è ciò che viene usato - quindi la formattazione della data non è "formattata in ISO, o anche locale del Paese", è "formattata in qualsiasi cosa venga fuori" e se ciò gli si addice, allora è un lavoro fatto (di solito è un critiche ai programmatori americani).

Quando programma in Ruby, generalmente ignoro sempre lo standard ISO Ruby. Perché? Perché è incredibilmente restrittivo! ISO Ruby è un sottoinsieme minimo dell'intersezione di Ruby 1.8 e Ruby 1.9. L'attuale versione di Ruby, che è supportata da tutte le implementazioni di Ruby (o almeno sarà molto presto) è Ruby 2.1, e ha molte caratteristiche che rendono più facile la programmazione. La programmazione in ISO Ruby è un PITA.

Quando programmo in C #, ignoro anche ISO C #, che è un sottoinsieme di C # 2.0 (e ancora più importante, la ISO Class Library è un sottoinsieme estremamente piccolo di .NET BCL), e invece programma in C # 5.0 e non mi limito a utilizzare solo le librerie che sono specificate nella CLI ISO, invece utilizzo il sottoinsieme comune di librerie disponibile in .NET 4.5.2 e Mono 3.4.0.

E quando faccio web design, preferisco usare HTML5 su ISO HTML (che è un piccolo sottoinsieme di HTML 4.01 Strict), ancora una volta, perché HTML5 è molto più ricco di funzionalità di un sottoinsieme limitato di una versione antica di HTML.

Quindi ci sono buone ragioni per ignorare gli standard ISO.

Per il tuo esempio, "GB" è il codice paese per il Regno Unito. Tuttavia, "UK" è stato contemporaneamente il codice standard MARC (US Library of Congress), anche se credo che sia deprecato. E lo IANA utilizza .uk per il dominio di primo livello per il Regno Unito.

Quindi, se qualcosa non è conforme a uno standard ISO, non significa che lo standard no è in uso; può semplicemente significare che viene utilizzato uno standard diverso . (Come notato da @ Jörg in un commento, la cosa bella degli standard è che ce ne sono così tanti tra cui scegliere.) In tal caso la domanda diventa davvero quale standard sarebbe più appropriato per il dominio, l'ambiente, ecc. .

Le risposte a questa domanda sarebbero probabilmente in gran parte basate sull'opinione pubblica e degenererebbero rapidamente in un dibattito "religioso". Ma la conformità allo standard ISO non è necessariamente sempre la migliore risposta. Ad esempio, se un software deve interfacciarsi con i database delle biblioteche, gli standard MARC potrebbero essere una scelta più appropriata di ISO. Se la maggior parte del software della tua organizzazione fa le cose in un certo modo, potresti voler mantenere quell'approccio, almeno nel breve termine: è lo "standard" della tua organizzazione, dopotutto.

Inoltre, gli standard si evolvono / cambiano. Quello che era conforme ieri potrebbe non essere oggi.

E, anche se non vorrei escludere ignoranza e / o indolenza come causa dei problemi che fai notare ... lo sviluppatore potrebbe semplicemente non aver avuto abbastanza tempo per affrontarli.

La conformità con uno standard ISO non è sempre un'attività gratuita. Se uno standard particolare non è già implementato nel toolkit che sta utilizzando, un programmatore deve affrontare una scelta necessaria: È più conveniente implementarlo correttamente ora o non implementare lo standard e gestire le conversioni in seguito?

È facile dire "hey, dovresti sempre implementare lo standard", ma tutto ha un costo. E ci sono alcune buone ragioni per cui un programmatore potrebbe non voler implementare uno standard ISO.

• Il cliente potrebbe seguire uno standard proprietario o non ISO. Meglio seguire lo standard che un cliente si aspetta di lasciare un mal di testa involontario per il suo successore nascondendo un'implementazione aggiuntiva oltre a ciò che il cliente desidera e richiede la lingua.
• Potrebbe esserci una grande quantità di dati esistenti e una conversione o interruzione di formato potrebbe non essere ancora fattibile. Se hai venti anni di contatti e contratti con clienti con data e ora locali, non devi necessariamente convertire tutte quelle centinaia di milioni di campi in date standard ISO finché non riesci a farlo correttamente.
• L'aderenza allo standard può imporre un costo maggiore rispetto a quello fornito. Se hai a che fare con voci interamente all'interno degli Stati Uniti, ad esempio, il codice ISO-3166-2 a cinque caratteri (US-NY) è di tre caratteri non necessari rispetto al codice postale statunitense standard (NY).

Nel caso di programmatori / designer di database inesperti , è perché non si sa. Tendono a reinventare la ruota perché non conoscono un gruppo di persone che abbracciano le industrie, hanno già discusso il problema e hanno elaborato uno standard approvato da tutti coloro che hanno partecipato, spesso dopo lunghe discussioni, revisioni, ecc. Recentemente un collaboratore il mio ha mostrato incredulità quando gli ho detto che c'era uno standard ISO sul fatto che una determinata settimana fosse considerata l'ultima settimana di un anno o la prima dell'anno successivo ( ISO 8601 ). Non credeva che esistesse uno standard per qualcosa di così specifico. Gli ho detto che la correttezza di molte applicazioni dipendeva da quello standard.

Nel caso di programmatori esperti / progettisti di database , non tiene conto della "conoscenza migliore" , della sindrome non inventata-qui e / o della grandiosità. Non si fidano di ISO o di altri corpi standard perché considerano il codice ISO "non abbastanza stabile" , il che significa che cambierà un giorno. Così creano i loro codici identificativi auto-inventati-qui o auto-incrementati che ostacolano l'interoperabilità, che ignorano anche loro. Vedi questo simile domanda , benché incline al design del database. Danno ragioni come:

I may not necessarily want my database design to depend on a bunch of third parties (IATA, ISO), regardless of how stable their standards are. Or, I may not want to depend on a particular standard at all.

Stranamente quelli che ignorano gli standard utilizzano porte USB standard, acquistano DVD e BluRay di dimensioni standard e guidano auto con pneumatici conformi agli standard.

Bene, le persone tendono a ignorare gli standard ISO: ad esempio, hai scritto

if you use the ISO standard you just store 20140201* and it's unambiguously February 1st.

ma la resa completamente conforme a ISO8601 è in effetti 2014-02-01 . (vedi anche xkcd 1179 )

Uno dei motivi è che il dominio dell'applicazione e gli utenti potrebbero non utilizzare questi standard da soli. Anche quando alcuni domini usano alcuni standard, alcuni potrebbero aver fatto scelte diverse rispetto agli standard ISO, spesso per ragioni storiche.

Se i tuoi utenti utilizzano già "UK" nelle loro procedure esistenti ⁽¹⁾ per fare riferimento a "Regno Unito di Gran Bretagna e Irlanda del Nord", non ha senso usare "GB "nelle loro strutture di dati (specialmente se ciò che intendi per paese non è abbastanza un paese" ISO ", ad esempio separare le nazioni del Regno Unito o avere sottili differenze con le Isole del Canale e così via). Naturalmente, è possibile avere una mappatura tra l'archiviazione interna di una presentazione, ma a volte è un po 'esagerato. Raramente programmi per la programmazione, spesso devi adattarti al tuo ambiente. ⁽²⁾

Devi anche ricordare che questi standard si sono evoluti in parallelo con il software. Spesso devi svilupparti nel contesto di altri software, alcuni dei quali potrebbero essere progettati in modo imperfetto, alcuni dei quali potrebbero comunque essere influenzati da decisioni legacy.

Anche se si osservano i formati di archiviazione dei dati interni, alcune ambiguità sono difficili da risolvere. Ad esempio, per quanto ne so, Excel utilizza un numero decimale per rappresentare i timestamp: utilizza un numero intero come numero di giorni da una data di riferimento, quindi cosa è dopo il decimale rappresenta la frazione delle 24 ore per fornire l'ora. .. Il problema è che questo ti impedisce di prendere in considerazione i fusi orari o l'ora legale (23 ore o 25 ore al giorno) e Excel convertirà qualsiasi data / ora in quel formato interno per impostazione predefinita. Se vuoi utilizzare il formato ISO o meno diventa irrilevante se un altro software con cui devi lavorare non ti lascia una scelta.

_{(1) Non intendo "procedure di programmazione" qui.}

_{(2) Non chiedermi perché persone non utilizzi nemmeno quegli standard nella loro vita quotidiana. Voglio dire YYYYmmdd è chiaro, gg / mm / AAAA è chiaro, ma ordinare una data con un ordine di granularità medio, piccolo, grande come mm / gg / AAAA, che non ha senso :-).}

Perché non dovrei utilizzare i codici ISO 3166-1 alpha-2 ?

Perché uso i codici paese STANAG 1059 ... e in quel Regno Unito è il codice per il Regno Unito (invece di GB secondo ISO 3166-1).

In alternativa, potrei utilizzare i codici FIPS - di nuovo il Regno Unito è il codice paese per il Regno Unito.

Esistono molti standard (ISO e non ISO) ea volte un particolare dominio utilizza / richiede uno standard che è incompatibile con lo standard ISO.

L'archiviazione di 20140201 non è affatto ambigua. Solo quando includi la conoscenza che segue lo standard ISO diventa univoco. Lo stesso vale per l'1/02/2014: quando includi la consapevolezza che il formato è mm / gg / aaaa è anche perfettamente inequivocabile.

Finché l'applicazione non deve interfacciarsi con altre applicazioni, qualsiasi standard ben documentato può funzionare altrettanto bene.

Esiste un compromesso tra ciò che è facile per gli esseri umani (io tendo ad usare 1-2-2014) e i computer (chi sarebbe meglio con una rappresentazione binaria invece di ISO). I programmatori principianti tendono a rimanere fedeli a ciò che possono facilmente capire, più esperienze i programmatori iniziano a vedere i vantaggi dell'archiviazione orientata al computer.

Un punto non sollevato finora è l'appropriatezza culturale degli standard internazionali.

Considerare lo standard internazionale per le misurazioni. Presentiamo quelli agli utenti negli Stati Uniti. Non sono sicuro che tutti i tuoi utenti statunitensi saranno contenti di chilometri, chilogrammi e litri.

Considera che gli standard internazionali sono scritti dai governi. Se il governo della Spagna sceglie di non riconoscere la lingua basca, allora come ottiene una specifica ISO? Questo è particolarmente un problema con i dialetti e i creoli dei gruppi emarginati.

Anche i codici paese possono essere problematici: la Crimea ora ha il proprio codice paese? Alla fine verranno trovate formule (ad esempio, "Ex Repubblica jugoslava di Macedonia"), ma la tua candidatura potrebbe richiedere un po 'di stand-in finché la diplomazia o la guerra non finiranno.

Considera che gli standard internazionali sono scritti pensando a particolari applicazioni. Questi potrebbero non adattarsi perfettamente alla tua applicazione. Ad esempio, se stai memorizzando la lingua per inviare lettere, potresti voler codificare distintamente il cieco, anche se sono abili nel parlare, ad esempio, in inglese americano. Le organizzazioni di statistica sono ben consapevoli della necessità di specificare il significato esatto di una variabile (ovvero i "metadati" della variabile) quando incontrano ogni possibile caso limite durante un censimento della popolazione. Parte di questo rigore è utile per i campi del database.

Il punto finale è che nel fare questo tipo di scelte il tuo programma potrebbe fare una dichiarazione politica. Questa realtà può interferire con il codice più bello (ad esempio, potresti aver bisogno di più nomi di lingua per la stessa lingua).

Nella mia esperienza i programmatori non utilizzano gli standard ISO per una serie di motivi dichiarati, ad esempio:

• "Non sapevo che esistesse uno standard ISO" (cessa di essere un valido motivo una volta che ti viene detto!)
• "Lo standard è inaccessibile (impossibile trovare / permetterne una copia)" (veramente ??)
• "Lo standard è troppo restrittivo" (di solito se lo standard dice "non farlo", allora c'è una buona ragione. Ignoralo al tuo, e al tuo cliente, pericolo!)
• "Lo standard non include l'ultima funzionalità / libreria" (nessuno standard include OGNI libreria che vorrete mai usare così aderire allo standard per le cose che include / cover ed essere coerenti con lo standard per le cose che non fa)
• "Lo standard è troppo ingombrante da implementare" (scusa eccessivamente usata ma vedi sotto)

L'unica ragione per cui accetto il mio staff, in quanto non è una scusa pessima, è "lo standard non è un buon 'adattamento'" - supportato da prove. A volte la complessità dello standard ISO applicabile è sproporzionata rispetto al problema / soluzione. A volte il contesto in cui implementerai la tua soluzione è significativamente diverso da quello ipotizzato dallo standard. E a volte lo standard può essere migliorato - ecco come avviene il progresso.

Il più delle volte però, l'incapacità di usare lo standard ISO può essere attribuita all'inesperienza, alla pigrizia o all'arroganza. Mi dispiace dire che i programmatori di lingua inglese sono particolarmente colpevoli di pigrizia per quanto riguarda l'internazionalizzazione e che i nostri colleghi statunitensi tendono a percepire l'ISO come "una cosa europea irrilevante" (scuse alla minoranza a cui questo non si applica).

ISO ha molti standard. Come ha fatto CCITT / ITU. Alcuni di questi standard sono standard "aspirazionali", mentre altri sono requisiti minimi richiesti. Non è spesso chiaro quale sia quale.

Ricordo che negli anni '80 mi ero chiesto perché alcuni produttori di apparecchiature implementassero un sottoinsieme dello standard mentre altri produttori implementano un sottoinsieme diverso. Ecco quando è venuto fuori che gli standard sono spesso impostati prima che qualcosa funzioni. E i fornitori spesso scelgono deliberatamente di non implementare gli standard in modo che possano ostacolare l'interoperabilità, il che conferisce loro un vantaggio.

Ecco perché mi piacciono gli RFC IETF. Non diventano nemmeno RFC finché non ci sono 3 implementazioni indipendenti della RFC.

Se sto creando un database Oracle e voglio memorizzare le date, utilizzerò il tipo di dati Oracle DATE. Non saprò, o mi preoccuperò, se Oracle è conforme allo standard ISO. Questo è davvero il caso della mia conformità a uno standard diverso (quello di Oracle) e non tanto alla partenza dallo standard ISO. Vedi @ Risposta di David.

In alcuni casi, quando ho capito che c'era uno standard ISO per qualcosa che avevo progettato, il costo di tornare indietro e ridisegnare sarebbe stato proibitivo, o almeno lo si è visto in quel modo.

A breve termine, viene prodotto un codice più funzionante utilizzando gli standard disponibili o inventandone di nuovi piuttosto che da un'attenta ricerca sugli standard esistenti. Lo svantaggio si verifica quando l'integrazione su larga scala richiede l'interoperabilità. Questo accade quasi sempre nel contesto di un progetto successivo.