In article <··········@roar.cs.utexas.edu> ······@cs.utexas.edu (Paul
Wilson) writes:
In article <··········@srv13s4.cas.org>, <·······@cas.org> wrote:
>
>I know that I've not tried either of these. In fact, I've never
>seen an app that embedded either of these. however, I've seen
>several hundred that embedded Tcl - including the latest version of
>nvi. Since I prefer to use apps that share the same embedded language
>when possible, use of tcl works for me at this time.
Larry,
This seems like the only reasonable argument that people have raised
and one I have some grudging respect for.
<snip>
Everyone else seems to think it would be nice, including many Tcl users
who write whole apps, or most of their apps, in Tcl.
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
type
myfunc arg1 arg2
than
(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
"http://www.yahoo.com/Computers_and_Internet/Programming_Languages/"
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.
--
--------------------------------------------------------------------------
Will Duquette, JPL | ··················@jpl.nasa.gov
But I speak only | ····@bean.jpl.nasa.gov
for myself. | It's amazing what you can do with the right tools.
····@peanut.jpl.nasa.gov (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:
Currently, I'm developing under a similar paradigm: Write most of the
code in an interactive, interpreted language. Extend with C-code when
interfacing to other libraries, or when doing performance critical
stuff.
As I see it, this is quite different from "gluing *applications*
together"; instead I extend my interpreter environment to include
C-libraries or other features from the rest of the system that I need.
(Yes, I do have threads as well).
However, I have not used tcl for this, I've been using Python, and
more recently Pike (http://pike.infovav.se). From what I have read and
heard about tcl, I can't see tcl having any advantage over the
languages I have been using (I haven't been doing much
GUI-programming, though). In particular, I find OO-techniques quite
powerful.
/Niels