Glenn Vanderburg

I have used Lisp, Scheme, Prolog (and multiple dialects of each) for extended periods in large projects. Each was a pleasure to work with. They all have their own advantages. I am not sure if there is value in arguing over x feature of one language vs. y of another. As a matter of fact, it was fun to write Prolog interpreters in Lisp, and Lisp interpreters in Prolog, for example. (Many courses / textbooks (used to) present these as side projects to do and the task is simpler than it sounds.) One could say Tcl is really an extension of Lisp or Prolog in its core concepts of syntax, data and program equality, style of interpretation, etc.

I agree wholeheartedly with the last paragraph of Mr. Ousterhout's reply here - and I must say, a smart, classy and almost Tcl-ish way of a jab at its distractors:

http://vanderburg.org/old_pages/Tcl/war/0009.html

I came across Tcl/Tk while doing Motif in a large C-based project. I simply couldn't believe how powerful, simple and succint Tk was compared to Motif (or anything else since). And it ran on Windows, Unix, Linux and Mac OS, to boot. It was too late for that project to switch, but all my other projects have used Tk if they ever needed a UI.

Similarly with Tcl. I still think the best introduction is Mr. Ousterhout's original Tcl/Tk book. It stands as one of the best language books on my shelf. Combined with Tk, one can put together a working application prototype in no time.

Of course, this was eons ago. Nowadays, Tcl…

> There are kinds of making other than engineering.

True enough. But the piece argues (I am the author) that software engineering is not making, it's designing.

> Carpentry is not engineering. Cooking is not engineering.

Carpentry is a craft, but furniture design can be engineering. Cooking dinner is a craft, but designing the menu and production process for a chain restaurant is definitely engineering.

> Before you can declare that making software is (or can be) engineering, you have to be able to explain why those things aren't.

My position is that they are (or can be), when analysed in an analogous way. You've asserted that they self-evidently are not, even in the absence of a rationale for why. I simply don't agree.

> My tentative theory is that engineering has rigorous ways to check whether a design will work before it is manufactured

I appreciate you sharing your theory! However, I believe you'll find the history of engineering has largely been one of people doing stuff first and then later finding ways to reduce the cost by doing analysis. I highly recommend watching one of Glenn Vanderburg's "Real Software Engineering" talks for a more in-depth treatment of that subject: http://vanderburg.org/speaking/

> A mechanical engineer might need to draw a detailed design, but can then check it rigorously with finite element methods.

That's great, but finite element analysis won't tell you e.g. where water might pool causing a structure to deteriorate, or that a…

> TCL

I actually know the answer to that one!

> The principal lesson of Emacs is that a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that!

> Another lesson from Emacs is that the way to make sure an extension facility is really flexible is to use it to write a large portion of the ordinary released system. If you try to do that with Tcl, you will encounter its limitations.

> Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow.

From Why you should not use Tcl by Richard Stallman [1].

[1] https://vanderburg.org/old_pages/Tcl/war/0000.html

Per http://vanderburg.org/old_pages/Tcl/war/0000.html

Stallman's argument at the time was:

"a language for extensions should... be a real programming language, designed for writing and maintaining substantial programs...

The first Emacs used a string-processing language, TECO, which was inadequate. We made it serve, but it kept getting in our way. It made maintenance harder, and it made extensions harder to write...

Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow. Tcl is ok for writing small programs, but when you push it beyond that, it becomes insufficient.

Tcl has a peculiar syntax that appeals to hackers because of its simplicity. But Tcl syntax seems strange to most users."

"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."

That's a very different approach. This is closer to using Lisp to generate C, whereas Lua+C usually involves a multilayered design: you write your engine in C or C++, write or generate a simple Lua wrapper for its API, and then the do logic in Lua, moving hotspots to C as necessary. (http://c2.com/cgi/wiki?AlternateHardAndSoftLayers, as they say.) As a bonus, the cross-language boundaries are often natural seams for containing complexity.

TCL was also designed with this style of programming in mind, and John Ousterhout describes it pretty well (http://www.vanderburg.org/OldPages/Tcl/war/0009.html).

FWIW, LuaJIT is only available for i386 at the moment, though amd64 porting is in progress. Standard Lua is still pretty fast, and it's great for prototyping. It's a good idea to get algorithms and overall design right before spending much time on low-level tuning.