La simplicidad y coherencia de Smalltalk frente a otros lenguajes (2022) [video]

Simplicidad, sintaxis y compromisos

• La sintaxis de Smalltalk es extremadamente mínima y uniforme, pero los comentaristas subrayan que esto no hace automáticamente que el código sea más fácil de leer/escribir ni que los compiladores sean fáciles de optimizar.
• Los bloques y el paso de mensajes unifican las estructuras de control con las llamadas normales a métodos, pero requieren casos especiales en el compilador (p. ej., inlining de ifTrue: / whileTrue:) para evitar grandes ralentizaciones.
• El modelo de “todo es un mensaje a un receptor” empuja el diseño hacia la distribución del comportamiento entre jerarquías de clases/traits, lo que algunos ven como elegante y otros como una complejidad añadida frente a las funciones simples de otros lenguajes.
• La familiaridad influye fuertemente en lo que se percibe como “simple”; un lenguaje demasiado minimalista puede complicar las soluciones.

Rendimiento y optimización de la VM

• Hay un debate animado sobre por qué históricamente las VMs de Smalltalk quedaron por detrás de los motores JS de alto rendimiento.
• Un lado lo atribuye en parte al diseño del lenguaje/VM (por ejemplo, bloques, despacho dinámico) más difícil de compilar bien con JIT, comparando la trayectoria de Smalltalk con la de Python.
• Otros argumentan que las diferencias de rendimiento se deben sobre todo a la inversión: JS tiene equipos grandes y bien financiados; OpenSmalltalk depende de voluntarios. Usar Squeak/Pharo como referencia de rendimiento se califica de engañoso.
• Se citan ejemplos de sistemas tipo Smalltalk de alto rendimiento (Self, Strongtalk, variantes de SOM basadas en Truffle/Graal, TruffleSqueak) que pueden igualar o superar a JS en algunos benchmarks, cuestionando las afirmaciones de que “Smalltalk es lento”.
• En el caso de Python, se describe que las razones subyacentes de la dificultad de optimización no están claras; se menciona la fuerte acoplamiento de CPython con extensiones en C, pero sin resolverlo.

Entornos de programación en vivo

• Muchos se sienten fascinados por el entorno vivo e basado en imágenes de Smalltalk, donde el código, la GUI, el depurador y las herramientas están integrados y siempre en ejecución.
• Esto se contrasta con los flujos de trabajo convencionales que requieren recompilar/reiniciar, vistos como un paso atrás.
• Se mencionan Emacs y los sistemas Lisp/Interlisp como espiritualmente similares (extensibles, vivos, con historia basada en imágenes), pero no idénticos en la experiencia; Smalltalk se ve como más coherente, Emacs como más “kludgy”.
• Desventajas: los entornos Smalltalk modernos pueden ser pesados (p. ej., 1 GB+ de RAM) y torpes de desplegar porque es necesario distribuir la VM/imagen.

Practicidad, herramientas y experiencia en proyectos

• Algunas anécdotas describen una productividad y herramientas impresionantes en sistemas Smalltalk (bases de datos OO, motores de flujo de trabajo, automatización integrada en el IDE).
• Contraanécdota: un gran proyecto secreto en Smalltalk que casi no produjo nada demostrable; el lenguaje no fue el único problema, pero el secretismo, la falta de validación y las dificultades históricas de SCM/configuración en Smalltalk jugaron un papel.
• Preocupaciones sobre la practicidad moderna de Smalltalk: percibida falta de bibliotecas “batteries included”, multithreading débil o ausente en implementaciones FOSS comunes, y UIs torpes (editores pequeños, flujos centrados en el ratón).
• Otros señalan que los Smalltalk comerciales anteriores estaban “batteries included” para su época; lo que es práctico varía según la década.

Filosofía del lenguaje y realidad profesional

• Algunos participantes sienten que los lenguajes dominantes (Python, C++, Java) son mucho menos agradables o expresivos que Smalltalk, Lisp, F#, Elixir, etc., pero se ven obligados a usarlos por razones profesionales.
• Consejo dado:
  • Prototipa en tu lenguaje preferido y demuestra una productividad/valor drásticamente superiores para influir en la elección del stack.
  • Prepárate para enseñar a tus compañeros si introduces un lenguaje de nicho.
  • Alternativamente, adopta herramientas populares pero aplica ideas de lenguajes “mejores” en el estilo de diseño y las abstracciones.
• Hay tensión entre amar las herramientas y centrarse en resolver problemas:
  • Un bando dice que la estética de las herramientas es una distracción; lo que importa es la eficacia.
  • Otro sostiene que las herramientas de alta calidad “disuelven” los problemas y que dominar las herramientas es crucial.
  • Algunos proponen un punto intermedio: no estar románticamente apegado a las herramientas, pero tampoco ignorar su impacto.

Comparaciones con otros lenguajes y sistemas

• Smalltalk se compara repetidamente con:
  • Lisp y las antiguas Lisp machines/Interlisp (imágenes, GC, desarrollo interactivo).
  • JS, Python, Ruby y modelos de despacho dinámico; la búsqueda de métodos basada en diccionarios se considera a la vez potente y un lastre para el rendimiento.
  • Tcl y GNU Smalltalk como opciones de scripting; GNU Smalltalk se caracteriza más como “scripting con sabor a Smalltalk” que como un entorno Smalltalk completo, con un estado de mantenimiento cuestionable.
• Se debate la “homoiconicidad”:
  • Algunos afirman que Smalltalk es homoicónico como Lisp; otros argumentan que en los Lisps compilados y entornos modernos, la noción clásica de “código como datos con la misma representación” realmente no se aplica.

Aprendizaje, configuraciones mínimas y experimentos

• La gente pide más vídeos de Smalltalk con “live coding”; se comparten enlaces a tutoriales de Pharo, charlas sobre edición en vivo y juegos, y demos introductorias de Smalltalk.
• Glamorous Toolkit (sobre Pharo) se destaca como un entorno moderno de “moldable development” donde la documentación en sí misma es código vivo y editable.
• Algunos quieren configuraciones Squeak ultraminimalistas (sin gráficos/sonido, solo REPL en dispositivos pequeños como Raspberry Pi Zero); se describe como algo no trivial, sin una ruta simple y documentada en el hilo.
• Se plantean ideas para:
  • Un sistema tipo Smalltalk sobre la VM BEAM de Erlang/Elixir para ganar concurrencia y distribución.
  • Usar VMs de JS como destinos de despliegue para Smalltalk (por ejemplo, squeak.js).
  • Considerar Objective-C (inspirado en Smalltalk) como una alternativa dinámica más práctica hoy en día; esto se menciona pero no se discute en profundidad.