Lançamento do Tcl 9.0

• Tcl/Tk 9.0 é a mais recente versão principal do Tcl e do Tk, trazendo novos recursos junto com algumas incompatibilidades em relação ao Tcl/Tk 8
• A versão mais recente é indicada como Tcl/Tk 9.0.4, com data de 26 de junho de 2026
• O Tcl oferece capacidade de 64 bits para lidar com valores de dados acima de 2 GB; strings podem ter comprimento arbitrário dentro da memória disponível, e listas e dicionários podem ter um número muito grande de elementos
• O processamento de texto oferece toda a faixa de code points Unicode, novas codificações como as famílias utf-16, utf-32 e ucs-2, além de CESU-8, profiles de encoding para controlar codificações de I/O, e -encoding utf-8 como padrão de source
• O Tcl permite montar arquivos zip como um sistema de arquivos com zipfs, e oferece suporte à distribuição de aplicações no estilo starkit por meio de arquivos de sistema de arquivos anexados a executáveis ou bibliotecas
• O mecanismo de processamento de eventos no Unix é configurado com base em epoll ou kqueue quando disponível, enquanto uma implementação baseada em select permanece para plataformas sem essas chamadas de sistema
• Entre as principais incompatibilidades do Tcl 9.0 estão: nomes de variáveis não qualificados passam a ser interpretados no namespace atual, não no global; a resposta padrão a malencoding de I/O muda para erro (-profile strict); ~ em caminhos deixa de ser interpretado como o diretório home; e $::tcl_precision não é mais usado para controlar a geração de strings de valores double
• Nas mudanças de build e plataforma, a opção de build --disable-threads foi removida, portanto o suporte a threads está sempre habilitado, e no Windows é necessário Windows 7 ou Windows Server 2008 R2 ou superior
• Extensões Tcl em C cujos binários foram compilados para Tcl 8.6 ou anterior não funcionam no Tcl 9.0; compatibilidade de ABI no Tcl 9.0 não foi um objetivo, e na maioria dos casos é possível recompilar para Tcl 9.0 se não forem usadas funções de API removidas
• Na interface pública em C, muitos argumentos foram expandidos de int para Tcl_Size; o suporte a versões de Tcl_ChannelTypeVersion abaixo de 5 foi encerrado; foi introduzido versionamento da estrutura Tcl_ObjType; e macros CONST* e várias funções de API foram removidas
• O Tk 9.0.0 não oferece suporte ao Tcl 8.6, e para usar o Tk 9.0.0 é necessário antes ter o Tcl 9.0.0
• O Tk oferece tk sysnotify, tk print e tk systray para acesso a notificações, saída e recursos de bandeja do sistema operacional
• Imagens no Tk oferecem suporte parcial a SVG, leitura e escrita de metadata de photo image, e acesso ao alpha channel
• Os widgets e temas integrados do Tk passaram a ser scaling-aware; o suporte a gestos com dois dedos foi aprimorado nos ambientes em que está disponível; e “aqua” em tk windowingsystem requer macOS 10.10 ou superior
• Como materiais de migração para Tcl 9, estão disponíveis Migrating C extensions to Tcl 9 e Migrating scripts to Tcl 9

[GN⁺]

Comentários do Hacker News

• É o primeiro grande lançamento em 27 anos. A estrutura interna agora é de 64 bits, então os dados podem ficar bem maiores, e há muitos recursos novos, como Unicode completo incluindo emojis modernos, sistema de arquivos Zip etc.
  Parte da sujeira antiga também foi removida, então alguns programas podem precisar de atualização, mas a compatibilidade ainda é relativamente alta. A página acima também leva às notas de lançamento, que detalham o que foi incluído e excluído

  • A mudança no sistema de arquivos Zip é realmente muito bem-vinda. Antes, para criar aplicações executáveis independentes, a comunidade usava várias técnicas com ferramentas e conhecimento específicos; agora isso foi incorporado ao conjunto padrão de ferramentas de forma oficial, o que é uma ótima mudança
  • Fico me perguntando por que removeram o til ~, que era uma abreviação prática para ir ao diretório Home

• Puristas da linguagem e puristas da orientação a objetos ao estilo dos anos 1990 realmente odeiam Tcl, mas existe uma filosofia de projeto especial no ecossistema
  Tudo é string ou comando, e as extensões orientadas a objetos parecem um pouco enxertadas, mas se você tentar fazer GUI em Tcl/Tk puro em vez de usar Tcl por meio do Python, como no tkinter, ou usar a interface do SQLite, ou escrever uma pequena extensão em C, ou empacotar uma biblioteca, muita coisa simplesmente funciona bem

  • Vi uma perspectiva interessante no texto sobre Tcl escrito pelo antirez [1]. Se me lembro bem, o Redis usa Tcl nos scripts de teste
    Cheguei a isso seguindo links na documentação de https://folk.computer, e esse projeto também usa Tcl como linguagem de script. Para esse tipo de uso, talvez não haja muito motivo para desgostar de Tcl
    [1] http://antirez.com/articoli/tclmisunderstood.html
  • O Tcl tornou possível a nossa startup, e a experiência e os aprendizados daquela época se tornaram o ponto de partida da OutSystems
    Uma das lições foi que eu nunca mais gostaria de usar uma linguagem dinâmica sem compilador JIT em um servidor web completo. A linguagem em si é excelente, mas ter de reescrever regularmente bibliotecas Tcl em C por causa de problemas de desempenho não era nada agradável
  • A frase “tudo é string ou comando” não é exagero. Realmente tudo é comando, a ponto de a forma de escrever comentários aqui ser daquele tipo “mas por que isso é assim?”: https://wiki.tcl-lang.org/page/comment
    Antes de escrever um comentário, é preciso encerrar o comando com ;, as chaves precisam estar balanceadas, então não dá para comentar código incorreto, e também não dá para colocar barra invertida dentro do comentário. Ainda assim, isso é explicado como uma funcionalidade, porque ao executar wish usa-se algo assim
    #!/bin/sh
# the next line restarts using wish \
exec wish8.0 "$0" "$@"
    A barra invertida é ignorada no shell, mas é analisada pelo wish
  • Trabalhei bastante com Tcl ao fazer benchmarking TPC na Citus
    https://github.com/TPC-Council/HammerDB/blob/master/src/post...
    O Tcl é razoável como linguagem de script de shell

• O fato de o mecanismo central de tratamento de eventos do Tcl, quando disponível, agora ser construído sobre epoll ou kqueue, e de uma implementação baseada em select ficar apenas para plataformas onde isso não existe, é uma mudança enorme
  Um dos grandes motivos de a concorrência do Tcl ser considerada antiquada e de baixo desempenho era justamente a dependência de select, mesmo com epoll e kqueue disponíveis há pelo menos 10 anos. Gosto de Tcl porque é uma linguagem fácil de começar a usar e também facilita metaprogramação

  • O principal motivo de o Tcl ser visto como lento é que as operações básicas são aproximadamente duas vezes mais lentas que no CPython. E o CPython também não é exatamente rápido: https://news.ycombinator.com/item?id=41637953
    Outro motivo é que não sabemos muito bem como escrever Tcl rápido, e naquele tópico eu acabei mostrando isso sem querer

• Gostaria de recomendar o NaviServer [0]. Antigamente ele se chamava AOLServer [1] e é um servidor web à prova de balas, testado por muito tempo em produção
  Se foi usado para rodar a AOL no passado, nem preciso dizer mais nada. O OpenACS [2] é o projeto principal, existe desde 1997 e é especialmente poderoso junto com Tcl. Ainda recebe manutenção e agora também oferece suporte ao Tcl 9
  Com a combinação de JavaScript, Tcl e NaviServer, mais módulos próprios como DNS Server, LDAP e Mail, isso vira uma ferramenta poderosa. Se você quiser começar com Tcl e desenvolvimento web, recomendo usar os dois juntos, porque é fácil criar algo interessante e divertido
  [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/

  • É uma stack nostálgica para quem aprendeu Tcl e SQL em meados dos anos 1990. Na época, eu não brincava com o OpenACS, mas com o próprio ArsDigita Community System, quando a ArsDigita ainda existia de fato
    Também me lembro de ter feito aulas gratuitas patrocinadas e ministradas pela própria ArsDigita no escritório deles, não lembro se em Pasadena, CA, ou Glendale. Não eram profundas nem longas, mas eram boas para iniciantes

• Para quem está conhecendo Tcl agora, existiu até um universo alternativo em que Tcl virou a linguagem do navegador em vez de JavaScript
  “Nota de rodapé interessante: a fundação da Netscape coincidiu com o período em que eu estava deixando Berkeley em 1994 e decidindo para onde ir na indústria. Jim Clarke e Marc Andreessen sondaram a possibilidade de eu entrar como fundador da Netscape, mas no fim recusei. Quando conversei com eles, eu ainda nem tinha decidido trabalhar com a web. Esse é um dos maiores ‘e se’ da minha carreira. Se eu tivesse ido para a Netscape, há uma boa chance de que Tcl tivesse virado a linguagem do navegador no lugar de JavaScript, e o mundo teria sido diferente! Olhando para trás, porém, não tenho certeza se Tcl realmente teria sido uma linguagem melhor para a web do que JavaScript, então talvez o que aconteceu tenha sido o certo.”
  Fonte: https://pldb.io/blog/JohnOusterhout.html

  • Pode ser. Acho que um dos principais motivos de JavaScript ter se firmado foi o fato de não carregar uma grande bagagem histórica, o que permitiu aos projetistas levá-la na direção necessária
    Qualquer linguagem usada por mais de algumas pessoas acaba acumulando algum tipo de bagagem, por melhor que seja. Então, naquele universo alternativo, o ecossistema de linguagens de script para navegador talvez tivesse ficado muito mais fragmentado
  • O trabalho com um subconjunto seguro de Tcl para a web ainda hoje pode ser útil para executar scripts não confiáveis em um sandbox fácil de gerenciar
    Se quiser, dá até para remover comandos o suficiente para tornar a linguagem não Turing-completa
  • Curiosamente, já existia um plugin de navegador para Tcl pelo menos desde 1996
    https://sunsite.icm.edu.pl/pub/programming/tcl/plugin/
    Também lembro de colegas indo ao laboratório de informática e dizendo: “Olha, agora até tem plugin de TK para o Mosaic!” Já não era mais exatamente a época do “parece um gopher com mouse!”, mas também não fazia tanto tempo assim
    Só que o plugin de Tcl exigia que você mesmo fizesse alguma coisa para usar, enquanto JavaScript, depois que entrou, passou a vir por padrão
  • Mesmo que isso tivesse acontecido, não parece que o mundo teria permanecido em TCL. JavaScript era bom o bastante para as pessoas tolerarem, mas TCL definitivamente não
    Provavelmente TCL coexistiria com outra coisa, e depois o TCL teria sido marcado para descontinuação
  • Concordo totalmente com a frase “talvez o que aconteceu tenha sido o certo”
    Eu não queria ver código como set x [ expr $y + $z ] espalhado por toda parte. Como linguagem de comandos, não é tão ruim assim

• Não é exagero dizer que eu realmente gosto de Tcl. Só usei um pouco no fim dos anos 1990 ao escrever scripts de IRC para o XiRCON, mas era uma linguagem elegante, simples, fácil de aprender e flexível, a ponto de eu chamá-la de Lisp para humanos
  Gostaria que tivesse sido mais popular, e fico feliz de ver que ainda está viva e ativa

  • Meu contato com Tcl foi só escrevendo scripts para bots de IRC, mas só tenho boas lembranças dessa experiência
  • Nos anos 90 eu escrevia scripts em TCL para clientes de IRC e achava excelente. Para esse uso, a linguagem era ótima
    Dito isso, minha outra linguagem principal na época era assembly x86, então talvez meu padrão para me impressionar fosse baixo
  • Para ser chamada de “Lisp para humanos”, ela tem upvar

• O autor de Tcl e Tk é o professor John Ousterhout, e o livro dele sobre projeto de software já chegou à 2ª edição
  A Philosophy of Software Design:
  https://web.stanford.edu/~ouster/cgi-bin/book.php

  • Esse livro é realmente excelente e estou lendo agora. Estou lendo um capítulo por vez, pensando o mais profundamente possível sobre ele, e depois aplicando os ensinamentos para reescrever meu projeto atual
    Estou agora no capítulo 11, “Design it Twice”, então provavelmente vou fazer uma reescrita completa de cima a baixo quando terminar. No momento, o modelo atual deixa só as variáveis no núcleo mínimo em Python e o resto no OpenSCAD, mas na nova implementação pretendo colocar o máximo possível em Python e usar OpenPythonSCAD https://pythonscad.org/

• Eu realmente gosto da linguagem, mas hoje em dia quase não uso. Fico me perguntando se no Linux ela ainda produz uma GUI com cara de 1995
  Se ao menos houvesse um suporte razoavelmente decente a GUI no Linux, no nível do que já era possível em outras plataformas há muito tempo, eu provavelmente ainda usaria

  • O mecanismo de temas já foi incluído há uns 15 anos. O tema padrão parece bem datado, mas há vários outros: https://wiki.tcl-lang.org/page/List+of+ttk+Themes
    Só que as capturas de tela dos temas principais são da 8.5/8.6 e, especialmente no tema padrão, houve algumas mudanças no Tk 9. A pegadinha é que o mecanismo de temas usa seus próprios widgets novos, então, para o aplicativo receber o tema, ele precisa usar a API nova. Se o código for de 1995 ou 2005, a GUI ainda vai parecer de 1995
  • Lembro de usar Tkinter quando estava aprendendo Python. Existem outras GUIs, mas é ainda mais trabalhoso encontrar exemplos funcionando com interfaces mais modernas
    A documentação ficou centrada demais em Tk(inter) por tempo demais, então parece ser a opção que a maioria acaba escolhendo por padrão. O suporte a GUI em Python melhorou, mas provavelmente a popularidade de uso em machine learning/IA influenciou isso. Como Tcl é menos popular, para encontrar documentação sobre como usar GUIs modernas é preciso procurar com mais cuidado

• A última vez que mexi com Tcl foi basicamente em trabalho com portfile do MacPorts
  Se alguém ainda usa hoje em dia para outra coisa, tenho curiosidade de saber por quê. Não odeio a linguagem, mas também nunca cheguei a gostar dela

  • Acho que Tcl é mais próximo de um Lisp para programadores C. Ele oferece as capacidades de metaprogramação que se obtém em Lisp, mas em uma linguagem que parece C, combina bem com C, é muito mais intuitiva do que uma linguagem de shell comum e ainda tem GUI multiplataforma
    Um programador experiente de Tcl consegue fazer mágica. De 2005 a 2015 programei quase exclusivamente em Tcl/Tk e gostava muito. Depois disso, passei a usá-lo mais para scripts leves do que para escrever aplicativos, mas, quando preciso criar scripts de automação em nível de sistema operacional, ele ainda é minha primeira escolha
  • Os usos mais padronizados são BigIP iRules[0] em equipamentos de rede da F5 e equipamentos da A10, orquestração nos supercomputadores do Argonne National Labs[1], Tealeaf[2], Python Tkinter[3] etc.
    O motivo de eu usar todos os dias é o bom equilíbrio entre o lado lispiano e a simplicidade de uma linguagem de script, além da excelente interface com C. O REPL também é bom, e dá para escrever extensões em C e empilhá-las como Tcl 100% de primeira classe. Isso se deve em grande parte, talvez inteiramente, ao fato de Tcl ser uma linguagem muito simples[4] e ter homoiconicidade[5]. É divertido desenvolver e usar
    [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 é a linguagem de script da indústria de EDA. Se você projeta chips de computador, então está usando TCL. Cadence e Synopsys adotam TCL como padrão há mais de 30 anos
    A vantagem é poder controlar ferramentas de EDA como se fossem comandos de shell script do tipo run_my_task -option_a -option_B. Se você não projeta chips, não há motivo para usá-la, e a linguagem em si é horrível. Quanto mais rápido a indústria de EDA abandonar TCL, melhor
  • O criador do SQLite, Richard Hipp, diz que o SQLite foi escrito em Tcl. O motor de banco de dados em si, claro, foi escrito em C, mas a suíte de testes, muito maior, foi escrita em sua maior parte em Tcl
    E é essa suíte de testes que faz do SQLite o motor confiável que ele é hoje. A suíte de testes continuou sendo mantida, enquanto o motor foi sendo reescrito por inteiro ou em partes
  • Usei Tcl algumas vezes por causa do Freewrap. Dava para criar um aplicativo Windows com GUI com pouquíssimo código e distribuí-lo facilmente como executável
    Fiz um app de backup para um aplicativo de vendas online, um app para corrigir arquivos POS com bugs de uma grande rede varejista, um pequeno app que copiava Forms/Reports para o servidor, executava a compilação e depois fazia push dos novos arquivos para o git, e um wrapper de gs para facilitar ao departamento de mídia juntar vários PDFs em um só. Todos tinham uma ou duas páginas de código

• Mais importante que Python 3.13
  Bravo !!!!
  Estou esperando Scilab e Python passarem a ser distribuídos com Tcl/Tk 9.0 incluído. O lançamento mais recente do Next Scripting parece estar pronto para 9.0. Vale a pena ficar de olho nas seções Undroidwish e Binary Releases da página oficial