¿Por qué todavía programamos con archivos planos? [cerrado]

https://stackoverflow.com/questions/160633

flat-file

03-07-2019
|

Pregunta

¿Por qué los archivos de texto plano son el estado del arte para representar el código fuente?

Claro: el preprocesador y el compilador necesitan ver una representación de archivo plano del archivo, pero eso se crea fácilmente.

Me parece que alguna forma de datos XML o binarios podría representar muchas ideas que son muy difíciles de rastrear, de lo contrario.

Por ejemplo, podría incrustar diagramas UML directamente en su código. Podrían generarse semiautomáticamente y ser anotados por los desarrolladores para resaltar aspectos importantes del diseño. Diagramas de interacción en particular. Diablos, incrustar cualquier dibujo de usuario podría aclarar las cosas.

Otra idea es insertar comentarios de las revisiones de código directamente en el código.

Podría haber todo tipo de ayudas para facilitar la fusión de varias ramas.

Algo que me apasiona no es solo rastrear la cobertura del código, sino también mirar las partes del código cubiertas por una prueba automatizada. La parte difícil es realizar un seguimiento de ese código, incluso cuando se modifica la fuente. Por ejemplo, mover una función de un archivo a otro, etc. Esto se puede hacer con GUID, pero son bastante intrusivos para incrustarlos directamente en el archivo de texto. En un formato de archivo enriquecido, podrían ser automáticos y discretos.

Entonces, ¿por qué no hay IDEs (que yo sepa, de todos modos) que le permitan trabajar con código de esta manera?

EDITAR: el 7 de octubre de 2009.

La mayoría de ustedes se obsesionaron con la palabra " binary " en mi pregunta Lo retraigo. Imagen XML, marcando muy mínimamente su código. En el instante antes de entregarlo a su preprocesador o compilador normal, elimina todo el marcado XML y pasa solo el código fuente. De esta forma, aún podría hacer todas las cosas normales en el archivo: diff, fusionar, editar, trabajar en un editor simple y mínimo, alimentarlos en miles de herramientas. Sí, la diferenciación, fusión y edición, directamente con el marcado XML mínimo, se vuelve un poco más complicado. Pero creo que el valor podría ser enorme.

Si existiera un IDE que respetara todo el XML, podría agregar mucho más de lo que podemos hacer hoy.

Por ejemplo, sus comentarios de DOxygen podrían en realidad verse como la salida final de DOxygen.

Cuando alguien quería hacer una revisión del código, como Code Collaborator, podía marcar el código fuente en su lugar.

El XML incluso podría ocultarse detrás de los comentarios.

// <comment author="mcruikshank" date="2009-10-07">
// Please refactor to Delegate.
// </comment>

Y luego, si desea usar vi o emacs, puede omitir los comentarios.

Si quiero usar un editor de última generación, puedo verlo en una docena de diferentes formas útiles.

Entonces, esa es mi idea aproximada. No es & Quot; bloques de construcción & Quot; de imágenes que arrastras en la pantalla ... No estoy tan loco. :)

Solución

puedes diferenciarlos
puedes fusionarlos
cualquiera puede editarlos
son simples y fáciles de tratar
son accesibles universalmente para miles de herramientas

Otros consejos

En mi opinión, cualquier beneficio posible se compensa al estar vinculado a una herramienta en particular.

Con la fuente de texto sin formato (que parece ser lo que está discutiendo, en lugar de archivos planos per se) puedo pegar fragmentos en un correo electrónico, usar sistemas de control de versiones simples (¡muy importante! ), escriba el código en los comentarios sobre Stack Overflow, use uno de los mil editores de texto en cualquier cantidad de plataformas, etc.

Con alguna representación binaria de código, necesito usar un editor especializado para verlo o editarlo. Incluso si se puede producir una representación basada en texto, no puede retroceder trivialmente los cambios a la versión canónica.

Smalltalk es un entorno basado en imágenes. Ya no está trabajando con código en un archivo en el disco. Estás trabajando y modificando los objetos reales en tiempo de ejecución. Todavía es texto pero las clases no se almacenan en archivos legibles por humanos. En cambio, toda la memoria del objeto (la imagen) se almacena en un archivo en formato binario.

Pero la mayor queja de quienes prueban smalltalk es porque no utiliza archivos. La mayoría de las herramientas basadas en archivos que tenemos (vim, emacs, eclipse, vs.net, herramientas unix) tendrán que ser abandonadas en favor de las propias herramientas de smalltalk. No es que las herramientas proporcionadas en smalltalk en inferior. Es simplemente diferente.

¿Por qué los ensayos están escritos en texto? ¿Por qué los documentos legales están escritos en texto? ¿Por qué las novelas de fantasía están escritas en texto? Porque el texto es la mejor forma para las personas de persistir en sus pensamientos.

El texto es cómo las personas piensan, representan, comprenden y persisten los conceptos , y sus complejidades, jerarquías e interrelaciones.

Los programas Lisp no son archivos planos. Son la serialización de estructuras de datos. Este código como datos es una vieja idea, y en realidad una de las mejores ideas en informática.

<? xml version = " 1.0 " encoding = " UTF-8 "? > < code > Los archivos planos son más fáciles de leer. < / code > ; < / xml >

He aquí por qué:

Lectura humana. Eso hace que sea mucho más fácil detectar un error, tanto en el archivo como en el método de análisis. También se puede leer en voz alta. Esa es una que simplemente no puede obtener con XML, y podría marcar la diferencia, especialmente en atención al cliente.
Seguro contra la obsolescencia. Mientras exista expresión regular, es posible escribir un analizador bastante bueno en solo unas pocas líneas de código.
Apalancamiento. Casi todo lo que hay, desde sistemas de control de revisiones hasta editores y filtros, puede inspeccionar, fusionar y operar en archivos planos. Combinar XML puede ser un desastre.
Capacidad para integrarlos con bastante facilidad con herramientas UNIX, como grep, cut o sed.

Es una buena pregunta. FWIW, me encantaría ver una herramienta de administración de código estilo Wiki. Cada unidad funcional tendría su propia página wiki. Las herramientas de compilación extraen el código fuente de la wiki. Habría un & Quot; discutir & Quot; página vinculada a esa página, donde las personas pueden discutir sobre algoritmos, API y similares.

Diablos, no sería tan difícil hackear uno de una implementación de Wiki preexistente. ¿Algún tomador ...?

Irónicamente, hay construcciones de programación que usan precisamente lo que usted describe.

Por ejemplo, los Servicios de integración de SQL Server, que implican codificar el flujo lógico arrastrando componentes a una superficie de diseño visual, se guardan como archivos XML que describen precisamente ese back-end.

Por otro lado, SSIS es bastante difícil de controlar en la fuente. También es bastante difícil diseñar cualquier tipo de lógica compleja en él: si necesita un poco más & Quot; control & Quot ;, necesitará codificar el código VB.NET en el componente, lo que trae volver a donde comenzamos.

Supongo que, como codificador, debes considerar el hecho de que por cada solución a un problema hay consecuencias que siguen. No todo podría (y algunos argumentan, debería) estar representado en UML. No todo se puede representar visualmente. No todo podría simplificarse lo suficiente como para tener una representación de archivo binario consistente.

Dicho esto, diría que las desventajas de relegar el código a formatos binarios (la mayoría de los cuales también tenderán a ser propietarios) superan con creces las ventajas de tenerlos en texto plano.

En mi humilde opinión, los formatos XML y binario serían un desastre total y no darían ningún beneficio significativo.

OTOH, una idea relacionada sería escribir en una base de datos, tal vez una función por registro, o tal vez una estructura jerárquica. Un IDE creado en torno a este concepto podría hacer que la fuente de navegación sea más natural y más fácil de ocultar cualquier cosa que no sea relevante para el código que está leyendo en un momento dado.

Las personas han intentado durante mucho tiempo crear un entorno de edición que va más allá del archivo plano y todos han fallado en cierta medida. Lo más cercano que he visto fue un prototipo para la Programación intencional de Charles Simonyi, pero luego se redujo a una herramienta de creación visual DSL.

No importa cómo se almacene o represente el código en la memoria, al final tiene que ser presentable y modificable como texto ( sin que el formato cambie en usted ) ya que esa es la forma más fácil que sabemos. Expresar la mayoría de los conceptos abstractos necesarios para resolver problemas mediante programación.

Con archivos planos obtienes esto de forma gratuita y cualquier editor de texto antiguo (con el soporte de codificación de caracteres correcto) funcionará.

Steve McConnell tiene razón, como siempre: escribe programas para otros programadores (incluido usted), no para computadoras.

Dicho esto, Microsoft Visual Studio debe administrar internamente el código que escribe en un formato muy estructurado, o no podrá hacer cosas como " Buscar todas las referencias " o renombrar o re-factorizar variables y métodos tan fácilmente. Me interesaría si alguien tuviera enlaces sobre cómo funciona esto.

En realidad, hace aproximadamente 10 años, el primer prototipo de Charles Simonyi para programación intencional intentó ir más allá del archivo plano en una representación de código de árbol que se puede visualizar de diferentes maneras. Teóricamente, un experto en dominios, un primer ministro y un ingeniero de software podrían ver (y armar) el código de la aplicación de una manera que les fuera útil, y los productos podrían construirse en una jerarquía de & Quot; intenciones declarativas & "; excavar a código de bajo nivel solo cuando sea necesario.

ETA (por solicitud en las preguntas) Hay una copia de uno de sus primeros artículos sobre esto en el sitio web de investigación de Microsoft. Desafortunadamente, desde que Simonyi dejó MS para comenzar una compañía separada hace varios años, no creo que el prototipo todavía esté disponible para descargar. Vi algunas demostraciones cuando estaba en Microsoft, pero no estoy seguro de cuán ampliamente se distribuyó su primer prototipo.

Su compañía, IntentSoft todavía está un poco callada sobre lo que planean entregar al mercado , en todo caso, pero algunas de las primeras cosas que salieron de MSR fueron bastante interesantes.

El modelo de almacenamiento tenía algún formato binario, pero no estoy seguro de cuántos de esos detalles se revelaron durante el proyecto MSR, y estoy seguro de que algunas cosas han cambiado desde las primeras implementaciones.

¿Por qué gobiernan los archivos de texto? Por la prueba de McIlroy. Es vital que la salida de un programa sea aceptable como el código fuente de otro, y los archivos de texto son lo más simple que funciona.

Labview y Simulink son dos entornos de programación gráfica. Ambos son populares en sus campos (interfaz al hardware desde una PC y sistemas de control de modelado, respectivamente), pero no se usan mucho fuera de esos campos. He trabajado con personas que eran grandes admiradores de ambos, pero nunca me metí en ellos.

Usted menciona que deberíamos usar " alguna forma de XML " ;? ¿Qué crees que son XHTML y XAML?

También XML sigue siendo solo un archivo plano.

Los viejos hábitos tardan en morir, supongo.

Hasta hace poco, no había muchas bibliotecas de buena calidad, alto rendimiento y ampliamente disponibles para el almacenamiento general de datos estructurados. Y enfáticamente no pondría XML en esa categoría incluso hoy en día: demasiado detallado, demasiado intenso para procesar, demasiado meticuloso.

Hoy en día, lo que más me gusta usar para datos que no necesitan ser legibles para humanos es SQLite y hacer un base de datos. Es increíblemente fácil incrustar una base de datos SQL con todas las funciones en cualquier aplicación ... hay enlaces para C, Perl, Python, PHP, etc ... y es de código abierto y realmente rápido, confiable y liviano.

I < 3 SQLite.

Cualquiera ha intentado Mathematica ?

La imagen de arriba es de una versión anterior, pero fue lo mejor que Google me pudo dar.

De todos modos ... compare la primera ecuación allí con Math.Integrate (1 / (Math.Pow (" x ", 3) -1), " x ") como si tuviera que escribir si estuviera codificando con texto sin formato en los idiomas más comunes. Imo, la representación matemática es mucho más fácil de leer, y esa sigue siendo una ecuación bastante pequeña.

Y sí, puede ingresar y copiar y pegar el código como texto sin formato si lo desea.

Véalo como la próxima generación de resaltado de sintaxis . Apuesto a que hay muchas otras cosas además de las matemáticas que podrían beneficiarse de este tipo de representación.

Es bastante obvio por qué el texto plano es el rey. Pero es igualmente obvio por qué un formato estructurado sería aún mejor.

Solo un ejemplo: si cambia el nombre de un método, su herramienta de control diff / merge / source podría decir que solo una cosa ha cambiado. Las herramientas que utilizamos hoy mostrarían una larga lista de cambios, uno para cada lugar y archivo al que se llamó o declaró el método.

(Por cierto, esta publicación no responde la pregunta como habrás notado)

La tendencia que estamos viendo acerca de las DSL es lo primero que viene a la mente al leer su pregunta. El problema ha sido que no existe una relación de 1 a 1 entre modelos (como UML) y una implementación. Microsoft, entre otros, está trabajando para llegar allí, de modo que pueda crear su aplicación como algo similar a UML, luego se puede generar el código. Y lo importante: al optar por cambiar su código, el modelo lo reflejará nuevamente.

Windows Workflow Foundation es un buen ejemplo. De hecho, hay archivos planos y / o XML en segundo plano, pero generalmente terminas definiendo tu lógica de negocios en la herramienta de orquestación. ¡Y eso es genial!

Necesitamos más de las " fábricas de software " pensando, y veremos una experiencia IDE más rica en el futuro, pero mientras las computadoras funcionen con ceros y unos, los archivos de texto plano pueden y (probablemente) siempre serán una etapa intermedia. Como ya se mencionó, varias personas, los archivos de texto simples son muy flexibles.

Me he preguntado melancólicamente lo mismo, como se describe en la respuesta a: ¿Qué herramienta / aplicación / lo que desea que haya existido?

Si bien es fácil imaginar una gran cantidad de beneficios, creo que el mayor obstáculo que debería abordarse es que nadie ha producido una alternativa viable.

Cuando las personas piensan en alternativas para almacenar la fuente como texto, a menudo parecen pensar inmediatamente en términos de representaciones gráficas (me refiero aquí a los productos comerciales que han estado disponibles, por ejemplo, HP-vee). Y si observamos la experiencia de personas como los diseñadores de FPGA, vemos que la programación (exclusivamente) gráfica simplemente no funciona, de ahí lenguajes como Verilog y VHDL.

Pero no veo que el almacenamiento de la fuente necesariamente deba estar vinculado al método de escritura en primer lugar. La entrada de la fuente puede hacerse en gran medida como texto, lo que significa que los problemas de copia / pegado aún pueden lograrse. Pero también veo que al permitir que se hagan fusiones y retrocesos sobre la base de una meta-fuente tokenizada, podríamos lograr herramientas de manipulación más precisas y potentes.

Visual FoxPro utiliza estructuras de tabla dbf para almacenar código y metadatos para formularios, informes, bibliotecas de clases, etc. Estos son archivos binarios. También almacena código en archivos prg que archivos de texto reales ...

La única ventaja que veo es poder usar el lenguaje de datos VFP incorporado para realizar búsquedas de código en esos archivos ... aparte de eso, es una responsabilidad imo. Al menos una vez cada pocos meses, uno de estos archivos se corromperá sin razón aparente. La integración con el control de origen y las diferencias también son muy dolorosas. Hay soluciones para esto, ¡pero implica convertir el archivo a texto temporalmente!

Para ver un ejemplo de un lenguaje que elimina la programación de texto tradicional, consulte Lava Idioma .

Otra cosa ingeniosa que descubrí recientemente es subtext2 ( demostración de video ).

El código de su programa define la estructura que se crearía con xml o el formato binario. Su lenguaje de programación es una representación más directa de la estructura de su programa que una representación XML o Binaria. ¿Alguna vez has notado cómo Word se porta mal cuando le das estructura a tu documento? WordPerfect al menos 'revelaría códigos' para permitirle ver lo que hay debajo de su documento. Los archivos planos hacen lo mismo para su programa.

Buena idea. Me he preguntado a menor escala ... mucho más pequeño, ¿por qué IDE X no puede generar esto o aquello?

No sé si soy capaz como programador para desarrollar algo tan genial y complejo como lo que estás hablando o sobre lo que estoy pensando, pero me interesaría intentarlo.

¿Quizás comenzar con algunos complementos para .NET, Eclipse, Netbeans, etc.? Muestre lo que se puede hacer y comience una nueva tendencia en la codificación.

Creo que otro aspecto de esto es que el código es lo importante. Es lo que se va a ejecutar. Por ejemplo, en su ejemplo de UML, creo que en lugar de tener UML (presumiblemente creado en algún editor, no relacionado directamente con el & Quot; código & Quot;) incluido en su & Quot; blob fuente < !> quot; Sería casi inútil. Mucho mejor sería tener el UML generado directamente a partir de su código, por lo que describe el estado exacto en el que se encuentra el código como una herramienta para comprender el código, en lugar de como un recordatorio de lo que debería haber sido el código.

Hemos estado haciendo esto durante años con respecto a las herramientas de documentación automatizadas. Si bien el programador real generó comentarios en el código que podrían no estar sincronizados con el código, las herramientas como JavaDoc y similares representan fielmente los métodos en un objeto, tipos de retorno, argumentos, etc. Los representan como realmente existen, no como algunos artefacto que surgió de un sinfín de reuniones de diseño.

Me parece que si pudiera agregar arbitrariamente artefactos aleatorios a algunos & "; fuente blob &"; estos probablemente estarían desactualizados y serían menos útiles de inmediato. Si puede generar tales artefactos directamente desde el código, entonces el pequeño esfuerzo para lograr que su proceso de compilación lo haga es mucho mejor que las dificultades mencionadas anteriormente de alejarse de los archivos fuente de texto sin formato.

Relacionado con esto, una explicación de por qué Me gustaría utilizar una herramienta UML de texto sin formato ( UMLGraph ) parece aplicarse casi por igual así como por qué quieres archivos fuente de texto plano.

Esto podría no responder exactamente a su pregunta, pero aquí hay un editor que permite tener una vista más alta del código: http://webpages.charter.net/edreamleo/front.html

Creo que la razón de por qué los archivos de texto se usan en el desarrollo es que son universales frente a varias herramientas de desarrollo. Puede mirar dentro o incluso corregir algunos errores usando un editor de texto simple (no puede hacerlo en un archivo binario porque nunca sabe cómo una solución destruiría otros datos). Sin embargo, no significa que los archivos de texto sean mejores para todos esos fines.

Por supuesto, puede diferenciarlos y fusionarlos. Pero eso no significa que la herramienta diff / merge entienda la estructura distintiva de los datos codificados por este archivo de texto. Puede hacer el diff / merge, pero (especialmente visto en archivos XML) la herramienta diff no le mostrará las diferencias correctamente, es decir, le mostrará dónde difieren los archivos y qué partes de los datos la herramienta " piensa " son lo mismo. Pero no le mostrará las diferencias en la estructura del archivo XML, solo coincidirá con las líneas que se ven iguales.

Independientemente de si estamos usando archivos binarios o archivos de texto, siempre es mejor que las herramientas de diferenciación / fusión cuiden la estructura de datos que este archivo representa en lugar de las líneas y caracteres. Para archivos C ++ o Java, por ejemplo, informe que algún identificador cambió su nombre, informe que alguna sección estaba rodeada de if () {} adicional, pero, por otro lado, ignore los cambios en las sangrías o los caracteres EOL. El mejor enfoque sería que un archivo se lea en estructuras internas y se descargue utilizando reglas de formato específicas. De esta forma, la diferencia se realizará a través de las estructuras internas y el resultado de la fusión se generará a partir de la estructura interna fusionada.

Los programas modernos están compuestos de piezas planas, pero ¿son planas? Hay usos, e incluye, y bibliotecas de objetos, etc. Una llamada de función ordinaria es un vistazo a un lugar diferente. La lógica no es plana, debido a que tiene múltiples hilos, etc.

¡Tengo la misma visión! Realmente deseo que esto exista.

Es posible que desee echar un vistazo a Fortress, un lenguaje de investigación de Sun. Tiene soporte especial para fórmulas en código fuente. La cita a continuación es de Wikipedia

Fortress está siendo diseñado desde comenzar a tener múltiples sintácticos hojas de estilo El código fuente puede ser renderizado como texto ASCII, en Unicode, o como una imagen bonita Esto permitira para soporte de símbolos matemáticos y otros símbolos en el renderizado salida para facilitar la lectura.

La razón principal de la persistencia del texto como fuente es la falta de herramientas eléctricas, como por ejemplo el control de versiones, para la fecha sin texto. Esto se basa en mi experiencia trabajando con Smalltalk, donde el código de bytes simple se mantiene en un volcado de núcleo todo el tiempo. En un sistema sin texto, con las herramientas actuales, el desarrollo del equipo es una pesadilla.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow