AdvPL — As vantagens de uma linguagem proprietária
Este documento foi baseado em minha apresentação no TDC 2020.
The very beginning
E no princípio Deus (do latim DEVSupremus) criou o Clipper,
e viu Deus que era bom… ;)
Tudo começa da necessidade, e não foi diferente com o AdvPL.
No final dos anos 90 todo software precisava rodar no Windows.
E a, então, Microsiga, com seus milhões de linhas de código em Clipper, tinha uma dúvida:
Como levar nosso ERP para o Windows de forma segura, rápida e barata.
A primeira iniciativa foi o porte para o Fivewin que, para quem nunca ouviu falar, era um compilador. Com esforço mínimo, ele compilava o código do Clipper 5.3 para Windows, daí o 5.win.
Mas por ser uma linguagem de 16 bits, os GPF’s eram constantes.
Houveram outras iniciativas e, tecnicamente, o Delphi era a escolha lógica, pois já era uma linguagem consagrada e muito robusta. Mas financeiramente essa reescrita seria muito cara.
Thinking outside the box
Achar a resposta naquela ocasião foi difícil, mas acertamos na mosca:
Porque migrar para uma nova linguagem
se posso simplesmente criar a minha?
Economizando anos com a reescrita de fontes e toda uma refatoração de testes.
Falando dos desafios
O primeiro obviamente significava pensar no futuro, garantindo a extensão de features e a evolução contínua, porque mantendo sua própria tecnologia, você vai depender muito do seu próprio time.
Decidiu-se, então, por um ambiente Client/Server, inspirado nas estações gráficas CAD/CAM, que focavam processamento na GPU nas workstations e na CPU na camada servidora.
Outro desafio era como me comunicar com um SGDB através de comandos ISAM?
A saída foi adquirir o DBAccess, na época chamado TopConnect, uma engine que traduzia comandos ISAM em instruções SQL.
Falando agora de front-end, o qual eu sou o PO hoje, o time voltou os olhos novamente para o Delphi, escrevendo o primeiro SmartClient nesta linguagem.
And the last but not least, era necessário compilar e depurar nesse novo ambiente e o DevStudio em Delphi se tornou nossa primeira IDE.
E misturando tudo isso, com o bom e velho jeitinho Brasileiro, nascia em 1997, o Protheus 5.07.
Always looking forward
Com a plataforma pronta, a evolução foi uma questão de dar os próximos passos, porém sempre com muito cuidado, mantendo a compatibilidade com a linguagem mãe.
Começamos estendendo o ecossistema para novos Sistemas Operacionais.
Garantindo esforço zero aos nossos Dev’s, pois o refactoring de código é muito caro, e para uma empresa como a TOTVS, que vende customizações, seria ainda mais caro.
E principalmente garantindo esforço zero aos nossos clientes, muitos deles com times próprios de desenvolvimento, pois com nosso ERP você pode literalmente reescrever uma rotina de acordo com sua necessidade.
Lembram do título deste documento?
As vantagens de se manter uma linguagem proprietária.
A partir deste momento, sem qualquer treinamento, nossos Dev’s passaram a desenvolver para multiplataforma, usando o mesmo código fonte.
Falando de outros Sistemas Operacionais, os dispositivos móveis eram o próximo passo.
E nossos Dev’s passaram a desenvolver para dispositivos móveis…
Com o uso do nginx foi possível “fazer” nossa camada servidora se comunicar via HTTP, possibilitando o usar o HTML5 como interface, estendendo assim o ERP à qualquer dispositivo com navegador.
Inclusive os Single Board Computers, barateando a implantação de novas workstations aos nossos clientes.
E nossos Dev’s passaram a desenvolver para o mundo Web…
E já que falamos do mundo ARM, seria possível compilar nativamente nossa plataforma para esses pequenos notáveis.
E também para outros dispositivos ARM que vem chegando por aí, como o Windows ARM e o MacOS Big Sur, que está pronto para rodar aplicativos do iPad em desktops.
E nossos Dev’s passarão a desenvolver para o ARM…
Voltando a falar um pouco de navegadores, ainda tínhamos um gap, que era o acesso ao dispositivo, e com o uso do ElectronJS foi possível aliar a Interface HTML5 à leitura e gravação de arquivos, e a execução de programas e Dlls nativas nas workstations, características bloqueadas nos navegadores por questões de segurança.
E quando falamos de ERP é muito importante pensar em integrações, um exemplo é nossa integração nativa com o Microsoft Office, mas nossas APIs permitem integração com diversas soluções.
Mas falar de integração vai além, precisamos manter conectividade com periféricos, através de chamadas nativas.
E mais uma vez nossas APIs permitem que os clientes integrem toda uma gama de equipamentos, sem depender de nós, apenas usando o modelo: faça você mesmo…
Mas talvez de tudo que comentei, o mais importante seja ter pleno controle quanto às mudanças, e caminhos que podemos seguir.
- Estendendo novos protocolos
- Criando novas funções conforme a necessidade
- Agregando novas ferramentas
- Decidindo por novos caminhos, sem nunca perder o foco no legado
