What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Niels P. Mayer
[note additional crossposting to comp.lang.lisp]
In article <LORD.94Ju...@x1.cygnus.com> lo...@x1.cygnus.com (Tom Lord) writes:
ous...@sprite.Berkeley.EDU:
Since we're slinging arrows, allow me to sling mine. It's
time to accept the fact that Lisp will never be a mainstream
language. There's no question that Lisp is an intellectually
interesting language, and it is very important in certain
communities, such as AI and formal language design. But it's
simply never going to be widely used.
Right. No general-use application written in lisp will ever fly.
Only in a few exotic situations do people ever use lisp.
Tom Lord
part-time emacs hacker
Perhaps you mean no general use application written entirely in Common
Lisp will ever fly? I can think of lots of counterexamples:
* GNU Emacs partially written in Lisp. It is a hybrid
implementation using C at its core, and Lisp as a configuration
and extension language.
* AutoCAD uses AutoLisp as an extension language. It is very very
popular given that it is a CAD package, and not, say, a spreadsheet.
I can't remember the figures exactly, but I've heard there's 500,000
to 1,000,000 copies of it floating around world-wide.
* Various other CAD packages use Lisp extension languages as well,
for example Cadence Design Systems.
* Interleaf uses Lisp as an extension language.
* SoftQuad has an SGML editor which uses Scheme (a Lisp dialect) as an
extension language.
* All applications written in WINTERP (I know of one that had
an estimated 1500 users.) All applications using Elk. All.
applications using CLM/GINA. All applications using GNU Emacs
and written in Emacs-Lisp (such as the newsreader I'm using --
GNUS).
* The statistics community has found Luke Tierney's XLISP-STAT
to be a very cool package as well. THis is a package with
a hybrid C/Lisp implementation of Lisp which is extended to
do graphics and plotting (Mac,Unix/X11) and with statistics
primitives.
--------------------
From: ous...@sprite.Berkeley.EDU (John Ousterhout)
> Since we're slinging arrows, allow me to sling mine. It's time to accept the
> fact that Lisp will never be a mainstream language. There's no question that
> Lisp is an intellectually interesting language, and it is very important
> in certain communities, such as AI and formal language design. But it's
> simply never going to be widely used. Lisp has been trying for more than
> 30 years; every few years we hear another round of grandiose claims, and
> a few years later they have evaporated. We could argue about why Lisp
> hasn't entered the mainstream, but none of this changes the basic fact
> that it hasn't.
>
> I believe that it is reasonable to give new ideas a chance and to accept
> plausible arguments that they might succeed, but when a system has been
> around for 30 years I don't think "plausible arguments" are enough anymore.
> If someone is going to argue today why Lisp should be a mainstream
> language, they must somehow explain why it hasn't succeeded in the past
> and what will happen this time to make things turn out differently.
Repeating "Lisp is dead" over and over and over again will not make it
true, just like repeating "Tk has a Motif Look and Feel" will not make it
true to someone expecting a Tk application to "feel" like Motif.
All you have to do is go down to any technical bookstore and you will find
many many books on Lisp programming, Lisp application programming and
Scheme programming. And I'm not talking about 30 year old books on Lisp,
I'm talking about books that are in their third or fourth printing and have
been published in the last few years. There is a market for these books,
otherwise the publishers would never have put these books out, nor put out
new editions of older books (e.g. Winston&Horn).
In addition to Lisp books, there are also a number of recently published
books on the Scheme dialect of Lisp. One of the best introductory books on
computer science, Abelson&Sussman's "Structure and Interpretation of
Computer Programs", uses SCHEME and not Pascal or C to introduce the
student to a variety of interesting CS problems. The fortunate few that are
able to make it in to MIT end up taking 6.001 (which uses the
Abelson&Sussman book) as their introductory computer science and
programming course, which tends to put these folks on the right track right
from the start.
Finally, I know of at least three books on GNU Emacs which discuss
Emacs-Lisp programming, and there's whole rows of books on AutoLisp
programming for AutoCAD.
(Since WINTERP uses XLISP-PLUS, I'll also mention that I know of two books
on XLISP, and one on Luke Tierney's XLISP-STAT).
Meanwhile, I know of exactly one book on TCL/Tk (Ousterhout's) that is now
available in bookstores. More importantly I haven't come across any books
on applications using TCL/Tk as an extension language (like the GNU Emacs
or AutoCAD books).
> |> Yes, TCL is a simple language -- I contend that it is too simple and too
> |> simplistic for constructing well engineered applications:
> |> ...
>
> Again, I think the large number of Tcl applications and the growing size of
> the Tcl community speak for themselves. What better evidence could there
> be that Tcl and Tk are practical for building interesting and useful
> applications?
I already answered to this in my original post when I said:
| The fact that people *can* program applications in the bourne shell, or
| tcsh, or the korn shell does not imply that a language having the above
| limitations is a good or expressive language for building applications.
Some of the problems I addressed:
| * type-overloading of strings, and lack of any real type system.
| * lack of proper automatic memory and resource management (freeing
| up data when a widget is destroyed doesn't quite cut it).
| * lack of lexical scopes for functions/procedures.
| * lack of closures (forcing programmers to use too many global
| variables).
| * Lack of object orientation in the standard TCL/Tk release.
Are clearly problems with TCL in terms of building larger applications that
scale well, and aren't mired in a sea of global references. I can't imagine
that people spent the time to develop [incr tcl] and [incr tk] unless
they were attacking a known problem.
I think the whole "popularity" line of reasoning is questionable: MS-DOS
and MS-WINDOWS are more popular than Unix/X, but many of us have good
reasons to keep working on Unix and X. Beyond that, if you're worried about
popularity, both the Lisp and TCL/Tk community are no doubt insignificant
when comparted to, say the Visual Basic community, or Actor, or other
similar packages available for MS-WINDOWS.
In other words, the popularity argument is meaningless at best, and
specious at worst. Some people are willing to pay the costs of Lisp in
return for its benefits. Others may be lured to TCL/Tk because it is small,
simple and free and includes a free toolkit. None of these have anything
to do with the fact that the language may not be good for building
GUI-based applications. People write applications in assembly too.
When discussing language features, one shouldn't confuse a trend with a
movement.
I personally couldn't give a deleted expletive about whether Lisp is more
or less popuplar than TCL/Tk or Perl, just as long as no employer of mine
ever demands that I write, maintain, or extend a TCL/Tk or Safe-TCL
program. In the mean time, I'm happy to see that we all have choices and
are not locked in to any particular form of lowest-common-denominator
groupthink (e.g. MS-DOS) -- use the best tool for the job, whether it be
C, C++, Lisp, TCL, Perl, Awk, Sed, ASN1, APL, Prolog, or whatever.
Michael Tiller
[lots of stuff deleted]
|>
|> I personally couldn't give a deleted expletive about whether Lisp is more
|> or less popuplar than TCL/Tk or Perl, just as long as no employer of mine
|> ever demands that I write, maintain, or extend a TCL/Tk or Safe-TCL
|> program. In the mean time, I'm happy to see that we all have choices and
|> are not locked in to any particular form of lowest-common-denominator
|> groupthink (e.g. MS-DOS) -- use the best tool for the job, whether it be
|> C, C++, Lisp, TCL, Perl, Awk, Sed, ASN1, APL, Prolog, or whatever.
Am I the only one who finds this paragraph self-contradicting.
"...as long as no employer of mine ever demands that I write...TCL/Tk"
followed in virtually the same breath by
"...use the best tool for the job..."
Come on.
Mike
Richard Karpinski
wholly or partially in Lisp IMHO should end all talk of Lisp
is Dead.
--
"If I cannot bring it up on my monitor and it does not interfere
with a major aspect of my physiology, like eating, sleeping, or breathing,
then it probably does not exist"
Bill Janssen
Am I the only one who finds this paragraph self-contradicting.
"...as long as no employer of mine ever demands that I write...TCL/Tk"
followed in virtually the same breath by
"...use the best tool for the job..."
With all due respect for the wonderful implementation of Tcl, I find
it difficult to think of a job for which Tcl is the best tool.
Perhaps someone could make a list?
Bill
--
Bill Janssen <jan...@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html
Niels P. Mayer
original posting appears to have expired on netcom...]
From: ous...@sprite.Berkeley.EDU (John Ousterhout)
| There are many things in Niels Mayer's article that deserve a rebuttal, I'll
| just pick a couple:
|
| |> TCL's problems of language quoting incosistency make it difficult to write
| |> higher level abstractions for UI construction -- macros, iterators,
| |> data-driven-UI-generation, etc. Not that higher level abstractions can't be
| |> done -- it's just that creating them in TCL is linguistically painful
| |> because the language uses the wrong fundamental data-type -- newline
| |> delimited STRINGs separated by spaces. In constrast LISP chose the right
| |> fundamental data-type LISTs of SYMBOLs, and consistently applies this
| |> datatype across throughout the language.
| |>
|
| This paragraph suggests that you don't understand Tcl. In fact the quoting
| rules are very simple and very consistent; I claim that it's quite
| straightforward to build higher-level constructs for UIs and I think there
| are many many examples in the Tcl community that illustrate this. One
| can make religious arguments ad nauseum, but I know of no technically
| sound evidence that lists of symbols are fundamentally better than strings.
It looks like a number of your users are also having trouble understanding
Tcl. In my opinion, this is because the quoting and parenthisation rules
are neither straighforward, simple, nor consistent. About once every week
or two, I see questions come up on comp.lang.tcl dealing with one or more
of the issues raised above. Examples of these problems have been
appended to the end of this article...
When users are having real problems, it becomes clear that the arguments
are no longer religious. In Lisp, you can get arbitrarily complex and
inscrutable once you go to extreme macro-ology and multiple levels of
backquoting. However, for the more typical cases handled by the neophyte,
the problems of quoting, time-of binding, time-of substitution, and scope
of bindings are more consistent and easier to understand in Lisp. And
when you need to, you know that there's a very nice macro capability
to back up any meta-level programming you need to accomplish.
By default, Lisp does the right thing for the case of binding at run-time,
and when you need to perform binding at evaluation time, you use
backquotes... The places where backquote substitutions happen are clearly
marked by backquoting 'commands' e.g. (,foo); all other cases look up the
value of a symbol based on the closure surrounding the code being
executed. By using closures, one may limit the extent of variables to
groups of functions or methods, an application module, or the entire
application -- closures are the basis enabling any lexically scoped Lisp
solution to scale better than TCL. And in Lisp, you don't have multitudes
of different ways of opening and closing expressions...
Furthermore, there's 30 years of history and 30 years worth of books on
Lisp programming which have dealt with these problems from the pedagogical,
technical, and style/design perspectives. Most beginners find this helpful.
Reinventing the issues which are already solved problems in Lisp, just so
that you can have a language that doesn't parenthesize like Lisp -- that is
not helpful to the beginner. It does, however, open up a whole new market
for books.
Finally, I think that having language syntax depend on newlines is a bad
idea -- I think most unix shell programmers will grudgingly agree with me
on this. I'd much rather have a Lispish syntax where you delineate your
current top-level evaluations by [ ... ] and don't bother with newlines.
Unfortunately, given people's knee-jerk response to Lisp, having such a TCL
would highlight TCL's parentage as bastard-child-of-Lisp. Something almost
Lisp-like would set-off or shatter people's preconceived panic
response. Can't do that! (Meanwhile, I eagerly await the chance/time to see
how the Dylan folks solved the problem of being politically right-thinking
with regards to syntax while retaining a Lisp core).
Well, here go the examples, cleaned from a random reading through
comp.lang.tcl articles on this site:
--------------------
From: hfv...@bcarh80a.bnr.ca (7Z31 Coop)
| In article <1994Jul21.1...@khis.com>, cha...@khis.com (David Chang) writes:
|
| [... Stuff Deleted ...]
| |> I'm trying to get the number of word "set" appeared in $file and set
| |> the scale value by using "set count [exec grep -c set $file]; .scale set $count".
| |> This doesn't work if no "set" appeared in file "$file" , so I change to use
| |> the following method (use catch) :-) Guess what ?
| |>
| [... Stuff Deleted ...]
| |>
| |> catch [exec grep -c "set" $file] retval
| |> if { $retval == 1 } {
| |> .scale set 0
| |> return 0
| |> }
| |>
| |> if { $retval != 1 } {
| |> set count [exec grep -c "set" $file]
| |> .scale set $count
| |> return 0
| |> }
| |>
| |> So my question is : How do I set the variable "count" if the return value of
| |> "grep -c" is 0 ?
|
| Try:
|
| if {[catch {set count [exec grep -c "set" $file]}]} {
| .scale set 0
| } else {
| .scale set $count
| }
| return 0
From: fri...@faw.uni-ulm.de (Davide Frisoni)
| Hello everyone,
| thanks to all people who answered my question, the main error come from a wrong use of [].
|
| I wrote :
| set code [catch [my_cprogram] err] :-(
| and now with :
| set code [catch {my_cprogram} err] :-)
| it works.
From: Rob Earhart <earh...@CMU.EDU>
| wessel@stt_even.let.ruu.nl (Wessel Kraaij) writes:
| > proc 8bitbindings {widget} {
| > bind $widget \" {set nop 0}
| > bind $widget \"\" {$widget insert insert \"}
| > bind $widget \"e {$widget insert insert \353}
| > }
| >
| > Unfortunately, this does not work, because $widget in the binding
| > script is evaluated at event time, not at bind time!
|
| proc 8bitbindings {widget} {
| bind $widget \" {set nop 0}
| bind $widget \"\" [list $widget insert insert \"]
| bind $widget \"e [list $widget insert insert \353]
| }
|
| Yeah, I stumbled on this when learning TCL, too :-)
From: dav...@london.sbi.com (David Artus)
| Long Pham (lp...@tern.NoSubdomain.NoDomain) wrote:
| : Hello tcl experts,
|
| : I'm a newbie in this area, and have a small problem while playing w/
| : tcl. So, be gentle.
|
| : Here is my problem:
| : I'm trying to create an n number of buttons, each button will call
| : a same proc upon activated. And an argument passes to the proc is
| : an variable, i.e. different value for different button. I want to
| : display the value of the argument that I passed to the proc everytime
| : I click on a button. However, the program doesn't work, it always
| : display the last value of the variable no matter what button I
| : clicked on.
|
| : set names {John Anne Mary Jim}
| : foreach b $names {
| :
| : button .$b -text $b -command {displayName $b}
| : pack .$b -side left -padx 3
|
| : }
|
| : proc displayName bname {
| : puts $bname
| : }
|
| your problem is -command {displayName $b}
|
| The {} defer evaluation of $b till the event occurs. At that time
| b is, of course, set to Jim. You probably mean -command "display $b"
| for the purposes of this playing, or in real life maybe some
| cunning way of extracting the button name, contents or whatever.
From: hfv...@bcarh80a.bnr.ca (Dan MacDonald)
|In article <1994Jul22.005941.19824@wmichgw>, 31ch...@wmich.edu writes:
||> Hello Everybody,
||>
||> I am a new user of tk/tcl. I have a question.
||>
|
|Your entire problem:
| Very simply it's the value being passed to your procedure s1 is
| always '0'. This stems from the fact that when you created the
|
| button .watch22.yes -text YES \
| -command "s1 $foo_value"
|
| you specified the command (bind command) in quotes which performs
| substitutions when created. If you enclose the command in curly
| braces the substitution will be performed later. Although the (all)
| bind command operates at global scope, this is acceptable since the
| variable foo_value is a global variable - it must be because it
| to is "bound" by the scale widget to store the value.
|
|Try: button .watch22.yes -text YES -command {s1 $foo_value}
|
|Dan MacDonald
From: f...@cam-orl.co.uk (Frank Stajano)
| In article <303o17$4...@hydrox.cs.umd.edu>, nle...@cs.umd.edu (Nathan Lewis) writes:
| |> Hi everyone,
| |>
| |> I'm still new to tcl and I'm having some trouble. I'm trying to write lines to
| |> a file. There is one line where I want to write a bunch of things to the file
| |> literally but the problem is that I want to write $variable-name to a file
| |> literally and the interpreter keeps trying to evaluate the variable and I can't
| |> seem to get it not to.
| |>
| |>
| |> Thanks alot for any help.
| |>
| |> This is the code:
| |>
| |> button $w.ok -text "EXIT" -command " ;\
| |> puts \$datafile \"set precedence_relO \$precedence_rel\" ;\
| |> puts \$datafile \"\n\n\n\" ;\
| |> puts \$datafile \"set precedence_rel {\[lindex \\$precedence_relO 0\]}\" ;\
| |> This is the line ^ This is the variable ^
| |> puts \$datafile \"\n\" ;\
| |> puts \$datafile \"set Threads [list $Threads]\" ;\
| |> puts \$datafile \"\n\" ;\
| |> puts \$datafile \"set exclusion_rel [list $exclusion_rel]\" ;\
| |> exit ;\
| |>
|
| I must admit I haven't got a very clear idea of what you are trying to do, but
| if all you want is putting out stuff literally you could use curly brackets
| instead of quotes. If instead you want to have some of the things substituted
| (like the []'s) and some not (like the $'s) then I'd say your best bet is to
| make the command a separate procedure and build up the complex string in the
| procedure with "append". Otherwise it becomes a bit too complicated to do in one
| single command line, and the code becomes difficult to read and maintain.
From: f...@cam-orl.co.uk (Frank Stajano)
| In article <ASSON.94J...@chacmool.stsci.edu>, as...@chacmool.stsci.edu (Drew Justin Asson) writes:
| [...]
| |> >proc foo {x} {
| |> > global Global_Var
| |>
| |> > if {$x == ""} {
| |> > return $Global_Var
| |> > } else {
| |> > return $x
| |> > }
| |> >}
| |>
| |>
| |> The only problem with this is that this will raise an error
| |> if no argument is provided. To do what you want, you would
| |> have to declare the argument list as:
| |>
| |> { {x ""} }
| |>
| |> Then, the code would work.
|
| You're absolutely right, thanks for pointing it out. (Using args instead of x is
| another option.)
|
| |> But, this isn't really what I wanted. I was more interested in
| |> doing something that we often do with LISP code. E.g.
| |>
| |> proc foo { {x minus-infinity} {y plus-infinity} } {
| |> ...
| |> }
| |>
|
| I can't think of a Tcl way of doing this sort of thing in the argument list. If
| someone finds one, I'd be curious to know about it.
From: s...@cs.hut.fi (Sami-Jaakko Tikka)
| In <30jdao$8...@access3.digex.net> cob...@access3.digex.net (Cary B. O'Brien) writes:
| >Why does expr { fred < sam } fail,
| >When expr { "fred" < "sam" } succeeds.
|
| When expr sees strings without quotes, it tries to convert them to
| numbers.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
== Niels Mayer -- netcom!mayer -- ma...@netcom.com ==
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Libes
+ From: ous...@sprite.Berkeley.EDU (John Ousterhout)
+ | This paragraph suggests that you don't understand Tcl. In fact the quoting
+ | rules are very simple and very consistent; I claim that it's quite
+ | straightforward to build higher-level constructs for UIs and I think there
+ | are many many examples in the Tcl community that illustrate this. One
+ | can make religious arguments ad nauseum, but I know of no technically
+ | sound evidence that lists of symbols are fundamentally better than strings.
+ It looks like a number of your users are also having trouble understanding
+ Tcl. In my opinion, this is because the quoting and parenthisation rules
+ are neither straighforward, simple, nor consistent. About once every week
+ or two, I see questions come up on comp.lang.tcl dealing with one or more
+ of the issues raised above. Examples of these problems have been
+ appended to the end of this article...
+ When users are having real problems, it becomes clear that the arguments
+ are no longer religious. In Lisp, you can get arbitrarily complex and
+ inscrutable once you go to extreme macro-ology and multiple levels of
+ backquoting. However, for the more typical cases handled by the neophyte,
+ the problems of quoting, time-of binding, time-of substitution, and scope
+ of bindings are more consistent and easier to understand in Lisp. And
+ when you need to, you know that there's a very nice macro capability
+ to back up any meta-level programming you need to accomplish.
As a computer scientist, I found Lisp beautiful and easy to learn.
But that doesn't mean I like programming in it. The heart of Lisp,
the list, models only a fraction of the algorithms and data structures
that I deal with. Everything else is 2nd class and dilutes the beauty
of the language. As soon as I wrote my first do-loop in Lisp, started
declaring my data structures, and explaining all sorts of things to
the compiler, the courtship was over. As I remember, macros were the
final straw. As you admit, they make the language inscrutable, and
since everyone uses them...
I am not defending Tcl. I am simply saying that I find your arguments
about Lisp contrived. There are obvious difficulties in Lisp to
beginners that you have conveniently forgotten. If as many people
were learning Lisp as were learning Tcl, I'm sure the number of
beginner-type questions to comp.lang.lisp would be just as high. I
actually went and looked to see what's happening in the newsgroups and
c.l.l has the same beginner questions that you can find in any
language newsgroup. Here's a classic sample:
>From: [name changed to protect the innocent]
>Subject: Book Recommendation????
>Message-ID: <2vo19p$o...@jadzia.CSOS.ORST.EDU>
>Date: 10 Jul 94 05:34:49 GMT
>
>I am new to the LISP language (studying for alomst a year) and have read
>a few books on LISP. I am interested in hard core (excuse the expression)
>programming using the LISP language. Most of the books that I have read
>have gotten confusing about halfway through. I know this may have been
>asked in the past but I would like to know what book(s) would be
>recommended for a beginner on LISP?? Any responses would be greatly
>appreciated...Thanks
This poor guy has been studying Lisp for a year, has read several
books on it and still considers himself "new to the language"?!
My point is, citing messages from confused novices doesn't prove the
language is difficult any more than messages from rabid experts proves
that the language is great.
Don Libes <li...@nist.gov>
Paul Alexander
|> Finally, I think that having language syntax depend on newlines is a bad
|> idea -- I think most unix shell programmers will grudgingly agree with me
|> on this. I'd much rather have a Lispish syntax where you delineate your
|> current top-level evaluations by [ ... ] and don't bother with newlines.
But Tcl was intended, and used by many of us, as a shell-like command
interface to applications and ALSO as an extension language. I think the
vast majority of users would be confused by a "SHELL" in which newline did
not terminate input to a command. It is in this respect that Tcl's very
simple syntax is just the job for an embedded language.
Paul Alexander
Department of Physics, University of Cambridge, Cambridge, UK
Stephen J Bevan
... As a computer scientist, I found Lisp beautiful and easy to learn.
But that doesn't mean I like programming in it. The heart of Lisp,
Lisp 1.5 perhaps, but things have moved on since then. Functions are
the heart of Scheme (I don't think Common Lisp has a heart :-)
... models only a fraction of the algorithms and data structures
that I deal with. Everything else is 2nd class and dilutes the beauty
of the language. ...
Are you implying that structures, vectors, ... etc. are all "2nd
class" in Common Lisp? Either way, what is your definition of "2nd class"?
Juergen Wagner
public domain): those using an interpreted approach, and those based
on a compiled language. The interpreted tools use a more or less
simple language to specify or actually program widgets, gadgets, and
whatever they may call them. The compiled tools emit C or C++ code
where a user may fit in his/her application code.
Both have advantages and disadvantages: interpreted languages usually
allow dynamic loading in a simple fashion, i.e., they are good for
prototyping of complex user interfaces you couldn't easily do in a
compiled environment due to the time needed for edit-compile-run
cycles. Also, compiler-based languages require an entire restart of
the application (because the patched program is a new program), while
interpreted systems can handle updates on the fly. Compiler-based
languages are more efficient for numerical calculations and other
low-level operations.
Compiling both approaches is what has been done in LISP. One of the
problems of LISP (still my favourite programming language), however,
is that it is a fully-fledged programming language with constructs a
little bit unfamiliar to usual programmers. The price you have to pay
for an elegant language like LISP: it is...umm... different.
Tcl also tries to combine the two approaches by providing an
interpreted language which is extensible by C- or C++-written
commands. However, sacrificing a real type system (LISP has a full
type system) causes problems for certain applications: take an
object-oriented database, for example. Object types and ids cannot be
simply distinguished from strings which happen to look the same. Users
have to artificially add type markers because there are only strings
in Tcl. Syntactic features must be used to differentiate between
types.
Other than that, Tcl very much resembles a LISP with BASIC elements,
and turns out to be useful for most user interface designs, although
the syntacticness of types can cause weird situations with character
or expression quoting.
As for Tk, there are also advantages and disadvantages: First of all,
it is nice to have a toolkit of relatively elaborate widgets which is
as simple to manage as Tk. Tools like XDesigner are nice, but once you
go beyond what they provide as pre-manufactured widgets, you have to
go down into the basement and dig up those Motif manuals. Also, you
may find your actual data items nested into a four-level struct. The
problems with Tk come in where compute-intensive portions of a GUI
need to be implemented. Passing data between Tcl/Tk and a C/C++
application in the form of strings simply won't be efficient enough
for such applications.
This is the point where I wished I had a more layered system at my
disposal:
Level 0 Xlib and friends
Level 1 Tk with a C/C++ interface pretty much
like SunView had
Level 2 Tcl-binding for Tk
This way, Tk would be 100% separated from Tcl, also allowing other
languages to bind more easily to the nice widgets provided. In
particular, C/C++ interfaces would be able to directly access
functions to do their high-volume data output which would be too
time-consuming when done through Tcl strings.
In a way, the purely syntactic character of data types in Tcl wouldn't
be that much of an issue any more because the critical parts, where
type semantics is lost in string conversion, could be done directly in
C or C++, or any other language replacing the level-2 binding (LISP?).
How much of Tk would be available at level 2, and how types are
handled exactly, would be left to level 2. Tcl would be a simple but
type-wise restricted language, LISP could carry through all
information.
The ultimate question always is: "Is it useful for my application? If
not, what is?" We had a project at FhG-IAO, where the GUI design was
done with a copmiler-based GUI designer. At some point, there was a
requirement to do splines. Due to problems implementing this quickly
under the GUI tool, we had to bring in UNIRAS, a huge, overkill
scientific visualization package. It sort of worked, but was an
incredible kludge to use that monstrous package only for the splines.
Little later, the entire GUI was re-done with Tcl/Tk. Not only was the
development time (including the time to learn Tcl/Tk) of the entire
GUI much shorter, but the configurability and overall flexibility was
greatly enhanced.
If I compare the results (and efforts!) for some GUI designs, I'm
happy to have a tool at my disposal which allows me to quickly
prototype GUIs without bothering much about type information and
declarations. This tool may be Tcl/Tk, it may be a LISP-based
environment. If I only have to position a few buttons, choose colors,
and plug a simple database interface program into the resulting GUI, a
tool like XDesigner would be most welcome. At WESCON'94, I'll describe
some of the experiences made in this project and others in more
detail.
IMHO, some of the previous discussion, where religious arguments came
up, lacked this view.
--Juergen Wagner
Juergen...@iao.fhg.de
gan...@csli.stanford.edu
Fraunhofer-Institut fuer Arbeitswirtschaft und Organisation (FhG-IAO)
Nobelstr. 12c Voice: +49-711-970-2013
D-70569 Stuttgart, Germany Fax: +49-711-970-2299
For more information/detail, please do "finger gan...@csli.stanford.edu".
Martin Rodgers
ma...@netcom9.netcom.com "Niels P. Mayer" writes:
> I think the whole "popularity" line of reasoning is questionable: MS-DOS
> and MS-WINDOWS are more popular than Unix/X, but many of us have good
> reasons to keep working on Unix and X. Beyond that, if you're worried about
> popularity, both the Lisp and TCL/Tk community are no doubt insignificant
> when comparted to, say the Visual Basic community, or Actor, or other
> similar packages available for MS-WINDOWS.
This is true. If you don't use VB or VC++, there are a lot of people
who won't take you too seriously. Even Actor and Smalltalk/V get heavy
criticism, coz reviewers (I'm told that one of the was Ray Duncan) use
the "Hello, World" type app (App? What a joke.) as a benchmark. Using
code like that can make even VC++ look bad, but that doesn't stop
reviewers wetting themselves over it, while all they can say about
Lisp, Smalltalk and Actor is that you _can_ use them if you want to.
They don't say you _have_ to, which is what they're saying about VB
and VC++.
That may explain why I never see any job offers for Lisp or Smalltalk,
but I see many for C++ and VB. Perhaps I'm looking in the wrong places?
After all, I'm only looking in the mainstream computing press.
Languages issues arew irrelevent when you look at them like this. It's
too easy to say, "Pay me to use your favourite language, and I'll be
happy to install it and program with it."
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
If "One likes to believe in the freedom of email", email
clipper....@cpsr.org and tell them you oppose Clipper.
This is a shareware .signature -- please pass it on!
Michael Tiller
|> In article <30p74c$q...@ef2007.efhd.ford.com> til...@solace.me.uiuc.edu (Michael Tiller) writes:
|>
|> Am I the only one who finds this paragraph self-contradicting.
|> "...as long as no employer of mine ever demands that I write...TCL/Tk"
|>
|> followed in virtually the same breath by
|> "...use the best tool for the job..."
|>
|> With all due respect for the wonderful implementation of Tcl, I find
|> it difficult to think of a job for which Tcl is the best tool.
|> Perhaps someone could make a list?
Well, I use a variety of tools some use TCL/Tk some don't. The two
most recent uses I have found for TCL/Tk were...
1) My real work (research) deals with mathematics. As part of this
research I found it necessary to write a Finite Element analysis
package. The package is written in C++ and I was quite content
to write a C++ "program" for each FEA "problem" that I wanted to
run. However after a while this got pretty tedious. Basically,
what it comes down to is the need for an input file which is
read interactively. Now I played around with some parser tools
to try to write a grammar for my input files. However, I kept
changing what kinds of elements I had and such and it got pretty
tedious. Then I decided to write the front-end in TCL. It
works great. Among the added features of using TCL...
* Expressiveness. I can use for loops and such rather than
explicit lists
* I get some added interactive capabilities. For example, in
addition to specifying the problem, I get a certain amount of
control over number of time steps and such. I can stop half
way through a simulation to examine some results
2) I'm currently working as a contractor for Ford Motor Company until
August. They had several text-based applications and they wanted
me to write some GUI stuff for them. I banged these GUIs together
pretty damn fast with the help of TCL/Tk. This has sparked a fair
amount of interest in TCL/Tk here in my department.
Now, I could have used anything I wanted for both of these projects
and I chose TCL/Tk because I felt they were the best tools for the
job. So far, I'm very happy with the results.
|>
|> Bill
|> --
|> Bill Janssen <jan...@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
|> Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
|> URL: ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html
Michael Tiller
University of Illinois
Christophe Muller
> Neils Mayer's recent post detailing the applications written
> wholly or partially in Lisp IMHO should end all talk of Lisp
> is Dead.
Lisp is not dead.
I think Lisp _and_ Tcl, and Perl etc.. will have more and more fields of
applications, it's just a matter of increasing CPU power and of ratio
hardware cost vs engineer cost (is this a fact that we could all agree on? :-).
It seems that Unix, X11, Windows, Emacs, Gcc will stay written in C (with a
small interpreter when needed) for a while, but that a lot of other
applications will be better generated in Cobol by a L4G or in C by Eiffel,
the rest, the "glue" for integrations being Tcl or Lisp code.
For this reason, a religious war between Lisp and Tcl is pointless, they
will certainly *both* have more and more adepts, and C/Fortran/Cobol less.. at
least I hope.. :-)
Cheers,
Christophe.
= % ping elvis =
= elvis is alive =
Don Bennett
> which newline did not terminate input to a command.
Do you really think so? On my machine, only csh terminates input
with a newline.
sh, ksh, and bash will prompt for additional input if you haven't
closed your quoted expressions.
The secondary prompt makes it clear (to me at least) that additional
input is expected.
--
Don Bennett (415)390-2145
d...@sgi.com
Silicon Graphics
Mathieu Longtin
In some earlier part of this discussion, somebody mentionned
a Scheme/Tk package called "STk" if I remember well. However
I can't seem to find anything about that package, does
anybody knows a ftp/www address where I could find info about
STk?
Thanks in advance
Mat
Peter da Silva
Don Bennett <d...@sgi.com> wrote:
> > I think the vast majority of users would be confused by a "SHELL" in
> > which newline did not terminate input to a command.
> Do you really think so? On my machine, only csh terminates input
> with a newline.
> sh, ksh, and bash will prompt for additional input if you haven't
> closed your quoted expressions.
% tcl
tcl>echo "hi there
=>foo"
hi there
foo
What's your point?
--
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?"
David Eby
You can find STk 2.1 in the Scheme Repository:
ftp.cs.indiana.edu:/pub/scheme-repository/imp/STk-2.1.tar.gz
I believe this is the latest version of STk. If you just want info
without actually downloading the package, you might try sending mail
to Erick Gallesio (e...@unice.fr).
David Eby
de...@cs.indiana.edu
Martin Rodgers
li...@nist.gov "Don Libes" writes:
> As a computer scientist, I found Lisp beautiful and easy to learn.
> But that doesn't mean I like programming in it. The heart of Lisp,
> the list, models only a fraction of the algorithms and data structures
> that I deal with. Everything else is 2nd class and dilutes the beauty
> of the language. As soon as I wrote my first do-loop in Lisp, started
> declaring my data structures, and explaining all sorts of things to
> the compiler, the courtship was over. As I remember, macros were the
> final straw. As you admit, they make the language inscrutable, and
> since everyone uses them...
Which Lisp dialect was this? Is it one with structures? Arrays?
Not everything is a list. Some things are even symbols.
> This poor guy has been studying Lisp for a year, has read several
> books on it and still considers himself "new to the language"?!
I still consider myself new to C, even tho I first used it in the
early 80s. Now I'm learning C++, which looks even worse. Most of
what I consider "learning a language" to be is more than the syntax
and the symantics. It's more like style and experience.
> My point is, citing messages from confused novices doesn't prove the
> language is difficult any more than messages from rabid experts proves
> that the language is great.
Agreed. Languages are just different. I love an exchange of opinions,
but please, _please_ let's not try to "prove" anything?
David Chase
|> Lisp is not dead.
|> I think Lisp _and_ Tcl, and Perl etc.. will have more and more fields of
|> applications, it's just a matter of increasing CPU power and of ratio
|> hardware cost vs engineer cost (is this a fact that we could all agree on? :-).
But Lisp could have better syntax. On the other hand, all these other
little languages could have better semantics. For some time it has been
a pet peeve of mine that people inventing little languages, with their
syntax appropriate-to-task/audience, seem to feel it is necessary to badly
re-invent execution semantics. It-would-be-nice if people would take a
little bit of trouble to layer their new syntax on top of (for instance)
Scheme, or an interpreter built in that (continuation-passing) style (it's
NOT HARD, DAMMIT!)
And, there are those little languages with inferior syntax, which could just
as well be replaced by Scheme with a few appropriate primitives. Here, I'm
thinking of the "languages" used to program sendmail and adb.
Then again, it seems to be the norm in Computer "Science" to step on toes
instead of stand on shoulders. Carry on.
David Chase, speaking for myself
Thinking Machines Corp.
John W. Baugh Jr.
Chase) writes:
> But Lisp could have better syntax. On the other hand, all these other
> little languages could have better semantics. For some time it has been
> a pet peeve of mine that people inventing little languages, with their
> syntax appropriate-to-task/audience, seem to feel it is necessary to badly
> re-invent execution semantics.
Amen. Preach it, brother!
In addition to "unix" languages, the Matlabs and Maples of the world
could use a reasonable --or at least sane-- execution semantics.
--
John Baugh
j...@eos.ncsu.edu
Peter da Silva
David Chase <ch...@Think.COM> wrote:
> But Lisp could have better syntax.
I like TCL fine, but I strongly disagree with this. A lot of Lisp's strengths
are *due* to its unconventional syntax (as is the case with Forth, SmallTalk,
Logo, PostScript, and, yes, TCL).
I just wish Lisp didn't have all these *other* syntaxes for arrays and macros
and everything else layered on top of it. I want Lisp 1.5, damnit.
(Peter shows his age again)
Scheme looks better, these days.
Martin Rodgers
mul...@simulog.fr "Christophe Muller" writes:
> For this reason, a religious war between Lisp and Tcl is pointless, they
> will certainly *both* have more and more adepts, and C/Fortran/Cobol less.. at
> least I hope.. :-)
Agreed. Nobody will ever "prove" one language is "better" than another.
All they'll do is convince people (like me) that there are a few more
fanatics that support language X than language Y. That's hardly an
attractive feature.
Nicolas M Williams
A neat experimental language that is in some ways similar to lisp is
Icon. It is built on the concepts of success/failure (instead of
true/false boolean values), generators and control backtracking. It is
also a very functional language, about the only lisp-like features it
is missing are lambda expressions, quote and and a simple syntax
(although all expressions except for assingments can be expressed in a
form that is very similar to lisp's s-expressions). It's greatest
strength lies in text handling, though it is by no means a specialized
language. It also has most of the types that lisp has and there is a
[relatively] simple way to write variants of it (there's an
object-oriented variant for example).
Icon also has a graphics library that makes graphics programs written
in it fairly portable accross platforms and OS's.
Icon can be obtained from ftp://cs.arizona.edu/icon/ and the newsgroup
for it is comp.lang.icon.
Nick
Mike Gallo
mul...@simulog.fr "Christophe Muller" writes:
>
> For this reason, a religious war between Lisp and Tcl is
> pointless, they will certainly *both* have more and more
> adepts, and C/Fortran/Cobol less.. at least I hope.. :-)
Actually, a religious war needs no point.
--
The more I get to know people, the more I like my dog.
Wolfgang Lux
|> Icon ... is
|> also a very functional language, about the only lisp-like features it
|> is missing are lambda expressions, quote and and a simple syntax
|> (although all expressions except for assingments can be expressed in a
|> form that is very similar to lisp's s-expressions).
lisp. Should it be true that Icon has no way of representing anonymous
functions?
Wolfgang
--
Wolfgang Lux
WZH Heidelberg, IBM Germany IBM IP-Net: l...@rio.heidelbg.ibm.com
+49-6221-59-4546 VNET: LUX at HEIDELBG
+49-6221-59-3300 (fax) EARN: LUX at DHDIBMIP
Bennett Todd
>|> it difficult to think of a job for which Tcl is the best tool.
>|> Perhaps someone could make a list?
As Michael Tiller said, one things TCL/Tk is excellent at is quickly
implementing small GUIs --- particularly GUI front-ends to non-GUI
applications. And that's an excellent model for general programming; don't
put any substantial, complex functionality into a GUI program if you can
help it; instead, write substantive command-line-driven programs, and GUI
front-ends. Improves code-reusability, modularity, regression testing, and
so on.
What's more, it helps set a precedent. As recently as a few years ago,
people were willing to stand up in public and claim that C (or C++) was the
only acceptable application development language. Within the last couple of
years Perl has forced its way in as another acceptable language, but somehow
most of those same people now want to try to say that C (or C++) and Perl
are the only two acceptable languages. So write your next application in
TCL/Tk. Then the one after that in Python. Then find a little Scheme, add
some dynamic loading, and create your own language for the next one. Use a
different language for every project until they get the point that chosing
the right language for the job is part of the design process, and can be
revisited _ab_initio_ for each new design.
-Bennett
b...@sbi.com
Henry G. Baker
>mul...@simulog.fr (Christophe Muller) writes:
>|> Lisp is not dead.
>
>|> I think Lisp _and_ Tcl, and Perl etc.. will have more and more fields of
>|> applications, it's just a matter of increasing CPU power and of ratio
>|> hardware cost vs engineer cost (is this a fact that we could all agree on? :-).
>
>But Lisp could have better syntax.
The whole point of Lisp syntax is that it is trivial, and doesn't require
a full-blown parser to interpret. Unfortunately, Common Lisp's parameter
syntax completely blew that particular advantage.
Improving the 'syntax' of a language is a little like climbing a tree
to make the first step towards the moon. It doesn't accomplish very
much, but it's easy and accessible and allows one to feel superior to
those still standing on the ground. In most cases, people would be
better off dispensing with character-based languages completely (e.g.,
for graphical languages), rather than wasting everyone's time creating
additional parsing and training nightmares.
Is the syntax of Lotus 1-2-3 macros really that brilliant, that it deserves
all of the brainpower wasted on it?
After tripping over all the minor syntactic incompatibilities of Fortran,
PL/I, Pascal, C, Ada, ..., I'm sick to death of the whole syntactic mess.
Proponents of syntactic sugar keep claiming their languages are more
'readable', but this presumes that users want to waste time reading
their silly 500-page manuals in the first place. I'm sure that
Persian and Finnish are 'readable' to their natives, too, but that
doesn't mean that they are 'readable' to anyone else.
>On the other hand, all these other
>little languages could have better semantics. For some time it has been
>a pet peeve of mine that people inventing little languages, with their
>syntax appropriate-to-task/audience, seem to feel it is necessary to badly
>re-invent execution semantics. It-would-be-nice if people would take a
>little bit of trouble to layer their new syntax on top of (for instance)
>Scheme, or an interpreter built in that (continuation-passing) style (it's
>NOT HARD, DAMMIT!)
Agreed, but I think that Lisp people have ignored for too long what the
users really want/need. Some of the things they want:
* the advantages of an integrated system with both compiled & interpreted code
* the ability to construct strict (file) and lazy (Unix stream)
compositions of existing functions
* the ability to explicitly control resource usage (GC hides too much)
without creating dangling references
* the ability to encapsulate nearly anything within a protocol-conversion
wrapper
* a powerful defaulting mechanism that isn't based on _state_ and
_state variables_. (This is probably one of the most important
problems facing the functional language community.)
>And, there are those little languages with inferior syntax, which could just
>as well be replaced by Scheme with a few appropriate primitives. Here, I'm
>thinking of the "languages" used to program sendmail and adb.
>
>Then again, it seems to be the norm in Computer "Science" to step on toes
>instead of stand on shoulders. Carry on.
Progress in most fields requires a throwing away of paradigms that
bind and constrict. Perhaps it is time to stop teaching students how
to parse, so they can focus on more worthwhile pursuits?
Joseph H Allen
Henry G. Baker <hba...@netcom.com> wrote:
>In article <31377d...@early-bird.think.com> ch...@Think.COM (David Chase) writes:
>>But Lisp could have better syntax.
>The whole point of Lisp syntax is that it is trivial, and doesn't require
>a full-blown parser to interpret. Unfortunately, Common Lisp's parameter
>syntax completely blew that particular advantage.
I agree. Common lisp is hopeless. Its standard manual is longer than that
of _every_ _other_ programming language and its syntax diverged from the
lisp ideal since the introduction dotted-pairs and ' for quoting. Perhaps
ideal lisp is not powerful or convenient enough for a real language.
>Improving the 'syntax' of a language is a little like climbing a tree
>to make the first step towards the moon. It doesn't accomplish very
>much, but it's easy and accessible and allows one to feel superior to
>those still standing on the ground.
Language syntax is related to style, in the graphic arts sense. It is
important for readability and can guide programming methodology. It helps
programmers remember language syntax and provides historic continuity.
Ideal-Lisp syntax may be trivial but it is not very nice looking. Why do
you think that algorithms in every non-lisp computer journal are printed in
pseudo-Algol-60?
>Is the syntax of Lotus 1-2-3 macros really that brilliant, that it deserves
>all of the brainpower wasted on it?
I don't know what you mean by this. Like lisp, Lotus 1-2-3 macro syntax is
trivial, but also like lisp, it's terrible looking.
>After tripping over all the minor syntactic incompatibilities of Fortran,
>PL/I, Pascal, C, Ada, ..., I'm sick to death of the whole syntactic mess.
Lisp isn't so wonderful in this respect either. Although the syntax, in the
strictest sense of the word, is trivial, the language is big, redundant and
non-uniform.
For example, 'setf' takes list of pairs which don't need to be enclosed:
(setf a 10 b 20 ... ), but then structures, which could also have this
syntax, require parenthesis around its pairs: (defstruct foo (a 3) (b 4)...).
Then there's: set, setq and setf; eq, eql and equal; and let, let*, letrec
and declare. Not to mention: cond and if; do, do*, and dotimes; and
array-dimension, initialize-instance, multiple-value-bind and
with-input-from-string.
>Proponents of syntactic sugar keep claiming their languages are more
>'readable', but this presumes that users want to waste time reading
>their silly 500-page manuals in the first place.
Which programming language has a 500-page manual? Only common lisp. Even
the manuals for PL/I, Ada and Algol-68 are shorter.
>I'm sure that
>Persian and Finnish are 'readable' to their natives, too, but that
>doesn't mean that they are 'readable' to anyone else.
I suppose you'd like them to convert to esperanto.
>>On the other hand, all these other
>>little languages could have better semantics. For some time it has been
>>a pet peeve of mine that people inventing little languages, with their
>>syntax appropriate-to-task/audience, seem to feel it is necessary to badly
>>re-invent execution semantics. It-would-be-nice if people would take a
>>little bit of trouble to layer their new syntax on top of (for instance)
>>Scheme, or an interpreter built in that (continuation-passing) style (it's
>>NOT HARD, DAMMIT!)
>Agreed, but I think that Lisp people have ignored for too long what the
>users really want/need. Some of the things they want:
I agree too, most languages could use better semantics. But they don't need
lisp's syntax.
>>And, there are those little languages with inferior syntax, which could just
>>as well be replaced by Scheme with a few appropriate primitives. Here, I'm
>>thinking of the "languages" used to program sendmail and adb.
I don't see what's so great about scheme. Constructs such as
(call-with-current-continuation name (body)) certainly don't encourage the
use of it's powerful semantic capability.
The major semantic paradigms present in scheme/lisp are:
1 Closures
2 Loops through tail-recursion and lambda functions
3 Type inference
4 Self-representation through common list syntax
1 is the most important one, and is syntacticly possible with other
languages. Most functional languages have closures. Other static languages
don't have them because they do not sit well with stack-based local
variables. For a non-lisp and non-functional language with closures, try my
language Ivy.
2 and 3 are not necessary, hurt readability and can be considered semantic
sugar.
4 is the only one which is really unique to lisp. It's made redundant by 1
though, so I don't miss it.
--
/* jha...@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
rodrigo vanegas
Finally, this long thread has reached the heart of what i believe to
be the principal reason why we can't do without lisp.
In article <Ctu43...@world.std.com>, jha...@world.std.com (Joseph H Allen) writes:
> The major semantic paradigms present in scheme/lisp are:
> 1 Closures
> 2 Loops through tail-recursion and lambda functions
> 3 Type inference
> 4 Self-representation through common list syntax
> 1 is the most important one, and is syntacticly possible with other
> languages. Most functional languages have closures. Other static languages
> don't have them because they do not sit well with stack-based local
> variables. For a non-lisp and non-functional language with closures, try my
> language Ivy.
1) ML also meets this criteria. It is an impure functional language
(meaning it has assignment which is all you need to program as you
would in C), and has a pleasant non-lisp syntax.
> 2 and 3 are not necessary, hurt readability and can be considered semantic
> sugar.
2) On the contrary, using tail-recursion allows one to use the return
values of each iteration to accumulate final values. (Mail me if you
want an example.) This is not possible with WHILE or FOR loops in
C/Pascal. Although, i admit that the paren-syntax is annoying, i
still prefer to program loops with tail recursion.
3) Type inference in Lisp? This is new to me. (Someone please
enlighten me here.)
> 4 is the only one which is really unique to lisp. It's made redundant by 1
> though, so I don't miss it.
4) But this is the ultimate reason why LISP is still indispensably
unique. Lisp's macros and ultra-flexible syntax have made it the
hot-bed of language research for many many years and continues to play
that role today. (Consider MOP, CLOS, CL Condition System, and
syntax-case for Scheme.) It's not made redundant by closures at all.
You still need the macros which can manipulate code as data
self-referentially.
Even so, i will concede without prompting,that if one is not
interested in either higher-order functions or language
experimentation, the lisp parentheses become only a nuisance and
Common Lisp's size just an obstacle to delivery.
rodrigo vanegas
r...@cs.brown.edu
Henry G. Baker
>In article <hbakerCt...@netcom.com>,
>Henry G. Baker <hba...@netcom.com> wrote:
>>In article <31377d...@early-bird.think.com> ch...@Think.COM (David Chase) writes:
>>>But Lisp could have better syntax.
>
>>The whole point of Lisp syntax is that it is trivial, and doesn't require
>>a full-blown parser to interpret. Unfortunately, Common Lisp's parameter
>>syntax completely blew that particular advantage.
>
>I agree. Common lisp is hopeless. Its standard manual is longer than that
>of _every_ _other_ programming language and its syntax diverged from the
>lisp ideal since the introduction dotted-pairs and ' for quoting. Perhaps
>ideal lisp is not powerful or convenient enough for a real language.
I think a quick perusal would show that most languages are happy with syntax
_trees_. Lisp S-expressions are general trees. QED
>>Improving the 'syntax' of a language is a little like climbing a tree
>>to make the first step towards the moon. It doesn't accomplish very
>>much, but it's easy and accessible and allows one to feel superior to
>>those still standing on the ground.
>
>Language syntax is related to style, in the graphic arts sense. It is
>important for readability and can guide programming methodology. It helps
>programmers remember language syntax and provides historic continuity.
God save us from language designers who want to impose their own personal
styles on all their users. The problem is that programming styles change
rather more rapidly than languages do, leaving the programs and programmers
of the 'I know what's best for you' languages high and dry.
>Ideal-Lisp syntax may be trivial but it is not very nice looking. Why do
>you think that algorithms in every non-lisp computer journal are printed in
>pseudo-Algol-60?
And how nice looking is the numerical program in pseudo-Algol that has
to first symbolically differentiate its functional argument, before
compiling and executing it?? Lisp syntax is ideal for programs which
must analyze and/or compose other programs. Since this is one of the
most powerful software levers available, languages which make this
difficult are guaranteeing poor productivity.
As to the pseudo-Algol-60 algorithms in computer books and
journals--it's truly a shame that Knuth never really got into Lisp.
His books would be _more_ readable, and TeX might actually have been a
decent language. Sigh...
>Lisp isn't so wonderful in this respect either. Although the syntax, in the
>strictest sense of the word, is trivial, the language is big, redundant and
>non-uniform.
>
>For example, 'setf' takes list of pairs which don't need to be enclosed:
>(setf a 10 b 20 ... ), but then structures, which could also have this
>syntax, require parenthesis around its pairs: (defstruct foo (a 3) (b 4)...).
>
>Then there's: set, setq and setf; eq, eql and equal; and let, let*, letrec
>and declare. Not to mention: cond and if; do, do*, and dotimes; and
>array-dimension, initialize-instance, multiple-value-bind and
>with-input-from-string.
Touche' ! (I'll have to send you a copy of my article "If it ain't Baroque,
fix it!")
>>Proponents of syntactic sugar keep claiming their languages are more
>>'readable', but this presumes that users want to waste time reading
>>their silly 500-page manuals in the first place.
>
>Which programming language has a 500-page manual? Only common lisp. Even
>the manuals for PL/I, Ada and Algol-68 are shorter.
The PL/I manual that I used was many more than 500 pages. Algol-68 is
shorter, but only because it appears to have been LZ-compressed and
therefore incomprehensible. The Ada83 manual is shorter, but you then need
the Commentaries and the Congressional Record to figure out what the manual
says.
Look at the computer books in your nearby Bookstar. Of course, the chatty
style, the double spacing, and those silly small-format pages do a lot to
create 500++ page books.
>The major semantic paradigms present in scheme/lisp are:
>
>1 Closures
>2 Loops through tail-recursion and lambda functions
>3 Type inference
>4 Self-repre