Why you should not use Tcl (1994)
vanderburg.org
vanderburg.org
TCL is an excellent language, and compared to the wildness that is the JS ecosystem, it's much more concise and elegant.
>Not a single person here would choose it over python or anything else if they were making the decision today.
You'd be surprised. I would like to be able to use it more.
Tcl is not elegant, it's simplistic. Just look at the ugly workarounds for language shortcomings like upvar. I'm not saying javascript is elegant (is anyone?) but it's less unwieldy, quicker to learn and immediately understandable to a c coder.
But people who are willing to take a less conventional approach may find that it opens up cleaner and more elegant ways of doing things. For example, upvar is not just a workaround - it can support meta-programming techniques which are not even possible in e.g. Python.
The "Tcl way" is to have a minimal core which just supports running commands and connecting them together. Everything else is implemented as commands, including the control constructs, and any command can be redefined. This flexibility does of course allow things to go wrong in ways that could not happen in a more restrictive language. But it also provides an adaptability that is hard to give up once you get used to it.
The Lisp-like language is Guile, an implementation of Scheme. Was the "more traditional" language ever defined or implemented?
Vala is also not relevant.
What the GNU's statement above is about is an embedded scripting language for GUI application extensibility (to write things like editor plugins in, to provide scripting for a GUI app like GIMP, etc.).
GtkBuilder is a UI builder for Gtk apps with a XML-based serialization format. It solves a totally different problem.
Vala was an attempt to replace C and have a "modern-ish" language with first class GObject support. Again, solving a totally different problem.
But as always, Perl takes the joke too far, by allowing variables to have incompatible string and integer representations simultaneously ("dual variables" in Perlspeak). For example, the variable $! is equivalent to C's `errno` when evaluated as an integer, but equivalent to `strerror(errno)` when evaluated as a string.
> Doesn't Python essentially provide what RMS wants? Why doesn't GNU just adopt Python as its defacto language?
Does anyone have an answer to this? (I scanned the first dozen or so messages, but did not find one.)
% expr {"a" eq "b"}
0
% expr {1 eq 1}
1
% expr {1 eq "1"}
1 % expr {1 == "1"}
1Javascript:
console.log("1"==1)
True
print "1"==1;
1
<?php
echo "1"==1;
?>
1 Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> "1"==1
False
I also find that in Javascript:
>>typeof(1)
"number"
>>typeof("1")
"string"
>>> gettype("1")
=> "string"
>>> gettype(1)
=> "integer"
System.out.println(1 == "1");
error: incomparable types: int and StringIf you look at today's language landscape, you have langauges like C, C++, Java etc occupying the "serious" niche and languages like Python etc occupying the "glue" niche ( although sometimes these languages do exchange roles ). The "glue" languages that succeeded did have support for arrays etc.
I think both parties have been proven right, at least partially.
I like RMS for what he's done for Free Software, but I rarely find myself agreeing with him wholeheartedly on technical questions.
For what it's worth, Tcl has had support for O(1) array indexing since 8.0 in 1997. That's because starting with 8.0, Tcl values had both an efficient internal representation and an external string representation. It's not a perfect solution, because it's not always transparent when (inefficient) transformations between representations take place, but it's definitely possible.
OK, I imagine it. What would be the problem?
He is correct in that Tcl's niche is too narrow to serve as a universal scripting language (though that, as John Ousterhout pointed out, wasn't really Tcl's goal to begin with).
But he was also mistaken (I think) in thinking that a universal scripting language would be both possible and a good idea.
In practice, needs and preferences are too diverse for one scripting language to serve them all equally well; also, language competition is a good idea.
The biggest problem that people had with Stallman's argument, I think, was that he was pushing the immature GEL/Guile as a replacement (and it would remain immature for years to come), while Tcl at the very least did its job well.
Tcl has arguably been as successful as Guile, but neither has exhibited longevity; both have been in decline for many years. Emacs has switched to Guile (maybe?), and Guile has gotten a major overhaul this decade (lots of smart people with a lot of experience like Scheme, so not a big surprise), but the other "high profile" projects using it are really not very high profile at all (Guix, Gnucash, GDB, all pretty niche projects with limited user bases).
Tcl got a lot of effort put into it by pretty big companies for a while, and it's actually a pretty good language, IMHO. It has significant limits, sure, but so did Guile for a long time. And real software has been built with both.
It almost feels like a personal vendetta rather than any significant technical reason, even though it's written as though, "Obviously, we should choose the technically superior extension language that, by the way, does not yet exist in a fully usable form."
Was there a licensing beef with Tcl, as well, or is it purely that RMS just really wanted everything to use Scheme?
Guile does this with bravura.
This avoids the Global Interpreter Lock problem that plagues Python. How does Guile handle that?
If you don't cross the C barrier again from your scheme code you can even use something like guile-fibers for Concurrent ML-like parallelism.
Within a context you can run multiple coroutines but these are all run on the same thread and are cooperative.
It doesn't natively support sharing across multiple OS threads.
Seems like in any case, if I were using any of them in a threaded program, I'd want to isolate them from threads as much as possible. One of these days, in my Copious Free Time(tm), I'll take the time to actually look at an implementation to see how people have handled this problem. I wonder if any reasonably complete game engines use Guile, for comparison...
That applies only if you are executing guile code in parallel in the same interpreter and environment (or asynchronously accessing interpreter data) which is impossible in insert_other_embeddable_language_here.
You don't have to use embedded guile like that.
From my experience: if you want to embed a language and only need it in a single thread, it is just as easy to use lua. If you want several interpreters in isolated threads without any communication Lua is easily the simplest solution.
But if you need communication between multiple embedded language threads or interpreters you are better of with guile or TCL depending on what threading model you prefer.