- No início dos anos 1990, as IDEs baseadas em texto ofereciam recursos excelentes mesmo em hardware limitado
- A então representativa série Borland Turbo contava com destaque de sintaxe, integração com compilador, depuração, ajuda e outros recursos, em um ambiente comparável às IDEs modernas
- No Linux, Vim e Emacs eram personalizáveis, mas tinham como limitação a dificuldade de aprendizado e a pouca intuitividade para iniciantes
- Recentemente, as TUIs (interfaces de texto) e os recursos de IDE vêm ressurgindo gradualmente com o aparecimento de novas tecnologias como LSP, mas ainda falta a integração dos anos 1990
- As vantagens das IDEs TUI incluem acesso remoto, baixo consumo de recursos e liberdade do open source; por outro lado, as IDEs modernas sofrem claramente com o fenômeno do inchaço por acúmulo de recursos
Introdução: a lembrança das IDEs baseadas em texto do início dos anos 1990
- Do fim dos anos 1980 ao início dos anos 1990, o autor reviveu antigos ambientes de desenvolvimento com DOSBox e sentiu o prazer de compará-los com os atuais
- As IDEs baseadas em texto da época tinham muitos recursos apesar das limitações de hardware
- Depois disso, a maior parte dessas funções desapareceu por muito tempo com a ascensão dos sistemas operacionais em janelas, e só recentemente algumas voltaram a aparecer
Editores iniciais e ambiente TUI
- Nos anos 1990, a maioria dos programas para DOS usava uma Text User Interface (TUI) em tela cheia, com janelas em modo texto, cores, sombras e até suporte a mouse
- Cada programa tinha um design diferente, mas era possível aprender rápido graças ao modo de operação semelhante
- O MS-DOS passou a oferecer um editor TUI embutido a partir da versão 5 (1991), mas era necessário fechar o editor para compilar/executar, e ao reabri-lo havia o incômodo de ter de reencontrar a posição de trabalho
- Também havia ferramentas baseadas em TSR (programas residentes), como o SideKick Plus (1984), que permitiam edição de código e build de forma eficiente em sistemas operacionais sem multitarefa
- Já em meados e no fim dos anos 1980 surgiram IDEs iniciais como Turbo Pascal e QuickBASIC, oferecendo uma experiência de desenvolvimento integrada
Série Borland Turbo: o auge da IDE integrada
- Borland Turbo C++, Turbo Assembler e Turbo Pascal eram voltados a linguagens específicas, mas ofereciam uma TUI em tela cheia e recursos poderosos
- Principais recursos:
- Destaque de sintaxe para melhorar a legibilidade do código
- Integração com compilador e avisos/diagnósticos
- Sistema de projeto/build e múltiplas janelas
- Depurador (breakpoints, call stack etc.)
- Ajuda embutida/manuais de referência
- Todos esses recursos ofereciam um ambiente autossuficiente e intuitivo mesmo sem internet no início dos anos 1990
Comparação com o ambiente Linux da época
- O Linux também era dominado por ferramentas baseadas em texto, mas TUIs em tela cheia não eram comuns
- Vim e Emacs, recomendados por livros e comunidades, eram funcionalmente extensíveis, mas para iniciantes eram pouco amigáveis e nada intuitivos
- Por exemplo, o Emacs tinha janela sem enfeites, cores limitadas, suporte a mouse instável e uma interface de menus difícil e pouco familiar
- IDEs como Borland Turbo C++ permitiam criar um programa “Hello World” e explorar o ambiente em poucos minutos, sem qualquer conhecimento prévio
As IDEs baseadas em texto de hoje
- Hoje, os ambientes mais parecidos com as antigas IDEs TUI são RHIDE, Free Pascal e QB64
- O RHIDE é quase idêntico ao Turbo C++, mas é exclusivo para DOS e está descontinuado
- O Free Pascal oferece suporte a ambientes Unix e um ambiente integrado poderoso, com calculadora embutida, tabela ASCII e mais
- O QB64 parece uma TUI, mas na prática é uma simulação de GUI e não pode ser executado em terminal
- Free Pascal e QB64 continuam sendo desenvolvidos até recentemente, mas não têm grande apelo popular por estarem expostos a linguagens antigas
Uma verdadeira IDE de console moderna
- Entre os ambientes integrados baseados em texto mais atuais, Neovim, Doom Emacs e Helix são os mais conhecidos
- Graças a diversos plugins, eles oferecem uma experiência em nível de IDE, mas ainda carecem da integração e intuitividade por linguagem que havia na linha Borland
- Recentemente, o GNU Nano vem ganhando destaque como editor TUI simples, mas não tem recursos de IDE, lembrando mais o WordStar
- No fim, os editores de console de hoje ou não chegam ao nível da experiência dos anos 1990, ou apenas estão recuperando aos poucos recursos de 30 anos atrás
A necessidade de IDEs TUI
- Por melhores que sejam os recursos remotos do VSCode, uma IDE TUI leva vantagem por poder ser usada imediatamente após um acesso SSH à máquina remota
- Além disso, a extensão remota do VSCode não é open source e não funciona em alguns sistemas operacionais, como o FreeBSD, o que impõe limitações
- As IDEs TUI consomem poucos recursos e são ainda mais úteis em ambientes remotos
Inchaço e o fenômeno do "bloat"
- O Borland Turbo C++ incluía todos os recursos e podia ser instalado com menos de 9 MB, funcionando com 640 KB de RAM
- O Doom Emacs atual passa de 500 MB, e as IDEs modernas chegam a vários GB, o que torna o inchaço um problema sério
- O VSCode, com 350 MB, é relativamente leve, mas por ser baseado em Electron ainda consome muitos recursos do sistema na prática
- Houve avanços em recursos, refatoração e outros pontos, mas a inovação em comparação com 30 anos atrás é limitada
- Assistentes de código com IA são uma mudança recente, mas na prática o principal modelo continua sendo a oferta de serviços remotos
Conclusão
- O autor usa diferentes ambientes de desenvolvimento conforme a situação, como Doom Emacs, Vim, VSCode e IntelliJ
- A experiência de desenvolvimento integrada e a eficiência oferecidas pelas IDEs TUI de 30 anos atrás contrastam claramente com o inchaço e a fragmentação das IDEs modernas
- O valor e o potencial das IDEs baseadas em texto continuam válidos, e ainda vale acompanhar como elas vão evoluir e se conseguirão renascer
1 comentários
Opinião do Hacker News
Fiquei bem impressionado ao perceber que o Visual Basic era excelente na área de programação gráfica. Antigamente dava para desenvolver, em um dia, uma aplicação GUI de nível intermediário com muita rapidez. O C# WinForms foi o que mais chegou perto disso, mas é uma pena que todas as ferramentas posteriores não tenham levado em conta a perspectiva do desenvolvedor individual. Proponho como novo paradigma poderoso de desenvolvimento o desenvolvimento baseado em voz/fala (SDD/VDD). Seria ótimo se pudéssemos nos libertar do sofrimento de tanto digitar e se a interação com a IA se tornasse tão natural quanto conversar com um colega. Mas, para isso funcionar de verdade, os modelos de IA precisam ficar muito mais rápidos
O Delphi já era superior ao Visual Basic naquela época e ainda continua utilizável. O Lazarus também segue firme. Na prática, o C# WinForms é o mais próximo da experiência do Delphi
Sempre achei que o Qt Creator oferece uma experiência parecida com a do VB6. Fico curioso se você já usou
Acho que o Emacs ainda oferece todas essas características. O que o autor chama de “não tradicional” vem do fato de ele não estar acostumado com essas convenções. O Emacs é totalmente autodocumentado e interativo. A melhor interface baseada em texto que já usei até hoje é o Magit dentro do Emacs (https://magit.vc/). Queria que mais partes do Emacs fossem como o Magit. Mesmo usando outro IDE, uso o Emacs como cliente git
O Emacs é uma ferramenta histórica, anterior ao desenvolvimento dos atalhos cmd-z/x/c/v pela Apple. Naquela época, entre os atalhos de editores para programadores, o padrão dominante era a linhagem do WordStar (por exemplo, a maioria dos produtos da Borland). Havia IDEs excelentes de 30 a 40 anos atrás que hoje quase ninguém conhece. Por exemplo, o Apple MPW (1986) era um editor GUI em que todas as janelas funcionavam como shells Unix, e você podia controlar janelas e tarefas de edição com shell scripts; ele também tinha um sistema de controle de código-fonte embutido. Você digitava um comando e apertava Option-Return, e surgia uma janela GUI chamada 'Commando' na qual era possível selecionar todas as opções. O Apple Dylan (1992-1995) era um IDE poderoso no estilo Lisp/Smalltalk, e o THINK Pascal e C (1986), o Metrowerks Codewarrior (1993) e o Macintosh Allegro Common Lisp também eram inovadores. Impressiona que IDEs tão sofisticados tenham sido implementados em ambientes de 8~40MHz M68000 com 2~32MB de RAM, nos anos 80 e início dos 90
Quanto à opinião de que o Emacs é autodocumentado e interativo, na prática, quando tive contato com ele pela primeira vez, nem salvar um arquivo era algo fácil de descobrir. Pode ser melhor que o vi, mas ainda falta bastante para um iniciante conseguir usar direto, sem explicação
O Magit é realmente impressionante. Fico me perguntando como chegaram a esse modelo de dados. Dá a sensação de que implementa algo além do próprio modelo de dados do git. Em comparação com a desorganização do porcelain do git, o Magit tem uma estrutura sistemática
IDEs no estilo Turbo-Vision permitem entender a maior parte das funções sabendo só algumas teclas como Alt, Tab, Return, Esc e as setas; já o Emacs não tem essa mesma consistência operacional
Uso o Emacs há mais de 25 anos, então já estou completamente acostumado
O Turbo Pascal era realmente incrível. No começo hesitei em usá-lo por ser uma implementação não padrão de Pascal, mas as ferramentas concorrentes eram caras demais e menos poderosas. Quando experimentei, fiquei totalmente fascinado. Foi ali que vivi uma IDE rápida e intuitiva no IBM PC. Entre as IDEs modernas, a Intellij continua muito à frente dos concorrentes há mais de 25 anos. Faz muito tempo que não uso produtos da Microsoft, então não tenho experiência com VSCode. O Eclipse era lento, pouco intuitivo e cheio de bugs. A JetBrains é uma das raras empresas que mantém sua missão e continua excelente. Impressiona como ela segue dando suporte constante a várias linguagens, padrões e ferramentas sem perder a qualidade excepcional
O Visual Studio ainda oferece suporte a WinForms e a um designer gráfico de formulários, então a experiência é muito parecida com a do Delphi do fim dos anos 90. Isso porque o WinForms imitou descaradamente o VCL
Mas o problema de consumo de recursos é grande. Num desktop em nuvem eu não conseguia usar neovim, então passei a usar ideavim, mas mesmo com 4 núcleos e 16GB de RAM, se eu abrir vários projetos tudo começa a engasgar. Pode ter influência do software de segurança da empresa, mas o VSCode não sofre tanto assim
A IDE do Turbo Pascal estava à frente do seu tempo e era maravilhosamente mágica também no CP/M (especialmente no Z-80). Era melhor do que qualquer outra coisa da época
O texto é de 2023, então talvez o correto fosse atualizar o ano do título para 32 anos atrás. O que mais me incomoda nos TUIs de hoje é que frameworks assíncronos às vezes simplesmente ignoram entradas de teclado. Nos TUIs anteriores a 2000, as teclas ficavam esperando mesmo que o sistema ainda não estivesse pronto. Já nos frameworks TUI “baseados na web” mais novos, se você apertar uma tecla antes de o event listener ser registrado, ela é simplesmente ignorada. Tirando esse problema, o TUI ainda vai muito bem. O Neovim, graças ao LSP e aos plugins, tem o melhor conjunto de recursos de toda a sua história. Não é um TUI baseado em mouse, mas em produtividade é excelente
Na era do DOS, em terminais reais havia buffer de teclado, e quem conhecia bem a interface costumava digitar várias teclas de uma vez e ficar à frente da UI. As entradas iam se acumulando no buffer e apareciam e desapareciam rapidamente na tela. É possível implementar essa estrutura também em frameworks modernos, mas isso exige cuidado
Eu já tinha esse tipo de experiência em 1984, então isso vai até 41 anos atrás. Até produtos GUI como Visual Studio 1.0 ou NetBeans aparecerem, esses projetos iniciais eram o mainstream. Era antes do vim (1991), mas parecia que eu queria janelas flutuantes em vez de ncurses
Esse negócio de ignorar entrada de teclado é enlouquecedor. Antigamente dava para usar o computador em velocidade absurda com combinações rápidas de atalhos; agora parece que estamos andando dentro de melaço pegajoso
Eu não tinha noção exata de quando eram “30 anos atrás”, mas estava esperando ver o browser de sistemas Smalltalk com GUI e fiquei decepcionado ao ver TUI em DOS. Ainda assim, fiquei feliz em lembrar de Turbo C/Pascal, MS C 4.0 e CodeView. Essas ferramentas funcionavam até em modos de 43 ou 50 linhas
Acho que depender demais de um IDE específico pode fazer mal tanto à sua competitividade quanto ao seu código. Falando de IDEs de terminal, o terminal GNU/Linux é o melhor aplicativo que existe. Se você abrir vários terminais num gerenciador de janelas em mosaico, a produtividade vai ao máximo. O escalonamento moderno em telas grandes também é excelente do ponto de vista ergonômico para desenvolvedores
Até hoje ainda desenvolvo e uso um editor/IDE baseado em texto que fiz eu mesmo (https://github.com/alefore/edge). Recentemente escrevi as conclusões de 10 anos de desenvolvimento (https://github.com/alefore/weblog/blob/master/edge/README.md)
No auge do DOS, os caracteres eram gerenciados como um array de bytes e os atributos (cor de fundo, cor de primeiro plano etc.) em outro array separado. Se você quisesse escrever um 'A' em uma posição específica, bastava gravar 0x41 no endereço de memória. Havia um pouco de wait state, mas ainda assim era muito mais rápido do que imprimir com comandos ANSI em um terminal de 9600 baud. O Emacs podia ser usado em terminais seriais lentos ou em emuladores de terminal de workstations Sun, e isso ajuda a explicar por que o TUI baseado em shell desapareceu
Embora o texto foque em IDEs baseadas em texto, acho que isso também vale para IDEs tradicionais como Visual Basic e Delphi. Para iniciantes, eu realmente acho que falta uma IDE de Python. Não uma baseada em texto, mas no estilo Visual Basic: tudo integrado e com uma estrutura fácil de descobrir (isso é importante!). Seria ótimo se tivesse também um construtor de GUI e um depurador embutidos. O editor de código só precisaria de destaque de sintaxe, autocompletar e navegação simples pelo código. Por exemplo, colocar um botão numa janela e, ao dar duplo clique nele no editor GUI, ir direto para o código do handler daquele botão. No passado, algumas pessoas se reuniram para discutir uma ideia parecida, mas a conversa acabou esfriando por divergências sobre qual framework de GUI usar (Pyside, Dear PyGui, baseado na web etc.). Já que falaram de Free Pascal, também vale mencionar o Lazarus (https://www.lazarus-ide.org/), uma cópia do Delphi. É muito bom e segue em desenvolvimento ativo. Só que Object Pascal já não é tão usado hoje e por isso passa uma sensação de algo datado
Concordo totalmente que é preciso uma IDE integrada para Python voltada a iniciantes, no estilo Visual Basic, com construtor de GUI e depurador embutido. Existia uma IDE Python chamada Boa Constructor (https://boa-constructor.sourceforge.net/) em 2000, mas ela nunca se popularizou
Recentemente eu também gravei um vídeo mostrando o processo de criar um app simples em VB3 no Windows 3.11, e o tuíte acabou “viralizando”. No fim das contas, o importante não é o TUI, e sim a experiência integrada de uso
Para mim, o Lazarus é o verdadeiro padrão de IDE. O Lazarus foi feito com o próprio Lazarus, e o autor usa intensamente o próprio produto e fornece exemplos e tutoriais. Também é excelente para ensinar programação a crianças. Assim como o Microsoft Visual Studio, ele integra tagging, busca, ajuda, documentação de API, exemplos de widgets, bibliotecas etc. Outros IDEs não têm esse mesmo nível de integração, e o Xcode, embora se chame IDE, fica devendo bastante perto do Lazarus. Sou tão teimoso que já estou há 6 meses fazendo meu próprio framework de frontend de UI em Go em vez de JS, e espero que um dia eu também possa criar um IDE
As IDEs da Borland eram uma alegria de verdade. Até hoje não encontrei nenhuma ferramenta moderna que entregue uma experiência naquele nível. Claro, existe um pouco de nostalgia nisso, mas ainda assim é divertido até inventar uma desculpa para usar Free Pascal só para trazer de volta aquela interface. Eu também gosto de Pascal. Às vezes uso o Sam e o Acme do Plan 9, mas isso não é IDE, e sim editor. Prefiro ferramentas que me deixem pensar sem me atrapalhar. Há muito o que aprender com os TUIs antigos. Por exemplo, abrir um shell no menu File, executar alguma coisa e depois voltar era perfeitamente aceitável e até heroico. E os atalhos de teclado! Os TUIs antigos adotavam bastante o padrão de atalhos do WordStar, e isso ficou tão impregnado no meu corpo que usar Emacs parece digitar com luvas de forno. Usei joe (alias jstar) por muito tempo. Agora é hora de subir uma VM com Dr. DOS, tentar os desafios do Advent of Code e fazer de propósito uma festa nostálgica ineficiente
Na época do DOS, softwares “profissionais” (como o Emacs) eram projetados para que o usuário vivesse completamente dentro daquele software. Você se fundia à máquina e manipulava atalhos como um organista. Lembro de ver funcionários da Fry’s Electronics operando TUI tão rápido que terminavam o trabalho e a impressão já saía antes mesmo de a tela aparecer direito
Fiquei curioso sobre o que são os bindings do WordStar e por que eles são bons. Tenho interesse em estudar a história desses padrões e as vantagens de cada abordagem
Concordo com o excelente texto. Eu também estou desenvolvendo, no meu tempo livre, um editor de código TUI no estilo Turbo Pascal. No futuro pretendo embutir também make e lldb
Gosto de vários aspectos do Plan 9, mas nunca consegui me adaptar à UI centrada no mouse do Acme. Uma UI que exige mira precisa com o mouse deve ter sido bem desconfortável para uso prolongado ou para pessoas com deficiência
A combinação de djgpp com vi for dos 1991 era imbatível
Usei tanto o Visix Vibe, uma IDE Java, quanto o Delphi, e os dois elevaram enormemente minha produtividade. Eu conseguia estimar com facilidade cronogramas para clientes, desde desenvolvimento de UI e ligação com a lógica até preparação para deploy. O que mais sinto falta, especialmente nessas duas IDEs, é o nível de integração. Você conectava um banco de dados, gerava um formulário e já podia inserir dados e validar tudo na hora. Em poucos dias, isso evoluía para uma UI refletindo os requisitos do projeto. Hoje em dia, é preciso muito mais cuidado no desenho e no planejamento para garantir que UI, API e backend realmente se integrem bem. Acho que não precisamos apenas de IA gerando código de UI; ainda precisamos de ferramentas que permitam desenhar visualmente o código e construir programas pela própria UI. Se alguém lançar uma ferramenta WYSIWYG decente para JUCE, acho que a era de ouro pode voltar
Na era do DOS, havia um array de bytes para representar os caracteres e um array de atributos de cor, e o hardware desenhava isso diretamente. Bastava escrever um valor em um endereço de memória para ele aparecer imediatamente na tela, então era muito mais rápido do que terminais seriais lentos ou saídas baseadas em comandos ANSI. Quando se usava Emacs em terminais de workstations Sun, a lentidão era inevitável, e foi por isso que o TUI desapareceu