6 ms·
Tcl/Tk is one of the cooler tools out there, though I wish it were not so... string-based. Much like Clojure took a bunch of neat stuff from recent programnmin
by rtpg 7y ago
Tcl/Tk is one of the cooler tools out there, though I wish it were not so... string-based.
Much like Clojure took a bunch of neat stuff from recent programnming languages (first class hash maps! immutable data structures!), I'd love to see a Tcl variant that takes some inspiration from recent trends.
- msla 7y agoIdeas about where Tcl went wrong: https://utcc.utoronto.ca/~cks/space/blog/programming/WhereTCLWentWrong https://utcc.utoronto.ca/~cks/space/blog/programming/WhereTC... https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went... ... and discussion of the page immediately above: https://news.ycombinator.com/item?id=3579088 https://news.ycombinator.com/item?id=3579088 Tcl does have a strange syntax. It tries to be "Lisp but with strings" and strings aren't even as easy to work with as what Lisp gives you, which are singly-linked lists of tokens and other singly-linked lists. And doing Lisp with other representations isn't that new: XSL is "Lisp but with XML", for example.
- goatinaboat 7y agoTcl does have a strange syntax. It seems strange until you internalise the 12 rules, then it flows very naturally. There are none of the weird quirks you get in Ruby or Perl. https://www.tcl.tk/man/tcl/TclCmd/Tcl.htm https://www.tcl.tk/man/tcl/TclCmd/Tcl.htm
- blacksqr 7y agoIt's funny, I hear people talk and talk and talk about simplicity in programming, and see post after post about it on HN, and everybody seems to think it's a great idea, until it's staring them in the face.
- _ph_ 7y agoI think the second link is a great read and I agree with most points. If Tk had been moved to GTK or QT (probably GTK due to licensing) early on, it could have maintained its role for making portable GUIs a bit clearer. Though, in my eyes, Tcl/Tk still is the easiest tool to use portable UIs. Especially with Tclkits, you can make single-file executables, which are very convenient to deplay, I have had great sucesses with that. Today, Python has grabbed a lot of attention from Tcl - for "programming" it might be the more elegant language, but for "scripting" Tcl is hard to beat. But it is ironic that Python still ships Tkinter as the default GUI solution. If any language, Python should have standardized on GTK support, it had good support for GTK, but never standardized it. The Tcl syntax is a bit rough, but is built on extremely simple rules. This has two benefits. First of all, it is - that was what it was designed for - a great language to control tools, that is, script complex programs. Thanks to the syntax, every function immediately becomes a command a user can type, no complex syntax for the input required. In that sense, like shell scripting, Tcl sacrifices a bit of syntax suger for the developer for a nice interactive input syntax. It is vastly nicer to program in compared to the shell languages :) The second benefit ist the ability to extend the language by the users - it doesn't even need a macro system for that like Lisp. Tcl is one of the few homoiconic languages. Finally, while Tcl isn't as activelely maintained and especially extended as other "modern" languages are, this cuts in two directions. The implementation is extremely robust and many features are very efficient. Of course the basic execution speed of Tcl code is one of the slower scripting languages, but the libraries it uses are excellent. It had high performing event handling many years before Node.js made that populer.
- dmux 7y ago>Tcl is one of the few homoiconic languages. I've been diving back into Scheme and one thing I found out was that in Scheme, procedures don't normally have an "external representation." I.e., once a procedure has been defined, I don't think there's a way to get that definition back out. Tcl is really interesting in this aspect since procedure definitions (names, argument lists and bodies) can be viewed using the "info" command. With that in mind, I'd say it's actually more homoiconic than Scheme.
- davidw 7y ago> I think the second link is a great read Thanks!
- kevin_thibedeau 7y agoTcl hasn't been string based since 8.0 added dual ported objects 20 years ago. Meanwhile the latest JavaScript is burdened with keeping full source strings hanging around in memory so that comments and whitespace can be preserved.
- Leszek 7y agoThough to be fair, full source strings are kept around in memory for lazy compilation anyway (and other lazy computation).
- bsder 7y ago> Tcl/Tk is one of the cooler tools out there, though I wish it were not so... string-based. Tcl was designed in a different time when memory was scarce. The point of being so "stringy" is that you could parse it in place in the same amount of RAM as the original "string program" took up. I really would love something with similar constraints as the old Tcl for microcontrollers. BASIC used to run in 4K RAM with 4K ROM--I really wish we had a modern equivalent that I could connect to with a UART. Quite often my constraint on a microcontroller is waking up and waiting for a sensor, transmitter, etc. -- I have forever to run interpreted code. A small language would be really nice.
- icebraining 7y agoNot quite 4k, but MicroPython runs on 16K of RAM.
- bsder 7y agoAs I understand it, that's a very cut back version and doesn't include the compiler/interpreter so you can't just hook up to a UART and start reprogramming. I could be wrong, so please feel free to correct my statement if it's completely off the wall. What I want is something that I can hook up to the UART serial port, and start typing interactive commands into it to debug why my system is hung/stuck/etc. It needs to live in about 4K of RAM (and I can trade quite a bit of flash to do that). 16K of RAM is too much. Something like a Nordic nRF52811 only has 24K of RAM, and a lot of that gets used for the Bluetooth stack.
- kbr2000 7y agoSounds like you might want to explore Forth a bit. Punyforth on the ESP8266 is a convenient way to try get started hands-on, Jonesforth if you want to learn how you could go about implementing one. On bigger devices (PC/SBC/...) with an OS, Tcl/Tk is a wonderfully effective programming tool!
- kbr2000 7y ago
- blacksqr 7y agoTcl added first-class hash maps in the form of dictionaries several years ago. Tcl also added coroutines and a native object system in the past decade. Tcl has variable trace hooks which can be called whenever an attempt is made to change a variable's value, the hook can block the change, making any so-traced variable effectively immutable. (see: https://rosettacode.org/wiki/Enforced_immutability#Tcl https://rosettacode.org/wiki/Enforced_immutability#Tcl )
- srean 7y ago> Tcl/Tk is one of the cooler tools out there, though I wish it were not so... string-based. The "string based" part lies at the very heart of Tcl and plays a big role in what makes Tcl Tcl. However, modern Tcl has moved away from "everything is a string" to "everything is also a string". The difference is that in the normal execution path native types are manipulated for speed, but the string representation is always available should one need more dynamism. Tcl/Tk pioneered the notion of a scripting language as a library. It got threading right. You can run multiple independent Tcl interpreters in the address space of your process and they can exchange messages. No need for GIL, no need for serialization/deserialization (pickle/unpickle) ... just within process memory copy (or no copies in case data is immutable). Its virtual file system was another great innovation. Lua has taken the crown for small embeddable/extendable language but I still have a soft corner for the playful vibe of Tcl. I would hesitate to use it in a project where I have to interact with folks with whom I have not programmed before (things like 'upvar' and 'uplevel' ups the amount of trust you need). But when its play time, breaking out Tcl is one of those guilty pleasures. Getting rarer these days, playtime that is. Tcl had a reputation for being slow. But those were different times when the standards for 'fast' was much more demanding. Now I doubt it would be any slower than Ruby, it would likely be faster.