Linguagens de programação visual

35

Muitos de nós aprendemos programação usando linguagens de programação "textuais", como Basic, C / C ++ e Java. Eu acredito que é mais natural e eficiente para os humanos pensarem visualmente. A programação visual permite que os desenvolvedores escrevam programas manipulando elementos gráficos. Eu acho que o uso de programação visual deve melhorar a qualidade do código e reduzir os erros de programação. Estou ciente de algumas linguagens visuais, como App Inventor , Scratch e LabView .

Por que não existem linguagens visuais de uso geral para desenvolvedores? Quais são as vantagens e desvantagens da programação visual?

Mohammad Al-Turkistany
fonte
7
Você está certo: as pessoas pensam visualmente. Mas as imagens de código complexo são impossíveis de entender de uma só vez; então, onde está a vantagem? Um bom programador tem um modelo visual do código em sua cabeça, independentemente do que estiver na tela. Linguagens visuais são, imho, para pessoas que ainda não aprenderam como abstrair da representação textual de um programa. Dito isto, acredito que o código textual deve ser bonito, por exemplo, estruturas e claro, para torná-lo navegável com os olhos.
Raphael
@ Rafael, OK, imagine isso, e se eu pedir uma descrição textual de um arranha-céu em vez de sua planta?
Mohammad Al-Turkistany
2
As linguagens visuais são certamente empregadas, pelo menos até certo ponto, nos construtores de interfaces com o usuário. Pode-se até conectar botões etc. ao código subjacente implementando a funcionalidade sem escrever nenhum código (exceto o código subjacente).
21812 Dave Clarke
11
@ MohammadAl-Turkistany: Essa comparação não é muito boa. Primeiro, os arranha-céus são construídos "visualmente", então faz sentido que seus planos se ajustem; o software está no final do dia, portanto parece apropriado usar o texto como modelo. Segundo, não acredito que alguém queira plantas de múltiplos arranha-céus sobrepostos que violem as leis da física; mas é assim que o software se parece hoje.
Raphael
@ MohammadAl-Turkistany Acho que isso é muito amplo. Seu último parágrafo contém 4 perguntas. Isso é demais.
211 uli

Respostas:

36

Em geral, há uma troca no design da linguagem de programação entre facilidade de uso e expressividade (poder). Escrever um programa simples "Olá, mundo" em uma linguagem iniciante, como Scratch ou App Inventor, geralmente é mais fácil do que escrevê-lo em uma linguagem de programação de uso geral, como Java ou C ++, onde você pode escolher vários fluxos para saída para, conjuntos de caracteres diferentes, a oportunidade de alterar a sintaxe, os tipos dinâmicos etc.

Durante a criação do App Inventor (do qual eu fazia parte), nossa filosofia de design era simplificar a programação para iniciantes. Um exemplo trivial foi basear nossos índices de matriz em 1, em vez de 0, embora isso faça com que os cálculos sejam provavelmente executados por programadores avançados um pouco mais complexos.

A principal maneira, no entanto, de que as linguagens de programação visual tendem a ser projetadas para iniciantes é eliminando a possibilidade de erros de sintaxe, tornando impossível a criação de programas sintaticamente inválidos. Por exemplo, os idiomas do bloco não permitem que você faça um rvalorizar o destino de uma declaração de atribuição. Essa filosofia tende a produzir gramáticas e idiomas mais simples.

Quando os usuários começam a criar programas mais complexos em uma linguagem de blocos, eles descobrem que arrastar e soltar blocos é mais lento do que a digitação. Você prefere digitar "a * x ^ 2 + b * x + c" ou criá-lo com blocos?

Não se pode dar justiça a este tópico (pelo menos por mim) em alguns parágrafos, mas algumas das principais razões são:

  1. Os idiomas de bloco tendem a ser projetados para iniciantes, portanto, não são tão poderosos por design.
  2. Não há uma maneira visual agradável de expressar alguns conceitos complexos, como sistemas de tipos, encontrados nas linguagens de programação de uso geral.
  3. O uso de blocos é pesado para programas complexos.
Ellen Spertus
fonte
3
Você pode dizer que os brindes visuais não se adaptam ao progresso do usuário?
Raphael
Boa resposta. Gosto da menção das trocas de design.
precisa
7
@ Rafael, acho que sim. Essa é uma das razões pelas quais o design de circuitos integrados passou de esquemático (que é uma linguagem gráfica) para HDL e síntese. Eu acho que alguém interessado em linguagens gráficas deveria estudar os usos do esquema e do HDL no projeto de circuitos e por que a chave ocorreu e por que o esquema ainda é preferido em alguns casos.
AProgramador
11
@ AProgrammer: Interessante. Parece "aprender visualmente, dominar a abstração".
Raphael
Eu acho que as pessoas deveriam tentar combinar o melhor dos dois mundos. Então, para "a x ^ 2 + b x + c" eu digitaria, mas apareceria como blocos (ou qualquer coisa visual), e então eu poderia arrastá-lo ou fazer conexões graficamente. Eu acho que é tudo uma questão de design de interface do usuário, para o qual o melhor compromisso é o uso mais eficaz de controles gráficos e de teclado e visualização gráfica e de texto, e acho que podemos fazer melhor do que o realce de sintaxe simples ..
guillefix
21

Por que não existem linguagens visuais de uso geral para desenvolvedores? Quais são as vantagens e desvantagens da programação visual?

As linguagens visuais tendem a quebrá-lo em três grandes categorias:

  1. Utiliza ferramentas não programadores para executar tarefas básicas de automação. Pense no Automator no Mac.
  2. Ambientes de aprendizado em que não é prático digitar muito ou em que a estrutura do programa mostrando o fluxo lógico é importante. Pense em Scratch, Alice, etc.
  3. O problema abordado é um problema de fluxo de dados, e a solução para o problema é bem modelada por algum tipo de fluxo de dados entre caixas independentes que imitam o mundo físico. O LabView e o Ableton vêm à mente.

A vantagem da programação visual é que você obtém uma visão geral de alto nível da estrutura do sistema. Isso leva ao problema imediato de que, quando você for detalhado, seu código de espaguete realmente se parece com espaguete . Um componente comum das linguagens visuais é algum tipo de bloco de código ou componente de configuração para o elemento visual. O problema é que o programador precisa entender os blocos de código desconectados que podem ser interligados de maneiras estranhas.

Embora não haja nada de errado com a programação visual, pode ser que simplesmente não seja uma boa abordagem para a maioria das tarefas.

John Percival Hackworth
fonte
Apenas pensei em informar que o autor da outra resposta acha que a sua é boa. :-)
Ellen Spertus
quando se refere a Ableton, você quer dizer Max / MSP? Os dois são projetos separados desenvolvidos por organizações diferentes e o Max / MSP, assim como o irmão de código aberto PureData, são mais complexos e expressivos do que o ponto 3 lhes dá crédito pela IMO.
sol
11

Existem inúmeras linguagens de programação visual, como as duas bibliografias a seguir serão mostradas: vlib.org e oregonstate.edu .

IMHO eles falharam em ganhar força, porque, embora sejam bons para exemplos de brinquedos, não conseguem gerenciar os vários níveis de abstração, representação e granularidade exigidos por grandes projetos. Você precisaria olhar para um sistema como o AutoDesk Revit (um sistema de gerenciamento de informações de construção usado por arquitetos e engenheiros) para ver como a informação visual de gerenciamento complexa pode se tornar.

Em vez de observar a programação de uso geral, é provável que a programação visual seja bem-sucedida como ferramenta de configuração em domínios especializados.

CyberFonic
fonte
8

O texto é visual.

Usamos todos os tipos de pistas visuais em nosso código. Todo uso de espaço em branco (recuos, novas linhas, linhas em branco, espaçamento intralino) é direcionado para fornecer pistas visuais para a funcionalidade do código. Usamos todos os tipos de sintaxe diferentes para fornecer informações visuais sobre o que o código está fazendo. Nossos editores colorem nosso código para destacá-lo.

A matemática é textual. Existem todos os tipos de notação, mas no final tudo se resume a basicamente texto. Eles estão fazendo há centenas de anos.

O que quero dizer: a representação textual do código está fazendo uso das habilidades visuais que os humanos têm. Provavelmente, podemos usá-lo melhor, mas não abandonando o texto.

Winston Ewert
fonte
11
Boa observação, mas sua última subcláusula é uma afirmação ousada. Por que você acha que elementos visuais mais elaborados do que espaços em branco e símbolos diferentes (e talvez cores) não podem ajudar?
Raphael
11
@ Rafael, não estou dizendo que não podemos fazer uso de elementos visuais mais elaborados, por isso disse: "Provavelmente podemos usá-lo melhor". Estou dizendo que isso não acontecerá jogando fora o texto. Todas as linguagens de programação "visuais" que eu vi começam com a suposição de que o texto é ruim e tentam eliminá-lo e aí estão completamente erradas.
Winston Ewert
6

[Para a versão PDF desta resposta , as figuras ou diagramas são interativos e dinâmicos.]

Elementos de rede e anotações: uma linguagem de programação visual de uso geral

Uso gráficos para organizar programas JavaScript ™ que usam a API Acrobat® / JavaScript. Cada objeto gráfico representa um elemento Petri Net (local, transição, entrada ou saída) ou representa mais de um elemento Petri Net. Cada objeto gráfico é na verdade uma anotação do elemento líquido correspondente. No entanto, se todo objeto gráfico for mapeado para um e apenas um elemento líquido, ele poderá ser usado para gerar o elemento líquido. E se um objeto gráfico for mapeado para mais de um elemento da rede e o mapeamento estiver bem definido, também poderá ser usado para gerar os elementos da rede. Os elementos Petri Net padrão são representados por certos tipos de gráficos: um círculo é um lugar, um quadrado ou retângulo ou linha é uma transição, uma seta de um círculo para um quadrado é uma entrada e uma seta de um quadrado para um círculo é uma saída. Além disso,

[Os tipos de anotações em uma "Rede de Petri Padrão" são encontrados na versão PDF desta resposta.]

Carl Adam Petri descreveu a maioria dessas idéias (incluindo os tipos de anotações em uma "Rede de Petri Padrão" em sua tese de doutorado (Petri, 1966) .Ele também aplicou os elementos de rede e anotações na descrição de vários circuitos lógicos, como Figura 6

Benefícios e Desafios

Uma linguagem de programação visual pode ajudar um programador de computador a desenvolver programas de computador (Menzies, 2002).

Eu tenho pelo menos três razões pelas quais considero elementos líquidos e anotações úteis (vantagens?).

Primeira razão. A lógica do processo pode ser criada um elemento por vez. Isso significa que uma rede pode ser estendida adicionando elementos à rede existente (Petri, 1966). Por exemplo, um modelo de um controlador pode ser dividido em componentes internos e externos. O componente interno regula o sistema. O componente externo faz interface com o ambiente aceitando entrada do ambiente. A Figura 1 é um modelo de Petri Net do componente interno. É possível adicionar um modelo de Petri Net do componente externo ao modelo de Petri Net do componente interno adicionando os locais e a transição apropriados (Figura 2).

Figura 1 Modelo de rede de Petri de um componente interno de um controlador (Halloway, Krogh e Giua, 1997) Um modelo de rede de Petri de um componente interno de um controlador (Halloway, Krogh e Giua, 1997)

Figura 2 Modelo de rede de Petri de componentes internos e externos de um controlador (Halloway, Krogh e Giua, 1997) Um modelo de rede de Petri de componentes internos e externos de um controlador (Halloway, Krogh e Giua, 1997)

Segunda razão. Os códigos associados a cada elemento da rede podem vir de mais de uma "linguagem de programação" (Petri, 1973). Eles podem vir de uma linguagem de computador como JavaScript, COBOL, ADA e uma linguagem de montagem. Eles podem vir de uma linguagem matemática, como símbolos algébricos. Eles podem vir de prosa codificada em inglês, alemão, francês, grego, tagalo, chinês etc. Assim, pode ser usada como base para comunicação e colaboração durante todo o ciclo de vida de desenvolvimento de software ou sistema; e entre diferentes usuários, desenvolvedores e partes interessadas (Petri, 1973).

Terceira razão. É possível focar em certos objetos gráficos na rede e escrever as anotações de código ou lógica para os objetos gráficos relacionados. Considere um modelo de Rede de Petri de um jogo de cartas na Figura 3. Se a seta para a entrada P7  T4 for um gráfico padrão para uma entrada em uma Rede de Locais / Transições e se m_7 for a marca do local P7, a anotação lógica para atualizar a marca do local de entrada é m_7 = m_7-1. Se s_9 ^ - é o status da entrada, a anotação lógica para atualizar o status da entrada é s_9 ^ - = ((m_7 <1)? False: true).

Figura 3 Um modelo de rede de Petri de um jogo de cartas Um modelo de jogo de cartas de Petri Net

Tenho pelo menos três razões pelas quais considero a aplicação das redes de Petri desafiadora (desvantagens?)

Se houver muitos objetos gráficos, seria difícil criar ou ler a rede. A dificuldade pode ser atenuada ao pegar um subconjunto dos gráficos e representá-los usando um, dois ou três símbolos gráficos (Noe, 1973; Petri, 1966). Por exemplo, se o modelo de Petri Net de um jogo de cartas na Figura 3 for considerado como tendo muitos objetos gráficos no diagrama, é possível combinar alguns dos gráficos e ainda manter informações suficientes para mapear o diagrama em um programa de computador. Considere a Figura 4, um modelo de Rede de Petri do mesmo jogo encontrado na Figura 3 com gráficos de alto nível (Chionglo, 2016a).

Figura 4 Um modelo de rede de Petri de um jogo de cartas usando gráficos de alto nível (Chionglo, 2016a) Um modelo de rede de Petri de um jogo de cartas usando gráficos de alto nível (Chionglo, 2016a)

Em outro exemplo, os componentes externos do controlador na Figura 2 podem ser combinados para criar uma representação gráfica mais concisa, como mostrado na Figura 5.

Figura 5 Um modelo de rede de Petri de um controlador com gráficos de alto nível para componentes externos Um modelo de rede de Petri de um controlador com gráficos de alto nível para componentes externos

Finalmente, um conjunto de locais mutuamente exclusivo ou um conjunto de transições mutuamente exclusivo também pode ser representado usando um objeto gráfico de alto nível (Chionglo, 2015).

Segunda razão. Mesmo com gráficos padrão, pode ser desafiador desenhar e posicionar gráficos, especialmente se se espera que o diagrama final seja fácil de usar ou de ler. Algumas das decisões para a tomada de um diagrama fácil de usar ou de ler incluem: o layout adequado dos objetos gráficos, as dimensões apropriadas da tela e das formas, a curvatura das setas, o tipo de ponta de seta, o tamanho e a fonte do texto, e a escolha de cores para gráficos e texto.

Terceira razão. É fácil criar anotações de elementos de rede de maneira ordenada, porque todas as anotações estão direta ou indiretamente relacionadas a um elemento de rede. No entanto, exibir todas as anotações junto com os gráficos de todos os elementos da rede pode não ser uma boa ideia, pois pode haver muitas informações apresentadas no diagrama. Por exemplo, considere um diagrama de um modelo de rede de Petri de um circuito lógico que inclua referências a todas as anotações de propriedades e lógicas (Figura 6). [O modelo original incluía uma condição de teste para o status de cada saída (figura 31 na página 78 de (Petri, 1966)); a condição de teste foi omitida aqui porque é equivalente ao modelo original para a marcação inicial especificada. Portanto, toda saída possui uma anotação lógica para calcular a marca do local de saída.]

Figura 6 Uma rede de lugar / transição com anotações - com base na figura 31, página 78 de uma tradução para o inglês da dissertação de Petri (1966) Uma Rede de Locais / Transições com anotações - com base na figura 31, página 78 de uma tradução para o inglês da dissertação de Petri (1966)

Uma maneira de mitigar esse desafio seria identificar os tipos de anotações usadas no modelo e definir objetos gráficos que incluam anotações desses tipos (Petri, 1966). Assim, quando um diagrama de Petri Net é composto de objetos gráficos das definições, a interpretação desses objetos deve incluir as anotações "invisíveis". A Figura 7 deve ser interpretada como uma rede de Petri padrão (consulte as anotações de uma rede de Petri padrão para obter as definições); portanto, a anotação lógica pode ser omitida do diagrama.

Figura 7 Uma Rede de Locais / Transições - com base na figura 31, página 78 de uma tradução para o inglês da dissertação de Petri (1966) Uma Rede de Locais / Transições - com base na figura 31, página 78 de uma tradução para o inglês da dissertação de Petri (1966)

Outra maneira de mitigar esse desafio seria usar visualizações de formulário das anotações para complementar ou complementar o (s) diagrama (s) (Chionglo, 2016b; 2014). As vistas podem ser divididas em vistas menores e cada vista pode ser exibida e oculta.

Referências

Chionglo, JF (2016a). Uma resposta a "Como projetar um fluxo de estado para um jogo de flashcard de reação / redux?" No Stack Overflow. Disponível em https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow .

Chionglo, JF (2016b). Duas vistas de formulário de uma rede de Petri. Disponível em http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .

Chionglo, JF (2015). Reduzindo o número de elementos gráficos líquidos em um diagrama de Petri Net usando gráficos de alto nível. Disponível em http://www.aespen.ca/AEnswers/WjTpY1429533268 .

Chionglo, JF (2014). Elementos de rede e anotações para programação de computadores: cálculos e interações em PDF. Disponível em https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

Halloway, LE; Krogh, BH e Giua, A. (1997). Uma pesquisa dos métodos da Petri Net para sistemas controlados de eventos discretos [versão eletrônica]. Sistemas Dinâmicos de Eventos Discretos: Teoria e Aplicações, vol. 7. Boston: Kluwer Academic Publishers, pp. 151 - 190.

Menzies, T. (2002). Problemas de avaliação para linguagens de programação visual. Em SK Chang (Ed). Manual de Engenharia de Software e Engenharia do Conhecimento, vol. 2 Tecnologias Emergentes. World Scientific Publishing co. Pte. Ltd., pp. 93 - 101.

Noe, JD e Nutt, GJ (1973). “Redes eletrônicas macro para representação de sistemas paralelos”, IEEE Transactions on Computers, vol. C-22, n. 8, agosto de 1973, pp. 718 - 727.

Petri, CA (1973). Conceitos da Teoria da Rede. Em Fundamentos Matemáticos da Ciência da Computação: Proc. do Symposium and Summer School, High Tatras, 3 - 8 de setembro de 1973, páginas 137 - 146. Math. Inst. do Acad eslovaco. of Sciences, 1973.

Petri, CA (1966). Comunicação com a Automota [trad. CF Greene, Jr.]. Suplemento I ao Relatório Técnico RADC-TR-65-377 (Volume I). Base da Força Aérea de Griffiss, NY: Centro de Desenvolvimento Aéreo de Roma, Divisão de Pesquisa e Tecnologia, Comando de Sistemas da Força Aérea, Base da Força Aérea de Griffiss. Recuperado em 31 de agosto de 2011 em http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf .

John Frederick Chionglo
fonte
2

Johne Percival Hackworth :

Embora não haja nada de errado com a programação visual, pode ser que simplesmente não seja uma boa abordagem para a maioria das tarefas.

Talvez as linguagens de programação visual até agora tenham sido muito imaturas? A noção de que visualizações avançadas não podem ser aplicadas a artefatos de software e que elas são deixadas completamente à 'imaginação' de cada desenvolvedor para criar suas próprias idéias pode ser uma suposição falsa. Aumentar o nível de abstração de maneira uniforme e automatizada parece óbvio, desde que a capacidade de executar abstrações de baixo nível e alto desempenho de execução não seja sacrificada. Em última análise, isso poderia levar à 'programação' de especialistas em domínio, não muito diferente da maneira como as planilhas automatizavam a tarefa dos programadores de COBOL de manipular números. A principal diferença aqui é substituir números pela manipulação de 'sistemas gerais'.

Sandy Klausner
fonte
2

Você pode ver a programação sem tecnologia de codificação (PWCT)

O PWCT é uma linguagem de programação visual de uso geral que permite o desenvolvimento de sistemas e aplicativos gerando etapas interativas em vez de escrever código.

Aqui é um bom lugar para começar e é de código aberto .

user11416
fonte
Para um site sobre uma linguagem de programação visual, esse segundo link certamente é excessivamente textual. Nem uma única página com capturas de tela. E o link da Wikipedia está quebrado; o artigo foi excluído por não-notabilidade.
Curinga
2

uma pergunta complicada. a programação visual ou baseada em fluxo realmente se tornou mais usada, mas não é amplamente usada em comparação com todas as linguagens de programação. fatores significativos são manutenção e padronização. o código do computador pode ser impresso nas páginas. nem sempre é tão claro como imprimir um programa visual.

em contraste com a principal resposta atual, eu argumentaria que definitivamente não há nenhuma limitação teórica inerente ao poder de programação visual versus linguagens textuais. de fato, a programação visual pode ser vista como mais fácil de manter um dia, com base na conceituação humana mais rápida das muitas camadas de abstração . então parece haver um elemento inconfundível de inércia / conservadorismo social / cultural em sua aceitação.

os editores visuais são provavelmente muito mais complexos em seu código, e isso é formidável, considerando que mesmo IDEs baseados em texto podem ser muito complexos, por exemplo , Eclipse , observe que existem plugins orientados à programação visual em alguns IDEs, como eciplse, por exemplo, para criação de GUI. A programação visual para criação de GUI é bastante difundida agora.

parece-me que o uso da programação visual está aumentando em áreas selecionadas e que, a partir de agora, poderá se tornar mais comum.

não devemos esquecer que a programação visual é inerente ao design de chips EE há décadas, onde não é uma abstração e (sub) sistemas são definidos em projetos 2d exatamente como pretendido.

o kit Lego mindstorms , agora difundido e com mais de uma década, sempre teve software de desenvolvimento baseado em programação visual, agora simplificado significativamente em muitas versões.

Aqui está um artigo recente interessante analisando a história e as perspectivas e sugerindo que ela pode se tornar mais comum na programação baseada na Web. A disposição dinâmica de controles / widgets em uma página é uma variante da programação baseada em visual.

Outra área chave / emergente em que é amplamente difundida em muitas ferramentas é o BPM, modelagem de processos de negócios.

vzn
fonte
1

Eu acho que a razão pela qual essas soluções não são tão populares, porque na maioria dos casos elas podem ser incontroláveis ​​e se tornar uma bagunça.

Quase todas as ferramentas de programação visual disponíveis hoje em dia fazem parte de aplicativos maiores e são usadas para uma finalidade específica (por exemplo: Blueprint no UE4).

De qualquer forma, um novo que eu me deparei recentemente para programação geral é o Korduene, que não é realmente um objetivo geral, pois é mais para a criação de aplicativos para Windows.

NetInfo
fonte
Você tem alguma citação para sustentar sua afirmação de que, na maioria dos casos, os idiomas visuais se tornam confusos e incontroláveis?
David Richerby
Na verdade, sim, por exemplo, gráfico de espaguete, mesmo com o software que mencionei acima, o desenvolvedor teve esse problema (eu acompanho de perto o desenvolvimento desse aplicativo), para fazer um backup do meu ponto, confira este LINK .
NetInfo 14/10
1

Acho que @Raphael e outros estão errados quando dizem que um programa é texto. Não é. São muitas coisas. É dizer ao computador o que fazer ou como fazê-lo. (programação imperativa e declarativa) A associação da programação à edição de texto é um dogma histórico e contra-intuitivo. Que foi criado pelas limitadas entradas / saídas textuais dos primeiros computadores. As pessoas não são analisadores de texto!

Embora eu ache que as pessoas estão certas de que uma linguagem totalmente visual (onde você faz qualquer coisa visualmente, conectando elementos via mouse e coisas assim) é impraticável para uma linguagem de uso geral, acho que todas as linguagens atuais podem e devem ser movidas para um intermediário nível. Onde os elementos de idioma têm uma representação visual, que é salva em um arquivo de idioma binário. O programador não digitaria texto como louco, ou viveria sob o feitiço de linhas e recuo.

Mas insere elementos por meio da combinação mais produtiva de teclas de atalho / comandos / elementos da interface do usuário. E apenas digita seqüências de caracteres e outros dados e identificadores. Isso tornaria os erros de sintaxe impossíveis e tornaria os idiomas com segurança e correção em mente (por exemplo: ADA) muito mais produtivos. E também tornaria os outros mais seguros e menos problemáticos, impossibilitando classes inteiras de erros comuns. (Como os que a ADA impede por serem pesados)

Até certo ponto, as coisas estavam indo nessa direção. Por recuo automático e coloração de sintaxe. Infelizmente, ninguém percebeu (ou se importou o suficiente) que esse é o conceito central do "analisador de texto humano". Os argumentos do emacs vs vim são engraçados porque ambos estão errados. Eles são "soluções" para um problema criado artificialmente.

mzso
fonte
11
"As pessoas não são analisadores de texto!" O que você está fazendo agora? Mas, de qualquer forma, essa resposta parece ser principalmente a sua opinião pessoal sobre qual seria a melhor maneira de programar. Existem exemplos de idiomas ou pesquisas que você pode citar que elevam isso além do nível da opinião pessoal? Que vantagens você vê ao armazenar o código-fonte em um formato binário? Parece-me que isso o colocaria à mercê de bugs no ambiente de desenvolvimento - pelo menos quando as coisas são armazenadas como texto, posso usar um editor de texto diferente se o meu favorito não funcionar por algum motivo.
David Richerby
@DavidRicherby Naturalmente, não existem exemplos. Eu estava falando sobre o que poderia ser. O formato binário pode ser adaptado ao idioma. Poderia trazer melhor desempenho e segurança de dados. "Parece-me que isso colocaria você à mercê de bugs no ambiente de desenvolvimento" Esse é sempre o caso. Seria necessário estar livre de erros. Assim como muitos outros softwares.
Mzso 31/10/16
Se o formato for padronizado como deveria, poderá ter editores diferentes. Achei que seria mais útil se a parte visual também fosse padronizada. Quanto a um programa para armazenar e recuperar dados sem falhas, não é um requisito exótico. Muitos softwares maduros conseguem isso, com poucos e distantes bugs.
Mzso # 31/16
11
Eu pedi "exemplos ou pesquisas"; você disse que não há exemplos. Isso deixa a pesquisa. Você alega que um formato binário melhoraria o desempenho e a segurança. Quão? Já temos um formato de origem padronizado: texto. Por que usar binário? Uma linguagem de programação visual é mais complicada e especializada do que um editor de texto: parece mais provável que seja um bug e já existem editores de texto maduros.
David Richerby
@DavidRicherby O texto não é um formato de origem. É um arquivo de texto simples e burro, que armazena texto. Claro que seria mais complicado, é apenas uma coisa simples para editar texto, não para programação. Seria mais rápido, evitando a análise e interpretação de texto. Um arquivo de texto armazena caracteres, um arquivo de idioma conteria os elementos do idioma. (mais dados) A linguagem visual não seria mais complicada, seria a mesma em uma representação diferente. Sem a desvantagem do editor de texto. PS: Não sei por que ou como você espera exemplos, procure uma idéia.
Mzso # 31/16