Hacker News new | past | comments | ask | show | jobs | submit login

Guile was RMS' counter-argument to tcl as an extension language back in the days, right? And wasn't it supposed to be a possible elisp replacement, too?

It would be very nice if someone could summarize the current state of the language, i.e. why one would use it instead of Racket or Gambit.




The ELisp frontend of Guile 2.0 will allow a gradual migration from ELisp to Scheme by integrating Guile into Emacs and letting it execute code in both languages. I can't wait for that to happen.

Guile hacker Andy Wingo (wingo on HN, hi!) gave a talk about this and other recent Guile developments, which I summarized (and linked) here: http://jugglingbits.wordpress.com/2010/04/19/andy-wingo-rece...


As far as history goes, http://www.gnu.org/software/guile/manual/html_node/History.h... is where it's at.


Yeah, Tcl had/has an "evil" BSD license.


Surprisingly enough, this was not among the reasons cited in RMS's original "Why you should not use Tcl" post: http://www.vanderburg.org/OldPages/Tcl/war/0000.html


The only reasons were [1]:

-Tcl is not Lisp.

-At that time Tcl was being developed by an Evil company: Sun Microsystems.

At the time, TCL was being pushed heavily for this purpose. I had a very low opinion of TCL, basically because it wasn't Lisp. It looks a tiny bit like Lisp, but semantically it isn't, and it's not as clean. Then someone showed me an ad where Sun was trying to hire somebody to work on TCL to make it the “de-facto standard extension language” of the world. And I thought, “We've got to stop that from happening.” So we started to make Scheme the standard extensibility language for GNU. Not Common Lisp, because it was too large. The idea was that we would have a Scheme interpreter designed to be linked into applications in the same way TCL was linked into applications. We would then recommend that as the preferred extensibility package for all GNU programs.

[1]http://www.gnu.org/gnu/rms-lisp.html


> The only reasons were [...]

This is not true. Isn't it obvious that "basically because it wasn't Lisp" is shorthand for "because of a bunch of respects in which it differs from Lisp and Lisp is better"?

Note that the comment you're replying to links to RMS's more complete account of "why you should not use Tcl", which lists a number of respects in which he considers that Tcl is not suitable as an extension language. For instance: "It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow." And: "Tcl has a peculiar syntax that appeals to hackers because of its simplicity. But Tcl syntax seems strange to most users." (Yes, it is kinda ironic that he said that and then proposed using Scheme. But, as he said at the time, the intention was to have two syntaxes with the same semantics, one of them Lispy and one more conventionally "algebraic".)

RMS also did not say that "Tcl was being developed by an Evil company", nor that that was a reason for discouraging its use. He said: He didn't like Tcl; Sun were trying to get Tcl made the de facto standard extension language; he wanted to make sure that didn't happen. There's no suggestion at all that he wanted to stop it happening because Sun were evil.


Which is sad really. Tcl is a nice language and the community is great.


Have you seen multiple kLOC tcl apps? I have, and it is not pretty :)

Thing about extension languages is that they tend to be nice languages to write code, so people write a lot of code in them, and suddenly your app is 95% written in the extension language. Scheme is the language I know that grows best from a simple extension language to a full-fledged mature programming language.


Tcl has been improved a lot since the Tcl War (17 years ago!) including namespaces, module/package system, a native OO, a sane thread support, and Dicts. I am not sure if it is still true that Tcl doesn't scale well.

By the way I wrote a toy, buggy and ugly scheme implementation in pure Tcl a year ago: http://wiki.tcl.tk/25512


If it's a large tcl "app", then quite often that's the first mistake. I've seen large Tcl systems which work pretty well. A combination of different applications, cron jobs, scripts etc., with some C/C++ libraries for integration and performance-critical things. With the added benefit of having a pretty decent graphical toolkit on top. Won't be the winner of a GUI beauty pageant, but it works.

And most of those systems were pretty old, so it's not like you had a lot of better options back in the days. Tcl was pretty awesome in the mid-90s.

Most Java programs that replaced those enterprise tcl systems were a lot worse than their predecessors.

For a new project? Maybe, maybe not.


Yes, unfortunately, nobody really uses either one in the grand scheme of languages.


Yes, and now we have no "de-facto standard extension language". Thanks RMS!


Ousterhout's reply is worth reading:

http://www.vanderburg.org/OldPages/Tcl/war/0009.html

I can't find where I'd seen it, but RMS certainly wasn't really keen on the idea of a BSD-licensed system becoming popular, either.


"Ousterhout's reply is worth reading:

http://www.vanderburg.org/OldPages/Tcl/war/0009.html

An excerpt, which (imo) should be quoted more often

"Language designers love to argue about why this language or that language must be better or worse a priori, but none of these arguments really matter a lot. Ultimately all language issues get settled when users vote with their feet. If Tcl makes people more productive then they will use it; when some other language comes along that is better (or if it is here already), then people will switch to that language. This is The Law, and it is good. The Law says to me that Scheme (or any other Lisp dialect) is probably not the "right" language: too many people have voted with their feet over the last 30 years. I encourage all Tcl dis-believers to produce the "right" language(s), make them publically available, and let them be judged according to The Law."


> when some other language comes along that is better (or if it is here already), then people will switch to that language.

That part is actually not entirely true. Languages have positive network externalities, as well as some very serious lock-in (see: Cobol) and switching costs.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: