3 pontos por GN⁺ 2023-11-16 | 1 comentários | Compartilhar no WhatsApp
  • Como o Excel se tornou a base dos processos de trabalho em muitas organizações, quando é preciso uma pequena automação, o VBA acaba sendo a escolha padrão de fato
  • A organização do exemplo tem 13 plataformas de dados e várias ferramentas de automação, mas as ferramentas com acesso amplo às fontes de dados necessárias se reduzem, na prática, a VBA e PowerShell
  • A CyberSecurity recusou a instalação de linguagens de alto nível como Python, Ruby, Node e Rust, e a alternativa, a Power Platform, mostra limitações em acesso a dados e na manutenção de algoritmos complexos
  • Os casos anteriores de Lotus Notes e IBM BPM mostram que sistemas conduzidos por TI podem ser vulneráveis a fim de suporte, migrações incompletas e lacunas de manutenção
  • O VBA é antigo e tem fraquezas, mas vem incluído no Office, é acessível a todos e oferece controle para que SMEs possam validar diretamente a lógica de negócio e a migração de dados

Motivos diretos pelos quais o VBA continua sendo escolhido

  • Em uma pesquisa de 2021 no /r/vba, a maioria dos usuários de VBA respondeu que usa VBA porque não há outra opção
  • Muitas organizações operam processos de trabalho inteiros no Excel e, quando precisam de um pouco de automação, o VBA costuma ser a primeira escolha
  • Por trás da crítica de que “parte da infraestrutura é controlada por planilhas”, existem restrições nas ferramentas fornecidas pela organização, no acesso aos dados e na estrutura de manutenção

Acesso a dados e limitações das ferramentas de automação

  • A área de engenharia da organização do exemplo pode usar várias plataformas de automação
    • OnPrem: PowerShell, VBA do Excel / OfficeJS limitado / OfficeScripts / PowerQuery, PowerBI Desktop, SAP Analysis for Office
    • OnCloud: PowerApps, Power BI, PowerAutomate não premium
    • Ambientes sandbox: ArcPy do ArcGIS, MapBasic do MapInfo, Ruby do InfoWorks ICM, ArcGIS Online
  • As plataformas de dados gerenciadas por TI vão de D1 a D13 e incluem banco de dados geoespacial, banco de dados SAP, plataforma de telemetria, SharePoint, Lotus Notes, IBM BPM, sistemas de arquivos, Hydraulic Model Information, entre outras
  • As plataformas de automação capazes de se conectar às fontes de dados necessárias acabam se resumindo a VBA e PowerShell
    • O Power BI Desktop foi adotado pela organização, mas não cobre todas as plataformas acessadas pelo VBA
    • Mesmo que o escopo de acesso fosse igual, o Power BI é difícil de usar para automação de processos e, para lidar com outros datasets, usa-se a abordagem de gerar CSVs e salvá-los no SharePoint
    • Em alguns casos, essa geração de CSV também fica por conta do VBA
  • Algumas conexões do VBA com serviços OnCloud se baseiam em tentativas diretas; considera-se que SAP BW4HANA e outros serviços em nuvem também possam ser integrados via VBA, mas os requisitos de autenticação e os protocolos ainda não foram resolvidos

Limitações de linguagens de alto nível e da Power Platform

  • A organização queria usar linguagens de alto nível como Python, Ruby, Node e Rust para automação de trabalho, mas todas as solicitações de instalação para equipes ou para a empresa em geral foram recusadas pela CyberSecurity
  • O motivo da recusa foi que permitir a usuários finais acesso a linguagens de programação de alto nível contrariava a visão da estratégia tecnológica da empresa
  • As alternativas mencionadas, PowerAutomate e PowerApps, quase não conseguem acessar os dados necessários
  • Mesmo quando o acesso aos dados é possível, a Power Platform é insuficiente para executar a maioria dos processos
    • Os algoritmos necessários são complexos, por isso soluções em PowerAutomate podem ser difíceis de manter e até de entender para a equipe de TI
    • Como exemplo, são mencionados projection algorithms
  • No fim, as ferramentas que permanecem viáveis na prática são PowerShell v3 e VBA
    • O PowerShell v3 não oferece suporte à sintaxe de classes, e também não é possível instalar módulos
    • O VBA acabou sendo o alvo de centenas de horas de trabalho para criar open source VBA libraries, a fim de reforçá-lo como uma linguagem razoável segundo padrões modernos

VBA como garantia de manutenção

  • Nos anos 2000, muitos sistemas foram construídos sobre bancos de dados do IBM Lotus Notes
  • Depois que o Lotus Notes foi adquirido pela HCL em 2019, a continuidade do suporte ficou instável, e o encerramento oficial do suporte estava previsto para junho de 2024
  • A partir de 2019, a equipe técnica tentou migrar vários sistemas para novas tecnologias, e a organização investiu muito no desenvolvimento de um sistema baseado no IBM Business Process Manager para substituir um banco de dados Lotus Notes
  • O plano era preencher o D11 com todos os dados do D10 e depois arquivar o D10, mas a situação em 2023 era diferente
    • Restavam 8 meses até o fim do suporte oficial
    • A equipe técnica eliminou o contrato de suporte do IBM BPM
    • Não havia um sistema substituto visível nem para o IBM BPM nem para o banco de dados Lotus Notes
    • A solução IBM BPM tinha pouca manutenção e não funcionava como necessário
    • Uma solução inadequada para o propósito foi forçada dentro do IBM BPM
    • Há uma API REST, mas ela é quase inútil para a equipe técnica e para os SMEs
      • Algumas chamadas REST usam JavaScript codificado como string
      • Outras chamadas exigem colocar HTML dentro de JSON dentro de XML
      • As tabelas do DB são consultadas por GUID, não por nome
      • Não há documentação dizendo qual GUID corresponde a qual tabela ou processo
    • Os dados do D10 não foram realmente migrados para o D11, então o negócio usa 2 sistemas, não 1
    • O modelo de dados do D11 também não oferece suporte adequado aos dados do D10
  • SMEs usam as ferramentas todos os dias e são quem decide quais mudanças no sistema são necessárias
  • Quando SMEs usam VBA, podem controlar e manter os sistemas diretamente na medida necessária, o que funciona como uma garantia de manutenção que sistemas de TI não asseguram

Controle e problemas de colaboração com SMEs

  • Um projeto recente consistia em criar um novo sistema integrado de TI para substituir uma planilha essencial ao negócio; se desse certo, a importância do D6 cairia para o nível C
  • A especificação inicial era simples
    • Servidor NodeJS e banco de dados MySQL
    • UI em React
    • Fornecer acesso ao código-base e ao git para administradores e SMEs
    • TI e SMEs colaborariam para construir o sistema
  • A equipe técnica apresentou outras exigências
    • Administradores e SMEs não teriam acesso ao código
    • O front-end seria construído em Microsoft PowerApps para se alinhar à “Strategic Vision”
    • O back-end seria construído em Microsoft Azure Pipelines para se alinhar à “Strategic Vision”
  • Do ponto de vista dos SMEs, essas exigências criam vários problemas
    • Como a equipe técnica não entende o trabalho do dia a dia, é difícil para ela compreender a lógica de negócio e os cálculos
    • Se desenvolvedores escreverem a lógica de negócio, erros ficam mais prováveis
    • A equipe técnica frequentemente abandona projetos tecnológicos sob medida, fazendo desaparecer os recursos de manutenção e melhoria
    • Ao colaborar com SMEs, pelo menos uma equipe consegue manter recursos para sustentar o sistema
    • SMEs precisam poder confiar nos resultados, mas, se o código não estiver visível, é difícil confirmar se ele funciona em todos os casos de borda
    • Mesmo que existam testes unitários, se o código não estiver visível é difícil verificar se os testes existem e são executados com frequência
    • SMEs melhoram e mantêm sistemas legados existentes e têm muito conhecimento sobre as interações entre sistemas
    • Para confirmar que todos os dados foram migrados e representados corretamente no novo sistema, é necessário acesso ao back-end
  • Se o código permanecer em VBA, SMEs e o negócio mantêm o controle
  • A equipe técnica entrega pouco controle às equipes de negócio, e SMEs conseguem verificar se o software é desenvolvido de forma modular adequada, em vez de virar um amontoado de tecnologias frouxamente conectadas

Experiência do usuário dentro de um ambiente familiar

  • A maioria dos engenheiros usa planilhas no trabalho diário
  • Como o VBA é embutido nas planilhas, ele pode oferecer ferramentas desconhecidas dentro de um ambiente familiar
  • Colocar novos recursos dentro de um ambiente familiar pode ser mais poderoso para os usuários do que oferecer uma ferramenta desconhecida em um ambiente desconhecido

Conclusão: as fraquezas do VBA e a escolha realista

  • Há vários motivos pelos quais organizações escolhem planilhas e VBA
    • Por preocupações de segurança, as alternativas oferecidas pela TI são fracas
    • Ferramentas alternativas não conseguem se conectar adequadamente aos sistemas de origem e, em geral, ainda estão em andamento
    • Há problemas de estratégia de TI que não contemplam alguns casos de uso
    • Por preocupações de segurança e manutenção, não se quer colaborar com SMEs
    • Usuários, administradores e SMEs não recebem treinamento suficiente nos sistemas substitutos
    • Usuários e SMEs querem certo nível de controle sobre a lógica de negócio dos sistemas
    • É a única tecnologia viável incluída no Office e disponível para todos
  • O VBA não deixa de ter fraquezas
  • Há alguns pontos corretos no texto da mataroa
  • Às vezes a gestão é péssima, mas muitas pessoas nas organizações tentam fazer a coisa certa com as ferramentas que recebem

1 comentários

 
GN⁺ 2023-11-16
Comentários do Hacker News
  • Nas empresas, já existe dentro do Excel um ambiente de desenvolvimento que não exige passar por gerência, alta gerência, registro de projeto, orçamento, designação de gerente de projeto etc. para obter aprovação de software fora do inventário
    Se quiser também armazenamento de dados em rede e interface web, basta acoplar o SharePoint. As soluções surgem nessa direção voltada ao usuário final, e essas soluções são feitas em VBA

    • No ambiente distópico que é uma empresa, não se deve esperar poder solicitar ou instalar software no próprio dispositivo. Só dá para usar o que já existe, e para mudar algo é preciso brigar com a burocracia, então não vale a pena
      Antigamente havia um horrível mecanismo de relatórios feito em Word VBA que lia definições de relatórios de um compartilhamento de arquivos, recortava e colava pedaços de templates e depois imprimia. Como o TI não recolheu o PC de uma pessoa que saiu da empresa, usávamos aquela máquina o dia inteiro para rodar .doc e gerar relatórios de engenharia, o que era muito mais rápido e barato do que comprar a opção de relatórios do software CAD/CAM. Essa opção teria exigido pelo menos 18 meses, consultores e consumo de orçamento de projeto
      Quando as pessoas reclamam que se fazem coisas horríveis com Excel VBA, é bem provável que a causa esteja mais acima na stack. Outra causa é o “martelo do macaco”: se você dá um martelo a um macaco, ele sai batendo em tudo; se a única ferramenta que você tem é VBA, tudo parece uma solução em VBA. Hoje nos tornamos primatas um pouco mais evoluídos
    • Vi pelo menos duas vezes a cena em que um gerente de departamento precisava de algo, mas não podia ou não queria incomodar a equipe de desenvolvimento, e começou com “quão difícil pode ser?”. De repente, havia algumas centenas de linhas de VBA resolvendo a necessidade dele
      Na etapa seguinte, Jim também quer rodar aquilo, então o script é copiado; Jane usa outra versão do VBA e ele é modificado; agora aparece um “e isto também!”, e a coisa se expande. No fim vira um remendo de 1.500 linhas, e tentam passar a manutenção para a equipe de desenvolvimento
    • Um amigo automatizou todo o próprio trabalho com Excel. Ele diz que termina um dia de trabalho em 15 minutos e passa o resto do tempo descansando
      O computador da empresa é extremamente bloqueado, ele não consegue instalar nada nem acessar sites que não estejam na lista branca, mas tem Excel
    • O próprio Visual Basic também é uma linguagem muito poderosa. Em ambientes como macros do Excel, é possível extrair bastante desse poder, e muitos power users de empresas realmente fazem isso
      É bem parecido com aplicar o antigo paradigma do “sistema operacional Emacs” em outro contexto
    • VBA está lá e funciona. É uma linguagem muito acessível e intuitiva para programar e iterar, sem precisar desperdiçar tempo instalando dependências externas, caindo no inferno das bibliotecas ou passando por uma etapa de compilação
      Portanto não surpreende que VBA ainda seja muito valioso nas empresas. Mesmo em ambientes com outras ferramentas e linguagens e processos de build maduros, vi gerentes de produto fazendo análises de negócios incrivelmente complexas em VBA, e para o problema que tinham em mãos aquela era a ferramenta certa
  • Fiquei surpreso ao ver que desenvolvedores profissionais também usam bastante Excel/VBA como ferramenta auxiliar
    Alguns anos atrás, ao trabalhar com um grande hedge fund, um analista de dados me enviou um modelo em Excel que ele mesmo havia criado; ao ver a extensão .xlsm, imaginei que havia código VBA ali. Pensei: “vamos ver o que esses caubóis do gravador de macros fizeram”. Mas por dentro havia bastante VBA, e o autor era um analista de dados formado em ciência da computação pela Caltech, muito bom em Python
    O VBA era usado para buscar dados do banco de dados, colocá-los nas planilhas, criar fórmulas e aplicar uma formatação apresentável, e havia também alguns UserForms. Brinquei: “VBA? O que vocês usam por aí também? Descaroçador de algodão e escavadeira a vapor?”. Para minha surpresa, ele elogiou muito o Excel e o VBA
    Uma frase dele ficou na minha memória: “O Excel torna fácil entender a estrutura de dependências implícita nos cálculos. Se eu tivesse feito isso em Python, teria passado o dia inteiro respondendo perguntas”

    • Quanto mais experiência se ganha como desenvolvedor, mais importante fica usar a ferramenta certa para o trabalho. Às vezes uma solução preguiçosa é muito melhor do que um amontoado de ideias impossível de entender
    • VBA tem problemas (https://sancarn.github.io/vba-articles/issues-with-vba.html), mas está longe de ser a pior ferramenta. Por exemplo, é melhor do que algo como PowerAutomate
      VB6 tem uma comunidade razoavelmente grande, e https://twinbasic.com/ recentemente ajudou bastante a unificar as comunidades de VBA e VB6. Por isso talvez haja uma pequena ressurreição na comunidade de desenvolvedores
    • O negócio que opero depende muito do Google Sheets. Injetando valores e lendo os valores calculados, conseguimos definir uma lógica de negócios bastante complexa em forma de planilha, e as pessoas de negócios e finanças conseguem ajustá-la facilmente. Todos estão muito satisfeitos com essa solução
    • O Excel é uma excelente interface para muitas coisas e, até certo ponto, ajuda as pessoas a entenderem dados. Por outro lado, as pessoas se acostumam a esse modelo de dados e, quando algo fica um pouco complexo, tendem a se culpar em vez de fazer perguntas
      Na Suécia existe até um modelo de previsão de aposentadoria em Excel/VBA de 3 GB com um manual do usuário de 38 páginas. Mas é difícil dizer que seja um bom exemplo de uso do Excel: https://www.pensionsmyndigheten.se/statistik-och-rapporter/p...
    • Uma clínica de internação pré-operatória de um grande hospital universitário era operada no Excel
      VBA é poderoso e permite prototipagem e iteração rápidas. Dá até para dizer que o VB6 foi o auge dos apps CRUD
  • “Porque é surpreendente”
    Ouvi dizer que, antigamente, havia mais de 20 mil bancos de dados Access na rede do JP Morgan. Analistas de dados de várias empresas um dia se cansaram do trabalho que faziam todos os dias e foram olhar o botão “Gravar macro”. Algumas pessoas acharam aquilo bem conveniente e continuaram usando. Outras foram mais espertas: olharam o código que a macro cuspia, aprenderam um pouco e tentaram modificá-lo
    Uma minoria chegou a aprender estruturas de dados e algoritmos para criar sistemas de autenticação e autorização imitando o Django, recriar interfaces UserForm do zero e implementar Markdown, parsing SAX, barras de rolagem customizadas, logging e até jogos
    A resposta provavelmente é que os analistas de dados ficaram entediados com o trabalho diário

    • Também pode ser que o departamento de TI, de sua torre de marfim, tenha imposto procedimentos demais, empurrando as pessoas para a TI paralela. Em grandes empresas, vi analistas que tinham capacidade de levar seus Frankensteins a um nível adequado serem bloqueados com coisas do tipo “é preciso iniciar um projeto e criar tickets, cronograma e requisitos”
      Claro que é uma preocupação válida ter de dar suporte a algo em que qualquer pessoa precisa entrar e aprender. Mas, enquanto o negócio tiver acesso a ferramentas para resolver problemas, as pessoas “entediadas” encontrarão um jeito. O atrito é grande demais
    • O botão “Gravar macro” é o ponto central. Mesmo que a Microsoft troque para C#, JavaScript, Python etc., basta manter esse botão para funcionar
    • É a mesma experiência de muita gente que começa em finanças e migra para engenharia de dados ou implementação de sistemas
      Como é mais fácil criar algo relativamente complexo dentro do Excel e colocar em um compartilhamento de rede do que passar pela TI para instalar uma IDE, construir alguma coisa, passar por procedimentos de segurança e fazer o deploy, isso não deve acabar tão cedo. Nem todo problema exige um projeto no Jira e uma solução excessivamente complicada
      Dito isso, sou totalmente contra construir coisas grandes em VBA. Um script pequeno que, a partir da mudança de alguns valores de células, consulta um cubo em um sistema e combina com dados de tabela de outro sistema pode até ser aceitável, mas a partir de certo ponto é preciso ir para outro lugar
      Para a maioria dos projetos, partindo do pressuposto de que há licenças de servidor para permitir automação, prefiro muito a stack Alteryx+Tableau/PowerBI
    • Para ser sincero, fiz algo parecido, depois migrei para C# e hoje sou simplesmente desenvolvedor de software
  • Eu precisava criar uma interface CRUD simples para analistas
    O primeiro problema era que os analistas queriam realizar todas as etapas de CRUD dentro do Excel. Como o Excel era a interface real, eu precisava de algo que pudesse rodar dentro dele
    O departamento de TI não permitia acesso à linha de comando e também recusava a instalação de ferramentas de desenvolvimento não aprovadas. Conseguir aprovação podia levar meses. Os administradores de banco de dados não gostavam da ideia de adicionar um novo banco ao Oracle DB existente, e o departamento de TI também não queria operar um banco de dados diretamente
    Até para colocar um novo suplemento no Excel era preciso implorar a alguém da TI. Com sorte, o suplemento aparecia de repente um dia, mas não dava para saber se levaria um dia, uma semana ou um mês
    Então a única alternativa realista era VBA, e no fim consegui colocar de pé uma solução provisória fixa que os analistas usavam uma vez a cada duas semanas

  • Quando trabalhei em uma agência de inteligência, precisei criar um app para pessoas destacadas no Afeganistão. Os únicos computadores que elas podiam usar eram Windows XP bloqueados, sem possibilidade de instalar nada novo
    Como estavam presos ao Office já validado e instalado, eu, que era usuário de Linux, também fiquei preso ao Office. Só com VBA puro, criei bastante Frankenstein e recebi boas avaliações

    • Tive a mesma experiência estando destacado no Oriente Médio. Automatizei o máximo possível com VBA em computadores XP totalmente isolados da rede
    • Em uma situação parecida, mas não igual, sobrevivi com arquivos HTML contendo código JavaScript em tags script. Fico curioso se, apesar de a máquina ser isolada da rede, a execução do IE estava bloqueada, ou se VBA era simplesmente mais conveniente do que JavaScript
  • Admitindo, TI é o departamento burocrático moderno, fica 95% ocupada com problemas que ela mesma criou e tem uns 5% de orientação a serviço. Para quem está de fora, os processos são opacos e geralmente não ajudam
    Ri muito quando li este trecho na descrição do IBM BPM, porque ele resume bem uma boa parte do problema
    “O IBM BPM até tem uma API REST, mas essa API REST é quase inútil para equipes técnicas e PMEs. Algumas chamadas REST usam JavaScript codificado como string, e outras exigem HTML dentro de JSON dentro de XML. As tabelas do banco de dados são consultadas por GUID, não por nome. Não há documentação dizendo qual GUID está associado a qual tabela/processo”
    Muita coisa ficou absurdamente complexa a ponto de ninguém fora da TI querer lidar com ela e, às vezes, nem mesmo dentro da TI. A partir do AJAX, metade do esforço de desenvolvimento começou a ir para projetar código de front-end e serviços de back-end, o que na verdade tem muito pouco a ver com o problema de automação do usuário final. Depois disso só piorou, e as UIs de hoje parecem modernas, mas são tão hostis ao usuário quanto a stack tecnológica usada para criá-las
    No Excel, a UI simplesmente “está lá”, também existe um gerador de código chamado gravador de macros, e o departamento de TI não fica questionando minhas permissões nem dizendo que não tem tempo e orçamento para ajudar no meu problema de negócio. Por isso, o VBA é uma rota de contorno para o usuário passar por fora do departamento de TI. Não é perfeito, mas é melhor que as outras alternativas

    • VBA é a linguagem de programação ágil definitiva. A TI corporativa, ou seja, o departamento burocrático, está presa a coisas como Scrum e Squad, mas as pessoas de outros departamentos concluem o trabalho com Excel/VBA
      Nada mudou. Isso já acontecia no século passado e era chamado de ilhas de automação. Na época, ao meu redor, isso era visto como uma boa estratégia: deixar os departamentos brincarem primeiro e, se aparecesse potencial, integrar depois
    • Se você procurar por tempo suficiente, dá para encontrar exemplos ruins em qualquer departamento. Entre as coisas administradas pela TI, há coisas que chegam perto do insano? Claro que há. Mas isso não é uma boa desculpa para criar shadow IT
      Alguns analistas se juntarem para hackear suas próprias ferramentinhas em VBA não me incomoda nem um pouco. Esse espírito é louvável e, como resultado, talvez eu até passe a entender melhor o meu dia a dia
      O que incomoda é quando esses analistas, em algum momento, esperam que a arquitetura do meu sistema de alguma forma se acomode ao projetinho pessoal deles. Quando peço documentação, não existe; não há visão geral de arquitetura; quando peço acesso ao repositório daquele monstro, a resposta é “o que é um repositório?”
      Eles perguntam por que a planilha deles não pode injetar dados no meu pipeline de processamento e acham que eu deveria escrever um controller para encaixar em algum pedaço de REST que aprenderam vendo metade de um vídeo no YouTube. Em reuniões, surge a pergunta: “O que você quer dizer com precisar de autenticação? Por que a TI sempre complica as coisas?”
      Seja VBA, low-code ou qualquer outra coisa, é bom que as pessoas criem ferramentas. Eu faço a mesma coisa, só que chamo isso de script de shell e deixo em um repositório Git. Mas, assim como eu não soltaria minha ferramenta CLI em um servidor de produção, também não deixaria algo que nunca passou por uma única revisão de código
    • Um dos meus primeiros empregos formais em engenharia de software foi trabalhar sentado ao lado de traders de câmbio no pregão de um banco
      Quem me contratou foi o diretor de gestão de risco de mercado, cuja função era garantir que o banco não perdesse dinheiro demais em um único dia. Ele me contratou porque não confiava que o departamento de TI oficialmente aprovado escreveria corretamente o código de implementação dos algoritmos dele. Por exemplo, eles já tinham errado por não entender a precedência de operadores, isto é, que multiplicação tem prioridade sobre adição
      Todos os trades precisavam entrar como insumo no cálculo de risco de mercado e, como era o início dos anos 2000, instalei Apache e Perl CGI em um PC embaixo da mesa e fiz um pequeno app para os traders lançarem operações e acompanharem posições. Os traders começaram a preferir isso à solução oficial de TI, porque era mais fácil de usar e mais conveniente para visualizar posições
      Em muitos ambientes corporativos, encontrar um jeito de contornar a TI é uma função importante. Voltando ao Excel, os traders usavam Excel para cálculos e simulações, e nós tentávamos aproveitar o que eles já faziam fornecendo ferramentas que se conectavam ao Excel
    • Há uma frase no artigo dizendo que isso é uma decisão explícita de política da empresa
      “Permitir que usuários finais tenham acesso a uma linguagem de programação de alto nível contraria a visão de estratégia tecnológica da empresa”
    • A resposta é esta: porque a única linguagem de programação que uma empresa não pode escolher não instalar é VBA
      As maravilhas do “enterprise”. Fico impressionado toda vez que alguém usa isso como se fosse uma vantagem ou uma desculpa
  • Porque até recentemente não havia uma boa alternativa. O futuro está no novo modelo de suplementos do Office: https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...
    Digam o que quiserem sobre TypeScript, mas pelo menos é melhor que VBA. O grande problema, porém, é que, ao contrário do VBA, não dá para programar diretamente dentro do Excel. Às vezes você não quer iniciar um projeto completo de suplemento pensando em reutilização; quer apenas um script descartável para rodar uma vez e consertar algo agora. Enquanto usava isso, descobri o Script Lab (https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...), que talvez ajude.

    • “Ao contrário do VBA, não dá para programar diretamente dentro do Excel” é quase um motivo para desistir do negócio
      Além disso, há uma pergunta óbvia. Um usuário sem privilégios consegue instalar suplementos sem intervenção do departamento de TI? Eles podem ser incorporados a uma planilha? Se a resposta para a primeira for “não”, isso é realmente fatal; e, mesmo que a resposta para a segunda seja “não”, isso também prejudica a adoção. A vantagem de macros e VBA é que, exceto pelas configurações de segurança, qualquer instância do Excel consegue executá-los imediatamente, sem instalação adicional.
    • Não vi a menção ao Script Lab no fim do comentário. Se for o Microsoft Script Lab, ele permite fazer exatamente isso: https://www.microsoft.com/en-us/garage/profiles/script-lab/
      Outro problema é que compartilhar suplementos com usuários finais não é trivial. É preciso publicar no marketplace ou no SharePoint, e o sideload exige um servidor SMB e GPO. Há, porém, uma opção pouco mencionada: você pode incluí-lo no documento para que, ao abrir pela primeira vez, ele seja instalado após a confirmação do usuário.
    • Para apenas exibir uma UI bonita para entrada de dados ou visualização, é bom, mas infelizmente o OfficeJS não faz nem metade do que o VBA consegue fazer. Se o sistema de suplementos tivesse FFI, eu teria migrado de vez
      Outro grande problema é que, para usar OfficeJS, é preciso conseguir hospedar um servidor web. Em geral, a maioria dos usuários finais não tem esse tipo de acesso.
  • VB(A) é parecido com Python. Não é bonito, mas resolve. Se você acha bonito, é porque tem pouca experiência e não conhece muitas alternativas melhores
    Uma ferramenta com um bom ecossistema que permita concluir trabalho de verdade — ferramentas, bibliotecas e integrações — é útil. Como sistema de desenvolvimento de apps desktop, o Visual Basic, junto com o MS Access e suas vantagens de banco de dados, foi muito útil em muitas situações. Quando você chegava ao ponto de superar isso, provavelmente também tinha dinheiro para escalar para uma solução “de verdade”.
    Não há dúvida de que sistemas baseados em VBA geraram quantias enormes de dinheiro. Pela minha experiência fazendo desenvolvimento financeiro principalmente como alguém de fora, a maior reescrita de Excel/VBA que vi foi a de uma empresa que ganhou muito dinheiro com swaps de inadimplência de crédito por volta de 2008. Antes da reescrita, a pasta de trabalho levava 5 minutos para abrir, mas o VBA fazia grande parte do trabalho pesado. As pessoas que tinham o conhecimento estavam ganhando muito dinheiro em bônus para a empresa e para si mesmas.
    A lição aqui é que importa mais a ferramenta ser acessível a pessoas que não foram treinadas especificamente para usá-la do que ela ser ideal. É pelo mesmo motivo que Python se tornou número 1 fora do navegador web do cliente. Isso não quer dizer que seja a melhor, mas que resolve o trabalho e é acessível.

    • Dá para argumentar que Python é uma linguagem bonita, uma linguagem completa com suporte a classes e funções de primeira classe, mas ainda relativamente simples e acessível
      Mas esse não é o único motivo de sua popularidade. Ela tem as ferramentas de ciência de dados mais sólidas, o que criou um efeito avassalador, e também conta com frameworks web decentes como Django e Flask. O fato de muitas universidades terem adotado Python como “primeira linguagem” no lugar de Java também impulsionou sua popularidade. VBA não tem isso.
    • Python é bonita, e acho que sua forma de usar espaços em branco é melhor do que estratégias de marcação de blocos como chaves, begin/end ou if/else
      Experiência também significa saber que há um elemento subjetivo no que é bonito ou não. O VBA evoluiu em condições “duras”, o que explica em parte suas esquisitices.
    • Python não é Scheme, mas, entre linguagens de programação, é sem dúvida uma das bonitas e, em muitos casos, não há alternativa melhor. Digo isso com base em cerca de 25 anos programando em dezenas de linguagens.
  • VBA é uma linguagem decente, com suporte a programação orientada a objetos. Não tem herança, mas permite composição. Dá acesso e controle profundos sobre o Excel, e é madura e estável. Isso porque a Microsoft não a modifica muito mais
    O motivo pelo qual os “programadores de verdade” detestam VBA geralmente é que existe muito código VBA espaguete amador escrito por pessoas da área de negócios, e às vezes pedem aos programadores que depurem isso

    • Em contraponto, VBA é uma linguagem horrível, exceto pelo fato de permitir acessar e controlar Excel, Word etc.
      Ela é cheia de características estranhas, como caracteres de controle dentro do código que são localizados.[1][2] Se você quiser que o código rode também em instalações que não estejam em inglês, precisa usar placeholders como Application.International(xlDecimalSeparator) para montar dinamicamente as strings passadas a essas funções, e a legibilidade do código cai muito. Quando o código quebra por esse motivo, as mensagens de erro são inacreditavelmente inúteis; se o desenvolvedor não souber que isso é um problema potencial do VBA, reproduzir o erro é praticamente impossível. Para reproduzir, é preciso mudar o idioma da interface para uma língua que talvez você nem conheça
      Pelo menos no Word, cerca de metade das funções mais úteis, como inserir um parágrafo depois do parágrafo atual, quebram quando usadas no último parágrafo de uma célula de tabela, exigindo um monte de contornos espaguete
      Se você quiser passar de um lado para outro uma string de texto com várias formatações, como ao referenciar a propriedade innerHtml de um elemento DOM, isso não é fácil, a menos que use seleção e copiar/colar baseados em scripts meio hacky
      Em outra thread, alguém comparou com Bash, e na verdade eu concordo. Você não deveria escrever nada complexo em nenhuma das duas linguagens
      [1] https://stackoverflow.com/questions/20652409/using-vba-to-de...
      [2] https://stackoverflow.com/questions/29832281/vba-range-funct...
    • Investi uma quantidade enorme de tempo criando uma biblioteca VBA (https://github.com/sancarn/stdVBA) e gosto de VBA, mas há problemas reais que impõem grandes limitações à linguagem (https://sancarn.github.io/vba-articles/issues-with-vba.html)
      Dito isso, também é verdade que boa parte do ódio que VBA recebe vem do estado dos projetos em VBA (https://sancarn.github.io/vba-articles/why-is-vba-most-dread...)
    • Acho justo olhar com maus olhos para um ambiente que inclui recursos ruins como On Error Resume Next
  • Pensando no Excel e nas planilhas como um todo, muita gente de fora não entende o quanto a linguagem das planilhas implementou bem a programação funcional reativa. É exatamente isso que React/Angular vêm tentando acertar há mais de 10 releases
    Além disso, muita gente não entende por que as planilhas são tão convenientes para usuários finais e, como resultado, oferece UIs inferiores que na prática tornam tudo mais difícil
    Às vezes é preciso dar um passo atrás e entender que, mesmo na época em que não havia interfaces gráficas, o pessoal antigo fazia as coisas direito. Os negócios já funcionavam nos primórdios, e, na maior parte do tempo, o que uma empresa precisa é de uma visualização em formato de tabela e da opção de fazer cálculos de funções reativas sobre ela. Pergunte a um amigo que trabalhe em uma pequena ou média empresa e ele confirmará isso

    • Grande parte do esforço em desenvolvimento web é gasta em apresentação. Concordo que, se você só precisa dos dados, é difícil superar uma planilha
    • O Excel pode ser visto como o melhor IDE para usuários finais já inventado