mr. ousterhout-
many thanks for producing the wonderful tk and tcl libraries.
i do take issue with one of your main points however. you
seem to think that tcl sits on the curve of pareto optimality
between language power and 'glueing' facility.
the pareto optimum is the curve that describes the trade off
between two competing value functions; it shows where one can
not improve in one direction with out going backwards in the
other.
please forgive the ascii charts:
g | .
l |
u | .
e | * <---tcl
i | .
n | c++
g | . |
| . |
e | . v
a | .
s | . * .
e |
+-----------------------------
language power ->
however, i think the situation looks more like this:
g | .
l |
u | .
e | * * <--stk, e.g.
i | ^ .
n | | c++
g | | . |
| tcl . |
e | . v
a | .
s | . * .
e |
+-----------------------------
language power ->
as an example, i present erick gallesio's wonderful
scheme system stk, which is a combination of your very
own tk library with scheme instead of tcl.
the interface to tk is quite sparse, very nearly as
clean as tcl's. and the programmer gets the additional
power of scheme as compared to tcl.
as for glueing, there is a complete foreign function
interface that is well documented and very easy to use.
dynamic loading is supported.
i agree that scripting/glue languages have necessary trade
offs; i also think that it is possible to have scripting
languages that are considerably more powerful than tcl.
-russ
--
Russell D. McManus phone: 212-357-4901
Goldman, Sachs & Co. beep: 917-556-0708
Intl. Equities Technology
From: Alaric B. Williams
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <3355045a.1739551@news.demon.co.uk>
On 15 Apr 1997 12:26:24 +1000, Chris Bitmead
<·············@alcatel.com.au> wrote:
>······@abwillms.demon.co.uk (Alaric B. Williams) writes:
>> How do you defined "power"? I have seen two definitions in languages:
>I personally would definitely go with 2) as the correct definition. 1)
>has it's uses but I wouldn't call that general purpose
>"power". According to that definition, assembler is a super-powerful
>language. To me this is absurd. Assembler has it's uses, but powerful
>isn't an adjective I'd use.
The major attitude I find amongst UNIX/C people is that assembler is
the ultimate in power, but also hard to use. C is pandering to
the user's needs, and thus drops in power. I have been told that
Linux is hard to configure because it is "so powerful", in that
you have to tell it the intimate details of your system - such
as telling X the dot clock rate for your graphics system!!!
When they look at languages like Scheme, TCL, or whatever, the
immediate reaction is "What an unpowerful language". I've got
an ongoing discussion thread with a long time C user archived,
but it gets a bit personal in places, so I'd better not post
it :-)
>> Low Level Power:
>> 1) C++
>Ok, most people would put C++ first in the so-called "low-level" power
>stakes. But it doesn't all go C++'s way. You define low level power as
>the power to control implementation. Consider that C++ is a strictly
>stack based language. Unlike Scheme, (or assembler with some tricky
>mucking around), you can't have multiple "stack-like" environments all
>existing at once. (i.e. continuations and call/cc).
>
>This is a powerful low level feature that C took away from assembler,
>but Scheme allows.
Yes, good point; however, C++ people don't realise it's a useful
feature (no offence, guys!)
I think the difference is that C++ has lost this "power" since the
problems for compiler generation against little perceived use
(back then, structured programming was the ultimate technology,
so I guess people got a little overexcited :o) made it seem
worthless, a "nasty" implementation detail of assembler we could
do best without. Continuations are a nice way of providing this
power without getting into hairy addresses and stack pointers.
>> High Level Power:
>In the high level power stakes, I think we must still put TCL last. If
>we take your definition of being able to do major things with simple
>pieces of code, I think TCL lacks the ability to do major things. TCL
>can nicely _control_ major things, where those major things are
>implemented in say C, but it can't nicely _implement_ major things.
Huh - from all the retorick here, I had a better impression of it.
Can't judge a book by it's cover :-(
But then again, perhaps we need to define the distinction of the
edge of the language better. A tiny gluing language with an immense
set of freely available libraries is, evidently, quite a powerful
tool. Like Scheme with /optional/ Common Lisp libraries! In this
case, the design of the language is to glue bits together, and as
such it's not expected to do much on it's own. So we would hope
that TCL gets things done by delegation.
However, I suspect the model is more of providing specific-purpose
tools to TCL programs, and then letting them control the overall
flow of execution. This is where it gets poor, since we have
monolithic foundations, which a house of TCL straw is then built
upon. If these modules were more abstract, general, things -
such as the way that arithmetic operators are added to a simple
LISP core system, and now it can do arithmetic just like any other
language, rather than coding all the arithmetic in C and linking
it into LISP - then we would have perhaps acheived a useful goal.
>So.. 1) Scheme 2) C++ (reluctantly) 3) TCL.
:-(
>The extent to which TCL is "powerful" is basicly because it is
>typeless. It gives programmers the illusion that they can do a lot
>without a lot of preparation and mucking around. This is a good thing!
>But I wouldn't like to sacrifice true language "power" to get it if I
>didn't have to.
Agreed.
ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."
(Windows for Early Warning and Defence User's manual P26)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
From: Alaric B. Williams
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <33568553.4856683@news.demon.co.uk>
On Wed, 16 Apr 1997 17:09:56 GMT, ······@abwillms.demon.co.uk (Alaric
B. Williams) wrote:
>>Ok, most people would put C++ first in the so-called "low-level" power
>>stakes. But it doesn't all go C++'s way. You define low level power as
>>the power to control implementation. Consider that C++ is a strictly
>>stack based language. Unlike Scheme, (or assembler with some tricky
>>mucking around), you can't have multiple "stack-like" environments all
>>existing at once. (i.e. continuations and call/cc).
>>
>>This is a powerful low level feature that C took away from assembler,
>>but Scheme allows.
Iiiii know what I found a little odd about this. Yeah, I don't really
think call/cc is a low level feature. It is a window to something
usually totally hidden by the implementation, but it's not low
level control of the implementation, since you don't know/tell
anything you don't need to when you program continuations. I mean,
accessing the bits of an integer is low level, but being able to
dynamically link libraries in is more a widening of control than of
making control lower-level, IYSWIM...
ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."
(Windows for Early Warning and Defence User's manual P26)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>