This is to announce that I've posted a new revision of my scripting white
paper. You can get HTML and PostScript versions at the following URLs:
http://www.sunlabs.com/people/john.ousterhout/scripting.html
http://www.sunlabs.com/people/john.ousterhout/scripting.ps
There is also a new Web page that provides more detailed information
such as the complete MFC and Java implementations of the button example
and more descriptive data for the comparisons in Table 1:
http://www.sunlabs.com/people/john.ousterhout/scriptextra.html
If you hated the first version then you aren't likely to be satisfied
with the new version either, but I've toned down the section on objects
a bit, mentioned the "L" word, and made various other small changes.
From: Cimarron Taylor
Subject: Re: New draft of scripting white paper
Date:
Message-ID: <3375802D.49A3@dis.org>
John Ousterhout wrote:
> If you hated the first version then you aren't likely to be satisfied
> with the new version either, but I've toned down the section on objects
> a bit, mentioned the "L" word, and made various other small changes.
Well, a quick read of the new paper doesn't entirely
satisify but I have to say it doesn't infuriate either
so it is probably better. My most specific criticism
is that the entire paper misses the larger picture of
how computing technology is being assimilated by our
culture. In particular, you write:
This paper is an opinion piece that calls attention to the change and
explains why scripting languages will handle many of the programming tasks
of the next century better than system programming languages.
This statement overlooks a very important class of high-level
domain-specific lanugages and interfaces (e.g. SQL, Matlab,
SAS, APT, Ladder-Logic, Spreadsheets, Word Macros, ...) which
are used to solve more real world problems than systems
programming or scripting languages.
I would like to claim that the current interest in general-purpose
scripting and systems programming languages (e.g Tcl / Java) is
rapidly approaching a local maximum and in the beginning of the
next century as more and more of our world's culture learns how
to represent business concepts in domain-specific computing languages
we will see a decline in the use of scripting and systems
programming and an increase in the use of domain-specific languages
supported by new generations of more powerful language construction
and analysis tools.
Cimarron Taylor
········@dis.org
Cimarron Taylor (········@dis.org) wrote:
: I would like to claim that the current interest in general-purpose
: scripting and systems programming languages (e.g Tcl / Java) is
: rapidly approaching a local maximum and in the beginning of the
: next century as more and more of our world's culture learns how
: to represent business concepts in domain-specific computing languages
: we will see a decline in the use of scripting and systems
: programming and an increase in the use of domain-specific languages
: supported by new generations of more powerful language construction
: and analysis tools.
I think I would agree that domain-specific languages will continue to
frow in usage. However, I don't think that general purpose language
usage will shrink at all - what evidence do you have of it's decline?
I think the use of both domain-specific and general purpose languages
will grow as more of the world increases computer use.
Tcl is interesting in this space because it is often used to create domain
specific languages. The extension mechanism in Tcl is powerful enough to
develop any type of new command, language construct, or programming paradigm
that makes sense for a given domain. That's really what application level
scripting languages are all about. Tcl is just one easy way to do that.
Ray Johnson
From: Cimarron Taylor
Subject: Re: New draft of scripting white paper
Date:
Message-ID: <3376A8FB.65F3@dis.org>
Raymond Johnson wrote:
>
> I think I would agree that domain-specific languages will continue to
> frow in usage. However, I don't think that general purpose language
> usage will shrink at all - what evidence do you have of it's decline?
> I think the use of both domain-specific and general purpose languages
> will grow as more of the world increases computer use.
I guess it depends on how you tally up usage. The actual use of currently
popular general purpose programming languages will probably increase as
long as the population itself increases, as will all things cultural
although the specific brand of general purpose language which is most
popular may vary from time to time.
Perhaps I should instead say that I think the number of programmers who
will earn a living using a general purpose language alone is declining
and will continue to decline because simple general purpose programming
skills are becoming as common as other communication skills and in many
ways we will have scripting languages like Tcl to thank for this. The
scripting language is becoming the tool of the information-age laborer.
This may just be wishful thinking, but I predict the distinguishing
characteristics of professional programmers of the next century will be
the algorithms they know, the problems they can solve and the technologies
they understand and not knowledge of a particular brand of general purpose
language or operating system. The "real" programming problems of the next
century will either require more sophisticated programming paradigms than
in use today or a radically different method for creating programs altogether.
>
> Tcl is interesting in this space because it is often used to create domain
> specific languages. The extension mechanism in Tcl is powerful enough to
> develop any type of new command, language construct, or programming paradigm
> that makes sense for a given domain. That's really what application level
> scripting languages are all about. Tcl is just one easy way to do that.
I disagree. The domain-specific languages you can build with Tcl
are pretty much limited to the variations of the simple procedural
constructs Tcl and most other shell languages have. Tcl is really
just a variation of /bin/sh which makes it easy to run commands in
the same process.
To put it another way, I've never heard anyone speak of extending the
"programming paradigm" of /bin/sh when they create a new executable.
Why should that terminology apply to Tcl?
To me the main difference between Tcl bindings to domain-specific
API libraries and a true domain-specific language is that the fundamental
execution model of a Tcl binding cannot differ from the semantics forced
on you by the Tcl interpreter whereas the execution model of a domain-specific
language can adopt the semantics most appropriate to the problem.
Cimarron Taylor
········@dis.org
From: ·······@cas.org
Subject: Re: New draft of scripting white paper
Date:
Message-ID: <5l6ui1$6ks$1@cas.org>
According to Cimarron Taylor <········@dis.org>:
:To me the main difference between Tcl bindings to domain-specific
:API libraries and a true domain-specific language is that the fundamental
:execution model of a Tcl binding cannot differ from the semantics forced
:on you by the Tcl interpreter whereas the execution model of a domain-specific
:language can adopt the semantics most appropriate to the problem.
I'm not sure of the constraints you are putting on this statement.
Can you provide specific examples of the types of things you believe one
cannot do in Tcl but which would be required to be able to be done to
be able to create domain specific APIs? During the previous part of this
thread, I had thought of Expect for instance as an example of a domain specifc
API. Obviously, there are some implications of your statement above which
eliminates Expect from being such a construct. I'm curious to understand
the implication.
--
Larry W. Virden INET: ·······@cas.org
<URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
Unless explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.
From: Cimarron Taylor
Subject: Re: New draft of scripting white paper
Date:
Message-ID: <33779814.7897@dis.org>
·······@cas.org wrote:
> Can you provide specific examples of the types of things you believe one
> cannot do in Tcl but which would be required to be able to be done to
> be able to create domain specific APIs? During the previous part of this
> thread, I had thought of Expect for instance as an example of a domain specifc
> API. Obviously, there are some implications of your statement above which
> eliminates Expect from being such a construct. I'm curious to understand
> the implication.
I'm not a serious user of Expect but I've followed its development
since Don Libes's initial Usenix paper was published. I think
say that Expect is a great tool and an example of the upper limit of
what you can do with Tcl. Expect's model of specifying Tcl actions
to take in response to input makes many tasks much simpler. However
I don't believe expect itself has any mechansism one can use to
reason about the interactions themselves. For instance, it has no
way of examining the arbitrary Tcl actions associated with an input
sequence so it can't really do actual protocol verification.
The things Tcl is not really suitable for are the things
which require altering or extending the fundamental semantics
of expression evaluation. My work involves data management,
symbolic processing and communication and I find Tcl has
few of the concepts I want. For instance, it doesn't have much
support for declarative query processing, integrity constraints,
rules, data type semantics, transaction models or access plans.
As such, it doesn't make a good language in which to build the
framework of data management applications. So if your application
involves data management, it's probably no suprise that you're
probably better off to use SQL or some other language closer
to the problem domain (data management).
I'm sure I could come up with more examples, but I want to respond
to Raymond's post as well before I have to get to the airport...
Cimarron Taylor
········@dis.org
According to Cimarron Taylor <········@dis.org>:
> :To me the main difference between Tcl bindings to domain-specific
> :API libraries and a true domain-specific language is that the fundamental
> :execution model of a Tcl binding cannot differ from the semantics forced
> :on you by the Tcl interpreter whereas the execution model of a domain-specific
> :language can adopt the semantics most appropriate to the problem.
·······@cas.org wrote:
> Can you provide specific examples of the types of things you believe one
> cannot do in Tcl but which would be required to be able to be done to
> be able to create domain specific APIs?
I don't think thats the point. I think the point is that if you wanted
for example lazy evaluation in your domain specific application, then
you can't get lazy evaluation just by cobbling together Tcl bindings to
domain specific API libraries, since the Tcl interpreter itself is not
lazy.
graham
--
We have not succeeded in answering all of our problems. Indeed, we
often feel we have not completely answered any of them. The answers
we
have found only serve to raise a whole set of new questions. In some
ways we feel we are as confused as ever, but we believe we are
confused
on a much higher level and about more important things.
Cimarron Taylor (········@dis.org) wrote:
: This may just be wishful thinking, but I predict the distinguishing
: characteristics of professional programmers of the next century will be
: the algorithms they know, the problems they can solve and the technologies
: they understand and not knowledge of a particular brand of general purpose
: language or operating system. The "real" programming problems of the next
: century will either require more sophisticated programming paradigms than
: in use today or a radically different method for creating programs altogether.
This is one of the basic points John is trying to make in the scripting
white paper. What you call "professional programers", however, John
would call a systems programmer. The point of scripting - and other
high level solutions - is that there will never be enough systems programmers
to do all the work that's needed. Scripting and domain specific programming
allow less sophisticated programmers take on more of the load.
: > Tcl is interesting in this space because it is often used to create domain
: > specific languages. The extension mechanism in Tcl is powerful enough to
: > develop any type of new command, language construct, or programming paradigm
: > that makes sense for a given domain. That's really what application level
: > scripting languages are all about. Tcl is just one easy way to do that.
: I disagree. The domain-specific languages you can build with Tcl
: are pretty much limited to the variations of the simple procedural
: constructs Tcl and most other shell languages have. Tcl is really
: just a variation of /bin/sh which makes it easy to run commands in
: the same process.
: To put it another way, I've never heard anyone speak of extending the
: "programming paradigm" of /bin/sh when they create a new executable.
: Why should that terminology apply to Tcl?
This show that you don't really know how the extensions mechanism in
Tcl works (not that many Tcl users do either). Tcl is not /bin/sh
and is much more flexable and extendable than /bin/sh or most any
other programming language (except lisp and some others). For example,
I've made a declaritive based extension language for an agent system
based on Tcl. Several people have made OO versions of Tcl for thier
needs. The key is that you can create new control structures very easily.
So your comments beg the question. What defines domain-specific?
I can think of many domain specific languages that I have seen that
simply add new commands. You imply that that isn't enough. Why?
Ray
From: Cimarron Taylor
Subject: Re: New draft of scripting white paper
Date:
Message-ID: <3377A4F1.72C6@dis.org>
Ray Johnson wrote:
> This is one of the basic points John is trying to make in the scripting
> white paper. What you call "professional programers", however, John
> would call a systems programmer. The point of scripting - and other
> high level solutions - is that there will never be enough systems programmers
> to do all the work that's needed. Scripting and domain specific programming
> allow less sophisticated programmers take on more of the load.
Ok, perhaps if John went into more detail about systems
programming I'd be more satisified with his paper.
> : To put it another way, I've never heard anyone speak of extending the
> : "programming paradigm" of /bin/sh when they create a new executable.
> : Why should that terminology apply to Tcl?
>
> This show that you don't really know how the extensions mechanism in
> Tcl works (not that many Tcl users do either). Tcl is not /bin/sh
> and is much more flexable and extendable than /bin/sh or most any
> other programming language (except lisp and some others).
Oh come now, I wrote what was perhaps one of the earliest
(now defunct) object extensions to Tcl, and I had to add some
extra code to the Tcl core in order to do it. Eventually
the extension proved unmaintainable so I gave up on it.
If Tcl had a real meta-object protocol or some other form
of metadata mechanism I could have added my language
extension without modifying the core.
> For example, I've made a declaritive based extension language for
> an agent system based on Tcl. Several people have made OO versions
> of Tcl for thier needs. The key is that you can create new control
> structures very easily.
I'm not aware of your work in this area and am curious about
what your language semantics really are. I've seen lots
of papers about ways to get constraint propagation using
Tcl variable traces. I've also seen ways to do OO style
programming using tricks like redefining proc.
My claim is that sort of thing does not count as a true
declarative language or true support for OO programming
since this kind of shortcut doesn't leave you with any way
of reasoning about expressions to verify correct semantics
without resorting to running the system.
> So your comments beg the question. What defines domain-specific?
I began to touch on this above. The primitives provided
by a domain-specific language should have semantics which
closely represent the underlying domain. SQL is a example
of a domain-specific language where the domain is managing
data. Mathematica is a domain-specific language for
manipulating algebraic equations in symbolic form. There
are many others.
Note that I'm not saying you can't do data management or
symbolic processing in Tcl. What I am saying is that if
you want to do this in Tcl you will have to re-invent many
of the things SQL or Mathematica already has.
> I can think of many domain specific languages that I have seen that
> simply add new commands. You imply that that isn't enough. Why?
A domain specific language has a way of representing,
evaluating and reasoning about expressions which differs
enough from that of a general programming language.
Of course, one can always re-invent an entire expression
framework as a bunch of Tcl commands but I don't see what
advantage that gives you since the resulting system will
be hard to learn and use since you'll always have to be on
guard for weird interactions between the Tcl expression
mechanism and your domain-specific evaluation framework.
Cimarron Taylor
········@dis.org
In article <·············@dis.org>, Cimarron Taylor <········@dis.org> wrote:
> SQL is a example
> of a domain-specific language where the domain is managing
> data.
Well, my preferred way of interfacing with our Informix databases is with
isqlperl. It uses SQL to interface with the database, but then lets me use
Perl's control structures, pattern matching, output formatting, etc. for
the rest of the program. Thus, Perl is providing glue between the database
and other parts of the system, just as a good scripting language should.
--
Barry Margolin
BBN Corporation, Cambridge, MA
······@bbnplanet.com
(BBN customers, call (800) 632-7638 option 1 for support)
In article <·············@dis.org> Cimarron Taylor, ········@dis.org
writes:
>I disagree. The domain-specific languages you can build with Tcl
>are pretty much limited to the variations of the simple procedural
>constructs Tcl and most other shell languages have. Tcl is really
>just a variation of /bin/sh which makes it easy to run commands in
>the same process.
>
>To put it another way, I've never heard anyone speak of extending the
>"programming paradigm" of /bin/sh when they create a new executable.
>Why should that terminology apply to Tcl?
Not really. The statements provided by /bin/sh et all are hard coded in
the interpreter. The tcl interpreter does not define language
statements, only language structure. Statements and procedures are the
same in tcl. With the tcl 'proc' command you can add a new statement
(you can also do this with 'c'). To demonstrate this, you can add an
'until' statment to tcl with a four or five lines of tcl in a 'proc'
command (you could also use 'c'). 'until' does the same thing as 'while'
except that the logic inverted. I don't think you can do this kind of
thing with /bin/sh or anything derived from it. You can't do it with c
or c++, pascal, ... etc, etc.
Another interesting feature of tcl is that it has no operators (in
particular, no replacement statement ). This eliminates the problem of
type-matching that is endemic to languages that use the replacement
statement. I think using the '=' sign in a replacement statement came
to programming because people thought that, since computers do
arithmetic, we should program the same way we do mathematics.
BDW> I don't think you can do this kind of
BDW> thing with /bin/sh or anything derived from it. You can't do it with
c
BDW> or c++, pascal, ... etc, etc.
But you can easily do that in Scheme or Common Lisp or Interlisp or Icon or
Smalltalk, ... etc, etc.
Actually many of my programming in Common Lisp consists of building the
right abstractions not only in data but in control structures, too. It's
easy and common practice to build a domain-specific language in Common Lisp
and then solve the problem in _this_ language. Ok, most of the time the
control structures of Common Lisp are powerful enough and so you integrate
the domain specific language into Common Lisp itself, so your domain
specific language is reduced to a package of special macros and
datastructures.
Actually most of the arguments for TCL in this field hold true for Common
Lisp, too. Only the C-Interface is a bit more complicated. But that's a
result of Common Lisp trying to interface to any C-language without
requiring the programmer to write glue code for every function that doesn't
fit into the accept-only-strings world.
bye, Georg
From: Joachim Durchholz
Subject: Re: New draft of scripting white paper
Date:
Message-ID: <VA.000000eb.0069155e@herold>
> the interpreter. The tcl interpreter does not define language
> statements, only language structure. Statements and procedures are
> the
> same in tcl. With the tcl 'proc' command you can add a new statement
> (you can also do this with 'c'). To demonstrate this, you can add an
> 'until' statment to tcl with a four or five lines of tcl in a 'proc'
> command (you could also use 'c'). 'until' does the same thing as
> 'while'
> except that the logic inverted. I don't think you can do this kind of
> thing with /bin/sh or anything derived from it. You can't do it with
> c or c++, pascal, ... etc, etc.
It's true you can't, and occasionally I missed some statements (in any
of these languages).
However, I don't consider opening up everything to redefinition
fruitful. If such language extension features are widely used, the end
result is that each programmer creates his own dialect that only he and
nobody else can read or maintain.
I guess this effect contributes to the supposed write-only character of
tcl (I don't know tcl, but I've seen some FORTH).
> Another interesting feature of tcl is that it has no operators (in
> particular, no replacement statement ). This eliminates the problem
> of type-matching that is endemic to languages that use the replacement
> statement.
Sorry, this is simply not true. If a programming language has any
functionality, be it operators, functions, macros, or whatever, you need
to check wether the parameters match the respective expected types.
(Substitute "behaviour" for "type" if you are a Smalltalker, and "can be
processed by the operator/function/whatever" if you are using a typeless
language.) That check might be done by the compiler, the run-time
system, or by the routines themselves (checking parameter validity), but
it must be done to avoid bugs passing routine boundaries.
> I think using the '=' sign in a replacement statement came
> to programming because people thought that, since computers do
> arithmetic, we should program the same way we do mathematics.
Yes. Though some languages (especially those in the tradition of Pascal)
use := to make the difference clear, and to emphasize the asymmetry.
Regards,
-Joachim
---
Please don't send unsolicited ads.
From: Cimarron Taylor
Subject: Re: New draft of scripting white paper
Date:
Message-ID: <3383ADEA.58FA@dis.org>
Bob De Wolf wrote:
> Cimarron Taylor, [... Tcl is really just a variation of /bin/sh ...]
>
> Not really. The statements provided by /bin/sh et all are hard coded in
> the interpreter. The tcl interpreter does not define language
> statements, only language structure. Statements and procedures are the
> same in tcl. With the tcl 'proc' command you can add a new statement
> (you can also do this with 'c'). To demonstrate this, you can add an
> 'until' statment to tcl with a four or five lines of tcl in a 'proc'
> command (you could also use 'c'). 'until' does the same thing as 'while'
> except that the logic inverted. I don't think you can do this kind of
> thing with /bin/sh or anything derived from it. You can't do it with c
> or c++, pascal, ... etc, etc.
You can do some of these things in sh and other shells but
it's a little more clumsy. If you're willing to resort
to using the preprocessor you can do this in C as well.
I believe the original implementation of /bin/sh actually
did this! The code I read used directives such as
#define BEGIN { and #define END } to make C look like sh.
But I digress...
My main objection here is to the use of the term "paradigm".
The point is that Tcl, sh, csh, ksh, command.com, ... are all
variations of shell languages. They all provide the bare essentials
(expressions and control structures) you need to write simple
programs and also provide mechanisms to interact with other code.
This is what they are designed to do and this is what they do well.
However, creating new procedures and alternate ways of expressing
flow control are all well and good but to say these techniques
allow you to extend the "programming paradigm" is too much of a
stretch for me.
Cimarron Taylor
········@dis.org
In article <·············@dis.org>, Cimarron Taylor <········@dis.org> wrote:
> My main objection here is to the use of the term "paradigm".
> The point is that Tcl, sh, csh, ksh, command.com, ... are all
> variations of shell languages. They all provide the bare essentials
> (expressions and control structures) you need to write simple
> programs and also provide mechanisms to interact with other code.
> This is what they are designed to do and this is what they do well.
>
> However, creating new procedures and alternate ways of expressing
> flow control are all well and good but to say these techniques
> allow you to extend the "programming paradigm" is too much of a
> stretch for me.
Tcl is more powerful than the shells since I know I can extend Tcl
(without additional C) to have object-oriented semantics (admittedly,
the syntax is not as good as you might wish) and I can also do things
that are remarkably close to lazy programming. I don't know what you
think, but they look like different paradigms to me.
Note that I don't claim that Tcl does these as well as some other
languages, but merely that it is possible to use techniques from those
styles of programming without great amounts of pain, unlike other
languages I can think of. Particularly helpful is the ability to
create new pieces of syntax to dress up new semantics - a great way of
making a piece of code easier to maintain since you can cut out the
bits which do not pertain to the overall conceptual semantics.
I know I can say this better if I try. Hmm...
By not attaching complex semantics to everything in sight itself and
not placing a complex syntax over the top of it all, Tcl makes it much
easier to add application-specific syntax and semantics to scripts.
My experience is that it is the app-specific stuff that tends to cause
Tcl scripting to win out (Tk is an example of app-specific syntax and
semantics being added to Tcl, and the difficulty that many other
authors have had with combining Tk with other languages has served to
indicate just how good Tcl is at embedding external syntax and
semantics). The fact that the core commands in the Tcl library are
fairly well rounded for general use is a bonus, but these are not what
makes Tcl.
Donal.
--
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ (SAY NO TO COMMERCIAL SPAMS!)
···········@man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K. +44-161-275-6137
The at symbol in my email address has been shifted one word right
to deter spam-bots. Sorry for any inconvenience this causes you.
From: Cimarron Taylor
Subject: Re: New draft of scripting white paper
Date:
Message-ID: <33966E8F.C8A@dis.org>
Donal K. Fellows wrote:
> In article <·············@dis.org>, Cimarron Taylor <········@dis.org> wrote:
> > However, creating new procedures and alternate ways of expressing
> > flow control are all well and good but to say these techniques
> > allow you to extend the "programming paradigm" is too much of a
> > stretch for me.
>
> Tcl is more powerful than the shells since I know I can extend Tcl
> (without additional C) to have object-oriented semantics (admittedly,
> the syntax is not as good as you might wish) and I can also do things
> that are remarkably close to lazy programming. I don't know what you
> think, but they look like different paradigms to me.
In the particular case you mention (object-oriented semantics)
is interesting because the technique predates Tcl and in fact
has been used in various shell programs. I've seen shell scripts
which read a lot like "oo" Tcl programs (e.g. $object do something..)
I think oo syntax tricks didn't ever catch on in /bin/sh or other
shells because the time wasn't right. I'm not certain what you
mean exactly by "lazy programming" so perhaps you could elaborate
more on this. Does Tcl turn people into lazy programmers? :-)
> Note that I don't claim that Tcl does these as well as some other
> languages, but merely that it is possible to use techniques from those
> styles of programming without great amounts of pain, unlike other
> languages I can think of. Particularly helpful is the ability to
> create new pieces of syntax to dress up new semantics - a great way of
> making a piece of code easier to maintain since you can cut out the
> bits which do not pertain to the overall conceptual semantics.
In this I agree entirely. Tcl allows you to use many
different programming techniques. However to me that's
not the same as "extending the paradigm". Extending the
paradigm to me means something far more radical, like
using declarative statements instead of procedural ones
or visual elements instead of textual ones or combining
programming and specification into a single process or
something other than just fiddling with a reinvention
of the lisp macro facility.
> By not attaching complex semantics to everything in sight itself and
> not placing a complex syntax over the top of it all, Tcl makes it much
> easier to add application-specific syntax and semantics to scripts.
Don't other languages do this as well? Sounds like the same
argument can be made for lisp, /bin/sh and just about anything
that keeps its fundamental expression evaluation mechanism
simple.
> My experience is that it is the app-specific stuff that tends to cause
> Tcl scripting to win out (Tk is an example of app-specific syntax and
> semantics being added to Tcl, and the difficulty that many other
> authors have had with combining Tk with other languages has served to
> indicate just how good Tcl is at embedding external syntax and
> semantics).
But Tk has been integrated with perl, scheme, and /bin/ksh.
To me this example shows that Tk is well engineered, not
that Tcl is fundamentally better than the other tools.
> The fact that the core commands in the Tcl library are fairly well rounded
> for general use is a bonus, but these are not what makes Tcl.
In a purely theoretical sence you are right, but in
practice I think very few would use Tcl if the library
wern't well engineered. From 1988 to 1992, Tcl was
perhaps the best piece of unix software in existance.
Cim
From: Leslie Mikesell
Subject: Re: New draft of scripting white paper
Date:
Message-ID: <5l914l$kbj$1@Venus.mcs.net>
In article <·············@dis.org>, Cimarron Taylor <········@dis.org> wrote:
>To put it another way, I've never heard anyone speak of extending the
>"programming paradigm" of /bin/sh when they create a new executable.
>Why should that terminology apply to Tcl?
That goes without saying. The whole concept of unix tool programming
is that any new tool automatically and intentionally includes all
the others. Of course this eventually becomes cumbersome enough
that for some purposes you need more integrated programs.
Les Mikesell
···@mcs.com
It's much better. Now, I can better appreciate the parts I agreed with to begin with,
because I'm not so busy objecting to the earlier errata. <g>
Bill House
--
http://www.dazsi.com
Note: my e-mail address has been altered to
confuse the enemy. The views I express are
mine alone (unless you agree with me).
In article <············@engnews2.Eng.Sun.COM>,
John Ousterhout <······@tcl.eng.sun.com> wrote:
>This is to announce that I've posted a new revision of my scripting white
>paper. You can get HTML and PostScript versions at the following URLs:
>
> http://www.sunlabs.com/people/john.ousterhout/scripting.html
> http://www.sunlabs.com/people/john.ousterhout/scripting.ps
>
This is a big improvement. I still disagree with the strict
scripting/systems dichotomy, but the paper seems much more reasonable.
The earlier draft read too much like Tcl propaganda---even though
I'm sure that's not how you meant it---and this one seems much
more clearly centered on the actual issues.
The last sentence of the conclusions section (saying you look forward to
more powerful scripting languages) hits just the right note.
The "other languages" section is too brief for my taste, but it's
reasonable in a short paper. What you do say makes it clear that you
have considered other languages, and recognized some of their various
strengths.
One suggestion: you might want to briefly note that Smalltalk pioneered
GUIs built into interactive languages, which was really important. One
of the very good things about Tcl and other scripting languages with
graphics toolkits like Tk is that they restored that combination, which
is incredibly convenient.
I, for one, really appreciate the fact that you've listened to criticisms
of the earlier draft, and improved the paper considerably. Thank you.
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (······@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)