Site menu Nostalgia
e-mail icon
Site menu

Nostalgia

e-mail icon

2017.04.13

Este artigo expressa a opinião do autor na época da sua redação. Não há qualquer garantia de exatidão, ineditismo ou atualidade nos conteúdos. É proibida a cópia na íntegra. A citação de trechos é permitida mediante referência ao autor e este sítio de origem.

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. A maioria dos colegas da era 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 dos 20 anos de idade. Ele trabalhou nisso até literalmente poucos dias antes de morrer. Era um dos caras mais inteligentes 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. Certamente já teria se livrado do computador, porque hoje em dia tudo isso faz-se melhor com Smart TV, Netflix e videogame.

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-se "ERP" na época. Aqui na nossa região havia a implicação adicional de se 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", 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 definitivamente 3GL. PHP tem um quê de propósito específico (Web), mas pode ser e é muito utilizada fora do seu nicho.

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 4GLs.) 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? Provavelmente porque os clientes dos respectivos ERPs eram obrigados a comprar licenças de runtime 4GL. Essa venda casada era a "mina de ouro".

Então, os representantes do 4GL contactavam uma software-house, oferecendo ferramenta, suporte e treinamento a fim de formar o mercado. Para a software-house era uma bênção, porque o "normal" era pagar milhares de dólares pela licença de desenvolvimento (que era mais cara que a de runtime). Se alguém daquela época vislumbrasse um ecossistema no estilo Node.js, cometeria suicídio...

A software-house também ganhava alguma coisa com os runtimes, pois a competência técnica a transformava numa representante informal da 4GL na sua região de atuação. Eu mesmo cheguei a funcionar como "vendedor técnico", demonstrando o ZIM para outras empresas.

Lembro que muitos clientes, principalmente os de menor porte, não queriam pagar de jeito nenhum pelas licenças de runtime. Então tínhamos de duplicar cuidadosamente os disquetes das licenças, de modo a reutilizá-las em diferentes clientes, o que não era um problema naquela era de computadores isolados, pré-Internet. E quem pagava, queria pagar o mínimo possível — aí uma empresa com 50 terminais comprava um runtime para 15 usuários simultâneos. Naturalmente a cota estourava, e isso era fonte constante de chamados ao nosso suporte.

Eu e o Emanoel trabalhávamos com essa 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 era equivalente aos bancos+4GL contemporâneos. Ferramentas 4GL têm uma curva de aprendizado inicial muito gentil, era muito fácil desenvolver sistemas típicos com elas, era fácil depurar etc.

O que inclusive criou o mito que "qualquer mané" podia ser desenvolvedor — nos anos 1990 você ganhava cinco vezes mais instalando servidores de rede Novell. O hábito de pagar mal e tratar mal os desenvolvedores ficou tão arraigado que, até onde sei, ainda é o hábito das ERPzeiras locais. (Esses dias um "headhunter" contactou-me em nome de uma delas. Que chique, pensei. Eu tinha sido recomendado por Deus e o mundo. Mas o salário oferecido foi equivalente ao de um cabo da Polícia Militar de SC. Nada contra os cabos da PM, acho que um cabo deve ganhar um salário digno e tal, mas por quanto tempo um PM permanece no posto de cabo? Por dois, três anos depois do ingresso na PM? Pois bem, na "corporação" em que sirvo, eu fui cabo em 1993, sargento em 1994, tenente em 1996, capitão em 2000... Bater continência pra baixo fica complicado.)

Mas estou desviando do assunto. Ia dizendo que as 4GL eram muito fáceis para desenvolver 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. Diferentes ferramentas 4GL têm limitações diferentes, mas essa barreira é algo inerente a uma linguagem de propósito específico.

Vou dar um exemplo do ZIM de 1993. Para gravar um arquivo-texto, que fosse no formato CSV ou naquele formato CNAB 400 para envio aos bancos, 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 do dispositivo de 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.

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.

A parte de 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 essa providência resolvia os problemas de um módulo mas criava ou ressuscitava problemas em 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 no suporte 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, e a portabilidade funcionava mesmo. Trabalhei com o ZIM em inúmeras plataformas: HP/UX, AIX, 386/ix, MS-DOS sobre 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, acesso a qualquer ferramenta de desenvolvimento era tipicamente caríssimo na época, então a filosofia UNIX foi um "choque". Não perdi essa 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é havia 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 uma alternativa clara 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". Imagino o esforço que as pequenas software-houses tiveram de fazer para transicionar de "4GL modo texto" para "3GL Windows cliente-servidor". (Felizmente para mim, Linux já tinha virado meu ganha-pão e já não era mais problema meu.)

Aí vieram mais dois baques. Um já foi citado: a Web. Suporte a Windows era bonitinho, mas suportar Web virou obrigação bem rápido.

O outro baque foi a debacle do modelo cliente-servidor em favor do modelo "três camadas" ou "servidor de aplicação". Inicialmente porque a Web impunha essa arquitetura. Aí todo mundo notou que o código de "business logic", reescrito a duras penas para rodar no Windows 95, nunca deveria ter deixado o servidor.

e-mail icon