Why you should not use Tcl
Richard Stallman
Why you should not use Tcl
Richard Stallman, GNU Project
As interest builds in extensible application programs and tools, and
some programmers are tempted to use Tcl, we should not forget the
lessons learned from the first widely used extensible text
editor--Emacs.
The principal lesson of Emacs is that a language for extensions should
not be a mere "extension language". It should be a real programming
language, designed for writing and maintaining substantial programs.
Because people will want to do that!
Extensions are often large, complex programs in their own right, and
the people who write them deserve the same facilities that other
programmers rely on.
The first Emacs used a string-processing language, TECO, which was
inadequate. We made it serve, but it kept getting in our way. It
made maintenance harder, and it made extensions harder to write.
Later Emacs implementations have used more powerful languages because
implementors learned from the problems of the first one.
Another lesson from Emacs is that the way to make sure an extension
facility is really flexible is to use it to write a large portion of
the ordinary released system. If you try to do that with Tcl, you
will encounter its limitations.
Tcl was not designed to be a serious programming language. It was
designed to be a "scripting language", on the assumption that a
"scripting language" need not try to be a real programming language.
So Tcl doesn't have the capabilities of one. It lacks arrays; it
lacks structures from which you can make linked lists. It fakes
having numbers, which works, but has to be slow. Tcl is ok for
writing small programs, but when you push it beyond that, it becomes
insufficient.
Tcl has a peculiar syntax that appeals to hackers because of its
simplicity. But Tcl syntax seems strange to most users. If Tcl does
become the "standard scripting language", users will curse it for
years--the way people curse Fortran, MSDOS, Unix shell syntax, and
other de facto standards they feel stuck with.
For these reasons, the GNU project is not going to use Tcl in GNU
software. Instead we want to provide two languages, similar in
semantics but with different syntaxes. One will be Lisp-like, and one
will have a more traditional algebraic syntax. Both will provide
useful data types such as structures and arrays. The former will
provide a simple syntax that hackers like; the latter will offer
non-hackers a syntax that they are more comfortable with.
Some people plan to use Tcl because they want to use Tk. Thankfully,
it is possible to use Tk without Tcl. A Scheme interpreter called STk
is already available. Please, if you want to use Tk, use it with STk,
not with Tcl. One place to get STk is from
ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
James Montebello
: Tcl has a peculiar syntax that appeals to hackers because of its
: simplicity. But Tcl syntax seems strange to most users.
I cannot agree with this. o you have any evidence to support such a
sweeping statement? I, for one, find Tcl's syntax a good deal more
readable than any Lisp variant.
Tcl also wasn't designed to be used in a vacuum, but to be embedded
into a larger application. The ease with which this can be done is its
primary strength. If the language lacks features you desire, add them.
This, too, is relatively easy to do.
--
james montebello (ja...@bridge.com) -------- 'my employer has no opinions'
The most popular labor-saving device today is still a husband with money.
- Joey Adams
Hal
> Why you should not use Tcl
> Richard Stallman, GNU Project
Stallman's article seems short on specific criticisms. I see:
1) Tcl was not designed to be a serious programming language.
2) Tcl lacks arrays.
3) Tcl lacks structures from which you can make linked lists.
4) Tcl is inherently slow.
5) End-users do not like Tcl syntax.
I would point out:
1) I can find no documentation that Tcl was not designed to be suitable
for serious programs. It is clearly based on LISP, which has been
widely used in the AI community among others for very serious programming.
2) Tcl has content addressable arrays, which are a superset of ordinary
arrays in functionality.
3) Tcl has no pointers, and shares this property with most LISP like
languages. Deeply nested list structures can be created, though, which
provide much of the functionality of linked lists.
4) It remains to be seen whether performance improvements are possible
to Tcl. There has been discussion on comp.lang.tcl on compilers. On-
the-fly compilation would combine interactivity with performance. Other
optimizations such as speedups for arrays whose index elements are
numbers should be possible.
5) I agree that LISP-like languages can be hard for amateurs to use.
It should be possible to make Tcl more usable by, for instance, creating
easier-to-use control structures. Stallman's idea for two compatible
languages with different syntax is perhaps worth looking at, but frankly
I suspect that programming is an inherently difficult process and it
will be hard to dumb it down much and still retain the needed power.
One other point - Stallman mentions TECO as a language with limitations
similar to those he sees in Tcl. I did considerable programming in
TECO back in the early days and IMO Tcl has practically nothing in
common with it. Tcl is far more similar to the LISP variant used in
present-day Emacs and again IMO is considerably more readable. The
shareware text editor Alpha for the Macintosh is Emacs-like, uses Tcl
in place of Emacs LISP, and the performance is fine.
Hal Finney
hfi...@shell.portal.com
Tom Tromey
> Richard Stallman (r...@gnu.ai.mit.edu) wrote:
> : Tcl has a peculiar syntax that appeals to hackers because of its
> : simplicity. But Tcl syntax seems strange to most users.
James> I cannot agree with this. o you have any evidence to support
James> such a sweeping statement? I, for one, find Tcl's syntax a good
James> deal more readable than any Lisp variant.
There is plenty of evidence, in the form of the many posts to
comp.lang.tcl that express confusion about Tcl syntax. Lately the
posts seem to be concentrating on unmatched braces in comments, but ""
vs {} quoting is also a favorite.
Tom
--
tro...@cns.caltech.edu Member, League for Programming Freedom
"Sadism and farce are always inexplicably linked"
-- Alexander Theroux
T. William Wells
sufficiently familiar with it to know that you don't know enough
about it to have an informed opinion. Rather than embroiling
myself in the flamewar that your specious claims are sure to
cause, I'll just observe that that sort of politicking is utterly
contemptible.
Patric Jonsson
>For these reasons, the GNU project is not going to use Tcl in GNU
>software. Instead we want to provide two languages, similar in
>semantics but with different syntaxes. One will be Lisp-like, and one
>will have a more traditional algebraic syntax. Both will provide
>useful data types such as structures and arrays. The former will
>provide a simple syntax that hackers like; the latter will offer
>non-hackers a syntax that they are more comfortable with.
Olin Shivers Scheme Shell?
--
The original argument in favor was that the macro provides some useful
and pleasant syntactic sugar, eliminating the frequent need to disrupt
lisp's soothing flow of parentheses with the angular orthography of
octathorp quote.
s...@Franz.COM (Steve Haflich)
comp.lang.lisp
Scott Schwartz
1) I can find no documentation that Tcl was not designed to be suitable
for serious programs.
It's clear from Ousterhout's original Usenix paper that tcl was intended
to be used as a lightweight extension language, not a large scale
implementation language.
2) Tcl has content addressable arrays, which are a superset of ordinary
arrays in functionality.
They are not first class objects: you can't assign one to another, pass
or return them from functions. Contorted "call by name" semantics are
the only workaround.
3) Tcl has no pointers, and shares this property with most LISP like
languages. Deeply nested list structures can be created, though, which
provide much of the functionality of linked lists.
Lists have O(1) append time. Tcl strings have O(n) append time.
Superquadratic runtime and lots of memory thrashing results.
Erik Naggum
I found the above utterly contemptible. let the first man with a gas can
and a lighter be responsible for the flame war, not he who states his
opinions, however unpopular.
#<Erik>
--
Microsoft is not the answer. Microsoft is the question. NO is the answer.
T. William Wells
Erik Naggum <er...@naggum.no> wrote:
: [T. William Wells]
:
: | Mr. Stallman, though I am but an occasional user of tcl, I am
: | sufficiently familiar with it to know that you don't know enough about
: | it to have an informed opinion. Rather than embroiling myself in the
: | flamewar that your specious claims are sure to cause, I'll just observe
: | that that sort of politicking is utterly contemptible.
:
: I found the above utterly contemptible. let the first man with a gas can
: and a lighter be responsible for the flame war, not he who states his
: opinions, however unpopular.
Tsk. You of all people should know that I don't care about popularity....
Mr. Stallman said baldly that "[tcl] lacks arrays". That is either a
demonstration of Mr. Stallman's ignorance or it is an outright lie. Either
way, that *alone* is sufficient to disqualify Mr. Stallman from having a
valuable opinion on the subject. That *alone* removes his politicking from
the reasonable to the contemptible. Never mind any of the other drivel!
I've directed followups to alt.flame, as that's the appropriate place for any
further comments from you on this subject.
Russell Leighton
I find Tcl perfect to add a flexible control/interface
to my programs, and Tk to generalize that to X11 ...
don't tell me what to use ...scheme, really... I believe
you are abusing your considerable influence ... what is
your agenda? What has Tk/tcl ever done to you? Nobody is
asking FSF to support this ... please continue to produce
great software but leave this alone... how rude.
--
Russell Leighton
Taylor Computing
ru...@taylor.digex.net tay...@world.std.com
http://taylor.digex.net http://www.digex.net/~rrl/Welcome.html
Jim Wise
>[T. William Wells]
>| Mr. Stallman, though I am but an occasional user of tcl, I am
>| sufficiently familiar with it to know that you don't know enough about
>| it to have an informed opinion. Rather than embroiling myself in the
>| flamewar that your specious claims are sure to cause, I'll just observe
>| that that sort of politicking is utterly contemptible.
>I found the above utterly contemptible. let the first man with a gas can
>and a lighter be responsible for the flame war, not he who states his
>opinions, however unpopular.
Actually, Mr. Wells was responding to an obvious and offensive FUD attack on
a language which many people, myself included, are quite happy and impressed
with. While I greatly respect RMS and his body of work, his attack is spurred
by so little understanding of, or even relevance to the intended uses and
strengths of Tcl that it makes me wonder what his motives are.
Jim Wise
wi...@acf4.nyu.edu
Steven Grimm
>Tcl has a peculiar syntax that appeals to hackers because of its
>simplicity. But Tcl syntax seems strange to most users.
And Lisp is the height of user-friendliness and clarity? People who live
in glass houses...
-Steve
Erik Naggum
| Mr. Stallman, though I am but an occasional user of tcl, I am
| sufficiently familiar with it to know that you don't know enough about
| it to have an informed opinion. Rather than embroiling myself in the
| flamewar that your specious claims are sure to cause, I'll just observe
| that that sort of politicking is utterly contemptible.
[Erik Naggum]
| I found the above utterly contemptible. let the first man with a gas
| can and a lighter be responsible for the flame war, not he who states
| his opinions, however unpopular.
[Jim Wise]
| Actually, Mr. Wells was responding to an obvious and offensive FUD
| attack on a language which many people, myself included, are quite
| happy and impressed with. While I greatly respect RMS and his body of
| work, his attack is spurred by so little understanding of, or even
| relevance to the intended uses and strengths of Tcl that it makes me
| wonder what his motives are.
whatever one may think about RMS, his work or his motives, Tcl or anything
else, it was T. William Wells' attitude that I was addressing. if the
statement of his opinions can cause only flames (at least in his opinion),
it is _he_ is who is starting the flame wars that he so despises. this is
his problem, not RMS's, and nobody else's. I find it utterly contemptible
to attempt to transfer the guilt of such irrational behavior to others, no
matter _what_ one thinks of the subject matter or _how_ one defends one's
views. this is definitely politicking. if one thinks certain kinds of
actions contemptible and engages in them at the first opportunity, who is
contemptible?
it should be possible to discuss the merits and demerits of RMS's statement
on Tcl without resorting to such flames. if he is so obviously wrong as is
implied, this can be pointed out. if RMS has strong influence on what
others may think, it is counter-productive, if one wishes to reduce this
influence, to behave irrationally. this only tells bystanders that it is
his critics who must have less than pure motives. this can actually cause
by-standers to believe what RMS is saying, _unchallenged_.
RMS's statement may be read as a slam on Tcl in favor of yet-undelivered
tools from the GNU project. we may note that dejagnu uses Tcl at present,
and we may assume that some lessons were drawn from this. RMS's statement
may also be read as urging people to consider alternatives because of some
things that RMS thinks are bad, and for which he gives a varying degree of
good arguments. we may note that people are doing this all the time, and
apply the necessary precautions when reading such notices, instead of
imputing evil motives and ranting and raving in openly hostile articles
completely devoid of technical content, the very definition of "flaming".
I now know that Tcl has some sort of arrays, and that there are ways to do
what one wants in the context for which it was designed, and that people
are doing this. this enables me to judge Tcl and RMS's opinions on it in a
technical context. if I wish to know more, I know whom to ask. I also
know that some individuals have given unsupported ad hominem attacks on RMS
in place of something that I could use to form my own opinions. this only
gives me information to judge those who engage in such attacks, should I so
desire. I am more interested in extension and scripting languages to want
to waste more of my time than to point these things out. T. William Wells
is encouraged not to respond unless he can tone down his replies a bit.
Marcus Daniels
>it should be possible to discuss the merits and demerits of RMS's statement
>on Tcl without resorting to such flames.
Right on.
Karl Fogel
>Lists have O(1) append time. Tcl strings have O(n) append time.
>Superquadratic runtime and lots of memory thrashing results.
I thought lists have O(N) append time too. I mean, you have
to copy a whole list in order to append it to something else. Even in
a destructive append, you still have to find the final cdrs, which
means bouncing down the whole list.
Of course, the final list that gets stuck on the end happens
in O(1) time; it's just all the other ones that don't...
I could be wrong, though, or have misunderstood. Please feel
free to correct me if so.
-Karl
--
Karl Fogel <kfo...@cs.oberlin.edu> <kfo...@phylo.life.uiuc.edu>
<>-<> <> <>-<> <>-<>-<> <>-<> <> <> <>-<>-<>-<> <>-<> <>-<> <>-<>-<> <>-<>
Finger me at either address for my PGP public key.
ozan s. yigit
it should be possible to discuss the merits and demerits of RMS's statement
on Tcl without resorting to such flames.
the obvious question is: why bother? we know RMS will not
change his mind. for gnu, his opinion is the one that
matters. done.
oz
T. William Wells
Erik Naggum <er...@naggum.no> wrote:
: whatever one may think about RMS, his work or his motives, Tcl or anything
: else, it was T. William Wells' attitude that I was addressing.
Take your flaming elsewhere, Naggum. They, and your paranoid ravings, are not
appropriate to this newsgroup.
I will repeat what I told you in e-mail, which you promptly ignored: I do not
want further e-mail from you, and I have, as I told you, filed that unwanted
e-mail unread. *Do not send more e-mail*.
Folks, I've had run-ins with Naggum before. You all know the type, one who
flames and then obfuscates the issues until he "wins" because everyone gives
up in digust. Please spare us all and don't reply to his arguments. You
cannot win, not because he's right, but because he is impervious to anything
resembling logic.
Barry Merriman
> Why you should not use Tcl
RMS rests his argument on two assertions:
I.
> Tcl was not designed to be a serious programming language.
II.
> Tcl has a peculiar syntax
And then goes on to suggest
III.
> we [ GNU Project] want to provide two languages, similar in
> semantics but with different syntaxes. One will be Lisp-like...
I & II are both undeniably true, but they should be taken in context:
Lets assume for the moment that we want a language that meets the
following minimal specifications (which tcl is supposed to provide)
(1) convenient for script writing
(2) interpreted
(3) embeddable
(4) composable
(5) portable
The question now becomes: can you do any better than tcl---i.e,
can you meet those specs, as well as support:
(7) full featured modern programming language
(8) friendly syntax
As for the dual language solution, III:
This does not seem like a good solution to me! Two language with
the same capabilities but vastly different syntaxes??? It
seems like the natural evolution of such a system will be that
either one language or the other will greatly dominate in
use---which defeats the purpose of having two, since one becomes
the defacto standard---or most projects will be written in
bits and pieces of both, which just means everyone has to know
all of them, and constantly switch back and forth between
different languages that do nearly the same thing
(much like the situation with the various unix shell languages
these days: sh, csh, tcsh, ksh, bash, rc...).
_If_ you want a viable two language solution,
one should play a subordinate role to the other, i.e. be built
on top of the other, as a higher level, somehow simplified
language (like C on top of assembly, for e.g..)
Qusetion1: Aside from the two dual language issue, why schould one
of them be lisp? This seems motivated solely by historical bias.
Question2: doesn't Python essentially provide what RMS wants?
Why doesn't GNU just adopt Python as its defacto language?
--
Barry Merriman
UCLA Dept. of Math
UCLA Inst. for Fusion and Plasma Research
ba...@math.ucla.edu (Internet; NeXTMail is welcome)
Matthew Dillon
:>[Please redistribute wherever appropriate.]
:>
:>
:>
:> Why you should not use Tcl
:> Richard Stallman, GNU Project
:>
:>As interest builds in extensible application programs and tools, and
:>some programmers are tempted to use Tcl, we should not forget the
:>Tcl was not designed to be a serious programming language. It was
:>designed to be a "scripting language", on the assumption that a
:>"scripting language" need not try to be a real programming language.
:>So Tcl doesn't have the capabilities of one. It lacks arrays; it
:>lacks structures from which you can make linked lists. It fakes
:>having numbers, which works, but has to be slow. Tcl is ok for
:>writing small programs, but when you push it beyond that, it becomes
:>insufficient.
We use Tcl/Tk for nearly the entire GUI in one of our major turnkey
projects, about 400 K of Tcl/Tk code.
I have found Tcl/Tk to be excellent for smallish self contained programs.
The GUI code I've written is comprised of approximately 14 relatively
independant programs and a small set of common library routines and
C programs for low level database access.
However, the largest of these GUI elements rapidly bogged down in several
areas as it was being coded. The primary problem was with the lack of
structure in the language and variable syntax. It required very HEAVY
commenting to keep things straight as event oriented procedures forced
us collect variable sets in global associative arrays, which greatly
complicated operation. The language structure also has a lot of problems,
especially with variable substitution and programmatic structures such
as switch statements and loops. These problems can be ignored for
small (1000 line or less) programs but rapidly cause confusion in larger
programs.
I would have to agree that as a programming language, Tcl sucks rocks
when it comes to largish projects. It is an excellent tool for smaller
projects (expect scripts, less complex Tk/Gui stuff) but Tcl is not
something I would want to inflict on somebody as a standard.
I also have to say that, personally, I think anything lisp-like is even
worse, so this response should not be interpreted as being particularly
for GNUs intentions. Perl comes closest to what I believe GNU wants
but so far nothing fits the bill exactly, and I do not particularly
like Perl's variable syntax either (though it's better then TCL's).
:Some people plan to use Tcl because they want to use Tk. Thankfully,
:it is possible to use Tk without Tcl. A Scheme interpreter called STk
:is already available. Please, if you want to use Tk, use it with STk,
:not with Tcl. One place to get STk is from
:ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
Heh, you convinced me to try it. :-)
-Matt
--
Matthew Dillon dil...@apollo.west.oic.com
1005 Apollo Way ham: KC6LVW (no mail drop)
Incline Village, NV. 89451 Obvious Implementations Corporation
USA Sandel-Avery Engineering
[always include a portion of the original email in any response!]
Dave Curado
> >it should be possible to discuss the merits and demerits of RMS's statement
> >on Tcl without resorting to such flames.
>
> Right on.
Agreed! But in case anyone is keeping count: Richard -- respectfully
don't agree...
Tcl has its place in the world.
--
no rest for the wicked...
Guido van Rossum
>Some people plan to use Tcl because they want to use Tk. Thankfully,
>it is possible to use Tk without Tcl. A Scheme interpreter called STk
>is already available. Please, if you want to use Tk, use it with STk,
>not with Tcl. One place to get STk is from
>ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
In a followup, Barry Merriman suggests to try Python. I can't agree
more :-). Moreover, Python also has a cool object-oriented interface
to Tk! Python's home ftp site has this URL:
ftp://ftp.cwi.nl/pub/python (read the INDEX file); the Tk interface is
called tkinter.tar.gz. There's also considerable on-line info about
Python on WWW; the URL is http://www.cwi.nl/~guido/Python.html.
Finally, there's a newsgroup (comp.lang.python).
--Guido van Rossum, CWI, Amsterdam <mailto:Guido.va...@cwi.nl>
<http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>
Gay David
In article <361irr$j...@news1.shell> hfi...@shell.portal.com (Hal) writes:
Stallman's article seems short on specific criticisms. I see:
1) Tcl was not designed to be a serious programming language.
3) Tcl lacks structures from which you can make linked lists.
4) Tcl is inherently slow.
I would point out:
1) I can find no documentation that Tcl was not designed to be suitable
for serious programs. It is clearly based on LISP, which has been
widely used in the AI community among others for very serious programming.
I keep on hearing this, so it must be true (;-)). But in what way is Tcl
similar to Lisp ? I see no direct relation to the lambda-calculus for
instance. It is true that Lisps, especially those with dynamic scope, are
not a pure implementation of the lambda-calculus, but they do not stray
all that far from it.
3) Tcl has no pointers, and shares this property with most LISP like
languages. Deeply nested list structures can be created, though, which
provide much of the functionality of linked lists.
But Lisp allows sharing of data-structures, which provides a safe access
to most of the pointer functionality. How can you do that with strings ?
4) It remains to be seen whether performance improvements are possible
to Tcl. There has been discussion on comp.lang.tcl on compilers. On-
the-fly compilation would combine interactivity with performance. Other
optimizations such as speedups for arrays whose index elements are
numbers should be possible.
Basing a language on string-substitution is obviously not the best way
to get high-performance. Sufficiently clever analysis and/or string
implementation may allow most substitutions to be avoided, but why
does all this have to be necessary ? While the Tcl compiler is busy
trying to work out the program's control structure, the Lisp compiler
is already at work attempting to discover the types of its variables :-)
David Gay
dg...@di.epfl.ch
Paul Alexander
|> [Please redistribute wherever appropriate.]
|>
|>
|> For these reasons, the GNU project is not going to use Tcl in GNU
|> software. Instead we want to provide two languages, similar in
|> semantics but with different syntaxes. One will be Lisp-like, and one
|> will have a more traditional algebraic syntax. Both will provide
|> useful data types such as structures and arrays. The former will
|> provide a simple syntax that hackers like; the latter will offer
|> non-hackers a syntax that they are more comfortable with.
|>
|>
1. Under what licence terms will these GNU languages be distributed? If
it is the usual GNU licence then this will prohibit commerical use or
involvement in their development --- this has been a very significant
factor in Tcl/tk (one only has to look at the people who have contributed
to the tcl/tk archive). Furthermore, users can expect to meet the GNU
scripting language only on net-distriubuted software. One of the major
attractions of working with tcl/tk even in an academic environment is that
future commercial products may well include tcl and or tcl/tk and therefore
our home-written applications will mesh well with commercial applications.
2. Tcl/tk are available now, relatively bug free, well supported and are
in extensive use simply because they do the job for which they are intended
really rather well. Undoubtedly they can be improved upon, but arguing they
should NOT be used because at some time in the unstated future GNU will
provide (in their opinion and maybe in most peoples?) better tools seems
a poor argument indeed. While I think the GNU project provides excellent
tools, their ability to deliver service of course depends on the good will
of individuals which sometimes means exceptionally long lead times into
projects (g77 is one such example). In this respect the commercial input
to tcl and the focussed effort of the tcl community has led to excellent
"support", again a major factor in the popularity of tcl/tk.
3. What is a "large" project? I have now written about 20000 lines of
tcl used as complete X applications, embedded scripting language in our
own F77/C image processing and data processing codes. I have found managing
this size of project relatively easy and overall time to produce the finished
"products" significantly reduced over using C or F77 to accomplish the same
tasks. While this may not be a "large" project it is not insignificant and
is well within the scope of tcl/tk.
4. The quality of documentation of tcl/tk is of an exceptionally high standard,
far superior to any other free (and most commercial) products I have used.
For me this is significantly more important than whether tcl is syntactically
better/worse than XXX, or whether it is 50% 100% n00% slower/faster than XXX ---
the point is occasional users can write tcl/tk code if the have access to the
available documentation.
--
Paul Alexander
Department of Physics, Cavendish Laboratory,
University of Cambridge,
Cambridge, UK.
Jonathan Edwards
Richard Stallman <r...@gnu.ai.mit.edu> wrote:
>
>For these reasons, the GNU project is not going to use Tcl in GNU
>software. Instead we want to provide two languages, similar in
>semantics but with different syntaxes. One will be Lisp-like, and one
>will have a more traditional algebraic syntax.
If you want to make a dent in Tcl, you are going to have to be a lot more
specific about your plans. What and when?
Developing (two!) new languages will take years.
The world will not wait for you. I certainly won't.
If you want to be relevant, you will have to come up with some concrete
proposal of how to leverage existing technology to come up with an
alternative to Tcl quickly. You have that technology already: elisp!
Why not build an "algebraic" Tcl-like dialect on top of elisp?
You would want a "quote-by-default" semantics like Tcl that is optimized
for one-liners and trivial programs. But you would be able to call upon
the full generality of Lisp when needed.
Another view of the same idea: turn emacs into a windowing shell.
The primitives are for widgets instead of text editing.
--
Jonathan Edwards edw...@intranet.com
IntraNet, Inc 617-527-7020
One Gateway Center FAX: 617-527-6779
Thomas M. Breuel
| I would have to agree that as a programming language, Tcl sucks rocks
| when it comes to largish projects. It is an excellent tool for smaller
| projects (expect scripts, less complex Tk/Gui stuff) but Tcl is not
| something I would want to inflict on somebody as a standard.
|
| I also have to say that, personally, I think anything lisp-like is even
| worse, so this response should not be interpreted as being particularly
| for GNUs intentions. Perl comes closest to what I believe GNU wants
| but so far nothing fits the bill exactly, and I do not particularly
| like Perl's variable syntax either (though it's better then TCL's).
Whether you have to put a "$" in front of variable names, use prefix
rather than infix syntax for addition, or put parens before rather
than after the function name really makes very little difference in
practice.
But Perl and Tcl do have serious syntax-related problems in the areas
of syntactic overloading, error recovery, scoping, and quoting.
Lisp wins hands down in all these areas, having a few, simple rules.
The only problem with Lisp syntax is that it doesn't give new users
that "warm and fuzzy feeling" of familiarity.
Thomas.
D'Arcy J.M. Cain
: There is plenty of evidence, in the form of the many posts to
: comp.lang.tcl that express confusion about Tcl syntax. Lately the
: posts seem to be concentrating on unmatched braces in comments, but ""
: vs {} quoting is also a favorite.
Although I like Tcl I must admit that the comment processing does
bother me. It seems so counter-intuitive. From a perusal of the
code I also have to wonder why it is handled in the parser. This
seems like the kind of thing that should be in the scanner.
It would be great if there was some way to just turn off the comment
processing altogether. I already have a comment-processing function
that I use in every program I write for consistency in the script
or configuration languages I create. I could use it in Tcl but
there is always the danger that after proper comment processing (by
my standards) there is still a valid Tcl comment left.
Is there such a large body of Tcl code out there that this comment
processing issue is closed? I certainly have a hard time giving
this syntax to an end user. The rest may be explainable but if
programmers have trouble with that syntax then how can we use it
in a general purpose scripting language?
In any case why not take comments out of the language itself and
put it in the scanner.? That way Tclsh and wish can continue to
use the same syntax but we don't have to use it in our own code.
I would suggest doing the same with the line continuation stuff.
--
D'Arcy J.M. Cain (da...@druid.com) |
Planix, Inc. | Democracy is three wolves and a
Toronto, Ontario, Canada | sheep voting on what's for dinner.
+1 416 424 2871 (DoD#0082) (eNTP) |
Dan Connolly
Tcl has a peculiar syntax that appeals to hackers because of its
simplicity. But Tcl syntax seems strange to most users. If Tcl does
become the "standard scripting language", users will curse it for
years--the way people curse Fortran, MSDOS, Unix shell syntax, and
other de facto standards they feel stuck with.
I wholeheartedly agree. (See also:
"Why Tcl Doesn't Scale"
$Id: why-tcl-doesnt-scale.html,v 1.1 1994/06/20 16:47:53 connolly Exp $
http://www.hal.com/users/connolly/drafts/why-tcl-doesnt-scale.html
)
But first, I think RMS's article fails to give credit where credit is
due. Tcl is a great contribution and serves many purposes. Dr. John
Osterhout has written some excellent code which helps a lot of folks
get a lot of stuff done. I fear that the lack of acknowledgement
in RMS's article will spawn a great volume of flames... let's hope
not.
Now that that's done with... what will GNU software use? Where can I
find more details?
For example, tcl/expect is used in DejaGnu, the regression testing
tools. Tcl seems well suited to this task. Certainly expect is the
best available tool of its kind. Is the plan to replace tcl with some
other scripting language in that toolset? That would seem to imply
that all the test suites would have to be revised. (Is dejagnu
considered GNU software, or is it like gnuplot in that it just uses
the GNU name?)
I gather that scheme is a contender. I like schemes formal grounding,
but scheme standards (R^4RS etc.) leave a lot of parts of a software
development platform unspecified. As a result, scheme code tends to
not be portable between implementations. Unlike large bodies of
common lisp code, large bodies of scheme code tend to need "tweaking"
and "porting" to run on various scheme implementations.
* I'm not advocating common lisp.
** I don't have a lot of experience developing in scheme --
I've just looked at lots of net distributions.
Have folks looked at Scheme48? See:
"Scheme 48 home page"
http://www-swiss.ai.mit.edu/~jar/s48.html
Has python been considered? I like the language, though the
implementation has some limitations. (for details, see
comp.lang.python or
http://www.cwi.nl/ftp/python/index.html
)
Here are some of the issues I find important in a modern programming
language, with a comparison of some of the options:
Threads: for interactive programs -- especially distributed applications
which are now the rule more than the exception -- thread support
in the language/runtime greatly simplifies development
Modules: or packages or whatever: some mechanism to help maintain
the namespace is a must.
Continuations: the all-powerful construct from which anything can be
derived. Makes foreign-function interfaces a mess, though.
Perhaps continuations or even objects are enough...
Good FFI: Foreign Function Interface. A way to bind C functions.
"Good" in the sense that lots of folks have used it to
build useful applications.
Exceptions: You can't rely on a style of checking return codes for
building large, reliable programs.
RPC Support: Support for making calls across address spaces easily.
Embedded Languages:
Tcl Scheme48 Python Perl4 Obliq
Threads ???(1) YES YES(2) NO YES
Modules NO YES YES YES NO
Continuations NO YES NO NO YES
Good FFI YES NO YES NO YES
Exceptions YES YES YES YES YES
RPC Support YES NO YES(3) NO YES
(1) I think Tcl as a language is consistent with a multithreaded
implementation, but I don't think the current implemention
is thread-safe. Certainly there is no language support for threads.
(2) The python threads support is kinda funky and not too stable.
(3) Python includes support for automatic marshalling of basic types,
plus socket support. It's not a complete RPC system, but it's close...
"Systems programming" Languages:
CommonLisp C++ Modula-3
Threads NO NO YES
Modules YES YES(4) YES
Continuations NO NO NO
Good FFI ???(6) YES YES
Exceptions YES YES(5) YES
RPC Support NO NO(7) YES
(4) Using classes as namespaces is a messy hack.
(5) C++ exceptions are a messy hack.
(6) Various common lisp implementations probably have good FFI's.
(7) There are several C++ based RPC systems based on COBRA.
I also consider it important that the language lend itself to static
alalysis -- whether that means something like Modula-3's excellent
type system and strong static typing, or even scheme's formal
semantics and static scoping which make thinks like type inference and
program proving somewhat practical.
Static analysis enables things like code browsers and optimizing
compilers (or even source-to-source optimizers...). For an interesting
example, see the Modula-3 library source code at:
http://www.research.digital.com/SRC/m3sources/html/INDEX.html
Mow imagine doing that with a body of C++ code -- if the C preprocessor
was used with great discipline, perhaps. But in real life...
Dan
--
Daniel W. Connolly "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010
<conn...@hal.com> http://www.hal.com/%7Econnolly/index.html
Dirk Grunwald
The think the appropriate way to do this is to first create the
byte-code interpreter for the core language.
Rather than define specific features for the core language, it should
focus on inter-operability. For example, the core language should use
something like the OMG's version of 'IDL' to define interface
specifications. Automated tools could then generate stubs and
interface code. This simplies the process of 'importing' functionality
into the interpreter.
Much of this has already be demonstrated by the 'dish' interpreter
that comes with Fresco.
The remainder of the interpreter should be a simple Scheme-like-core
(static scoping, dynamic typing?, exceptions, garbage collection) --
the external syntax could be anything you want, but you need the
internal support before worrying about the external mechanisms. The
scheme-core is efficient and simple to evaluate, and there are a
number of public implementations. The Scheme2C system from DEC would
be a good start.
This would give you a lot of possibilities:
(1) The external syntax could be compiled to the core, and the
core and the program could be linked with an application if you
want a GUI builder w/o worrying about the users being able to
extend the application dynamically.
The "compiler" for the external syntax could provide considerably
more information and debugging information that the TCL
interpreter, because you wouldn't link it into applications.
The interpreter could be wicked fast.
You can also take things a step further and compile the 'core'
into a language like C, as the Scheme2C system does.
(2) You could build an parser/interpreter for the external language
that could be linked into the application if you want the ability
to extend the application.
(3) You could have a stand-alone "wish-like" tool that bundles the
interpreter and multiple utilities into one commonly-used tools.
By defining and documenting the internal core, you would let people
produce other front-ends to that language.
None of this is all that hard to do, it's simply doing it in a way
that's portable & documenting it that's hard.
Matthew Dillon
:>In article <3635a6$a...@apollo.west.oic.com> dil...@apollo.west.oic.com (Matthew Dillon) writes:
:>| I would have to agree that as a programming language, Tcl sucks rocks
:>| when it comes to largish projects. It is an excellent tool for smaller
:
:Whether you have to put a "$" in front of variable names, use prefix
:rather than infix syntax for addition, or put parens before rather
:than after the function name really makes very little difference in
:practice.
Good god, do you really believe that I would say what I said for
something that trivial?
:Lisp wins hands down in all these areas, having a few, simple rules.
:The only problem with Lisp syntax is that it doesn't give new users
:that "warm and fuzzy feeling" of familiarity.
:
: Thomas.
Oh, great, a fanatic. I won't even bother to argue the point except
to say that of all the lisp programs and programmers I know, the only
people who understand them (the programs) are the people that wrote
them. Assembly has a few simple rules too, and forth, but you do not
see me doing projects of half a million lines in them.
Paul Budnik
that different approaches make sense for different goals. Tools that
are simple to learn and easy to get things going quickly can be an
atrocious choice for complex projects. This does not mean the tool is
no good or should not be used. It only means it should be used only
in certain projects. Since little projects frequently grow into big ones
one needs to be careful in making such choices or be willing to start
over with a different foundation if the project goes beyond a certain point.
I want to advocate a different approach that is less general but can have
enormous advantages for certain projects. I just released ObjectProDSP
under the GPL (FTP sites are listed at the end of this message). This
is a tool for Digital Signal Processing (DSP) built on InterViews and
an extended C++ language called ObjectPro++. You can define interactive
classes of objects in much the way you define standard classes in C++.
The great advantage of this approach is that you can develop a new
application without writing *any* user interface code. You only need
to write the kernel process that operates on the data stream and to
describe the constructor parameters for the object and the types
of data streams the kernel can process. The ObjectPro++ class definitions
include a brief description of the class, a more elaborate description
and an optional help file. Similarly each parameter has a brief description
and an optional more elaborate description. These descriptions are used
to prompt the user for parameters and provide online help.
They are also used to create printed reference manuals.
A second advantage is the ability to use the same objects in a wide
range of applications. ObjectProDSP has a single plotting class that
can deal with one or two dimensional data streams (two dimensional
streams are typically the output of an FFT). It can handle real or
complex data or for that matter an arbitrary number of scalar values
in each sample. The user does not need to set any of these parameters.
The plot class reads the description of the type of data on its input
channel and configures itself accordingly. One can easily rescale the
plot or get a power or decibel scale view. There are a number of classes
for reading files with different data formats, a general node for listing
streams and a variety of signal generation nodes. This machinery is
available and automatically integrated for any new application from
the ObjectPro++ description.
A third advantage is the uniform user interface that applications developed
in this way share. A menu data base makes it easy to get a description
of a class and its constructor parameters, create or delete instances
of the class, graphically edit instances into a network and see all instances
and their parameters. Objects are persistent between sessions. They are
saved as C++ constructor calls. Networks of objects are defined with
the operators `>>' and `+' and also saved as C++ code. This file is
easy to edit manually if desired.
A final advantage is that you can obtain both interactive and stand alone
versions of your application from the same source. ObjectPro++ translates
its input into both interactive and stand alone C++ code. You can build
a network interactively and then generate a stand alone executable of that
network.
C++ was crucial to making all of this work. It would not be practical to
develop a tool like this in a lesser language. However you do not need
to know C++ to use this tool. Everything can be controlled by menu
selections and response to prompts.
Although released under the GPL my goal is to build a business out of this
product by also selling commercial licenses. I would like to see a hybrid
software business develop where the source code is freely available but
that source code is also used in commercial applications and that
finances development of more free software.
Paul Budnik
Mountain Math Software
ObjectProDSP is available at SunSITE.unc.edu in directory
/pub/Linux/devel/opd and at ftp.funet.fi in directory
/pub/OS/Linux/util/electronics/opd. Please use the mirror
site nearest you.
Kai Petzke
>[Please redistribute wherever appropriate.]
> Why you should not use Tcl
> Richard Stallman, GNU Project
Dear Mr. Stallman,
you just forgot three words in your "Subject:" and heading. The
correct formulation reads:
Why you should not use Tcl for GNU Projects
And then, you could argue, why Tcl is bad for GNU. But Tcl has other
uses, where you do not need speed, but where you can exploit tcl's
scripting powers, its orthogonality, its ...
Kai
--
Kai Petzke | How fast can computers get?
Technical University of Berlin |
Berlin, Germany | Sol 9, of course, on Star Trek.
w...@marie.physik.tu-berlin.de |
Blair MacIntyre
FYI. I'm not alone in my severe dislike of TCL.
>>>>> On Fri, 23 Sep 94 19:14:52 -0400, r...@gnu.ai.mit.edu (Richard
>>>>> Stallman) said:
rms> [Please redistribute wherever appropriate.]
rms> Why you should not use Tcl
rms> Richard Stallman, GNU Project
rms> As interest builds in extensible application programs and tools,
rms> and some programmers are tempted to use Tcl, we should not forget
rms> the lessons learned from the first widely used extensible text
rms> editor--Emacs.
rms> The principal lesson of Emacs is that a language for extensions
rms> should not be a mere "extension language". It should be a real
rms> programming language, designed for writing and maintaining
rms> substantial programs. Because people will want to do that!
rms> Extensions are often large, complex programs in their own right,
rms> and the people who write them deserve the same facilities that
rms> other programmers rely on.
rms> The first Emacs used a string-processing language, TECO, which
rms> was inadequate. We made it serve, but it kept getting in our
rms> way. It made maintenance harder, and it made extensions harder
rms> to write. Later Emacs implementations have used more powerful
rms> languages because implementors learned from the problems of the
rms> first one.
rms> Another lesson from Emacs is that the way to make sure an
rms> extension facility is really flexible is to use it to write a
rms> large portion of the ordinary released system. If you try to do
rms> that with Tcl, you will encounter its limitations.
rms> Tcl was not designed to be a serious programming language. It
rms> was designed to be a "scripting language", on the assumption that
rms> a "scripting language" need not try to be a real programming
rms> language. So Tcl doesn't have the capabilities of one. It lacks
rms> arrays; it lacks structures from which you can make linked lists.
rms> It fakes having numbers, which works, but has to be slow. Tcl is
rms> ok for writing small programs, but when you push it beyond that,
rms> it becomes insufficient.
rms> Tcl has a peculiar syntax that appeals to hackers because of its
rms> simplicity. But Tcl syntax seems strange to most users. If Tcl
rms> does become the "standard scripting language", users will curse
rms> it for years--the way people curse Fortran, MSDOS, Unix shell
rms> syntax, and other de facto standards they feel stuck with.
rms> For these reasons, the GNU project is not going to use Tcl in GNU
rms> software. Instead we want to provide two languages, similar in
rms> semantics but with different syntaxes. One will be Lisp-like,
rms> and one will have a more traditional algebraic syntax. Both will
rms> provide useful data types such as structures and arrays. The
rms> former will provide a simple syntax that hackers like; the latter
rms> will offer non-hackers a syntax that they are more comfortable
rms> with.
rms> Some people plan to use Tcl because they want to use Tk.
rms> Thankfully, it is possible to use Tk without Tcl. A Scheme
rms> interpreter called STk is already available. Please, if you want
rms> to use Tk, use it with STk, not with Tcl. One place to get STk
rms> is from
rms> ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
--
Blair MacIntyre -- b...@cs.columbia.edu -- Graduate Student (Graphics and UI Lab)
smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St.,
Columbia University, New York, NY 10027
Robert DeLine
Mathew Dillon writes;
> However, the largest of these GUI elements rapidly bogged down in several
> areas as it was being coded.
I would like to second Mathew Dillon's experience with my own.
I'm a very practical guy and am willing to use whatever works, especially
when it comes to programming languages. So in order to do a prototype of a
user interface, I went with Tcl/Tk since it's popular, well documented,
fast, portable, etc. It turns out that Tk is everything I wanted, but Tcl
became a problem for two reasons: no support for data structures and no
support for structuring large programs. After a few thousand lines of Tcl
code, I spent most of my time just trying to get my program to hold
together and trying to map and unmap my data structures to strings. In the
end I switched to STk and have not regretted it -- not because I'm a Lisp
bigot (I hate all those parens as much as the next guy), but because it's
the interpreted language with the best access to Tk. Also note that when
trying to re-code my Tcl program in Stk, I found it very difficult to
discern what some of the Tcl code was doing after not looking at it for a
few months (and yes, it was well structured and commented).
Ultimately I think this is what Stallman is getting at. He didn't flame
Tcl as a general tool, but he warned that it isn't a good tool as an
extension language. Most Tcl programmers make up for Tcl's shortcomings
by dropping down into C; this just isn't appropriate with an extension
language. If you look carefully at this article, you'll notice that his
complaints echo mine above:
It lacks arrays; it lacks structures from which you can make linked
lists. It fakes having numbers, which works, but has to be slow.
Tcl is ok for writing small programs, but when you push it beyond
that, it becomes insufficient. [Stallman]
Perhaps his complaints do not represent his actual experience programming
in Tcl (and for that he can be criticized), but Mathew Dillon and my
separate experiences reflect that his comments are not totally out of line.
If other programmers out there have had experience (good or bad) using Tcl
for actual projects, I'd much rather hear about them than hear these random
flames.
Rob DeLine
Drew Justin Asson
battle that's starting, but I can't ignore several people's comments
about not being able to structure data in Tcl, etc....
There are many extensions to the language that provide very nice
data abstraction. One that we use is [incr Tcl], also called itcl.
It provides an object oriented extension to Tcl with classes, methods,
private, public, and common data, etc. We've found it very nice and very
quick. Large Tcl programs can be written using this without running into
the mess that Stallman and others are claiming is inevitable.
Along these lines, ** ANY ** programming language can be used to develop
horrible, spaghetti code which constantly falls apart. LISP, Scheme, C,
C++, or any language, does not prevent you from writing poor functions, using
global variables, etc.
Tcl and its extensions are not the be all end all of languages. It is
a great language for small to medium projects and its Tk extension provides
quick and easy extensibility into adding GUI's to applications. Tcl is a good
glue (as Ousterhout says in his book) for putting together lots of applications
and uniting them with a GUI. This doesn't mean that everything has to be
written in Tcl. I've been developing LISP code for real systems since 1990
and have been writing C since 1987. I've learned that mono-language systems
might be good for small in-house efforts, but each language offers subtle
nuances that are very useful. Writing a system that incorporates C, Lisp,
Tcl, perl, etc. is not a bad thing.
Drew
--
===================================
Drew J. Asson
AI Sr. S/W Engr - APSB
Space Telescope Science Institute
(410) 338-4474, Fax: (410) 338-1592
===================================
STScI: as...@stsci.edu
Newton: DrewJAsson (@eworld.com)
===================================
Dave Probert
>[T. William Wells]
>| Mr. Stallman, though I am but an occasional user of tcl, I am
>| sufficiently familiar with it to know that you don't know enough about
>| it to have an informed opinion. Rather than embroiling myself in the
>| flamewar that your specious claims are sure to cause, I'll just observe
>| that that sort of politicking is utterly contemptible.
>I found the above utterly contemptible. let the first man with a gas can
>and a lighter be responsible for the flame war, not he who states his
>opinions, however unpopular.
While it may seem appropriate to some to treat RMS with kidgloves because
of the valuable contributions GNU has made, there is reason to be unhappy
with the way RMS approached this.
For one thing he wasn't just 'stating his opinions', but speaking on
behalf of the GNU project -- announcing policy -- and attempting to
throw a wet blanket on the use of GNU by others.
Ever since I first heard about GNU I have had the expectation that Orwell's
critique of socialism in Animal Farm would be applicable one day. Will
we trade one set of masters for another? Let RMS have his opinions (and
if his opinions ultimately are a setback for GNU -- well, if it weren't
for RMS there would be no GNU anyway) ...
But why not let RMS have the burden of defending his opinions rather than
attacking those who challenge them? He is obviously not shy.
Perhaps you don't see Stallman's remarks as politicking, but if it was not
his intention to discourage use of TCL, then what was his purpose?
--
Dave - pro...@cs.ucsb.edu
Ron Natalie
: not be a mere "extension language". It should be a real programming
: language, designed for writing and maintaining substantial programs.
: Because people will want to do that!
I've been working with EMACS for as long as the lisp-ized version of
has been around and with the hoarded versions of Gosling and UniPress
before that. This conclusion is not clear to me. Yes, if you leave
your application largely unfinished such that it becomes a development
environment in itself, you need a decent extension language to write
the customized applications in. Unfortunately, most of these pidjin
lisps are barely up to the job either. A truly decent development
environment is lacking.
: Extensions are often large, complex programs in their own right, and
: the people who write them deserve the same facilities that other
: programmers rely on.
However, how many of your applications are going to end up being kitchen
sink text editors? 99% of your applications are better designed to be
targetted at what the customer wanted to begin with (of course, delivering
what a customer wantes is obviously not a goal of the GNU project, as
we are still forced to deal with the backspace key being bound to the
help key by default, which leads you into an obtuse help system that
requires more time to figure out how to use than a typical user is
willing to invest in the problem he was originally trying to solve).
We went on to fancier scripting/control/extension languages. Did most
of our application in an object oriented one, we though it was great.
The users hate it. It's too complex for the average casual researcher
needing to hack a few commands in sequence. It is a mistake to view
these people as programmers. They want simple (they think visual basic
would be an ideal extension language).
The bottom line, and this has been shown time and time again.
NOBODY CARES HOW HARD IT WAS TO DEVELOP A PACKAGE. THE MEASURE IS
HOW EASY IT IS FOR THE USER TO DO SOMETHING WITH IT.
I come to feel that the major problem RMS finds with Tcl is that it
doesn't come with the overly restrictive GNU licensing terms nor any
other FSF sanction. It seems that sometimes RMS feels it's more important
to stifle development of code other than those he blesses than to promote
the concept of software freedom he claims as his primary goal).
-Ron
Douglas E. Smith
In article <940923231...@mole.gnu.ai.mit.edu>, Richard Stallman (r...@gnu.ai.mit.edu) writes:
*snip*
>
>Extensions are often large, complex programs in their own right, and
>the people who write them deserve the same facilities that other
>programmers rely on.
>
*snip*
This paragraph seems to sum up rms's objections to tcl. I cannot
disagree. However, tcl/tk exists, is useful, does not take that
long to learn, and is well suited to the class of problems that
Ousterhout envisioned for it,and can be extended. Also, it is not
encumbered by the FSF/GNU copyright.
When the GNU equivelents with their, I have no doubt, superiour
extension language(s) become availible, people will adopt them.
Until then, existing tools trump nonexistant tools.
Also, in the meantime, please....no holy wars people. They are a
waste of time and bandwidth.
As a disclaimer, I feel a bit like a little leaguer commenting on
Reggie Jackson's batting style. And I will look into STk.
--
Doug Smith "It may well be better to be a live sheep
Technology Shop than a dead lion. It is better still to
be a live lion. And usually easier."
On the other hand, eagles soar, but weasels
don't get sucked into jet engines.
Perry Hutchison
> Why you should not use Tcl
The first I heard of Tcl was in connection with Don Libes' "expect"
program, which I understand to be somehow based on or otherwise related
to Tcl. I know "expect" only by reputation, and even less about Tcl,
but it from what I have read "expect" seems like a most useful program
for certain situations. I'd like to know if the GNU project has any
recommendations of a non-Tcl alternative to "expect".
Please include comp.lang.tcl in any followups to this posting, as it is
the only one of the listed groups which exists on this system.
rodrigo vanegas
But why not let RMS have the burden of defending his opinions rather than
attacking those who challenge them? He is obviously not shy.
Perhaps you don't see Stallman's remarks as politicking, but if it was not
his intention to discourage use of TCL, then what was his purpose?
To encourage the design, implementation, and use of superior extension
languages. The reason this was expressed by discouraging the use of
TCL is that if TCL becomes too popular then we'll all be forced to use
it in the effort to be compatible. I think the idea is to switch to a
better tool while TCL is still growing and not yet a de facto
standard. As for what is a better tool, this depends on what you
want. See the following recent post for a good analysis.
<CONNOLLY.94...@austin2.hal.com>
Note that TCL is still sometimes the only tool for the job. Let's
hope this doesn't remain the case for long. Also, don't get so worked
up about RMS. Complaining about the style of his post if like
complaining about Reagan for his occasional quips about the evil
empire. Whatever...
rodrigo vanegas
r...@cs.brown.edu
Barry Merriman
> but so far nothing fits the bill exactly, and I do not particularly
> like Perl's variable syntax either (though it's better then TCL's).
>
The problems I see with perl are that: (1) it has an unnecessarily complicated/ugly
syntax and name space conventions, that tends to lead to obfuscated
code (though not as obscure as sed,awk,sh code) and (2) It also seems to be a
rather derivative language---it essentially just collects together
all the useful features found in
-shell languages,
-standard unix commands,
-unix C system routines,
-standard C libraries
and rolls them into one big interpreted, system independent language.
That may be nearly ideal if your goal is to write unix system administration routines
and portable across unices scripts. But that is probably a poor basis
for a general purpose programming language; such a language should have
a general basis and a library devoted to the points above, not
the other way around.
Matt: are you familiar with Python? (as in comp.lang.python). Given your
considerable experience, I'd like to know what you think of it.
--
Barry Merriman
UCLA Dept. of Math
UCLA Inst. for Fusion and Plasma Research
ba...@math.ucla.edu (Internet) ba...@arnold.math.ucla.edu (NeXTMail)
Brian Mancuso
>
>Dear Mr. Stallman,
>
A couple of observations regarding gnu.misc.discuss:
a. If rms declared one day that the sky was blue, half of you
would deny it.
b. Obviously there is not enough room in this conference for all
of the big egos. In an effort to alleviate the strain, I propose
two conferences: gnu.misc.discuss-e for those _with_ the
inferiority complex, gnu.misc.discuss for those without.
c. Rational academic scrutiny, productive logical thought, and
constructive criticism have all but been tossed aside to make
way for hasty, flustered, ill-considered, baseless, flaming
condemnations of a respected man's un-clouded and factual
account of reality.
Observation of this conference alone is enough to conclude that one is
quick to knock down those that stand on pillars.
Brian Mancuso
bri...@cs.bu.edu
Daniel F Boyd
Ron Natalie <r...@myhost.subdomain.domain> wrote:
> delivering what a customer wantes is obviously not a goal of the GNU
> project, as we are still forced to deal with the backspace key being
> bound to the help key by default
i.e. "Everybody else who contributed to GNU made something
that I personally don't like, because of this one keybinding."
Gay David
In article <KFOGEL.94S...@ninja.life.uiuc.edu> kfo...@ninja.life.uiuc.edu (Karl Fogel) writes:
In article <SCHWARTZ.94...@groucho.cse.psu.edu> schw...@groucho.cse.psu.edu (Scott Schwartz) writes:
>Lists have O(1) append time. Tcl strings have O(n) append time.
>Superquadratic runtime and lots of memory thrashing results.
I thought lists have O(N) append time too. I mean, you have
to copy a whole list in order to append it to something else. Even in
a destructive append, you still have to find the final cdrs, which
means bouncing down the whole list.
But you can prepend 1 element to a list in O(1) time (ie cons). Also
append is O(length of list added), not O(sum of lengths). Of course,
you can implement strings as lists (don't some Lisps do this ?) ...
David Gay
dg...@di.epfl.ch
Scott Schwartz
But you can prepend 1 element to a list in O(1) time (ie cons).
And you can cache a pointer to an arbitrary cell (such as the tail),
hence list update takes constant time.
Kai Petzke
>In article <wpp.780520697@marie>,
>>
>>Dear Mr. Stallman,
>>
>A couple of observations regarding gnu.misc.discuss:
I can not figure out, what you want to say. RS posted his article
to three groups. Only one of them is gnu.misc.discuss. Another
one is comp.lang.tcl. And posting an article "Why you should not
use Tcl" is always prone to ignite a flame war.
I tried to show in my article, what Stallman made wrong in his
post. But actually, you deleted the body of my message when
quoting me, perhaps taking it for pure flame bait, and putting
your general "observations" in.
[observations deleted - they are about a group I do not read]
>Observation of this conference alone is enough to conclude that one is
>quick to knock down those that stand on pillars.
In the comp.lang.tcl group, John Ousterhout is the one on the pillars.
And actually, I have not seen any flame against him.
Michael Salmon
hfi...@shell.portal.com (Hal) writes:|> > Richard Stallman, GNU Project
|>
|> Stallman's article seems short on specific criticisms. I see:
[...]
|> 3) Tcl lacks structures from which you can make linked lists.
[...]
|> 3) Tcl has no pointers, and shares this property with most LISP like
|> languages. Deeply nested list structures can be created, though, which
|> provide much of the functionality of linked lists.
I think that Tcl has pointers because you can have the name of a
variable in a variable and then use eval or upvar to access it.
I also think that you forgot to include that Tcl wasn't developed at
MIT or FSF.
--
Michael Salmon
#include <standard.disclaimer>
#include <witty.saying>
#include <fancy.pseudo.graphics>
Ericsson Telecom AB
Stockholm
Michael Salmon
da...@druid.com (D'Arcy J.M. Cain) writes:
|> Tom Tromey (tro...@klab.caltech.edu) wrote:
|> : There is plenty of evidence, in the form of the many posts to
|> : comp.lang.tcl that express confusion about Tcl syntax. Lately the
|> : posts seem to be concentrating on unmatched braces in comments, but ""
|> : vs {} quoting is also a favorite.
|>
|> Although I like Tcl I must admit that the comment processing does
|> bother me. It seems so counter-intuitive. From a perusal of the
|> code I also have to wonder why it is handled in the parser. This
|> seems like the kind of thing that should be in the scanner.
The problem is that the scanner then needs to be more complex, in fact
duplicating some of the scanner's work. You need to decide if the
comment is a comment or quoted e.g. puts "#"
[...]
|> In any case why not take comments out of the language itself and
|> put it in the scanner.? That way Tclsh and wish can continue to
|> use the same syntax but we don't have to use it in our own code.
|> I would suggest doing the same with the line continuation stuff.
I haven't checked the code but I think that the line continuation stuff
is in the scanner.
Personally I don't see the problem with Tcl's rules, they are IMHO very
simple and once you understand them easy to follow. I am a little
surprised that no-one has complained about the necessity of commands
starting on the same line as it's associated keyword:
proc a
{b}
{
puts $b
}
is wrong, even if it is allowed in C.
Andy Newman
>Tcl also wasn't designed to be used in a vacuum, but to be embedded
>into a larger application. The ease with which this can be done is its
>primary strength.
I'd say that the Tcl's C interface is its only strength. Tcl may be okay
for writing ten liners but rms is really correct in stating that it is
not really suitable for some of the larger things that it is being applied
to.
>If the language lacks features you desire, add them.This, too, is relatively
>easy to do.
Why spend effort fixing broken things when there are better solutions out
there? (See the catalog of freely available compilers/interpreters for a
full list).
--
Andy Newman (an...@research.canon.oz.au) (Not a Canon spokesperson)
"If business is war, the computer business is thermonuclear war". Ted Lewis.
Jay Maynard
>NOBODY CARES HOW HARD IT WAS TO DEVELOP A PACKAGE. THE MEASURE IS
>HOW EASY IT IS FOR THE USER TO DO SOMETHING WITH IT.
BINGO!
This is the primary problem with computing today: a complete loss of focus
on the customer. People perpetrate word-processing packages that take up 35
megabytes of hard disk space, and code slow programs in C++ with tremendous
amounts of overhead, and develop Unix-based systems, just because they're
more concerned about religious programming style issues or ease of
development than giving the customer what he needs.
>I come to feel that the major problem RMS finds with Tcl is that it
>doesn't come with the overly restrictive GNU licensing terms nor any
>other FSF sanction. It seems that sometimes RMS feels it's more important
>to stifle development of code other than those he blesses than to promote
>the concept of software freedom he claims as his primary goal).
This is news? It's obvious that RMS thinks that his utopia is somethign that
all programmers should aspire to, whether or not they agree - so if they can
be forced in that direction, so much the better. One need read no farther
than the GNU Manifesto and the General Public Virus to see that.
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmay...@admin5.hsc.uth.tmc.edu | adequately be explained by stupidity.
The US Constitution: 1789-1994. RIP.
Juergen Nickelsen
Petzke) writes:
[...]
> I can not figure out, what you want to say. RS posted his article
> to three groups. Only one of them is gnu.misc.discuss. Another
> one is comp.lang.tcl. And posting an article "Why you should not
> use Tcl" is always prone to ignite a flame war.
But that doesn't mean you should start it.
Although I do not always agree with Richard Stallman's opinions and
attitudes, I see that he quite accurately points out the major
weaknesses of Tcl (with one exception not mentioned: the quoting
problem).
Lots of people, including me, benefit a lot from the availability and
excellent implementation of Tcl and Tk. Nevertheless these weaknesses
still exist and deserve to be discussed. As far as I have seen the
discussion following Richard Stallman's article is fortunately very
fact-oriented and constructive.
BTW, I am posting this as a reader of comp.lang.tcl.
If necessary, please reply by email, not to the newsgroups.
--
Juergen Nickelsen
Mark Weissman
bigger it got, the slower and harder to deal with it became. Lack of
descent data types, a way slow parse/eval semantics and code that isnt
checked even a little before eval time make it a bit of a headache.
Now that I've got a ton of it that works (slowly) I really dont want
to go through the effort of porting it to C. Tk is great, and tcl
seemed like a good prototype system but it totally lacks a path from
prototype to product. Its a better time now to replace TK with a
language with a future than when we're all stuck with it as the "Lingua
Franca" of the internet... *sigh*
Mark Weissman
weis...@gte.com
--
Ken Corey
: [Please redistribute wherever appropriate.]
: Why you should not use Tcl
: Richard Stallman, GNU Project
Geez, Richard. You blew it with this one.
Does this remind anyone else of an individual whose initials are BG?
Does GNU = MS?
Feh.
--
Ken Corey exu...@exu.ericsson.com 214/907-5841 Speaking for everyone...
"When I was crossing the border into Canada, they asked if I had any
firearms with me. I said, `Well, what do you need?'"
-- Steven Wright
Fred L Drake Jr
Scott Schwartz <schw...@groucho.cse.psu.edu> wrote:
>They are not first class objects: you can't assign one to another, pass
>or return them from functions. Contorted "call by name" semantics are
I agree with you on this one, but:
> 3) Tcl has no pointers, and shares this property with most LISP like
> languages. Deeply nested list structures can be created, though, which
> provide much of the functionality of linked lists.
>
>Lists have O(1) append time. Tcl strings have O(n) append time.
>Superquadratic runtime and lots of memory thrashing results.
I've never seen a Lisp/Scheme implementation with O(1) list catentation/
appending. Though the list need not be copied, it does need to be traversed.
Implementing a list as a vector with extra space reserved at the end to allow
for appended elements is good for amoritizing the cost of appending, reducing
the time complexity below O(n).
Tcl string-based "lists" don't need to be traversed to append an element,
but are O(n) due to the copying involved. As the dynamic strings are used
more internally this might become amortized, reducing the real cost of list
operations.
Typically, LISP has pointers, they're simply not called that because what's
at the "other end" has a more specific data type, and that's what's actually
important to the code. Besides, allowing free access to the actual pointers
is typically a bad idea.
Personally, I'd like the Tcl internals become more LISP-ish, simply for
performance and convenience reasons. The text representation would not need
to be changed. In fact, the existing C interface would not need to be
changed either; just the "Tcl inside."
Not trying to start a war, just making my own observations.
-Fred
Cary B. O'Brien
>doesn't come with the overly restrictive GNU licensing terms nor any
>other FSF sanction. It seems that sometimes RMS feels it's more important
>to stifle development of code other than those he blesses than to promote
>the concept of software freedom he claims as his primary goal).
>
>-Ron
>
Cary O'Brien
cob...@access.digex.net
Rich Neitzel
|>
|> Question2: doesn't Python essentially provide what RMS wants?
|> Why doesn't GNU just adopt Python as its defacto language?
|>
Hear, hear! Quite agree. Python is a nice, easy to learn, powerful
langauge.
--
Richard Neitzel th...@atd.ucar.edu Torren med sitt skjegg
National Center For Atmospheric Research lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000 Gjø'i med sitt shinn
303-497-2057 jagar borni inn.
Kevin K. Lewis
This is news? It's obvious that RMS thinks that his utopia is somethign that
all programmers should aspire to, whether or not they agree - so if they can
be forced in that direction, so much the better. One need read no farther
than the GNU Manifesto and the General Public Virus to see that.
An unbiased post if I ever saw one!
--
Kevin K. Lewis | My opinions may be unreasonable
lew...@aud.alcatel.com | but such is the voice of inspiration
Robert Withrow
dil...@apollo.west.oic.com (Matthew Dillon) writes:
|> I would have to agree that as a programming language, Tcl sucks rocks
|> when it comes to largish projects.
Does anyone with *direct* experience (as opposed to loud opinions on
the morality of criticising TCL) in this know if ``itcl'' or something
similar helps enought to overcome this objection?
Aside: I suggest that criticisms about the durability of Tcl in larger
projects be taken seriously, even by Tcl boosters (of which I am one).
I remember when Pascal was proclaimed the one-true-language-for-everything.
I also remember when C was criticized as being deficient for large projects.
I think most people will agree that Tcl *does* have problems WRT larger
projects. But is that flaw terminal?
--
Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430
R.W. Withrow Associates, 319 Lynnway, Lynn MA 01901 USA, Net: wi...@rwwa.COM
Hank Walker
easier to extend Tcl than other extension languages. A second point is
that Tcl ports to the Mac and Windows environments already exist, but I
see relatively little use of GNU software on these platforms. Indeed, the
GNU project is philisophically against any support of these environments.
Finally, as was pointed out repeatedly in the 1994 Tk/Tcl workshop, the
primary use of scripting/extension languages will likely be for agents on
the net. These agents are unlikely to be large programs, and most hosts
will be Macs and PCs. This combination gives the discussion a little bit
of the flavor of which is the best fiddle to use while Rome burns. The
real alternatives to Tk/Tcl is not STk, but Visual Basic, Visual C++,
AppleScript, and maybe TeleScript. Usage of the Microsoft and Apple tools
already vastly exceeds Tk/Tcl. Given that many of my university and
industry colleagues are relegating UNIX to servers, a UNIX-only focus is a
sure way to marginal status.
There are a large number of developers who would like to support all three
platforms to increase market share, but currently the cost is often not
worth it. Tk/Tcl provides the first realistic chance of doing so, and I
think when robust ports are available, there will be a large increase in
Tk/Tcl usage. Witness the many requests for Mac and PC ports, questions
about when they will be available, etc. The major threat to this would be
a Microsoft port of the Visual tools to the Mac.
P.S. I've used TECO, all versions of Emacs, and lots of different
extension languages, and have come to the conclusion that widespread
support, particularly in terms of third party additions, is the dominant
factor in determining success. Not pretty syntax, pretty semantics, etc.
--
Duncan M. (Hank) Walker
wal...@cs.tamu.edu
Mr. Yeung Chee Wai
: > >it should be possible to discuss the merits and demerits of RMS's statement
: > >on Tcl without resorting to such flames.
: >
: > Right on.
: Agreed! But in case anyone is keeping count: Richard -- respectfully
: don't agree...
: Tcl has its place in the world.
: --
: no rest for the wicked...
--
Chee Wai
-----------------------------------------------------------------------------
Yeung Chee Wai Email: che...@HK.Super.NET
Gregor Schmid
>Lists have O(1) append time. Tcl strings have O(n) append time.
>Superquadratic runtime and lots of memory thrashing results.
I thought lists have O(N) append time too. I mean, you have
to copy a whole list in order to append it to something else. Even in
a destructive append, you still have to find the final cdrs, which
means bouncing down the whole list.
Of course, the final list that gets stuck on the end happens
in O(1) time; it's just all the other ones that don't...
I could be wrong, though, or have misunderstood. Please feel
free to correct me if so.
This is only partly true. You may carry around a pointer to the end
of the list from a prior calculation and thus get an O(1) append time.
This is the general case where it matters, e.g. when you are building
a list.
In Tcl, even if you know the position of the final element of a "list"
you can't reference it in a way that saves you the effort of traversing
the whole string, thus you always have O(N) append time.
Regards,
Greg
Robert Withrow
|> a. If rms declared one day that the sky was blue, half of you
|> would deny it.
Well gee. That means that 50% of us agree. That is a pretty good
approval rating these days.
Of course, RMS frequently claims that the sky is tartan-plaid, and
50% of *you* agree with him.
And he has been known to claim that the sky is full of pot-bellied
pigs, and they are falling. Thankfully only 48% of us agree with that.
Will Morse
>r...@gnu.ai.mit.edu (Richard Stallman) writes:
>> Why you should not use Tcl
>> Richard Stallman, GNU Project
>
>
>
>2) Tcl lacks arrays.
>
>3) Tcl lacks structures from which you can make linked lists.
>
>
>5) End-users do not like Tcl syntax.
>
[Thanks to Hal for explaining what RMS was blithering about]
Well, I'm probably wading in deeper than my waders, but as a geoscientist
(e.g., end-user) that writes a few odd programs so we don't have to hire
an MIS Department, I feel I can comment on point 5 anyway.
I have written several programs in Tcl/Tk in the 1,000 line range. These
are real programs that do real work, not demos or trivial utilities
(although I have a number of these as well). These programs do some
math, a little trig, nothing as complex as a matrix inversion.
I have run into a few notions that confused me at first, such as leading
zeros indicating an octal number, but once I got the answer, I have
had very few problems implementing some pretty good programs. I have
received FAR BETTER SUPPORT from this newsgroup than I ever got from
any computer department or vendor help line I have ever used.
I do not know what a "serious programming language" (point 1) is, but
I have some pretty serious applications that work very well in Tcl/Tk.
I get them done fast and cheap in my "copious spare time" and still have
time to do my real job.
My programs use arrays (point 2), I don't know what RMS is talking about.
I never use linked lists (point 3), but it seems to me the Tcl associative
array could do that.
Tcl is slow (point 4). X11R4 and OpenWindows were slow. Drawing pictures
across the ethernet is slow. What's your (RMS') point? When I need speed,
I call a perl script using exec. I could probably call a Fortran or
C program just as easily. You don't have to write the whole program
in one language. Use the whole toolbox, you don't need to use a
screwdriver to pound a nail when there is a perfectly good (and FREE)
hammer just sitting there.
It's a true and simple fact that I probably wouldn't use Tcl except for
Tk. It's just as true that I wouldn't use perl except for its advanced
regular expressions, ability to handle binary files, and a few other nice
features. Maybe when Tkperl-5 comes off beta, I will have everything
in one place. I don't know. I do know that there are others in my
shop who use Tcl/Tk, but I am the only perl user.
So, in summary, I say, Keep up the good work John, and Thanks from all
us "end-users" put here.
Will
--
# Gravity, # Will Morse
# not just a good idea, # BHP Petroleum (Americas) Inc.
# it's the law. # Houston, Texas
# # wi...@starbase.neosoft.com
#
# These are my views and do not necessarly reflect the views of BHP !
Steve Madere
Robert DeLine <rdel...@CS.CMU.EDU> wrote:
>
>Mathew Dillon writes;
>> However, the largest of these GUI elements rapidly bogged down in several
>> areas as it was being coded.
>
>I would like to second Mathew Dillon's experience with my own.
>
>I'm a very practical guy and am willing to use whatever works, especially
>when it comes to programming languages. So in order to do a prototype of a
>user interface, I went with Tcl/Tk since it's popular, well documented,
>fast, portable, etc. It turns out that Tk is everything I wanted, but Tcl
>became a problem for two reasons: no support for data structures and no
>support for structuring large programs. After a few thousand lines of Tcl
>code, I spent most of my time just trying to get my program to hold
>together and trying to map and unmap my data structures to strings.
You guys have obviously not seen [incr Tcl].
It is AWESOME.
I have been using Tcl for a scripting language for two years now and
I was just about to reach the limits myself. Then I tried [incr Tcl].
It's amazing what a relatively simple extension can do for your
programs.
It takes about three to five hours to get into [incr Tcl] if you are
an experienced Tcl programmer and it saves you TONS of time.
I strongly recommend that EVERYONE try it out. Pick up a copy and
just try it. I think you'll like it.
[Incr Tcl] is a REAL solution to the namespace pollution problem. It also
makes for very elegant code. Because Tcl in interpreted, [incr Tcl]
actually achieves what C++ wants to do but can't.
It provides local data structures, overloading, multiple inheritance.
I even created a Record class that mimics a struct (using an
associative array to hold the members with the field names as indices).
Then many of my data-intensive classes just inherit from this and
voila, data structures. As for linked lists, that's incredibly easy
in [incr Tcl]. All you need is two public variables next and prev
in your object. Make these hold the NAMES of the objects which
are next an previous in the list. One doesn't necessarily need
binary memory address to function as a pointer.
Just remember to use [incr Tcl] classes for everything, not just
for widgets. And remember to make your classes general and widely
useful and post them to the archive so we can all benefit from
code reuse. :-)
Steve Madere
Stefan Monnier
Paul Alexander <p...@mrao.cam.ac.uk> wrote:
> 3. What is a "large" project? I have now written about 20000 lines of
> tcl used as complete X applications, embedded scripting language in our
> own F77/C image processing and data processing codes. I have found managing
> this size of project relatively easy and overall time to produce the finished
> "products" significantly reduced over using C or F77 to accomplish the same
> tasks. While this may not be a "large" project it is not insignificant and
> is well within the scope of tcl/tk.
Finally !
The actual reason why people like Tcl is the one given above:
when you're stuck with jurassic park's style of languages (C, F77,
..), even tcl is god sent !
Of course, when you're used to higher level languages, with module
systems, exceptions, powerful data structure handling (OO or closure
based, I don't really care) and lexical scoping, tcl really looks like
shit !
Stefan
PS: I still don't understand why RMS hasn't yet admitted elisp's
limitations though !
Thomas Werthmann-Auzinger
Richard Stallman <r...@gnu.ai.mit.edu> wrote:
> Why you should not use Tcl
> Richard Stallman, GNU Project
I'd like to:
- comment on Richard's remarks
- address some issues that I haven't seen anywhere else
- refrain from addressing issues that have been dealt with elsewhere
>The principal lesson of Emacs is that a language for extensions should
>not be a mere "extension language". It should be a real programming
>language, designed for writing and maintaining substantial programs.
>Because people will want to do that!
Then why call it an extension language? You can't compare extending an
application like emacs with extending a programming language like C/C++.
In the first case you *have* to write "substantial" programs, because
you can't or don't want to (ever looked at the emacs source code?) modify
the application. In the second case (Tcl) you make an engineering tradeoff
about which parts of your software change so rapidly that it is better to
implement them using Tcl.
>Another lesson from Emacs is that the way to make sure an extension
>facility is really flexible is to use it to write a large portion of
>the ordinary released system. If you try to do that with Tcl, you
>will encounter its limitations.
I would disagree with that statement as well. Usually the domains of
building a system and building applications that are built on top of
that system have characteristics different enough to warrant different
languages.
Gnu software always looked to me as wanting to solve all the problems
at once and providing little structuring of the problem space. So this
disagreement might just be an irreconcilable difference of philosophies.
>Tcl has a peculiar syntax that appeals to hackers because of its
>simplicity. But Tcl syntax seems strange to most users. If Tcl does
>become the "standard scripting language", users will curse it for
>years--the way people curse Fortran, MSDOS, Unix shell syntax, and
>other de facto standards they feel stuck with.
So what? You seem to overlook the simple fact that the only purpose of
writing software is to make money - either from your customers or from
your University. We chose Tcl/Tk because:
- some applications similar to ours already exist
- it is easy to learn (a couple of days to get started)
- it is robust and has support both from the developer and the user community
- there is a critical mass of developers out there (according to the
resumes I received for summer jobs)
- most likely it can be ported to other platforms in the near future
and therefore our software investment seems to be most secure for the next
couple of years.
These factors by far outweigh any shortcomings of the syntax, which
certainly couldn't win at a beauty contest.
>Some people plan to use Tcl because they want to use Tk. Thankfully,
>it is possible to use Tk without Tcl. A Scheme interpreter called STk
>is already available. Please, if you want to use Tk, use it with STk,
>not with Tcl. One place to get STk is from
>ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
Thanks for the pointer. Can we incorporate it in commercial products?
Thomas
--
Thomas Werthmann-Auzinger MTS, Software Architecture
Siemens Corporate Research, Inc. (609) 734-3697
755 College Road East (609) 734-6565 (Fax)
Princeton, NJ 08540 t...@scr.siemens.com
Nicholas C. Weaver
(note followup line. Also pardon me if I may be missing some concepts
here in my scheme knowledge.)
I haven't used Tcl yet. Thus, I can't sincerely comment on RMS's
comments on Tcl's "problems". Although, Tcl is something I should learn,
mostly to take advantage of the TclServices package available for NeXTstep.
Since one of the three newsgroups this thread is in is
comp.lang.scheme, comments by RMS, common references to Scheme/Tk, etc... I
would assume that many would like to see a Scheme derived extention language
as something competing with Tcl.
So that leads to the following question: how Scheme-like should
such a mythical extention language be?
Syntax flames aside, I wonder about the following issues as well:
Would it be appropriate in such a context to restirct call/cc to non
local exits only? (Yes, it would no longer be Scheme, just Scheme-like)
Would a byte code interpreter be fast enough, or would a more
platform specific compiler be necessary, giving machine-code output?
How small could such an interpreter/compiler be made and still run
fast enough?
Could it run within a factor of 100 of C? Factor of 10?
What sort of module system could be added? Macro system? Are there
some good examples already available? Is there a move to formalize R4RS
macros somewhere?
--
Nicholas C. Weaver nwe...@orodruin.cs.berkeley.edu
It is a tale, told by an idiot, full of sound and fury, .signifying nothing
Fun with anagrams: computer science -> coerce inept scum
Edward Lee
or for Berkeley. But I would like to turn a nit-picking discussion
of syntax details to a more fundamental one.
I would like to observe that Mr. Stallman's article reflects
a long-standing dogma: that special-purpose languages are no good.
The dogma is that you only need one language (your religion will
decide whether it is Lisp, C++, Prolog, ... ). This is why no
language should be a "mere extension language."
But what is wrong with using more than one language?
Why not use C, C++, Tcl, Esterel, Matlab, etc., all together?
They each have their strengths. If the language and compiler
designers would concentrate on these strengths, we could really
get a nice programming environment -- one in which subprograms
would be simple and well-suited to their application.
Use a user-interface language for the user interface,
a mathematical language for the computations, a control language
for the automata, etc.
There are two arguments against this that I can think of:
1) Programmers will have to learn more than one language.
2) Languages will have to define the foreign function interface.
In answer to (1): How many serious programmers do you know that
only use one language? I think the notion that you can get by
with just one language is a Fortran-era notion.
In answer to (2): Language designers have resisted doing this
because "everything can be done in my language." E.g., "common" Lisp,
which included almost everything ever implemented in any Lisp system
anywhere, omitted (at least at first) a definition of the FFI.
This is undoubtedly one of the reasons Lisp is dead (IMHO, Lisp
is dead, except as an extension language for emacs). It was very slow,
for example, to get even rudimentary X window interfaces going,
partly because of the lack of portability of any solution.
Tcl has real strengths, not the least among them is its light
weight. Make it a "real programming language", and you remove
this advantage. But why not get the facilities you need
through C? If you need fast array computations, use C,
or better yet, some compiled version of a special-purpose
language, like Matlab.
Prof. Edward A. Lee
EECS Dept., Cory Hall
University of California
Berkeley, CA 94720-1770
email:e...@eecs.Berkeley.EDU
mathew
Matthew Dillon <dil...@apollo.west.oic.com> wrote:
>In article <TMB.94Se...@arolla.idiap.ch> t...@idiap.ch writes:
>:Lisp wins hands down in all these areas, having a few, simple rules.
>:The only problem with Lisp syntax is that it doesn't give new users
>:that "warm and fuzzy feeling" of familiarity.
>
> Oh, great, a fanatic. I won't even bother to argue the point
He gives you a list of sound technical reasons for favouring Scheme over
hack jobs like Perl and Tcl:
>:But Perl and Tcl do have serious syntax-related problems in the areas
>:of syntactic overloading, error recovery, scoping, and quoting.
...and that makes him a "fanatic"?
So, the only comments we're allowed to make are superficial,
non-technical and ignorant ones? Otherwise we're fanatics? Wonderful.
> to say that of all the lisp programs and programmers I know, the only
> people who understand them (the programs) are the people that wrote
> them. Assembly has a few simple rules too, and forth, but you do not
> see me doing projects of half a million lines in them.
Indeed, because assembly has many of the same faults which Perl and
Tcl have, which make it unsuitable for large projects.
God knows where you found your Lisp programming friends from, though.
mathew
--
http://www.mantis.co.uk/~mathew/
Seeking: Bug-tracking systems for UNIX, DOS and Windows which aren't GNATS.
Information on construction of housing using geodesic domes.
Reasonably priced recumbant bikes.
John Ousterhout
there's any need for me to respond, but I would like to say a few things
anyway:
First, I'd like to encourage everyone to keep their responses cordial and
technical, rather than personal, regardless of how strong your opinions
are. Comp.lang.tcl has managed to avoid flame-wars pretty well so far;
let's keep it that way by focusing on the technical issues rather than
worrying about motives.
I think that Stallman's objections to Tcl may stem largely from one
aspect of Tcl's design that he either doesn't understand or doesn't
agree with. This is the proposition that you should use *two* languages
for a large software system: one, such as C or C++, for manipulating the
complex internal data structures where performance is key, and another,
such as Tcl, for writing small-ish scripts that tie together the C pieces
and are used for extensions. For the Tcl scripts, ease of learning,
ease of programming and ease of glue-ing are more important than
performance or facilities for complex data structures and algorithms.
I think these two programming environments are so different that it
will be hard for a single language to work well in both. For example,
you don't see many people using C (or even Lisp) as a command language,
even though both of these languages work well for lower-level programming.
Thus I designed Tcl to make it really easy to drop down into C or C++
when you come across tasks that make more sense in a lower-level
language. This way Tcl doesn't have to solve all of the world's
problems. Stallman appears to prefer an approach where a single
language is used for everything, but I don't know of a successful
instance of this approach. Even Emacs uses substantial amounts of
C internally, no?
I didn't design Tcl for building huge programs with 10's or 100's of
thousands of lines of Tcl, and I've been pretty surprised that people
have used it for huge programs. What's even more surprising to me is
that in some cases the resulting applications appear to be manageable.
This certainly isn't what I intended the language for, but the
results haven't been as bad as I would have guessed.
I don't claim that Tcl is without flaws. Some of the flaws, like the
lack of a compiler and the lack of module support, will get fixed
over time. Others, like the substitution-oriented parser, are inherent
in the language. Is it possible to design a language that keeps Tcl's
advantages, such as simplicity, easy glue, and easy embedding, but
eliminates some of its disadvantages? Almost certainly (there are
several decisions that I would re-think if I were starting over). Is
the two-language approach really the right one? I still think so, but
reasonable people can disagree.
Language designers love to argue about why this language or that language
*must* be better or worse a priori, but none of these arguments really
matter a lot. Ultimately all language issues get settled when users vote
with their feet. If Tcl makes people more productive then they will use
it; when some other language comes along that is better (or if it is
here already), then people will switch to that language. This is The
Law, and it is good. The Law says to me that Scheme (or any other Lisp
dialect) is probably not the "right" language: too many people have
voted with their feet over the last 30 years. I encourage all Tcl
dis-believers to produce the "right" language(s), make them publically
available, and let them be judged according to The Law.
Tim Pierce
Thomas M. Breuel <t...@idiap.ch> wrote:
>Lisp wins hands down in all these areas, having a few, simple rules.
>The only problem with Lisp syntax is that it doesn't give new users
>that "warm and fuzzy feeling" of familiarity.
Some of us would call that a hands-down win, too.
--
"A person who dies of lung cancer at age 70 will not be hospitalized later
with another disease," said a study released Thursday by [Canada's] Imperial
Tobacco touting the benefits of early death in smokers on the health-care
system. (Reuters, in the Chicago _Tribune_, 9/3/94)
Peter da Silva
rodrigo vanegas <r...@cslab6b.cs.brown.edu> wrote:
> To encourage the design, implementation, and use of superior extension
> languages.
I would personally prefer to use a slightly extended (with a few decent
string primitives) scheme than Tcl, myself. But nobody ever came out and
did the work necessary to make Scheme a useful scripting language, including
embedded and standalone versions. Ousterhout did that, and with a language
that is at least clean and regular, if a little oddball, and absent a set
of implementations of Scheme toolkits that are as widely available, compatible,
and easily portable as Tcl there's really no alternative.
It could be a lot worse. The standard scripting language on the Amiga is a
variant of REXX, and there's been a few people pushing it on UNIX.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"
Peter da Silva
> Although I like Tcl I must admit that the comment processing does
> bother me. It seems so counter-intuitive. From a perusal of the
> code I also have to wonder why it is handled in the parser. This
> seems like the kind of thing that should be in the scanner.
puts stdout {#!/bin/sh -f
echo "This is a test"
}
if $var {#!/bin/sh -f
echo "This is a test"
}
How does the "scanner" distinguish these two cases?
Wayne Throop
in the places where I agree with his criticisms, the issues are not
Tcl-specific. IMHO, he makes critical errors that render his
conclusions suspect. And further, his proposed cure has features
that seem worse than the criticisms he brings against Tcl.
Let me be specific.
: From: r...@gnu.ai.mit.edu (Richard Stallman)
: [Tcl] lacks arrays
Incorrect. Tcl has arrays, eg, set a($i) foo
Some people have noted that what might have been meant was that
arrays aren't first-class objects, and can't be returned,
assigned, and so on. But since the names of arrays *can* be
returned, assigned, and so on, this is hardly a show-stopping
problem. For example, very similar problems didn't stop C.
: [Tcl] lacks structures from which you can make linked lists
Incorrect. Linked lists can obviously be made from associative
arrays. Depending on other factors, the important semantics of lists
can easily be had in Tcl using either strings or arrays.
: [Tcl] fakes having numbers, which works, but has to be slow
Largely irrelevant. Tcl may be slow compared to other interpreters,
but it doesn't "have" to be, nor can its slowness be pinned on its
lack of "real" numbers. For example, I have an interpreter in which
numbers are always represented as character strings, and on every
arithmetic operation, they are converted to and from string
representation. Yet this interpreter is three times faster than the
elisp interpreter (which I believe has "real" numbers), on my local
machine, using the code
(defun fib (n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2)))))
vs
define'fib with'n arg'1 if < val'n'2 val'n + fib - val'n'1 fib - val'n'2
Of course, the objection may be made that the code isn't really
arithmetic intensive, and that the speed is largely dominated by
stack frame push/pop. Which is true, but then, that is my point:
programming in extension languages very rarely runs into an
arithmetic speed problem.
: Tcl is ok for writing small programs, but when you push it beyond
: that, it becomes insufficient
Very subjective. Tcl has procedures with lexically scoped
variables. The [incr tcl] package adds objects and private storage.
TclX adds myriads of primitives, and keyed lookup of named fields in
smallish datasets. To me, the only reason Tcl might become
"insufficient" at large sizes is for programmers to avoid exploiting
these features, or for programmers to avoid designing their use of
the global namespace. Elisp or scheme programmers would have
similar problems if they decided not to use the package facility for
some reason, and allocated names randomly.
: Tcl has a peculiar syntax that appeals to hackers because of its
: simplicity. But Tcl syntax seems strange to most users
It would be nice to have some documentation of this allegation.
Certainly, I don't see anything drastic wrong with typical tcl
usages, such as
text .text -height 40
or even
.text insert insert [exec sh -c $filterprog [selection get]]
(which runs the current X selection through a program and inserts
the resulting text at the insertion cursor in the .text widget.)
But perhaps arithmetic notation is again the problem here.
Yes, things like
set r [expr $a*$x*$x + $b*$x + $c]
can be confusing. But it is absolutely *trivial* to provide
special purpose syntaxes in Tcl, eg:
sete r a*x*x + b*x + c
is prototyped in a handful of Tcl
proc e {args} {regsub -all {[A-Za-z]+} $args {$&} args
regsub -all {([0-9\.])\$} $args {\1} args
regsub -all {\$([a-z]+\()} $args {\1} args
uplevel [list expr $args]}
proc sete {name args} {set $name [e $args]}
and could easily be added to the core interpreter.
Of course, the argument can be made that this is hacker-level usage,
and that most folks wouldn't be comfortable with this sort of thing.
True enough. But if somebody would document that the above problem
is worth addressing (that is, that using a general-purpose string
substitution syntax obscuring the arithmetic expression syntax), Tcl
could respond trivially and efficiently, because its syntax is
minimally intrusive.
So again, at best subjective, and not well documented.
: If Tcl does become the "standard scripting language", users will curse
: it for years--the way people curse Fortran, MSDOS, Unix shell syntax,
: and other de facto standards they feel stuck with.
This is vacuous, because it is true no matter what replaces "Tcl" in
the above sentence. The perennial Rubin flames are a case in point.
Tcl, on the other hand, because of its lexical conservatism, can
accomodate more differing tastes, and incorporate novel notational
solutions more easily than many alternatives. And thus I would
argue, would be *less* cursed than many alternatives.
: For these reasons, the GNU project is not going to use Tcl in GNU
: software. Instead we want to provide two languages, similar in
: semantics but with different syntaxes. One will be Lisp-like, and one
: will have a more traditional algebraic syntax.
Oh, joy. Oh, rapture. Yet Another Couple of Scripting Languages.
But two points may be worth making here. First, it isn't clear that
segregation is the right way to go. That is, the above is
essentially the argument that Tcl tried to provide both "lisp-like"
regularity and "traditional algebra" (in "expr"s), and it is better
to supply these things separately (but presumably equally) than in
an integrated fashion. I am not convinced. The first thing that's
going to happen is that an application scripted with the lisp-like
language is going to want to import scripts written for an
application scripted with the traditional algebraic language.
Second, "lisp-like" and "algebraic" (or perhaps "prefix" and
"infix") doesn't cover all the ground that Tcl attempts to cover.
In particular, it would be easy, in the rush to provide "useful data
types such as structures and arrays" in both prefix and infix forms,
to forget to provide a simple, clean, "unquoted" syntax to be used
to enter commands interactively. Sure, sure, GUI, WIMP, and other
gestural interfaces make a type-able syntax a bit less important
than it used to be. But not *un*important.
In conclusion, let me ask a question. Analogs of *all* of the
criticisms that have been brought to bear against Tcl here can also be
brought to bear against C and Unix. C lacks first-class arrays. C
lacks a true two-dimensional or better namespace. Unix system calls are
minimal and regular, but only hackers like them, and all the
higher-level conventions to do with sockets and pseudoterminals and so
on are incomprehensible to the casual user. And even hackers are
abandoning Unix to pursue alternatives, because it's getting so old.
So. Given this, why did the GNU project decide to saddle the software
using community with a Unix-like OS and the GNU C compiler, which many
people even now curse as a de-facto standard that they are stuck with,
and yet has decided to saddle up a quite different beast, and *avoid*
the defacto standard of Tcl? The most likely reason might be that Tcl is
a less entrenched evil than Unix/C, and can be nipped in the bud. If
that's the rationale, Tcl strikes me as neither evil enough nor bud
enough to be a good candidate for nipping. There are other jihads more
fruitful to pursue than one against Tcl.
--
Wayne Throop throopw%sheol...@dg-rtp.dg.com
thr...@aur.alcatel.com
Robert DeLine
Thanks, John, for not fanning the flames and for encouraging technical
discussion. In that spirit, I would like to take issue with one of your
comments:
John Ousterhout writes:
|> Ultimately all language issues get settled when users vote
|> with their feet. If Tcl makes people more productive then they will use
|> it; when some other language comes along that is better (or if it is
|> here already), then people will switch to that language. This is The
|> Law, and it is good. The Law says to me that Scheme (or any other Lisp
|> dialect) is probably not the "right" language: too many people have
|> voted with their feet over the last 30 years.
This notion of "voting with your feet" as a way of judging the quality
("right"-ness) of a programming language only works when the choice of
programming language is based on technical merit. I'd like to claim that
there are many reasons why a given programming language is chosen for a
given project and that these reasons seldom deal with the technical merits
of the language. People choose a programming language for a project
because:
* they already have experience in that language;
* there are tools available for that language in their target environment;
* they must interface with existing software, which implies that language;
* the language is popular, so obtaining training and tools is easier;
* there are nifty tools/libraries available if they use that language;
* there is corporate/university infrustructure that demands that language;
* and so on.
I've worked on and started many software projects, but not once have I
gotten to use "my favorite programming language" -- there were always
external containts that dictacted the language to use. Hence people don't
always switch to "better" languages when they come along, and a language's
lack of popularity doesn't necessarily damn it as a bad langauge.
In short, using a programming language's popularity as a quality metric is
dubious.
Rob DeLine
Wayne Throop
: Does anyone with *direct* experience (as opposed to loud opinions on
: the morality of criticising TCL) in this know if ``itcl'' or something
: similar helps enought to overcome this objection?
That's a very good question. I've stated my opinion in another post
that [incr tcl] does provide enough "module" primitives to at the
very least blunt the "can't deal with large systems" objection.
But I must admit, I've only written a couple hundred lines of tcl so
far. The major basis for my opinion is my experience is using a
philosophically-tcl-like interpreter to write a CM system. This CM
system isn't all that large, as large goes nowadays. Only ~3 KLOC.
But I don't see any fundamental problem (given either autoload or undump
to ease startup overhead) with code in the many hundreds of KLOC. Once
you can partition your namespace, whether with perl packages, or itcl
classes, or just about *any*thing, you're pretty much as well off as any
other of the common notations, decompositionability-wise.
For example, that 3 KLOC of scripts, with only classes and procs
as the structuring primitives, comes in lots of little roughly-50-KLOC
(or smaller) chunks, each of which interacts with the others fairly cleanly.
Therefore, I expect exactly similar strategies to work in tcl/itcl.
Mumit Khan
>In article <3635a6$a...@apollo.west.oic.com>,
> dil...@apollo.west.oic.com (Matthew Dillon) writes:
>|> I would have to agree that as a programming language, Tcl sucks rocks
>|> when it comes to largish projects.
>
>Does anyone with *direct* experience (as opposed to loud opinions on
>the morality of criticising TCL) in this know if ``itcl'' or something
>similar helps enought to overcome this objection?
I'm not a big fan of Tcl syntax, but I needed to run away from InterViews
and so Tcl/Tk was my answer; so far, I have not regretted it one bit, esp
after I found [incr Tcl] (and the fact that the documentation and help from
the net about Tcl related thingies is far superior than that for any other
language I know gives it a nice boost)
small projects: (order of < few thousand lines of code)
- core Tcl (maybe + Extended Tcl for Unix'y things) works like a charm
- Speed is reasonable, but could always be boosted by some C code.
(If speed becomes an issue, I'd use perl for that project).
large'ish projects: (order of > 10s of thousands of lines)
- core Tcl (and + Extended Tcl for Unix'y things) simply is too hard
to maintain.
- core Tcl + [incr Tcl]: works like a charm.
I have two large'ish pet projects, both of which are > 20,000 lines
of code, and the code is as readable and maintainable as its older C++
counterpart, thanks to [incr Tcl].
As far as maintainability goes, I would take Tcl + [incr Tcl] over Scheme
given the fact that most of my users/collaborators are much more prone to
learn algebraic-type language than a LISP variant.
for my own use, I'd pick whatever's available that works best -- I'm not
about to let programming fascism affect my good judgement. I'm not also
about to sit around for years waiting for the perfect tool to come along;
otherwise, I would've never learned C/C++/Perl/you-name-it.
mumit -- kh...@xraylith.wisc.edu
Scott McLoughlin
> This is only partly true. You may carry around a pointer to the end
> of the list from a prior calculation and thus get an O(1) append time.
> This is the general case where it matters, e.g. when you are building
> a list.
>
Howdy,
But take a look at Richard Waters article in Lisp Pointers
IV.4 1993 "To NReverse When Consing a List ...". He makes a good
case for using nreverse (reverse! in scheme, non-standard but often
there) vs rplacd (set-cdr! in scheme), looks at generated machine code
in various lisps, times the two approaches, etc. Basically, got to
watch those inner loops (and I imagine write barrier detection in
certain GC implementations) and what the compiler/rts can do in
real implementations.
Now for my two cents. I like Lisp and Scheme. Visual Basic and
TCL are popular on their respective platforms. Whose "fault" is this?
It's _our_ fault (I'm developing a Lisp system for Windows): language
implementors.
I feel that paren syntax is one of Lisp's greatest _strengths_:
the ability to easily write macros that write Lisp programs. A wonderful
concession to the "hacker" in all of us. See Paul Grahams recent book.
If Lisp were more popular, it would have been called "Tricks of the
Common Lisp Masters". Or look at H.Baker's paper on "META" - an
excellent hack for small parsing problems vs. 300 pages of LL/LR
parsing theory.
The language is perfectly _cool_. Not everyone loves it, but
who cares. We're not going to please everyone.
But.... where are the implementations that "keep up with the
times". MIT Scheme is slick - but it's Win32s or better and has no
GUI interface. SCM is small and portable but it's fairly minimal.
CLISP is nice, but I don't like the built in editor. Etc. No one
implementation is hacked on hard enough to make it portable/
feature rich/etc.
I know that there are no easy answers. There _are_ happy
users out there. Never seems to reach critical mass though. Some
nudnick criticized a happless Windows user of MIT Scheme a few
posts ago: "Get a real OS". This attitude is stiffling. (Tk/Tcl
has just been ported to NT as I understand it.) We've got to
return to a fundamental design principle if Lisp/Scheme are to
thrive and grow: Easy things should be easy; difficult things
should be possible.
Anyway, here's a simple plan.
(1) Get GCL running on Win32s. Just plain _stupid_ not
to.
(2) Find a smaller Lisp/scheme and make it EGCL or
EGScheme (embeddable) - now. Hack real hard until it
works on Unixes/Windows. It _doesn't_ have to be
recompilable, just "portable" - meaning ported. Support
as much native OS functionality as possible, in fact.
(3) Make sure a GUI tool runs on (1) and (2) above. Don't
start from scratch. SCM maybe a good place to start - it
runs on _everything_, although there are other considerations.
Easier said than done, I know.... Oh yeah:
(4) Make sure docs/online help are available in the format
used by each platform. (TeX alone doesn't cut it.)
(5) Don't get _too_ clever. Use low tag bits/tagged objects
hybrid scheme. Maybe use non-copying scheme to support easy
C integration - _or_ provide for "locked references" to
support the same.
Sorry for long post...
P.S. LinkLisp for Windows (16 bit!) coming soon. CL subset .DLL for
embedding in your favorite C/Pascal application. Visual Basic VBX
on the way! Also DDE interface for implementing "Lisp Servers" or
interfacing a DDE aware editor with Lisp. Lisp editting "shell"
provided. Source for shell provided as a "sample app". Fast bytecode
compiler/vm. Large RTL in C shared across all Lisp processes. Ability
to define "binary" data structures. Link to DLL's. LinkLisp aware
.DLL's able to generate "Simple-Errors" for integration with Lisp's
structured exception handling. And more... For more information,
email. We have a promo-flier and are working on a more technical
"white paper" for the discriminating consumer ;-)
LinkLisp(tm) is a trademark of Conscious Computing.
Windows(tm) is a trademark of the Microsoft Corporation.
=============================================
Scott McLoughlin
Conscious Computing
=============================================
Scott McLoughlin
>
> So that leads to the following question: how Scheme-like should
> such a mythical extention language be?
>
> Syntax flames aside, I wonder about the following issues as well:
>
> Would it be appropriate in such a context to restirct call/cc to non
> local exits only? (Yes, it would no longer be Scheme, just Scheme-like)
Yup. call/cc is killer for a scripting language. Not going to
work _all_ of the time. Too much for users to worry about.
Plain truth. Let's make tools that are easy to use and work
today. Save the rocket science for the lab.
>
> Would a byte code interpreter be fast enough, or would a more
> platform specific compiler be necessary, giving machine-code output?
Yup. For an "extension language" skip native code. BC is plenty fast.
Direct threading can make it faster. Lots of folks us BC compiled
languages for _real applications_: dBase, Visual Basic, SmallTalk...
Native code is over-rated for about 85% of the apps out there.
>
> How small could such an interpreter/compiler be made and still run
> fast enough?
We've got a whole mess of CL (there's still a whole mess missing) in
our LinkLisp(tm) product coming soon - ~250K kernel implemented as a
shared library (Windows .DLL). This doesn't count the Lisp "standard
library", but source is there and can be pruned. Non-prunables are
documented as such.
>
> Could it run within a factor of 100 of C? Factor of 10?
Of course it _could_. We'll soon start honoring declarations. Don't
know if it'll make it into v1.0. But our motto for embedded Lisp
is "Render unto C what C is due." where "due" is defined by _what
typical non-academic user want or percieve_. Quixote's we're not.
Better spending one's time implemented _very_ friendly interface
to C (finalization on C pointers, integrated error handling, etc.)
>
> What sort of module system could be added? Macro system? Are there
> some good examples already available? Is there a move to formalize R4RS
> macros somewhere?
We support Lisp packages. For now, it's standardized and good enough.
We support Lisp defmacro's with normal lambda-list syntax. Don't have
time right now for "destructuring bind". Next version, maybe. We're
starting to have to make footprint decisions.
> --
> Nicholas C. Weaver nwe...@orodruin.cs.berkeley.edu
> It is a tale, told by an idiot, full of sound and fury, .signifying nothing
> Fun with anagrams: computer science -> coerce inept scum
Don't think too hard. Write something and then try to use it. If
you have problems, it's not good enough. Then give it to
colleagues. If they don't like it, it's not good enough. Proof
is in the pudding.
P.S. I _love_ the work produced by the Lisp research community. I
just think we've got to start segregating the research from the
commercial world. Novell now hawks Unix in the marketplace and
Bell Labs hacks Plan 9. That's as it should be. If we believe
the "20 year rule", the commerical world should be hacking out
stable Lisp systems based on ~20 year old techniques. Just bang
them out and make them available and affordable.
Michael B. Johnson
>>
>>Tcl has real strengths, not the least among them is its light
>>weight. Make it a "real programming language", and you remove
>>this advantage. But why not get the facilities you need
>>through C? If you need fast array computations, use C,
>>or better yet, some compiled version of a special-purpose
>>language, like Matlab.
>>
Hear, hear. I've been using tcl for around 5 years, and besides the
truly pragmatic reasons to use it (unencumbered source code license,
amazing support from comp.lang.tcl, very portable core, etc.) there
is one philosophical reason which has kept me from switching to a
"purer" language like Scheme. Simply put, tcl was built to do exactly
what I use it for - serve as an extensible, embeddable scripting
language, where it's straightforward to do database-like accessing
of variables and procedures. Sure, I'd like it to be faster, but in
the mean time, I'm getting an enormous amount of work done. If the
GNU folks come out with an embeddable extensible scripting language
that is as portable as tcl while staying at an equivalent "cost"
with regard to code size and gives me much higher performance, I'll
certainly give it a look, but in the mean time, I'm getting a
huge amount of work done with tcl.
As always, thanks to John and this community for the fine job done
with tcl.
--
--> Michael B. Johnson -- wa...@media.mit.edu
--> MIT Media Lab -- Computer Graphics & Animation Group
--> 20 Ames St. E15-023G -- (617) 666-4119 (day office)
--> Cambridge, MA 02139 -- (617) 253-0663 (night office)
George M. Sipe
Ron Natalie <r...@myhost.subdomain.domain> wrote:
>[other comments deleted]
>
>I come to feel that the major problem RMS finds with Tcl is that it
>doesn't come with the overly restrictive GNU licensing terms nor any
>other FSF sanction. It seems that sometimes RMS feels it's more important
>to stifle development of code other than those he blesses than to promote
>the concept of software freedom he claims as his primary goal).
Agreed. I think you are right on the mark here.
If the FSF "accepted" Tcl, they would probably make a copylefted GNU
version to gain control of the language and to apply their license
terms to it. Of course, only their version would be acceptable in GNU
applications. This would hurt, not help the Tcl community.
RMS's request should be ignored. Tcl may be inserted into GNU provided
applications as the user pleases. The result may be given away under
the terms of the GNU license (this does *not* put Tcl in general under
the GNU license). RMS's control is limited to what the FSF directly
distributes, which considering his position, will preclude Tcl based
code. Everyone else can decide for themselves.
Imagine both Scheme based and Tcl based versions of various applications.
Let the "market" select which one it likes the best, as supported by
which language is most often used for extensions.
--
Manager, Strategic Services - (404) 728-8062 - Georg...@Pyramid.com
Kevin K. Lewis
So what? You seem to overlook the simple fact that the only purpose of
writing software is to make money - either from your customers or from
your University.
This is an interesting fact. And what's more, it's simple. One
problem: it's false. I like to write programs for fun. I don't make
any money with these program. Seems to me your fact is not so simple.
Paul Smith
%% gs...@pyratl.ga.pyramid.com (George M. Sipe) writes:
gms> In article <364bq2$m...@topaz.sensor.com>,
gms> Ron Natalie <r...@myhost.subdomain.domain> wrote:
>> I come to feel that the major problem RMS finds with Tcl is that
>> it doesn't come with the overly restrictive GNU licensing terms
>> nor any other FSF sanction. It seems that sometimes RMS feels
>> it's more important to stifle development of code other than
>> those he blesses than to promote the concept of software freedom
>> he claims as his primary goal).
gms> Agreed. I think you are right on the mark here.
gms> If the FSF "accepted" Tcl, they would probably make a
gms> copylefted GNU version to gain control of the language and to
gms> apply their license terms to it. Of course, only their version
gms> would be acceptable in GNU applications. This would hurt, not
gms> help the Tcl community.
This is nothing but complete FUD, pure and simple.
There is absolutely no basis for this suspicion in RMS's statement.
Furthermore, the GNU project has embraced *many* packages which aren't
licensed under the GPL or the GLPL; it is *not* a requirement that
everything GNU distributes be placed under the GPL. Naturally, if the
FSF were to create the new packages RMS discusses they would certainly
be released under GPL or some form, and that might be a legitimate
issue. But this concept of FSF "making a copylefted GNU version" is
just silly.
Please, there are many interesting technical points to this discussion
(and they can only be healthy in the long run, whatever the outcome, if
they're treated with respect) without throwing ridiculous charges not
supported by facts into the mix.
--
-------------------------------------------------------------------------------
Paul D. Smith | That's the thing about being a boxer:
<psm...@wellfleet.com> | even when you're at the top of your field,
Wellfleet Communications, Inc. | people still hit you in the head.
Network Management Development | -- Paula Poundstone
-------------------------------------------------------------------------------
<Expressed above are my opinions. Wellfleet takes no responsibility for them.>
John Lazzaro
George M. Sipe <Georg...@Pyramid.com> wrote:
>If the FSF "accepted" Tcl, they would probably make a copylefted GNU
>version to gain control of the language and to apply their license
>terms to it. Of course, only their version would be acceptable in GNU
>applications. This would hurt, not help the Tcl community.
This flys in the face of history -- there is lots of "free to
commercialize" software that GNU has chosen to use rather than
duplicate, Mach, X11, and various UCB stuff being most obvious. These
tools are critical to the GNU mission in ways an extension language
could never be. There's much to be gained by having a technical, as
opposed to political, discussion of RMS's note, since there really
isn't any overt political content in it.
Marcus Daniels
> (1) Get GCL running on Win32s. Just plain _stupid_ not to.
Who, why, huh?
Steven D. Majewski
>projects be taken seriously, even by Tcl boosters (of which I am one).
>I remember when Pascal was proclaimed the one-true-language-for-everything.
>I also remember when C was criticized as being deficient for large projects.
>I think most people will agree that Tcl *does* have problems WRT larger
>projects. But is that flaw terminal?
>
As a veteran Python booster in the "language wars", I'll try to set a
precedent for candor and rational discussion in this thread ( if it's
not already too late! :-) by admitting that Python ain't perfect
either.
It shares with tcl the problem/benefit of having a single widely
available implementation, which, in practice, IS the language
definition, rather than an independent description. ( Basic tcl -
the tcl described on John Osterhout's original paper has the
advantage of being much simpler, but is there actually much
written using only the base language ? )
Scheme, on the other hand, has lots of implementations - free and
commercial, and there has been a lot of research and progress on
better implementation. However - scheme has been around quite a
while ( +++ They've had time to discover and try to tackle some of the
problems that tcl folk are just starting to bump into. ) and ( --- )
it drags a lot of baggage with it that someone starting from scratch
would probably drop.
Dylan is an example of trying to do an object oriented scheme-like
language with the freedom to start over from scratch.
However - knowing RMS attitude concerning Apple - Dylan may not be
a favorite candidate for FSF support. Also, (IMHO) I'm not sure that
Dylan has "got it right". Dylan may be trying to do too much and be
all things to all programmers.
[ See Richard Gabriels paper on " ... how to win big ... " for an
alternative view of "the next lisp" ]
Perl and Tcl on the other hand, started out to do one or two things
really well - were successful at that, and as a result are being asked
to expand their domain into areas they were not designed/intended for.
[ The same statement can be made in principle for scheme and Python,
but, I think, less strongly, as I think both started out with a more
general purpose "target". ]
The question, as someone else in this thread stated it, is - is it
worth the surgery to fix the problems, or is it better to take the
lessons learned and start over ?
[ I don't personally have an answer for this question! ]
-- Steve Majewski (804-982-0831) <sd...@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --
[ "Cheese is more macho?" ]
Tom Tromey
John> I didn't design Tcl for building huge programs with 10's or
John> 100's of thousands of lines of Tcl, and I've been pretty
John> surprised that people have used it for huge programs. What's
John> even more surprising to me is that in some cases the resulting
John> applications appear to be manageable. This certainly isn't what
John> I intended the language for, but the results haven't been as bad
John> as I would have guessed.
I think this design decision is where most of my problems with Tcl
lie. As I see it, there are a few problems that come from this
decision, problems that were perhaps not forseen. Certainly I didn't
forsee them when I decided to use Tcl on my current project.
One problem is that programming in Tcl is much easier than programming
in any compiled language. My current project is a mix of C++ and
Tcl. Given the choice, I will write any random piece of code in Tcl,
because the edit-debug cycle is so much shorter. This makes me more
effective.
But this means that more and more of my application is written in Tcl,
and so Tcl's flaws wrt big systems become very apparent.
Aside: at first I did not consider the lack of a type system to be a
flaw. But now I do. I find that the idea of "everything is a string"
does not correspond to hwo programs actually work. In my Tcl code,
strings, ints, lists, are almost never converted in the unrestrained
way that Tcl allows. (For instance, I don't think I've ever compared
two lists as strings). Also, Tcl doesn't consider everything to be a
string; arrays being the most notable example. (You can only pass
arrays by reference. This is a pain).
Obviously, I can't speak for Richard Stallman. But I don't recall
anything in his post saying that the "two-language" method is a bad
approach. And I certainly don't think it is a bad approach. In fact,
I'd like to be able to integrate many languages at once. (Each
language has its particular strengths. I think attempts to make one
language do everything are misguided)
John> Language designers love to argue about why this language or that
John> language *must* be better or worse a priori, but none of these
John> arguments really matter a lot. Ultimately all language issues
John> get settled when users vote with their feet. If Tcl makes
John> people more productive then they will use it; when some other
John> language comes along that is better (or if it is here already),
John> then people will switch to that language. This is The Law, and
John> it is good. The Law says to me that Scheme (or any other Lisp
John> dialect) is probably not the "right" language: too many people
John> have voted with their feet over the last 30 years. I encourage
John> all Tcl dis-believers to produce the "right" language(s), make
John> them publically available, and let them be judged according to
John> The Law.
Popularity is no measure of technical excellence, a point that
Stallman made obliquely, I think. In fact, by that measure, we might
be deluded into thinking that C++ is a good idea (:-).
There are many other reasons to pick a given language over another.
We chose Tk for our project because there was no other extension
language available at the time. At least, we couldn't find one of
similar quality.
There is one more problem that can arise that I have not seen
discussed anywhere. The problem is that, when using Tk, it is really
only convenient to do anything from Tcl. For instance, in our
application, we have display a DAG representing the state of some
system in a canvas, using bitmaps and arrows. Computing the location
of the bitmaps, arrows, etc, is very slow, especially when dragging
them around. We could move this code to C, but that would be quite
painful, both because maintenance suddenly becomes 100x worse (harder
to fix bugs), and because creating Tk objects from C is not very
easy. Obviously this is more of a Tk issue, but one could argue that
it is actually a problem with Tcl -- extensions tend to be written to
the model of the system they are extending. Writing a good C
interface to Tk, in that light, is an absurd task.
Tom
--
tro...@cns.caltech.edu Member, League for Programming Freedom
"Sadism and farce are always inexplicably linked"
-- Alexander Theroux
Michael Schumacher
Hello Richard,
I was really surprised when I saw your posting... Such a subject line
is typically used to start holy wars--but considering your reputation,
this couldn't have been your intention. So I read carefully what you've
written; but after all, it still doesn't make sense to me. Your point of
view is that using Tcl is the wrong way, but you didn't say clearly enough
why you do think so. It would help a lot if you would post a follow-up to
this thread, and tell us a bit more. If I missed a point in my follow-up,
please feel free to drop me a note.
> [Please redistribute wherever appropriate.]
No need to. I think you've posted it to all relevant newsgroups... :)
> Why you should not use Tcl
> Richard Stallman, GNU Project
> As interest builds in extensible application programs and tools, and
> some programmers are tempted to use Tcl, we should not forget the
> lessons learned from the first widely used extensible text
> editor--Emacs.
Oh oh! Be careful! The world is divided into two parts: one which
doesn't know about Emacs at all, while the other (minor) part is
subdivided into "Emacs-lovers" and "Emacs-haters". The lessons I've
learned so far from Emacs are:
1. Emacs stands for "Eight megabytes and constant swapping".
2. Emacs stands for "Extended-Meta-Alternate-Control-Shift".
I think, Tcl has "been there, done that": it is small, simple and
easy to use. But of course this is not what you wanted to say...
> The principal lesson of Emacs is that a language for extensions should
> not be a mere "extension language". It should be a real programming
> language, designed for writing and maintaining substantial programs.
> Because people will want to do that!
Well, the world is full of bad things of all sorts... :) Your opinion might
indeed reflect the "real world", but IMHO whoever tries to use a tool for
something it is not intended for, makes a grave mistake. Would you use a
database for writing articles? I wouldn't, because it is silly to do that
(even though it would be possible in some way).
> Extensions are often large, complex programs in their own right, and
> the people who write them deserve the same facilities that other
> programmers rely on.
Why? I mean, if you don't like the extension language (for what reasons
ever), why use it? If you don't like Tcl (and if Tcl is used as the
extension language for an existing application), you can easily write
your extension in any other language that you prefer--because Tcl
is able to invoke your extension, pass it any information it needs, and
wait for its results. Believe it or not - that's *exactly* why John
created this beautiful language. You can, of course, write huge
stand-alone applications using Tcl (provided that you're a *good* and
*experienced* programmer), but that is not what Tcl is meant for. Remember:
Tcl stands for "Tool command language" - not for "Totally complete
language"...
> The first Emacs used a string-processing language, TECO, which was
> inadequate. We made it serve, but it kept getting in our way. It
> made maintenance harder, and it made extensions harder to write.
Perhaps you should have used Tcl? ;-)
> Later Emacs implementations have used more powerful languages because
> implementors learned from the problems of the first one.
Could it be that there are more people programming in Tcl than in elisp? ;)
> Another lesson from Emacs is that the way to make sure an extension
> facility is really flexible is to use it to write a large portion of
> the ordinary released system.
I partially second. If you take a closer look at the Tcl distribution
(or Tk, TclX, BLT, ...), you will see that much of the functionality
is provided by means of procedures written in Tcl. On the other hand,
it wouldn't make any sense to self-host the Tcl interpreter. This
would lead to programs being interpreted by an interpreted interpreter.
Which buys you nothing but a huge performance loss. Furthermore, Tcl
is not the language to write compilers or interpreters (see above).
> If you try to do that with Tcl, you will encounter its limitations.
YesNo. See above. And below :-)
> Tcl was not designed to be a serious programming language. It was
> designed to be a "scripting language", on the assumption that a
> "scripting language" need not try to be a real programming language.
It's a matter of personal taste: why should a scripting language not
be a "serious" or "real" programming language? Tcl is as real and
serious as it can be--it's (freely) available, and of course one can
write serious programs with it. Where's the problem? Just because I
can't use it to write a compiler doesn't mean Tcl isn't a "real" or
"serious" programming language. It's simply not meant for that.
> So Tcl doesn't have the capabilities of one. It lacks arrays; it
> lacks structures from which you can make linked lists.
Please allow me a question: how long did you "really" examine Tcl so far?
Or am I just missing the point? Of course, you can't say "int arr[3];"
as you would do in C, but one of the great things in Tcl is that you
don't have to do that! Just say "set arr(0) 0" if you need an array
variable--no need to explicitly allocate space for that. But there
are a lot of things you can't do in C, e.g. "set l($item,next) NULL" and
"set l($item,last) l\($last" will give you a good starting point to
implement a linked list in Tcl--should you ever really need one... :)
> It fakes having numbers, which works, but has to be slow.
If you need high performance, use a compiler, but not an interpreter
"including, but not limited to" Tcl. Or run Tcl on a Cray-YMP...
> Tcl is ok for writing small programs, but when you push it beyond that,
> it becomes insufficient.
See above.
> Tcl has a peculiar syntax that appeals to hackers because of its simplicity.
Oops--I hope you do not accuse people who like Tcl's syntax of being
hackers (whatever that means). BTW: hackers prefer *huge*, *complicated*
and *real cool* stuff. Such as Emacs .-)
> But Tcl syntax seems strange to most users.
Sure. That's because Tcl is a programming language and not a program intended
to be used by end-users... (just kidding :). I think most "users" (in the
sense of people who would like to be programmers) got a very bad attitude:
"real programmers don't read manuals!". Tcl/Tk is probably one the best
documented software *ever*, its syntax is easy, the behaviour of the
parser/interpreter is absolutely predictable. But if folks are not able to
read (and understand) the five necessary rules, Tcl isn't. But then, any
other language isn't either. IMHO, Tcl code is far more readable than
certain Makefiles...
> If Tcl does become the "standard scripting language", users will curse it
> for years--the way people curse Fortran, MSDOS, Unix shell syntax, and
> other de facto standards they feel stuck with.
Hmmm. Lots of people still use Fortran and COBOL without cursing. There's
rumour that even more people still buy MSDOS--and end up cursing out loud.
Of course this has only partially to do with its shell syntax... :)
Plus: since I know how to use Tcl, I stopped writing (Unix) shell scripts.
> For these reasons, the GNU project is not going to use Tcl in GNU
> software.
Ahem? What about dejagnu? Besides that, I don't like it very much if
someone tries to force me to use a certain language (or tries to forbid
me to use another one). Just my opinion, but I like it. ;-)
> Instead we want to provide two languages, similar in
> semantics but with different syntaxes. One will be Lisp-like, and one
> will have a more traditional algebraic syntax.
Don't you think we *really* have *enough* programming languages?
Is it *really* necessary to always again reinvent the wheel? I mean, if
one feels like programming in Lisp, why should he use a "Lisp-like"
language (provided he is willing to wait until its state changes from
vaporware to Release 1.0, and additionally is willing to learn it then)?
And if you need a "traditional algebraic" language, ...see above.
Furthermore: from the recent discussions in gnu.misc.discuss and elsewhere
about FSF's GPL you should have learned something...
> Both will provide
> useful data types such as structures and arrays. The former will
> provide a simple syntax that hackers like; the latter will offer
> non-hackers a syntax that they are more comfortable with.
All this sounds like "I consider Wolfenstein to be too dangerous, so I'm
going to write 'DOOM for adults' and 'DOOM for children over 18'". Even if
the two languages you intend to invent and implement will be a success
(as is most of FSF's software), they will face exactly the same problems
than the current implementations. There is no "one-and-only" language--
and never will be. Not even English or ASCII... :)
> Some people plan to use Tcl because they want to use Tk.
And some don't.
> Thankfully, it is possible to use Tk without Tcl. A Scheme interpreter
> called STk is already available.
Isn't Scheme one of these great AI languages just like Lisp and Prolog,
which eventually turn out to be useless for real-world applications?
> Please, if you want to use Tk, use it with STk, not with Tcl. One place to
> get STk is from ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
Okay, let's make a deal: I will take a look at STk, and you will download and
test tgdb (aftp sunsite.unc.edu:/pub/Linux/devel/debuggers/tgdb-1.0.src.tgz).
It is a perfect example for why Tcl and its extensions are so useful and
successful (even though I bet you prefer the Emacs-interface to gdb... :).
Best regards,
mike
:wq :-)
PS: I'm sure that Dr. John Ousterhout reads this thread--John, be sure that
there are *lots* of people who appreciate your work. It's great! And I don't
think that Richard wanted to vulnerate you personally.
PPS: Richard, I hope you won't get flamed too much for this subject. You
haven't deserved this. Oh - I have a wish: if you should have some time on
your hands, could you please write an Oberon compiler? This would turn out
to be a lot more useful than to invent two other languages. And if you want
to be real cool, please make sure that Oberon's runtime system and libraries
are distributed under a BSDish copyright...
Rahul Dhesi
>Perhaps you don't see Stallman's remarks as politicking, but if it was not
>his intention to discourage use of TCL, then what was his purpose?
RMS has his own motives (whatever they may be) for speaking out against
tcl. Like any reasonably bright person, he realizes that it is not
always enough to simply present one's own personal objections; so he
has collected together as many technical reasons as he can find that
he believes support his position.
There is nothing wrong or dishonorable about this strategy. If you
wish to convince somebody of something, you must appeal to his likes
and dislikes, not your own. I do it, everybody does it, everybody
should do it, everybody will do it.
The only way to effectively counter RMS's posting is to rebut
what he says, not what you think he should have said.
--
Rahul Dhesi <dh...@rahul.net>
also: dh...@cirrus.com
Samuel S. Paik
Big" seems to be perfectly applicable to this thread.
I've only glanced through Tcl, while I've done some small programs in
Lisp and Scheme, and I tend to agree that Tcl, as a language seems
deficient.
Substitution syntax seems a weird base for serious programs, fraught
with potentital side effects and parameter passing weirdness, a semantic
mess as big as pass by name. On the other hand, essentially every
Unix shell works this way, and a shell, like Tcl, is used to glue
together foreign pieces of code, quite successfully.
Tcl is nearly a perfect example of the New Jersey "Worse is Better"
approach. It works, it is here now, it has a small and simple and
portable implementation.
RMS almost certainly advocates the 'big complex system' for GNU.
Sam
p.s. I don't quite agree with either pole. I don't live in academia, I
need tools that work now, but I cringe when I see lessons from
previous systems ignored.
p.p.s. Is the only reason why Dylan isn't under consideration because it
is being developed by Apple?
"Unix and C are the ultimate computer viruses.
...
The virus lives while the complex organism is stillborn. Lisp must
adapt, not the other way around. The right thing and 2 shillings will
get you a cup of tea."
R.P. Gabriel, _Lisp: Good News, Bad News, How to Win Big_
--
Samuel Paik / Digital Equipment Corporation / 3D Device Support
pa...@mlo.dec.com / 508-493-4048 / I speak only for myself
It doesn't matter who you are, or what you've done, or think you can do.
There's a confrontation with destiny awaiting you. Somewhere, there is a
chile you cannot eat. -- Daniel Pinkwater, "A Hot Time in Nairobi"
Peter da Silva
In article <09Z0sc...@sytex.com>, Scott McLoughlin <sm...@sytex.com> wrote:
> (2) Find a smaller Lisp/scheme and make it EGCL or
> EGScheme (embeddable) - now. Hack real hard until it
> works on Unixes/Windows. It _doesn't_ have to be
> recompilable, just "portable" - meaning ported. Support
> as much native OS functionality as possible, in fact.
Probably be best to use the Scheme core from Stk for this, to help bootstrap
the next stage:
> (3) Make sure a GUI tool runs on (1) and (2) above. Don't
> start from scratch. SCM maybe a good place to start - it
> runs on _everything_, although there are other considerations.
If you port Stk, and steal the code from the various windows/NT tks, this
should give you pretty good coverage with a very nice GUI toolkit.
> (4) Make sure docs/online help are available in the format
> used by each platform. (TeX alone doesn't cut it.)
Make the docs available in HTML, and steal the HTML parser from wwwish
so you've got a GUI docreader as a sample application.
This would be a relatively *small* amount of work to get a very nice
environment.
Peter da Silva
> nwe...@madrone.CS.Berkeley.EDU (Nicholas C. Weaver) writes:
> > Would a byte code interpreter be fast enough, or would a more
> > platform specific compiler be necessary, giving machine-code output?
> Yup. For an "extension language" skip native code. BC is plenty fast.
Hell, for an extension language BC is almost overkill. Just grovel over the
syntax tree directly in list format, taking advantage of the fast parsing you
get from Lisp-type languages, the way Lisp-1.5 on the '11 did. that'll save
a couple of big chunks of code... for a lot of apps loading in the bytecode
interpreter is as much overhead as parsing the lists.
And it'd make implementations and porting easier, which helps spread the
system around. One thing you have to learn in the Lisp community is that
making things easy for implementors is vital.
Jay Maynard
>It could be a lot worse. The standard scripting language on the Amiga is a
>variant of REXX, and there's been a few people pushing it on UNIX.
OS/2, too.
Why do you consider REXX to be "a lot worse"? It has a not insignificant
following, and not a few visual development tools, at least on OS/2.
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmay...@admin5.hsc.uth.tmc.edu | adequately be explained by stupidity.
The US Constitution: 1789-1994. RIP.
Peter da Silva
> a. If rms declared one day that the sky was blue, half of you
> would deny it.
And if he declared it was orange, the other half would back him 100%. For
good or ill, RMS is not someone you ignore.
Can we take the rest of this flame war as read and get back to the regular
ones?
Eduardo Pelegri-Llopart
| I think that Stallman's objections to Tcl may stem largely from one
| aspect of Tcl's design that he either doesn't understand or doesn't
| agree with. This is the proposition that you should use *two* languages
| for a large software system: one, such as C or C++, for manipulating the
| complex internal data structures where performance is key, and another,
| such as Tcl, for writing small-ish scripts that tie together the C pieces
| and are used for extensions. For the Tcl scripts, ease of learning,
| ease of programming and ease of glue-ing are more important than
| performance or facilities for complex data structures and algorithms.
| I think these two programming environments are so different that it
| will be hard for a single language to work well in both. For example,
| you don't see many people using C (or even Lisp) as a command language,
| even though both of these languages work well for lower-level programming.
The GNU emacs experience, is that this clean separation just does not
happen. Systems evolve by writing large portions of the code in the
extension language. Over time features migrate up and down from the
C/elisp boundary, as functionality, extensibility and performance
requirements are understood better.
Notice that, as you point out later in your message, the TCL
experience is the same: the extension language is used for large
portions of the system.
| Thus I designed Tcl to make it really easy to drop down into C or C++
| when you come across tasks that make more sense in a lower-level
| language. This way Tcl doesn't have to solve all of the world's
| problems. Stallman appears to prefer an approach where a single
| language is used for everything, but I don't know of a successful
| instance of this approach. Even Emacs uses substantial amounts of
| C internally, no?
The emacs approach is NOT to use elisp for everything. But, why
use C when elisp can do? Ditto for TCL.
| I didn't design Tcl for building huge programs with 10's or 100's of
| thousands of lines of Tcl, and I've been pretty surprised that people
| have used it for huge programs. What's even more surprising to me is
| that in some cases the resulting applications appear to be manageable.
| This certainly isn't what I intended the language for, but the
| results haven't been as bad as I would have guessed.
BTW, I think that TCL is not far off from being a pretty reasonable
extension language. From what I've seen several small modifications
would make it adequate. Hopefully it will keep evolving and improving.
From reading RUSH, it seemed a good direction. I haven't looked
at [incr tcl] yet.
- eduardo
Daniel C. Wang
throopw%sheol...@dg-rtp.dg.com (Wayne Throop) writes:
[stuff deleted]
> : Tcl is ok for writing small programs, but when you push it beyond
> : that, it becomes insufficient
>
> Very subjective. Tcl has procedures with lexically scoped
> variables. The [incr tcl] package adds objects and private storage.
> TclX adds myriads of primitives, and keyed lookup of named fields in
> smallish datasets. To me, the only reason Tcl might become
> "insufficient" at large sizes is for programmers to avoid exploiting
> these features, or for programmers to avoid designing their use of
> the global namespace. Elisp or scheme programmers would have
> similar problems if they decided not to use the package facility for
> some reason, and allocated names randomly.
>
Tcl is not lexically scoped in any meaning of the phrase, it like elisp is
dynamicly scoped. Hence hacks like upvar, uplevel, and the need to have a
"global" deceleration. If Tcl were indeed lexically scoped, and included a
real lambda abstraction, it would be almost trival to build up a object
system without having to extend the lanuage with an extension like [incr tcl].
Kartik Subbarao
John Ousterhout <ous...@tcl.eng.sun.com> wrote:
>Language designers love to argue about why this language or that language
>*must* be better or worse a priori, but none of these arguments really
>matter a lot. Ultimately all language issues get settled when users vote
>with their feet. If Tcl makes people more productive then they will use
>it; when some other language comes along that is better (or if it is
>here already), then people will switch to that language. This is The
>Law, and it is good. The Law says to me that Scheme (or any other Lisp
>dialect) is probably not the "right" language: too many people have
>voted with their feet over the last 30 years
Right on. Lisp, scheme, or whatever dialect thereof that GNU or MIT wants to
push these days, is definitely NOT the "right" language. I wonder how long
it will take them to realize The Law. What saddens me even more is that
they teach Scheme to introductory CS students at MIT, rather than the
more practical C.
>I encourage all Tcl
>dis-believers to produce the "right" language(s), make them publically
>available, and let them be judged according to The Law.
It's already been done, and it's called Perl (actually Perl was around well
before Tcl I believe). See also the related discussion in comp.lang.perl. I
learned Tcl recently to play with Tk and expect, and I constantly was
frustrated as to the clumsiness of what I needed to say in order to get
what I wanted. I've also introduced some Tcl'ers to Perl, and they dumped Tcl
like a hot potato.
Once you're used to a Porsche, a Yugo just doesn't cut it ;-) And with
Perl5, make that a Lamborghini!
--
Kartik Subbarao, Workstation Systems Division, Hewlett-Packard
Internet: <subb...@fc.hp.com>, Phone: (303) 229-3897, Fax: (303) 229-6858
Peter da Silva
Jay Maynard <jmay...@admin5.hsc.uth.tmc.edu> wrote:
> Why do you consider REXX to be "a lot worse"? It has a not insignificant
> following, and not a few visual development tools, at least on OS/2.
It's a cramped language, with no clean method for parsing/extending the code
directly and a hideously complex inter-language calling sequence. Plus it's
got a set of its own flaws, like giving uninitialised variables their name
as their value (the only rational alternatives are to trap (I prefer this)
or to yeild the null string).
It's got too much syntax. I don't think an embedded language should have a
whit more syntax than is absolutely necessary.
It's got oddball primitives for string handling that don't match the UNIX
hacker tools. PARSE is not nearly as capable as REGSUB.
No two platforms have implementations close enough to allow easy code porting.
That's where Scheme falls down, too, alas.
Omar El-Ghazzawy
Richard Stallman <r...@gnu.ai.mit.edu> wrote:
>[Please redistribute wherever appropriate.]
>
> Why you should not use Tcl
> Richard Stallman, GNU Project
>
>As interest builds in extensible application programs and tools, and
>some programmers are tempted to use Tcl, we should not forget the
>lessons learned from the first widely used extensible text
>editor--Emacs.
>
It is obvious that you are likening Tcl to Emacs. Are you declaring Emacs
a failure and a mistake to use? Or do you believe has Emacs overcome it's
early limitations and become a worthwhile entity?
>Tcl was not designed to be a serious programming language. It was
>designed to be a "scripting language", on the assumption that a
>"scripting language" need not try to be a real programming language.
>So Tcl doesn't have the capabilities of one. It lacks arrays; it
>lacks structures from which you can make linked lists. It fakes
>having numbers, which works, but has to be slow. Tcl is ok for
>writing small programs, but when you push it beyond that, it becomes
>insufficient.
What are you're Tcl credentials?
Those of us who develop with Tcl know that John Ousterhout solicits suggestions
from us before releasing new versions, doing a very good job of addressing
the most important limitations that those of us who actually use Tcl face.
(from what you have stated, it seems that you haven't actually tried to
develop a large application in Tcl - it can be and is being done)
I will cite the limitation of the speed of Tcl and the fact that John is
addressing this problem right now. As for your other objections, they seem
to be run of the mill beginner Tcl observations that either aren't correct,
have easy workarounds, or are currently being addressed.
>For these reasons, the GNU project is not going to use Tcl in GNU
>software. Instead we want to provide two languages, similar in
>semantics but with different syntaxes.
Oh, now we get to the real reason you don't like Tcl. Time will tell...