1 คะแนน โดย GN⁺ 2024-09-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Tcl/Tk 9.0 เป็นเมเจอร์รีลีสล่าสุดของ Tcl และ Tk โดยมาพร้อมฟีเจอร์ใหม่และความไม่เข้ากันบางส่วนเมื่อเทียบกับ Tcl/Tk 8
  • การระบุเวอร์ชันรีลีสล่าสุดคือ Tcl/Tk 9.0.4 และวันที่คือ 26 มิถุนายน 2026
  • Tcl มอบ 64-bit capacity สำหรับจัดการค่าข้อมูลที่เกิน 2GB โดยสตริงสามารถมีความยาวได้ตามอำเภอใจภายในขอบเขตหน่วยความจำที่ใช้งานได้ และลิสต์กับดิกชันนารีสามารถมีองค์ประกอบได้จำนวนมากมาก
  • การประมวลผลข้อความรองรับช่วง code point ของ Unicode ทั้งหมด, การเข้ารหัสใหม่อย่าง utf-16·utf-32·ucs-2 และ CESU-8, encoding profiles สำหรับควบคุม I/O encoding, และค่าเริ่มต้น -encoding utf-8 ของ source
  • Tcl สามารถเมานต์ไฟล์ zip ให้เหมือนเป็นไฟล์ซิสเต็มได้ด้วย zipfs และรองรับการแจกจ่ายแอปพลิเคชันแบบ starkit ด้วยไฟล์ซิสเต็มอาร์ไคฟ์ที่แนบมากับไฟล์ executable หรือไลบรารี
  • เอนจินจัดการอีเวนต์บน Unix ถูกตั้งค่าให้ใช้ epoll หรือ kqueue เป็นพื้นฐานเมื่อใช้งานได้ และยังคงมีอิมพลีเมนเทชันแบบ select สำหรับแพลตฟอร์มที่ไม่มี system call เหล่านั้น
  • ความไม่เข้ากันหลักของ Tcl 9.0 ได้แก่ ชื่อตัวแปรที่ไม่ระบุขอบเขตจะถูกตีความใน namespace ปัจจุบันแทนที่จะเป็น global, การตอบสนองเริ่มต้นต่อ I/O malencoding เปลี่ยนเป็นข้อผิดพลาด (-profile strict), ~ ในพาธจะไม่ถูกตีความเป็นโฮมไดเรกทอรี, และ $::tcl_precision จะไม่ถูกใช้เพื่อควบคุมการสร้างสตริงของ double อีกต่อไป
  • การเปลี่ยนแปลงด้านการบิลด์และแพลตฟอร์มทำให้ตัวเลือกบิลด์ --disable-threads ถูกถอดออก จึงเปิดใช้ thread เสมอ และบน Windows ต้องใช้ Windows 7 หรือ Windows Server 2008 R2 ขึ้นไป
  • ส่วนขยาย Tcl C นั้น ไบนารีที่บิลด์สำหรับ Tcl 8.6 หรือต่ำกว่า จะไม่ทำงานบน Tcl 9.0 และความเข้ากันได้ระดับ ABI ของ Tcl 9.0 ไม่ใช่เป้าหมาย โดยในกรณีส่วนใหญ่สามารถรีบิลด์ให้รองรับ Tcl 9.0 ได้หากไม่ได้ใช้ฟังก์ชัน API ที่ถูกถอดออก
  • อินเทอร์เฟซสาธารณะของ C มีการขยายอาร์กิวเมนต์จำนวนมากจาก int เป็น Tcl_Size, ยุติการรองรับ Tcl_ChannelTypeVersion ที่ต่ำกว่า 5, เพิ่มการจัดการเวอร์ชันให้โครงสร้าง Tcl_ObjType, และถอด CONST* macro กับฟังก์ชัน API หลายรายการออก
  • Tk 9.0.0 ไม่รองรับ Tcl 8.6 และการใช้งาน Tk 9.0.0 จำเป็นต้องมี Tcl 9.0.0 ก่อน
  • Tk มี tk sysnotify, tk print, tk systray สำหรับเข้าถึงความสามารถด้านการแจ้งเตือนของระบบ การพิมพ์/เอาต์พุต และ system tray ของระบบปฏิบัติการ
  • ภาพของ Tk รองรับ SVG บางส่วน, การอ่านและเขียน metadata ของ photo image, และการเข้าถึง alpha channel
  • วิดเจ็ตและธีมในตัวของ Tk ถูกปรับให้รองรับการสเกลมากขึ้น, ปรับปรุงการรองรับท่าทางสองนิ้วในสภาพแวดล้อมที่รองรับ, และ “aqua” ของ tk windowingsystem ต้องใช้ macOS 10.10 ขึ้นไป
  • มีเอกสารการย้ายมา Tcl 9 ได้แก่ Migrating C extensions to Tcl 9 และ Migrating scripts to Tcl 9

1 ความคิดเห็น

 
GN⁺ 2024-09-27
ความคิดเห็นจาก Hacker News
  • เป็น เมเจอร์รีลีสแรกในรอบ 27 ปี โครงสร้างภายในเป็น 64 บิต ทำให้ข้อมูลมีขนาดใหญ่มากได้ และมีฟีเจอร์ใหม่มากมาย เช่น Unicode ครบชุดรวมถึงอีโมจิสมัยใหม่, ระบบไฟล์ Zip ฯลฯ
    มีการเอาเศษซากเก่า ๆ บางส่วนออกไปด้วย ทำให้บางโปรแกรมอาจต้องอัปเดต แต่โดยรวมยังถือว่าเข้ากันได้ดี หน้าข้างต้นมีลิงก์ไปยัง release notes ที่ระบุรายละเอียดฟีเจอร์ที่รวมเข้า/ตัดออกไว้

    • การเปลี่ยนแปลงเรื่อง ระบบไฟล์ Zip น่ายินดีจริง ๆ เมื่อก่อนตอนทำแอปพลิเคชันแบบสแตนด์อโลน ชุมชนเคยใช้เทคนิคหลายแบบด้วยเครื่องมือและ know-how เฉพาะทาง การนำสิ่งเหล่านั้นมาใส่ไว้ในชุดเครื่องมือพื้นฐานแบบมาตรฐานจึงเป็นการเปลี่ยนแปลงที่ยอดเยี่ยม
    • สงสัยว่าทำไมถึงเอา เครื่องหมายทิลด์ ~ ซึ่งเป็นรูปแบบย่อที่สะดวกสำหรับไปยังไดเรกทอรี Home ออกไป
  • พวกนักบริสุทธิ์นิยมด้านภาษาและนักบริสุทธิ์นิยม OOP แบบยุค 1990 ไม่ชอบ Tcl อย่างมาก แต่ในอีโคซิสเต็มมี ปรัชญาการออกแบบ ที่พิเศษอยู่
    ทุกอย่างเป็นสตริงหรือคำสั่ง และส่วนขยาย OOP ก็ดูเหมือนถูกแปะเพิ่มเข้ามาอยู่บ้าง แต่ถ้าลองสร้าง GUI ด้วย Tcl/Tk ล้วน ๆ แทนการใช้ Tcl ผ่าน Python อย่าง tkinter หรือลองใช้ SQLite interface หรือลองเขียนส่วนขยาย C เล็ก ๆ หรือ wrap ไลบรารีดู หลายอย่างก็ทำงานได้ดีไปเอง

    • เคยเห็นมุมมองที่น่าสนใจในบทความ Tcl ที่ antirez เขียน [1] ถ้าจำไม่ผิด Redis ใช้ Tcl ในสคริปต์ทดสอบ
      ผมตามลิงก์ไปจากเอกสารของ https://folk.computer ซึ่งโปรเจกต์นี้ก็ใช้ Tcl เป็นภาษาสคริปต์ด้วย สำหรับการใช้งานแบบนั้น อาจไม่มีเหตุผลอะไรเป็นพิเศษที่จะไม่ชอบ Tcl
      [1] http://antirez.com/articoli/tclmisunderstood.html
    • Tcl ทำให้สตาร์ทอัปของเราเกิดขึ้นได้ และประสบการณ์กับสิ่งที่เรียนรู้ตอนนั้นก็กลายเป็น จุดเริ่มต้นของ OutSystems
      หนึ่งในบทเรียนคือ ผมไม่อยากใช้ภาษาไดนามิกที่ไม่มี JIT compiler กับเว็บเซิร์ฟเวอร์เต็มรูปแบบอีกแล้ว ตัวภาษานั้นยอดเยี่ยม แต่การต้องเขียนไลบรารี Tcl ใหม่เป็น C เป็นระยะ ๆ เพราะปัญหาประสิทธิภาพนั้นไม่ค่อยน่าพิสมัย
    • คำว่า “ทุกอย่างเป็นสตริงหรือคำสั่ง” ไม่ได้พูดเกินจริง ทุกอย่างเป็นคำสั่งจริง ๆ จน วิธีเขียนคอมเมนต์ ตรงนี้ทำให้รู้สึกว่า “นี่มันอะไรกันเนี่ย”: https://wiki.tcl-lang.org/page/comment
      ต้องจบคำสั่งด้วย ; ก่อนเขียนคอมเมนต์ วงเล็บปีกกาต้องจับคู่กันครบ ดังนั้นห้ามพยายามคอมเมนต์โค้ดที่ผิด และใส่แบ็กสแลชในคอมเมนต์ก็ไม่ได้ อย่างไรก็ตามสิ่งนี้ก็ถูกอธิบายว่าเป็นฟีเจอร์ เพราะเวลาเรียกใช้ wish จะเขียนแบบด้านล่าง
      #!/bin/sh
      # the next line restarts using wish \
      exec wish8.0 "$0" "$@"
      แบ็กสแลชจะถูกเชลล์มองข้าม แต่ใน wish จะถูก parse
    • เคยทำงานกับ Tcl เยอะตอนทำ TPC benchmark ของ Citus
      https://github.com/TPC-Council/HammerDB/blob/master/src/post...
      Tcl ถือว่าใช้เป็นภาษา shell script ได้ค่อนข้างดี
  • การที่เอนจินประมวลผลอีเวนต์ส่วนกลางของ Tcl ถูกสร้างบน epoll หรือ kqueue เมื่อใช้งานได้ และยังคงมี implementation แบบ select สำหรับแพลตฟอร์มที่ไม่รองรับ ถือเป็น การเปลี่ยนแปลงครั้งใหญ่มาก
    เหตุผลสำคัญที่ concurrency ของ Tcl ถูกมองว่าล้าสมัยและประสิทธิภาพต่ำ คือมันพึ่งพา select ทั้งที่ epoll และ kqueue ใช้ได้มานานอย่างน้อย 10 ปีแล้ว Tcl เป็นหนึ่งในภาษาที่ผมชอบ เพราะเริ่มต้นง่ายและทำ metaprogramming ก็ง่าย

    • เหตุผลหลักที่ Tcl ถูกมองว่าประสิทธิภาพต่ำคือ operation พื้นฐาน ช้ากว่า CPython ประมาณสองเท่า และ CPython เองก็ไม่ได้ถือว่าเร็ว: https://news.ycombinator.com/item?id=41637953
      อีกเหตุผลคือเราไม่ค่อยรู้ว่าควรเขียน Tcl ให้เร็วอย่างไร และในเธรดนั้นผมก็แสดงให้เห็นโดยไม่ได้ตั้งใจ
  • อยากแนะนำ NaviServer [0] ชื่อเดิมคือ AOLServer [1] เป็นเว็บเซิร์ฟเวอร์ระดับถึกทนที่ผ่านการพิสูจน์ในงานจริงมายาวนาน
    ถ้าเป็นสิ่งที่เคยใช้รัน AOL มาก่อน ก็คงไม่ต้องอธิบายเพิ่มแล้ว OpenACS [2] เป็นโปรเจกต์หลักและมีมาตั้งแต่ปี 1997 โดยเฉพาะเมื่อใช้ร่วมกับ Tcl จะทรงพลังมาก ยังมีการดูแลรักษาอยู่ และตอนนี้รองรับ Tcl 9 แล้ว
    การผสม JavaScript, Tcl, NaviServer เข้ากับโมดูลของตัวเองอย่าง DNS Server, LDAP, Mail จะกลายเป็นเครื่องมือที่ทรงพลัง ถ้าอยากเริ่มต้นกับ Tcl และการพัฒนาเว็บ ขอแนะนำให้ลองใช้สองอย่างนี้ร่วมกัน เพราะสร้างผลงานสนุก ๆ ได้ง่าย
    [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/

    • เป็น สแต็กแห่งความทรงจำ ที่ผมใช้เรียน Tcl กับ SQL ช่วงกลางทศวรรษ 1990 ตอนนั้นไม่ได้เล่น OpenACS แต่เล่น ArsDigita Community System ตัวจริง และเป็นช่วงที่ ArsDigita ยังมีอยู่จริง
      ยังจำได้ว่าเคยไปเรียนคลาสฟรีที่ ArsDigita สนับสนุนและสอนเอง ที่สำนักงานซึ่งน่าจะอยู่ใน Pasadena, CA หรือไม่ก็ Glendale แม้จะไม่ได้ลึกหรือยาวมาก แต่ก็ดีสำหรับการเริ่มต้น
  • สำหรับคนที่เพิ่งรู้จัก Tcl ครั้งแรก ก็เคยมีจักรวาลคู่ขนานที่ Tcl กลายเป็นภาษาของเบราว์เซอร์ แทน JavaScript ด้วย
    “เกร็ดเชิงอรรถที่น่าสนใจ: การก่อตั้ง Netscape เกิดขึ้นในช่วงเดียวกับตอนที่ผมออกจาก Berkeley ในปี 1994 และกำลังตัดสินใจว่าจะไปทางไหนในอุตสาหกรรม Jim Clarke และ Marc Andreessen เคยหยั่งเชิงความเป็นไปได้ที่ผมจะเข้าร่วมเป็นผู้ก่อตั้ง Netscape แต่สุดท้ายผมปฏิเสธ ตอนที่คุยกับพวกเขา ผมยังไม่ได้ตัดสินใจด้วยซ้ำว่าจะทำงานเกี่ยวกับเว็บ นี่เป็นหนึ่งใน ‘ถ้าเกิดว่า’ ที่ใหญ่ที่สุดในอาชีพของผม หากผมไป Netscape ก็มีความเป็นไปได้ไม่น้อยที่ Tcl จะกลายเป็นภาษาของเบราว์เซอร์แทน JavaScript และโลกก็คงเปลี่ยนไป! แต่เมื่อมองย้อนกลับไป ผมก็ไม่มั่นใจว่า Tcl จะเป็นภาษาสำหรับเว็บที่ดีกว่า JavaScript จริงหรือไม่ ดังนั้นบางทีสิ่งที่เกิดขึ้นอาจเป็นเรื่องที่ถูกต้องแล้วก็ได้”
    ที่มา: https://pldb.io/blog/JohnOusterhout.html

    • ก็อาจเป็นไปได้ หนึ่งในเหตุผลหลักที่ JavaScript ตั้งหลักได้ ผมคิดว่าเป็นเพราะมันไม่มี ภาระทางประวัติศาสตร์ ก้อนใหญ่ ทำให้นักออกแบบพามันไปในทิศทางที่จำเป็นได้
      ภาษาใดก็ตามที่มีคนใช้มากกว่าสองสามคน ต่อให้ดีแค่ไหนก็ย่อมมีภาระบางอย่างเกิดขึ้น ดังนั้นในจักรวาลคู่ขนานนั้น ระบบนิเวศของภาษาสคริปต์บนเบราว์เซอร์อาจแตกเป็นเสี่ยงมากกว่านี้มากก็ได้
    • งานทำซับเซตที่ปลอดภัยของ Tcl สำหรับเว็บ ทุกวันนี้ก็ยังนำไปใช้รันสคริปต์ที่ไม่น่าเชื่อถือใน แซนด์บ็อกซ์ ที่จัดการง่ายได้
      ถ้าต้องการ ก็ลบคำสั่งออกให้มากพอจนทำให้ภาษาไม่เป็น Turing complete ได้ด้วย
    • ที่น่าสนุกคือปลั๊กอินเบราว์เซอร์ของ Tcl มีมาตั้งแต่อย่างน้อยปี 1996 แล้ว
      https://sunsite.icm.edu.pl/pub/programming/tcl/plugin/
      ยังจำได้ด้วยว่าก่อนหน้านั้น เพื่อนนักศึกษามาที่ห้องคอมพิวเตอร์แล้วบอกว่า “ดูสิ ตอนนี้มีปลั๊กอิน TK สำหรับ Mosaic แล้ว!” ยังไม่ถึงยุคที่พูดกันว่า “เหมือน gopher ที่มีเมาส์เลย!” แต่ก็ไม่ได้ห่างกันนานนัก
      เพียงแต่ถ้าจะใช้ปลั๊กอิน Tcl ต้องลงมือทำอะไรเองบางอย่าง ส่วน JavaScript พอเข้ามาแล้วก็ถูกให้มาเป็นค่าเริ่มต้น
    • ถึงจะเกิดเรื่องแบบนั้นขึ้น ผมก็ไม่คิดว่าโลกจะยังคงอยู่กับ TCL ต่อไป JavaScript ดีพอในระดับที่ผู้คนยอมทนได้ แต่ TCL ไม่ใช่อย่างนั้นแน่นอน
      เป็นไปได้มากกว่าว่าคงมี TCL อยู่ร่วมกับอะไรอีกอย่างหนึ่ง แล้วสุดท้าย TCL ถูกจัดให้อยู่ในสถานะเตรียมเลิกใช้
    • เห็นด้วยเต็มที่กับคำว่า “บางทีสิ่งที่เกิดขึ้นอาจเป็นเรื่องที่ถูกต้องแล้วก็ได้”
      ไม่อยากเห็นโค้ดอย่าง set x [ expr $y + $z ] กระจายอยู่ทุกที่ ถึงในฐานะภาษาคำสั่งมันจะไม่ได้แย่ขนาดนั้นก็ตาม
  • จะบอกว่าผมชอบ Tcl จริง ๆ ก็ไม่เกินจริง แม้จะเคยใช้แค่ช่วงสั้น ๆ ตอนเขียนสคริปต์ XiRCON IRC ช่วงปลายทศวรรษ 1990 แต่มันเป็นภาษาที่สง่างาม เรียบง่าย เรียนรู้ง่าย และยืดหยุ่น จนเรียกได้ว่าเป็น Lisp สำหรับมนุษย์
    อยากให้มันได้รับความนิยมกว่านี้ และดีใจที่เห็นว่ามันยังมีชีวิตชีวาอยู่

    • ผมได้สัมผัส Tcl แค่ตอนเขียนสคริปต์บอต IRC เท่านั้น แต่ประสบการณ์นั้นมีแต่ความทรงจำดี ๆ
    • เคยเขียนสคริปต์ TCL สำหรับไคลเอนต์ IRC ในยุค 90 และชอบมาก ภาษานี้ยอดเยี่ยมสำหรับงานแบบนั้น
      แต่ตอนนั้นภาษา main ที่ใช้เป็น x86 assembly ดังนั้นมาตรฐานความประทับใจของผมอาจต่ำก็ได้
    • จะเรียกว่า “Lisp สำหรับมนุษย์” ก็คงยาก เพราะมี upvar อยู่
  • ผู้เขียน Tcl และ Tk คือศาสตราจารย์ John Ousterhout และหนังสือด้านการออกแบบซอฟต์แวร์ของเขาออกมาถึงฉบับพิมพ์ครั้งที่ 2 แล้ว
    A Philosophy of Software Design:
    https://web.stanford.edu/~ouster/cgi-bin/book.php

    • หนังสือเล่มนี้เป็น หนังสือที่ยอดเยี่ยมจริง ๆ และตอนนี้กำลังอ่านอยู่ อ่านทีละบท คิดให้ลึกที่สุดเท่าที่ทำได้ แล้วนำบทเรียนไปใช้เขียนโปรเจกต์ปัจจุบันใหม่
      ตอนนี้มาถึงบทที่ 11 “Design it Twice” แล้ว ดังนั้นหลังอ่านจบคงได้เขียนใหม่ทั้งระบบจากบนลงล่าง ตอนนี้เป็นโมเดลที่เก็บเฉพาะตัวแปรไว้ในแกน Python ขั้นต่ำ ส่วนที่เหลืออยู่ใน OpenSCAD แต่ในการทำใหม่ ตั้งใจจะย้ายทุกอย่างที่ทำได้มาไว้ใน Python และใช้งานผ่าน OpenPythonSCAD https://pythonscad.org/
  • ชอบภาษานี้มากจริง ๆ แต่ช่วงนี้ไม่ได้ใช้มากนัก สงสัยว่าแม้บน Linux มันยังสร้าง GUI แบบปี 1995 ออกมาอยู่หรือเปล่า
    ถ้ามีการรองรับ GUI บน Linux ที่พอสมเหตุสมผลในระดับที่แพลตฟอร์มอื่นทำได้มานานแล้ว ก็คงยังใช้อยู่ถึงตอนนี้

    • เอนจินธีมถูกใส่เข้ามาเมื่อราว 15 ปีก่อนแล้ว ธีมเริ่มต้นดูค่อนข้างเก่า แต่ก็มีธีมอื่นมากมาย: https://wiki.tcl-lang.org/page/List+of+ttk+Themes
      อย่างไรก็ตาม ภาพหน้าจอของธีมหลักอิงกับ 8.5/8.6 และโดยเฉพาะธีมเริ่มต้นใน Tk 9 ก็เปลี่ยนไปเล็กน้อย จุดที่เป็นกับดักคือเอนจินธีมใช้วิดเจ็ตชุดใหม่ของตัวเอง ดังนั้นถ้าอยากให้แอปพลิเคชันได้ธีม ก็ต้องใช้ API ใหม่ ถ้าเป็นโค้ดปี 1995 หรือ 2005 ก็ยังได้ GUI แบบปี 1995 อยู่ดี
    • ยังจำตอนเรียน Python แล้วใช้ Tkinter ได้ มี GUI อื่น ๆ ด้วย แต่การหาตัวอย่างที่ทำงานเป็น GUI สมัยใหม่ยุ่งยากกว่า
      เอกสารผูกอยู่กับ Tk(inter) มานานเกินไป จนคนส่วนใหญ่น่าจะเลือกมันเหมือนเป็นค่าเริ่มต้น Python รองรับ GUI ดีขึ้นแล้ว แต่ก็คงได้รับอิทธิพลจากความนิยมในการใช้งานด้านแมชชีนเลิร์นนิง/AI ส่วน Tcl ได้รับความนิยมน้อยกว่า ดังนั้นถ้าจะหาเอกสารวิธีใช้ GUI สมัยใหม่ ก็ต้องตรวจสอบให้ละเอียดกว่านี้
  • ช่วงหลังที่ได้แตะ Tcl ก็มีแค่งานทำ MacPorts portfile เท่านั้น
    ถ้ายังมีคนใช้มันเพื่ออย่างอื่นในยุคนี้ ก็อยากรู้ว่าใช้เพราะอะไร ผมไม่ได้เกลียดภาษานี้ แต่ก็ไม่ได้ถึงกับชอบมัน

    • ผมคิดว่า Tcl ใกล้เคียงกับ Lisp สำหรับโปรแกรมเมอร์ C มันให้ความสามารถด้าน metaprogramming แบบที่ได้จาก Lisp ในภาษาที่หน้าตาเหมือน C, เข้ากับ C ได้ดี, ตรงไปตรงมากว่าภาษาเชลล์ทั่วไปมาก และยังมี GUI ข้ามแพลตฟอร์มด้วย
      โปรแกรมเมอร์ Tcl ที่ชำนาญสามารถทำอะไรได้ราวกับใช้เวทมนตร์ ผมเขียนโปรแกรมแทบทั้งหมดด้วย Tcl/Tk ตั้งแต่ปี 2005 ถึง 2015 และชอบมันมาก หลังจากนั้นก็ใช้เป็นหลักกับสคริปต์เบา ๆ มากกว่าการเขียนแอป แต่เมื่อไหร่ที่ต้องเขียนสคริปต์อัตโนมัติระดับระบบปฏิบัติการ มันยังเป็นตัวเลือกอันดับหนึ่งของผมอยู่
    • การใช้งานมาตรฐาน ๆ ก็เช่น BigIP iRules[0] ของอุปกรณ์เครือข่าย F5 และอุปกรณ์ A10, การ orchestration ของซูเปอร์คอมพิวเตอร์ที่ Argonne National Labs[1], Tealeaf[2], Python Tkinter[3] เป็นต้น
      เหตุผลที่ใช้ทุกวันคือมันสมดุลดีระหว่างความเป็น Lisp กับความเป็นภาษาสคริปต์เรียบง่าย และมีอินเทอร์เฟซกับ C ที่ยอดเยี่ยม REPL ก็ใช้ได้ดี และสามารถเขียน extension ด้วย C แล้วต่อยอดให้เป็น Tcl ชั้นหนึ่ง 100% ได้ สาเหตุส่วนใหญ่ หรืออาจทั้งหมด เป็นเพราะ Tcl เป็นภาษาที่เรียบง่ายมาก[4] และมีความเป็น homoiconicity[5] มันสนุกทั้งตอนพัฒนาและตอนใช้งาน
      [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 คือ ภาษาสคริปต์ของวงการ EDA ถ้าคุณออกแบบชิปคอมพิวเตอร์ คุณก็กำลังใช้ TCL อยู่ Cadence และ Synopsys ใช้ TCL เป็นมาตรฐานมากว่า 30 ปีแล้ว
      ข้อดีคือสามารถควบคุมเครื่องมือ EDA ได้เหมือนคำสั่งเชลล์สคริปต์ เช่น run_my_task -option_a -option_B ถ้าไม่ได้ออกแบบชิปก็ไม่มีเหตุผลให้ใช้ และตัวภาษาเองก็แย่มาก ยิ่งวงการ EDA เลิกใช้ TCL ได้เร็วเท่าไรก็ยิ่งดี
    • Richard Hipp ผู้สร้าง SQLite เคยบอกว่า SQLite เขียนด้วย Tcl แน่นอนว่าเอนจินฐานข้อมูลเองเขียนด้วย C แต่ ชุดทดสอบ ที่ใหญ่กว่ามากนั้นส่วนใหญ่เขียนด้วย Tcl
      และชุดทดสอบนั้นเองที่ทำให้ SQLite เป็นเอนจินที่เชื่อถือได้อย่างทุกวันนี้ ชุดทดสอบถูกดูแลต่อเนื่อง ส่วนเอนจินก็ถูกเขียนใหม่ทั้งทั้งหมดหรือบางส่วนมาเรื่อย ๆ
    • เคยใช้ Tcl อยู่หลายครั้งเพราะ Freewrap สามารถสร้างแอป Windows ที่มี GUI ด้วยโค้ดน้อยมาก และแจกจ่ายเป็นไฟล์ executable ได้ง่าย
      ผมทำแอปสำรองข้อมูลสำหรับแอปขายออนไลน์, แอปแก้ไฟล์ POS ที่มีบั๊กของเชนค้าปลีกรายใหญ่, แอปเล็ก ๆ ที่คัดลอก Forms/Reports ไปยังเซิร์ฟเวอร์ รันการคอมไพล์ แล้ว push ไฟล์ใหม่เข้า git, และ wrapper ของ gs เพื่อให้ฝ่ายมีเดียรวม PDF หลายไฟล์เป็นไฟล์เดียวได้ง่ายขึ้น ทั้งหมดมีโค้ดแค่ประมาณหนึ่งถึงสองหน้าเท่านั้น
  • สำคัญกว่า Python 3.13 อีก
    Bravo !!!!
    กำลังรอให้ Scilab และ Python แจกจ่ายพร้อม Tcl/Tk 9.0 ดูเหมือนว่ารีลีสล่าสุดของ Next Scripting จะพร้อมสำหรับ 9.0 แล้ว น่าจับตาดูส่วน Undroidwish และ Binary Releases บนหน้าอย่างเป็นทางการ