A brief interview with Tcl creator John Ousterhout
pldb.com
pldb.com
It then took about 5 minutes to compile on a DECstation 5000 with 32MB RAM running Ultrix.
Someone in the computer lab saw me with the Motif toolkit book and said "Why don't you use Tcl / Tk?" I said "What's that?" and they showed me. I had "Hello World" in 3 lines and could edit and start my new version in a couple of seconds instead of minutes to compile.
After I graduated I got a job in the semiconductor industry which ran on Solaris and HP-UX and now Linux. All our digital tools from Cadence and Synopsys started using Tcl as the built in scripting language. I ended up teaching my older coworkers how to program in Tcl. I was still writing Tcl yesterday. There are a lot of things I hate about it but it has stuck around.
The text before the interview mentions AFS which I did not think Ousterhout had anything to do with. I thought it was from Carnegie Mellon and then IBM Transarc. We used AFS at my school and I still miss it. Going to NFS in the industry seemed like a step backward.
We only had an 8MB quota for our entire Unix account in college. It was great when working on a group project that I could make a dir in my account for that project and then add the 3 other classmates login id's to the group dir ACL list.
These days at work depending on the size of the company we have to send an email to the sysadmin / devops team to say "Add user ABC to project group ID XYZ" and then wait hours or days. At my current job we can request Unix group access through a web site but I still think it is some human running commands to manually add users because it takes about 24 hours.
Ya - I wonder if the article writer actually meant LFS (log-structured file system)[0] which was part of the Sprite operating system project.
[0] https://en.m.wikipedia.org/wiki/Log-structured_file_system
Updated here: https://github.com/breck7/pldb/commit/312d5dab32fda3782e8466...
The most horrific thing I discovered about tcl is that curly braces within comments can affect flow control. This is because comments are interpreted as a command that does nothing, not the same as complete ignored. Finding that out the hard way was not fun.
This is not true. Once Tcl sees a valid comment, the rest of the line up to the newline is treated as a comment. An odd number of trailing backslashes suppress the newline for interpretation purposes. Within the comment you can use braces or whatever without affecting control flow.
However, the parser is confused by unbalanced braces in comments.
Here's a classic case that turns up occasionally during development:
proc asdf { args } {
# if { first draft complex condition } {
if { final simplified condition } {
do something
} else {
do something else
}
}
missing close-brace: possible unbalanced brace in commentOusterhout did work on Sprite (a distributed OS and file system) in the 1990s at Berkeley, and then, as another mentions, the log-structured FS (LFS).
This brings backs some memories for me. In high school we only had a 10MB quota. I remember bringing in stacks of floppies to workaround the quota so I could download junk off their T1 and using file splitting programs. One of my friends even blew all his McJob money on an external Zip drive. By the time I started college USB thumb drives came into vogue and made everything so much easier.
Ah...I recall doing this too. Funny to remember so much of that money going to buy the best possible hardware for the least amount of money.
Like I thought I won the lottery when I got a deep discount on an OEM AWE32 card that came loose in a cardboard box, literally bare and rubber-banded to a pile of floppy discs. Just so I could have low-latency midi and load soundfonts into the card.
The zip drive was frustrating though. I got to college and had all my HS portfolio work on a zip disc but no drive anymore. So I bit the bullet and bought a drive, thinking it would be a while before that format was useless.
Functionally I was right but for practical purposes I never used the drive much after copying my files over. Especially after hearing about the... Click of death issue I think it was called?
Funny memories.
The Tcl language is actually really clever and interesting, but the textual evaluation model (a much smarter approach than Bourne and C-shell) still made it poor for representing and manipulating graphs.
I was lead for the extension language in a new CASE system, which had rich semantic graphs, including cycles. Tcl ended up being chosen by a cofounder, so I wrote up a doc on language limitations and how to work around them.
(I'd also argued in the early/mid-'90s that the high-level extension language should also be the application implementation language. Such that we'd develop much of the application functionality ourselves in this high-level language, atop a C++ or C core API for foundation that needed that. Python eventually went this route, but hadn't yet. At the time, people in these sectors (which were very different from MIS developers) were thinking of extension language as things customers could use for simple reports or crude customizations or integration glue. Python and Tcl were new candidates for extension languages, and some big-ticket CAD/EDA/publishing tools had already been using their own more powerful Lisp variant implementations.)
We had Rails and Active Record done in Tcl back in 1998.
I asked myself: "how hard can it be?"
I decided to search online for easy and free ways to read the files. It had been several years since I last programmed anything though I had done a bit of script modifications on some perl/awk/sed scripts. I found Tcl/Tk after a bit of digging and decided to give it a whirl.
In all I spent about 16 hours dinking around with Tcl and had a nice, short program written to read everything, display the data for a QC check, and write it to disk. The documentation was detailed and concise. Of all the programming languages that I have used over the years the fact that I could sit down and find the right set of simple commands and assemble all of it into a working program in a couple of days with no learning curve pain or friction was amazing.
Thanks John Ousterhout.
I re-read it whenever I sometimes fall into as it reminds me design and craftsmanship are the most important aspects of building great software.
Some decades later I see that Ousterhout, among others of course, is still contributing to the community, e.g. the Raft consensus algorithm, while the steam may have left Tcl.
I'm not sure what the y-intercept of Rust is, but its slope seems to be pointed towards more code being written in it than ever before. For example, the wasm compilation is probably the clincher for my toy projects because I like to build stuff to run on a website, but I don't always like writing in JS.
[1] - https://gist.github.com/gtallen1187/e83ed02eac6cc8d7e185
People playing with new stuff in a regular basis? HN Readers: all, RestOfWorld: None.
People who have heard of rust? Similar to above.
Rest of world=99.99% of devs.
Yes I am exaggerating, but this place is a bubble. Rust does seem to be growing in popularity, but so far, doing so in a really tight community.
Rust is being used where it makes sense--generally security. So, gamedev won't use it for main loops but will use it for networking code. The crypto Ponzi brigade chose Rust for a reason. Some of us who write communication stacks (TCP/IP, CANBUS, etc.) try to use Rust whenever possible.
However, you are correct in that Rust popularity is growing, but it's going to be slow. If you look at the TIOBE index, there is a limit as to what Rust can really displace. A lot of the top languages are now GC-based, you're not going to reach for Rust if you can use those. So, Rust can realistically only displace C, C++, and ... nothing else. That means almost 75% of programming language use cases aren't even in scope. And C programmers really aren't going to gravitate to Rust as it's more of a C++ replacement.
So, you need a specific usecase (security) or a greenfield project that would use C++. That's going to be a slow climb.
So while Rust is being adopted, it is at the same scale that C++ was against C around the early 1990's, in regards to market size adoption.
[0] - They are looking into it, still no standard update that allows for Rust
Also given how the team has managed C++/CX transition to C++/WinRT with lesser tooling stuck on C++17, dropped Modern C++ bindings [0][1], before going into other shinny thing, I wonder how long they will keep at it.
[0] - https://blogs.windows.com/windowsdeveloper/2021/01/21/making...
In the future, the question won't be "what language do I need to learn to code on this platform", but instead "where are the language bindings for my favourite language".
Being a Borland and ETHZ fanboy has taught me some hard lessons in development effort, when languages don't have tier 1 support from platform owners.
So until Rust is on Visual Studio and Windows SDK out of the box, I rather keep using .NET languages alongside C++ for Windows development.
C++/Cx (and it's predecessors) was bad in requiring special compiler support whilst WinRT had already seen real adoption and cppwin32 didn't really give any benefits apart from another backend so they seem to have concluded that C++ devs would easier be supported by something more mature (that needed support anyhow) and then just focus the win32metadata project (That's still alive) on "new" languages.
They should all have been fired if it was up to me, we don't pay VS licenses for killing our workflows like that.
WinRT is Windows only technology, who cares about extensions.
Plenty of people don't have any issues with GCC and clang extensions, or macOS specific ones like Objective-C++, or TI, or ARM SDK, or whatever fancies their party, only MS ones are bad.
Some ecosystems where there is still to exist a Rust story in accepted toolchains.
Sure it is possible, provided one is willing to spend the money to make it happen.
It’s 175 pages of well-refined, to-the-point, applicable wisdom; highly recommended.
A more lasting contribution:
Why Threads Are a Bad Idea (1995) [pdf] (gatech.edu)
Stuff operates in parallel in those languages, because you’re essentially describing little machines that all run independently of each other. You probably have some handoff from one machine to another. It’s more like Factorio and less like multi-threading.
From the old hn convo, which I agree with.
> Structured threads aren't that hard (e.g. task-based systems, thread pools).
> Unmaintanable raw-pthread messes are a nightmare sequel from the director of Endless GOTOs.
I think @Amelius is over generalizing on parallelism while Ousterhout is talking specifically about fine grain locking as a specific form of implementing parallelism.
It’s no accident that a lot of sqlite tests are written in Tcl, or that a “weird language like Tcl” has first class sqlite support. In fact, for a while Richard also sat on the Tcl Core Team (TCT), shepherding its development.
Tk too! https://gitlab.com/cznic/tk
Made possible by a clever C to Go compiler: https://gitlab.com/cznic/ccgo
But despite now being a Go programmer, and as much as I’d like to try it, I can barely remember a single thing about any of it.
But I do wish there was a bit more info in the README.
So there was a discussion about why people still use C or similar recently and I think that C+tcl is a potent combination where you can mix C and TCL in a very natural way such that you never do in C what TCL does much more easily but you can still get excellent performance where it counts. It's all theoretically possible in python but just feels like much more work.
The best lack all conviction, while the worst Are full of passionate intensity.
https://web.stanford.edu/~ouster/cgi-bin/wrist.php
About 15 years later, Tavis Rudd developed his system to program by voice.
Now here we are a decade, or 3 decades, later. Damn, the future sure is taking its time.
"The biggest improvement in performance is the non-working-to-working."
https://albertcory50.substack.com/p/in-larrys-kingdom-part-2
A friend of mine worked for him at Sun, and said his coding standards were incredibly rigorous, but never silly.
The funny part was when I got an email from someone at Oracle, perhaps in legal, who wanted me to sign an "indemnify and hold harmless" statement for my code, code that I shared freely, received no compensation for, and had no control on how it was used by Oracle in their product -- Rrriiight. I replied "no thanks", and if Oracle wanted to use my software, they simply should comply with the BSD license that it shipped with, including the attribution clause.
memory fades. I don't remember how I did that anymore. Maybe we folded Oratcl into the OEM agent???
As you'll read in that article, the agent didn't work all that well, at first, and it was a particularly hellish time to be a manager.
There's also a 'ps' listing on page 50, with a user id 'aholser', if that rings any bells.
I haven't used Oracle since about 1998, and never Oracle's Enterprise Manager or whatever agent, so no idea how well it worked. I'll read your article.
by 2000, my colleague Dimitris Nakos had cleaned it up, probably. I don't know who 'aholser' might be.
Performance isn't such a big deal - even though he says it isn't as fast as a really slow language like Python, the scripts tend to be very short.
The issue is "everything is a string". Anyone who has written any significant Bash or CMake will be familiar with how shitty that is. TCL is actually a bit nicer than CMake or Bash, but it still suffers from the fundamental problems of stringly based languages.
Quoting is insane and hard to get right. Type errors are very common. I would say TCL has had a negative effect overall at least on the EDA industry. Maybe if it didn't exist we could have had a slightly nicer embedded language like Lua. Or even just a C API.
What I will say is it's absurdly easy to write a Tcl extension - I wanted to talk to a soft CPU using a Xilinx Platform Cable USB (which isn't supported by OpenOCD). I ended up creating a simple Tcl extension around xc3sprog and it worked a treat - I'm pretty sure the engineering effort to do the same for a different scripting language would have been much greater.
This really makes me wonder if you’ve used Tcl. Quoting in Tcl is so much simpler than in e.g. bash or cmake. It’s all about know when a string will be evaluated or not.
> Type errors are very common.
In my experience, no more so than in any other dynamic language, e.g. Python or Lua.
Again in my experience, if one wants a scripting language — i.e., one used to orchestrate a number of commands — then Tcl is exactly what the doctor ordered.
"Writing with a screwdriver is so much simpler than e.g. a potato or a sock."
On the contrary, compared to e.g. bash, unless you're doing something super unusual or wrong, you rarely have to think about quoting in Tcl. Use "" when you want substitution, {} when you don't, {*} when you need to pass a list as multiple words, construct lists and dicts using their appropriate constructors and never by hand — and you're safe. Unlike bash, quoting in Tcl is dead simple, predictable and never surprising.
That being said, those are very much edge cases.
More damning, from my POV, is that you can't get ref counting of things like C objects or file handles, since they're just string handles. But there are a lot of uses that don't need that
I agree that its syntax is pretty weird when compared to any other language. And a lot of stuff works differently than you’d expect if you’re coming from Python.
For me, there’s always a mental context switch that needs to happen before I can get in the flow with TCL. Once I’m there though, it’s a very fast/powerful language to implement stuff with.
Thank you, Mr. Ousterhout!
edit: ooh, and https://tclarchive.org