
Where Tcl and Tk Went Wrong - davidw
http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong
======
antirez
Btw, I would like to introduce this very related argument at this point.

At some point Redis will get scripting. It will take time, we are just
entering 2.0 feature freeze, and later the priority will be redis-cluster, but
we'll get scripting soon or later probably. Now I happen to be the original
author of Jim, a small embeddable but fast enough (using an objects
specialization technique) Tcl implementation. It's just a single .c file with
10k lines of C that is albe to run many Tcl programs unmodified if they don't
tak with the "outside world" (that is no files, no sockets, no everything). It
is really designed to be embedded, check it here:

<http://repo.or.cz/w/jimtcl.git>

Jim Tcl is actively developed, and used in OpenOCD
(<http://www.amontec.com/openocd/doc/About-JIM_002dTcl.html>), in eCos
environments and so forth.

But what I think is that users may get upset if I don't use a different
language. The problem is, I don't know any single-c-file easy to embed, fast
enough, interpreter for a language that will be more welcomed (I would like
Javascript, for instance).

Also Tcl happens to be perfect to write Redis scripts, as they will look like
commands issued with the redis-cli, like that:

    
    
        register-command GETDEL key {
            set result [GET $key]
            DEL $key
            bulk-reply $result
        }
    

I wonder what will happen, if I'll go ahead or if there will be an
alternative. I can't see how Lua is more elegant or better than Tcl, and while
not hard to embed definitely not as simple and self-contained as Jim Tcl is.
Also Lua is far from being a well known language.

I really think that the right thing to do is to embed Jim Tcl, but there is a
cultural barrier preventing me from doing this.

Btw, Lua is absolutely the best among all the JS / Ruby / Python / ...
implementation I saw.

Without configure, and with a "Make ansi" target that is suitable to be used
with the zero-configuration environment of Redis. So actually if it will not
be Jim, it will probably be Lua.

~~~
andrewcooke
i am pretty sure the number of _new_ uses of lua way exceeds the number of
_new_ uses of tcl, and i suspect the number of deployed lua instances exceeds
tcl instances (there are a lot of games out there...).

i think you being author of jim is biasing you hugely in this. lua is the
obvious solution here, not tcl.

~~~
antirez
yep this is a good point. But indeed I don't like Lua nor Tcl too much for
this task. I would simply love to have an easy to embed Javascript
implementation, but that does not exist.

If nothing will change under the sun I think I'll use Lua even if I don't like
the language too much, but sounds like the sanest thing to do.

~~~
silentbicycle
At a language design level, what in Javascript do you prefer to Lua? I know
Javascript has more familiarity (no doubt due to this "web" thing I keep
hearing so much about), but Lua seems to me like a far cleaner iteration of
the same kind of language. Circumstance froze Javascript's design before it
could have some major issues worked out, while Lua was able to develop more
organically. They have a lot in common, though, particularly what Crockford
calls JS's "good parts".

------
Aegean
To summarize in two words: Its ugly.

Tcl syntax is ugly, tk GUI's are ugly and look old.

Also, Python is the winner for me because it's syntax resembles C but is a lot
easier to write.

~~~
antirez
Actually if you look at the syntax from a mathematical point of view, Tcl
synax is much simpler.

Also behind the clean Python look (that almost seems pseudo code in simple
programs) the Python semantic is really complex compared to the one of Ruby
for instance.

~~~
moe
_Python semantic is really complex compared to the one of Ruby for instance._

Wrong. The opposite is true. See their respective grammar dependency graphs.

Ruby: <http://farm1.static.flickr.com/93/280661836_e477a01932_o.jpg>

Python: <http://farm1.static.flickr.com/80/281055485_cc5069b990_o.jpg>

(Source <http://laurentszyster.be/blog/jruby-vs-cpython/>)

~~~
fhars
That doesn't refute the statement that the semantics behind the simple looks
of python are complex. All that the simple grammar shows is that python looks
simple. _That_ was a given.

~~~
moe
I'm not sure what you mean, can you elaborate?

Python is specifically built around the concept of "One and only one way to do
it". (Source: <http://www.python.org/dev/peps/pep-0020/>)

Ruby is specifically built around the perl motto of "There's more than one way
to do it". (Source: <http://www.artima.com/intv/ruby3.html>)

Claiming that python semantics were more complex than ruby semantics just
makes no sense to me when the difference is even clearly stated in their
respective design goals.

~~~
fhars
The point is that the diagrams you linked to don't tell you anything about the
semantics. For example, according to the python diagram, there is absolutely
no difference except for the parameter definition between what is allowed in a
normal function definition and a lambda expression. The subtlety that a lambda
can only be a single line is lurking in some surprising and dark corner of the
language semantics. That is what makes a language difficult: arbitrary and
subtle differences between things that should be the same.

Not that the three sligthly different types of callable
objects/blocks/watchamaycallits in ruby are a shining example of elegant
design. I don't know if ruby or python is simpler (I don't care, scala is even
more baroque around the corners than both and I still prefer it), it is just
that your syntax diagramms add nothing to a discussion about semantics.

~~~
dalke
"according to the python diagram, there is absolutely no difference except for
the parameter definition between what is allowed in a normal function
definition and a lambda expression"

They both point to the parameter definition, but lambda sits under "test" and
refers back to "test" while the normal function definition sits under
"compound_stmt" and also points to "suite."

Those are rather big differences, and reflect rather well that while perhaps
semantically they are similar, syntactically speaking they are very different.

------
sutro
A very well-written, thoughtful analysis, relevant to all languages and to the
high-tech hype cycle in general.

~~~
swannodette
I read the article more as "Things to consider if you don't want to run your
really great technology into the ground". It shows how a community that has a
great thing can sit on it's laurels and let the rest of the world pass them
by.

It happened to Common Lisp. I personally think PLT Scheme rebooting itself as
Racket is just the kind of break-with-the-past mentality more projects should
embrace.

------
mansr
My main issue with tcl is the "everything is a string" approach and the
resulting quoting hell.

------
xtho
With respect to the language: having strings as the only data structure
(everything is a string) and the developers stance on OOP (we don't need that)
didn't help either and made way for python & ruby. With respect to the WWW,
there was ACS/OpenACS, which even the author doesn't mention.

------
chipsy
Tcl is one that I kind of want to learn but can't find any excuse for. I came
to the party too late, I guess - Python does just as well for my scripting
tasks, and "EIAS" scares me away from trying it for a substantial application.

~~~
davidw
The EIAS thing is not really _that_ bad in practice, since you get lists and
hashes and numbers, which can be used to build a whole lot of things. You also
have namespaces to help organize code, and an OO system is on the way.

The things that come to mind where Tcl might be worth trying as opposed to
Python are fairly niche:

* Tcl still handles threads a bit better than Python, IMO.

* "Starkits" are kind of cool if you want to distribute a single executable. Don't know what Python has in that department or how easy it is to use. <http://wiki.tcl.tk/3661> . To tell the truth, though, "distributing" a web app is way easier than even starkits.

* Tcl, for some things, might still make a better "embedded" language because of its extensive C API.

That said though, Tcl isn't _too_ different in its "ecological niche" from
Python/Ruby/Perl, so I think if you know one of those, you'd probably be
better off with something "further afield" like Erlang or Scala.

BTW, some shoots off the Tcl tree are worth looking at if you want to play
around with a relatively smaller codebase: antirez' Jim Interpreter, at
<http://jim.berlios.de/> and my own Hecl, at <http://www.hecl.org>

