Hacker News Reader

Comment by tmcb | Hacker News Reader

Tcl is a little gem of programming lore, an ugly duckling story where the ducklings are LISPs instead.

One of the most mind-blowing things to me as a (perpetual) Tcl noob is that when you look at

    proc my_function {x} {
        puts $x
    }

You are lead to believe it is an ordinary C-inspired language with an odd syntax. It took me an embarrassingly long amount of time to realize that

    proc my_other_function "x" "puts \$x"

Is equivalent to the former. Other little oddities like `upvar` are beautiful once you understand them. It has some warts but Tcl has never had the luxury of under the scrutiny that languages like Python or Ruby have had. This is one of the reasons I would really like to see a "modern" version of Tcl more suitable for programming in the large---something that happened to Python 3 almost as an accident, imho.

View on HN

> a "modern" version of Tcl more suitable for programming in the large

Would lua fit that definition? Between game engines, redis, openresty (nginx w/ lua) and others I feel like it fits a similar need (adding code to existing applications).

I've done a fair amount of programming in Lua in the past but it still feels different from Tcl. Back in 2010 I would probably compare Lua to (a better) JavaScript due to its prototype-based nature. JavaScript evolved in a different direction afterwards.

The language itself is very different, but Lua is a replacement for Tcl in the sense that it's a fairly simple and small language that can easily be embedded. i.e. it's about use cases rather than the language design.

I understand what you mean, but this is not the point I was trying to get across with my original comment. Maybe that's the reason why I haven't touched this subject. Although both languages can be easily embedded, the programming experience is still different, and there are still lots of "freestanding" systems in both languages, so the language design comparison still applies.

The command-argument based workflow is so easy to grok as a model that it is intensely loveable. Generating arguments at runtime without messing up your substitutions can trip people up occasionally, but the straightforward nature of how the compiler understands the function is relatively wonderful IMO.

Well, there are classes and objects in there now. They're designed for modelling pretty heavyweight entities like widgets instead of lightweight things like linked lists.

It was a fun OO system to write. It's much more dynamic than it appears to be at first glance; it's first glance looks much like many other languages object systems with a few slight oddities (no new operator, but rather classes have a new method).

Reply on news.ycombinator.com