Sortie de Tcl 9.0

• Tcl/Tk 9.0 est la dernière version majeure de Tcl et Tk, avec de nouvelles fonctionnalités et certaines incompatibilités par rapport à Tcl/Tk 8
• La dernière version publiée est Tcl/Tk 9.0.4, datée du 26 juin 2026
• Tcl offre une capacité 64 bits pour gérer des valeurs de données dépassant 2 Go ; les chaînes peuvent avoir une longueur arbitraire dans la limite de la mémoire disponible, et les listes comme les dictionnaires peuvent contenir un très grand nombre d’éléments
• Le traitement de texte couvre l’ensemble de la plage des points de code Unicode, de nouveaux encodages comme utf-16, utf-32, la famille ucs-2 et CESU-8, des profils d’encoding pour contrôler l’encodage des E/S, ainsi que -encoding utf-8 par défaut pour source
• Avec zipfs, Tcl peut monter des fichiers zip comme un système de fichiers et prend en charge le déploiement d’applications de type starkit via des archives de système de fichiers attachées à des exécutables ou des bibliothèques
• Le moteur de traitement des événements Unix est configuré sur epoll ou kqueue lorsqu’ils sont disponibles ; une implémentation basée sur select reste utilisée sur les plateformes qui ne disposent pas de ces appels système
• Parmi les principales incompatibilités de Tcl 9.0 : les noms de variables non qualifiés sont résolus dans le namespace courant et non plus globalement ; la réponse par défaut aux erreurs d’encodage E/S devient une erreur (-profile strict) ; ~ dans les chemins n’est plus interprété comme le répertoire personnel ; $::tcl_precision n’est plus utilisé pour contrôler la génération des chaînes des nombres double
• Côté build et plateformes, l’option de compilation --disable-threads a été supprimée et les builds sont donc toujours thread-enabled ; sous Windows, Windows 7 ou Windows Server 2008 R2 minimum est requis
• Pour les extensions Tcl en C, les binaires compilés pour Tcl 8.6 ou antérieur ne fonctionnent pas avec Tcl 9.0 ; la compatibilité ABI avec Tcl 9.0 n’était pas un objectif et, dans la plupart des cas, une recompilation pour Tcl 9.0 suffit si aucune fonction d’API supprimée n’est utilisée
• L’interface publique C a été modifiée avec de nombreux arguments passant de int à Tcl_Size, l’arrêt du support de Tcl_ChannelTypeVersion inférieur à 5, l’introduction d’un versionnement pour la structure Tcl_ObjType, ainsi que la suppression des macros CONST* et de plusieurs fonctions d’API
• Tk 9.0.0 ne prend pas en charge Tcl 8.6, et l’utilisation de Tk 9.0.0 nécessite d’abord Tcl 9.0.0
• Tk fournit tk sysnotify, tk print et tk systray pour accéder aux notifications, à l’impression/sortie et aux fonctions de zone de notification du système
• Les images Tk prennent en charge partiellement SVG, la lecture/écriture des metadata des images photo, ainsi que l’accès au canal alpha
• Les widgets intégrés et les thèmes de Tk sont désormais adaptés à la mise à l’échelle, la prise en charge des gestes à deux doigts a été améliorée lorsque l’environnement le permet, et “aqua” de tk windowingsystem nécessite macOS 10.10 ou version ultérieure
• Des ressources de migration vers Tcl 9 sont disponibles : Migrating C extensions to Tcl 9 et Migrating scripts to Tcl 9

[GN⁺]

Avis sur Hacker News

• C’est la première version majeure en 27 ans. La structure interne est en 64 bits, ce qui permet des données très volumineuses, et il y a beaucoup de nouveautés, comme la prise en charge complète d’Unicode avec les emoji récents, un système de fichiers Zip, etc.
  Une partie des vieux résidus a aussi été supprimée, donc certains programmes pourraient nécessiter une mise à jour, mais la compatibilité reste globalement élevée. La page ci-dessus renvoie vers les notes de publication détaillant les fonctionnalités incluses et exclues.

  • Le changement autour du système de fichiers Zip est vraiment bienvenu. Auparavant, pour créer des applications autonomes, la communauté utilisait diverses techniques avec des outils et du savoir-faire spécifiques ; les intégrer à l’ensemble d’outils de base, de manière standard, est une excellente évolution.
  • Je me demande pourquoi ils ont supprimé le tilde ~, qui était une notation abrégée pratique pour accéder au répertoire Home.

• Les puristes du langage et les puristes de l’orienté objet façon années 1990 détestent vraiment Tcl, mais son écosystème a une philosophie de conception particulière.
  Tout est chaîne de caractères ou commande, et les extensions orientées objet donnent un peu l’impression d’avoir été greffées dessus, mais si l’on essaie de créer une interface graphique en Tcl/Tk pur plutôt que d’utiliser Tcl depuis Python comme avec tkinter, d’utiliser l’interface SQLite, d’écrire une petite extension en C ou d’envelopper une bibliothèque, beaucoup de choses fonctionnent tout simplement bien.

  • J’ai trouvé un point de vue intéressant dans l’article d’antirez sur Tcl [1]. Si ma mémoire est bonne, Redis utilise Tcl pour ses scripts de test.
    Je l’ai découvert en suivant un lien dans la documentation de https://folk.computer ; ce projet utilise aussi Tcl comme langage de script. Pour ce type d’usage, il n’y a peut-être pas vraiment de raison de détester Tcl.
    [1] http://antirez.com/articoli/tclmisunderstood.html
  • Tcl a rendu notre startup possible, et l’expérience et les apprentissages que nous en avons tirés sont devenus le point de départ d’OutSystems.
    L’un d’eux était que je ne voudrais plus jamais utiliser un langage dynamique sans compilateur JIT pour un serveur web complet. Le langage lui-même est excellent, mais devoir réécrire régulièrement des bibliothèques Tcl en C à cause des problèmes de performance n’était pas très agréable.
  • Dire que « tout est chaîne de caractères ou commande » n’est pas une exagération. Absolument tout est une commande, au point que la façon de gérer les commentaires donne vraiment envie de se demander « mais pourquoi donc ? » : https://wiki.tcl-lang.org/page/comment
    Il faut terminer la commande avec ; avant d’écrire un commentaire, les accolades doivent rester équilibrées, donc il ne faut pas essayer de commenter du code incorrect, et on ne peut pas non plus mettre de barre oblique inverse dans un commentaire. Cela dit, c’est aussi présenté comme une fonctionnalité, parce qu’on écrit ceci lorsqu’on lance wish :
    #!/bin/sh
# the next line restarts using wish \
exec wish8.0 "$0" "$@"
    La barre oblique inverse est ignorée par le shell, mais analysée par wish.
  • J’ai beaucoup manipulé Tcl en travaillant sur les benchmarks TPC de Citus.
    https://github.com/TPC-Council/HammerDB/blob/master/src/post...
    Tcl est plutôt correct comme langage de script shell.

• Le fait que le moteur central de gestion des événements de Tcl soit construit au-dessus de epoll ou kqueue quand ils sont disponibles, avec une implémentation basée sur select qui subsiste pour les autres plateformes, est un changement énorme.
  L’une des grandes raisons pour lesquelles la concurrence de Tcl était considérée comme vieillotte et peu performante, c’est qu’elle dépendait de select alors que epoll et kqueue étaient disponibles depuis au moins dix ans. Tcl est l’un de mes langages préférés, parce qu’il est facile à prendre en main et que la métaprogrammation y est aussi simple.

  • La principale raison pour laquelle Tcl est considéré comme peu performant, c’est que ses opérations de base sont environ deux fois plus lentes que celles de CPython. CPython n’est déjà pas particulièrement rapide : https://news.ycombinator.com/item?id=41637953
    Une autre raison est que nous ne savons pas très bien comment écrire du Tcl rapide, et dans ce fil, je l’ai montré sans le vouloir.

• Je voudrais recommander NaviServer [0]. Son ancien nom était AOLServer [1], et c’est un serveur web blindé, éprouvé depuis longtemps en production.
  S’il a servi à faire tourner AOL à l’époque, cela se passe de commentaires. OpenACS [2] en est un projet majeur, existe depuis 1997 et se révèle particulièrement puissant avec Tcl. Il est encore maintenu et prend désormais aussi en charge Tcl 9.
  La combinaison JavaScript, Tcl et NaviServer, avec en plus ses propres modules comme DNS Server, LDAP ou Mail, devient un outil puissant. Si vous voulez vous initier à Tcl et au développement web, je recommande d’essayer les deux ensemble : il est facile d’obtenir des résultats intéressants.
  [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/

  • C’est la stack nostalgique avec laquelle j’ai appris Tcl et SQL au milieu des années 1990. À l’époque, je bricolais avec ArsDigita Community System lui-même, pas OpenACS, et ArsDigita existait encore réellement.
    Je me souviens aussi avoir suivi des cours gratuits sponsorisés et donnés directement par ArsDigita dans leurs bureaux, à Pasadena, CA, ou peut-être à Glendale. Ce n’était ni très approfondi ni très long, mais c’était bien pour débuter.

• Pour les personnes qui découvrent Tcl, il a aussi existé un univers parallèle où Tcl serait devenu le langage du navigateur à la place de JavaScript
  « Note intéressante : la création de Netscape a coïncidé avec le moment où j’ai quitté Berkeley, en 1994, pour décider où aller dans l’industrie. Jim Clarke et Marc Andreessen ont envisagé la possibilité que je rejoigne Netscape comme cofondateur, mais j’ai finalement refusé. Au moment où je leur ai parlé, je n’avais même pas encore décidé de travailler sur le Web. C’est l’un des plus grands “et si” de ma carrière. Si j’étais allé chez Netscape, il est assez probable que Tcl serait devenu le langage du navigateur à la place de JavaScript, et le monde aurait été différent ! Cela dit, avec le recul, je ne suis pas certain que Tcl aurait réellement été un meilleur langage que JavaScript pour le Web ; peut-être que les choses se sont donc passées comme il fallait. »
  Source : https://pldb.io/blog/JohnOusterhout.html

  • C’est possible. À mon avis, l’une des principales raisons pour lesquelles JavaScript s’est imposé est qu’il n’avait pas de gros héritage historique, ce qui a permis à ses concepteurs de l’emmener dans la direction dont ils avaient besoin
    Dès qu’un langage est utilisé par plus que quelques personnes, aussi bon soit-il, il accumule forcément un certain bagage. Dans cet univers parallèle, l’écosystème des langages de script pour navigateur aurait donc pu être bien plus fragmenté
  • Le travail sur un sous-ensemble sûr de Tcl pour le Web pourrait encore aujourd’hui servir à exécuter des scripts non fiables dans un sandbox facile à gérer
    Si on le souhaite, on peut retirer suffisamment de commandes pour que le langage ne soit plus Turing-complet
  • Fait amusant, un plugin navigateur Tcl existait au moins depuis 1996
    https://sunsite.icm.edu.pl/pub/programming/tcl/plugin/
    Je me souviens aussi que, même avant cela, des camarades étudiants étaient venus en salle informatique en disant : « Regarde, il y a maintenant aussi un plugin TK pour Mosaic ! » Ce n’était pas tout à fait l’époque où l’on disait « on dirait gopher avec une souris ! », mais ce n’était pas beaucoup plus tard non plus
    En revanche, pour utiliser le plugin Tcl, il fallait faire quelque chose soi-même, tandis que JavaScript, une fois arrivé, était fourni par défaut
  • Même si cela s’était produit, je ne pense pas que le monde serait resté sur TCL. JavaScript était suffisamment bon pour que les gens l’acceptent, mais TCL ne l’était clairement pas
    Il est plus probable que TCL aurait coexisté avec autre chose, puis aurait fini par être déprécié
  • Je suis entièrement d’accord avec l’idée que « peut-être que les choses se sont donc passées comme il fallait »
    Je n’aurais pas voulu voir partout du code du genre set x [ expr $y + $z ]. Comme langage de commande, ce n’est pas si mauvais, cela dit

• Ce n’est pas exagéré de dire que j’aime vraiment Tcl. Je ne l’ai utilisé que brièvement à la fin des années 1990 pour écrire des scripts IRC XiRCON, mais c’était un langage élégant, simple, facile à apprendre et flexible, au point que je l’appellerais un Lisp pour humains
  J’aurais aimé qu’il soit plus populaire, et je suis content de voir qu’il est encore bien vivant

  • Mon seul contact avec Tcl a été l’écriture de scripts pour bots IRC, mais je n’en garde que de bons souvenirs
  • Dans les années 90, j’écrivais des scripts TCL pour des clients IRC, et j’aimais vraiment ça. Pour cet usage, le langage était excellent
    Cela dit, mon autre langage principal à l’époque était l’assembleur x86, donc mon seuil d’émerveillement était peut-être bas
  • Pour parler de « Lisp pour humains », il y a quand même upvar

• L’auteur de Tcl et Tk est le professeur John Ousterhout, et son livre sur la conception logicielle en est à sa 2e édition
  A Philosophy of Software Design :
  https://web.stanford.edu/~ouster/cgi-bin/book.php

  • Ce livre est vraiment excellent, et je suis en train de le lire. Je lis un chapitre à la fois, j’y réfléchis aussi profondément que possible, puis j’applique les leçons en réécrivant mon projet actuel
    J’en suis maintenant au chapitre 11, « Design it Twice », donc je vais probablement tout réécrire de fond en comble après l’avoir terminé. Pour l’instant, mon modèle ne garde que les variables dans un noyau Python minimal et met le reste dans OpenSCAD ; dans la nouvelle implémentation, je prévois de mettre tout ce qui est possible dans Python et de l’utiliser via OpenPythonSCAD https://pythonscad.org/

• J’aime vraiment le langage, mais je ne l’utilise plus beaucoup aujourd’hui. Je me demande si, même sous Linux, il produit encore des GUI façon 1995
  Si Linux avait simplement eu un support GUI à peu près raisonnable, du niveau disponible depuis longtemps sur d’autres plateformes, je l’utiliserais probablement encore

  • Le moteur de thèmes est arrivé il y a déjà environ 15 ans. Le thème par défaut paraît assez daté, mais il en existe beaucoup d’autres : https://wiki.tcl-lang.org/page/List+of+ttk+Themes
    Cela dit, les captures d’écran des thèmes principaux correspondent à 8.5/8.6, et le thème par défaut en particulier a un peu changé dans Tk 9. Le piège, c’est que le moteur de thèmes utilise ses propres nouveaux widgets ; pour qu’une application bénéficie du thème, elle doit donc utiliser la nouvelle API. Du code de 1995 ou de 2005 donnera toujours une GUI façon 1995
  • Je me souviens avoir utilisé Tkinter quand j’apprenais Python. Il existe d’autres GUI, mais il est plus pénible de trouver des exemples qui fonctionnent comme des GUI modernes
    La documentation est restée centrée sur Tk(inter) pendant si longtemps que la plupart des gens semblent le choisir comme option par défaut. Le support GUI de Python s’est amélioré, mais cela tient probablement aussi à sa popularité dans le machine learning et l’IA. Tcl étant moins populaire, il faut vérifier plus soigneusement pour trouver de la documentation sur l’usage de GUI modernes

• Récemment, je n’ai touché à Tcl que pour travailler sur un portfile MacPorts
  Si quelqu’un l’utilise aujourd’hui pour autre chose, je suis curieux de savoir pourquoi. Je ne déteste pas le langage, mais je n’ai jamais fini par l’aimer non plus

  • Je pense que Tcl est assez proche d’un Lisp pour programmeurs C. Il apporte les capacités de métaprogrammation qu’on trouve dans Lisp, dans un langage qui ressemble à du C, s’intègre bien avec C, est bien plus intuitif qu’un langage de shell classique, et dispose même d’une GUI multiplateforme
    Un programmeur Tcl expérimenté peut faire de la magie. De 2005 à 2015, j’ai programmé presque exclusivement en Tcl/Tk et j’adorais ça. Depuis, je l’utilise surtout pour des scripts légers plutôt que pour écrire des apps, mais cela reste mon premier choix quand je dois écrire des scripts d’automatisation au niveau du système d’exploitation
  • Les usages standards sont les BigIP iRules[0] des équipements réseau F5 et A10, l’orchestration des supercalculateurs d’Argonne National Labs[1], Tealeaf[2], Python Tkinter[3], etc.
    Si je l’utilise tous les jours, c’est parce qu’il offre un bon équilibre entre son côté Lisp et sa simplicité de langage de script, et parce que son interface C est excellente. Le REPL est correct, et on peut écrire des extensions en C qui s’empilent comme du Tcl 100 % de première classe. Cela tient en grande partie, voire entièrement, au fait que Tcl est un langage très simple[4] et qu’il possède l’homoiconicité[5]. C’est agréable à développer et à utiliser
    [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 est le langage de script de l’industrie EDA. Si vous concevez des puces informatiques, vous utilisez TCL. Cadence et Synopsys ont fait de TCL leur standard depuis plus de 30 ans
    Son avantage est de permettre de piloter les outils EDA comme des commandes de script shell du type run_my_task -option_a -option_B. Si vous ne concevez pas de puces, vous n’avez aucune raison de l’utiliser, et le langage lui-même est affreux. Plus vite l’industrie EDA abandonnera TCL, mieux ce sera
  • Richard Hipp, le créateur de SQLite, dit que SQLite a été écrit en Tcl. Le moteur de base de données lui-même est évidemment écrit en C, mais la suite de tests, bien plus volumineuse, est majoritairement écrite en Tcl
    Et c’est cette suite de tests qui fait de SQLite le moteur fiable qu’il est aujourd’hui. La suite de tests a continué à être maintenue, tandis que le moteur a été réécrit en totalité ou en partie au fil du temps
  • J’ai utilisé Tcl plusieurs fois à cause de Freewrap. Avec très peu de code, on pouvait créer une application Windows avec GUI et la distribuer facilement sous forme d’exécutable
    J’ai créé une application de sauvegarde pour une application de vente en ligne, une application qui corrigeait les fichiers POS bogués d’une grande chaîne de distribution, une petite application qui copiait Forms/Reports sur un serveur, lançait la compilation puis poussait les nouveaux fichiers dans git, ainsi qu’un wrapper gs permettant au service médias de fusionner facilement plusieurs PDF en un seul. À chaque fois, le code faisait à peine une ou deux pages

• Plus important que Python 3.13
  Bravo !!!!
  J’attends que Scilab et Python soient distribués avec Tcl/Tk 9.0. La dernière version de Next Scripting semble prête pour la 9.0. Les sections Undroidwish et Binary Releases de la page officielle valent le coup d’œil