Como eram as IDEs com interface baseada em texto (de 1970 aos dias atuais)

Vi um artigo no Blog System/5 falando sobre como eram as IDEs há 30 anos, e resolvi trazer essa curiosidade para cá. Eu também trouxe algumas coisas que não foram citadas no artigo, e ajustei os exemplos em ordem cronológica.

Na década de 1990, quase todos os programas DOS tinham uma interface de usuário baseada em texto (TUI) em tela inteira que exibia janelas baseadas em texto, com sombras projetadas, cores e suporte para mouse (conforme a imagem abaixo), mas ao longo do artigo você poderá ver como isso evoluiu com o passar dos anos.

_{O MS-DOS Editor com uma de suas caixas de diálogo de configurações abertas. Veja a barra de menu (em cima), a caixa de diálogo com seletores e botões de lista, e a barra de status (embaixo) que documenta os atalhos de navegação.}

Emacs (1976)

O autor do artigo menciona o Emacs num tópico específico onde fala sobre Linux, e o Emacs difere bastante das IDEs de DOS. No Linux, quase todos os programas também eram baseados em texto, mas esses programas não vinham com TUI em tela inteira como os de DOS. Não era “o jeito Unix”.

Na opinião do autor, usar o Vim e Emacs parecia voltar ao passado, enquanto que os programas de tela inteira do DOS/Windows pareciam mais modernos e bonitos. O Vim tinha destaque de sintaxe, mas estava longe de ser uma IDE. O Emacs poderia ser configurado para integração com alguns recursos de assistência de código e similares, mas estava longe da experiêcia que a família de IDEs Turbo proporcionava (mencionadas nos próximos tópicos).

O Emacs era bem mais antigo do que as IDEs Turbo, mas acredito que o autor tenha mencionado ele porque era uma das recomendações para quem usava o Linux na época, e ainda é uma ferramenta que algumas pessoas usam e recomendam hoje em dia.

Turbo Pascal 1.0 (1983)

Mencionado brevemente no artigo, o Turbo Pascal 1.0, da Borland, mostrava o início de uma experiência integrada, embora ainda não apresentasse sua TUI icônica. Você pode ver algumas imagens no WinWorld (e, aparentemente, pode baixar e instalar, mas não testei isso).

SideKick Plus (1984)

Um dos primeiros editores de código (que não é bem um editor de código) mencionado no artigo é o SideKick Plus. Este programa era um sistema de gerenciamento de informações pessoais com um bloco de notas integrado. Ele se tratava de um programa Terminate and Stay Resident (TSR), o que significa que ele era carregado em segundo plano e você poderia acessá-lo a qualquer momento pressionando Ctrl + Alt, como exemplificado na imagem abaixo.

Essa era uma forma multitarefa rudimentar para um sistema operacional que não tinha multitarefa. Isso era importante para o desenvolvimento, porque permitia alternar rapidamente entre a edição e o build do código.

Turbo Pascal 4.0 (1987)

O Turbo Pascal 4.0 não foi mencionado no artigo, mas é uma IDE mais parecida com a próxima da lista, e uma evolução do Turbo Pascal 1.0. Veja como a interface era agora, após 4 anos da versão 1.0:

_{Fonte da imagem: WinWorld PC}

Turbo C++ (1990)

Outra IDE da Borland, o Turbo C++ servia para uma linguagem específica (C++), mas tinha TUIs em tela cheia e era extremamente poderoso. Algumas funcionalidades eram:

Integração com o compilador e diagnóstico de erros (repare também no realce de sintaxe no código):

Gerenciamento de projetos e recursos de múltiplas janelas:

_{A imagem mostra dois arquivos fonte C++, um dependendo do outro, e a janela do projeto listando todos os arquivos que precisam ser compilados juntos.}

Um depurador com pontos de interrupção (break points), a pilha de chamadas de funções e similares:

Um detalhe importante mencionado no artigo, já que hoje em dia as coisas são um pouco diferentes:

Eu era um usuário ávido do Turbo C++, com o qual aprendi muito. Lembro-me de usar suas bibliotecas conio.h para implementar minhas próprias TUIs e, em seguida, suas bibliotecas graphics.h integradas para brincar com a implementação de GUIs. E observe: isso foi sem Internet. Para muitos, não havia opção de apenas “ver como as coisas funcionavam” no Stack Overflow: o IDE precisava ser descoberto imediatamente (o que era) e independente para oferecer uma experiência de desenvolvimento completa.

Free Pascal (1997)

De acordo com o autor, o Free Pascal é o mais próximo que você chegará da experiência antiga, mas com uma base de código moderna, rodando nativamente em sistemas Unix e aproveitando terminais de qualquer tamanho.

_{A IDE Free Pascal com um "olá mundo" e janelas sobrepostas para uma tabela ASCII integrada e uma calculadora.}

IDEs de console contemporâneas “reais”

O estado da arte parece ser Neovim, Doom Emacs ou mesmo Helix. Esses editores são muito poderosos e, graças a vários plugins, oferecem experiências semelhantes às de IDEs. Apesar disso, para o autor, nenhum deles oferece o mesmo tipo de experiência que os produtos Borland anteriores ofereciam: suas interfaces são obscuras e, devido à sua natureza multilíngue, funcionam bem para quase tudo, mas não são ótimos para nada. Jack of all trades, master of none.

_{Neovim, imagem obtida na publicação Por que você deveria usar NeoVim para programar do NathanFirmo.}

_{Doom Emacs, imagem obtida no GitHub.}

_{Helix, imagem obtida no GitHub.}

Por que usar IDEs TUI hoje em dia?

Em geral, você provavelmente não deseja uma IDE TUI, mas ainda existem situações em que elas podem ser úteis.

A primeira é que uma IDE TUI é excelente para trabalhar em máquinas remotas – ainda melhor que o VSCode. Você pode usar SSH em qualquer máquina com facilidade e iniciar a IDE. Combine isso com o tmux e você terá multitarefas de forma “completa”.

A segunda é que as extensões remotas do VSCode não são de código aberto, o que não é um grande problema, exceto pelo fato de que elas não funcionam no FreeBSD e não há como corrigi-las, por exemplo. Portanto, isso torna impossível acessar remotamente o servidor de desenvolvimento primário usando o VSCode pelo FreeBSD.

E a terceira é uma redução do consumo de recursos, que hoje são bem "desperdiçados". O autor menciona alguns exemplos de bloat (inchaço):

• O Borland Turbo C++, com todos os seus recursos (a UI, o conjunto de ferramentas C++, os manuais integrados etc.), tem menos de 9 MB após a instalação e roda em 640 KB de RAM.
• O Helix tem 16 MB em disco, o que é bastante impressionante (e honestamente inesperado).
• O Doom Emacs tem cerca de 500 MB e consome muitos MB de RAM.

Nenhum dos números do Helix e Doom Emacs leva em conta as toolchains de ferramentas de linguagem ou sistemas de ajuda, e as toolchains hoje em dia estão classificadas em GBs de espaço em disco.

Para obter IDEs “reais”, temos que pular para programas gráficos como IntelliJ ou VSCode. O VSCode, por exemplo, tem cerca de 350 MB em disco (surpreendentemente menos que o Doom Emacs), mas vai consumir bastante recurso do seu computador, já que é feito em Electron. O autor percebeu uma economia significativa na vida útil da bateria do notebook dele ao trocar o VSCode e pelo Doom Emacs.

O autor deixa uma reflexão final:

Portanto, a questão da qual quero me desfazer é: avançamos muito em 30 anos? IDEs modernas têm ferramentas de refatoração melhores, recursos melhores e suportam mais linguagens, mas fundamentalmente elas não mudaram muito. A única grande diferença que estamos começando a ver pode ser a codificação assistida por IA, mas esse é um recurso fornecido principalmente por um serviço remoto, nem mesmo pelo código instalado!

E isso é tudo por hoje. Da minha parte, continuarei felizmente usando todo o Doom Emacs, Vim, VSCode e IntelliJ dependendo da situação.

Na minha opinião, a maior parte das mudanças que ocorrem nos sistemas hoje em dia são do ponto de vista de "beleza", o que muda conforme o tempo passa, e curiosamente também passa a exigir mais do computador para isso. Exibir degradês, transições e animações, opacidade e efeitos de vidro (glassmorphism). Tudo isso exige mais do computador (às vezes, bem mais) para fazer as mesmas coisas.

Um ponto ainda mais danoso que tem surgido ultimamente é o uso de modelos 3D animados em sites de "landing page". Lembro do lançamento do Resend onde vi algumas pessoas comentando um alto consumo de CPU, apenas porque tem um modelo de cubo mágico "rodando" no site. Isso definitivamente corta o acesso de pessoas que estão usando computadores mais antigos.

Então, com essa publicação de curiosidades dos "tempos antigos", fica também a reflexão para quem é desenvolvedor: quando for programar algo, lembre que eficiência pode não ser necessário no mínimo detalhe como era antigamente, mas "jogar recurso fora" pode ser algo danoso, principalmente dependendo do público alvo do seu site, app ou programa.