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