Site menu 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 um conceito vendido como "melhor que 3GL", afinal 4 é maior que 3, certo? Porém a definição formal de 4GL é linguagem de propósito específico, ou seja, mais restrita e não necessariamente melhor que uma linguagem de uso geral (3GL). É um conceito estranho para os dias atuais, já que todas as linguagens em uso corrente (Java, Python, Javascript, C, etc.) são 3GL. PHP tem um quê de propósito específico para Web, mas é poderosa o suficiente para ser largamente utilizada fora da Web.

Voltando a 1993. Havia um bom número de produtos verticais, 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. (Bons produtos 4GL como o PowerBuilder não eram verticalizados, e os melhores bancos de dados nunca impuseram o uso de sua 4GL.) 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.

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.

Ferramentas 4GL 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 desenvolvimento de software seria trabalho de secretária, tal qual datilografia. Havia promessas de ferramentas ainda mais fáceis de usar, tipo CASE. (Essa moda vem e vai periodicamente. Em 2020 falou-se muito de "ferramentas no-code".)

Destas impressões, resultava que programação era uma ocupação um tanto quanto depreciada. Era algo que alguém fazia 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.

Mas ia dizendo que as 4GL tornavam muito fácil o pão-com-manteiga. Porém, bastava desviar um pouquinho do trivial, e a coisa ficava rapidamente difícil. É 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 arquivo 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. Uma coisa é certa: se você usa C para prototipagem, é porque a coisa tá feia!

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 um "sabor" diferente de pseudo-terminal). 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 que acabávamos adotando era 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, 386/ix, MS-DOS, rede Novell, e Edisa (um minicomputador brasileiro baseado em 68000 com seu próprio sabor de UNIX).

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 acabou tendo 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á tinha virado meu ganha-pão.)

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.