Por qué la gente sigue usando VBA

• En muchas organizaciones, Excel se ha convertido en la base de los procesos de trabajo, por lo que cuando se necesita una pequeña automatización, VBA termina siendo la opción predeterminada de facto
• La organización del caso tiene 13 plataformas de datos y varias herramientas de automatización, pero las herramientas con acceso amplio a las fuentes de datos necesarias se reducen básicamente a VBA y PowerShell
• CyberSecurity rechazó la instalación de lenguajes de alto nivel como Python, Ruby, Node y Rust, y la alternativa, Power Platform, muestra limitaciones en el acceso a datos y en el mantenimiento de algoritmos complejos
• Los casos anteriores de Lotus Notes e IBM BPM muestran que los sistemas impulsados por TI pueden ser vulnerables al fin de soporte, migraciones incompletas y vacíos de mantenimiento
• VBA es antiguo y también tiene debilidades, pero viene incluido en Office, está al alcance de cualquiera y ofrece control para que los SME puedan validar directamente la lógica de negocio y la migración de datos

---

Razones directas por las que VBA se sigue eligiendo

• En una encuesta de 2021 en /r/vba, la mayoría de los usuarios de VBA respondió que usa VBA porque no tiene otra opción
• Muchas organizaciones operan procesos de negocio completos en Excel y, cuando se necesita algo de automatización, VBA suele ser la primera opción
• Detrás de la crítica de “controlar parte de la infraestructura con hojas de cálculo” están las limitaciones de las herramientas que ofrece la organización, el acceso a los datos y la estructura de mantenimiento

Limitaciones del acceso a datos y de las herramientas de automatización

• El área de ingeniería de la organización del caso puede usar varias plataformas de automatización
  • OnPrem: PowerShell, VBA de Excel / OfficeJS limitado / OfficeScripts / PowerQuery, PowerBI Desktop, SAP Analysis for Office
  • OnCloud: PowerApps, Power BI, PowerAutomate no premium
  • Entornos sandbox: ArcPy de ArcGIS, MapBasic de MapInfo, Ruby de InfoWorks ICM, ArcGIS Online
• Las plataformas de datos administradas por TI van de D1 a D13 e incluyen bases de datos geoespaciales, bases de datos SAP, plataformas de telemetría, SharePoint, Lotus Notes, IBM BPM, sistemas de archivos e información de modelos hidráulicos
• Las plataformas de automatización que pueden conectarse a las fuentes de datos necesarias se reducen básicamente a VBA y PowerShell
  • Power BI Desktop se introdujo en la organización, pero no cubre todas las plataformas a las que accede VBA
  • Incluso con el mismo alcance de acceso, Power BI es difícil de usar para automatización de procesos, y para trabajar con otros datasets se usa un método que crea CSV y los guarda en SharePoint
  • A veces, esa generación de CSV también queda a cargo de VBA
• Algunas conexiones de VBA a servicios OnCloud se basan en intentos directos, y se considera que SAP BW4HANA y otros servicios en la nube también podrían conectarse mediante VBA, pero los requisitos de autenticación y los protocolos aún no están resueltos

Límites de los lenguajes de alto nivel y Power Platform

• La organización quería usar lenguajes de alto nivel como Python, Ruby, Node y Rust para automatización de negocio, pero todas las solicitudes para instalarlos en equipos o en toda la empresa fueron rechazadas por CyberSecurity
• El motivo del rechazo fue que permitir a los usuarios finales acceder a lenguajes de programación de alto nivel iba en contra de la visión de estrategia tecnológica de la compañía
• Las alternativas mencionadas, PowerAutomate y PowerApps, casi no tienen acceso a los datos necesarios
• Incluso cuando hay acceso a los datos, Power Platform no alcanza para ejecutar la mayoría de los procesos
  • Los algoritmos necesarios son complejos, por lo que una solución en PowerAutomate puede ser difícil de mantener y difícil de entender incluso para el personal de TI
  • Como ejemplo se mencionan projection algorithms
• Al final, las herramientas que quedan como opciones prácticas son PowerShell v3 y VBA
  • PowerShell v3 no admite sintaxis de clases y tampoco permite instalar módulos
  • VBA es el objetivo para el cual se dedicaron cientos de horas a crear open source VBA libraries, con el fin de reforzarlo como un lenguaje razonable según estándares modernos

VBA como garantía de mantenimiento

• En los años 2000, muchos sistemas se construyeron sobre bases de datos de IBM Lotus Notes
• Tras la adquisición de Lotus Notes por HCL en 2019, la continuidad del soporte quedó en duda, y el fin del soporte oficial estaba previsto para junio de 2024
• Desde 2019, el equipo técnico intentó migrar varios sistemas a nuevas tecnologías, y la organización invirtió mucho dinero en desarrollar un sistema basado en IBM Business Process Manager para reemplazar una base de datos de Lotus Notes
• El plan era cargar todos los datos de D10 en D11 y luego archivar D10, pero la situación en 2023 era distinta
  • Faltaban 8 meses para el fin del soporte oficial
  • El equipo técnico eliminó el contrato de soporte de IBM BPM
  • No se veía ningún sistema de reemplazo ni para IBM BPM ni para la base de datos de Lotus Notes
  • La solución de IBM BPM tenía poco mantenimiento y no funcionaba como se necesitaba
  • Se había forzado dentro de IBM BPM una solución que no era adecuada para el propósito
  • Existe una API REST, pero casi no sirve para el equipo técnico ni para los SME
    • Algunas llamadas REST usan JavaScript codificado como string
    • Otras llamadas requieren poner HTML dentro de JSON dentro de XML
    • Las tablas de la base de datos se consultan por GUID, no por nombre
    • No hay documentación sobre qué GUID corresponde a qué tabla o proceso
  • Los datos de D10 en realidad no se migraron a D11, por lo que el negocio usa dos sistemas, no uno
  • El modelo de datos de D11 tampoco soporta correctamente los datos de D10
• Los SME son quienes usan las herramientas todos los días y deciden qué cambios necesita el sistema
• Si los SME usan VBA, pueden controlar y mantener el sistema directamente en la medida necesaria, y eso funciona como una garantía de mantenimiento que los sistemas de TI no aseguran

Control y problemas de colaboración con los SME

• Un proyecto reciente consistía en crear un nuevo sistema integrado de TI para reemplazar hojas de cálculo centrales para el negocio, y si tenía éxito, la importancia de D6 bajaría a nivel C
• La especificación inicial era simple
  • Servidor NodeJS y base de datos MySQL
  • UI en React
  • Dar a administradores y SME acceso al código base y a git
  • TI y SME colaborarían para construir el sistema
• El equipo técnico planteó otros requisitos
  • Administradores y SME no tendrían acceso al código
  • El frontend se construiría con Microsoft PowerApps para alinearse con la “Strategic Vision”
  • El backend se construiría con Microsoft Azure Pipelines para alinearse con la “Strategic Vision”
• Desde el punto de vista de los SME, estos requisitos crean varios problemas
  • El equipo técnico no entiende el trabajo operativo, por lo que le resulta difícil comprender la lógica de negocio y los cálculos
  • Si los desarrolladores escriben la lógica de negocio, es fácil que aparezcan errores
  • El equipo técnico suele abandonar proyectos tecnológicos a medida, con lo que desaparecen los recursos de mantenimiento y mejora
  • Si se colabora con los SME, al menos un equipo puede conservar recursos para mantener el sistema
  • Los SME deben poder confiar en los resultados, pero si no pueden ver el código, es difícil confirmar que funcione en todos los casos límite
  • Aunque existan pruebas unitarias, si el código no es visible es difícil verificar que las pruebas existan y se ejecuten con frecuencia
  • Los SME mejoran y mantienen sistemas legacy existentes y tienen mucho conocimiento sobre las interacciones entre sistemas
  • Para confirmar que todos los datos se migren y representen correctamente en el nuevo sistema, necesitan acceso al backend
• Si el código permanece en VBA, los SME y el negocio conservan el control
• El equipo técnico rara vez entrega control al equipo de negocio, y los SME pueden verificar que el software se desarrolle correctamente de forma modular y no se convierta en un conjunto de piezas tecnológicas débilmente conectadas

Experiencia de usuario dentro de un entorno familiar

• La mayoría de los ingenieros usa hojas de cálculo en su trabajo diario
• VBA está integrado dentro de las hojas de cálculo, por lo que puede ofrecer herramientas desconocidas en un entorno familiar
• Puede ser más potente para los usuarios incorporar nuevas funciones dentro de un entorno familiar que ofrecer herramientas desconocidas en un entorno desconocido

Conclusión: las debilidades de VBA y la elección práctica

• Las organizaciones eligen hojas de cálculo y VBA por varias razones
  • Por preocupaciones de seguridad, las alternativas que ofrece TI son pobres
  • Las herramientas alternativas no se conectan correctamente con los sistemas fuente y, por lo general, siguen en desarrollo
  • Hay problemas de estrategia de TI que no contemplan algunos casos de uso
  • Por preocupaciones de seguridad y mantenimiento, no quieren colaborar con los SME
  • Usuarios, administradores y SME no reciben suficiente capacitación sobre los sistemas de reemplazo
  • Usuarios y SME quieren cierto nivel de control sobre la lógica de negocio del sistema
  • Es la única tecnología viable incluida en Office y disponible para todos
• VBA no está libre de debilidades
• El artículo de mataroa tiene algunos puntos válidos
• A veces la gestión es pésima, pero muchas personas dentro de la organización intentan hacer lo correcto con las herramientas que tienen

[GN⁺]

Opiniones de Hacker News

• En las empresas, ya existe dentro de Excel un entorno de desarrollo que no requiere pasar por gerencia, alta gerencia, registro de proyecto, presupuesto, asignación de project manager, etc., para obtener la aprobación de software que no está en inventario.
  Si además se quiere almacenamiento de datos en red y una interfaz web, basta con sumarle SharePoint. Las soluciones salen desde esta orientación al usuario final, y esas soluciones se construyen con VBA.

  • En el entorno distópico que es una empresa, no deberías esperar poder pedir o instalar software en tu equipo. Solo puedes usar lo que ya existe, y cambiarlo implica pelear contra la burocracia, así que no vale la pena.
    Antes había un motor de reportes horrible hecho en Word VBA que leía definiciones de reportes desde un recurso compartido de archivos, recortaba y pegaba fragmentos de plantillas y luego los imprimía. Como TI no recuperó la PC de alguien que se había ido de la empresa, la usábamos todo el día para generar reportes de ingeniería procesando .doc, y era mucho más rápido y barato que comprar la opción de reportes del software CAD/CAM. Esa opción habría requerido al menos 18 meses, consultores y consumir presupuesto de proyecto.
    Cuando la gente critica que se hagan cosas horribles con Excel VBA, es muy probable que la causa esté más arriba en el stack. Otra causa es el “martillo del mono”: si le das un martillo a un mono, golpea todo; si la única herramienta que tienes es VBA, todo parece una solución en VBA. Ahora nos hemos convertido en primates un poco más evolucionados.
  • Al menos dos veces vi la escena en la que un gerente de área necesitaba algo, pero no podía o no quería molestar al equipo de desarrollo, y empezaba con “¿qué tan difícil puede ser?”. Y entonces, antes de darte cuenta, aparecían unos cientos de líneas de VBA que resolvían su necesidad.
    En la siguiente etapa, Jim también quiere correrlo, así que se copia el script; Jane usa otra versión de VBA y lo modifica; y ahora viene el “¡esto también!”, y se expande. Al final se convierte en un remiendo de 1500 líneas, y quieren pasarle el mantenimiento al equipo de desarrollo.
  • Un amigo automatizó todo su trabajo con Excel. Dice que termina un día de trabajo en 15 minutos y descansa el resto.
    La computadora de la empresa está muy bloqueada, así que no puede instalar nada ni entrar a sitios que no estén en la lista blanca, pero tiene Excel.
  • Visual Basic en sí también es un lenguaje muy potente. En entornos como las macros de Excel, se puede aprovechar bastante esa potencia, y muchos power users de empresas realmente lo usan así.
    Se parece bastante a aplicar el viejo paradigma del “sistema operativo Emacs” en otro contexto.
  • VBA está ahí, y funciona. Es un lenguaje muy accesible e intuitivo para programar e iterar, y no hace falta perder tiempo instalando dependencias externas, cayendo en el infierno de librerías o pasando por una etapa de compilación.
    Por eso no sorprende que VBA siga siendo muy valioso en las empresas. Incluso en entornos con otras herramientas y lenguajes, y procesos de build maduros, he visto a product managers hacer análisis de negocio increíblemente complejos en VBA, y para el problema que tenían entre manos era la herramienta adecuada.

• Me sorprendió ver que incluso desarrolladores profesionales usan mucho Excel/VBA como herramienta auxiliar.
  Hace unos años, cuando trabajaba con un gran hedge fund, un analista de datos me envió un modelo de Excel hecho por él mismo y, al ver la extensión .xlsm, pensé que tendría código VBA. Me dije: “a ver qué hicieron estos cowboys de grabar macros”, pero adentro había mucho VBA, y el autor era un analista de datos graduado en Ciencias de la Computación de Caltech que manejaba Python muy bien.
  El VBA se usaba para traer datos desde una base de datos, ponerlos en hojas, crear fórmulas y darles formato para que se vieran bien, y también había algunos UserForm. Le tomé el pelo diciendo: “¿VBA? ¿Qué más usan ahí? ¿desmotadoras de algodón y palas de vapor?”, pero, contra lo que esperaba, elogió mucho Excel y VBA, y eso me sorprendió.
  Me quedó grabado lo que dijo: “Excel hace que sea fácil entender la estructura de dependencias implícita en los cálculos. Si hubiera hecho esto en Python, habría pasado todo el día respondiendo preguntas”.

  • Mientras más experiencia acumulas como desarrollador, más importante se vuelve usar la herramienta adecuada para el trabajo. A veces una solución perezosa es mucho mejor que una masa de ideas imposible de entender.
  • VBA tiene problemas (https://sancarn.github.io/vba-articles/issues-with-vba.html), pero está lejos de ser la peor herramienta. Por ejemplo, es mejor que cosas como PowerAutomate.
    VB6 tiene una comunidad bastante grande, y https://twinbasic.com/ ha ayudado bastante últimamente a unificar las comunidades de VBA y VB6. Así que podría haber una pequeña resurrección en la comunidad de desarrolladores.
  • El negocio que opero depende mucho de Google Sheets. Inyectando valores y leyendo los valores calculados, podemos definir una lógica de negocio bastante compleja en forma de hoja de cálculo, y la gente de negocio y finanzas puede ajustarla fácilmente. Todos están muy satisfechos con esta solución.
  • Excel es una interfaz excelente para muchas cosas y, hasta cierto punto, ayuda a la gente a entender los datos. Por otro lado, la gente está tan acostumbrada a ese modelo de datos que, cuando algo se vuelve un poco complejo, tiende a culparse a sí misma en lugar de hacer preguntas.
    En Suecia incluso hay un modelo de predicción de pensiones en Excel/VBA de 3 GB con un manual de usuario de 38 páginas. Pero es difícil decir que sea un caso de muy buen uso de Excel: https://www.pensionsmyndigheten.se/statistik-och-rapporter/p...
  • Una clínica de internación preoperatoria de un gran hospital universitario se gestionaba con Excel.
    VBA es potente y permite prototipar e iterar rápido. Incluso se podría decir que VB6 fue la cumbre de las apps CRUD.

• “Porque es sorprendente”
  Escuché que antes había más de 20.000 bases de datos de Access en la red de JP Morgan. Analistas de datos de varias empresas un día se hartaron de lo que hacían todos los días y se pusieron a mirar el botón “Grabar macro”. A algunos les pareció bastante cómodo y siguieron usándolo. Otros se hicieron los listos, miraron el código que escupía la macro, aprendieron un poco e intentaron modificarlo
  Unos pocos llegaron a aprender estructuras de datos y algoritmos, crearon sistemas de autenticación y permisos que imitaban a Django, rehicieron desde cero interfaces con UserForm e implementaron Markdown, parsing SAX, barras de desplazamiento personalizadas, logging e incluso juegos
  La respuesta probablemente sea que los analistas de datos se aburrieron de su trabajo diario

  • También puede ser que el departamento de IT bajara demasiados procedimientos desde su torre de marfil y empujara a la gente hacia el shadow IT. En grandes empresas vi casos en que los analistas tenían la capacidad de llevar sus Frankensteins a un nivel adecuado, pero quedaban bloqueados con cosas como “hay que iniciar un proyecto y crear tickets, cronogramas y requisitos”
    Claro que es una preocupación válida tener que dar soporte a algo que cualquiera que entre deba aprender. Pero mientras el negocio tenga acceso a herramientas para resolver problemas, la gente “aburrida” encontrará la manera. Hay demasiada fricción
  • “Grabar macro” es la clave. Aunque Microsoft lo cambiara a C#, JavaScript, Python, etc., bastaría con poner ese botón
  • Es la misma experiencia que tienen muchas personas que empiezan en finanzas y luego se pasan a ingeniería de datos o implementación de sistemas
    Como es más fácil crear algo relativamente complejo dentro de Excel y subirlo a un recurso compartido de red que pasar por IT, instalar un IDE, construir algo, atravesar procedimientos de seguridad y desplegarlo, no creo que esto vaya a terminar pronto. No todos los problemas necesitan un proyecto en Jira y una solución excesivamente compleja
    Dicho eso, estoy totalmente en contra de construir cosas grandes en VBA. Un script pequeño que, según los cambios en algunos valores de celdas, consulta un cubo de un sistema y lo combina con datos tabulares de otro sistema está bien, pero a partir de cierto punto hay que llevarlo a otro lado
    Para la mayoría de los proyectos, suponiendo que haya licencias de servidor y que se pueda automatizar, prefiero mucho el stack Alteryx+Tableau/PowerBI
  • Sinceramente, hice algo parecido, luego me pasé a C# y ahora simplemente soy desarrollador de software

• Tenía que crear una interfaz CRUD simple para analistas
  El primer problema era que los analistas querían manejar todos los pasos del CRUD dentro de Excel. Como Excel era la interfaz real, necesitábamos algo que pudiera ejecutarse dentro de Excel
  El departamento de IT no permitía acceso a la línea de comandos y también rechazaba instalar herramientas de desarrollo no aprobadas. Conseguir la aprobación podía llevar meses. A los administradores de bases de datos no les gustaba agregar una DB nueva al Oracle DB existente, y al departamento de IT tampoco le gustaba que uno operara una DB por su cuenta
  Incluso para poner un complemento nuevo en Excel había que rogarle a alguien de IT. Con suerte, un día el complemento aparecía de repente, pero no se sabía si tardaría un día, una semana o un mes
  Así que la única alternativa realista era VBA, y al final logramos levantar una solución fija temporal que los analistas usaban una vez cada dos semanas

• Cuando trabajaba en una agencia de inteligencia, tuve que crear una app para personas desplegadas en Afganistán. Las únicas computadoras que podían usar eran Windows XP bloqueadas y no había forma de instalar nada nuevo
  Como estábamos atados a Office, que ya estaba validado e instalado, incluso yo, que usaba Linux, quedé atado a Office. Con VBA puro construí bastantes Frankensteins y recibieron buenas evaluaciones

  • Desde la perspectiva de alguien desplegado en Medio Oriente, tuve la misma experiencia. Automatizé todo lo posible con VBA en computadoras XP totalmente aisladas de la red
  • En una situación parecida, aunque no igual, me las arreglé con archivos HTML que tenían código JavaScript dentro de etiquetas script. Me pregunto si, pese a que la máquina estaba aislada de la red, IE estaba bloqueado, o si simplemente VBA era más cómodo que JavaScript

• Admitámoslo: IT es el departamento burocrático moderno, está ocupado en un 95% con problemas que él mismo creó y su orientación al servicio es de alrededor del 5%. Para alguien de afuera, los procesos son opacos y por lo general no ayudan.
  Me reí mucho al leer esta parte en una descripción de IBM BPM, porque resume bastante bien buena parte del problema:
  “IBM BPM sí tiene una API REST, pero esta API REST es casi inútil para los equipos técnicos y las pymes. Algunas llamadas REST usan JavaScript codificado como cadenas, y otras exigen HTML dentro de JSON dentro de XML. Las tablas de la base de datos se consultan por GUID, no por nombre. No hay documentación sobre qué GUID está asociado con qué tabla/proceso”.
  Muchas cosas se han vuelto absurdamente complejas, al punto de que nadie fuera de IT quiere lidiar con ellas, y a veces ni siquiera dentro de IT. Desde AJAX, la mitad del esfuerzo de desarrollo empezó a irse en diseñar código de frontend y servicios de backend, algo que en realidad tiene muy poco que ver con el problema de la automatización para usuarios finales. Desde entonces empeoró, y las UI de hoy se ven modernas, pero son tan hostiles para el usuario como el stack tecnológico con el que se hicieron.
  En Excel, la UI simplemente “está ahí”, también hay un generador de código llamado grabador de macros, y el departamento de IT no me cuestiona mis permisos ni me dice que no tiene tiempo ni presupuesto para ayudarme con mi problema de negocio. Por eso VBA es una ruta alternativa para que los usuarios esquiven al departamento de IT. No es perfecto, pero es mejor que las otras alternativas.

  • VBA es el lenguaje de programación ágil definitivo. El IT corporativo, es decir, el departamento burocrático, está atado a cosas como Scrum y Squad, pero la gente de otros departamentos termina el trabajo con Excel/VBA.
    Nada cambió. Esto ya pasaba en el siglo pasado y se lo llamaba islas de automatización. En mi entorno de entonces se consideraba una buena estrategia: dejar que los departamentos jugaran primero con eso y, si se veía potencial, integrarlo.
  • Si buscas el tiempo suficiente, puedes encontrar malos ejemplos en cualquier departamento. ¿Hay cosas gestionadas por IT que se acercan a niveles de locura? Por supuesto que sí. Pero eso no es una buena excusa para crear shadow IT.
    No me molesta en absoluto que unos cuantos analistas se junten a hackear su propia pequeña herramienta en VBA. Ese espíritu es digno de elogio, y el resultado incluso podría ayudarme a entender mejor su trabajo diario.
    Lo que molesta es cuando esos analistas, en algún momento, esperan que la arquitectura de mis sistemas se adapte como sea a su proyecto personal. Les pides documentación y no hay; no hay resumen de arquitectura; les pides acceso al repositorio de ese monstruo y responden: “¿qué es un repositorio?”.
    Preguntan por qué su hoja de cálculo no debería inyectar datos en mi pipeline de procesamiento, y asumen que yo debería escribir un controlador que encaje con los pedazos de REST que aprendieron viendo medio video de YouTube. En las reuniones aparece la pregunta: “¿Qué significa que hace falta autenticación? ¿Por qué IT siempre complica las cosas?”.
    Está bien que la gente cree herramientas, sea con VBA, low-code o lo que sea. Yo hago lo mismo, solo que lo llamo script de shell y lo guardo en un repositorio Git. Pero así como no suelto mi herramienta CLI en servidores de producción, tampoco voy a dejar ahí algo que no pasó ni por una sola revisión de código.
  • Uno de mis primeros trabajos formales de ingeniería de software fue sentarme junto a traders de divisas en el piso de trading de un banco.
    Quien me contrató fue el responsable de gestión de riesgo de mercado, cuyo rol era asegurarse de que el banco no perdiera demasiado dinero en un solo día. Me contrató porque no confiaba en que el departamento de IT aprobado oficialmente escribiera bien el código para implementar su algoritmo. Por ejemplo, una vez se equivocaron porque no entendían la precedencia de operadores, es decir, que la multiplicación tiene prioridad sobre la suma.
    El cálculo de riesgo de mercado tenía que tomar todas las operaciones como entrada y, como era a principios de los 2000, instalé Apache y Perl CGI en una PC debajo del escritorio e hice una pequeña app para que los traders ingresaran operaciones y siguieran sus posiciones. Los traders empezaron a preferirla porque era más fácil de usar que la solución oficial de IT y les permitía ver mejor sus posiciones.
    En muchos entornos corporativos, encontrar formas de esquivar a IT es una función importante. Volviendo a Excel: los traders usaban Excel para cálculos y simulaciones, y nosotros intentábamos aprovechar lo que ya hacían ofreciéndoles herramientas que se integraban con Excel.
  • Hay una frase en el artículo que dice que esta es una decisión explícita de política de la empresa:
    “Permitir a los usuarios finales acceder a un lenguaje de programación de alto nivel va en contra de la visión de estrategia tecnológica de la empresa”.
  • La respuesta es esta: porque el único lenguaje de programación que las empresas no pueden optar por no instalar es VBA.
    Las maravillas del “enterprise”. Me sorprende cada vez que alguien lo saca a relucir como si fuera una ventaja o una excusa.

• Porque hasta hace poco no había buenas alternativas. El futuro está en el nuevo modelo de complementos de Office: https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...
  Digan lo que digan de TypeScript, al menos es mejor que VBA. Pero, a diferencia de VBA, el gran problema es que no se puede programar directamente dentro de Excel. A veces uno no quiere iniciar un proyecto serio de complemento pensando en reutilizarlo, sino simplemente un script para ejecutar una sola vez y arreglar algo en ese momento. Mientras veía esto me enteré de Script Lab (https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...), y quizá sirva de ayuda.

  • Que “a diferencia de VBA, no se puede programar directamente dentro de Excel” es casi un motivo para descartar la operación.
    Además, hay una pregunta obvia: ¿un usuario sin privilegios puede instalar complementos sin intervención del departamento de TI? ¿Se pueden incluir dentro de una hoja de cálculo? Si la respuesta a lo primero es “no”, de verdad es fatal; y si la respuesta a lo segundo también es “no”, afecta negativamente su adopción. La ventaja de las macros y VBA es que, salvo por la configuración de seguridad, cualquier instancia de Excel puede ejecutarlas de inmediato sin instalaciones adicionales.
  • No vi la mención a Script Lab al final del comentario. Si es Microsoft Script Lab, permite hacer justamente eso: https://www.microsoft.com/en-us/garage/profiles/script-lab/
    Otro problema es que compartir complementos con usuarios finales no es trivial. Hay que publicarlos en el marketplace o en SharePoint, y la carga lateral requiere un servidor SMB y GPO. Pero hay una opción que casi no se menciona en ningún lado: se puede incluir en el documento para que, al abrirlo por primera vez, se instale después de la confirmación del usuario.
  • Está bien si solo se quiere mostrar una interfaz bonita para entrada de datos o visualización, pero lamentablemente OfficeJS no puede hacer ni la mitad de lo que puede hacer VBA. Si el sistema de complementos tuviera FFI, me habría cambiado para siempre.
    Otro gran problema es que, para usar OfficeJS, hay que poder alojar un servidor web. Normalmente la mayoría de los usuarios finales no tienen ese tipo de acceso.

• VB(A) es parecido a Python. No es bonito, pero hace el trabajo. Si te parece bonito, es porque te falta experiencia y no conoces muchas alternativas mejores.
  Una herramienta con un buen ecosistema —herramientas, bibliotecas e integraciones— que permite terminar trabajo real es útil. Como sistema de desarrollo de apps de escritorio, Visual Basic, junto con MS Access y sus ventajas de base de datos, fue muy útil en muchas situaciones. Si llegabas al punto de superarlo, probablemente también tenías dinero para escalar a una solución “de verdad”.
  No hay duda de que se ganó muchísimo dinero con sistemas basados en VBA. Según mi experiencia haciendo desarrollo financiero sobre todo desde fuera, la mayor reescritura de Excel/VBA que vi fue la de una empresa que ganó mucho dinero con credit default swaps alrededor de 2008. Antes de la reescritura, el libro tardaba 5 minutos en abrirse, pero VBA estaba encargándose de gran parte del trabajo pesado. Las personas con conocimiento estaban ganando muchísimo dinero en bonos, tanto para la empresa como para ellas mismas.
  La lección aquí es que importa más si la herramienta es accesible para personas que no fueron entrenadas específicamente para usarla que si es ideal. Esa es también la razón por la que Python se volvió número 1 fuera del navegador web del cliente. No significa que sea la mejor, sino que hace el trabajo y es accesible.

  • Se puede sostener que Python es un lenguaje bonito, y es un lenguaje completo con soporte para clases y funciones de primera clase, pero aun así es relativamente simple y accesible.
    Pero esa no es la única razón de su popularidad. Tiene las herramientas de ciencia de datos más sólidas, lo que generó un efecto abrumador, y también cuenta con frameworks web decentes como Django y Flask. El hecho de que en muchas universidades haya reemplazado a Java como “primer lenguaje de aprendizaje” también impulsó su popularidad. VBA no es así.
  • Python es bonito, y considero que su forma de usar espacios en blanco es mejor que estrategias de delimitación de bloques como llaves, begin/end o if/else.
    La experiencia también consiste en saber que hay un componente subjetivo en si algo es bonito o no. VBA evolucionó en condiciones “duras”, así que sus rarezas se explican en cierta medida.
  • Python no es Scheme, pero entre los lenguajes de programación definitivamente está entre los bonitos, y en muchos casos no hay mejores alternativas. Lo digo con unos 25 años programando en decenas de lenguajes.

• VBA es un lenguaje bastante bueno que admite programación orientada a objetos. No tiene herencia, pero sí permite composición. Puede acceder y controlar Excel en profundidad, y es maduro y estable. Eso se debe a que Microsoft ya no lo cambia demasiado.
  A los “programadores de verdad” no les gusta VBA sobre todo porque hay mucho código VBA espagueti amateur escrito por gente de negocio, y de vez en cuando les piden a los programadores que lo depuren.

  • Como contraargumento, VBA es un lenguaje terrible salvo por el hecho de que puede acceder y controlar Excel, Word, etc.
    Está lleno de peculiaridades extrañas, como que los caracteres de control dentro del código se localizan.[1][2] Si quieres que el código funcione también en instalaciones que no estén en inglés, tienes que usar marcadores como Application.International(xlDecimalSeparator) para construir dinámicamente las cadenas que le pasas a esa función, y la legibilidad del código cae muchísimo. Cuando el código se rompe por este motivo, los mensajes de error son increíblemente poco útiles, y si el desarrollador no sabe que esto es un posible problema de VBA, reproducirlo es prácticamente imposible. Para reproducirlo, hay que cambiar el idioma de la interfaz a un idioma que quizá ni siquiera conozcas.
    Al menos en Word, cerca de la mitad de las funciones más útiles, como insertar un párrafo después del párrafo actual, se rompen si se usan en el último párrafo de una celda de tabla, por lo que hacen falta muchos rodeos espagueti.
    Si quieres intercambiar cadenas de texto con varios formatos, como al referenciar la propiedad innerHtml de un elemento del DOM, no es fácil a menos que uses selección basada en scripts y copiar/pegar de forma hacky.
    Alguien en otro hilo lo comparó con Bash, y la verdad estoy de acuerdo. No deberías escribir nada complejo en ninguno de los dos lenguajes.
    [1] https://stackoverflow.com/questions/20652409/using-vba-to-de...
    [2] https://stackoverflow.com/questions/29832281/vba-range-funct...
  • Invertí muchísimo tiempo en crear una biblioteca para VBA (https://github.com/sancarn/stdVBA) y me gusta VBA, pero el lenguaje tiene problemas reales que lo limitan mucho (https://sancarn.github.io/vba-articles/issues-with-vba.html).
    Dicho eso, también es cierto que buena parte del odio que recibe VBA viene del estado de los proyectos en VBA (https://sancarn.github.io/vba-articles/why-is-vba-most-dread...).
  • Me parece justo mirar con malos ojos un entorno que incluye funcionalidades mal diseñadas como On Error Resume Next.

• Si pensamos en Excel y en las hojas de cálculo en general, mucha gente de afuera no entiende bien qué tan bien implementan las hojas de cálculo la programación funcional reactiva. Es exactamente eso que React/Angular llevan más de 10 versiones intentando hacer bien.
  Además, mucha gente no entiende por qué las hojas de cálculo son tan cómodas para los usuarios finales, y como resultado ofrece interfaces de usuario inferiores que en realidad hacen las cosas más difíciles.
  A veces hay que dar un paso atrás y entender que, incluso en la época en que no había interfaces gráficas, la gente de antes hacía bien las cosas. Los negocios funcionaban desde el principio, y durante la mayor parte del tiempo lo que las empresas necesitan es una vista en forma de tabla y la opción de hacer cálculos funcionales reactivos sobre ella. Si le preguntas a algún amigo que trabaje en una pyme, te lo va a confirmar.

  • Gran parte del esfuerzo en el desarrollo web se va en la presentación. Si lo único que necesitas son datos, coincido en que es difícil superar a una hoja de cálculo.
  • Excel puede considerarse el mejor IDE para usuarios finales jamás inventado.