Nostalgia
Nostalgia
Nota: esta é a tradução de um texto antigo, cujo inglês estava tão quebrado que não deu vontade de consertar. Além disso, muitas informações não fazem sentido a um público não-lusófono, e por último me fez lembrar de momentos felizes com o falecido amigo Emanoel.
A infame reserva de mercado brasileiro de informática, de 1978 a 1992, teve um efeito colateral curioso: expôs toda uma geração de informatas (os quarentões como eu) a uma evolução acelerada da tecnologia. Em termos relativos, é claro. Comecei em 1987 tendo contato com tecnologias do final dos anos 1970: CP/M, Apple II, Sinclair... A geração anterior, do mainframe, experimentou aceleração ainda mais intensa, e muitos não conseguiram fazer o transbordo para a microinformática.
Então, num certo sentido, posso alegar que tenho uns 40 anos de "experiência", para o bem e para o mal. Certamente a calvície é coerente com essa experiência acelerada.
Um fator adicional: eu era analista de sistemas ERP até 1999 e então migrei para engenharia de software. Não conheço muita gente que fez esse transbordo, porque é como mudar de profissão. Muitos colegas da fase ERP ainda trabalham com ERP, e nas raras funções sociais em que temos contato, não falamos de informática.
O próprio estilo de vida é bem divergente. Por exemplo, eu tinha um amigo, o Emanoel, que escreveu um sistema MRP completo antes de completar 20 anos. Ele trabalhou com ERP até literalmente poucos dias antes de morrer.
E sim, ele sabia que ia morrer. Ainda assim, trabalhou em casa, de cama, no hospital, aonde estivesse, do jeito que dava. Estranho? Certamente era uma distração bem-vinda para ele, uma satisfação sentir que o cérebro ainda funcionava. Foi um dos caras mais inteligentes e trabalhadores que conheci.
Agora o detalhe: ele não teve computador em casa até a maior parte da década de 2000! E só comprou um para jogar, e depois para baixar filmes. Se estivesse vivo, certamente já teria trocado o computador por uma Smart TV e um PS5.
Gente estranha essa, que não tem pelo menos dois computadores ligados 24x7 em casa, e não fuça pelo puro prazer de fuçar...
Trabalhamos juntos numa software-house (hoje seria uma "fábrica de software"?) entre 1993 e 1994. Ser programador, naquela época, no Brasil, significava desenvolver sistemas empresariais — nem chamavam de ERP na época. Aqui na nossa região havia a implicação adicional de usar alguma linguagem de programação de quarta geração (4GL). Havia software-houses que usavam Clipper, mas eram consideradas de estirpe inferior.
4GL era vendida como uma evolução natural e irreversível sobre 3GL. Porém, o real significado de 4GL é linguagem de propósito específico, enquanto 3GL significa linguagem de propósito geral. Uma 4GL é especializada em um nicho, portanto sua aplicação é intrinsecamente mais restrita que uma 3GL. E não há garantia que a 4GL será necessariamente melhor que 3GL, especialmente conforme o tempo passa e as necessidades daquele nicho vão mudando e expandindo.
O tempo provou que as 3GL são melhores. Todas as principais linguagens em uso corrente (Java, Python, Javascript, C, C++, Go, Rust, etc.) são 3GL. A linguagem PHP tem um quê de propósito específico para Web, mas pode ser e é utilizada fora da Web.
Muitas 4GL acopladas a bancos de dados tentavam ser "facinhas", para que usuários finais pudessem "escrever seu próprio software", eliminando ou diminuindo a necessidade de programadores profissionais. Quantas linguagens e ferramentas já foram criadas com essa premissa? COBOL, SQL, CASE, geradores de relatórios de todos os matizes, hoje em dia é o tal do low code/no code...
Além de não conseguir satisfazer os usuários leigos, quase todas as ferramentas nassa linha abespinham os programadores obrigados a lidar com elas. O próprio PHP tem esse ranço: na tentativa de ser "facinho" para Web designers que precisavam de apenas uma pitada de processamento server-side (esse era o público-alvo original do PHP) a linguagem ficou cheia de idiossincrasias, inconsistências e feiúras.
Voltando a 1993. Havia um bom número de produtos verticalizados, bancos de dados que embutiam uma 4GL: Progress, ZIM, Informix, Dataflex, Mumps, Accel/Unify, etc. Uma vez adotado um banco de dados, você era obrigado a usar a 4GL embutida. Aí, cada software-house adotava uma 4GL, e criava-se uma enorme rivalidade entre facções de desenvolvedores, cada qual exaltando as virtudes da "sua" 4GL.
(Parênteses: Bons produtos 4GL como o PowerBuilder eram desacoplados de qualquer banco de dados, e os melhores bancos de dados nunca impuseram o uso de uma 4GL. Mesmo na época, sentíamos que as soluções verticais eram cheias de idiossincrasias, e não conheço nenhum técnico que lamente o progressivo desaparecimento delas.)
Mas por que cada empresa adotava uma 4GL diferente? Porque os clientes dos produtos derivados dela eram obrigados a comprar licenças de runtime 4GL. Essa venda casada era a "mina de ouro".
O representante nacional de uma 4GL precisava criar um mercado para ela, com o objetivo final de vender runtimes. Então procurava as software-houses, oferecendo gratuitamente as ferramentas de desenvolvimento. Para a software-house, isso era uma dádiva dos céus, porque nessa época uma licença de desenvolvimento para qualquer linguagem era caríssima. (Ninguém vislumbrava ecossistemas baseados em software livre, como é o padrão hoje em dia.)
A software-house também ganhava comissão nos runtimes, o que em tese inibia a pirataria. Além disso, a competência técnica transformava a software-house numa representante informal da 4GL em seu entorno. Eu mesmo cheguei a funcionar como "vendedor técnico", demonstrando o ZIM para outras empresas. Todos esses incentivos levavam cada software-house a adotar uma 4GL diferente, e criar um pequeno feudo em torno dela.
Faltou explicar o que é "ZIM". Pois é, eu e o Emanoel trabalhávamos com uma solução 4GL denominada ZIM. É um produto tão obscuro que, para você ter uma ideia, não há entrada na Wikipedia para ele. Mas foi relativamente popular no Brasil: a representante local, que se não me engano era sediada em Porto Alegre, fez um bom trabalho.
Como disse antes, ferramentas 4GL tentam ser "facinhas", e de fato têm uma curva de aprendizado inicial muito gentil. Era muito fácil desenvolver sistemas no estilo "CRUD" com elas, era fácil depurar, etc. Parecia que qualquer mané munido de uma 4GL virava um desenvolvedor pró. Alguns chegavam a dizer que era uma profissão sem futuro, pois em breve programação seria trabalho de secretária, tal qual datilografia. Havia promessas de ferramentas ainda mais fáceis de usar, tipo CASE.
Por conta dessa mitologia, programação era uma ocupação meio depreciada. Era algo que alguém fazia por hobby e por gosto, ou para pagar as contas até arrumar um trabalho "de verdade". (Instalar servidores de rede Novell era considerado trabalho de verdade, e pagava muito mais, apesar de ser muito mais fácil.)
Uma vez que cada software-house usava uma 4GL diferente, era difícil trocar de emprego. Quem tentava, descobria que o bullying com novatos era bem forte (não nessa empresa em que trabalhei, felizmente). Arraigou-se profundamente o hábito de pagar mal e tratar mal a equipe de desenvolvedores.
Para desenvolvimento típico de ERP — CRUDs, relatórios — o 4GL era realmente fácil. Porém, se a tarefa desviasse um pouquinho do usual, o desenvolvimento ficava exponencialmente mais difícil. Chamo isto de "a barreira do som" 4GL.
Vou dar um exemplo do ZIM de 1993. Para gravar um arquivo-texto, que fosse no formato CSV ou naquele formato bancário CNAB 400, precisávamos usar os recursos do gerador de relatório. Não havia funções de manipulação de arquivos no ZIM. O único subterfúgio disponível para escrever um arquivo externo era gerar um relatório, apontando o destino para um arquivo em vez da impressora. Mas o formato de dados precisava ser cuidadosamente especificado, como se realmente fosse um relatório... e não era permitido escrever bytes fora da tabela ASCII e tal.
Era mais fácil gerar um arquivo-texto em C que em ZIM. De fato, cheguei a prototipar e depurar formatos complicados em C. Isso dá uma boa noção de quão barroco era desenvolver certas coisas em ZIM.
Essas linguagens 4GL, além de pouco expressivas quando utilizadas fora do nicho imaginado pelos criadores, também careciam de qualquer mecanismo de extensão. Se escrever um arquivo-texto em ZIM era difícil, comunicar-se com um serviço REST ou mesmo abrir uma conexão TCP/IP era impossível. O contrário também era verdadeiro: pelo menos o ZIM não oferecia uma API para software escrito em outra linguagem acessar o banco de dados.
Em 1999, a tal software-house ainda usava ZIM, e fui comissionado para desenvolver um "gateway de e-commerce". Tradução: uma gambiarra que permitisse a uma aplicação Web comunicar-se com o banco de dados ZIM. Foi de longe a coisa mais feia que já desenvolvi na vida. Veja bem: o ZIM suportava um modo prompt, e foi este o meu subterfúgio. Cada sessão Web abria um prompt ZIM. Meu gateway traduzia requições CGI para as consultas a-la-SQL, que eram repassadas ao prompt ZIM via pseudo-terminal. O resultado que o ZIM imprimia no "terminal" era novamente traduzido pelo gateway e virava HTML.
Por incrível que pareça, o troço funcionava, e funcionava em três sabores de UNIX (deu trabalho, porque cada um tinha uma API diferente para pseudo-terminais). Era para uso em ambiente controlado (Intranet), e era uma época mais inocente em termos de preocupações com segurança. Mas a versão MS-DOS da gambiarra conseguia ser pior ainda. Na ausência de mecanismos como subprocessos e pseudo-terminais, a única solução que encontrei foi postar consultas CGI como arquivos. Um certo número de sessões ZIM (executando continuamente) lia esses arquivos, e o resultado do processamento era postado como um arquivo de retorno. Exceto pela latência maior que a versão UNIX, também funcionava.
O banco de dados do ZIM era um pesadelo quando havia muitos usuários concorrentes, devido ao page-based locking e ausência de mecanismos como MVCC. Sem MVCC, até transações de leitura acabam travando. (É bem verdade que bancos bem mais modernos como o MS-SQL tinham problemas similares até uma boa década depois.) A solução oficial para problemas de concorrência era manipular uns parâmetros "mágicos" de calibragem. Geralmente isso resolvia um problema, mas criava ou ressuscitava dois outros.
A solução final acabava sendo quebrar uma transação lógica em diversas transações menores, ou abolindo completamente a declaração de transação (cada comando individual era então automaticamente encapsulado em sua própria transação). É obviamente uma solução de borra — se o processo for abortado, a transação lógica original vai garantidamente ficar pela metade. Mas era melhor aceitar esse risco do que ouvir o cliente reclamando que a empresa inteira parou por uma hora, só porque o contador resolveu imprimir um balancete.
É preciso ser justo e lembrar um ponto forte desses bancos de dados 4GL, que lhes colocavam num patamar acima de soluções como o Clipper: eles eram altamente portáveis. Trabalhei com o ZIM em inúmeras plataformas: HP/UX, AIX, XENIX/SCO, MS-DOS, rede Novell, e Edisa (minicomputador brasileiro baseado em 68000).
Trabalhei no suporte técnico e depois como desenvolvedor. Foi no suporte que entrei em contato com o UNIX. Fiquei surpreso com a existência de um compilador C gratuito dentro do sistema — como eu disse antes, qualquer ferramenta de desenvolvimento era rara e cara. Neste ponto a filosofia UNIX foi um choque. Não perdi a oportunidade de aprender C. Mais tarde essas experiências me conduziram ao Linux, e o resto é história.
O suporte técnico era uma área estressante — por isso mesmo mudei para desenvolvimento — mas às vezes tínhamos muito tempo livre, semanas inteiras de calmaria. Aqui devo "tirar o chapéu" para meus patrões e chefes que me facultavam usar o tempo livre como bem entendesse. Também havia uma pequena biblioteca com livros técnicos, entre eles o K&R, isso numa empresa onde o interesse comercial por C era nulo!
O golpe fatal no ZIM foi a popularização do Windows e do modelo cliente-servidor que veio de arrasto. Até houve o "ZIM para Windows", mas era muito fraco. Aquele meu ex-empregador teve de fazer uma dura escolha entre Java, Visual Basic ou Delphi, e acabou reescrevendo o sistema inteiro em Delphi. Curiosamente, o Clipper foi "morto" pelo mesmo processo: falhou em oferecer um caminho viável de migração para o Windows.
Na época, o famoso artigo de Joel Spolsky não era conhecido, e muito menos a regra de ouro: "nunca reescreva software". As pequenas software-houses tiveram de investir o que não tinham para transicionar de "4GL modo texto" para "3GL Windows cliente-servidor". Felizmente, isso já não era mais problema meu, pois Linux já era minha ocupação em tempo integral.
Depois vieram mais dois baques: a Web e a debacle do modelo cliente-servidor, o que impôs mais um bocado de reescrita de código. A cada baque, desapareceu um punhado de software-houses, geralmente absorvidas por outras maiores. Até a legendária Datasul daqui da terrinha acabou comprada pela Totvs.
Na minha opinião, sobreviveu no mercado ERP quem controlava suas próprias ferramentas de desenvolvimento, logrando assim surfar cada nova onda da tecnologia sem ter de reescrever tudo de novo. O caso mais célebre é o SAP, que tem sua própria linguagem e seu próprio banco de dados.
Outro problema do ERP é a eterna necessidade de customização. Cada cliente tem necessidades peculiares, e clientes grandes vão querer desenvolver suas próprias extensões. A solução é disponibilizar o ambiente de desenvolvimento a clientes ou consultores externos. Novamente, isso é mais fácil de fazer quando a mantenedora do ERP controla o ambiente de desenvolvimento, e novamente a SAP é o 'case' de sucesso.