Who Says Tcl Rules?
wiki.tcl-lang.org
wiki.tcl-lang.org
Discovered Tcl/Tk a lil while later. They were already on my Mac. With a half-dozen-line program in 1 minute I'd made a window on my screen with text. Graphics not much harder. I couldn't believe I'd gone through all that! haha. Had no idea GUIs could be so simple to write on a Mac. Noone told me. I wrote a couple of games in a few days. Tcl is a kinda weird language, unique, but very easy to get the hang of and be very productive in, a joy. I loved it.
https://tkdocs.com/tutorial/intro.html
Which exists since 2008.
Here's the minimal example for Tcl, Perl, Python and Ruby (note -- Tk doesn't have to be used only in Tcl!) with the pictures of the native looking interfaces on Mac OS X, Windows and Linux (all three):
[edit]
Tile (which was incorporated in tcl 8.5) is actually older, as an extension, so with a bit of work you could get better looking apps even earlier.
In fact, my favorite GUI app on Linux (xcircuit) uses tk.
Things have improved, I found a good multi-language documentation page (https://tkdocs.com/index.html) including this good multi language example (https://tkdocs.com/tutorial/firstexample.html) but very little on how to use the c api (https://www.tcl-lang.org/man/tcl8.6/TkLib/contents.htm).
I hope things keep improving, Tk is what electron should should have been.
Except that it has zero accessibility support, e.g. for blind users with screen readers. Please don't use it for any non-toy application, unless it's something inherently visual.
Then someone suggested that I try Tcl/Tk. Literally within 2 hours of first hearing of the language I had a reasonably functional application running on my computer.
I do most things in Python these days since it is simply far and away more capable than Tcl but I still think it's an excellent language for a lot of things.
But it was robust and great at interacting with whatever you wanted and enabling you to do it in a controlled way.
It reminds me how it is perceived in much the same way AWK was and still is, it's a hidden gem that many never bothered with but if you spend a bit of time to learn it, you start to think, why didn't I look into this more earlier.
Though python has in so many ways, usurped it and indeed AWK for their niche uses, they still have their places.
[EDIT X11, not Z11 typo]
Funny you should mention that. Python's standard GUI system is still based on tk, and from a quick look at the docs you can even run a tcl script from inside Python.
I have a bunch of private tools for personal organization (time tracker, todo list, notepad-like app) that I've written in Tcl. Over the years, I used Android smartphones more and more and I just wanted all those small apps for Android too, but never had time to learn mobile development.
With Androwish I can just run them in my Android almost unmodified! And I can also make use of Android features like notifications. I sync the files between devices with Syncthing [2] or another tool and, voilà! I can use the same apps in both Android and Unix!
EDIT: syntax
I still need to discover how I overcome some Androwish limitations. Tk is great but the integration with the system (like copy-n-paste) is still something I need to discover how to deal with.
EDIT: found some at http://androwish.org/index.html/wiki?name=Example+Scripts
I wowed some students in my operations research class a couple of months ago by writing a few lines of code in the Python interpreter and popping up a window with a button in it with Tkinter. "You keep doing magic!"
Looking at it just now, I couldn't help thinking his style of illustrating with photos was an influence on your own books?! I guess so. (I've only read the 2 coffee-themed JS books, which I really loved. Thank you! p.s. The most sophisticated JS program I wrote was "JavaScript REPL with allong.es" hehe.)
I love the way you put this. My team is in the middle of an IMO largely pointless port of working code from Scala to JS, because some senior people think Scala is icky...
(Even though my team is a JS team, I don't think JS is a better language than Scala. To the objection I get: "we can't find Scala engineers" I point out that JS engineers on my team have had to learn to read Scala in order to port the code, so they're halfway there already...)
Is there such a thing as a PL engineer? I thought it was software engineer, and the particular language matters less than general software principles and practices. Plus, any new employee is going to have to learn the code base regardless of whether they start out knowing the language.
Any software engineer should be able to learn a new language. The idea that you have to higher engineers who already know the language, particularly a high level general purpose one, seems suspect. It's not like they're writing some low level Rust or C code.
It seems like a poor reason to port a code base, but I guess it happens often enough.
Yeah, I agree. And I'm doubtful that the time it would take for one or two competent people to come up to speed in Scala is less than the time we're spending to port the entire thing over to JS. It's months of engineering time. That time could have been spent improving the existing codebase rather than the much riskier option of porting to a new language. And then that team would have the Scala engineers it needs, for ongoing work. Or at least a shared resource to help out.
It sounds like you’re saying the project succeeded by good design despite Tcl (fair - I don’t know your project), but I’d argue Tcl itself is a fine example of good design. With a small amount of study you’ll be able to effectively reason about it. It’s extremely regular, composable, and interfaces well be it text manipulation, networking, filesystems, GUIs, ..., or indeed, itself - it’s well-established and takes compatibility seriously. I think I’m into it nigh 15 years, and it’s still a proper first-goto tool for me.
Don't get me wrong, I love it too, but it has warts just like any other language.
Ousterhout is clearly an outlier thinker though. Not just the father of TCL and TK but log structured filesystems, RAFT consensus, and more. I'd be excited if he jumped back into a new language project based on his reflective experience. I imagine a more pragmatic Perl 6 or similar.
Back to Ousterhout though, you might dig his “Philosophy of Software Design”[0] book, or talks associated with it[1].
Lots to like in this space...
[0] https://www.amazon.com/Philosophy-Software-Design-John-Ouste...
Please note that Perl 6 has been pragmatically renamed to Raku (https://raku.org using the #rakulang tag on social media).
Tcl on the other hand is more shell-like in its core syntax, trying to simplify that. Not really because it's supposed to supplant shell scripts, but because it has a similar target audience, people looking to automate things (or customize them).
At least that's the beginning, and if it would've stayed that way, nobody would lament either language's passing, as they'd be good in their niche. To truly fall, one must rise first. Perl did that with early web programming (CGI), Tcl with UI programming.
I like both a lot. I've had a lot of fun programming with Tcl, and it was interesting how your workflow changes if a UI is really, really close to hand (sorry, TKinter doesn't come close to me, the only other language I'd nominate for that would be Rebol). Programming with BASIC I always asked for input, programming with Perl/Python I always pass command line parameters, with Tcl I often popped up small Windows.
Of course that didn't end up happening, but it's interesting to think about what might have been different if it had.
Sort of a bitter-sweet scenario - I think some were excited that Tcl could have been out there more, in people’s face, but others think Tcl dodged a bullet, as mass adoption would have laid a tough burden of backward compatibility and a bit of ossification that the core team is happy to not have mandated on them.
[0] https://books.google.ca/books?id=GQIMAgAAQBAJ&pg=PA4&lpg=PA4...
It's a clever language but it has the kind of sloppiness that Python has for better and for worse. In particular (in both languages) you can look up the stack and see and influence more than most people think you should.
I've come to appreciate the module system in Javascript which is static enough to allow tree shaking. You could not do that reliably for Tcl or Python -- you can't even do it in Java because almost all Java code does something with passing strings to the Classloader, even if it is just the standard library looking things up in resource files.
Many people who like Tcl have moved on to Lua for various reasons.
Granted, you could do much worse. Unlike shell scripts you at least have access to sensible data structures like lists, dictionaries, and so on. And unlike shell scripts or Makefiles, you can actually handle spaces in your data, so that's at least not horrible.
But when everything is a string, there is no type safety anywhere. So many things that should just be compile errors blow up on you at run-time instead. God help you if you're using code that other people are updating and silently changing.
The syntax is also pretty annoying at times. For instance, you can use unbalanced {} characters within comments, but not if those comments are within a proc. You can nicely write long lists over many lines with {...}, but you can't put comments in those.
Anyway, haters gonna hate. I hope other folks like it more than I do.
It's possible your parent didn't mean literally "strong typing" or even "static typing", but instead more generally "notions of types, whether at runtime or before".
Being exposed to a language at first by trying to understand what it is doing in installing software is probably not a great introduction. I did get the software installed but my dislike remained
This was probably further increased by the fact that post that I had bad experiences with my supervisor that just soured everything about it. Even to this day where it would benefit me to use TCL, I try to avoid it in favor of languages like Python.
IMHO it's creator Don Libes [2] is an original-thinker/innovator in the same league as Ousterhout.
[0] https://en.wikipedia.org/wiki/Expect?
The only other GUI development environment I've come across that I've found to be similarly easy to develop in (and cross-platform) is Free Pascal / Lazarus. I assume the commercial Delphi offerings might be similar, but I don't have any experience with them.
I guess I was just trying to say Rebol/Red have something similar to TCL/Tk in that you can trivially build powerful GUIs.
For those interested, here's a link that discusses it: https://www.tcl.tk/man/tcl8.6/TclCmd/return.htm
My secret wish is to replace it with an embedded TCL REPL. TCL isn't perfect, but it's pretty easy to interface with C, and it fits on small targets. My main problem (aside from lack of time) is that I'd actually need a tiny version that would fit within dozens of kilobytes of code. Closest I've found is Jim [1], which is 100-200kB (depending on features). Compare that with Lua, which fits under 100kB (though excluding its standard library).
Sounds like a poor man's execline:
I don't remember that about Tcl.. How far can you do that? And how do you do that? (an example would be great). Thanks.
I've been getting into Forth lately, where you can redefine absolutely everything[0], and make your own anything, to a ridiculous degree. Not sure what this quote means. I'll be pleasantly surprised if it's true.
[0] Well, you are stuck with the stack(s) I guess. But that's about it.
edit: Thank you all for the great answers!
proc do {body condition} {
while 1 {
uplevel $body
if {![uplevel [list expr $condition]]} break
}
}
set i 10
do {puts $i ; incr i -1} {$i > 0}
10
9
8
7
6
5
4
3
2
1Procedures are defined using "proc", which is also a procedure: proc sum {x y} { return [expr $x + $y] }
Here proc is taking 3 args: name, args, and body (curly braces wind up enclosing one arg).
But you can also redefine proc, using proc. Here is a neat function which uses this to keep other procs from being given new definitions:
rename proc _proc
_proc proc {name args body} {
if {[info commands $name]!=""} {
puts stderr "warning: [info script] redefines $name"
}
_proc $name $args $body
}
An example that shows this:
~$ tclsh
% rename while origwhile
% proc while {args} {
puts stderr "Debug: invoked while with arguments $args"
# do anything you want here
uplevel 1 origwhile $args
}
% set i 0
% while {$i < 5} {puts $i; incr i}
Debug: invoked while with arguments {$i < 5} {puts $i; incr i}
0
1
2
3
4
%
Semantically Tcl is a bit like Lisp with Algol syntax, and you get to execute expressions on upper stack levels, and can also evaluate parameter blocks (aka lambdas).
So you just need to create a function for your control structure, that will take the required parameters for the control structure body, and then eval it on the upper call level.
It is very rough as description, but maybe I was still able to convey the idea.
For our in-house app server, all our configuration DSLs were just Tcl scripts that we sourced (loaded) on application start.
https://www.iro.umontreal.ca/~monnier/hopl-4-emacs-lisp.pdf [2.2]
By the way, does anybody know if anyone ever attempted to add a kind of static typing to Tcl? It would be very interesting to see how a stringly-typed language would go about that.
I looked at addressing TIP 302, but it was complicated since Tcl virtualizes the clock (like it does the filesystem).
Even better was the ability to attach to the running ui or server (yes we had both), replace some of the code on-the-fly, and disconnect. Perhaps not so amazing these days, but it was way ahead of anything else I'd seen upto that point and pretty mind-bending for a C/C++ coder.
Someone who wanted to play folk historian could probably have a lot of fun going through the archive, assuming their eyes wouldn't glaze over at terms like "cycle accuracy" or "serial loopback".
Perl has the magic and TCL has the voodoo. Add both together you get voodoo magic which is quite fascinating.
I've used Tcl in various cases in which I needed to provide the client with and executable. Freewrap gives you a reasonably sized executable (it's a lot better than having your end-user install Java or even Perl).
This is how the tkdocs.com examples in Perl maintain parity.
I think ideally I'd like both capabilities, which seems possible if you just expose the language's parser as a function.
Plus things like uplevel let you jam a lot of meta trickery into commands without needing AST manipulation.
So, yeah, you do get both capabilities, it's just done atop the very simple baseline system, if that makes sense.
(look at e.g. 'snit', a pure Tcl OO system, as an example of what can be done with just Tcl itself)
That, along with the ability to pass code block literals, lets you redefine the language into your own DSL with new control flow statements. You can define a “while loop” function, for example.
Before heavy use of closures and callbacks in dynamic languages (Array.forEach, for example) became the thing this was pretty huge, and it’s still nicer syntax sugar than you get defining control structures with that route.
I used TCL with Squish for Qt-based UI test automation for a couple of years. For stuff like that where you really do want a set of domain-specific imperatives you can string together, it was really cool to work with. Biggest downside was you could get too fancy and find yourself alone off in the weeds of your own DSL.
I think it's a lovely language. If it had a debugger it'd be awesome.
Nowadays not sure if it still has viable market.
Setup a GET method to a TCL procedure and then return the HTML of that procedure.
I think many TCLers weren't that amazed when Rails showed up.
For a while, I know that https://flightaware.com/ used it fairly heavily. Indeed, their careers page still shows an interest in Tcl skills.
After he sold the company to Red Hat I worked there really briefly. Apparently half the sales fell through because Tcl wasn't regarded as "enterprisey" enough for customers (note the customers themselves would probably never write a line of code). There was an attempt to rewrite the entire engine in Java — it being 2002 — which limped along for a while before the project died.
But there's more! The original Tcl stack was open sourced and continues to this day as OpenACS (https://openacs.org/).
The Java rewrite also still exists (https://svnlegacy.ow2.org/byline/) but has been dead 15+ years, and just digging into those 7 level deep directories rekindles a feeling of dread in me.
ad_proc and online documentation was awesome.
I also had to figure many things out from first principles because documentation was all for PHP and Apache, not aolserver and tcl.
Kinda strange how scope is restricted to the current level.
TCL is perhaps my favorite scripting language of all time.
- TCL 8.5 Network Programming
Yes, we are in 8.6, but except OOP almost nothing changed.
report_timing -from ... -to ...
However, the problem is that it has been pushed to its absolute limit. Massive automated design flows consisting of tens to hundreds of thousands of lines of often highly unstructured tcl are present at most semiconductor companies. All of this code is written by VLSI engineers who have not much software training. These engineers take advantage of the highly dynamic nature of tcl to solve their problems quickly... and the result is often an unmaintainable mess of code. As an example, I've almost never seen anyone use tcls module system, instead its just scripts using the `source` function to load other scripts.
Since the language is not mainstream among software engineers, there is very little material on best practices, and semiconductor companies are extremely locked down meaning there is no open source tooling to speak of. So VLSI engineers continue producing spaghetti code to handle all of the implementation.
Obviously I am speaking in very broad strokes, so there may be companies out there that do it right.
This is all fine and good, but when a vendor can no longer change or fix tooling without running the risk of breaking a large customer's Tcl abomination, the flexibility that it provided is now a problem that's dragging everybody down with it. All of this goes without mentioning that electrical engineers that often get saddled with this aren't very good programmers.
People are excited about SymbiFlow for a reason. The hype in spite of how unlikely it is that it will ever match vendor tooling is a testament to the situation.
Take a look at http://www.androwish.org/index.html/wiki?name=jsmpeg+SDL+Vid... for an experimental approach to displaying Tcl/Tk applications in a web browser.
Using a standard Tool Command Language to control your EDA Tools, is a wonderful concept. Tcl's numerical handling leaves something to be desired ([expr 1 + 1]), but in other aspects, such as node/list processing, it is stellar.
What would have been a better choice? Lisp, as in AutoCad? Something else?