Tcl Static Prime: experimental compiler for Tcl that produces C or Java code | Hacker News Reader

Tcl Static Prime: experimental compiler for Tcl that produces C or Java code

github.com

61 pointsblacksqr40 comments

No one has mentioned the very Lisp-like nature of Tcl, and that includes the property of homoiconicity. This makes many programming patterns easy to implement in Tcl. Increasingly Scheme/Lispy features have been added, which makes it even more appealing.

Indeed the language is notable for great flexibility and adaptability, nearly every aspect can be modified to the point it resembles completely different programming languages.

Way back in the 90's I started using Tcl/Tk because it was easy to create GUI applications I needed for my business. Over the years I've employed it for many purposes, including client/server apps that today we might use Websockets to implement.

Tcl's stability is valuable. A couple of days ago, I was maintaining a "legacy" server which runs a key business app written in Tcl. The most recent timestamp of the Tcl source was >10 years old, and running glitch free for even longer. Sure doing it today I might do it differently, but I can't complain about "bang for the buck".

I didn't believe I'd see the day when a larger Tcl project reaches HN front page. This looks really exciting and ambitious. John Ousterhout mentioned in one of the interviews that he regrets he didn't manage to produce the Tcl compiler while working in Sun.

While in my day to day work I don't feel the need for the compiler (starkits are good enough) it might attract more performance concerned people to this powerful but forgotten language.

For me returning to Tcl is always an immense pleasure. This is what it gives out of the box:

  - convenience of bash
  - power and elegance of Lisp
  - self-containing no-dependency nature of Go
  - clarity of Python
  - probably unique for the entire industry reliable cross-platform GUI toolkit
  - simplicity of Dodecalogue

What Tcl is missing:

- good handle on concurrency in bigger projects (with scale, events lead to spaghetti or mega state machines). I tried to address this one myself by developing Golang/CSP style concurrency library https://github.com/securitykiss-com/csp

- large community

This is completely awesome. Tcl has been around for quite a while and is very mature although it lacks the massive libs and support of Python it's still my language of choice when it comes to data science.

To anyone who upvoted this, can you relate why one may consider using TCL today? What are it's strengths and weaknesses compared to other 'common' scripting languages ie python, lua, ruby, ... ? And why is translation and static compilation desireable?

Compilation is desirable for increased performance. See submission link for statistics.

As for why use Tcl, see: http://wiki.tcl.tk/what%20is%20tcl

TCL is probably the only major scripting language that has rock solid thread and concurrency (events, too) support.

As a matter of opinion, the embedding api is cleaner than most alternatives.

Unfortunately, I'm not sure how "major" it's can be considered these days. Perl struggles with maintaining that title (if it hasn't already lost it for the majority of people), and my impression has always been that Perl is quite a bit more popular than TCL. That impression could be quite off though, as programming language usage measurements are always rife with controversy.

Legacy reasons and existing code base works. This might offered a migration path for those who wish.

Though the TCL/TK combo for some has always been appealing and simple enough to work and come across it in area's for comm's to nice display interface and medical data processings. Cloverleaf being worth a mention and that is written in TCL and used that near on 20 years ago for processing medical important things from banks of modems - it worked. Sure could use something else but that is true of everything. Still TCL been around a while, back in a time in which perl was popular.

I haven't used tcl for 20 years and probably will never use it again, but upvoted on grounds of 'hey, that looks cool'.

Hello, Redis test suite is written in Tcl because for this kind of stuff Tcl is very good. A few reasons:

1. It is very easy to write DSLs in Tcl, you can turn it into a radically different on-purpose language. If you think Ruby is good at DSLs, try Tcl.

2. It has good I/O functions and is event-driven by default. The Redis test for example uses a server-client model using the event driven support of Tcl.

3. It has excellent ways to interact with other Unix commands, see for example the [exec] command: http://www.tcl.tk/man/tcl8.5/TclCmd/exec.htm

4. It has automatic memory management but does not use a garbage collector, reference counting is used instead. This means that the memory footprint is small and there are no GC pauses. Moreover the interpreter is extremely stable.

There are more reasons for using Tcl in certain projects, the above are the reasons I'm using it for Redis testing.

Ha! I would have expected to see Jim there. Do some of these strengths not apply ? I have heard rumors about Tcl 9.0 and Jim merging, any opinion on that. Would love to hear how Jim came about in the first place.

The use of reference counting is suddenly really compelling for me to try out Tcl a bit. I've been looking for a good reference-counted language (other than Perl, which is where much of my programming background originated), and Tcl's looking more and more like a good fit.

CPython is a good reference counted language. So are J/K/A+/Kona.

(PyPy and Jython are NOT reference counted - so saying "Python is reference counted" is wrong)

In my case, EDA and FPGA stuff. Tools like Mentor Graphic Modelsim and Xilinx Vivado (this one is quite recent by EDA standards) use TCL as both a console interface and scripting language, to the point that configuration files are also written in TCL.

Knowing TCL enables me not only tool automation, but a huge deal of personalization and setup, by allowing me to access data and internal functions of the systems. Modelsim, for example, has its whole GUI made in TCL/TK and I can easily create new GUI elements in TCL to help me debugging.

Also, TCL is a very interesting language by itself. Ok, not modern or cool, but much more interesting than most people think of it. This blog post [1] tries to make this point, and was already discussed in HN [2].

[1] http://antirez.com/articoli/tclmisunderstood.html [2] https://news.ycombinator.com/item?id=7069642

I'm familiar with parts of TCL, but I still can't arrive at a good answer for those questions.

It has a unique (wild and strange) feature called upvar that I haven't seen in python or lua. You "use" it to reference a previous frame in your call stack.

You can use upvar and uplevel to write control structures (if, while, that kind of thing) in Tcl itself. For instance, Tcl itself does not have a do ... while loop, but you can write one that will look like it's part of the language.

Also: it's Tcl, by the way, not TCL.

Lua has something called an "upvalue" but it's a completely different thing.

Lobster[0] also lets you write do/while loops and new conditionals, but does that in a different way that does not require upvar/uplevel, and is IMHO cleaner. (It is less capable in general, but captures 99% of the use cases that I've seen for upvar/uplevel in Tcl)

It is indeed Tcl, but it IS an acronym for "Tool Command Language", or at least started out that way.

[0] http://strlen.com/lobster

The acronym is true but the community uses Tcl now and has for quite a while.

Stuff like this intrigues me, from a linguistic perspective.

I'm really curious what lead to the community settling on this. You'll occasionally see all-lowercase in some projects thanks to the fact that *nix commands are usually all-lowercase, but title-casing an acronym is weird.

If I had to hazard a guess, I'd say it's because "Tcl" is typically pronounced as a word ("tickle"), so it got de-acronymized like "radar" or "scuba". Then again, nobody writes SCSI as Scsi. I'd love to study this some more...

My guess: it's kind of a fashion thing. FORTRAN and COBOL and FORTH and whatnot are a bit old fashioned looking.

https://en.wikipedia.org/wiki/Fortran#Naming

You can actually reference any frame in the stack all the way to the top. And it has a companion "uplevel" which allows you to evaluate code on any of those stack frames. But usually both are used only with the previous stack frame. This allows TCL functions to mostly behave like macros.

manipualting stack is exhilarating once you understand it. I learned clojure way after my tcl so now in retrospect I think of it as a macro system - keep it hygenic!

TCL is still a mainstay of IC (Integrated Circuit) development design and test. It was originally developed for that purpose, and it's deeply entrenched.

I personally think it should die a very quick (honorable) death.

> I personally think it should die a very quick (honorable) death.

Mind elaborating?

While TCL does a good job gluing together IC tools, there are many languages that are much more expressive, powerful, and even just as simple (with good DSL support), with larger communities and more modules to choose from that aren't being used because TCL is. TCL has always seemed to me to be the incumbent that prevented uses of more modern languages.

I can't think of one thing TCL does better than any of the languages that come after it that warrants keeping it around, outside of super easy C bindings and some light metaprogramming capability.

A lack of good resources on TCL also leads to people learning it all sorts of ways, and writing all sorts of (often buggy) code with it. Maybe that's just symptomatic of the companies at which I've used TCL, but I think it's pretty clear that there are way more good resources on something like lisp or python than there are on TCL (I mention lisp because if you squint and replace some [ ]s with ( )s, TCL looks almost like lisp)

A lot of my reasons aren't quite concrete, but in short, I think using an almost-dead language like TCL leads to stagnation of a code base. People aren't pushing boundaries, doing new things in TCL. There's definitely nothing wrong with having a no-surprises go-to language that just gets stuff done, but I just don't personally find TCL stimulating.

Maybe I'm just too much of a new-shiny-language hipster

> I personally think it should die a very quick (honorable) death.

No, I would disagree. I like Tcl. I like using Tcl. The community is very good as well. The Tcl maintainers are really good at what they do for Tcl and the community.

There is no reason IMO for it to die at all.

These sound like things that could easily be said of any programming language -- anything in particular that makes TCL stand out? Pretty much all the useful features of TCL already exist in other modern (better) languages...

Why do you like TCL more than any other language (ex. Python, Lisp, etc)?

It's very simple to create an executable for Windows with Freewrap so that your users don't need anything pre-installed.

Interesting article about the "Tcl experience" here: http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html

I love how simple the language is. Quick and easy to learn, small footprint, embeddable. For quite a while I used to prototype simple web services in Tcl, then convert to C for speed. The Tcl versions were so much easier to write, adapt, and debug, and had more features, because in C at some point I thought, meh, don't really need this...

You can't be a serious IRC bot hacker without knowing TCL ;)

Author here, happy to answer any questions.

For this question: I've used Tcl for 20+ years for various things, database, web, monitoring, prototyping - basically anything you'd use any other scripting language, it just happens to fit me well (I also use Python for some things). Tcl is not without its warts, but positives far out weigh any negatives. Translation to C or Java is done primarily for performance, other use cases would be for IP protections.

TCL interpreter is really easy to embed into your own project and then you get impressive scripting for that small effort. You can also extend it pretty easily. A lot of people say it's hackish, but it's really not that bad if you sort of follow this mindset like you are ping ponging between what's in charge - your code or the interpreter in turns.

Is there any good documentation out there on embedding Tcl? The current page about it on the Tcl site (which itself is a maze of twisty passages) is mostly dedicated to trying to convince you not to embed it, and then there's some broken links to other sites.

There was some papers and a book (sorry can't remember anymore which one, there used to be more out there about TCL) I used but mostly looked at the expect source as an example.

Tcl and the Tk Toolkit by J. Osterhout is an old reference but very useful for getting started with the C API to Tcl including embedding an interpreter. The last 1/3rd of the book is on writing Tcl applications in C.

Also look at the the source files for the Tcl (tclsh) or Tk (wish) shells. They are fairly concise.

There is also an updated version out (with my name on the cover, to boot:-)

http://amzn.to/1LQrLTK

Although even that is not super recent.

Tcl's C API is very pleasant to work with, and its C code is a good read - except for the regex stuff, which are the first few files you'd see in an alphabetical listing.

Yep that was the book I was lent.

There is also the lighter weight JimTcl [1] clone which is suitable for more resource constrained systems.

[1] http://jim.tcl.tk/index.html/doc/www/www/index.html

Python is excellent, although I'd still give Tcl a small edge over Python for quick use. I find event driven, sockets and serial ports a bit more tedious with Python.

The suite of first class objects in Tcl is very appropriate. But I have more experience with Tcl, so there's another bias.

There's a way to do state machine patterns with Tcl that I've not seen in any other language - arrays of code-strings indexed by state - you "eval $fsm($state)". I'm sure there are other languages that do this, so observer bias. That, with event-driven socket/serial port/file I/O is where it shines the most.

The strengths are really the Tcl core team, who have all been at it for a long time, have excellent backgrounds and don't ship a lot of problems. IMO, Tcl's "obscurity" ( relative to Perl ) was a saving grace - Tcl moved at a more deliberate pace. I also tend to trust my own Tcl code more than things developed in other ways - I've used it to find countless bugs in other peoples' stacks and libraries.

I have not used static compilation, so I'll withhold comment. There is freewrap at least for making a standalone Tcl application. It basically embeds a Tcl interpreter with the "executable".

Also - I think the way to learn Tcl is to use the Brent Welch book.

I am curious about this because different camps scream about its "everything is a stringish thing casted as needed" type of language. (I know that is an oversimplification, but hear me out.)

I wonder how that translates, at all or well, to compiling languages like Java.

Will have to read on. Sounds neat!

Reply on news.ycombinator.com