Atenção
A versão inicial desta publicação recebeu uma ótima resposta no Reddit na forma de mais de 300 comentários. Depois disso, decidi adicionar uma pequena atualização para responder a algumas críticas das muitas recebidas.
Uma linguagem de programação visual é aquela que permite ao programador criar programas manipulando elementos gráficos em vez de digitar comandos de texto. Um exemplo famoso é o
Scratch , uma linguagem de programação visual nativa do MIT usada para educar crianças. Suas vantagens são que torna a programação mais acessível para iniciantes e não programadores.
Na década de 1990, houve um movimento muito popular para introduzir programação visual no ambiente corporativo usando as ferramentas
CASE , onde os sistemas corporativos podiam ser definidos usando
UML e gerados [seu código] sem a necessidade de atrair desenvolvedores de software treinados. Isso ocorre devido ao conceito de "round trip", em que o sistema pode ser modelado visualmente, o código do programa será gerado a partir dos modelos resultantes e quaisquer alterações no código poderão ser retornadas ao modelo. Infelizmente, essas ferramentas não foram capazes de cumprir sua missão e a maioria dos experimentos [em sua implementação] está atualmente largamente abandonada.
Assim, a programação visual não ganhou popularidade, exceto em algumas áreas muito limitadas. Essa situação se deve em grande parte aos seguintes conceitos errados sobre programação:
- Linguagens de programação de texto confundem o que é essencialmente um processo simples.
- Abstração e dissociação ( dissociação, redução da conectividade ) desempenham um pequeno papel periférico na programação.
- Ferramentas que foram projetadas para ajudar na programação não são importantes.
O primeiro equívoco insiste em que o desenvolvimento de software tem um alto limite de entrada, uma vez que as linguagens de programação de texto complicam a verdadeira natureza da programação. A popularidade do Scratch entre os educadores acadêmicos está acompanhando esse equívoco. A idéia é que a programação é realmente bastante simples e, se pudéssemos apresentá-la em um formato gráfico claro, reduziria drasticamente a curva de aprendizado e o esforço mental necessário para criar e ler o código do programa.
Suponho que esse erro decorra da incapacidade de realmente ler um programa típico escrito na linguagem de programação de texto padrão e imagine como ele é convertido em elementos gráficos de "cubos" e setas. Se você ainda pode imaginar isso, ficará imediatamente aparente que uma única linha de código geralmente corresponde a vários "blocos". Como mesmo para o programa mais simples, a presença de centenas ou duas linhas de código não é incomum, seu código se transformará em centenas ou até milhares de elementos gráficos. Uma tentativa de analisar mentalmente uma imagem tão complexa será muito mais difícil do que apenas ler o texto equivalente do programa.
A solução para a maioria das linguagens de programação visual é tornar os "blocos" mais complexos, de modo que cada elemento visual seja equivalente a um grande bloco de código de texto. As ferramentas visuais do fluxo de trabalho são um obstáculo imediato.
O problema é que o código ainda precisa ser definido em algum lugar. Portanto, o processo de codificação [em grandes elementos visuais] se transforma em “propriedades da caixa de diálogo de programação”. Os próprios elementos visuais representam apenas o nível mais alto de movimento do programa durante a execução, e a maior parte do trabalho agora é feita em código de texto padrão oculto em "cubos" visuais. Como resultado, pegamos o pior dos dois mundos e obtivemos programação de texto que não é suportada por ferramentas modernas.
Os diálogos de propriedades geralmente são ambientes de desenvolvimento não padrão e impõem uma escolha específica de linguagem, geralmente uma linguagem de script de algum tipo. Os elementos visuais básicos em si só podem ser criados por programadores experientes e podem ser completamente compreendidos apenas pela leitura de seu código básico; portanto, a maioria dos supostos benefícios da apresentação visual é perdida aqui.
Existe uma incompatibilidade de impedância entre o “código” visual e o código de texto (um
conjunto de dificuldades conceituais e técnicas ), e o programador precisa navegar na interface entre eles, gastando frequentemente mais esforço em melhorar a própria ferramenta de programação gráfica do que em resolver a tarefa original [de escrever o programa].
E agora chegamos ao segundo equívoco de que abstração e desduplicação desempenham um pequeno papel na programação. A programação visual é baseada no pressuposto de que a maioria dos programas são sequências processuais simples, um pouco semelhantes a um fluxograma. Como regra, a maioria dos programadores iniciantes acha que o software funciona exatamente assim.
No entanto, assim que o programa se tornar mais do que um exemplo trivial, sua complexidade logo sobrecarregará o programador iniciante. Os iniciantes acham muito difícil falar sobre uma grande base de código processual e geralmente ficam atolados nas tentativas de criar software estável e eficiente em larga escala. A principal inovação em linguagens de programação foi a tentativa de controlar a complexidade, geralmente por meio de abstração, encapsulamento e conectividade reduzida. Todos os sistemas de tipos e construções de linguagens de programação orientadas a objetos e funcionais são na verdade apenas uma tentativa de assumir o controle da complexidade dessas linguagens.
A maioria dos programadores profissionais abstrai e desacopla constantemente o código. De fato, a diferença entre código bom e ruim é basicamente o quanto o programador conseguiu fazer isso. As ferramentas de programação visual raramente possuem mecanismos eficazes para tais coisas; como resultado, o desenvolvedor “visual” fica preso nos recursos disponíveis, equivalentes ao BASIC da década de 1970.
O equívoco final é que os programadores visuais podem prescindir de todas as ferramentas de suporte de programação desenvolvidas ao longo de décadas. Veja a longa evolução dos editores de código e IDEs. Por exemplo, o Visual Studio oferece suporte a uma ferramenta intellisense eficaz que permite espiar as milhares de APIs disponíveis somente na biblioteca de classes base. A falta de um bom controle de versão é outra falha importante na maioria das ferramentas de programação visual.
Mesmo que eles salvem seu layout no formato de texto, os "diffs" não têm ou quase nenhum significado. É muito difícil culpar (encontrar o commit e responsável por alterar uma linha específica) em um grande bloco de XML ou JSON. Coisas que não têm significado para a execução funcional de um programa, como a posição e o tamanho dos elementos gráficos, constantemente levam a alterações nos metadados, o que dificulta ainda mais a análise do diff.
As linguagens de programação de texto aprenderam a separar os blocos estruturais de código em arquivos de origem separados, por isso é fácil mesclar uma alteração em uma parte de um sistema com outra em outra. As ferramentas visuais geralmente salvam o resultado de acordo com o princípio de "um diagrama por arquivo", o que significa que a fusão se torna problemática e ainda mais difícil se o significado semântico de "diff" for difícil de analisar.
UpdateProvavelmente me enganei quando tirei uma captura de tela do Scratch e a usei como um excelente exemplo no meu primeiro parágrafo. Não sou professor e não tenho minha opinião sobre a eficácia do Scratch como ferramenta de aprendizado. Muitas pessoas dizem que é extremamente útil no ensino de programação, especialmente para crianças. Tudo o que ajuda as pessoas a entrar no maravilhoso e emocionante mundo da programação só deve ser elogiado. Eu realmente não pretendia criticar especificamente o Scratch agora, este é apenas um exemplo de um sistema de programação visual que, como me pareceu, a maioria dos meus leitores deveria ter ouvido pelo menos.
Outro exemplo contrário fornecido pelo Reddit foram ferramentas de estrutura estática, como designers de UI, designers de esquema de banco de dados ou designers de classe. Concordo que eles podem ser muito úteis. Qualquer coisa que ajude a visualizar a estrutura de dados ou a estrutura de escala do programa é um bônus. Mas eles nunca são suficientes. Isso é evidenciado pela falha completa de ferramentas dos anos 90, como o Power Builder, que foram baseadas em visualizações gráficas para criar um ambiente de desenvolvimento sem a necessidade de trabalhar com código.
Sobre o autor:
Notas, pensamentos em voz alta, aprendendo à vista, mal-entendidos, erros, opiniões não diluídas. Sou Mike Hadlow, um desenvolvedor de pregação. Eu moro perto de Brighton, na costa sul da Inglaterra.
A tradução foi apoiada pela EDISON Software, uma empresa profissional de desenvolvimento e teste de software .