The only benefit you claim for Tcl that doesn't also apply to scheme
is #3. You would like to type...
func arg1 arg2
(func arg2 arg2)
Ok, a minor but perhaps valid point if you want dumb users to use it
like a shell.
I've often thought that if I ever wrote a Scheme shell, I would
provide an option to put in a line prefix and suffix to lines just to
satisfy this point. You might do something like this...
> (write 'foobar)
> (set! prefix "(")
(> set! suffix ")")
(&)> write 'foobar
As you see, by setting the prefix and suffix variables a "(" and ")"
would automatically be prepended and appended to each line you
type. The prompt would change to "(&)" to remind you that this is in
effect. If you wanted a shell like a Unix shell that runs other
processes you might change it to "(run &)" which would automatically
call the run procedure on anything you type in. This would allow you
to type ls -l at the prompt and have it work.
firstname.lastname@example.org (Will Duquette) writes:
> Here's what Tcl/Tk buys *me*.
> I have no interest in writing large programs solely in Tcl to Tcl/Tk.
> There are indeed better languages out there for that purpose.
> However, in my work we have a developed a number of APIs for a variety
> of obscure tasks. These are generally coded as C libraries. By
> writing Tcl extensions for these libraries, I get the following
> practical advantages:
> 1. I can build a Tclsh with my own extensions.
> #1 is crucial. The libraries I work with use threads. You can't
> dynamically load a threaded library into a program that's compiled to
> be single-threaded and have it work--not on Solaris at least. If I
> could not build my own executable, Tcl would be useless to me.
> 2. I can write simple programs using these libraries without
> pulling out the compiler, writing Makefiles, and so forth.
> This is particularly useful for testing.
> Many languages can provide this, I'm sure.
> 3. I can exercise these libraries interactively, one command at a
> time, in a shell-like environment.
> Proponents of Scheme and similar languages have pointed out
> that they can do this in their language as well. And yet,
> psychologically anyway, Tcl feels simpler to me. I'd rather
> myfunc arg1 arg2
> (myfunc arg1 arg2)
> Moreover, I'd rather tell users of my extended shell to type
> the former rather than the latter. I guess that's the issue:
> If you want to use a Tcl-based shell as a means of typing
> commands, you can ignore the rest of Tcl; the commands look
> like the kinds of commands you might type into any other
> command-line oriented program.
> 4. I'm using a language with sufficient popular support that I
> know I can get help if I need it. Tcl may never be the most
> popular language in the world, but it's popular enough that
> it's not going to vanish overnight, either.
> Go look at
> sometime, and see how many links they list for each language.
> This is at least a rough measure of the current amount of
> public interest in each language. I don't claim it measures
> usage, of course.
> You'll notice that I've made no arguments about Tcl as a *language*.
> Pragmatically speaking, though, it enables me to get my job done
> easily, efficiently, and well.