After thinking about J. O's paper it looks like what he's really talking
about is domain specific versus general purpose langauges.
Where "scripting language" = Domain Specific
and "systems language" = General Purpose.
When he talks about "gluing" I think he's really ought to say putting
together primitives designed by someone else that are at the right level of
abstraction. Read with this perspective some of what he says sounds a bit
more resonable.
Daniel Wang <·······@salomon.CS.Princeton.EDU> skrev i artiklen
<···············@salomon.CS.Princeton.EDU>...
>
> After thinking about J. O's paper it looks like what he's really talking
> about is domain specific versus general purpose langauges.
>
> Where "scripting language" = Domain Specific
> and "systems language" = General Purpose.
>
> When he talks about "gluing" I think he's really ought to say putting
> together primitives designed by someone else that are at the right level
of
> abstraction. Read with this perspective some of what he says sounds a bit
> more resonable.
Unless of course his totally undocumented (as anything in the article was
that) comment about OO languages - not that I do not agree in his opinion,
but 'opinion' is an important word that JO confuses with the english word
fact(1).
/Jesper
(1) Or maybe he is confusing it with the sentence "I'm proud of me
concept". Taking into consideration the widespread use of Tcl - he should
be, but pride makes no trues.
In article <···············@salomon.CS.Princeton.EDU>, ·······@salomon.CS.Princeton.EDU (Daniel Wang) writes:
>
>After thinking about J. O's paper it looks like what he's really talking
>about is domain specific versus general purpose langauges.
>
>Where "scripting language" = Domain Specific
>and "systems language" = General Purpose.
>
>When he talks about "gluing" I think he's really ought to say putting
>together primitives designed by someone else that are at the right level of
>abstraction. Read with this perspective some of what he says sounds a bit
>more resonable.
The whole discussion about scripting or systems languages, from the
original definitions in Ousterhouts paper onwards, has been very
strange. This seems like the first attempt to give a more abstract
definition.
Previously it has been very bottom up: "we have features a,b,c,... ,
and will call a language with features g,i and m for a scripting
language, otherwise it is a systems language". Doing it this way is of
course completely ridiculous.
The only reasonable way to decide which languages are scripting
languages is to FIRST determine what you intend a scripting language
to be able to do and how it is meant to be used. THEN you can look
through your list of languages and those that satisfy your criteria
are then scripting languages, IRRESPECTIVE of which features they have
or lack. The features by themselves are really quite uninteresting, it
is the combination and general feel which is important.
Viewed in this way, calling everything which is not a scripting
language for a "systems language" is also ridiculous. I mean a
"systems language" must be one used for writing operating systems. If
scripting languages are used to glue things together what are the
things that I am gluing together to be written in? Application
languages?
However you look at it Ousterhouts paper to me stills read as some
form of technical advertising hype about why you should be using
Tcl. Limiting the languages placed in the same class as Tcl to VB also
clearly shows who the intended audience is. As is the way of making ad
hoc definitions which don't really relate to more normal CS usage.
A final question which has long interested me and which seems relevant
to this whole discussion: who would use Tcl if it DIDN'T have such a
integrated interface to Tk?
--
Robert Virding Tel: +46 (0)8 719 95 28
Computer Science Laboratory Email: ··@erix.ericsson.se
Ericsson Telecom AB
S-126 25 �LVSJ�, SWEDEN
WWW: http://www.ericsson.se/cslab/~rv
"Folk s�ger att jag inte bryr mig om n�gonting, men det skiter jag i".
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
··@erix.ericsson.se (Robert Virding) writes:
:A final question which has long interested me and which seems relevant
:to this whole discussion: who would use Tcl if it DIDN'T have such a
:integrated interface to Tk?
The people using it for expect.
--tom
--
Tom Christiansen ·······@jhereg.perl.com
With a PC, I always felt limited by the software available. On Unix, I am
limited by my knowledge. --Peter J. Schoenster <······@baste.magibox.net>
From: Tom Poindexter
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5im6q7$gua@nyx.cs.du.edu>
In article <············@csnews.cs.colorado.edu>,
Tom Christiansen <·······@mox.perl.com> wrote:
>
>In comp.lang.perl.misc,
> ··@erix.ericsson.se (Robert Virding) writes:
>:A final question which has long interested me and which seems relevant
>:to this whole discussion: who would use Tcl if it DIDN'T have such a
>:integrated interface to Tk?
>
>The people using it for expect.
Actually, quite a few folks use Tcl without Tk for a variety of tasks - CGI,
sysadmin, database monitoring, software testing, space flight control
software, factory control automation, to name a few. Take a look at papers
from the past Tcl Workshops, or try searching around the web.
However, I'd speculate that Tcl gets used very little for any purpose
at the perl.com domain :)
--
Tom Poindexter
········@nyx.net
http://www.nyx.net/~tpoindex/
Tom Christiansen wrote:
> In comp.lang.perl.misc,
> ··@erix.ericsson.se (Robert Virding) writes:
> :A final question which has long interested me and which seems relevant
> :to this whole discussion: who would use Tcl if it DIDN'T have such a
> :integrated interface to Tk?
>
> The people using it for expect.
I'm sure the crowd would be much greater than just the expect users out
there. There are many products out there that use tcl as an extension /
macro language. Products which don't necessarily use Tk. Ours uses tcl
as an extension language in the core product as well as using an
extended 'wish' for the GUIs. The fact that we embed tcl is what makes
our product better than our competition's (in our opinion anyway).
I for one will always consider embedding tcl in any future projects I'm
involved in. It's just flat the best embeddable language out there. Not
the most powerful, not the most efficient. But best nonetheless (IMHO)
for the end-user. I am a user interface designer / developer, and part
of an applications "user interface" is it's scripting interface if it
has one. So, I tend to approach scripting languages from the end-user's
point of view. I am firmly convinced that tcl provides an end user with
the most power for the smallest amount of (the end user's) time
invested.
Perl is great for what perl is, but I don't particularly care for it as
language embedded in other programs. Lisp variants have a special place
in my heart (I admit, I *love* lisp in almost all of its forms and have
written my share of lisp), but lisp isn't a very user-friendly scripting
language. To me, the biggest drawback in embedding lisp in a commercial
product is that list pretty much requires a text editor that knows a
little about lisp syntax.
--
Bryan Oakley ·············@healthcare.com
Software Engineer http://www1.clearlight.com/~oakley/
Healthcare Communications, Inc. http://www.healthcare.com/
From: Richard A. O'Keefe
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5ivb0f$ch$1@goanna.cs.rmit.edu.au>
Bryan Oakley <······@healthcare.com> writes:
>To me, the biggest drawback in embedding lisp in a commercial
>product is that list pretty much requires a text editor that knows a
>little about lisp syntax.
Ok, hands up all the people who *can't* get
- a free vi clone (stevie, vim, vile)
- a free Emacs lookalike (jove, top, emacs)
- a programmer's editor such as "alpha" (which ironically uses tcl)
All the DOS, Windows, OS/2, UNIX, and VMS users have their hands down.
The editor I use knows
- how to move forward over an S-expression
- how to move into the next S-expression
- how to move backwards over an S-exression
- how to copy/cut S-expressions
- how to switch S-expressions
- how to autoindent to the same column as the previous line
(the autoindent function copies leading comment symbols too)
- how to put matching brackets around the next/previous N S-expressions
- how to highlight the matching left bracket when a right bracket of
any type is entered.
The total cost is 5030 characters of C *source code*.
Not lines: characters.
And all of these things are also used (with the appropriate syntax
table) when editing C or Fortran or Pascal or Ada or Java or HTML
(treat <> as brackets; it helps a lot). This editor does _not_ know
how to pretty-print Lisp. I've written a fair bit of Lisp code with
it without any trouble. This isn't rocket science! Even vi can do
a lot of these things, and the newer vi clones can do quite a bit.
Here's the punch-line: TCL has all those nested curly braces.
Can you seriously imagine editing TCL with an editor that doesn't
know about TCL quotation marks and curly braces? Well, the editor
I use _can_ handle these things, and the code it handles them _with_
*IS* the code it uses for Lisp!
- move forward over a "string" or {block}
- move into the next {block}
- move backward over a "string" or {block}
- copy/cut a "string" or {block}
- switch strings/block
- autoindent
- put matching braces around things to make a block
- highlight the matching { when a } is entered
You need the *same* things for editing TCL that you do for editing Lisp.
It is a very tiny matter of programming to write one set of code that
handles both, simply by switching a small syntax table (I know because
I've done it). Those 5030 characters of C are just as useful/necessary
for TCL as they are for Lisp.
So where is the advantage of TCL over Lisp?
Not in the editor, that's for certain sure!
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: Karl Lehenbauer
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <334FE630.41C67EA6@NeoSoft.com>
> ··@erix.ericsson.se (Robert Virding) writes:
> :A final question which has long interested me and which seems relevant
> :to this whole discussion: who would use Tcl if it DIDN'T have such a
> :integrated interface to Tk?
Shell scripts rewritten in Tcl/TclX 8.0 run anywhere from about twenty
to two hundred times faster.
Awk programs rewritten using TclX's "scanmatch" file scanning routines
run much faster.
Say what you want about Scheme, I doubt there're more than a small
handful of believers who would claim that sh or csh is a better or
more capable language than Tcl.
In article <············@news.du.etx.ericsson.se>, Robert Virding wrote:
[lots snipped]
>A final question which has long interested me and which seems relevant
>to this whole discussion: who would use Tcl if it DIDN'T have such a
>integrated interface to Tk?
Anyone who wanted a simple scripting language that could be easily embedded
into their applications. Last time I checked Tcl was the only language you
could do this with. There was something called libscheme that came close,
but did not really allow for full integration with the application.
Not too long ago I added a Tcl interpreter into my pet application (a GIS
data conversion tool). It was an easy task and it has (IMHO) greatly improved
the usefulness of the application. Users can now write their own extensions
to my program in Tcl. It also provides a framework for them to make calls to
compiled libraries.
From: George Herbert
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <5j42f2$p8s@crl3.crl.com>
Note followups.
Dan Haskell <····@danpc.cris.com> wrote:
>>A final question which has long interested me and which seems relevant
>>to this whole discussion: who would use Tcl if it DIDN'T have such a
>>integrated interface to Tk?
>
>Anyone who wanted a simple scripting language that could be easily embedded
>into their applications. Last time I checked Tcl was the only language you
>could do this with. There was something called libscheme that came close,
>but did not really allow for full integration with the application.
One example, the one that got me started using Tcl, is the ICB chat
program (formerly fn). The origional author embedded Tcl 3.0 in one
version to allow for users setting up macros and customizing things
and it's been there ever since (though it got upgraded to newer
versions of Tcl over time). It's completely text based and Tk
has never entered the picture.
Embedding in a easily customizable interpreted language has all sorts
of nifty applications if you think about it.
-george william herbert
········@crl.com
····@danpc.cris.com (Dan Haskell) writes:
>In article <············@news.du.etx.ericsson.se>, Robert Virding wrote:
>[lots snipped]
>>A final question which has long interested me and which seems relevant
>>to this whole discussion: who would use Tcl if it DIDN'T have such a
>>integrated interface to Tk?
>Anyone who wanted a simple scripting language that could be easily embedded
>into their applications. Last time I checked Tcl was the only language you
>could do this with. There was something called libscheme that came close,
>but did not really allow for full integration with the application.
What do you mean by "full integration with the application"? Libscheme
just lets you control the Scheme interpreter from C, what does Tcl has
that helps your integration.
Talking of Scheme's for embedding:
mzscheme is built on top of libscheme and somewhat more under
developement. Uses the same C call interface (and a slightly screwup
up install procedure). Mzscheme also has support for Guile's C
interface.
SCM and Guile are another line, using a different interface (two, to
be precises), a faster interpreter than libscheme that is slower at
startup.
The third is Elk, which focuses on using C from Lisp, can load object
files at runtime. The other systems work the other way round, by
linking the C program with a scheme lib.
Elk is very descent, libscheme as well, but guile-1.0 lacked suport
for important functions when it comes to embedding (the current
snapshots have them) and Scm is somewhat hard to build for
non-experienced people.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin