From: Niels P. Mayer
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <MAYER.94Jul22112140@netcom9.netcom.com>
[note additional crossposting to comp.lang.lisp]
In article <··················@x1.cygnus.com> ····@x1.cygnus.com (Tom Lord) writes:
······@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: ······@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.
From: Michael Tiller
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <30p74c$q0n@ef2007.efhd.ford.com>
In article <···················@netcom9.netcom.com>, ·····@netcom9.netcom.com (Niels P. Mayer) writes:
[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
From: Bill Janssen
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <JANSSEN.94Jul22212224@holmes.PARC.Xerox.Com>
In article <··········@ef2007.efhd.ford.com> ······@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?
Bill
--
Bill Janssen <·······@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
From: Michael Tiller
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <310bo9$832@ef2007.efhd.ford.com>
In article <·····················@holmes.PARC.Xerox.Com>, ·······@parc.xerox.com (Bill Janssen) writes:
|> In article <··········@ef2007.efhd.ford.com> ······@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 <·······@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
From: Mathieu Longtin
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <longtin.775156750@drebin>
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
From: David Eby
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <1994Jul25.185243.8685@news.cs.indiana.edu>
In article <·················@drebin>, Mathieu Longtin <·······@crim.ca> wrote:
>
>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
>
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 (··@unice.fr).
David Eby
····@cs.indiana.edu
From: Bennett Todd
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <319if7$ob6@sbi.sbi.com>
>|> 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?
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
···@sbi.com
From: Richard Karpinski
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <DICKK.94Jul22152239@netcom13.netcom.com>
Neils Mayer's recent post detailing the applications written
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"
From: Christophe Muller
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <MULLER.94Jul25192443@obelix.simulog.fr>
In article <···················@netcom13.netcom.com> ·····@netcom13.netcom.com (Richard Karpinski) writes:
> 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 =
From: David Chase
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <31377dINNk0c@early-bird.think.com>
······@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. 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.
From: Thomas M. Breuel
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <TMB.94Aug1204029@arolla.idiap.ch>
In article <··········@world.std.com> ·······@world.std.com (Joseph H Allen) writes:
|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.
CommonLisp is not particularly complicated by modern standards. Most
of CLtL/2 describes what in other languages is part of a separate
library standard. And CLtL/2 describes a language that is
substantially simpler than, say, C++ and several other successful
modern languages.
Still, CommonLisp probably should be simpler...
Thomas.
From: Richard A. O'Keefe
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <327lgq$lgd@goanna.cs.rmit.oz.au>
···@arolla.idiap.ch (Thomas M. Breuel) writes:
>CommonLisp is not particularly complicated by modern standards. Most
>of CLtL/2 describes what in other languages is part of a separate
>library standard.
For what it's worth, I have a paper copy (double-sided A4) of the current
draft of the Ada 9X standard. It's pretty close to CLtL2 in bulk. About
half of that is "language", and half of it is "libraries". Since Ada9x
and Common Lisp have _comparable_ feature sets (OOP + packages) apart from
philosophical differences about types, this is not too much of a surprise.
If it comes to that, my C++ document set + NIHCL library doc are about the
same size as CLtL2.
--
30 million of Australia's 140 million sheep
suffer from some form of baldness. -- Weekly Times.
From: Larry W. Virden
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <1994Aug9.112115.3040@chemabs.uucp>
How many pages are we talking here? I mean the Tcl book, with only one of
the dozens of extensions described, is 458 pages (counting index). If
there were documentations on [incr tcl] - the OOP extension I would guess
that we would be talking 600+ pages. This book contains some
tutorial information though.
--
:s Great net resources sought...
:s Larry W. Virden INET: ·······@cas.org
:s Personal: 674 Falls Place, Reynoldsburg, OH 43068-1614
The task of an educator should be to irrigate the desert not clear the forest.
From: Thomas M. Breuel
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <TMB.94Aug1204400@arolla.idiap.ch>
In article <··········@world.std.com> ·······@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
Type inference is definitely not a "semantic paradigm" of Scheme or
Lisp. Type inference is mainly used in statically typed functional
programming languages like SML and Haskell. Scheme and Lisp use
dynamic typing.
Thomas.
From: Richard Mlynarik
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <MLY.94Aug1164846@carrot.adoc.xerox.com>
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.
As I see it, computer "science" as taught is to a large extent a
matter of using YACC and being able to write shell-scripts.
It is sad but unsurprising that people who have mastered (or
bachelored) this rubbish feel that they must constantly demonstrate
and highlight their competence by insisting that it be used as much as
possible.
From: Bennett Todd
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <31uil1$jrn@sbi.sbi.com>
In article <················@carrot.adoc.xerox.com>,
Richard Mlynarik <···@adoc.xerox.com> wrote:
>As I see it, computer "science" as taught is to a large extent a
>matter of using YACC and being able to write shell-scripts.
>
>It is sad but unsurprising that people who have mastered (or
>bachelored) this rubbish feel that they must constantly demonstrate
>and highlight their competence by insisting that it be used as much as
>possible.
As you said, ``to a large extent'', but it isn't universal. There are some
Computer Science departments that strive to treat it as a real academic
science, putting the emphasis on theoretical results.
There are others that chose to pursue it as an engineering discipline, where
the focus is on mastering the range of techniques currently used to get real
work done, with enough theory to leave the students equipped to learn new
techniques as they are evolved.
There seems to be a lag of 10 to 20 years, as best I can see, between the
theoreticians dreaming up new concepts and the engineers putting them to
good use to get work done. Shortening up that lag is desireable, but I don't
see how it can happen; the people who are dreaming up the new concepts
aren't concerned with practical application. In fact, the one school I have
personal experience with had a theoretical bent so strong that they weren't
interested in practical work for academic credit.
So I think the really interesting question is:
What new, better techniques _should_ people be using to get work done?
-Bennett
···@sbi.com
From: David J. Hughes
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <31k7d2$nvv@kirk.Bond.edu.au>
I didn't see the original of this, but a language that hasn't been
mentioned in ESL. ESL is a C styled scripting language that provides
the C programmer with a familiar and convenient environment. The 'E'
stands for extensible. I've just had a student add Motif bindings to
ESL so the next release will fit the original question.
ESL itself supports automatic memory allocation for text objects,
arrays, and associative arrays. Assoc's can also be either in-core or
bound to ndbm files without any modification to their usage. Scripts
can also be "compiled" into an architecture neutral format and shiped
onto any box running the ESL interpreter (bit like forth in that regard
- or so I'm told).
There are currently bindings provided for SNMP and also Mini SQL. It
was originally written for use in network management.
I may be biased (probably am since I wrote it :-) but it's a nice
language if your a C programmer. If you want to have a look at it it's
available from ftp://Bond.edu.au/pub/Bond_Uni/Minerva/esl. Like I said,
the Motif support will appear in the enxt release.
__ David J. Hughes - ·····@Bond.edu.au
/ \ / / / http://Bond.edu.au/People/bambi.html
/___/ __ _ ____/ / / _
/ \ / \ / \ / / / / / \ / Senior Network Programmer, Bond University
\___/ \__// / \__/ \__/ / / / Qld. 4229 AUSTRALIA (+61 75 951450)
From: Tim Bradshaw
Subject: Type inference (was Re: What other experimental languages...? (was: Why is TCL successful ?))
Date:
Message-ID: <TFB.94Aug3175207@burns.cogsci.ed.ac.uk>
* Joseph H Allen wrote:
> IMHO, except for trivial programs, declarations improve readability because
> you can easily figure out what is stored in variables and arguments and
> don't have to trace constants or depend on operators not being overloaded.
> You can jump into the middle of a program and start modifying it without
> comprehending all of it. It makes your programs less general perhaps, but
> definitly more readable.
But I want this to work (yes this is a trivial program, but it could
be part of a non-trivial one, and having to put declarations in at
that level is a serious pain.
(defun foo (n)
(declare (fixnum n))
(dotimes (i n ...)
<use i, compiler knows i is a fixnum>
...))
> Likewise, structures (records) are better than
> lists and tuples.
Which is why people use them in Lisp of course.
--tim
There's something about languages with overly complex syntax and
crufty semantic foundations that makes them popular. I wish I
understood it.
The semantics of TCL are truly mind-boggling. I was using it to build
a gui front-end to something (under the dicates of portability).
Suffice to say, I ended up using a couple of global variables to pass
things around.
In fact, I highly recommend trying to write a nontrivial program in
TCL, as a rather enlightening experience. You should particularily try
to use 'uplevel' and 'upvar'. You should also pass associative arrays
around a lot. Try pass closures as the 'action' field of a pushbutton.
On the plus side, TCL interfaces to C very easily. There's no garbage
collection to worry about. Data structures are simple. All in all,
it's a breeze to write tcl commands in C.
Maybe part of the reason for the success of TCL and C++ is this. Lisp
& Smalltalk & ML & your favourite language all provide a number of
simple primitives, which you connect together to form an
application. The primitives themselves are a bit abstract, so it takes
some creativity to apply them in order to reach your goal. With some
experience, though, cranking out common program structures becomes
automatic.
TCL & C++, on the other hand, have language features for many of the
things you might wish to do. So you get a nice warm feeling by looking
in the index for the manual and seeing the thing you want to do there.
You should look at Jeff Ullman's "Elements of ML Programming" as an
example of how to present a language as a large collection of
solutions, rather than as a simple and elegant set of primitives.
I'm not knocking the book - it just has a very different style from
the way I like to think about languages. (You don't learn until
chapter 21 of 26, in the "Additional Details and Features" section,
that you can curry functions.) In fact, I would highly recommend the
book to anyone who wants to learn to program in ML, and hasn't seen
much beyond Pascal or C.
It seems to be the case that language designers have a different way
of thinking about things than inexperienced language users.
"Elements...", like Ousterhout's TCL manual, presents them in a nice,
concrete way that's palatable to beginners. The manuals for any of the
research languages I've used are very different.
To summarize, TCL is succeeding because:
- hello-world-in-an-X-window is 2 lines, and easy to understand
- the manual is very concrete
- the environment is very portable
- there are no abstract concepts you need to learn to write basic programs.
--
--
Trevor Blackwell ···@das.harvard.edu (617) 495-8912
(info and words of wit in my .plan)
Disclaimer: My opinions.
* Trevor Blackwell wrote:
> There's something about languages with overly complex syntax and
> crufty semantic foundations that makes them popular. I wish I
> understood it.
I think that it's because natural languages are like this too (well,
they have complex syntax and semantics, perhaps not overly complex).
This however doesn't explain why only *some* people like these
programming languages.
--tim
In article <················@burns.cogsci.ed.ac.uk>, ···@cogsci.ed.ac.uk (Tim Bradshaw) writes:
|> * Trevor Blackwell wrote:
|> > There's something about languages with overly complex syntax and
|> > crufty semantic foundations that makes them popular. I wish I
|> > understood it.
|>
|> I think that it's because natural languages are like this too (well,
|> they have complex syntax and semantics, perhaps not overly complex).
|> This however doesn't explain why only *some* people like these
|> programming languages.
There's generally a common reason people like things that are
"crufty" and "complex": job security.
Perhaps that's the reason so many of these complex and crufty
systems are economically viable - and why so many academic systems
are not. Academicians should remember to add a healthy helping of
cruft and complexity to their designs.
Something to think about.
- Mark
In article <··········@fido.asd.sgi.com> ···@hoot.asd.sgi.com (Mark Kilgard) writes:
>In article <················@burns.cogsci.ed.ac.uk>, ···@cogsci.ed.ac.uk (Tim Bradshaw) writes:
>|> * Trevor Blackwell wrote:
>|> > There's something about languages with overly complex syntax and
>|> > crufty semantic foundations that makes them popular. I wish I
>|> > understood it.
>|>
>|> I think that it's because natural languages are like this too (well,
>|> they have complex syntax and semantics, perhaps not overly complex).
>|> This however doesn't explain why only *some* people like these
>|> programming languages.
>
>There's generally a common reason people like things that are
>"crufty" and "complex": job security.
>
>Perhaps that's the reason so many of these complex and crufty
>systems are economically viable - and why so many academic systems
>are not. Academicians should remember to add a healthy helping of
>cruft and complexity to their designs.
I thought that adding cruft and complexity was the role of the ANSI/IEEE
standardization committee. :-)
Henry G. Baker:
I thought that adding cruft and complexity was the role of the ANSI/IEEE
standardization committee. :-)
uh, oh. i cannot wait for a IEEE standard on perl. :-]
> There's generally a common reason people like things that are
> "crufty" and "complex": job security.
>
> Perhaps that's the reason so many of these complex and crufty
> systems are economically viable - and why so many academic systems
> are not. Academicians should remember to add a healthy helping of
> cruft and complexity to their designs.
Yes -- just look at;
LISP
COBOL
The excuse given to me when I enquired as to just why I should learn
lisp when there are perfectly good, and genuine, functional languages
I could use was that
"in the world of AI research, lisp is everywhere.
If you can't speak lisp, you won't do very well
in AI research. Its whats out there.
So much AI software is written in lisp..."
etc.
Lame excuses for perpetuating a lame language.
IMHO of course :-)
>The excuse given to me when I enquired as to just why I should learn
>lisp when there are perfectly good, and genuine, functional languages
>I could use was that
>"in the world of AI research, lisp is everywhere.
> If you can't speak lisp, you won't do very well
> in AI research. Its whats out there.
> So much AI software is written in lisp..."
>etc.
>Lame excuses for perpetuating a lame language.
>IMHO of course :-)
Golly, I can kind of see how C or TCL might get propagated this way,
seeing how they are comparatively featureless and straightforward to
learn, but LISP? Why would all these counterproductive academics
go to all the trouble to learn this complex language unless it gave
them unique flexibility? Could it be that LISP has been useful in
developing these `good, and genuine functional languages'? Hmm.
Apparently you weren't convinced, and didn't try to learn LISP.
In article <···················@cs19.cs.aukuni.ac.nz> ······@cs19.cs.aukuni.ac.nz (Stephen David Wray) writes:
>> There's generally a common reason people like things that are
>> "crufty" and "complex": job security.
>>
>> Perhaps that's the reason so many of these complex and crufty
>> systems are economically viable - and why so many academic systems
>> are not. Academicians should remember to add a healthy helping of
>> cruft and complexity to their designs.
>
>Yes -- just look at;
> LISP
> COBOL
What cruft is there in Lisp, as opposed to specific varieties of
Lisp such as Common Lisp?
>The excuse given to me when I enquired as to just why I should learn
>lisp when there are perfectly good, and genuine, functional languages
>I could use was that
>"in the world of AI research, lisp is everywhere.
> If you can't speak lisp, you won't do very well
> in AI research. Its whats out there.
> So much AI software is written in lisp..."
>etc.
>
>Lame excuses for perpetuating a lame language.
>IMHO of course :-)
That's what you get for asking the wrong people. People who
don't have good reasons can't give you good reasons.
In article <················@burns.cogsci.ed.ac.uk> ···@cogsci.ed.ac.uk (Tim Bradshaw) writes:
>* Trevor Blackwell wrote:
>> There's something about languages with overly complex syntax and
>> crufty semantic foundations that makes them popular. I wish I
>> understood it.
>
>I think that it's because natural languages are like this too (well,
>they have complex syntax and semantics, perhaps not overly complex).
^^^^^^^^^^^^^^
>This however doesn't explain why only *some* people like these
>programming languages.
IMHO, Terry Winograd showed that the _syntax_ of English is trivial, and
that what NL types were trying to do with parsing and syntax is much better
left to semantic analysis.
The problem with Enlish is analogous to the problem with certain
graphical languages: after you select certain entities to play a part
in the next operation, it is up to the operation to try to figure out
what role each entity will play, based on the semantics of the
operation and the characteristics of the entities.
From: Matthew Newman
Subject: Re: Why is TCL successful ?
Date:
Message-ID: <Cu9nrM.Kv3@deshaw.com>
In <················@netcom.com> ······@netcom.com (Henry G. Baker) writes:
>In article <················@burns.cogsci.ed.ac.uk> ···@cogsci.ed.ac.uk (Tim Bradshaw) writes:
>>* Trevor Blackwell wrote:
>>> There's something about languages with overly complex syntax and
>>> crufty semantic foundations that makes them popular. I wish I
>>> understood it.
I am a little bemused reading all this discussion, Tcl syntax is simple.
All you need to know is "" vs {} quoting including \ quoting.
and $ vs [] substitution.
and what a properly formed list is, which is simle to explain once the
first two concepts have been grasped.
All this can be explained in a hour or so, or in a very small sector of a book.
The problem often is that people do not correctly grasp the
fundamentals, before attacking other parts of the language, in the case
of Tcl the fundamentals are so simple that there is really no excuse.
I personally don't care wether other people like or dislike Tcl, I
certainly don't wish to put down there preferences for other languages,
but it is *not* a complicated language.
My personal reasons for liking it over and above C++ and lisp et al is
that it doesn't force me to "buy in" to a whole new way of thinking, I
can mix and match my solutions to various problems in C or Tcl or any
other language that I can readily interface to C.
Sure I would like to see it faster, there must be a way to get below 23
microseconds for a Tcl nop, but it is a good, *simple* and powerful
system, and I am happy with that.
The debates that go on on Usenet seem to me to often be akin to the
political and cutural battles that have plauged human civilisation ever
since it begun, namely
We expend enormous energy *stressing* we our views are
different to others, rather than building on the commonality
that we all share.
For instance look at modern computing, as defined in popular use, we
are decades behind where we might have been because we fight amongst
ourselves, either between companies for spurious financial or power
gain, but also amongst the research community, isn't it time we matured
beyond this stage in our evolution, think not of differences, but of
what we share.
As always, these our my own views (an my wifes!).
Here's an example of something crufty in tcl syntax:
/usr/local/tcl/bin/wish
% set names(fred) 3
3
% set names([list joe bob]) 99
99
% set names("joe bob") 43
wrong # args: should be "set varName ?newValue?"
% set names({joe bob}) 33
wrong # args: should be "set varName ?newValue?"
% set ind "joe bob"
joe bob
% set names($ind) 77
77
Why aren't these all the same thing?
--
--
Trevor Blackwell ···@das.harvard.edu (617) 495-8912
(info and words of wit in my .plan)
Disclaimer: My opinions.
Trevor Blackwell:
. % set names("joe bob") 43
. wrong # args: should be "set varName ?newValue?"
. % set names({joe bob}) 33
. wrong # args: should be "set varName ?newValue?"
% set names("joe\ bob") 44
44
% set names({joe\ bob}) 55
55
One thing bothers me: in the Tcl manual page, I find the statement
"Backslash substitution is not performed on words enclosed in braces,
except for backslash-newline as described above."
Also,
% set names({{joe bob}}) 33
wrong # args: should be "set varName ?newValue?"
I think this should be considered a tcl bug.
Raul D. Miller n =: p*q NB. prime p, q, e
<········@nova.umd.edu> NB. public e, n, y
y =: n&|&(*&x)^:e 1
x -: n&|&(*&y)^:d 1 NB. 1 < (d*e) +.&<: (p,q)
My personal main bugbear of TCL is that, if I recall correctly,
what we more mortals would code as a=b+c comes out as set a [expr $b+$c].
This hardly strikes me as intuitive. Also there is the array syntax which
escapes me for the moment.
If it weren't so popular I'd guess it was some variety of practical joke.
--
John Styles
From: Jay Sekora
Subject: Re: Why is TCL successful ?
Date:
Message-ID: <330iu3$asb@news.bu.edu>
John Styles (·······@aivis.demon.co.uk) wrote:
My personal main bugbear of TCL is that, if I recall correctly,
what we more mortals would code as a=b+c comes out as set a [expr $b+$c].
No, actually mere mortals would code that as "ADD B TO C GIVING A".
or maybe "(setq a (+ b c))". or maybe "b c + /a def". [Apologies
to comp.lang.lisp'ers if that's totally bogus lisp.]
Seriously, there's nothing wrong with having a personal preference
for the way things look in C over the way things look in Perl or Tcl
or PostScript or APL, but the way expressions look in Tcl isn't a
_failing of the language_, and it isn't _a priori_ less intuitive
than some other way, it's just less like C. (And, to be honest, a
little less like standard algebraic notation, although the "a=" part
is pure C, because it's procedural rather than descriptive.)
I guess you could argue that it's inherently inferior to C because
it requires more typing.
Of course, Tcl is a scripting language, so it makes sense to compare
it to sh or csh, which do things more like Tcl than like C. (Perl
is somewhere in the middle, but more like C.)
This hardly strikes me as intuitive. Also there is the array syntax which
escapes me for the moment.
Hunh?
set foo(bar) something
puts $foo(bar)
set foo(1) something_else
set i 1
puts $foo($i)
what's non-intuitive about that?
If it weren't so popular I'd guess it was some variety of practical joke.
--
John Styles
Ain't a practical joke, ain't necessarily better than what you like,
ain't necessarily worse. Just differ'nt. Tcl makes radically
different tradeoffs than C. That means they're good for different
kinds of things.
All IMHO, of course.
--
Jay Sekora ··@bu.edu
BU Information Technology (MIME ok)
111 Cummington Street
Boston, MA 02115 +1 617 353 2780
From: Peter da Silva
Subject: Re: Why is TCL successful ?
Date:
Message-ID: <id.RN8C1.RT2@nmti.com>
In article <··········@news.bu.edu>, Jay Sekora <··@bu.edu> wrote:
> No, actually mere mortals would code that as "ADD B TO C GIVING A".
> or maybe "(setq a (+ b c))". or maybe "b c + /a def". [Apologies
> to comp.lang.lisp'ers if that's totally bogus lisp.]
No, that's fine, but your Postscript should be {/a b c add def}.
--
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?"
··@caedmon.bu.edu (Jay Sekora) writes:
>John Styles (·······@aivis.demon.co.uk) wrote:
>Seriously, there's nothing wrong with having a personal preference
>for the way things look in C over the way things look in Perl or Tcl
>or PostScript or APL, but the way expressions look in Tcl isn't a
>_failing of the language_, and it isn't _a priori_ less intuitive
>than some other way
[stuff deleted]
>--
>Jay Sekora ··@bu.edu
>BU Information Technology (MIME ok)
>111 Cummington Street
>Boston, MA 02115 +1 617 353 2780
I don't want to focus on TCL syntax (or C or APL). What I'd like to discuss
is this idea of personal preference. Over the years I've observed that
discussions of the merits of languages or particular constructs always seem
to end when someone states that its use is a matter of 'preference'.
Do people really think that software development has become enough of an
engineering discipline -- that is, has reached levels of comparative
technical competence across *most* practitioners -- that 'preference' is a
valid argument?
In the TCL discussion that prompted my message (and this was just the most
recent in a long line of such discussions on more newsgroups than I can
count) I think an objective analysis could be done to determine that one or
the other syntax under discussion was more intuitive or useful, or just
*standard*. This is the whole idea of user interface usability testing. In
lieu of empirical results, we can surely at least perform some simple
analysis be careful argumentation and refutation.
But my main point is that 'preference' is not a valid argument (at least not
at this stage in the development of software engineering).
[The Mighty Captain Flame-Bait dons his Invulnerable Asbestos Suit...]
--
--------------------------------------------------------------------------------
Jeff Kotula ······@camax.com
Camax Systems Inc. Speaking only for myself
-----------------------------------------------
From: Bennett Todd
Subject: Re: Personal Preference: The Devil in Disguise
Date:
Message-ID: <CuytJ2.LAs@ritz.mordor.com>
[Please note Followup-To]
In article <······················@camax.com>,
Jeff Kotula <······@camax.com> wrote:
>Do people really think that software development has become enough of an
>engineering discipline -- that is, has reached levels of comparative
>technical competence across *most* practitioners -- that 'preference' is a
>valid argument?
I think the relative [in]competence of most practitioners isn't the major
issue; it's only one of many. You should always try to pick the best tool
for a job, and sometimes that choice is a matter of preference, of taste.
The choice of programming language should reflect many factors, including
how well you know the languages, whether the job is big enough to justify
the cost of learning a new one, what features are available in each
language, what language implementations are available and how good they are,
who will have to support the resulting program and for how long, and so on.
Sometimes there won't be a clear winner, given all the factors. Since nobody
knows enough to really objectively evaluate all possible factors against all
conceivable languages, there will be many cases where people disagree. Much
of the time it's reasonable to call such cases ``matter of taste'', and
leave it to individual preference.
-Bennett
···@sbi.com
From: S M Ryan
Subject: Re: Personal Preference: The Devil in Disguise
Date:
Message-ID: <smryanCuz0oB.76n@netcom.com>
: In the TCL discussion that prompted my message (and this was just the most
: recent in a long line of such discussions on more newsgroups than I can
: count) I think an objective analysis could be done to determine that one or
: the other syntax under discussion was more intuitive or useful, or just
: *standard*. This is the whole idea of user interface usability testing. In
: lieu of empirical results, we can surely at least perform some simple
: analysis be careful argumentation and refutation.
Some of this was based on a common view of what program variables are. The
common view not always being the most straightforward.
I could argue every variable should be explicitly declared and devarred. It
would certainly clean up C++ syntax and semantics.
--
Tha se eorl ongan for his ofermode | ······@netcom.com PO Box 1563
alyfan landes to fela lathere theode. | Cupertino, California
... ond lof-gearnost. | (xxx)xxx-xxxx 95013
Actually, I think `personal preference' is a very useful tool for
evaluating competence and/or experience. Knowing a programmer's
`personal preference' in tools for accomplishing some task can tell
you a lot about them.
--
Bill Janssen <·······@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
In article <············@phage.cshl.org> ······@phage.cshl.org (William Chang in Marr Lab) writes:
>Do people really think that software development has become enough of an
>engineering discipline -- that is, has reached levels of comparative
>technical competence across *most* practitioners -- that 'preference' is a
>valid argument?
On the contrary, my opinion is that programming is still an art, so
concessions must be made to foster individual creativity. Hence, personal
preference cannot be ignored. My favorite language is APL, by the way.
A very idiomatic and stylistic tool. Now, if individual creativity is
the last thing that a company wants to see in a "coder" (not "programmer"),
then by all means take away the choice and give'm templates. Would you
work for them?
Let me ask you this: suppose a new bridge was going up in your city and the
civil engineer in charge of the project wanted to use beams with a cross
section like "|" instead of "I" because he hated the way I's look (his
personal preference). Would you drive over it?
A good engineer certainly has to be creative, but a good engineer doesn't
have to be an artist. In fact, there isn't much room for personal
preference in the face of "accepted engineering practice".
--
__________________________________________________________________________
Phillip J. Windley, Asst. Professor | ·······@cs.byu.edu
Laboratory for Applied Logic |
Dept. of Computer Science, TMCB 3370 |
Brigham Young University | Phone: 801.378.3722
Provo UT 84602-6576 | Fax: 801.378.7775
------------------------------------------------------------------------
If you use WWW, I'm <A HREF="http://lal.cs.byu.edu/people/windley/windley.html">here</A>.
From: William Chang in Marr Lab
Subject: Re: Personal Preference: The Devil in Disguise
Date:
Message-ID: <33gf58INN1iu@phage.cshl.org>
In article <·····················@jaguar.cs.byu.edu> ·······@cs.byu.edu (Phillip J. Windley) replies:
>A good engineer certainly has to be creative, but a good engineer doesn't
>have to be an artist. In fact, there isn't much room for personal
>preference in the face of "accepted engineering practice".
which shows he clearly missed my first sentence.
> On the contrary, my opinion is that programming is still an art...
Is programming already "accepted engineering practice"? What do people say?
-- Bill Chang (······@cshl.org)
In article <············@phage.cshl.org>, ······@phage.cshl.org
writes:
> Is programming already "accepted engineering practice"? What do
> people say?
A friend of mine described programming as removing the thought from a
task. From this point of view, programming will never be "accepted
engineering practice." There will only be yet more models of
abstraction from which to build yet more models of abstraction. (But
then again, I consider programming to be a very different thing than
"engineering" software.)
thant
In article <············@phage.cshl.org>
······@phage.cshl.org "William Chang in Marr Lab" writes:
> Is programming already "accepted engineering practice"? What do people say?
I missed some of this thread while away. Apologies if my comments repeat
anything.
Although software development continues to evolve in the right
direction, I don't think it has yet evolved to the mature state which is
required to be regarded as "accepted engineering practice".
Within each of the established engineering disciplines (civil,
mechanical, electrical etc) there is a very high degree of consensus on
a wide range of things including the following:
1) the basic metrics which allow:
- quantification of the requirements,
- orderly progress of the design,
- objective assesment of the product's conformance with the
requirement.
2) a definition of and method for computing reliability (the
availablility of reliability measures is central to the responsible
application of any technology in projects where safety is critical).
3) the graphical style of presenting design as engineering drawings.
It is not until software development has evolved a measure of consensus
on such crucial matters that its practices can claim to be "accepted".
regards
Dave Gray Nailsea Bristol UK 0275 857746
Bespoke Engineering & Technical Software ·····@davegray.demon.co.uk
[comp.lang.tcl removed from distribution at their request]
On Tue, 30 Aug 1994, David Gray wrote:
> In article <············@phage.cshl.org>
> ······@phage.cshl.org "William Chang in Marr Lab" writes:
>
> > Is programming already "accepted engineering practice"? What do people say?
> ....
> Within each of the established engineering disciplines (civil,
> mechanical, electrical etc) there is a very high degree of consensus on
> a wide range of things including the following:
>
> 1) the basic metrics which allow:
> - quantification of the requirements,
> - orderly progress of the design,
> - objective assesment of the product's conformance with the
> requirement.
In general, this assertion may be correct. However, at least in water
supply related civil engineering work, there is still a fair amount of
art (or intuition if you prefer) involved in the design work. In
particular, conformance with requirements is not in any sense a given.
Failure of the Teton dam in Idaho several years ago is an especially
glaring case in point, but I am also referring more broadly to any
predictions about the performance of reservoir systems in meeting water
supply requirements. The behavior of surface (not to mention ground) water
systems is not well enough understood to be subject to the same kind of
engineering rigor in design as, for example, a street or a building.
Sure, the structures themselves (dams, channels, etc.) are engineered
pretty rigorously, but the design of whole water supply systems cannot be.
This may seem to be off on a tangent, but the point is that not all that
is done within the engineering disciplines is strictly engineering. It
is probably foolish to assume that we can achieve complete rigor in software
engineering, and the (partial) reliance on individual expertise, experience
and "feel" in other disciplines should give us a hint.
> 2) a definition of and method for computing reliability (the
> availablility of reliability measures is central to the responsible
> application of any technology in projects where safety is critical).
Here I come back to the Teton dam example. My understanding of it is
that this failure was not predictable based solely on the design. It
occurred due to a combination of one design flaw with deviations from the
spec by contractors. Had the design and spec been followed, even though
it was flawed, the failure would probably not have occurred.
In software, you really need to get down to proving the correctness of
programs if you want rigor in reliability assessment.
In article <·····················@jaguar.cs.byu.edu>, ·······@cs.byu.edu (Phillip J. Windley) writes:
|>
|> In article <············@phage.cshl.org> ······@phage.cshl.org (William Chang in Marr Lab) writes:
|>
|> On the contrary, my opinion is that programming is still an art, so
|> concessions must be made to foster individual creativity. Hence, personal
|> preference cannot be ignored....
|>
|> Let me ask you this: suppose a new bridge was going up in your city and the
|> civil engineer in charge of the project wanted to use beams with a cross
|> section like "|" instead of "I" because he hated the way I's look (his
|> personal preference). Would you drive over it?
I can think of any number of such silly, contrived examples that
don't have anything to do with software. What's your point?
|> A good engineer certainly has to be creative, but a good engineer doesn't
|> have to be an artist. In fact, there isn't much room for personal
|> preference in the face of "accepted engineering practice".
Of course there is. Preference for certain tools, for example.
Accepted practice only defines the limits, not what goes on within
them. Sometimes those limits are tight, sometimes not. In the
software development arena, the limits defined by "accepted
engineering practice" are very loose to say the least.
From: Henry G. Baker
Subject: Re: Personal Preference: The Devil in Disguise
Date:
Message-ID: <hbakerCv4AL7.4My@netcom.com>
In article <··········@pulitzer.eng.sematech.org> ··········@sematech.org (Bill Gooch) writes:
>
>In article <·····················@jaguar.cs.byu.edu>, ·······@cs.byu.edu (Phillip J. Windley) writes:
>|>
>|> In article <············@phage.cshl.org> ······@phage.cshl.org (William Chang in Marr Lab) writes:
>|>
>|> On the contrary, my opinion is that programming is still an art, so
>|> concessions must be made to foster individual creativity. Hence, personal
>|> preference cannot be ignored....
>|>
>|> Let me ask you this: suppose a new bridge was going up in your city and the
>|> civil engineer in charge of the project wanted to use beams with a cross
>|> section like "|" instead of "I" because he hated the way I's look (his
>|> personal preference). Would you drive over it?
>
>I can think of any number of such silly, contrived examples that
>don't have anything to do with software. What's your point?
A famous airplane designer (perhaps Lockheed's Kelly Johnson ???) once
said that both turkeys and eagles fly, but he'd rather design eagles,
thank you very much.
The point being that one usually has enough flexibility to have both
performance and elegance, and one usually pays later, in spades, for
inelegance. ("Marry in haste; repent at leisure.)
In article <················@netcom.com>, ······@netcom.com (Henry G. Baker) writes:
|>
|> A famous airplane designer (perhaps Lockheed's Kelly Johnson ???) once
|> said that both turkeys and eagles fly, but he'd rather design eagles,
|> thank you very much.
Turkeys get a bum rap. Eagles are overrated.
From: Henry G. Baker
Subject: Re: Personal Preference: The Devil in Disguise
Date:
Message-ID: <hbakerCv9x6B.GsE@netcom.com>
In article <··········@pulitzer.eng.sematech.org> ······@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes:
>
>In article <················@netcom.com>, ······@netcom.com (Henry G. Baker) writes:
>|>
>|> A famous airplane designer (perhaps Lockheed's Kelly Johnson ???) once
>|> said that both turkeys and eagles fly, but he'd rather design eagles,
>|> thank you very much.
>
>Turkeys get a bum rap. Eagles are overrated.
Actually, turkeys _don't_ fly! I think the comment was 'both _vultures_ and
eagles fly...' Sorry about that!
In article <················@netcom.com> ······@netcom.com (Henry G. Baker) writes:
From: ······@netcom.com (Henry G. Baker)
>I can think of any number of such silly, contrived examples that
>don't have anything to do with software. What's your point?
A famous airplane designer (perhaps Lockheed's Kelly Johnson ???) once
said that both turkeys and eagles fly, but he'd rather design eagles,
thank you very much.
A famous airplane passenger once said that both turkeys and eagles
fly, but he'd rather the turkey for lunch, thank you very much.
The point being that one usually has enough flexibility to have both
performance and elegance, and one usually pays later, in spades, for
inelegance. ("Marry in haste; repent at leisure.)
My point is that the style and elegance of coding in software
engineering generally is not and generally should not be visible to
the end user. Of course, good design and implementational elegance
contribute to good software, but if things like indentation style or
the other silly aspects of coding style that are sometimes thrashed
here are visible to an end user, then heaven help your software --
it's in serious trouble.
There are exceptions in engineering, of course. The user's aesthetic
appreciation for the way small engineering details fit together to
contribute to the whole can indeed be an intended aspect of the
design. (Sports cars, fine Italian furnitue, and some kitchen gadgets
come to mind.) But it's rare for mere source code elegance to be
visible in a piece of completed software, just as it's rare that I
need to be reminded that my lunch once had feathers.
Phillip J. Windley (·······@cs.byu.edu) wrote:
:
: In article <············@phage.cshl.org> ······@phage.cshl.org (William Chang in Marr Lab) writes:
:
: >Do people really think that software development has become enough of an
: >engineering discipline -- that is, has reached levels of comparative
: >technical competence across *most* practitioners -- that 'preference' is a
: >valid argument?
:
: On the contrary, my opinion is that programming is still an art, so
: concessions must be made to foster individual creativity. Hence, personal
: preference cannot be ignored. My favorite language is APL, by the way.
: A very idiomatic and stylistic tool. Now, if individual creativity is
: the last thing that a company wants to see in a "coder" (not "programmer"),
: then by all means take away the choice and give'm templates. Would you
: work for them?
:
: Let me ask you this: suppose a new bridge was going up in your city and the
: civil engineer in charge of the project wanted to use beams with a cross
: section like "|" instead of "I" because he hated the way I's look (his
: personal preference). Would you drive over it?
:
Now you have taken a very bad example for your case. Do you know how many
different types of bridges exist ranging from small wooden bridges for people
to walk over to enourmous metal/concrete constructions taking entire highways.
You may not believe it but there seem to be many ways to build a 'good'
bridge. Of course there are some technical constraints, but the possible
variation between the constraints (type, form, material, ornaments, ...) is
so big, there always will be some personal taste in it (be it from the
producer/designer/architect/engeneer). The same applies to programming.
There are technical constraints, but a lot of things does depend on
personal (or corporate) choice.
Peter
·······@reks.uia.ac.be (Peter.DeRijk) writes:
>Phillip J. Windley (·······@cs.byu.edu) wrote:
>:
>: In article <············@phage.cshl.org> ······@phage.cshl.org (William Chang in Marr Lab) writes:
>:
>: Let me ask you this: suppose a new bridge was going up in your city and the
>: civil engineer in charge of the project wanted to use beams with a cross
>: section like "|" instead of "I" because he hated the way I's look (his
>: personal preference). Would you drive over it?
>:
>Now you have taken a very bad example for your case. Do you know how many
>different types of bridges exist ranging from small wooden bridges for people
>to walk over to enourmous metal/concrete constructions taking entire highways.
>You may not believe it but there seem to be many ways to build a 'good'
>bridge. Of course there are some technical constraints, but the possible
>variation between the constraints (type, form, material, ornaments, ...) is
>so big, there always will be some personal taste in it (be it from the
>producer/designer/architect/engeneer). The same applies to programming.
>There are technical constraints, but a lot of things does depend on
>personal (or corporate) choice.
>Peter
But you have to recognize that personal choice is a different thing than
taste or preference. Making a choice implies a reason behind making the
choice. Matters of preference or taste are -- by definition -- not
supportable. I submit that when you defend a course of action by claiming
'preference' that:
a) You don't understand you're preference well enough to be able
to justify it as a choice.
b) Your preference has no logical basis.
c) Your preference has a basis that is not pertinent to the
problem.
Preference indicates some big, amorphous blob of reasons that make you like
something better than something else. This is not engineering. If you
cannot logically justify a decision you either don't understand the decision,
the problem, or engineering.
--
--------------------------------------------------------------------------------
Jeff Kotula ······@camax.com
Camax Systems Inc. Speaking only for myself
-----------------------------------------------
In article <·····················@camax.com>, ······@camax.com (Jeff Kotula) writes:
|> ....
|> Preference indicates some big, amorphous blob of reasons that make you like
|> something better than something else. This is not engineering. If you
|> cannot logically justify a decision you either don't understand the decision,
|> the problem, or engineering.
You seem to be saying that there is no place for intuition in
engineering. I cannot agree. Logic is great, but it has been
proven to be limited. Intuition (that "amorphous blob") can
pick up where logic hits its limits. I have great respect for
someone who is brave enough, in software circles, to say "That
doesn't seem right to me. I don't know why, but I don't feel
good about it." I myself have quite a bit of difficulty doing
this, but I like having someone around who has good intuition
and trusts it enough to run with it.
As an aside, you have also apparently decided as a premise that
programming is strictly engineering. Part of the debate here
is whether programming is also, or completely, art. I think
it is some of both, and where you do which depends on what
aspects of your problem you are dealing with (user interface
tends to be largely art, based on some unprovable principles),
and to some extent on the nature of the problem itself.
······@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes:
>In article <·····················@camax.com>, ······@camax.com (Jeff Kotula) writes:
>|> ....
>|> Preference indicates some big, amorphous blob of reasons that make you like
>|> something better than something else. This is not engineering. If you
>|> cannot logically justify a decision you either don't understand the decision,
>|> the problem, or engineering.
>You seem to be saying that there is no place for intuition in
>engineering. I cannot agree. Logic is great, but it has been
>proven to be limited. Intuition (that "amorphous blob") can
>pick up where logic hits its limits. I have great respect for
>someone who is brave enough, in software circles, to say "That
>doesn't seem right to me. I don't know why, but I don't feel
>good about it." I myself have quite a bit of difficulty doing
>this, but I like having someone around who has good intuition
>and trusts it enough to run with it.
There is a threshold at which intuition becomes important. Usually however,
an intuition can be thought about for a while until the real issues reveal
themselves. I've found this to be universally true with my intuitions --
there is something solid there, you've just got to think about it for a bit.
That said, intuition is not a valid argument. Given a situation, you may
decide to go with an intuition because it simply doesn't pay to analyze
further. My problem is with using intuition as the first and sole
justification for decisions most of the time.
>As an aside, you have also apparently decided as a premise that
>programming is strictly engineering. Part of the debate here
>is whether programming is also, or completely, art. I think
>it is some of both, and where you do which depends on what
>aspects of your problem you are dealing with (user interface
>tends to be largely art, based on some unprovable principles),
>and to some extent on the nature of the problem itself.
The statement about user interface is absolutely false. The problem with
user interface design is that everybody thinks they are just as qualified to
do it as everybody else, but have no background in how to do it. They think
they are qualified just because they are a user. That's like saying since I
know how to drive a car, I can design an alternate steering mechanism. There
is a lot of science in user interface design that is usually just ignored.
On the "programming is art" idea I can only reiterate what I've said before:
calling programming art demeans art and provides a convenient excuse to
avoid doing the hardest parts of programming. A task that requires
creativity doesn't automatically become art. I've seen really good designs,
but they're not art -- they're just really good designs.
I know what I'm saying sounds harsh, and probably a little bit too absolute.
My point is to try to focus attention on why discussions involving
programming, design, etc. tend to stay so high-level and oftentimes lack
resolution. We, as an industry, have gotten in the habit of accepting
opinion and intuition as perfectly legitimate forms of argumentation. I
would just like to see us start getting more concrete, and not taking
"That's just my opinion" as the end of the discussion.
If we look into the reasons behind the opinions we are likely to learn a
great deal. People who have been doing this for a long time will have lots
of interesting opinions, but the bigger value is in why, with their
experience, they hold the opinions they do.
--
--------------------------------------------------------------------------------
Jeff Kotula ······@camax.com
Camax Systems Inc. Speaking only for myself
-----------------------------------------------
Lenny Gray (········@netcom.com) wrote:
: Jeff Kotula (······@camax.com) wrote:
: : ...
: : >|> Preference indicates some big, amorphous blob of reasons that make you
: : >|> like something better than something else. This is not engineering.
: : >|> If you cannot logically justify a decision you either don't understand
: : >|> the decision, the problem, or engineering.
: : >You seem to be saying that there is no place for intuition in
: : >engineering. I cannot agree. Logic is great, but it has been
: : >proven to be limited. Intuition (that "amorphous blob") can
: : >pick up where logic hits its limits.
: : > ...
: : There is a threshold at which intuition becomes important. Usually however,
: : an intuition can be thought about for a while until the real issues reveal
: : themselves. I've found this to be universally true with my intuitions --
: : there is something solid there, you've just got to think about it for a bit.
: IMHO, that threshold is _complexity_. To the extent that it is dealt
: with, appreciation of the complexity of _reality_ is what invokes said
: intuition. It is the limitation of an individual's _language_ (human)
: that lumps the multiplicites of logical evaluations of the moment into
: the _seemingly_ amorphous masses we label "intuition". In fact, there
: usually _is_ focus and logic in the expression of such "feelings" that
: _doesn't_ necessarily reduce to "something solid". Without knowing
: _all_ the internal calculations of another, the "logic" of his
: conclusions cannot necessarily be transmitted. In the shadow of
: possible failure in such an undertaking, some don't bother to try.
This thread started me thinking about where I have used intuition in
design decisions myself. More often than not, it happens when I am faced
with a choice between several implementation methods and don't know for
sure which is best. The advantages and disadvantages of each are usually
clear, what isn't clear is how much of an impact each advantage or
disadvantage will have on the project.
Suppose, for example, you are designing the schema for a database system.
You have a one-to-many relationship between a parent record and its children.
There is a monetary field in each child, and you know you will often need
the cumulative total of this field for all children belonging to the parent.
Do you keep a total field in the parent record, or do you recalculate the
total everytime you need it?
I'm sure everyone here can list the advantages and disadvantages
with each approach. But no one here could make a reasonable decision
as to which is the best approach, because that depends upon issues such
as how many child records we are likely to see, time-critical the
system is when we need the totals, how time-critical the system is when
we insert child records, how essential it is that the totals be exact,
and how likely it is that this section of the system is going to be
modified during future development.
Issues such as these are only completely answerable in hind-site. Before
the fact you can only guess. I find programmers use intuition, based
on a feel for the project and experience with similar projects to decide
issues such as these. Not because they don't know the pros and cons, but
because there is no way to be certain which of the pros and cons will most
impact the future of the project.
=====================================================================
On 30 Aug 1994, Jeff Dege wrote:
> Lenny Gray (········@netcom.com) wrote:
> : Jeff Kotula (······@camax.com) wrote:
> ....
Please be careful in editing attribution from previous posts. In
your post, there are three sets of comments and only two previous
posters included. The unattributed comments were mine. I would be
more concerned about having things mistakenly attributed to me, but
in any case it's best to be precise. Thanks.
······@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes:
>In article <······················@camax.com>, ······@camax.com (Jeff Kotula) writes:
>|> There is a threshold at which intuition becomes important. Usually however,
>|> an intuition can be thought about for a while until the real issues reveal
>|> themselves. I've found this to be universally true with my intuitions --
>I agree. However, if intuition is thought to be inadequate, there's
>a significant risk of never realizing you should do the analysis,
>because the reasons for doing it (and the "real issues") are fuzzy.
How so? If you don't trust intuition you're more likely to do further
analysis.
>|> there is something solid there, you've just got to think about it for a bit.
>|> That said, intuition is not a valid argument. Given a situation, you may
>I disagree - intuition is valid (at least that's how I feel). You
>continue by providing one of the reasons that it may be important.
The discussion about intution really is getting off of my main point. My
main point is that when you are discussing or arguing a position, on the net
or in technical discussions, using the argument of 'personal preference'
tends to shut down the discussion. In this context, personal preference
should be viewed with great skepticism and the real reasons (if there are
any) found.
>|> The statement about user interface is absolutely false. The problem with
>|> user interface design is that everybody thinks they are just as qualified to
>|> do it as everybody else, but have no background in how to do it. They think
>|> they are qualified just because they are a user. That's like saying since I
>|> know how to drive a car, I can design an alternate steering mechanism. There
>|> is a lot of science in user interface design that is usually just ignored.
>For example? I realize that scientific studies exist, but their
>results so far don't provide a strong, broad foundation for UI
>engineering. This may be simply because there hasn't been enough
>time devoted to the effort yet to cover most of the bases, or it
>may be something inherent in the nature of UI design. But until
>there are what appear to be sound engineering principles that can
>guide the less-experienced through the process of designing and
>implementing high-leverage, intuitive user interfaces for complex
>applications, the practice will continue to involve a lot of art.
Lots of literature, lots of experts in cognitive psychology and industrial
engineering. You can argue that it is a 'soft' science, but its no softer
than software engineering is at this point.
>|> On the "programming is art" idea I can only reiterate what I've said before:
>|> calling programming art demeans art and provides a convenient excuse to
>|> avoid doing the hardest parts of programming.
>Nothing about what I've said should lead you to believe that I'm
>interested in "an excuse to avoid doing the hardest parts of pro-
>gramming." I think that what you have said demeans programming and
>those who program artistically.
I wasn't referring to your posting in particular. When I've seen that
argument it is generally in the context of stating why requirements capture,
or design, or reviews and inspections are unimportant.
However, I do intend to demean those who program artistically. Software
development is not the place for personal expression or celebration of life
or exploring the interconnectedness of all things. Software is meant to get
the job done. If it cannot be understood -- easily -- by a maintainer, it
is junk, no matter how 'artistic' it is.
>I would point out, though, that I never said "programming is art"
>as a blanket statement, nor have I suggested that it is, or should
>be, primarily anything other than engineering.
>There seems to be a lot of feeling behind your comments - perhaps
>you have a war story you'd like to tell?
Most of my disgust comes from working with code that was done in a very lax,
unprofessional way. The attitude that produces this is only strengthened by
the 'art' argument. Hence my venom:)
>|> A task that requires
>|> creativity doesn't automatically become art. I've seen really good designs,
>|> but they're not art -- they're just really good designs.
>Quibbling over semantics.
That's what the discussion was about, so I don't see it as 'quibbling'.
--
--------------------------------------------------------------------------------
Jeff Kotula ······@camax.com
Camax Systems Inc. Speaking only for myself
-----------------------------------------------
[comp.lang.tcl removed from distribution at their request]
On Thu, 1 Sep 1994, Jeff Kotula wrote:
> ······@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes:
>
> >I agree. However, if intuition is thought to be inadequate, there's
> >a significant risk of never realizing you should do the analysis,
> >because the reasons for doing it (and the "real issues") are fuzzy.
>
> How so? If you don't trust intuition you're more likely to do further
> analysis.
Only if you trust it enough to follow it at all. If intuition is
dismissed outright, there may be no apparent justification for further
analysis, and you just "do what you know" at the time.
> The discussion about intution really is getting off of my main point. My
> main point is that when you are discussing or arguing a position, on the net
> or in technical discussions, using the argument of 'personal preference'
> tends to shut down the discussion. In this context, personal preference
> should be viewed with great skepticism and the real reasons (if there are
> any) found.
I agree.
> >|> The statement about user interface is absolutely false. The problem with
> >|> user interface design is that everybody thinks they are just as qualified to
> >|> do it as everybody else, but have no background in how to do it. They think
> >|> they are qualified just because they are a user. That's like saying since I
> >|> know how to drive a car, I can design an alternate steering mechanism. There
> >|> is a lot of science in user interface design that is usually just ignored.
>
> >For example? I realize that scientific studies exist, but their
> >results so far don't provide a strong, broad foundation for UI
> >engineering. This may be simply because there hasn't been enough
> >time devoted to the effort yet to cover most of the bases, or it
> >may be something inherent in the nature of UI design. But until
> >there are what appear to be sound engineering principles that can
> >guide the less-experienced through the process of designing and
> >implementing high-leverage, intuitive user interfaces for complex
> >applications, the practice will continue to involve a lot of art.
>
> Lots of literature, lots of experts in cognitive psychology and industrial
> engineering. You can argue that it is a 'soft' science, but its no softer
> than software engineering is at this point.
I'm fairly familiar with the literature, and I have been to CHI
conferences. The "science" that I've seen in this domain is highly
variable and does not IMHO cover the ground well, and a lot of the
technical sessions at such conferences have the flavor of war story
sessions ("well, I don't know, but here's what I did..."). That is
not to say that there isn't some very good work in the field, and I
especially don't want my friends to think I'm belittling their efforts!
Some people have done, and are doing, really good work, but there just
isn't enough coverage to provide a very solid foundation.
> >|> On the "programming is art" idea I can only reiterate what I've said before:
> >|> calling programming art demeans art and provides a convenient excuse to
> >|> avoid doing the hardest parts of programming.
>
> >Nothing about what I've said should lead you to believe that I'm
> >interested in "an excuse to avoid doing the hardest parts of pro-
> >gramming." I think that what you have said demeans programming and
> >those who program artistically.
>
> I wasn't referring to your posting in particular. When I've seen that
> argument it is generally in the context of stating why requirements capture,
> or design, or reviews and inspections are unimportant.
At least they're not saying that these activities are contra-indicated.
I would not agree with such statements, so I support your position
insofar as you're saying that laziness is not justified by the belief
that some aspects of programming are art. More like the opposite.
> However, I do intend to demean those who program artistically. Software
> development is not the place for personal expression or celebration of life
> or exploring the interconnectedness of all things. Software is meant to get
> the job done. If it cannot be understood -- easily -- by a maintainer, it
> is junk, no matter how 'artistic' it is.
I think you're mixing some things up here that should be considered
distinctly. Getting the job done and producing maintainable code need
not exclude the other possibilities. Part of the art of programming is
in writing code that is not only readable, but enjoyable and entertaining
to read (and perhaps in some way illuminates the interconnectedness of
all things (how *did* that sofa get there?)). I'm sure some will scoff at
this, but I think it's a worthwhile goal, though it isn't a high priority
in the context of doing real work. (This is by no means the main aspect
of art in programming.) Like a technical book that is both informative
and entertaining, it will be more readily understood than the dry, boring
equivalent.
From: ···@oblivion.utdallas.edu
Subject: Re: Personal Preference: The Devil in Disguise
Date:
Message-ID: <33i87t$ke@news.utdallas.edu>
Phillip J. Windley (·······@cs.byu.edu) writes:
>
> Let me ask you this: suppose a new bridge was going up in your city and the
> civil engineer in charge of the project wanted to use beams with a cross
> section like "|" instead of "I" because he hated the way I's look (his
> personal preference). Would you drive over it?
Time for this quote, taken from _Eiffel: The Language_:
Must it be assumed that because we are engineers beauty is not
our concern, and that while we make our constructions robust
and durable we do not also strive to make them elegant?
Is it not true that the genuine conditions of strength always
comply with the secret conditions of harmony?
The first principle of architectural esthetics is that the
essential lines of a monument must be determined by a perfect
adaptation to its purpose.
---Gustave Eiffel, 1887
From his response in the newspaper _Le Temps_ to a
petition by members of the literary and artistic
Establishment protesting his project of elevating a
tower of iron in Paris.
Like the engineer, the programmer's idea of beauty is not arbitrary.
---glv
···@oblivion.utdallas.edu writes:
>Phillip J. Windley (·······@cs.byu.edu) writes:
>>
>Time for this quote, taken from _Eiffel: The Language_:
[ stirring quote from Gustave Eiffel deleted ]
>Like the engineer, the programmer's idea of beauty is not arbitrary.
>---glv
This is true. But a statement of aesthetic beauty regarding a piece of
architecture has very little credence coming from someone who has no
background or deep understanding of it. Its the same with software
engineering. I don't believe that most people working in the field are at
that level of understanding, and as support for this statement I will simply
refer to the poor quality and late delivery of most software.
--
--------------------------------------------------------------------------------
Jeff Kotula ······@camax.com
Camax Systems Inc. Speaking only for myself
-----------------------------------------------
From: ···@oblivion.utdallas.edu
Subject: Re: Personal Preference: The Devil in Disguise
Date:
Message-ID: <33llkv$8te@news.utdallas.edu>
Jeff Kotula writes:
>
> ···@oblivion.utdallas.edu writes:
> >Like the engineer, the programmer's idea of beauty is not arbitrary.
>
> This is true. But a statement of aesthetic beauty regarding a piece of
> architecture has very little credence coming from someone who has no
> background or deep understanding of it. Its the same with software
> engineering. I don't believe that most people working in the field are at
> that level of understanding, and as support for this statement I will simply
> refer to the poor quality and late delivery of most software.
Here we agree. I was reacting against a statement that there was no
room for aesthetic preference in software engineering at all. But it
is certainly true that a *lot* of programmers like certain things
because "they're cool!" without really understanding their decisions ...
---glv
In article <·····················@camax.com> ······@camax.com (Jeff Kotula) writes:
···@oblivion.utdallas.edu writes:
>Phillip J. Windley (·······@cs.byu.edu) writes:
>>
>Time for this quote, taken from _Eiffel: The Language_:
[ stirring quote from Gustave Eiffel deleted ]
>Like the engineer, the programmer's idea of beauty is not arbitrary.
>---glv
This is true. But a statement of aesthetic beauty regarding a piece of
architecture has very little credence coming from someone who has no
background or deep understanding of it.
In other words, you have no sympathy for the commonplace "I don't
know anything about art, but I know what I like"?
Its the same with software
engineering. I don't believe that most people working in the field are at
that level of understanding, and as support for this statement I will simply
refer to the poor quality and late delivery of most software.
To echo another poster's response to this article, one key issue here
is whether software development is engineering or art (or at least
craft). I would contend that, unless you're working on writing the
world's fastest sort program, you're not engineering. I think that
the poor quality and late delivery of most software is due at least
in part to the refusal of many development organizations to recognize
this, and to insist that their developers work as if they were
engineers, and as if there were 'right' answers, when that's just not
true.
A second issue relates to the nature of software itself. There has
begun to be a movement (which I applaud) towards considering software
to be a form of communication, rather than merely a matter of writing
instructions for a computer to execute. Looked at in this way,
elegance -- and specifically elegance that can be appreciated by a
novice -- becomes a critical component of software development. Maybe
if programming were considered akin to expository writing, with the
same intent and the same criteria for quality, we'd be in better
shape.
Note that this does not mean that I feel that 'personal taste' should
be allowed to dominate either sound engineering considerations WHEN
APPROPRIATE, or to outweigh 'societal' taste. The choice of
programming language is a good example: while you might really prefer
the elegance and rhythm of classical Latin, you'll do a much better
job of communicating with most readers if you stick to English. Of
course, there is still a great deal of room for difference of
expression and dialect within English, and there personal taste
becomes important.
--
-----------------------------------------------------------------------------
Alan Geller phone: (908)699-8285
Bell Communications Research fax: (908)336-2953
444 Hoes Lane e-mail: ···@cc.bellcore.com
RRC 5G-110
Piscataway, NJ 08855-1342
[comp.lang.tcl removed from distribution at their request]
On 31 Aug 1994, 25381-geller wrote:
> In article <·····················@camax.com> ······@camax.com (Jeff Kotula) writes:
>
> Its the same with software
> engineering. I don't believe that most people working in the field are at
> that level of understanding, and as support for this statement I will simply
> refer to the poor quality and late delivery of most software.
>
> To echo another poster's response to this article, one key issue here
> is whether software development is engineering or art (or at least
> craft). I would contend that, unless you're working on writing the
> world's fastest sort program, you're not engineering. I think that
> the poor quality and late delivery of most software is due at least
> in part to the refusal of many development organizations to recognize
> this, and to insist that their developers work as if they were
> engineers, and as if there were 'right' answers, when that's just not
> true.
Amen to that. Oversimplification of the view of programming problems
(not solutions) contributes considerably to this.
I very much agree with the rest of your post, but I won't echo it here.
Thanks for the cogent comments.
In article <·················@xyzzy.gamekeeper.bellcore.com>,
25381-geller <···@xyzzy.gamekeeper.bellcore.com> wrote:
:In article <·····················@camax.com> ······@camax.com (Jeff Kotula) writes:
:
:
: Its the same with software
: engineering. I don't believe that most people working in the field are at
: that level of understanding, and as support for this statement I will simply
: refer to the poor quality and late delivery of most software.
:
:To echo another poster's response to this article, one key issue here
:is whether software development is engineering or art (or at least
:craft). I would contend that, unless you're working on writing the
I think that a distinction should be made that something need not be
engineering or art - or craft for that matter. A lot of programming
being done out in the world is quite simply just hacks. Stuff being done
without any more goal in mind than to get a job done and move on with life.
No planning, no intentional expression of one's inner thoughts and feelings,
no care being taken to follow the traditions. It's like taking out the
trash , doing the dishes, or sorting the laundry.
--
:s Great net resources sought...
:s Larry W. Virden INET: ·······@cas.org
:s <URL:http://www.mps.ohio-state.edu/cgi-bin/hpp?lvirden_sig.html>
The task of an educator should be to irrigate the desert not clear the forest.
In article <······················@camax.com>
······@camax.com "Jeff Kotula" writes:
>
> Do people really think that software development has become enough of an
> engineering discipline -- that is, has reached levels of comparative
> technical competence across *most* practitioners -- that 'preference' is a
> valid argument?
>
What the arguments often come down to are actually issues of the tradeoffs
that different tools (in this case languages) make. No tool is perfect for
every situation, so they all make different tradeoffs. The same happens in
all engineering disciplines, eg. cable-stayed bridges have different
tradeoffs to suspension bridges. I'm sure many civil engineers would say
they preferred one type of bridge or the other: what they're actually saying
is that they would prefer to work in the type of situation that calls for
one type of bridge. It's perfectly valid for engineers to have such
personal preferences, as long as these don't cause them to use inappropriate
tools through ignorance or prejudice.
That said, software development is still pretty lacking in objective
criteria for making choices between tools. It's still a very young
discipline.
Graham
--
Graham Oakes
······@oakridge.demon.co.uk
·······@aivis.demon.co.uk (John Styles) writes:
>My personal main bugbear of TCL is that, if I recall correctly,
>what we more mortals would code as a=b+c comes out as set a [expr $b+$c].
>This hardly strikes me as intuitive. Also there is the array syntax which
>escapes me for the moment.
Well, arrays seem to work OK for me, but I really find lists much easier
(if less efficient). But I totally agree that the inability to do simple
assignments without having to call "expr" is a pain. The more programming
I do in TCL, the less I like that aspect of things.
I also hate the fact that it is so easy to forget to put that damn "$" in
front of a variable when you want to take it's value. I almost wish it
were the other way around, like in C - variable name resolves to it's
value, and you need a "$" to refer to the variable's storage location.
However, both of these "problems" make it much easier to write a small and
efficient interpreter, so these might be reasonable tradeoffs.
>If it weren't so popular I'd guess it was some variety of practical joke.
Hardly. It *is* popular for a reason, it gets the job done with fewer
problems than other tools. I do almost all my scripting now in TCL, and
very little coding in C or sh (only use these for tools used outside my
area).
--
|+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| Michael J. Suzio ······@tiamat.umd.umich.edu |
| Marketing Director - Friday Knight Games |
| aka "That F*K*G company!" |
|+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
John Styles (·······@aivis.demon.co.uk) wrote:
: My personal main bugbear of TCL is that, if I recall correctly,
: what we more mortals would code as a=b+c comes out as set a [expr $b+$c].
: This hardly strikes me as intuitive. Also there is the array syntax which
I think this is a matter of consistancy. The parsing rules for Tcl are very
simple, and very consistent. What you define as 'mere mortals' are actually
'people who have coded a lot in other languages such as C'. (I have also
coded a lot in C, but I try to keep an open mind.) For non programmers the
a=b+c is also hard to grasp; what' this equation doing here.
Lets make a comparison of C and Tcl in several cases to show you what
I mean with consistancy:
I want to put '1' in variable a:
C:
int a;
a=1;
Tcl:
set a 1
I want to put 'Hello world' in variable a:
C:
char a[12];
strcpy(a,"Hello world");
Tcl:
set a "Hello world"
I want to put '<value of b> + <value of c>' in variable a:
C (of course 20 might not be enough, but to keep it simple):
char a[20];
int b,c;
b=23;
c=46456;
sprintf(a,"%d + %d",b,c);
Tcl:
set b 23
set c 46456
set a "$b + $c"
I want to put the result of <value of b> + <value of c> in variable a:
C:
int a,b,c
b=23;
c=45;
a=b+c;
Tcl:
set b 23
set c 45
set a [expr $b + $c]
: escapes me for the moment.
: If it weren't so popular I'd guess it was some variety of practical joke.
:
: --
: John Styles
I can't agree. Tcl is actually very nice to use.
Peter
Since we are at it... let's make some more noise.
In article <······················@reks.uia.ac.be> ·······@reks.uia.ac.be (Peter.DeRijk) writes:
From: ·······@reks.uia.ac.be (Peter.DeRijk)
Organization: U.I.A.
X-Newsreader: Tin 1.1 PL5
References: <············@aivis.demon.co.uk>
Date: Fri, 19 Aug 1994 09:56:16 GMT
Lines: 59
John Styles (·······@aivis.demon.co.uk) wrote:
: My personal main bugbear of TCL is that, if I recall correctly,
: what we more mortals would code as a=b+c comes out as set a [expr $b+$c].
: This hardly strikes me as intuitive. Also there is the array syntax which
I think this is a matter of consistancy. The parsing rules for Tcl are very
simple, and very consistent. What you define as 'mere mortals' are actually
'people who have coded a lot in other languages such as C'. (I have also
coded a lot in C, but I try to keep an open mind.) For non programmers the
a=b+c is also hard to grasp; what' this equation doing here.
Lets make a comparison of C and Tcl in several cases to show you what
I mean with consistancy:
I want to put '1' in variable a:
C:
int a;
a=1;
Tcl:
set a 1
Common Lisp:
(setf a 1)
I want to put 'Hello world' in variable a:
C:
char a[12];
strcpy(a,"Hello world");
Tcl:
set a "Hello world"
Common Lisp
(setf a "Hello world")
I want to put '<value of b> + <value of c>' in variable a:
C (of course 20 might not be enough, but to keep it simple):
char a[20];
int b,c;
b=23;
c=46456;
sprintf(a,"%d + %d",b,c);
Tcl:
set b 23
set c 46456
set a "$b + $c"
Common Lisp
(setf b 23)
(setf c 46453)
(setf a (format nil "~D + ~D" b c))
I want to put the result of <value of b> + <value of c> in variable a:
C:
int a,b,c
b=23;
c=45;
a=b+c;
Tcl:
set b 23
set c 45
set a [expr $b + $c]
Common Lisp
(setf b 23)
(setf c 46453)
(setf a (+ b c))
or
(setf a #$ b+c $)
Yes! Infix notation in Common Lisp!
I can't agree. Tcl is actually very nice to use.
I can't agree. Common Lisp is actually nice to use. :)
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
In article <·····················@mosaic.nyu.edu> ·······@mosaic.nyu.edu (Marco Antoniotti) writes:
>Since we are at it... let's make some more noise.
>In article <······················@reks.uia.ac.be> ·······@reks.uia.ac.be (Peter.DeRijk) writes:
> ... What you define as 'mere mortals' are actually
> 'people who have coded a lot in other languages such as C'. (I have also
> coded a lot in C, but I try to keep an open mind.) For non programmers the
> a=b+c is also hard to grasp; what' this equation doing here.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huhh ???
Mere mortals are people who happened to attend any school that managed
to teach them the basic algebra. For all those 99.99 % of population
the expression:
a = b + c
has a clear meaning, whereas:
set a 1
is something new.
However, programmers, who may account for some 0.01 % of Earth population
are a different breed. For them,
a = b + c may sound like "C" (rather than algebra)
A = B + C may sound like FORTRAN
SET A 1 may sound like COBOL
The problem with (many) programming languages is that they (for whetever
reson) depart from paradigms that most people have learned at school.
In some areas, it has clear advantages. In others, this conflict between
language syntax and "algebra syntax" (as hammered into our heads at
school) makes grasping such language "less intuitive", at least until
the hammered-in expectation of an "algebra syntax" is broken.
For people who are exposed to a multitude of programming languages, the
"algebra syntax" fixation is broken early in the process.
For others, such as engineers who "also learned to code", this will be
more difficult.
But on the original subject. Syntactical "cleanliness" and other "stuff"
are, in my experience, much less important than
- I can make it what I want
- I can make changes fast and see the result NOW
This is why so many people like "C" with all it's bizzaire quirks (they
can make it do whatever they want, good or bad),
and this is why people like Tcl (they can see their changes NOW).
After that, what is "better", "cleaner", "more consistent" etc. has
a very little value beyond estetics.
--
>>> Opinions presented above are solely of my own, not those of my employer <<<
Martin Brunecky ······@xvt.com (303)443-5130 ext 229 or 443-4223
In article <······················@xvt.com> ······@xvt.com (Martin Brunecky) writes:
|> For non programmers the
|> a=b+c is also hard to grasp; what' this equation doing here.
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Huhh ???
| Mere mortals are people who happened to attend any school that managed
| to teach them the basic algebra. For all those 99.99 % of population
| the expression:
| a = b + c
| has a clear meaning,
Yes, but unfortunately, that "clear meaning" doesn't correspond to the
actual meaning in most existing programming languages. Among other things,
people were taught in basic algebra that
a = b + c
and
b = a - c
are equivalent. Well, they aren't equivalent in programming.
| whereas:
| set a 1
| is something new.
Sounds good to me. A new concept should get a new notation. Note
that languages like Pascal chose quite deliberately to use different
notation. Their use of "=" is much closer to one of the mathematical
meanings.
Thomas.
In article <·················@arolla.idiap.ch>, ···@arolla.idiap.ch (Thomas M. Breuel) writes:
|> In article <······················@xvt.com> ······@xvt.com (Martin Brunecky) writes:
|> |> For non programmers the
|> |> a=b+c is also hard to grasp; what' this equation doing here.
|> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> | Huhh ???
|> | Mere mortals are people who happened to attend any school that managed
|> | to teach them the basic algebra. For all those 99.99 % of population
|> | the expression:
|> | a = b + c
|> | has a clear meaning,
|>
|> Yes, but unfortunately, that "clear meaning" doesn't correspond to the
|> actual meaning in most existing programming languages.
Exactly, and everybody who learned programming _after_ having algebra
should have experienced this. The best example here is that
a = a + 5
makes no sense in algebra (at least if we speak in terms of classic
numerics), but makes perfect sense in programming. The difference is
that algebra speaks about a number of rules, whereas programming about
a sequential list of steps to be performed (well, there are different
languages ;)
--
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) ··········@IRS.Inf.TU-Dresden.de | o |
+-o-+--------------------------------------------------------+-o-+
--
Geoff. Lane. | Internet: ·······@cs6400.mcc.ac.uk | Janet: ·······@uk.ac.mcc
CS6400 Sys Admin, Manchester Computing Centre, Oxford Rd, Manchester, M13 9PL
On a clear disk you can seek forever. -- Denning
In article <·················@arolla.idiap.ch>,
Thomas M. Breuel <···@idiap.ch> wrote:
>In article <······················@xvt.com> ······@xvt.com (Martin Brunecky) writes:
>|> For non programmers the
>|> a=b+c is also hard to grasp; what' this equation doing here.
>| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>| Huhh ???
>| Mere mortals are people who happened to attend any school that managed
>| to teach them the basic algebra. For all those 99.99 % of population
>| the expression:
>| a = b + c
>| has a clear meaning,
>
>Yes, but unfortunately, that "clear meaning" doesn't correspond to the
>actual meaning in most existing programming languages. Among other things,
>people were taught in basic algebra that
>
> a = b + c
>
>and
>
> b = a - c
>
>are equivalent. Well, they aren't equivalent in programming.
>
>| whereas:
>| set a 1
>| is something new.
>
>Sounds good to me. A new concept should get a new notation. Note
>that languages like Pascal chose quite deliberately to use different
>notation. Their use of "=" is much closer to one of the mathematical
>meanings.
>
The problem lies in the limited character set available on computers,
particularly in the "early" days. When Backus invented FORTRAN in the
early 1950s, the punched card character set included the letters,
digits, space, and a few special characters: + - * / ( ) $ = . , '
(Note: This was what was called the BCD `H' set. There were others.)
He chose to use the = symbol for left assignment. Many successor
languages followed suit. Others chose to use combinations of
characters, and expanded into the expanded ASCII set of 64 graphics
found on Model 33 Teletype machines as terminals became available. One
programming language, NELIAC (based on Algol 58), chose to go with a
custom character set. It was initially built on a special purpose
Flexowriter terminal. NELIAC included a right-pointing arrow character
for assignments. If we represent that single character by -> we could
write statements like:
A + B -> C;
When Control Data first brought out 64-character printers, they used a
slight variation of the NELIAC character set. Later, when ASCII
graphics caught on as the standard, they switched.
Other languages have also used right assignment. In COBOL, for
example, you can write:
ADD A, B GIVING C.
The important thing in helping people understand a program is to help
them understand that the symbols used in writing the program have their
own special meanings for that programming language. If the designers of
that language didn't use another language's convention, the meaning
cannot match.
--
Michael D. Shapiro, Ph.D. Internet: ········@nosc.mil
Code 4123, NCCOSC RDT&E Division (NRaD) San Diego CA 92152
Voice: (619) 553-4080 FAX: (619) 553-4808 DSN: 553-4080
(Organization name changed from NOSC in January 1992.)
In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
|> In article <·····················@mosaic.nyu.edu>,
|> Marco Antoniotti <·······@mosaic.nyu.edu> wrote:
|> > (setf a (+ b c))
|> > or
|> > (setf a #$ b+c $)
|> > Yes! Infix notation in Common Lisp!
|>
|> Ick. Give me (+ b c) any day. Bring back Lisp 1.5!
Anyone mentioned
/a b c add def
already ? I like stack languages, esp. PostScript ;)
--
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) ··········@IRS.Inf.TU-Dresden.de | o |
+-o-+--------------------------------------------------------+-o-+
In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
> In article <·····················@mosaic.nyu.edu>,
> Marco Antoniotti <·······@mosaic.nyu.edu> wrote:
> > (setf a (+ b c))
> > or
> > (setf a #$ b+c $)
> > Yes! Infix notation in Common Lisp!
>
> Ick. Give me (+ b c) any day. Bring back Lisp 1.5!
No prob. If you don't like it, do not load infix.lisp, and
you still have #$ free for some other use.
What's even better, you do not even have to bother about FTPing it! :-)
--
F.D. Mato Mira
Computer Graphics Lab ········@epfl.ch
EPFL FAX: +41 (21) 693-5328
From: Peter da Silva
Subject: Re: Why is TCL successful ?
Date:
Message-ID: <id.6KEC1.M26@nmti.com>
In article <··········@disuns2.epfl.ch>,
Fernando Mato Mira <········@di.epfl.ch> wrote:
> In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
> > In article <·····················@mosaic.nyu.edu>,
> > Marco Antoniotti <·······@mosaic.nyu.edu> wrote:
> > > (setf a (+ b c))
> > > or
> > > (setf a #$ b+c $)
> > > Yes! Infix notation in Common Lisp!
> > Ick. Give me (+ b c) any day. Bring back Lisp 1.5!
> No prob. If you don't like it, do not load infix.lisp, and
> you still have #$ free for some other use.
I don't want #$ free for other use.
I don't want macros.
I don't want the mechanism that *lets* you implement #$ in the language.
Sometimes smaller *is* better.
(really. I almost want to crosspost to comp.lang.dysfunctional)
--
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?"
In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
> I don't want macros.
Bad choice.
Have you read :
On Lisp - Advanced Techniques for Common Lisp
Paul Graham
Prentice Hall
ISBN 0-13-030552-9
?
--
F.D. Mato Mira
Computer Graphics Lab ········@epfl.ch
EPFL FAX: +41 (21) 693-5328
From: Peter da Silva
Subject: Re: Why is TCL successful ?
Date:
Message-ID: <id.U4GC1.A_H@nmti.com>
In article <··········@disuns2.epfl.ch>,
Fernando Mato Mira <········@di.epfl.ch> wrote:
> In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
> > I don't want macros.
> Bad choice.
What, because I don't want a piece of syntactic sugar some college kid
thought would be neat and laid down on top of what was originally a
language with a very simple and clean syntax...
> Have you read :
> On Lisp - Advanced Techniques for Common Lisp
Nope. Never even cracked it. If it's like other "advanced techniques" books
I've seen it's probably a great way to learn how to create write-only code.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"
Peter da Silva <·····@nmti.com> wrote:
> I don't want macros.
Fernando Mato Mira <········@di.epfl.ch> wrote:
> Bad choice.
PdS:
> What, because I don't want a piece of syntactic sugar some college
> kid thought would be neat and laid down on top of what was
> originally a language with a very simple and clean syntax...
I used to have this opinion. However, when your macro system hooks
into the language itself (which in my case is Scheme), you can use it
not just to change the syntax of the language, but to add new
semantics. You build your own language based on the kinds of ideas
you want to express. In fact, when I write macros, I put considerable
effort into making sure I change the *syntax* of Scheme as little as
possible.
Macros (at least in Scheme) are a very good thing.
thant
In article <············@nmti.com> ·····@nmti.com (Peter da Silva) writes:
>Fernando Mato Mira <········@di.epfl.ch> wrote:
>> In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
>> > I don't want macros.
>> Bad choice.
>
>What, because I don't want a piece of syntactic sugar some college kid
>thought would be neat and laid down on top of what was originally a
>language with a very simple and clean syntax...
While I sympathize with the reaction against creeping featuritis, I
would not choose macros as the thing to eliminate. Most people I know
don't write very many macros, but almost every 'real' Common Lisp project
I've seen includes a few that people couldn't live without. Perhaps my
experience isn't representative.
Also, not all uses of macros are complicated. For instance, suppose
you want an operator that looks and works *exactly* like DEFUN, except
that it does one extra bit of processing (ie export the function name,
or (in my case) memoize it). A trivial macro makes something that
looks and works precisely like DEFUN: the user's don't have to be told
anything new about how to use it.
Similarly, you want to make a variation of DEFCLASS that, say,
automatically includes some project-specific superclass. This lets
debuggers and maintainers write routines that specialize on this
class (instead of STANDARD-CLASS), so their methods don't get invoked
on internal system objects such as CLIM objects. This is also a very
simple and easy to read macro.
One we just wrote here, also trivial, times a form. The builtin TIME,
on Lucid on SPARCs, is not very useful for timing very small fast
functions, since its clock only ticks in increments of 0.01 seconds.
You don't want to put the form in a loop, since then you are including
the looping overhead in your timing. But a simple and easy to understand
macro lets you type (Time-Form <Lisp-Form> <N>), which will run the Form
N times consecutively, then average the time and report it to you.
Another simple one is WITH-METERING. It just executes a body of code,
but it turns on the Lucid profiling system first, turns it off after,
and generates a breakdown of time spent in various functions. Sure, we
could just tell our users "To meter a function, type XXX, then type YYY,
then execute your form, then type ZZZ". Sure, all this does is save them
some typing and remembering. But it is useful, IMHO.
>Nope. Never even cracked it. [Graham's _On Lisp. Advanced Techniques in
> Common Lisp] If it's like other "advanced techniques" books
>I've seen it's probably a great way to learn how to create write-only code.
I agree that some macros are indeed very complicated and hard to understand.
And people do, in my experience, sometimes use macros when there are simpler
and clearer alternatives.
But don't you think that there are *some* hard problems for which there is
no simple solution? Shouldn't a language not only support the tools for
nice, clean, elegant solutions to basic problems as well as tools that
will let you solve complicated, messy problems? For instance, Graham's
book talks about solving variable capture problems. In X, how many times
have you seen someone do
Arg args[N]
int num_args = 0;
...
XtSetArg(args[num_args++], XtNlabel, "Title");
and then get bit by the variable capture bug? They should have done
XtSetArg(args[num_args], XtNlabel, "Title"); num_args++
because XtSetArg evaluates that argument more than once.
Now, there are not too many problems that really need a macro (not just an
inline function) that suffer from this problem. But there are some, IMHO,
and people who write large complicated applications in Lisp would like to
have a way to solve them. I know I do.
Just my experience working on large, complicated Lisp projects in industry.
Your mileage may vary. Cheers-
- Marty
(proclaim '(inline skates))
In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
|> In article <··········@disuns2.epfl.ch>,
|> Fernando Mato Mira <········@di.epfl.ch> wrote:
|> > In article <············@nmti.com>, ·····@nmti.com (Peter da Silva) writes:
|> > > I don't want macros.
|>
|> > Bad choice.
|>
|> What, because I don't want a piece of syntactic sugar some college kid
|> thought would be neat and laid down on top of what was originally a
|> language with a very simple and clean syntax...
It's a lot more than "syntactic sugar." One of the most
important uses I have found for macros in Lisp is to create
new defining forms. Another is to build reusable abstractions
in cases where performance is critical. In either of these
situations, serious readbility/maintainability problems can
arise when macros are taken away.
From: ·····@nmti.com (Peter da Silva)
In article <·····················@mosaic.nyu.edu>,
Marco Antoniotti <·······@mosaic.nyu.edu> wrote:
> (setf a (+ b c))
> or
> (setf a #$ b+c $)
> Yes! Infix notation in Common Lisp!
Ick. Give me (+ b c) any day. Bring back Lisp 1.5!
--
Peter da Silva `-_-'
Actually I was wrong. I hadn't downloaded the latest version. The
implementation I was using, does not work in MCL because that
implementation uses #\$ for something else.
The example should now be written as
(setf a #I(b+c))
or
(setf a #I(a + b*sin(x)^^2)/(2^^x + k))
It is interesting to recall why this package exists. About a year ago
another flame Lisp-vs-C was on. One of the *main* issues there was
syntax. Mark Kantrowitz (praised be his name and parenthesis), stopped
any extra flames by writing up the package. So here it is. You can
write infix arithmetic in Common Lisp.
Happy Lisping
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
In article <·····················@mosaic.nyu.edu> ·······@mosaic.nyu.edu (Marco Antoniotti) writes:
From: ·······@mosaic.nyu.edu (Marco Antoniotti)
Date: 24 Aug 1994 14:36:26 GMT
References: <············@aivis.demon.co.uk> <······················@reks.uia.ac.be>
<·····················@mosaic.nyu.edu> <············@nmti.com>
Xref: ai-lab comp.lang.functional:3551 comp.lang.lisp:7471 comp.lang.misc:7387 comp.lang.tcl:17251 comp.software-eng:16456
From: ·····@nmti.com (Peter da Silva)
In article <·····················@mosaic.nyu.edu>,
Marco Antoniotti <·······@mosaic.nyu.edu> wrote:
> (setf a (+ b c))
> or
> (setf a #$ b+c $)
> Yes! Infix notation in Common Lisp!
Ick. Give me (+ b c) any day. Bring back Lisp 1.5!
--
Peter da Silva `-_-'
Actually I was wrong. I hadn't downloaded the latest version. The
implementation I was using, does not work in MCL because that
implementation uses #\$ for something else.
The example should now be written as
(setf a #I(b+c))
or
(setf a #I(a + b*sin(x)^^2)/(2^^x + k))
It is interesting to recall why this package exists. About a year ago
another flame Lisp-vs-C was on. One of the *main* issues there was
syntax. Mark Kantrowitz (praised be his name and parenthesis), stopped
any extra flames by writing up the package. So here it is. You can
write infix arithmetic in Common Lisp.
Those interested in infix parsers for Lisp may want to have a look at
Vaughan Pratt's early work on CGOL, and his paper on top-down operator
precedence parsers (you can find the reference in the Aho, Sethi,
Ullman dragon book).
Such a parser is used in the Macsyma computer algebra system, and of
course there is a read-macro that allows your to enter Macsyma code in
Lisp via #$ .... $ as above.
* Trevor Blackwell wrote:
> There's something about languages with overly complex syntax and
> crufty semantic foundations that makes them popular. I wish I
> understood it.
I think that it's because natural languages are like this too (well,
they have complex syntax and semantics, perhaps not overly complex).
This however doesn't explain why only *some* people like these
programming languages.
--tim
I think it is quite simple. People who have trouble with abstract
concepts (like me), prefer languages with the minimum number of
new concepts over those they know from natural language. I am quite
happy to read something that is a few characters longer if it looks
more like something that I already know (English). Consider what is
required to understand:
(cond (< (+ a b) 5)
(setq a 1)
(setq b 1)
)
versus:
if a + b < 5 then
a <- 1;
else
a <- 2;
endif;
This principle works for Cobol, but that language (IMHO) violates
the same principle in another way, by having far too many words
with differing meanings.
--
Chris Gray ··@myrias.ab.ca [C macros - a powerful way to make bugs!]
Myrias Computer Technologies Inc. (403) 463-1337
In article <···············@myrias.ab.ca> ··@myrias.ab.ca (Chris Gray) writes:
;; I think it is quite simple. People who have trouble with abstract
;; concepts (like me), prefer languages with the minimum number of
;; new concepts over those they know from natural language. I am quite
;; happy to read something that is a few characters longer if it looks
;; more like something that I already know (English). Consider what is
;; required to understand:
;;
;; (cond (< (+ a b) 5)
;; (setq a 1)
;; (setq b 1)
;; )
;;
;; versus:
;;
;; if a + b < 5 then
;; a <- 1;
;; else
;; a <- 2;
;; endif;
FYI: The above attempt at Lisp code is incorrect. Also note how Emacs
re-indents the code automatically, making a suspicious-looking piece of
code:
(cond (< (+ a b) 5)
(setq a 1)
(setq b 1) )
It is syntactically incorrect (cond is a macro) and gives "void
variable: <". You probably intended something like:
(cond ((< (+ a b) 5)
(setq a 1))
(t
(setq b 2))))
which is a lot more readable too, IMHO.
;; This principle works for Cobol, but that language (IMHO) violates
;; the same principle in another way, by having far too many words
;; with differing meanings.
What principle?
... my stuff deleted again ...
;; (cond (< (+ a b) 5)
;; (setq a 1)
;; (setq b 1)
;; )
;;
;; versus:
;;
;; if a + b < 5 then
;; a <- 1;
;; else
;; a <- 2;
;; endif;
FYI: The above attempt at Lisp code is incorrect. Also note how Emacs
re-indents the code automatically, making a suspicious-looking piece of
code:
(cond (< (+ a b) 5)
(setq a 1)
(setq b 1) )
It is syntactically incorrect (cond is a macro) and gives "void
variable: <". You probably intended something like:
(cond ((< (+ a b) 5)
(setq a 1))
(t
(setq b 2))))
which is a lot more readable too, IMHO.
Sorry, its been 15 years since I programmed in LISP.
;; This principle works for Cobol, but that language (IMHO) violates
;; the same principle in another way, by having far too many words
;; with differing meanings.
What principle?
The principle of a programming language being mostly readable by
a reader not familiar with it. Programming is a difficult enough
job as it is - why make it harder by using languages that are hard
to read?
Note that I am not an academic - I program for a living and as a
hobby sometimes. I am much more concerned with code readability and
maintainability then I am with how quickly something can be hacked
together using some language's "neato keen" tools and features.
Here's kind of a twisted example, but heck, maybe someone out there
can help me with it. I've written a MUD system at home (if you don't
know what a MUD is, just ignore this), and one day I thought it would
be K00L to put a variant of "Eliza" or "Doctor" into it. I think all
the needed facilities are there. So, I grabbed the only version I
had around - that for GNU-Emacs ELisp. I have yet to be able to
figure out just what it does. This is precisely what I mean - if I
can ever convert it to my MUD system (a language along the lines of
the first one above), I would hope that it would be much more
readable. Anyone got a version that I can understand?
--
Chris Gray ··@myrias.ab.ca [C macros - a powerful way to make bugs!]
Myrias Computer Technologies Inc. (403) 463-1337
Chris Gray (··@myrias.ab.ca) wrote:
: ;; if a + b < 5 then
: ;; a <- 1;
: ;; else
: ;; a <- 2;
: ;; endif;
: (cond ((< (+ a b) 5)
: (setq a 1))
: (t
: (setq b 2))))
: which is a lot more readable too, IMHO.
Of course.
: The principle of a programming language being mostly readable by
: a reader not familiar with it. Programming is a difficult enough
: job as it is - why make it harder by using languages that are hard
: to read?
I look forward to the day when introductory textbooks explain
"The 'if <condition> then expression_1 else expression_2 endif' statment
is the computer langauge's obscure version of what we humans all know
as '(cond ((conditional_expression) (expression1)) (t (expression2))))'"
: Chris Gray ··@myrias.ab.ca [C macros - a powerful way to make bugs!]
: Myrias Computer Technologies Inc. (403) 463-1337
--
-Matt Kennel ···@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-*** lyapunov.ucsd.edu, username "anonymous".
PS: "He used *sarcasm*".
[Chris Gray]
| Sorry, its been 15 years since I programmed in LISP.
that may explain why you didn't do this:
(if (< (+ a b) 5)
(setq a 1)
(setq b 1))
but even this is not the best use of LISP. different languages, different
concepts, and different expressability. if you try to write FORTRAN in
LISP, it will look less pretty than FORTRAN, and FORTRAN will "win", but
try to write LISP in FORTRAN, instead.
| The principle of a programming language being mostly readable by a
| reader not familiar with it. Programming is a difficult enough job as
| it is - why make it harder by using languages that are hard to read?
why do you want to optimize for irrelevant people? "a reader not familiar
with" a programming language is either not someone you want to read your
code, or he will become familiar with it shortly if he isn't. programmers
have to be able to express themselves in a language, and that is more than
just "familiarity". readability is a factor of many things, but common to
all is familiarity.
| Here's kind of a twisted example, but heck, maybe someone out there can
| help me with it. I've written a MUD system at home (if you don't know
| what a MUD is, just ignore this), and one day I thought it would be
| K00L to put a variant of "Eliza" or "Doctor" into it. I think all the
| needed facilities are there. So, I grabbed the only version I had
| around - that for GNU-Emacs ELisp. I have yet to be able to figure out
| just what it does. This is precisely what I mean - if I can ever
| convert it to my MUD system (a language along the lines of the first
| one above), I would hope that it would be much more readable. Anyone
| got a version that I can understand?
it's a twisted example, all right. with languages come concepts, and if
you don't know the concepts, no amount of readability will help. the
belief that one can "read" simple code (e.g., C) because the operations are
simple is erroneous. you need to understand _why_ something is done, not
just _what_ it does. you reimplement the _why_, not the _what_, anyway.
</Erik>
--
Microsoft is not the answer. Microsoft is the question. NO is the answer.
In article <···················@bingen.hrp.no> ······@hrp.no (Eyvind Ness) writes:
>In article <···············@myrias.ab.ca> ··@myrias.ab.ca (Chris Gray) writes:
>
> ;; I think it is quite simple. People who have trouble with abstract
> ;; concepts (like me), prefer languages with the minimum number of
> ;; new concepts over those they know from natural language. I am quite
> ;; happy to read something that is a few characters longer if it looks
> ;; more like something that I already know (English). Consider what is
> ;; required to understand:
> ;;
> ;; (cond (< (+ a b) 5)
> ;; (setq a 1)
> ;; (setq b 1)
> ;; )
> ;;
> ;; versus:
> ;;
> ;; if a + b < 5 then
> ;; a <- 1;
> ;; else
> ;; a <- 2;
> ;; endif;
>
>FYI: The above attempt at Lisp code is incorrect.
Anyway, COND must be just about the least readable part of Lisp.
It's not too bad once you're used to it, but COND alone does not
a fair comparison make. It's kind of like comparing Lisp and C
by comparing (if test then-part else-part) with test ? then-part :
else-part.
The usual answer for COND is "if you don't like COND, you can define
an macro", but maybe that's not fair either. After all, COND is in
the standard language, while this macro isn't, and having everyone
write their own macro isn't a very good solution. But, on the other
hand, Common Lisp isn't all there is to Lisp. In Franz Lisp, you
could write
(if (< (+ a b) 5) then
(setq a 1)
else
(setq a 2)
)
In article <·········@cogsci.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
> Anyway, COND must be just about the least readable part of Lisp.
> It's not too bad once you're used to it, but COND alone does not
> a fair comparison make. It's kind of like comparing Lisp and C
> by comparing (if test then-part else-part) with test ? then-part :
> else-part.
> The usual answer for COND is "if you don't like COND, you can define
> an macro", but maybe that's not fair either. After all, COND is in
> the standard language, while this macro isn't, and having everyone
> write their own macro isn't a very good solution. But, on the other
> hand, Common Lisp isn't all there is to Lisp. In Franz Lisp, you
> could write
> (if (< (+ a b) 5) then
> (setq a 1)
> else
> (setq a 2)
> )
And in Common Lisp you can write,
(if (< (+ a b) 5)
(setq a 1)
(setq a 2))
or better yet for the "paper-saving" lispers among us,
(setq a (if (< (+ a b) 5) 1 2))
rodrigo vanegas
··@cs.brown.edu
In article <·········@cogsci.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
...
|> Anyway, COND must be just about the least readable part of Lisp.
|> It's not too bad once you're used to it, but COND alone does not
|> a fair comparison make. It's kind of like comparing Lisp and C
|> by comparing (if test then-part else-part) with test ? then-part :
|> else-part.
|>
|> The usual answer for COND is "if you don't like COND, you can define
|> an macro", but maybe that's not fair either. After all, COND is in
|> the standard language, while this macro isn't, and having everyone
|> write their own macro isn't a very good solution.
Actually, in Common Lisp, IF is the primitive special form, and
COND is a system-defined macro that presumably expands into an
expression using IF.
--
James McDonald
Kestrel Institute ········@kestrel.edu
3260 Hillview Ave. (415) 493-6871 ext. 339
Palo Alto, CA 94304 fax: (415) 424-1807
In article <······················@kestrel.edu> ········@kestrel.edu (Jim McDonald) writes:
>
>In article <·········@cogsci.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>...
>
>|> Anyway, COND must be just about the least readable part of Lisp.
>|> It's not too bad once you're used to it, but COND alone does not
>|> a fair comparison make. It's kind of like comparing Lisp and C
>|> by comparing (if test then-part else-part) with test ? then-part :
>|> else-part.
>|>
>|> The usual answer for COND is "if you don't like COND, you can define
>|> an macro", but maybe that's not fair either. After all, COND is in
>|> the standard language, while this macro isn't, and having everyone
>|> write their own macro isn't a very good solution.
>
>Actually, in Common Lisp, IF is the primitive special form, and
>COND is a system-defined macro that presumably expands into an
>expression using IF.
Sure, but that's not inconsistent with what I said. COND is (almost
always) built-in while (if ... then ... else ...) isn't.
··@myrias.ab.ca (Chris Gray) writes:
> * Trevor Blackwell wrote:
> > There's something about languages with overly complex syntax and
> > crufty semantic foundations that makes them popular. I wish I
> > understood it.
> I think that it's because natural languages are like this too (well,
> they have complex syntax and semantics, perhaps not overly complex).
> This however doesn't explain why only *some* people like these
> programming languages.
> --tim
>I think it is quite simple. People who have trouble with abstract
>concepts (like me), prefer languages with the minimum number of
>new concepts over those they know from natural language. I am quite
>happy to read something that is a few characters longer if it looks
>more like something that I already know (English). Consider what is
>required to understand:
> (cond (< (+ a b) 5)
> (setq a 1)
> (setq b 1)
> )
>versus:
> if a + b < 5 then
> a <- 1;
> else
> a <- 2;
> endif;
Well, I think the latter is easier to understand for most people
mainly because most computer languages are structured like the latter.
By the way, I don't think buy the argument that a language that is
hard to understand for someone who hasn't learnt it, is therefore bad.
If you followed this then I'd say COBOL would be the king of all
languages because lot's of it can be understood by managers etc.
Look at pointers in C. They are very hard to understand for a
beginner, but C has become very popular, even as a first programing
language.
> Look at pointers in C. They are very hard to understand for a
> beginner, but C has become very popular, even as a first programing
> language.
Ah, but in my experience the feature most often used incorrectly is said
feature of pointers! I have had folk who have written code for 10 years (!)
who come by with simple pointer questions, and when I explain it, say
'I have always wondered how that worked' or 'I have been doing that wrong
for all these years' - a scary thought indeed!
--
:s Great net resources sought...
:s Larry W. Virden INET: ·······@cas.org
:s Personal: 674 Falls Place, Reynoldsburg, OH 43068-1614
The task of an educator should be to irrigate the desert not clear the forest.
·····@chemabs.uucp (Larry W. Virden) wrote:
// > Look at pointers in C. They are very hard to understand for a
// > beginner, but C has become very popular, even as a first programing
// > language.
//
// Ah, but in my experience the feature most often used incorrectly is
// said feature of pointers! I have had folk who have written code for
// 10 years (!) who come by with simple pointer questions, and when I
// explain it, say 'I have always wondered how that worked' or 'I have
// been doing that wrong for all these years' - a scary thought indeed!
One man's opinion: C's popularity is due to economic
forces *at least* as much as to any of its inherent
strengths. On this topic, I'd go as far as to say that
unrestricted pointers are really the data structure equivalent
of GOTOs (and C is the contemporary equivalent of old BASIC).
I'm not saying that "pointers" sould be eliminated,
but, just as WHILE and REPEAT loops can be thought of as
controlled GOTO intructions, pointers should be controlled
addresses. I think Pascal, for example, does a good job of
this.
"GOTOs and addresses belong in assembly code," he said
as he climbed into his asbestos suit . . . :-)
--
Theatre is life. Film is art. Television is furniture.
In article <················@chardonnay.harvard.edu> ···@chardonnay.harvard.edu (Trevor Blackwell) writes:
|Maybe part of the reason for the success of TCL and C++ is this. Lisp
|& Smalltalk & ML & your favourite language all provide a number of
|simple primitives, which you connect together to form an
|application. The primitives themselves are a bit abstract, so it takes
|some creativity to apply them in order to reach your goal. With some
|experience, though, cranking out common program structures becomes
|automatic.
I don't lack the creativity. But I do lack the time. Trying to work
around a lack of numerical libraries, string libraries, and graphics
and GUI libraries requires a _lot_ of time and effort. Likewise,
trying to get some complicated algorithm to run fast and use little
space can be much harder in Lisp or Smalltalk than in C, even if a
simple implementation of the algorithm would be easier in those
languages.
Thomas.
···@arolla.idiap.ch (Thomas M. Breuel) writes:
>I don't lack the creativity. But I do lack the time. Trying to work
>around a lack of numerical libraries, string libraries, and graphics
>and GUI libraries requires a _lot_ of time and effort.
This is true. Haskell's standard prelude goes some very small way
towards addressing this, but you invariably end up having to use custom
libraries and compiler features to get half-decent performance (string
manipulation is horribly inefficient in standard Haskell, but a *lot*
faster and more space-efficient if you use the Glasgow Haskell packed
string extensions).
In the Scheme world, SLIB does a nice job of giving you lots of useful
library features, and does it quite portably too. Common Lisp
programmers get an even larger kitchen sink with their systems, so I
think the library problem is more or less solely confined to the more
``experimental'' functional languages (though I assume Yale Haskell
lets you get at a lot of CL baggage without too much pain).
>Likewise, trying to get some complicated algorithm to run fast and use
>little space can be much harder in Lisp or Smalltalk than in C, even if
>a simple implementation of the algorithm would be easier in those
>languages.
I don't know about Smalltalk, but it's not overly hard to get complex
algorithms to go quickly in Lisp or even, dare I say it, Haskell
(though space efficiency will bite you in Haskell). I'd say the amount
of effort required to code an algorithm efficiently in either of these
languages is about the same as that required to get an efficient
algorithm going in C.
<b
--
Bryan O'Sullivan u nas est tolko odyeen yagnyonok seychas.
Computing Science Department email: ···@cyclic.com, ···@dcs.gla.ac.uk
University of Glasgow web.gunge: http://www.scrg.cs.tcd.ie/~bos
From: Amancio Hasty Jr
Subject: TAOS (Re: Why is TCL successful ?)
Date:
Message-ID: <hastyCu8K9u.KKH@netcom.com>
Any comments or experiences with TAOS?
There a nice article in the Byte Magazine about it. I think in the
June issue...
What I like about TAOS is that the compilitation output is targeted
to a virtual machine. When objects are loaded, the system compiles
them into the native machine code. Supposedly the assembly process
is very efficient.
Tnks,
Amancio
--
FREE unix, gcc, tcp/ip, X, open-look, netaudio, tcl/tk, MIME, midi,sound
at freebsd.cdrom.com:/pub/FreeBSD
Amancio Hasty, Consultant |
Home: (415) 495-3046 |
e-mail ·····@netcom.com | ftp-site depository of all my work:
| sunvis.rtpnc.epa.gov:/pub/386bsd/X
From: Jurgen Botz
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <31u8pb$j4m@mudraker.mtholyoke.edu>
In article <··········@world.std.com>,
Joseph H Allen <·······@world.std.com> wrote:
>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, [...]
No argument there...
>2 and 3 are not necessary, hurt readability and can be considered semantic
>sugar.
I don't think any of these /hurt/ readability, ever, and I can't
imagine what "semantic sugar" might be (I've heard of "syntactic
sugar", i.e. "sweetening" cumbersome syntax by dressing it up, but
before we can talk about sweetening cumbersome semantics, we'd have to
get into an argument over what cumbersome semantics /are/...) Also,
isn't it a bit self-contradictory to claim that something is sugar,
but that it ain't sweet?
>4 is the only one which is really unique to lisp. It's made redundant by 1
>though, so I don't miss it.
I don't see what Lisp's ability to treat programs and data identically
(which is what I assume you mean by self-representation) has to do
with closures? Most Lisp's don't have closures, but they all
represent programs as lists...
On the other hand, Tcl (I started reading this thread in comp.lang.tcl) is
also self-representing in the above sense, but using strings rather than
lists as the fundamental type from which programs are made.
(I removed comp.windows.x from the newsgroups line.)
--
Jurgen Botz, ·····@mtholyoke.edu | Communications security is too important to
Northampton, MA, USA | be left to secret processes and classified
| algorithms. -- USACM
From: Steven D. Majewski
Subject: Thick Books ( was: What other experimental languages connect... )
Date:
Message-ID: <Cu8nvK.JEv@murdoch.acc.Virginia.EDU>
In article <··········@world.std.com>,
Joseph H Allen <·······@world.std.com> wrote:
>
>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.
>
The length of a language manual is not a commensurate metric.
"Common Lisp, the Language" has more complete and detailed
coverage of it's language than almost any other manual I've seen. Guy
Steele ( the editor of CLtL ) was also the coauthor of a reference
manual for C which was 2 or 3 times as long as K&R. Steele's C manual
was as detailed as the Lisp manual, with discussion and justifications
of various ANSI features, and comparison with non-ANSI compilers, etc.
A lot of explaination of WHY and WHY-NOT.
The functional equivalent of the same level of documentation
for C would be Harrison & Steele's C Reference Manual *PLUS* another
book on portability and the standard C libraries. This would probably
equal the page count of CLtL1 ( The first version, which is the one
I have on my shelf. CLtL2, which adds documentation for CLOS probably
regains the record again. )
I'm not arguing that Common Lisp isn't, in many ways, a complex
language. Just that the size of the manual is NOT usually a reasonable
mesaure of complexity. ( I could also argue that there are different
TYPES of complexity, and that some types are better/worse than others,
but I'll save that argument for later! )
- Steve Majewski (804-982-0831) <·····@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics
From: Ted Dunning
Subject: Re: Thick Books ( was: What other experimental languages connect... )
Date:
Message-ID: <TED.94Aug8204121@lole.crl.nmsu.edu>
In article <··········@murdoch.acc.Virginia.EDU> ·····@elvis.med.Virginia.EDU (Steven D. Majewski) writes:
The functional equivalent of the same level of documentation
for C would be Harrison & Steele's C Reference Manual *PLUS* another
book on portability and the standard C libraries.
plus a complete reference on c++ and associated object libraries along
with specification of the hooks available to build a class browser
(i.e. a metaobject protocol).
This would probably
equal the page count of CLtL1 ( The first version, which is the one
I have on my shelf. CLtL2, which adds documentation for CLOS probably
regains the record again. )
not after you mention c++, it doesn't. and c alone is a much more
like what cltl1 describes.
From: Jeff Dalton
Subject: Re: Thick Books ( was: What other experimental languages connect... )
Date:
Message-ID: <CuFq7L.60J@cogsci.ed.ac.uk>
In article <··········@murdoch.acc.Virginia.EDU> ·····@elvis.med.Virginia.EDU (Steven D. Majewski) writes:
>In article <··········@world.std.com>,
>Joseph H Allen <·······@world.std.com> wrote:
>>
>>I agree. Common lisp is hopeless. Its standard manual is longer than that
>>of _every_ _other_ programming language
Not so. Look at InterLisp or ZetaLisp, for instance, or even PL/I.
There may well be others.
>>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.
Dotted pairs have been around since at least lisp 1.5. ' since at
least the early 70s. Where do you get this "Lisp ideal" from?
And why do you place the departure from the ideal at Common Lisp?
>The length of a language manual is not a commensurate metric.
Just so. For instance, it includes much that might otherwise be
in a spearate "library" document.
>[...]
>Guy Steele ( the editor of CLtL ) was also the coauthor of a reference
>manual for C which was 2 or 3 times as long as K&R. Steele's C manual
>was as detailed as the Lisp manual, with discussion and justifications
>of various ANSI features, and comparison with non-ANSI compilers, etc.
>A lot of explaination of WHY and WHY-NOT.
>
> The functional equivalent of the same level of documentation
>for C would be Harrison & Steele's C Reference Manual *PLUS* another
>book on portability and the standard C libraries. This would probably
>equal the page count of CLtL1 ( The first version, which is the one
>I have on my shelf. CLtL2, which adds documentation for CLOS probably
>regains the record again. )
Note BTW that CLtL II describes some things that are *not part
of Common lisp* (e.g. series) and some things that would ordinarily
be considered a separate program (the XP-derived pretty-printer).
Some other randomly selected comparisons:
CLtL I is shorter than Knuth vol 1. CLtL II is shorter than the BSD
library man pages, not to mention the X man pages. The XView
Programming Manual alone (which I happen to have on my bookshelf)
is as big as CLtL I.
>I'm not arguing that Common Lisp isn't, in many ways, a complex
>language. Just that the size of the manual is NOT usually a reasonable
>mesaure of complexity. ( I could also argue that there are different
>TYPES of complexity, and that some types are better/worse than others,
>but I'll save that argument for later! )
Is TeX simpler than CL? Is C++? I don't find them so.
-- jeff
From: Mike Gallo
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <1994Jul28.095531.28717@psg.com>
In article <····················@obelix.simulog.fr>
······@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.
From: Wolfgang Lux
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <31akl6$lta@kaa.heidelbg.ibm.com>
In article <······················@cs.rit.edu>, ·······@cs.rit.edu (Nicolas M Williams) writes:
|> 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).
Sorry, but I thought lambda was one of the very functional parts of
lisp. Should it be true that Icon has no way of representing anonymous
functions?
Wolfgang
--
Wolfgang Lux
WZH Heidelberg, IBM Germany IBM IP-Net: ···@rio.heidelbg.ibm.com
+49-6221-59-4546 VNET: LUX at HEIDELBG
+49-6221-59-3300 (fax) EARN: LUX at DHDIBMIP
From: Hendrik Boom
Subject: Re: Why we must somtimes have lisp/scheme after all. (WAS: What other experimental languages connect to a windowing system?)
Date:
Message-ID: <31mamr$8kc@cumulus.CAM.ORG>
I hear the usual complaints on this thread about Lisp's parentheses.
There's been lots of syntaxes for different constructions that would
otherwise be unreadable because of the parentheses. But there's a simple
way to deal with most of the parentheses.
Whenever a parenthesized phrase occurs at the end of another.
use a slash instead of parenthesizing it, thus:
(abf gut ( hnniuf slks))
becomes
(abf gut / hnniuf slks)
this gets rid of most of the parenthesis clusters in Lisp.
It makes it easy to use "if" instead of "cond",
or a "let" without a list, because many such constructs naturally
nest in their last argument.
P.s. another candidate for a "/" is a semicolon, but that looks better at
the end of a lin than at the beginnning:
( if onions bagels
/ if cows milk
/ let horse pony
/ list onions cows horse
)
( if onions bagels ;
if cows milk ;
let horse pony ;
list onions cows horse
)
In my experience, with this feature, most Lisp read-macros
become unnecessary, and much syntactic sugar likewise.
hendrik.
From: Niels P. Mayer
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <MAYER.94Jul23142244@netcom2.netcom.com>
[please excuse following up to my own last posting ... Ousterhout's
original posting appears to have expired on netcom...]
From: ······@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: ·······@bcarh80a.bnr.ca (7Z31 Coop)
| In article <······················@khis.com>, ······@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: ·······@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 <········@CMU.EDU>
| ······@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: ······@london.sbi.com (David Artus)
| Long Pham (·····@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: ·······@bcarh80a.bnr.ca (Dan MacDonald)
|In article <······················@wmichgw>, ········@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: ···@cam-orl.co.uk (Frank Stajano)
| In article <··········@hydrox.cs.umd.edu>, ······@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: ···@cam-orl.co.uk (Frank Stajano)
| In article <···················@chacmool.stsci.edu>, ·····@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: ···@cs.hut.fi (Sami-Jaakko Tikka)
| In <··········@access3.digex.net> ·······@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 -- ·····@netcom.com ==
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From: Paul Alexander
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <30tikq$mb6@lyra.csx.cam.ac.uk>
In article <···················@netcom2.netcom.com>, ·····@netcom2.netcom.com (Niels P. Mayer) writes:
|> 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
From: Don Bennett
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <DPB.94Jul25114854@pedernales.sgi.com>
> 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.
The secondary prompt makes it clear (to me at least) that additional
input is expected.
--
Don Bennett (415)390-2145
···@sgi.com
Silicon Graphics
From: Peter da Silva
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <id.1QJB1.UI@nmti.com>
In article <·················@pedernales.sgi.com>,
Don Bennett <···@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?"
From: Juergen Wagner
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <1994Jul24.170926.23697@Csli.Stanford.EDU>
There are two types of GUI toolkits on the market (including the
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
··············@iao.fhg.de
·······@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 ·······@csli.stanford.edu".
From: Martin Rodgers
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Date:
Message-ID: <775056888snz@wildcard.demon.co.uk>
In article <···················@netcom9.netcom.com>
·····@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
················@cpsr.org and tell them you oppose Clipper.
This is a shareware .signature -- please pass it on!