Lanzamiento de Tcl 9.0

• Tcl/Tk 9.0 es la versión mayor más reciente de Tcl y Tk, e incluye nuevas funciones junto con algunas incompatibilidades respecto de Tcl/Tk 8
• La versión más reciente indicada es Tcl/Tk 9.0.4, con fecha del 26 de junio de 2026
• Tcl ofrece capacidad de 64 bits para manejar valores de datos de más de 2 GB; las cadenas pueden tener una longitud arbitraria dentro del límite de la memoria disponible, y las listas y diccionarios pueden contener una cantidad muy grande de elementos
• El procesamiento de texto ofrece todo el rango de puntos de código Unicode, nuevas codificaciones como las familias utf-16, utf-32 y ucs-2, además de CESU-8, encoding profiles para controlar la codificación de I/O, y -encoding utf-8 como valor predeterminado de source
• Tcl permite montar archivos zip como un sistema de archivos mediante zipfs, y admite la distribución de aplicaciones al estilo starkit mediante archivos de sistema de archivos adjuntos a ejecutables o bibliotecas
• El motor de procesamiento de eventos en Unix se configura sobre epoll o kqueue cuando están disponibles, mientras que en plataformas sin esas llamadas al sistema se mantiene una implementación basada en select
• Entre las principales incompatibilidades de Tcl 9.0, los nombres de variables no calificados se interpretan en el namespace actual y no en el global; la respuesta predeterminada ante malencoding en I/O pasa a ser un error (-profile strict); ~ en las rutas ya no se interpreta como el directorio home; y $::tcl_precision ya no se usa para controlar la generación de cadenas de valores double
• Como cambios de compilación y plataforma, se eliminó la opción de build --disable-threads, por lo que siempre está habilitado para threads, y Windows requiere Windows 7 o Windows Server 2008 R2 o superior
• En las extensiones C de Tcl, los binarios compilados para Tcl 8.6 o versiones anteriores no funcionan en Tcl 9.0; la compatibilidad ABI de Tcl 9.0 no fue un objetivo, y en la mayoría de los casos es posible recompilar para Tcl 9.0 si no se usan funciones de API eliminadas
• En la interfaz pública de C, muchos argumentos se ampliaron de int a Tcl_Size, se dejó de admitir Tcl_ChannelTypeVersion menor que 5, se introdujo versionado en la estructura Tcl_ObjType, y se eliminaron las macros CONST* y varias funciones de API
• Tk 9.0.0 no soporta Tcl 8.6, y para usar Tk 9.0.0 primero se requiere Tcl 9.0.0
• Tk ofrece tk sysnotify, tk print y tk systray para acceder a funciones de notificaciones, salida e íconos de bandeja del sistema operativo
• Las imágenes de Tk ofrecen soporte parcial para SVG, lectura y escritura de metadata en photo images, y acceso al canal alfa
• Los widgets y temas integrados de Tk ahora son scaling-aware, se mejoró el soporte para gestos con dos dedos en entornos disponibles, y “aqua” en tk windowingsystem requiere macOS 10.10 o superior
• Como material para migrar a Tcl 9, están disponibles Migrating C extensions to Tcl 9 y Migrating scripts to Tcl 9

[GN⁺]

Opiniones en Hacker News

• Es el primer lanzamiento mayor en 27 años. Como la estructura interna es de 64 bits, los datos pueden volverse muy grandes, y hay muchas funciones nuevas, como Unicode completo, incluidos los emojis modernos, sistema de archivos Zip, etc.
  También se eliminaron algunos restos antiguos, así que es posible que algunos programas necesiten actualizarse, pero la compatibilidad sigue siendo bastante alta. En la página de arriba hay enlaces a las notas de lanzamiento, que detallan las funciones incluidas y excluidas.

  • El cambio del sistema de archivos Zip es realmente bienvenido. Antes, para crear aplicaciones independientes, la comunidad usaba varias técnicas con herramientas y conocimientos específicos; ahora las incorporaron a un conjunto de herramientas básico y estándar, así que es un cambio excelente.
  • Me da curiosidad por qué eliminaron la virgulilla ~, que era una abreviatura cómoda para ir al directorio Home.

• Los puristas del lenguaje y los puristas de la orientación a objetos al estilo de los años 90 realmente detestan Tcl, pero el ecosistema tiene una filosofía de diseño especial.
  Todo es una cadena o un comando, y las extensiones de orientación a objetos se sienten un poco añadidas encima, pero si pruebas crear una GUI con Tcl/Tk puro en vez de usar Tcl desde Python como con tkinter, o usar la interfaz de SQLite, o escribir una pequeña extensión en C o envolver una biblioteca, muchas cosas simplemente funcionan bien.

  • Vi una perspectiva interesante en el artículo sobre Tcl escrito por antirez [1]. Si no recuerdo mal, Redis usa Tcl en sus scripts de prueba.
    Llegué a él siguiendo un enlace desde la documentación de https://folk.computer, y ese proyecto también usa Tcl como lenguaje de scripting. Para ese tipo de uso, quizá no haya mucha razón para odiar Tcl.
    [1] http://antirez.com/articoli/tclmisunderstood.html
  • Tcl hizo posible nuestra startup, y la experiencia y los aprendizajes de entonces se convirtieron en el punto de partida de OutSystems.
    Una de esas lecciones fue que nunca más querría usar un lenguaje dinámico sin compilador JIT para un servidor web completo. El lenguaje en sí es excelente, pero no era agradable tener que reescribir periódicamente bibliotecas Tcl en C por problemas de rendimiento.
  • Decir “todo es una cadena o un comando” no es una exageración. De verdad todo es un comando, por lo que la forma de comentar aquí llega al nivel de “¿pero por qué demonios es así?”: https://wiki.tcl-lang.org/page/comment
    Antes de escribir un comentario tienes que terminar el comando con ;, las llaves deben estar balanceadas, así que no debes intentar comentar código incorrecto, y tampoco puedes poner barras invertidas dentro de los comentarios. Aun así, lo explican como una función, porque al ejecutar wish se escribe algo como esto:
    #!/bin/sh
# the next line restarts using wish \
exec wish8.0 "$0" "$@"
    La barra invertida se ignora en el shell, pero wish la parsea.
  • Trabajé mucho con Tcl mientras hacía trabajos de benchmarks TPC para Citus.
    https://github.com/TPC-Council/HammerDB/blob/master/src/post...
    Tcl está bastante bien como lenguaje de shell scripting.

• Que el motor central de procesamiento de eventos de Tcl se construya sobre epoll o kqueue cuando estén disponibles, y que quede una implementación basada en select para las plataformas donde no lo estén, es un cambio enorme.
  Una de las grandes razones por las que se consideraba que la concurrencia de Tcl era anticuada y de bajo rendimiento era que dependía de select, aunque epoll y kqueue llevaban al menos 10 años disponibles. Tcl es uno de mis lenguajes favoritos porque es fácil empezar con él y también es fácil hacer metaprogramación.

  • La razón principal por la que se considera que Tcl tiene bajo rendimiento es que sus operaciones básicas son aproximadamente el doble de lentas que las de CPython. Y CPython tampoco es precisamente rápido: https://news.ycombinator.com/item?id=41637953
    Otra razón es que no sabemos bien cómo escribir Tcl rápido, y en ese hilo yo lo demostré sin querer.

• Quiero recomendar NaviServer [0]. Su nombre anterior era AOLServer [1], y es un servidor web a prueba de balas, probado durante mucho tiempo en producción.
  Si fue algo que se usó para operar AOL en su momento, no hace falta decir más. OpenACS [2] es el proyecto principal y existe desde 1997; es especialmente potente cuando se usa con Tcl. Todavía está mantenido y ahora también soporta Tcl 9.
  La combinación de JavaScript, Tcl y NaviServer, sumada a sus propios módulos como DNS Server, LDAP y Mail, se vuelve una herramienta poderosa. Si quieres iniciarte en Tcl y el desarrollo web, recomiendo probarlos juntos, porque es fácil crear cosas interesantes.
  [0] https://wiki.tcl-lang.org/page/NaviServer
  https://github.com/naviserver-project/naviserver
  [1] https://news.ycombinator.com/item?id=35648805
  https://www.linuxjournal.com/article/6164
  [2] https://openacs.org/about/history
  https://openacs.org/

  • Es un stack de recuerdos con el que aprendí Tcl y SQL a mediados de los 90. En ese entonces no jugaba con OpenACS, sino con el propio ArsDigita Community System, cuando ArsDigita todavía existía de verdad.
    Recuerdo también haber tomado clases gratuitas patrocinadas e impartidas directamente por ArsDigita en una oficina que quedaba en Pasadena, CA, o quizá en Glendale. No fueron muy profundas ni largas, pero sirvieron bien como introducción.

• Para quienes se acercan a Tcl por primera vez, también existió un universo alternativo en el que Tcl se convirtió en el lenguaje del navegador en lugar de JavaScript
  “Nota al pie interesante: la fundación de Netscape coincidió con la época en que dejé Berkeley en 1994 y estaba decidiendo hacia dónde ir en la industria. Jim Clarke y Marc Andreessen tantearon la posibilidad de que me uniera como fundador de Netscape, pero al final rechacé la oferta. Cuando hablé con ellos, todavía ni siquiera había decidido trabajar en algo relacionado con la web. Es uno de los grandes ‘qué habría pasado si…’ de mi carrera. Si hubiera ido a Netscape, es bastante posible que Tcl se hubiera convertido en el lenguaje del navegador en lugar de JavaScript, ¡y el mundo habría sido distinto! Dicho eso, en retrospectiva no estoy seguro de que Tcl hubiera sido realmente un mejor lenguaje para la web que JavaScript, así que quizá ocurrió lo correcto.”
  Fuente: https://pldb.io/blog/JohnOusterhout.html

  • Podría ser. Creo que una de las principales razones por las que JavaScript se impuso fue que no tenía una gran carga histórica, así que sus diseñadores pudieron llevarlo en la dirección necesaria
    Cualquier lenguaje usado por más de unas pocas personas acumula alguna carga, por bueno que sea. Así que, en ese universo alternativo, el ecosistema de lenguajes de scripting para el navegador podría haber estado mucho más fragmentado
  • El trabajo sobre un subconjunto seguro de Tcl para la web todavía puede aprovecharse para ejecutar scripts no confiables en un sandbox fácil de gestionar
    Si se quiere, se pueden quitar suficientes comandos como para que el lenguaje deje de ser Turing completo
  • Curiosamente, el plugin de Tcl para navegadores existía al menos desde 1996
    https://sunsite.icm.edu.pl/pub/programming/tcl/plugin/
    También recuerdo que, antes de eso, unos compañeros estudiantes llegaron al laboratorio de cómputo diciendo: “¡Miren, ahora también hay un plugin de TK para Mosaic!”. No era exactamente la época de “¡parece gopher con mouse!”, pero tampoco había pasado tanto tiempo
    El problema es que para usar el plugin de Tcl había que hacer algo por cuenta propia, mientras que JavaScript, una vez que llegó, venía incluido por defecto
  • Aunque eso hubiera pasado, no creo que el mundo se hubiera quedado con TCL. JavaScript era lo bastante bueno como para que la gente lo tolerara, pero TCL claramente no
    Lo más probable es que TCL hubiera convivido con alguna otra cosa, y luego TCL hubiera quedado marcado como obsoleto
  • Estoy totalmente de acuerdo con lo de “quizá ocurrió lo correcto”
    No habría querido ver código como set x [ expr $y + $z ] por todas partes. Como lenguaje de comandos no está tan mal, eso sí

• No es exagerado decir que realmente me gusta Tcl. Solo lo usé un poco a fines de los 90, cuando escribía scripts para XiRCON IRC, pero era un lenguaje elegante, tan simple, fácil de aprender y flexible como para llamarlo Lisp para humanos
  Ojalá hubiera sido más popular, y me da gusto ver que todavía sigue vivo

  • Mi contacto con Tcl se limitó a escribir scripts para bots de IRC, pero no tengo más que buenos recuerdos de esa experiencia
  • En los 90 escribí scripts en TCL para clientes de IRC y me encantó. Para ese uso, el lenguaje era excelente
    Aunque, como mi otro lenguaje principal en esa época era ensamblador x86, quizá mi estándar para impresionarme era bajo
  • Para llamarlo “Lisp para humanos”, existe upvar

• El autor de Tcl y Tk es el profesor John Ousterhout, y su libro sobre diseño de software ya va por la segunda edición
  A Philosophy of Software Design:
  https://web.stanford.edu/~ouster/cgi-bin/book.php

  • Este libro es realmente excelente y lo estoy leyendo ahora. Leo un capítulo por vez, intento reflexionar lo más profundamente posible y luego aplico esas lecciones para reescribir mi proyecto actual
    Ahora estoy en el capítulo 11, “Design it Twice”, así que probablemente, cuando termine, lo reescriba por completo de arriba abajo. Actualmente es un modelo en el que solo las variables están en un núcleo mínimo de Python y el resto está en OpenSCAD, pero en la nueva implementación planeo poner todo lo posible en Python y usarlo mediante OpenPythonSCAD https://pythonscad.org/

• Me gusta mucho el lenguaje, pero hoy en día no lo uso demasiado. Me pregunto si en Linux todavía produce GUIs estilo 1995
  Si hubiera tenido un soporte de GUI para Linux medianamente razonable, al nivel que otras plataformas tenían desde hace mucho, probablemente todavía lo estaría usando

  • El motor de temas ya se incorporó hace unos 15 años. El tema predeterminado se ve bastante viejo, pero hay muchos otros temas: https://wiki.tcl-lang.org/page/List+of+ttk+Themes
    Eso sí, las capturas de pantalla de los temas principales son de 8.5/8.6 y, en particular, el tema predeterminado cambió un poco en Tk 9. La trampa es que el motor de temas usa sus propios widgets nuevos, así que para que una aplicación reciba el tema tiene que usar la nueva API. Si es código de 1995 o 2005, seguirá produciendo una GUI estilo 1995
  • Recuerdo haber usado Tkinter cuando aprendía Python. Hay otras GUI, pero encontrar ejemplos que funcionen como una GUI moderna da más trabajo
    La documentación estuvo centrada en Tk(inter) durante demasiado tiempo, así que la mayoría parece elegirlo como si fuera la opción por defecto. Python mejoró su soporte de GUI, pero probablemente influyó su popularidad para machine learning/IA. Como Tcl es menos popular, hay que revisar con más cuidado para encontrar documentación sobre cómo usar GUIs modernas

• Lo más reciente que he hecho con Tcl fue apenas trabajar en un portfile de MacPorts.
  Si alguien lo usa hoy para otros fines, me da curiosidad saber por qué. No me desagrada el lenguaje, pero tampoco llegué a quererlo.

  • Creo que Tcl se parece más a Lisp para programadores de C. Ofrece la capacidad de metaprogramación que se obtiene de Lisp en un lenguaje que se ve como C, se lleva bien con C, es mucho más intuitivo que un lenguaje de shell común y además tiene GUI multiplataforma.
    Un programador experimentado de Tcl puede hacer magia. De 2005 a 2015 programé casi exclusivamente en Tcl/Tk y de verdad me gustaba. Desde entonces lo uso más para scripts ligeros que para escribir apps, pero sigue siendo mi primera opción cuando tengo que crear scripts de automatización a nivel de sistema operativo.
  • Los usos estándar son BigIP iRules[0] en equipos de red F5 y A10, la orquestación de supercomputadoras de Argonne National Labs[1], Tealeaf[2], Python Tkinter[3], etc.
    Lo uso todos los días porque logra un buen equilibrio entre su lado tipo Lisp y la simpleza de un lenguaje de scripting, y porque su interfaz con C es excelente. El REPL también está bien, y se pueden escribir extensiones en C y apilarlas como Tcl 100% de primera clase. Esto se debe en gran parte, quizá por completo, a que Tcl es un lenguaje muy simple[4] y tiene homoiconicidad[5]. Es divertido desarrollarlo y usarlo.
    [0] https://community.f5.com/kb/technicalarticles/irules-concept...
    [1] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf
    [2] https://www.acoustic.com/pdf/Acoustic-Experience-Analytics-%...
    [3] https://docs.python.org/3/library/tkinter.html
    [4] https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm
    [5] https://stackoverflow.com/questions/6492704/what-exactly-doe...
  • Tcl es el lenguaje de scripting de la industria EDA. Si diseñas chips de computadora, estás usando TCL. Cadence y Synopsys llevan más de 30 años tomando TCL como estándar.
    La ventaja es que permite manejar herramientas EDA como si fueran comandos de un script de shell, tipo run_my_task -option_a -option_B. Si no diseñas chips, no hay razón para usarlo, y el lenguaje en sí es horrible. Mientras antes la industria EDA abandone TCL, mejor.
  • Richard Hipp, creador de SQLite, dice que SQLite está escrito en Tcl. El motor de base de datos en sí, por supuesto, está escrito en C, pero la suite de pruebas, mucho más grande, está escrita en su mayor parte en Tcl.
    Y esa suite de pruebas es lo que convierte a SQLite en el motor confiable que es hoy. La suite de pruebas se ha seguido manteniendo, mientras que el motor se ha reescrito total o parcialmente a lo largo del tiempo.
  • Usé Tcl algunas veces por Freewrap. Con muy poco código podía crear apps de Windows con GUI y distribuirlas fácilmente como ejecutables.
    Hice una app de respaldo para una aplicación de ventas en línea, una app para arreglar archivos POS con bugs de una gran cadena minorista, una pequeña app que copiaba Forms/Reports al servidor, ejecutaba la compilación y luego subía los archivos nuevos a git, y un wrapper de gs para que el departamento de medios pudiera combinar varios PDF en uno. Todas tenían apenas una o dos páginas de código.

• Es más importante que Python 3.13.
  ¡Bravo!
  Estoy esperando que Scilab y Python se distribuyan con Tcl/Tk 9.0 incluido. Parece que la versión más reciente de Next Scripting ya está lista para 9.0. Vale la pena estar atentos a las secciones Undroidwish y Binary Releases de la página oficial.