flat file - txt - ¿Por qué todavía programamos con archivos planos?
que es un archivo plano (30)
¿Alguien alguna vez ha probado Mathematica ?
La imagen de arriba es de una versión anterior, pero fue la mejor que google me pudo dar.
De todos modos ... compare la primera ecuación de Math.Integrate (1 / (Math.Pow ("x", 3) -1), "x") como si tuviera que escribir si estaba codificando con texto sin formato en la mayoría lenguajes 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 el resaltado de sintaxis de la próxima generación. Apuesto a que hay muchas otras cosas además de las matemáticas que podrían beneficiarse de este tipo de representación.
¿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 XML o datos binarios podría representar muchas ideas que son muy difíciles de rastrear, de lo contrario.
Por ejemplo, puede insertar diagramas UML directamente en su código. Podrían generarse de forma semiautomática y anotarse por los desarrolladores para resaltar aspectos importantes del diseño. Diagramas de interacción en particular. Diablos, incrustar cualquier dibujo del usuario podría aclarar las cosas.
Otra idea es insertar comentarios de revisiones de código directamente en el código.
Podría haber todo tipo de ayudas para facilitar la fusión de múltiples ramas.
Algo que me apasiona no es solo la cobertura del código de seguimiento, sino también las partes del código que cubre una prueba automatizada. La parte difícil es hacer 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 GUIDs, 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 permiten trabajar con el código de esta manera?
EDITAR: El 7 de octubre de 2009.
La mayoría de ustedes se obsesionó mucho con la palabra "binario" en mi pregunta. Me retracto. Picture XML, marcando muy poco tu código. El instante antes de entregarlo a su preprocesador o compilador normal, elimina todas las marcas XML y solo transmite 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í, el diff, merge y edit, directamente con el mínimo XML markup, se vuelve un poco más complicado. Pero creo que el valor puede 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, tus comentarios de DOxygen podrían verse como la salida final de DOxygen.
Cuando alguien quería hacer una revisión del código, como Code Collaborator, podían marcar el código fuente, en su lugar.
El XML incluso podría estar oculto 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 aproximadamente una docena de maneras útiles diferentes.
Entonces, esa es mi idea aproximada. No son "bloques de construcción" de imágenes que arrastra en la pantalla ... No estoy tan loco. :)
¿Menciona que deberíamos usar "alguna forma de XML"? ¿Qué crees que XHTML y XAML son?
Además, XML sigue siendo solo un archivo plano.
¿Por qué los archivos de texto gobiernan? 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.
¿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 la forma en que las personas piensan, representan, comprenden y persisten los conceptos , y sus complejidades, jerarquías e interrelaciones.
<? xml version = "1.0" encoding = "UTF-8"?> <code> Los archivos planos son más fáciles de leer. </ code> </ xml>
Creo que la razón de por qué los archivos de texto se utilizan en el desarrollo es que son universales contra varias herramientas de desarrollo. Puedes mirar dentro o incluso corregir algunos errores usando un editor de texto simple (no puedes hacerlo en un archivo binario porque nunca sabes cómo cualquier solución destruiría otros datos). Sin embargo, esto no significa que los archivos de texto sean los mejores para todos esos propósitos.
Por supuesto, puedes diferenciarlos y fusionarlos. Pero esto no significa que la herramienta diff / merge comprenda la estructura distinta 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 "piensa" la herramienta. son lo mismo. Pero no le mostrará las diferencias en la estructura del archivo XML, simplemente coincidirá con las líneas que parecen iguales.
Independientemente de si estamos utilizando archivos binarios o archivos de texto, siempre es mejor que las herramientas diff / merge se ocupen de la estructura de datos que representa este archivo en lugar de las líneas y los caracteres. Para archivos C ++ o Java, por ejemplo, informe que algún identificador cambió su nombre, informa que alguna sección estaba rodeada con if () {} adicional, pero, por otro lado, ignora los cambios en sangrías o caracteres EOL. El mejor enfoque sería que un archivo se lea en estructuras internas y se descargue usando 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.
Creo que otro aspecto de esto es que el código es lo que es importante. Es lo que se va a ejecutar. Por ejemplo, en tu ejemplo de UML, pensaría que en lugar de tener UML (presumiblemente creado en algún editor, no relacionado directamente con el "código") incluido en tu "fuente de blob" sería casi inútil. Mucho mejor sería tener el UML generado directamente desde su código, por lo que describe el estado exacto en que se encuentra el código como una herramienta para entender el código, en lugar de un recordatorio de lo que el código debería haber sido.
Hemos estado haciendo esto durante años con respecto a las herramientas de doc automatizadas. Si bien el programador actual generó comentarios en el código que podrían no estar sincronizados con el código, 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 interminables reuniones de diseño.
Me parece que si pudiera agregar arbitrariamente artefactos aleatorios a algún "blob de origen", estos probablemente estarían desactualizados y serían menos que útiles de inmediato. Si puede generar dichos 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 trampas mencionadas anteriormente de alejarse de los archivos fuente de texto sin formato.
Relacionado con esto, una explicación de por qué querría usar una herramienta UML de texto sin formato ( UMLGraph ) parece aplicarse casi igualmente al motivo por el que quiere archivos de texto sin formato.
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 de lo que sería una representación XML o binaria. ¿Alguna vez notó cómo Word se comporta mal con usted al darle estructura a su 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.
En mi humilde opinión, XML y formatos binarios sería un desastre total y no daría 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 puede hacer que la fuente de navegación sea más natural y más fácil ocultar todo lo que no sea relevante para el código que está leyendo en un momento dado.
En mi opinión, cualquier posible beneficio se ve superado por estar vinculado a una herramienta en particular.
Con fuente de texto plano (que parece ser lo que estás discutiendo, en lugar de archivos planos per se) puedo pegar trozos en un correo electrónico, usar sistemas simples de control de versiones (¡muy importante!), Escribir código en comentarios en Desbordamiento de pila, utilice uno de los miles de 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 trivialmente deshacer los cambios en la versión canónica.
En realidad, hace aproximadamente 10 años, el prototipo inicial de Charles Simonyi para la programación intencional intentó ir más allá del archivo plano en una representación en árbol de código que se puede visualizar de diferentes maneras. Teóricamente, un experto en dominio, un PM y un ingeniero de software podrían ver (y armar) el código de la aplicación de forma que les resultara útil, y los productos podrían construirse sobre una jerarquía de "intenciones" declarativas, cavando a niveles bajos. código de nivel solo según sea necesario.
ETA (por solicitud en las preguntas) Hay una copia de uno de sus primeros trabajos 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 su descarga. Vi algunas demos cuando estaba en Microsoft, pero no estoy seguro de cuánto se distribuyó su prototipo inicial.
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.
Es bastante obvio por qué el texto simple 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á decir que solo una cosa ha cambiado. Las herramientas que usamos hoy mostrarían una larga lista de cambios, uno por cada lugar y archivo que el método fue llamado o declarado.
(Por cierto, esta publicación no responde la pregunta como habrás notado)
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 juntan el código fuente fuera de la wiki. Habría una página de "discusión" vinculada a esa página, donde las personas pueden discutir sobre algoritmos, API y cosas por el estilo.
Diablos, no sería tan difícil piratear uno de una implementación de Wiki preexistente. Ningún arrendatario...?
Este es el por qué:
Humano legible 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. Es uno que no se puede obtener con XML, y puede marcar la diferencia, especialmente en la atención al cliente.
Seguro contra la obsolescencia. Mientras exista la expresión regular, es posible escribir un analizador bastante bueno en unas pocas líneas de código.
Apalancamiento. Casi todo lo que hay, desde los sistemas de control de revisiones hasta los editores para filtrar, puede inspeccionar, fusionar y operar archivos planos. Combinar XML puede ser un desastre.
Posibilidad de integrarlos fácilmente con las herramientas de UNIX, como grep, cut o sed.
Irónicamente, existen construcciones de programación que usan exactamente lo que describes.
Por ejemplo, los servicios de integración de SQL Server, que implican la codificación del flujo lógico mediante el arrastre de componentes en 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 desde la fuente. También es bastante difícil diseñar cualquier clase de lógica compleja: si necesita un poco más de "control", necesitará codificar el código VB.NET en el componente, lo que nos lleva de vuelta al punto de partida.
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ían) representarse en UML. No todo podría ser representado visualmente. No todo podría simplificarse lo suficiente como para tener una representación de archivo binario consistente.
Una vez dicho esto, postularí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.
La gente ha intentado durante mucho tiempo crear un entorno de edición que va más allá del archivo plano y todos han fallado hasta cierto punto. Lo más parecido que he visto fue un prototipo para la Programación intencional de Charles Simonyi, pero luego lo degradaron a una herramienta visual de creación de DSL.
No importa cómo se almacena o representa el código en la memoria, al final tiene que ser presentable y modificable como texto ( sin que el formato cambie ) ya que esa es la manera más fácil que tenemos de expresar la mayoría de los conceptos abstractos que se necesitan para resolviendo problemas por programación.
Con los archivos planos obtienes esto de forma gratuita y cualquier editor de texto simple (con la compatibilidad de codificación de caracteres correcta) funcionará.
La tendencia que estamos viendo sobre DSL es lo primero que se le ocurre al leer su pregunta. El problema ha sido que no existe una relación de 1 a 1 entre los modelos (como UML) y una implementación. Microsoft, entre otros, están trabajando para llegar allí, para que pueda crear su aplicación como algo similar a un UML, luego se puede generar el código. Y lo importante: al optar por cambiar su código, el modelo lo reflejará de nuevo.
Windows Workflow Foundation es un buen ejemplo. Debido a que hay archivos planos y / o XML en segundo plano, generalmente termina definiendo su lógica comercial en la herramienta de orquestación. ¡Y eso es genial!
Necesitamos más del pensamiento de "fábricas de software", 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 ha dicho, varias personas, los archivos de texto simples son muy flexibles.
Los programas Lisp no son archivos planos. Son serialización de estructuras de datos. Este código como datos es una vieja idea, y en realidad una de las mejores ideas en ciencias de la computación.
Los programas modernos están compuestos de piezas planas, pero ¿son planos? 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 tener múltiples hilos, etc.
Los viejos hábitos se mueren duro, 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, mi elemento favorito para usar en datos que no necesitan ser legibles por humanos es SQLite y hacer una base de datos. Es increíblemente fácil incorporar 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, muy rápido, confiable y liviano.
I <3 SQLite.
Puede que esto no responda exactamente 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
Smalltalk es un entorno basado en imágenes. Ya no está trabajando con el código en un archivo en el disco. Está trabajando con 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 de objeto (la imagen) se almacena en un archivo en formato binario.
Pero las mayores quejas de quienes prueban smalltalk es que no usan archivos. La mayoría de las herramientas basadas en archivos que tenemos (vim, emacs, eclipse, vsnet, herramientas de Unix) tendrán que ser abandonadas a favor de las herramientas de smalltalk. No es que las herramientas proporcionadas en smalltalk en inferior. Es simplemente diferente.
Steve McConnell tiene razón, como siempre, usted escribe programas para otros programadores (incluyéndose a 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ía hacer cosas como "Buscar todas las referencias" o cambiar el nombre o volver a factorizar variables y métodos tan fácilmente. Me interesaría si alguien tuviera enlaces a cómo funciona esto.
Una buena idea. Me he preguntado en una escala más pequeña ... mucho más pequeña, ¿por qué IDE X no puede generar esto o aquello?
No sé si todavía soy capaz como programador para desarrollar algo tan genial y complejo como tu forma de hablar o en lo que estoy pensando, pero me gustaría intentarlo.
¿Tal vez comenzar con algunos complementos para .NET, Eclipse, Netbeans, etc.? Muestre lo que se puede hacer e inicie una nueva tendencia en la codificación.
Labview y Simulink son dos entornos de programación gráfica. Ambos son populares en sus campos (interconectados con hardware de 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 admiradoras de ambos, pero nunca me metí en ellas.
- puedes diferenciarlos
- puedes unirlos
- cualquiera puede editarlos
- son simples y fáciles de tratar
- son accesibles universalmente para miles de herramientas
¡Tengo la misma visión! Realmente desearía que esto existiera.
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 siguiente cita es de Wikipedia
Fortress está siendo diseñado desde el principio para tener varias hojas de estilo sintácticas. El código fuente se puede representar como texto ASCII, en Unicode o como una imagen preciada. Esto permitirá el soporte de símbolos matemáticos y otros símbolos en la salida representada 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 fechas sin texto. Esto se basa en mi experiencia trabajando con Smalltalk, donde el código de bytes simple se mantiene en un núcleo de volcado todo el tiempo. En un sistema que no es de texto, con las herramientas de hoy, el desarrollo del equipo es una pesadilla.
Visual FoxPro utiliza estructuras de tablas 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 utilizar el lenguaje de datos VFP incorporado para realizar búsquedas de códigos en esos archivos ... aparte de eso, es un inconveniente de responsabilidad. Al menos una vez cada pocos meses, uno de estos archivos se dañará sin motivo aparente. La integración con el control de origen y las diferencias también son muy dolorosas. Hay soluciones para esto, pero implica convertir temporalmente el archivo a texto.
Para ver un ejemplo de un lenguaje que elimina la programación de texto tradicional, consulte el lenguaje Lava .
Otra cosa ingeniosa que acabo de descubrir es subtext2 ( video demo ).
Me he preguntado, anhelante, lo mismo, como se describe en la respuesta a: ¿Qué herramienta / aplicación / qué es lo que deseas que exista?
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 fuentes 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áficamente simplemente no funciona, por lo tanto, idiomas como Verilog y VHDL.
Pero no veo que el almacenamiento de la fuente necesariamente tenga que estar ligado al método de escritura en primer lugar. La entrada de la fuente se puede hacer en gran parte como texto, lo que significa que aún se pueden lograr los problemas de copiar / pegar. Pero también veo que al permitir que las fusiones y retrocesos se realicen sobre la base de meta-fuente tokenizada, podríamos lograr herramientas de manipulación más precisas y potentes.