¿Por qué los programadores ignorarían los estándares ISO? [cerrado]

Una de las cosas con las que me encuentro a menudo son los problemas causados ​​por programas que no se ajustan a los estándares ISO.

Un ejemplo sería no usar las tablas de países ISO, sino crear sus propias manos cortas, lo que está bien para los Estados Unidos (EE. UU.) O los Países Bajos (NL), pero va espectacularmente mal para el Reino Unido (GB, no el Reino Unido) o España (ES, no SP) y muchos otros países.

Como otro ejemplo, anotaciones de fecha interna. ¿Por qué alguien almacenaría una fecha como 01/02/2014 alguna vez? No está completamente claro si eso es el 1 de febrero o el 2 de enero, mientras que si usa el estándar ISO simplemente almacena el 1 de febrero de 2014 * y es inequívocamente el 1 de febrero.

Mi pregunta: ¿cuándo y por qué un programador debe hacer sus propias construcciones cuando hay un estándar ISO disponible?

_{* Almacene el 01-02-2014 y formatee la fecha en consecuencia cuando se lo muestre a un usuario final.}

Nunca atribuya a la malicia lo que se explica adecuadamente por la estupidez. - Robert J. Hanlon .

Eso y falta de comunicación.

Por lo tanto, no es una conspiración del sentimiento anti-ISO que hace que la gente piense "Lo sé, usaré el Reino Unido en lugar de GB", ni es una inclinación a que "sepan mejor", o incluso la sensación de que el estándar no es bueno . Será completamente porque simplemente no saben que está allí, y deberían usarlo.

Quiero decir, para algunas personas, si no está incluido en Visual Studio , bien podría no existir. Para algunos otros, tal vez simplemente no quieren el conjunto completo o es demasiado difícil obtener la lista definitiva, por lo que simplemente crean su propio subconjunto para resolver su situación inmediata. Para otros, el valor predeterminado es lo que se usa, por lo que el formato de fecha no está "formateado en ISO, o incluso en la configuración regional del país", está "formateado en lo que sea que salga" y si eso les conviene, entonces es un trabajo hecho (esto generalmente es un crítica a los programadores estadounidenses).

Cuando programo en Ruby, generalmente siempre ignoro el estándar ISO Ruby. ¿Por qué? ¡Porque es increíblemente restrictivo! ISO Ruby es un subconjunto mínimo de la intersección de Ruby 1.8 y Ruby 1.9. La versión actual de Ruby, que es compatible con todas las implementaciones de Ruby (o al menos lo será muy pronto) es Ruby 2.1, y tiene muchas características que facilitan la programación. La programación en ISO Ruby es una PITA.

Cuando programo en C #, también ignoro ISO C #, que es un subconjunto de C # 2.0 (y lo que es más importante, la Biblioteca de clases ISO es un subconjunto extremadamente pequeño de .NET BCL), y en su lugar programo en C # 5.0 y no uso No me limito a usar solo las bibliotecas que se especifican en la CLI de ISO, sino que uso el subconjunto común de bibliotecas disponibles en .NET 4.5.2 y Mono 3.4.0.

Y al hacer diseño web, prefiero usar HTML5 sobre HTML ISO (que es un pequeño subconjunto de HTML 4.01 Strict), una vez más, porque HTML5 es mucho más rico en funciones que un subconjunto restringido de una versión antigua de HTML.

Por lo tanto, hay buenas razones para ignorar las normas ISO.

Según su ejemplo, "GB" es el código de país para el Reino Unido. Sin embargo, "Reino Unido" fue el código estándar MARC (Biblioteca del Congreso de EE. UU.), Aunque creo que está en desuso. Y la IANA utiliza .ukel dominio de nivel superior para el Reino Unido.

Entonces, si algo no se ajusta a un estándar ISO, no significa que no se esté utilizando ningún estándar; puede significar simplemente que se está utilizando un estándar diferente . (Como se señaló @ Jörg en un comentario, lo bueno de los estándares es que hay tantos para elegir.) En este caso la pregunta realmente se convierte en el estándar que serían las más apropiadas para el dominio del problema dado, medio ambiente, etc. ?

Las respuestas a esa pregunta probablemente se basarían en gran medida en opiniones y rápidamente degenerarían en un debate "religioso". Pero la conformidad con la norma ISO no es necesariamente la mejor respuesta. Por ejemplo, si un software necesita interactuar con las bases de datos de la biblioteca, los estándares MARC podrían ser una opción más apropiada que la ISO. Si la mayoría del software de su organización hace las cosas de cierta manera, es posible que desee seguir con ese enfoque, al menos a corto plazo: después de todo, es el "estándar" de su organización.

Además, los estándares evolucionan / cambian. Lo que ayer fue conforme puede no serlo hoy.

Y, aunque no quisiera descartar la ignorancia y / o la pereza como la causa de los problemas que usted señala ... es posible que el desarrollador simplemente no haya tenido tiempo suficiente para abordarlos.

El cumplimiento de una norma ISO no siempre es una actividad gratuita. Si un estándar en particular aún no está implementado en el juego de herramientas que está usando, un programador se enfrenta a una elección necesaria: ¿es más barato implementar esto correctamente ahora o no implementar el estándar y manejar las conversiones más adelante?

Es fácil decir "oye, siempre debes implementar el estándar", pero todo tiene un costo. Y hay algunas buenas razones por las cuales un programador puede no querer implementar un estándar ISO.

• El cliente puede estar siguiendo un estándar patentado o no ISO. Es mejor cumplir con el estándar que espera un cliente que dejar dolores de cabeza involuntarios para su sucesor al ocultar una implementación adicional además de lo que el cliente quiere y su idioma requiere.
• Puede haber una gran cantidad de datos existentes, y una conversión o salto de formato aún no es factible. Si tiene veinte años de contactos con clientes y contratos con fechas y horas locales, no necesariamente desea cambiar todos esos cientos de millones de campos a fechas estándar ISO hasta que pueda hacerlo bien.
• El cumplimiento de la norma puede imponer un costo mayor que el beneficio que proporciona. Si se trata de entradas enteramente dentro de los Estados Unidos, por ejemplo, el código ISO-3166-2 de cinco caracteres (US-NY) es tres caracteres innecesarios sobre el código postal estándar de los Estados Unidos (NY).

En el caso de programadores / diseñadores de bases de datos sin experiencia , es por no saberlo. Tienden a reinventar la rueda porque no conocen a un grupo de personas que abarquen industrias, ya discutieron el tema y elaboraron un estándar aprobado por todos los que participaron, a menudo después de largas discusiones, revisiones, etc. Recientemente, un compañero de trabajo la mía mostró incredulidad cuando le dije que había un estándar ISO con respecto a si una semana determinada se considera la última semana de un año o la primera del año siguiente ( ISO 8601 ). No creía que existiera un estándar con respecto a algo tan específico. Le dije que la corrección de muchas aplicaciones dependía de ese estándar.

En el caso de programadores / diseñadores de bases de datos experimentados , no se tiene en cuenta el hecho de "conocer mejor" , el síndrome no inventado aquí y / o la grandiosidad. No confían en ISO ni en ningún otro organismo estándar porque consideran que el código ISO "no es lo suficientemente estable" , lo que significa que algún día cambiará. Por lo tanto, crean sus propios códigos / identificadores inventados aquí o con incremento automático que dificultan la interoperabilidad, lo que también ignoran. Vea esta pregunta similar , aunque inclinado el diseño de la base de datos. Dan razones como:

Es posible que no quiera que el diseño de mi base de datos dependa de un grupo de terceros (IATA, ISO), independientemente de cuán estables sean sus estándares. O bien, es posible que no quiera depender de un estándar en particular.

Curiosamente, aquellos que ignoran los estándares usan puertos USB estándar, compran DVD y BluRays de tamaño estándar y conducen automóviles con neumáticos que cumplen con los estándares.

Bueno, la gente tiende a ignorar los estándares ISO: por ejemplo, usted escribió

si usa el estándar ISO, simplemente almacene 20140201 * y es inequívocamente el 1 de febrero.

pero la versión totalmente compatible con ISO8601 es, de hecho, 2014-02-01 . (ver también xkcd 1179 )

Una de las razones es que el dominio de la aplicación y los usuarios podrían no usar estos estándares ellos mismos. Incluso cuando algunos dominios usan algunos estándares, algunos de ellos pueden haber tomado diferentes decisiones que los estándares ISO, a menudo por razones históricas.

Si sus usuarios ya usan "Reino Unido" en sus procedimientos existentes ⁽¹⁾ para referirse a "Reino Unido de Gran Bretaña e Irlanda del Norte", no necesariamente tiene sentido usar "GB" en sus estructuras de datos (especialmente si por país no es exactamente un país "ISO", por ejemplo, separar las naciones del Reino Unido o tener diferencias sutiles con las Islas del Canal, etc. Por supuesto, podría tener una asignación entre el almacenamiento interno y una presentación, pero a veces es un poco exagerado. Raramente está programando por el bien de la programación, a menudo tiene que adaptarse a su entorno. ⁽²⁾

También debe recordar que estos estándares han evolucionado en paralelo con el software. A menudo tiene que desarrollarse dentro del contexto de otras piezas de software, algunas de las cuales pueden estar diseñadas de manera imperfecta, algunas de las cuales aún pueden verse afectadas por decisiones heredadas.

Incluso si observa los formatos de almacenamiento de datos internos, algunas ambigüedades son difíciles de resolver. Por ejemplo, hasta donde yo sé, Excel usa un número decimal para representar las marcas de tiempo: usa un número entero como el número de días desde una fecha de referencia, luego lo que está después del decimal representa la fracción de las 24 horas para darle la hora. .. El problema es que esto le impide tener en cuenta las zonas horarias o el horario de verano (23h o 25h en un día), y Excel convertirá cualquier fecha / hora a ese formato interno de forma predeterminada. Si desea utilizar el formato ISO o no, se vuelve irrelevante si otra pieza de software con la que tiene que trabajar no le deja una opción.

_{(1) No me refiero a "procedimientos de programación" aquí.}

_{(2) No me pregunte por qué las personas tampoco usan esos estándares en su vida diaria. Quiero decir AAAAMMdd es claro, dd / mm / AAAA es claro, pero ordenar una fecha con un orden de granularidad medio, pequeño y grande como mm / dd / AAAA, eso simplemente no tiene sentido :-).}

¿Por qué no usaría los códigos de país ISO 3166-1 alpha-2 ?

Porque uso los códigos de país STANAG 1059 ... y en ese Reino Unido está el código para el Reino Unido (en lugar de GB según ISO 3166-1).

Alternativamente, podría usar los códigos de país FIPS ; nuevamente, el Reino Unido es el código de país para el Reino Unido.

Hay muchos estándares (ISO y no ISO) y, a veces, un dominio particular usa / exige un estándar que es incompatible con el estándar ISO.

Almacenar 20140201 no es nada ambiguo. Solo cuando incluye el conocimiento que sigue el estándar ISO se vuelve inequívoco. Lo mismo ocurre con el 01/02/2014: cuando incluye el conocimiento de que el formato es mm / dd / aaaa, también es perfectamente inequívoco.

Siempre que la aplicación no tenga que interactuar con otra aplicación, cualquier estándar bien documentado puede funcionar igual de bien.

Existe una compensación entre lo que es fácil para los humanos (tiendo a usar 1-2-2014) y las computadoras (que incluso serían mejores con una representación binaria en lugar de ISO). Los programadores novatos tienden a apegarse a lo que pueden entender fácilmente, más programadores de experiencias comienzan a ver las ventajas del almacenamiento orientado a la computadora.

Un punto que no se ha planteado hasta ahora es la adecuación cultural de las normas internacionales.

Considere el estándar internacional para mediciones. Vamos a presentarlos a los usuarios en los Estados Unidos. No estoy seguro de que todos sus usuarios estadounidenses estén contentos con los kilómetros, kilogramos y litros.

Tenga en cuenta que las normas internacionales son redactadas por los gobiernos. Si el gobierno de España decide no reconocer el idioma vasco, ¿cómo obtiene una especificación ISO? Esto es particularmente un problema con los dialectos y criollos de los grupos marginados.

Incluso los códigos de país pueden ser problemáticos: ¿Crimea ahora tiene su propio código de país? Con el tiempo, se encuentran fórmulas (por ejemplo, "Antigua República Yugoslava de Macedonia"), pero su solicitud puede necesitar algunos sustitutos hasta que finalice la diplomacia o la guerra.

Tenga en cuenta que las normas internacionales están escritas teniendo en cuenta aplicaciones particulares. Es posible que estos no se ajusten completamente a su aplicación. Por ejemplo, si está almacenando un idioma con el fin de enviar cartas, es posible que desee codificar a los ciegos de forma distinta, incluso si son competentes para hablar, por ejemplo, inglés de EE. UU. Las organizaciones de estadística son conscientes de la necesidad de especificar el significado exacto de una variable (también conocido como "metadatos" de la variable) ya que se encuentran con todos los casos límite posibles durante un censo de población. Algo de ese rigor vale la pena para los campos de la base de datos.

El punto final es que al hacer este tipo de elecciones, su programa puede estar haciendo una declaración política. Esta realidad puede interferir con el mejor código (p. Ej., Es posible que necesite varios nombres de idioma para el mismo idioma).

En mi experiencia, los programadores no usan los estándares ISO por una variedad de razones establecidas, por ejemplo:

• "No sabía que había un estándar ISO" (¡deja de ser una razón válida una vez que te lo dicen!)
• "El estándar es inaccesible (no puedo encontrar / pagar una copia)" (¿en serio?)
• "El estándar es demasiado restrictivo" (por lo general, si el estándar dice "no", entonces hay una buena razón. ¡Ignórelo bajo su riesgo y el de su cliente!)
• "El estándar no incluye la última funcionalidad / biblioteca" (ningún estándar incluye TODAS las bibliotecas que quiera usar, por lo tanto, adhiérase al estándar para lo que SÍ incluye / cubre y sea coherente con el estándar para las cosas que no lo hace)
• "El estándar es demasiado engorroso para implementar" (excusa muy usada en exceso, pero ver más abajo)

La única razón por la que acepto de mi personal, ya que no es una excusa poco convincente, es "el estándar realmente no es un buen" ajuste ", respaldado por evidencia. A veces, la complejidad del estándar ISO aplicable está fuera de proporción con el problema / solución. A veces, el contexto en el que implementará su solución es significativamente diferente del supuesto por el estándar. Y a veces se puede mejorar el estándar, así es como sucede el progreso.

Sin embargo, la mayoría de las veces, la falta de uso del estándar ISO puede atribuirse a la inexperiencia, la pereza o la arrogancia. Lamento decir que los programadores de habla inglesa son particularmente culpables de pereza en lo que respecta a la internacionalización y que nuestros colegas de EE. UU. Tienden a percibir a ISO como "algo europeo irrelevante" (disculpas a la minoría a quien esto no se aplica).

ISO tiene muchos estándares. Como lo hizo CCITT / ITU. Algunos de estos estándares son estándares "aspiracionales", mientras que otros son funcionalidades mínimas requeridas. A menudo no está claro cuál es cuál.

Recuerdo en la década de 1980 que preguntaba por qué algunos proveedores de equipos implementan un subconjunto del estándar, mientras que otros proveedores implementan un subconjunto diferente. Fue entonces cuando se descubrió que los estándares a menudo se establecen antes de que algo funcione. Y los proveedores a menudo eligen deliberadamente no implementar estándares para que puedan obstaculizar la interoperabilidad, lo que luego les otorga una ventaja.

Por eso me gustan los RFC de IETF. Ni siquiera se convierten en RFC hasta que hay 3 implementaciones independientes de RFC.

Si estoy construyendo una base de datos Oracle y quiero almacenar fechas, voy a utilizar el tipo de datos DATE de Oracle. No sabré, ni me importará, si Oracle cumple o no con el estándar ISO. Este es realmente un caso de mi conformidad con un estándar diferente (el de Oracle) y no tanto desviación del estándar ISO. Ver la respuesta de @ David.

En algunos casos, cuando me di cuenta de que había un estándar ISO para algo que había diseñado, el costo de volver y rediseñar habría sido prohibitivo, o al menos se lo veía así.

A corto plazo, se genera más código de trabajo utilizando los estándares disponibles o inventando otros nuevos que mediante una cuidadosa investigación de los estándares existentes. La desventaja ocurre cuando la integración a gran escala requiere interoperabilidad. Esto casi siempre ocurre en el contexto de un proyecto posterior.