Por que ainda programar com arquivos simples? [fechadas]

https://stackoverflow.com/questions/160633

flat-file

03-07-2019
|

Pergunta

Por que texto simples arquiva o estado da arte para representar o código fonte?

Claro -. O pré-processador e o compilador necessidade de ver uma representação arquivo simples do arquivo, mas que é facilmente criado

Parece-me que alguma forma de dados XML ou binários poderia representar muitas idéias que são muito difíceis de controlar, de outra forma.

Por exemplo, você poderia incorporar diagramas UML para a direita em seu código. Eles poderiam ser gerados semi-automaticamente, e anotado pelos desenvolvedores para destacar aspectos importantes do design. diagramas de interacção em particular. Heck, a incorporação de qualquer desenho do usuário pode tornar as coisas mais claras.

Outra ideia é a comentários embed do revisões de código para a direita no código.

Pode haver todos os tipos de ajudas para fazer fusão de várias filiais mais fácil.

Algo que eu sou apaixonado não é apenas rastreamento de cobertura de código, mas também olhar para as partes de código cobertos por um teste automatizado. A parte mais difícil é manter o controle do mesmo código, mesmo que a fonte seja modificada. Por exemplo, mover uma função de um arquivo para outro, etc. Isso pode ser feito com GUIDs, mas eles são bastante intrusiva para a direita incorporar no arquivo de texto. Em um formato de arquivo rico, eles poderiam ser automático e discreto.

Então, Por que não há IDEs (a meu conhecimento, de qualquer maneira), que permitem que você trabalhe com o código desta forma?

EDIT: 7º Em outubro de 2009

A maioria de vocês foi muito desligou na palavra "binária" na minha pergunta. Eu recolhê-lo. Imagem XML, muito minimamente a marcação de seu código. No instante antes de entregá-lo para o seu pré-processador normal ou compilador, você tira toda a marcação XML, e passar apenas o código-fonte. Nesta forma, você ainda pode fazer todas as coisas normais para o arquivo: diff, merge, editar o trabalho com de forma simples e editor mínimo, alimentá-los em milhares de ferramentas. Sim, o diff, merge, e editar, diretamente com a marcação XML mínima, fica um pouco mais complicado. Mas eu acho que o valor poderia ser enorme.

Se um IDE existia que respeitava todo o XML, você pode adicionar muito mais do que o que podemos fazer hoje.

Por exemplo, seus comentários doxygen poderia realmente olhar como a saída doxygen final.

Quando alguém queria fazer uma revisão de código, como Código Colaborador, eles poderiam marcar o código-fonte, no lugar.

O XML poderia até ser escondida atrás de comentários.

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

E então se você quiser usar vi ou emacs, você pode simplesmente ignorar os comentários.

Se eu quiser usar um editor de state-of-the-art, eu posso ver que em cerca de uma dúzia de diferentes maneiras úteis.

Então, essa é a minha idéia aproximada. Não é "blocos de construção" de fotos que você arrasta na tela ... Eu não sou tão louco. :)

Solução

você pode diff-los
você pode fundi-los
qualquer um pode editá-los
eles são simples e fáceis de lidar
são universalmente acessível a milhares de ferramentas

Outras dicas

Na minha opinião, eventuais benefícios são contrabalançados por estar vinculado a uma determinada ferramenta.

Com fonte de texto simples (que parece ser o que você está discutindo, em vez de flat files per se) I pode colar os pedaços em um email, usar sistemas de controle de versão simples (muito importante! ), escrever código para comentários sobre estouro de pilha, utilize um dos milhares de editores de texto em qualquer número de plataformas, etc.

Com alguma representação binária do código, eu preciso usar um editor especializado para ver ou editar isso. Mesmo se uma representação baseada em texto pode ser produzido, você não pode trivialmente reverter as alterações para a versão canônica.

Smalltalk é um ambiente baseado em imagem. Você não está mais trabalhando com o código em um arquivo no disco. Você está trabalhando com e modificar os objetos reais em tempo de execução. Ainda é texto, mas as aulas não são armazenados em arquivos legíveis. Em vez disso toda a memória objeto (a imagem) é armazenado em um arquivo no formato binário.

Mas as maiores queixas daqueles experimentar Smalltalk é porque ele não usa arquivos. A maioria das ferramentas baseadas em arquivos que temos (vim, emacs, eclipse, vs.net, ferramentas Unix) terá de ser abandonado em favor das próprias ferramentas do Smalltalk. Não que as ferramentas fornecidas no smalltalk na inferior. É apenas diferente.

Por que são ensaios escrito no texto? Por que são documentos legais escrito no texto? Por que são romances de fantasia escrito no texto? Porque o texto é a única melhor forma - para as pessoas -. De persistir seus pensamentos

O texto é como as pessoas pensam, representam, entender e persistem conceitos -. E suas complexidades, hierarquias e inter-relações

programas Lisp não são arquivos simples. Eles são serialização de estruturas de dados. Este código-as-dados é uma ideia antiga, e, na verdade, um dos maiores idéia em ciência da computação.

Arquivos simples são mais fáceis de ler.

Aqui está o porquê:

legível. Isso faz muito mais fácil de detectar um erro, tanto no arquivo eo método de análise. Também pode ser lida em voz alta. Essa é uma que você simplesmente não pode obter com XML, e pode fazer a diferença, especialmente no apoio ao cliente.
Seguro contra a obsolescência. Enquanto existirem regex, é possível escrever um parser muito bom em apenas algumas linhas de código.
A alavancagem. Quase tudo o que há, de sistemas de controle de revisão para os editores de filtro, pode inspecionar, merge e operar em arquivos simples. Mesclando XML pode ser uma bagunça.
Capacidade de integrá-los com bastante facilidade com ferramentas UNIX, como grep, corte ou sed.

É uma boa pergunta. FWIW, eu adoraria ver uma ferramenta de gerenciamento de código Wiki-estilo. Cada unidade funcional teria sua própria página wiki. As ferramentas de compilação reunir o código-fonte para fora do wiki. Haveria um "discutir" página vinculada a essa página, onde as pessoas podem discutir sobre algoritmos, APIs e tal como o.

Heck, não seria tão difícil de cortar um acima de uma implementação pré-existente Wiki. Todos os compradores ...?

Ironicamente, existem construções que usam exatamente o que você descreve a programação.

Por exemplo, SQL Server Integration Services, que envolvem codificação fluxo lógico arrastando componentes em uma superfície de design visual, são salvos como arquivos XML que descrevem precisamente o back-end.

Por outro SSIS mão é muito difícil de fonte-controle. Também é bastante difícil projetar qualquer tipo de lógica complexa para ele: se você precisa de um pouco mais "controle", você precisa de código VB.NET código para o componente, o que nos volta para onde começamos.

Eu acho que, como um programador, você deve considerar o fato de que para cada solução para um problema há conseqüências que se seguem. Nem tudo pode (e alguns argumentam, deve) ser representado em UML. Nem tudo pode ser representado visualmente. Nem tudo poderia ser simplificado o suficiente para ter uma representação arquivo binário consistente.

Dito isto, gostaria de postular que as desvantagens de relegando código para formatos binários (a maioria dos quais também tendem a ser proprietária) longe sobrelevar as vantagens de tê-los em texto simples.

IMHO, XML e formatos binários seria uma bagunça total e não daria qualquer benefício significativo.

OTOH, uma idéia relacionada seria escrever em um banco de dados, talvez uma função por registro, ou talvez uma estrutura hierárquica. Um IDE criado em torno deste conceito poderia tornar a navegação fonte mais natural e mais fácil de esconder nada não é relevante para o código que você está lendo em um dado momento.

As pessoas têm tentado por um longo tempo para criar um ambiente de edição que vai além do arquivo simples e todo mundo falhou em certa medida. O mais próximo que eu vi foi um protótipo de programação intencional de Charles Simonyi, mas depois que foi rebaixado para uma ferramenta de criação de DSL visual.

Não importa como o código é armazenado ou representados na memória, no final, tem que ser apresentável e modificáveis ??como texto ( sem a formatação mudando em você ) uma vez que é a maneira mais fácil que sabemos expressar a maioria dos conceitos abstratos que são necessários para resolver os problemas de programação.

Com arquivos simples você receber esse grátis e qualquer editor de texto velho liso (com o suporte correto codificação de caracteres) funcionará.

Steve McConnell tem direito, como sempre -. Você escrever programas para outros programadores (incluindo você), não para computadores

Dito isto, Microsoft Visual Studio tem de gerir internamente o código que você escreve em um formato muito estruturado, ou você não seria capaz de fazer coisas como "Localizar todas as referências" ou variáveis ??renomear ou re-factor e métodos tão prontamente . Eu estaria interessado se alguém tinha links para como isso funciona.

Na verdade, cerca de 10 anos atrás, protótipo de Charles Simonyi para a programação intencional tentativa de ir além do arquivo simples em uma representação de árvore de código que pode ser visualizado de diferentes maneiras. Teoricamente, um especialista de domínio, um PM e um engenheiro de software tudo poderia ver (e peça juntos) código da aplicação de maneiras que eram úteis para eles, e produtos poderiam ser desenvolvidas a partir de uma hierarquia de "intenções" declarativas, cavando para baixo para baixo código de nível somente quando necessário.

ETA (por solicitação nas questões) Há uma cópia do um de seus primeiros papéis sobre isso no web site de pesquisa da Microsoft. Infelizmente, desde que Simonyi deixou MS para começar uma empresa separada há vários anos, eu não acho que o protótipo ainda está disponível para download. Eu vi algumas demos de volta quando eu estava na Microsoft, mas não tenho certeza de como amplamente o seu protótipo inicial foi distribuída.

Sua empresa, a IntentSoft ainda é um pouco quieto sobre o que eles estão planejando para entregar ao mercado , se alguma coisa, mas algumas das coisas mais cedo que saiu da MSR foi bastante interessante.

O modelo de armazenamento era algum formato binário, mas não tenho certeza quanto desses detalhes foram divulgados durante o projeto MSR, e tenho certeza que algumas coisas mudaram desde o início implementações.

Por que regra arquivos de texto? Por causa do teste de McIlroy. É vital ter a saída de um programa ser aceitável como o código-fonte para outra, e arquivos de texto são a coisa mais simples que funciona.

Labview e Simulink são dois ambientes de programação gráfica. Eles são populares em seus campos (interface de hardware a partir de um PC, e modelagem de sistemas de controle, respectivamente), mas não muito usado fora desses campos. Eu já trabalhei com pessoas que eram grandes fãs de ambos, mas nunca entrou em-los eu mesmo.

Você menciona que devemos usar "alguma forma de XML"? O que você acha XHTML e XAML são?

Além disso XML ainda é apenas um arquivo simples.

Os velhos hábitos custam a morrer, eu acho.

Até recentemente, não havia muitos de boa qualidade, de alto desempenho, bibliotecas amplamente disponíveis para armazenamento geral de dados estruturados. E eu enfaticamente não XML colocar nessa categoria até hoje -. Muito detalhado, muito intensivo de processo, também mimado

Hoje em dia, minha coisa favorita a utilização de dados que não precisam ser humano-readableis SQLite e fazer uma base de dados. É tão incrivelmente fácil de incorporar um banco de dados SQL full-featured em qualquer app ... existem ligações para C, Perl, Python, PHP, etc ... e é open-source e muito rápido e confiável e leve.

I <3 SQLite.

Alguém já tentei Mathematica ?

A foto acima é de uma versão antiga, mas foi o melhor google poderia me dar.

De qualquer forma ... comparar a primeira equação lá para Math.Integrate (1 / (Math.pow ( "x", 3) -1), "x") como você teria que escrever, se você estava codificação com texto simples na maioria das linguagens comuns. Imo a representação matemática é muito mais fácil de ler, e que ainda é bastante pequena equação.

E sim, você pode tanto de entrada e copie e cole o código como texto simples, se quiser.

Veja-a como a próxima geração destaque de sintaxe . Aposto que há um monte de outras coisas do que de matemática que poderia levar benifit deste tipo de representação.

É bastante óbvio por que texto simples é rei. Mas é igualmente óbvio porque um formato estruturado seria ainda melhor.

Apenas um exemplo: Se você renomear um método, a sua ferramenta de controle de diff / merge / fonte seria capaz de dizer que só uma coisa tinha mudado. As ferramentas que usamos hoje iria mostrar uma longa lista de mudanças, um para cada lugar e de arquivo que o método foi chamado ou declarada.

(A propósito, este post não responder à pergunta como você pode ter notado)

A tendência que estamos vendo cerca de DSL são a primeira coisa que vem à mente ao ler sua pergunta. O problema tem sido o facto de não existir uma relação de um-para-um entre os modelos (como UML) e uma implementação. Microsoft entre outros estão trabalhando em chegar lá, de modo que você pode criar seu aplicativo como semelhante a UML, em seguida, o código pode ser gerado alguma coisa. E o mais importante -. Como você optar por alterar o código, o modelo vai refletir isso de novo

Windows Workflow Foundation é um bom exemplo. De causa existem arquivos e / ou XML planas no fundo, mas você geralmente acabam definindo sua lógica de negócios na ferramenta de orquestração. E isso é muito legal!

Precisamos de mais das "fábricas de software" pensar e verá uma experiência IDE mais rico no futuro, mas enquanto computadores executado em zeros e uns, arquivos de texto plano pode e (provavelmente) será sempre um estágio intermediário . Como afirmado haver várias pessoas já, arquivos de texto simples são muito flexíveis.

Eu melancolicamente perguntava a mesma coisa, como descrito na resposta à: Que ferramenta / aplicativo / whatever Deseja existiu?

Embora seja fácil imaginar um grande número de benefícios Acho que o maior obstáculo que teria de ser abordado é que ninguém tem produzido uma alternativa viável.

Quando as pessoas pensam de alternativas para o armazenamento de fonte como texto eles parecem pensar muitas vezes imediatamente em termos de representações gráficas (estou me referindo aqui aos produtos comerciais que estão disponíveis -. Por exemplo, HP-Vee). E se olharmos para a experiência de pessoas como os designers FPGA, vemos que a programação (exclusivamente) graficamente simplesmente não funciona -., Portanto, linguagens como Verilog e VHDL

Mas eu não ver que o armazenamento de fonte precisa necessariamente estar vinculado ao método de escrevê-lo em primeiro lugar. Entrada de fonte pode ser feito em grande parte como texto - o que significa que as questões de copiar / colar pode ainda ser alcançado. Mas também vejo que, ao permitir fusões e reversões de ser feito com base em tokenised meta-fonte poderíamos alcançar ferramentas mais precisas e mais poderosas de manipulação.

Visual FoxPro usa DBF estruturas de tabela para armazenar código e metadados para formulários, relatórios, libs classe, etc. Estes são arquivos binários. Também código lojas em arquivos PRG que texto real arquivos ...

A única vantagem que eu vejo é ser capaz de usar o construída em linguagem de dados VFP para fazer pesquisas de código nesses arquivos ... outras que é um passivo imo. Pelo menos uma vez a cada poucos meses, um desses arquivos será corrompido por nenhuma razão aparente. A integração com o controle de origem e diffs muito doloroso também. Existem soluções para este, mas envolvem a conversão do arquivo para texto temporariamente!

Para um exemplo de uma linguagem que acaba com texto de programação tradicional, consulte a Lava idioma .

Outra coisa bacana eu só descobri recentemente é subtext2 ( vídeo de demonstração ).

O código do seu programa de definir a estrutura que seria criado com xml ou o formato binário. Sua linguagem de programação é uma representação mais direta da estrutura do seu programa do que um XML ou representação binária seria. Alguma vez você já reparou como misbehaves palavra sobre você como você dar estrutura ao documento. WordPerfect, pelo menos, iria 'revelar códigos' para que você possa ver o que havia debaixo do seu documento. arquivos simples fazer a mesma coisa para o seu programa.

A ideia pura é. Eu tenho me perguntou em uma escala menor ... muito menor, por que não pode IDE X gerar isso ou aquilo.

Eu não sei se eu sou capaz como um programador para desenvolver ainda algo tão fresco e complexo como o seu falar ou o que eu estou pensando, mas eu estaria interessado em tentar.

Talvez começar com alguns plugins para .NET, Eclipse, NetBeans, e assim por diante? Mostrar o que pode ser feito, e iniciar uma nova tendência na codificação.

Eu acho que um outro aspecto disso é que o código é o que é importante. É o que vai ser executado. Por exemplo, no seu exemplo UML, eu acho que ao invés de ter UML (presumivelmente criado em algum editor, não diretamente relacionado com o "código") incluído no seu "blob fonte" seria quase inútil. Muito melhor seria ter a UML gerado diretamente do seu código, por isso descreve o estado exato do código está em como uma ferramenta para a compreensão do código, em vez de como um lembrete de que o código deve ter sido.

Estamos fazendo isso há anos sobre ferramentas doc automatizadas. Embora os comentários programador real gerados no código pode ficar fora de sincronia com o código, ferramentas como o JavaDoc e similares representar fielmente os métodos em um objeto, tipos de retorno, argumentos, etc. Eles representá-los como eles realmente existem, não como alguns artefato que saiu do design reuniões intermináveis.

Parece-me que se você poderia acrescentar arbitrariamente artefatos aleatórios para algum "blob fonte", estes seriam provavelmente desatualizado e menos do que útil imediatamente. Se você pode gerar tais artefatos diretamente a partir do código, em seguida, o pequeno esforço para obter o seu processo de construção de fazer isso é muito melhor do que as armadilhas mencionadas anteriormente de se afastando de arquivos de origem de texto simples.

Relacionado a isso, um explicação de por que você 'd querer usar um texto simples UML ferramenta ( UMLGraph ) parece aplicar-se quase igualmente assim como para por que você quer arquivos de origem de texto simples.

Isto pode não responder exatamente a sua pergunta, mas aqui é um editor permite ter uma visão maior de código: http://webpages.charter.net/edreamleo/front.html

Penso que a razão do porquê de arquivos de texto são usadas em desenvolvimento é que eles são universais contra várias ferramentas de desenvolvimento. Você pode olhar para dentro ou mesmo corrigir alguns erros usando um editor de texto simples (você não pode fazê-lo em um arquivo binário, porque você nunca sabe como qualquer correção iria destruir outros dados). Isso não significa, no entanto, que os arquivos de texto são os melhores para todos os fins.

É claro, você pode diff e fundi-los. Mas isso não significa que a ferramenta diff / merge compreender a estrutura distinta dos dados codificados por este arquivo de texto. Você pode fazer o diff / merge, mas (especialmente visto em arquivos XML) a ferramenta de comparação não vai mostrar as diferenças corretamente, ou seja, ele irá mostrar-lhe onde os arquivos são diferentes e que partes dos dados a ferramenta "pensa" são os mesmos. Mas isso não vai lhe mostrar as diferenças na estrutura do arquivo XML -. Ela só vai corresponder as linhas têm a mesma aparência

Independentemente se estamos usando arquivos binários ou arquivos de texto, é sempre melhor que as ferramentas diff / merge cuidar da estrutura de dados deste arquivo representa, em vez das linhas e caracteres. Para arquivos C ++ ou Java, por exemplo, relatam que alguns identificador mudou seu nome, relatório que alguma seção foi cercado com adicional se () {}, mas, por outro lado, ignorar alterações nos travessões ou caracteres EOL. A melhor abordagem seria que um arquivo é lido em estruturas internas e despejado usando regras de formatação específicas. Desta forma, o diff-ing será feito através das estruturas internas e do resultado da junção irá ser gerado a partir da estrutura interna mescladas.

programas modernos são compostos de peças planas, mas eles são flat? Há usings, e inclui, e bibliotecas de objetos, etc. Uma chamada de função comum é uma espiada em um lugar diferente. A lógica não é plana, devido a ter vários segmentos, etc.

Eu tenho a mesma visão! Eu realmente gostaria que esta faria existe.

Você pode querer dar uma olhada em Fortaleza, uma linguagem de pesquisa pela Sun. Ele tem suporte especial para fórmulas em código fonte. A citação abaixo é de Wikipedia

Fortaleza está sendo projetado desde o início para ter vários sintática folhas de estilo. O código-fonte pode ser processado como texto ASCII, em Unicode, ou como uma imagem prettied. Isso permitirá que para suporte de símbolos matemáticos e outros símbolos no prestados saída para facilitar a leitura.

A principal razão para a persistência de texto como fonte é a falta de powertools, como por exemplo, controle de versão, para data não-texto. Isto é baseado na minha experiência de trabalho com Smalltalk, onde byte-code planície é mantido em um núcleo-dump todos os tempos. Em um sistema não-texto, com ferramentas de hoje, o desenvolvimento da equipe é um pesadelo.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow