
I can’t believe I’m praising Tcl - m_for_monkey
http://www.yosefk.com/blog/i-cant-believe-im-praising-tcl.html?
======
antirez
About Tcl and the embedded world, a few years ago I wrote a single-file Tcl
interpreter that is mostly compatible with current Tcl implementations
(something is missing like namespaces, something was added like anonymous
functions):

<http://jim.tcl.tk/index.html/doc/www/www/index.html> (source code is here:
<https://github.com/msteveb/jimtcl>)

Now maintained by Steve Bennett, and actively used by some embedded folks.

------
mih
If one looks at the EDA industry you will have to appreciate the breadth of
applications Tcl is used in. Usually there is a Tcl interpreter with custom
commands written in C for optimization.

The ease with which one can quickly create interfaces between different tools
I think is one of the contributing factors to its success. That and of course,
the legacy codebase.

------
cturner
You can get lisp to interact more like a console language. Write a parser to
accept python-ish whitespace syntax (whilst still allowing parens syntax), and
transform that s-expressions so you can pass to the interpreter

To imply:

    
    
        (define (fn a b)
          (list (car a) (car (car b))))
    

You could type:

    
    
        define: fn a b
          list:
            car a
            car (car b)
    

As it's a console, in practice you'll mostly be typing commands like this:

    
    
        load x y z
    

but you have good mechanisms for going deeper. And if you just want to write
in s-expressions you still can.

~~~
silentbicycle
The aside in the linked article about avoiding shifting and parens just to
type a simple command is even more true once a command spans multiple lines.
Say what you will about syntactic attempts to remove the parens from Lisp, I
think it's a secondary issue for a command language.

There are some good observations about design pressures on command languages
vs. programming languages in Olin Shivers's "A Scheme Shell", as well.

------
forinti
IMHO, nothing beats Tcl/Tk when you need to write a small distributable
application with a GUI. The last ones I wrote were for purging files acording
their date and for compiling Forms/Reports. With freewrap I can build an
executable with no effort at all.

------
febeling
I think it was antirez who said that Tcl had one of the best C codebases he
had ever seen. Since then it's on my code reading list.

~~~
luriel
Another recommendation for your reading list: The Plan 9 kernel (could be
considered a modernized version of a classic code reading which is also highly
recommended: Lions' UNIX 6th Edition commentary).

The Go compilers and stdlib are also a great read. Is no coincidence that Ken
Thompson was involved in all those projects.

More on topic: I agree it is sad how underrated Tcl is, perhaps not the best
language ever created, but deserves much more attention and credit than the
latest JS-flavour-of-the-week.

Tk is also great and IMHO still the best portable GUI toolkit around.

~~~
aidenn0
Tk is _great_. What I don't get is why people are still making applications
that don't use ttk and it's modern theme. It's Motif look on linux is the
single biggest complaint I hear about it today and that problem was solved
what, a decade ago?

As an aside, LTK, which is basically just lisp bindings for talking over a
socket to wish is the only lisp gui that I've had work on all platforms and
all lisp implementations.

------
sliverstorm
I spend a lot of time using Tcl (I have to) and I spend almost as much time
wishing I could be using Perl instead. This is partly because of weirdness, as
described by the author of this article, and partly because I routinely run
into things that seem to be far more difficult to do in Tcl, than they ever
would be in Perl.

Can I get one of the Tcl adherents in this thread to comment- have I got
things completely wrong? Need I simply become better with Tcl? Or does it
truly lack things like powerful string handling and hash tables?

~~~
pmarin
For hash tables you have two options: the dictionary[1] or the Tcl array[2],
which is more or less like an Awk array.

Can you give me an example of _powerful string handling_?

string[3] for the usual string manipulations.

subst[4] when you want weird string substitutions (works like a template).

regsub[5] and regexp[6] for regular expressions.

[1] <http://www.tcl.tk/man/tcl/TclCmd/dict.htm>

[2] <http://www.tcl.tk/man/tcl/TclCmd/array.htm>

[3] <http://www.tcl.tk/man/tcl/TclCmd/string.htm>

[4] <http://www.tcl.tk/man/tcl/TclCmd/subst.htm>

[5] <http://www.tcl.tk/man/tcl/TclCmd/regsub.htm>

[6] <http://www.tcl.tk/man/tcl/TclCmd/regexp.htm>

------
makecheck
I'm not as fond of the language as some, primarily because it is unnecessarily
hard to debug errors and unnecessarily hard to read code and data.

For example the interpreter can basically say "there's a syntax error
somewhere in this giant block of yours" and not have _any idea_ where.

A related issue is that a single delimiter (the brace) is bad for readability,
even if it's easy to parse. Just try reading a gigantic dictionary; it isn't
anywhere near as clear as Python/JSON-style can be (where there are obvious
commas, colons, quoted strings and more to show you exactly what you're
looking at).

Another headache for debugging is that commands frequently accept the _names_
of variables. In unfamiliar code you can't even answer simple questions like
"where are all the places 'xyz' is used?" because a reference to 'xyz' could
be hiding almost anywhere. You can change something and not fully understand
the effects that your change could have. While I'm sure this allows for very
clever code to be quickly _written_ , it fails the more-important test of
producing code that is easy to _read_.

It is even possible for commands to silently accept mistakes and seem correct,
with major consequences. Suppose "x" just happens to be a one-element list
containing a number, '{0}'. With this input, "lindex 0 $x" is legal (even
though "lindex $x 0" is the correct argument order). Worse, the wrong form
_returns something that seems reasonable without error_. In this case what it
_actually_ does is grab the index that it found by magically looking inside
the _list_ ($x) and return one of the values from _the implicit list
containing "0" that was given on the command line_ ; it returns a "0" but not
the "0" that you'd think it does!

While one can argue that each language has "best practices" and intended
usage, the examples above are largely pulled directly from built-in commands
and data types. These are things that people encounter all the time, they are
not caused by any particular TCL programming practice.

------
chengiz
Circa 1999, I wrote a simple reminder script - which I still use - that brings
a popup on the desktop, in like 3 lines of Tcl/Tk using the wish shell. I shed
a tear at how easy it was compared to anything else at the time. I am not even
sure if it's that easy with anything else today.

------
lcargill99
Tcl is one heck of a Swiss-army knife solution. The core team is of the first
order. The best thing is that it's so easy to use pipes to integrate a 'C'/C++
console mode program and control it via stdin/stdout/sockets. That turns out
to be a significant architectural plus - rather than using some MVC C++/Java
type library, you get complete seperation of concern. You don't even have to
integrate it tightly with 'C' code; just use stdin/stdout and wrap a Tcl
package to build a pipe around it.

Tcl might have been _too_ easy. I also recall ESR dismissing it at one point
in favor of Python.

------
js2
My introduction to TCL was in the mid-90's via Expect:

<http://www.nist.gov/el/msid/expect.cfm>

------
cafard
Isn't that what Ousterhout and his students designed Tcl for? I fooled around
some with AOLServer years ago, and have used it with Oracle's "Intelligent
Agent".

But I didn't know how much I liked it until I Googled for "PHP upvar" and
found a forum thread with bunch of people telling some guy that he was a
language fascist for wanting such a thing.

------
lucian1900
Tcl is an interesting beast indeed, since it takes its extreme love for
strings so far, it's actually homoiconic.

~~~
stcredzero
What would you get with the choices set as:

    
    
        - everything is a literal
        - everything is an expression
    

Is there a Tcl variation that's a functional language?

~~~
Avshalom
Forth or Factor perhaps

~~~
stcredzero
That's way off base. Wrong language family.

------
adestefan
Tcl was lua before there was lua. It pops up under the cover as the scripting
language of so many useful tools.

~~~
mhd
What's often not as exposed is that Tcl was node.js before there was node.js
(or, well, Twisted, POE etc.) . It has a pretty powerful event loop (moved out
of Tk into the core language originall, if I remember correctly), and it's
very easy to tie in scripts to add functionality. So it became quite popular
for system that had to communicate with lots of different devices, gathered
information from a lot of sources etc., centralized information processing
hubs. Nevermind that it was very easy to add GUIs to monitor it or enter
information. Back in the days, quite a few companies had pretty huge Tcl-based
infrastructure, and despite the lack of support for "programming in the
large", they were surprisingly easy to decipher and extend.

I still don't know why Tcl had problems entering the WWW age. It started out
pretty well, the aolserver was/is a pretty capable and performant system and
they even had browser plugins (i.e. as a Java rival), but once the plethora of
web services hit the landscape and we all went "Web 2.0", the lack of a proper
CPAN equivalent and the slightly outdated Tk look caused some exodus to more
hip scripting languages. The sad thing is that since quite a while Tcl
overcame all those troubles (modules, packages, native look and feel), but
probably a bit too late.

~~~
blacksqr
I also wish I understood why Tcl was not more widely used in the early days of
the Web. HTML is a string-based protocol, and Tcl is optimized for handling
strings -- it's an absolutely natural fit.

Bugzilla, for example, was originally written in Tcl; but for reasons I have
never been able to discover, it was completely redone in Perl. Anybody here
know why?

~~~
mhd
Well, Tcl enjoyed a bad reputation for a while, mainly due to the
"everything's a string" mantra leading some to believe it's not much use
beyond that, RMS's flame war against it (which is why we're all using Guile
now), and mostly the simple, but slightly odd syntax (expr, array and list
functions).

Then you've got to remember that for a while, Sun owned Tcl. Pretty much the
same period when they were hyping Java…

Also, the core Tcl distribution was still focused on scripting (embedded or
not) and GUI programming with Tk. Modularity back in the days often involved
separate interpreters with added featurs (TclX for example).

Compare that to PHP: Basically the same situation regarding additional
modules, but they had everything related to simple web development in one
package - parsing requests, handling pictures… You could use PHP to do
scripting and even GUIs, and you could use Tcl to do web development. But once
you're written off as a niche language, it's hard to escape that trap.

We've got a whole bunch of interpreted languages out there, but only a few of
them are considered all-purpose languages. Ruby and Python mostly, even Perl
has to fight a bit against the Unix scripting preconceptions.

Tcl wouldn't be the first scripting language of that period "lost". Anyone
remember Pike or Icon?

~~~
protomyth
As for Icon, it might not be such a bad idea for folks to read about its
interesting conditionals.

<http://www.cs.arizona.edu/icon/docs/ipd266.htm>

------
systems
I used to really like Tcl and it have one the nicest communities but I think
it needs two things 1- a CPAN 2- Killer app (and no aolserver or openacs are
not)

------
scrid
I work for a medium-large technology company supplying mission critical
software (very large amounts of money are involved). We use Tcl for the vast
majority of our software. We may head towards Java in the future, but not so
much due to any failings of Tcl, more because it is easier to recruit Java
programmers.

I think the general consensus at our company is that Tcl was the right choice,
although our programmers do occasionally gripe at some Tcl shortcomings.

~~~
bch
@scrid -- curious to hear more.

------
jostmey
I love the TCL foreach loops. TCL is the only language that lets you iterate
through multiple data structures with the same loop. It is actually really
useful. Just try this statement with any other language:

foreach animal { "dog" "cat" "bird" } color { "brown" "black" "red" } { puts
"See the $color $animal?" }

~~~
gruseom
This is fun.

    
    
      (loop :for animal :in '("dog" "cat" "bird")
        :for color :in '("brown" "black" "red")
        :do (format t "See the ~a ~a?~%" color animal))
    
      See the brown dog?
      See the black cat?
      See the red bird?
    

How far can we take the example?

    
    
      (loop :for animal :in '("dog" "cat" "bird")
        :for color :in '("brown" "black" "red")
        :for count :from 2
        :do (format t "See the ~a ~a ~as?~%" count color animal))
    
      See the 2 brown dogs?
      See the 3 black cats?
      See the 4 red birds?
    

How about this?

    
    
      (loop :for animal :in '("dog" "cat" "bird")
        :for color :in '("brown" "black" "red")
        :for count :from 2 :sum count :into total
        :do (format t "See the ~a ~a ~as?~%" count color animal)
        :finally (format t "See all ~a?~%" total))
    
      See the 2 brown dogs?
      See the 3 black cats?
      See the 4 red birds?
      See all 9?
    

Anybody?

~~~
jostmey
Okay, so I am impressed that you can also do this in lisp. I never really paid
any attention to the language. Maybe it is worth checking out.

~~~
gruseom
To be fair, LOOP isn't really Lisp so much as an embedded DSL for loops that
exists because of how easy Lisp makes embedded DSLs.

People either love or hate Common Lisp's LOOP. Lispy types who prefer
recursion often abhor it. I'm a lover.

------
zem
a scheme repl could borrow a leaf from tcl's book by preprocessing everything
you typed in to let you (a) omit the outermost parens and (b) mix () and []
freely. would be an interesting experiment to see if it had a better feel for
this sort of interactive scripting

------
gaius
Tcl is a bloody good language+ but seems to have languished in obscurity. I
can't count the number of times I've heard people in the Python and Ruby (and
Lua and Processing, and node.js, for that matter) communities announce some
wizzy new thing that Tcl had 5 or 10 years earlier. I've never understood why
that is. The problem with the computing community in general is that it can't
see over its own shoulder. Every few years, we reinvent the wheel.

\+ By this I mean you can get a lot done, in not very much code, and maintain
it afterwards, and read and modify other people's code easily.

~~~
haberman
A programming language runtime is a whole package; just because some elements
of previous system designs are reused does _not_ mean that we are "reinventing
the wheel."

To pick Lua (my favorite of the technologies you listed), it has the following
things that Tcl does not have:

    
    
      - strict ANSI C implementation
      - small implementation (15k sloc vs. 110k-160k for Tcl, depending on how you count)
      - a fast implementation, with an even faster JIT
    

If you follow your argument to its logical conclusion then everything is just
a reinvention of Lisp (including Tcl). But we have tools available to us today
(like Lua) that are strictly better than Lisp or Tcl for some use cases.

~~~
pka
An honest question: for which use cases is Lua strictly better than Lisp?

~~~
silentbicycle
Lua is designed specifically to provide a scripting/extension language for
projects in C or C++, or projects where interop with C is key. This is where
it really shines -- where most Lisps expect to be the primary language, but
have FFIs to C for performance and integration reasons, Lua _expects_ to be
used for writing plugins, configuration, and the like. It handles those tasks
well, and otherwise stays out of the way.

While it's good as a standalone language, it's an _outstanding_ extension
language. It's small, trivially portable, and has excellent interop with C.
It's not competition for Lisp in general so much as Emacs Lisp or vimscript,
designed for systems that have a core written in C but need a lot of
customization layered on top. Configuration for window managers, scripting
enemy behavior for game engines written in brutally optimized C++, that kind
of thing. Systems with a "hard and soft layer" architecture
(<http://c2.com/cgi/wiki?AlternateHardAndSoftLayers>). (Incidentally, Tcl was
also designed with this use case in mind.)

That said, if you're using Lua as your primary language but are proficient in
C, you can add a lot of power to it pretty easily. The emphasis on C interop
goes both ways. (Also, the implementation is very intelligently engineered,
and is worth study if you're interested in language design or virtual
machines.)

~~~
pka
Thanks for the comprehensive reply; however, a quick search turned up a couple
of small, portable and embeddable Lisp dialects (Hedgehog, PicoLisp, ECL) that
all seem to target the same niche Lua is apparently designed for. Admittedly,
Lua has probably been developed for a longer period of time, but small Lisp
interpreters shouldn't be very complex, so I guess they are pretty stable.

Lua is probably going to be faster, but one wouldn't exactly use a scripting
language for math heavy stuff etc either.

~~~
silentbicycle
Lua has had a long time to slowly and deliberately evolve, informed by
feedback from a gradually growing group of users.

It's kind of the opposite of Javascript, which went from 0 to release in a few
weeks and had a bunch of design errors become permanent as a result. Lua and
Javascript have a lot in common, and studying Lua may be a good way to see
where Javascript is going in the long term.

Lua is significantly smaller than ECL, and a bit smaller than PicoLisp.
According to sloccount, they weigh in at 432,818 (ECL), 15,018 (PicoLisp), and
14,309 (Lua).

------
yashchandra
I did my first professional programming in Tcl/Tk used by a trading system. It
was awesome and even though most people have not heard of it when I talk to
friends/clients, glad to see this post.

