[HN Gopher] A brief interview with Tcl creator John Ousterhout (...
___________________________________________________________________
A brief interview with Tcl creator John Ousterhout (2023)
Author : breck
Score : 118 points
Date : 2024-07-20 15:56 UTC (7 hours ago)
(HTM) web link (pldb.io)
(TXT) w3m dump (pldb.io)
| abhgh wrote:
| John Ousterhout also was leading a project called RAMcloud (I
| thought was interesting) that the article doesn't mention - [1],
| [2]. Also, he has a book on s/w design [3] which is short and
| nice, and is more of a collection of ideas rather than an
| approach, which I highly recommend.
|
| [1] RAMcloud talk by J.
| Ousterhout:https://www.youtube.com/watch?v=lcUvU3b5co8
|
| [2] RAMcloud paper: https://web.stanford.edu/~ouster/cgi-
| bin/papers/ramcloud.pdf
|
| [3] A Philosophy of Software Design,
| https://www.amazon.com/Philosophy-Software-Design-John-Ouste...
| 8s2ngy wrote:
| +1 for 'A Philosophy of Software Design.' I read that book a
| while ago and really liked his views on a lot of things. Off
| the top of my head some of them are: complexity being the
| greatest enemy of software engineers, the importance of
| strategic programming (as opposed to tacit 'somehow-get-the-
| job-done' programming), general-purpose abstractions, and
| having deep modules exposed through simple interfaces.
| ilrwbwrkhv wrote:
| +1 One of the only books on design which actually is backed
| up by data.
|
| I had been misled by the Ruby ecosystem earlier in my career
| to do clean code + refactoring + tdd and this book + actually
| looking at complex systems such as games made me realize that
| coding is not about abstractions but it is about data and
| what the computer needs to do.
| jasinjames wrote:
| In your view, what word(s) would you use to describe the
| following?
|
| "a carefully designed API for interacting with piece of
| data which provides both a consistent technical interface
| and conceptual understanding of the meaning of said thing"
|
| The reason I ask is because the word I've always used for
| that is "abstraction", but I'm getting the sense that over-
| abstracted and over-architected frameworks has soured many
| people to the word. I want to communicate the idea without
| conjuring up images of java classes with 90 character
| names. What would you recommend?
| ilrwbwrkhv wrote:
| You are absolutely right. In that sense the right
| abstraction is what one should go after.
|
| But what I mean is the more popular Java / OOP style
| abstractions like a repository which returns a builder
| which returns class which you new up and pass to some
| sort of super interface and its just such a mess.
|
| As a technology I really like the JVM and hotspot but
| good Lord if I have to wade through 10 different things
| to get there.
|
| Finally to answer your question I have started using the
| actual name of the thing in the language I'm using. Such
| as a "struct" in c and rust which I mostly use these
| days.
| hangonhn wrote:
| Wasn't he also one of the creators of RAFT
| (https://en.m.wikipedia.org/wiki/Raft_(algorithm) )
| bbarnett wrote:
| Thanks John, I've kicked many a people from IRC using TCL.
| surfingdino wrote:
| Tcl "powers" the internet in a non-direct way since it is used in
| Cisco IOS.
| rwmj wrote:
| And every proprietary EDA tool in the world too.
| bch wrote:
| ...and a10/F5 aFleX/iRules[0][1], and the scripting in
| Tealeaf[2][3], ...
|
| [0] https://www.a10networks.com/blog/aflex-tutorial/
|
| [1] https://community.f5.com/kb/technicalarticles/irules-
| concept...
|
| [2] https://www.acoustic.com/tealeaf
|
| [3] https://help.goacoustic.com/hc/en-
| us/articles/360043785173-E...
| IshKebab wrote:
| ...unfortunately.
|
| I guess to be fair if it hadn't been TCL they would have
| chosen something even worse.
| surfingdino wrote:
| I guess Lua wasn't available at the time.
| latenightcoding wrote:
| Chez Scheme too then!
| zakirullin wrote:
| He is an absolutely amazing and extremely humble person. He
| agreed to review my article (written under the influence of his
| book) in his spare time. He does tons of code reviews every week
| for his students as well.
|
| I was especially impressed by his notion of "deep modules" in "A
| Philosophy of Software Design". The idea is extremely not-
| popular, but really sound and practical. I would definitely go
| for this book instead of "Clean Code" and such.
|
| His book is so fundamental, and it goes far beyond the overused
| and vague "complexity" term.
| skrebbel wrote:
| Any tldr for "deep modules"?
| zakirullin wrote:
| Deep module - simple interface, complex functionality
|
| Shallow module - interface is relatively complex to the small
| functionality it provides. Shallow modules don't hide as much
| complexity.
|
| https://github.com/zakirullin/cognitive-load?#too-many-
| small...
|
| But I highly recommend picking up the book :) It is an
| enjoyable read.
| Scarblac wrote:
| IIRC, the deep/shallow thing is anout how much
| functionality there is, and he used wide/narrow for the
| size of the API?
|
| So that the goal is to have deep, narrow modules: modules
| that have a lot of functionality hidden behibd a small API.
| v9v wrote:
| I think a good example of this concept is the foreach
| command in Tcl: It's quite flexible compared to list
| iteration constructs found in most languages.
|
| This is normal usage: foreach x {1 2}
| {puts $x} => 1 2
|
| You can iterate over two lists at once:
| foreach x {1 2} y {3 4} {puts $x $y} => 1 3 2 4
|
| Instead of reading one element from the list, you can
| read multiple: foreach {x1 x2} {1 2 3 4}
| y {5 6} {puts $x1 $x2 $y} => 1 2 5 3 4 6
|
| If any of the lists happen to run out before the others,
| instead of complaining it just returns empty elements.
|
| Many commands in Tcl give the impression that they can be
| used in many different ways, so writing a program in Tcl
| feels like building a structure by creatively assembling
| a limited set of legos.
| runlaszlorun wrote:
| Aha, I'd known some of the superpowers of TCL's foreach
| but not all of those.
|
| A 'deep command'.
| devnonymous wrote:
| This google talk
| https://youtu.be/bmSAYlu0NcY?si=yHREamFoRG_fZopl is a
| condensed version of the (already small - 150 pags IIRC)
| book. I highly recommend both.
|
| To the point made by the GP (and others here) about how
| useful the book is, I must add that I got a whole lot more
| from this small book than some other well known and oft
| suggested titles (like Clean Code, POSA etc).
|
| My most recent peeve about the matter is that Kent Beck"s
| "Tidy, Fisrt?" was apparently motivated partly in response to
| this book and yet it falls way too short to matching up. Half
| of thst book is way too simplistic and almost patronizing and
| the other is handwavy abstract notions too scared to touch
| reality lest it spoil the narrative.
| throwaway81523 wrote:
| I never liked tcl but the implementation was definitely small,
| which mattered more back then than it does now. Does anyone still
| care about it?
|
| These days what we really need is an easily embeddable Python.
| Guile is very nice if you want a somewhat fancy Scheme system,
| but it got out of control if all you wanted was something light
| and embeddable.
| psychoslave wrote:
| I guess Lua remains the chief goto for light embedded scripting
| environment, doesn't it?
| dunham wrote:
| I believe lua is often used in this role these days. I've
| gotten the impression that it is light and easy to integrate,
| but I haven't tried it myself.
| throwaway81523 wrote:
| Yes, Lua is quite easy to embed and is popular in game
| development for that reason. It appears in a few other
| applications like Redis as well. But, in the big picture,
| it's a weird language that is not very popular. People want
| Python and/or Javascript, and JS is awful, so that leaves
| Python ;).
| f1shy wrote:
| I do bot understand the downvotes. Maybe because of wording
| "weird". Give me a break, I think it has a point: much more
| people can do Python as Lua.
|
| I do like Lua, but if I just try to use it in my work, I
| would be paria.
| bch wrote:
| Lots of people care about it, and it's alive and kicking in-
| industry and being developed (Tcl 9 is imminent[0]).
|
| I've had fun w Guile over the years (though actually never
| considered its "heaviness"); fun.
|
| I'm constantly amazed at the professional love for Python; its
| got it's network effect in full-effect: lots of people, lots of
| software - there's just no denying that. But for Joy of
| Development, Tcl (and C) is still my go-to.
|
| You probably know this, but speaking of embeddable Python and
| Tcl, Tcl is indeed _embedded in Python_ if you 're running
| Tkinter[1].
|
| And Larry Wall thought _routers_ were weird places to be ported
| to[2].
|
| [0] https://sourceforge.net/projects/tcl/postdownload
|
| [1] https://docs.python.org/3/library/tkinter.html
|
| [2] https://libquotes.com/larry-wall/quote/lbh5n5p
| OskarS wrote:
| A huge bummer about Guile (and that is frankly shocking for a
| language designed to be embeddable) is that it relies on a
| bunch of global state, which means that you can't embed
| multiple interpreters a single process. This totally kills it
| as a embedded scripting language for many applications, and
| it's also just bad practice in general. Even Python, far less
| easily embeddable, supports multiple interpreters, though
| before Python 3.13 (I think) they all shared the GIL.
|
| Aside from this issue, the Guile API is pretty good, but the
| best one by far is Lua's C API, which is just a thing of
| beauty. I'm curious to try it with Tcl.
| coliveira wrote:
| Tcl makes it very easy to use multiple interpreters in the
| same process. It is one of its strengths.
| mkovach wrote:
| To this day, TCL is still my go-to for internal scripting
| languages or, quite often, creating a simple configuration DSL
| (or an internal linter for configuration files).
|
| Of course, I also do most of my scripting in TCL, so I'm a wee
| bit biased.
| derriz wrote:
| What I like about JO is that he acknowledges the deep flaws of
| Tcl. And there never developed an inward looking bubble of
| Tcl/Tk advocates - the users were largely driven by pragmatism;
| it just got the job done.
|
| This contrasted with Larry Wall and ethos/self-delusion of the
| Perl community - anyone critical of the language or its design
| was disregarded as simply lacking the intellect to appreciate
| the "poetry" of Perl - and the the language warts (better
| described as big pus-weeping boils) were actually features.
| f1shy wrote:
| >> what we really need is an easily embeddable Python. Guile is
| very nice if you want a somewhat fancy Scheme system, but it
| got _out of control if all you wanted was something light_ and
| embeddable.
|
| In my experience what goes out of control are python scripts,
| with many dependencies.
|
| Also the changes in the language tend to be much more intrusive
| and often than in scheme.
| IshKebab wrote:
| Yeah it is the de facto scripting language for EDA tools
| (everything about designing and manufacturing ASICs and FPGAs).
|
| It's pretty terrible but honestly Python would be pretty bad
| too. What these tools really need is a proper API that you can
| hook into and then use any language you want.
| kragen wrote:
| the implementation of tcl is not small; it's 1.9 megabytes
| stripped, 8.5 times the size of lua 5.2, which is a very
| popular embeddable scripting language: : ~;
| ls -l /lib/x86_64-linux-gnu/libtcl8.6.so /lib/x86_64-linux-
| gnu/liblua5.2.so.0.0.0 -rw-r--r-- 1 root root 216960
| Dec 10 2022 /lib/x86_64-linux-gnu/liblua5.2.so.0.0.0
| -rw-r--r-- 1 root root 1852968 Feb 1 2023 /lib/x86_64-linux-
| gnu/libtcl8.6.so
|
| even guile is smaller: : bin; ls -l
| /lib/x86_64-linux-gnu/libguile-3.0.so.1.5.0 -rw-r--r--
| 1 root root 1303112 Mar 5 2022 /lib/x86_64-linux-
| gnu/libguile-3.0.so.1.5.0
|
| a _small_ scripting language might be the 7th edition bourne
| shell or the 7th edition awk: : bin; ls -l sh
| awk -rwxr-xr-x 1 user user 46126 May 11 1979 awk
| -rwxr-xr-x 1 user user 17310 May 5 1979 sh
|
| admittedly tcl is still not as bloated as perl or cpython:
| : bin; ls -l /lib/x86_64-linux-gnu/libpython3.11.so.1.0
| /lib/x86_64-linux-gnu/libperl.so.5.36.0 -rw-r--r-- 1
| root root 3823936 Nov 25 2023 /lib/x86_64-linux-
| gnu/libperl.so.5.36.0 -rw-r--r-- 1 root root 7732544
| May 2 08:59 /lib/x86_64-linux-gnu/libpython3.11.so.1.0
|
| a small embeddable lisp might be xlisp or siod
|
| this stuff still matters a _lot_ due to things like icache
| misses, embedded systems, and standalone executable size.
| people complain about the size of golang and rust binaries but
| they don 't hold a candle to the cpython interpreter
| bch wrote:
| JO is giant in the industry; a longtime working professional with
| fantastic pedagogical chops. In my opinion, if he's talking, I'm
| listening.
| lizknope wrote:
| I tried learning Motif to write X11 graphical programs in 1994.
| Another student in the computer lab told me about Tcl / Tk. It
| was far easier. Then I got a job in the semiconductor design
| industry in 1997. The next year the leading EDA companies Cadence
| and Synopsys started using Tcl as the internal scripting language
| for the tools. So now it is 2024 and our CAD flows are tens of
| thousands of lines of Tcl code. Every week I still write Tcl code
| to generate reports or automate something.
| nequo wrote:
| What have been the pros and cons of Tcl for you, compared with
| other scripting languages if you have experience with them?
| DonHopkins wrote:
| Here's a transcript of a keynote I gave to the Toronto Usenix
| symposium, where I talked about the pros and cons of TCL/Tk,
| from developing multi-player SimCity with it around 1993.
|
| A lot has changed since then, but in 1993 it was so much
| better than Motif and every other alternative in so many
| ways.
|
| https://www.donhopkins.com/home/catalog/simcity/keynote.html
|
| >Hello, my name is Don Hopkins, and I ported SimCity to Unix
| on top of X11 using the TCL/Tk toolkit, and also on top of
| the NeWS window system using HyperLook. Unfortunately I can't
| be in Toronto to demonstrate this stuff to you, but
| fortunately I have some video tapes that you can see that
| demonstrate the whole system.
|
| >The X11 version of SimCity is multi player, and several
| people can join the game, and cooperate, and people draw
| roads, and put down buildings in different places, and then
| when you do something important, like change the tax rate, or
| build an airport, you have to get everybody else who's
| playing to agree where to put it, and which thing to put
| down. So it makes you slow down and rationalize what you're
| doing, and explain to people why it is you want to put it
| there. It's a really interesting addition to SimCity because
| it adds politics.
|
| >I'm going to show first the X11 version, which is on top of
| TCL/Tk, and that's a free toolkit that's available, written
| by John Ousterhaut at Berkeley. There's a book that's coming
| out describing it, and you can just get TCL/Tk and use it to
| make products for free. You don't have to pay anything for
| it, and it's actually very good code. It really beats the
| pants off of Motif, and we were able to modify it in order to
| support things like colormaps and multiple displays the way
| we needed to, and add things to it like a sound server to
| make sound effects, and pie menus for quickly selecting city
| editing tools. TCL/Tk made alot of sense for SimCity.
|
| [...]
|
| >HyperLook has this scripting language in it, and TCL/Tk has
| the TCL scripting language in it, so I was able to translate
| the things I had written in PostScript into TCL, and have a
| very similar structure. It makes it much easier to develop a
| thing as complex as SimCity if you have an interpretive
| programming language there, so you can just fiddle around,
| and paste new function definitions into the running system.
|
| >There are some user interface editors that have been
| developed for TCL/Tk, but I just wrote code by hand because I
| was doing some more specialized things, like multiple views
| and putting up views on different X11 displays over the net,
| that the user interface editors didn't support. HyperLook has
| a built in user interface editor, and I'll demonstrate
| HyperLook SimCity and the HyperLook environment in the
| following video tape.
|
| [...]
|
| >One of the things I developed for TCL/Tk and for HyperLook
| was this sound mixer server. And then we got an NCD
| X-Terminal, and just layered my sound mixer on top of their
| sound server. It can either use the built-in audio device and
| be a TCL sound server, or it can use the sound server that's
| in your X-Terminal or your Sun or SGI or whatever, if you're
| running NetAudio.
|
| [...]
|
| >For the pie menus and the multi player interaction stuff,
| like putting up windows on different screens and letting
| people have a shared view of this one environment, it was
| really nice to have the source code to the TCL/Tk toolkit, in
| order to support that kind of stuff.
|
| >It wouldn't have been possible to port SimCity to X11 using
| Open Software Foundation's Motif toolkit. It just absolutely
| sucks. It's not open, and you have to pay for the source
| code, and it's not being maintained.
|
| >But there's a really wonderful community that's grown around
| TCL/Tk, and people are allowed to use it in their products
| for free, and get the source code. I implemented pie menus
| with TCL/Tk for SimCity, and out of gratitude, I put the
| source code for the pie menu module out for other people to
| use, just to help to community. It's a nice positive feedback
| situation, as opposed to the cold war situation you have with
| COSE, Motif, and Open Software Foundation.
|
| >We bundled the HyperLook runtime system with the NeWS
| version of SimCity. If you're running OpenWindows 3.0, you
| can get it and try it out.
|
| [...]
| spacedcowboy wrote:
| Also responsible for Magic [1],[2] which is the basis (AFAIK) for
| the efabless route to getting your own chip designed these
| days...
|
| I ported it to the Mac and played with it a while back with the
| intention of making my own chip, but priorities changed when my
| wife fell very ill.
|
| [1] https://en.wikipedia.org/wiki/Magic_(software)
|
| [2] http://opencircuitdesign.com/magic/
| bch wrote:
| TFA mentions the Sprite operating system, which brought us a few
| things, including (i recently discovered), pmake[0] (by way of
| Adam de Boor[1]) which was an early instance of parallelizing
| make(1), and begat BSD Make[2], which is lovely to use.
|
| [0] https://web.stanford.edu/~ouster/cgi-
| bin/spriteRetrospective...
|
| [1] https://www.linkedin.com/in/adam-de-boor-4293a1/
|
| [2] https://man.netbsd.org/make.1
| ofalkaed wrote:
| I just recently started learning tcl/tk out of frustration with
| the other options for gui toolkits. Liking it quite a bit now
| that I have gotten over the hurdle of figuring out the sense of
| tcl which often felt like nonsense at the start. TK is especially
| nice, very easy to work with.
| kragen wrote:
| tk is still excellent, tcl is mediocre
| monkeydust wrote:
| I remember early in my career working at an investment bank on
| the trading floor as a support analyst.
|
| I was asked by a very frustrated trader to modify the behaviour
| of one of the trading apps.. basically he shouted..."just figure
| it out". Yea he was bit of a twat but then trading desks have
| changed a lot today.
|
| The app was from a 3rd party provider and making changes would
| take time of course, then they told me I could do this myself
| with Tcl. So in a day I figured out Tcl, made the change and it
| was in production the next day. Of course doing that now would be
| impossible but I remember the buzz from being able to make a real
| world change so damn fast.
| OhMeadhbh wrote:
| Perfect timing. I ordered a copy of "A Philosophy of Software
| Design" a week ago and it arrived yesterday. I'm going to start
| reading it tonight, but this is a nice preface, I bet.
|
| Several months ago a friend encouraged me to look at Tcl again
| (independent of Tk.) Mixins, regexes, reflection. All stuff I
| didn't appreciate in the early 90s. And I had reason to look at
| Minix a few years back. Ousterhout definitely did some good work.
| I think he might have been just a little bit ahead of the rest of
| us.
| kragen wrote:
| it didn't have mixins in the early 90s
|
| tcl's model of what data is doesn't accommodate general graphs,
| just trees. you can make a hash table but not a hash table of
| hash tables. on the plus side you won't have aliasing bugs like
| python's notorious matrix = [[0] * width] *
| height
|
| because its data model is so weak, you routinely resort to
| reflection to get things done, which makes it really hard to
| maintain tcl programs of any depth
| EdwardCoffin wrote:
| If you want a more substantial interview with John Ousterhout, I
| highly recommend his hour-long talk at google A Philosophy of
| Software Design, which is essentially a synopsis of his book by
| the same title.
|
| Edit: I guess not an interview, but he does answer some questions
| from the audience at the end.
|
| [1] https://www.youtube.com/watch?v=bmSAYlu0NcY
___________________________________________________________________
(page generated 2024-07-20 23:06 UTC)