What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Niels P. Mayer
[note additional crossposting to comp.lang.lisp]
In article <LORD.94Ju...@x1.cygnus.com> lo...@x1.cygnus.com (Tom Lord) writes:
ous...@sprite.Berkeley.EDU:
Since we're slinging arrows, allow me to sling mine. It's
time to accept the fact that Lisp will never be a mainstream
language. There's no question that Lisp is an intellectually
interesting language, and it is very important in certain
communities, such as AI and formal language design. But it's
simply never going to be widely used.
Right. No general-use application written in lisp will ever fly.
Only in a few exotic situations do people ever use lisp.
Tom Lord
part-time emacs hacker
Perhaps you mean no general use application written entirely in Common
Lisp will ever fly? I can think of lots of counterexamples:
* GNU Emacs partially written in Lisp. It is a hybrid
implementation using C at its core, and Lisp as a configuration
and extension language.
* AutoCAD uses AutoLisp as an extension language. It is very very
popular given that it is a CAD package, and not, say, a spreadsheet.
I can't remember the figures exactly, but I've heard there's 500,000
to 1,000,000 copies of it floating around world-wide.
* Various other CAD packages use Lisp extension languages as well,
for example Cadence Design Systems.
* Interleaf uses Lisp as an extension language.
* SoftQuad has an SGML editor which uses Scheme (a Lisp dialect) as an
extension language.
* All applications written in WINTERP (I know of one that had
an estimated 1500 users.) All applications using Elk. All.
applications using CLM/GINA. All applications using GNU Emacs
and written in Emacs-Lisp (such as the newsreader I'm using --
GNUS).
* The statistics community has found Luke Tierney's XLISP-STAT
to be a very cool package as well. THis is a package with
a hybrid C/Lisp implementation of Lisp which is extended to
do graphics and plotting (Mac,Unix/X11) and with statistics
primitives.
--------------------
From: ous...@sprite.Berkeley.EDU (John Ousterhout)
> Since we're slinging arrows, allow me to sling mine. It's time to accept the
> fact that Lisp will never be a mainstream language. There's no question that
> Lisp is an intellectually interesting language, and it is very important
> in certain communities, such as AI and formal language design. But it's
> simply never going to be widely used. Lisp has been trying for more than
> 30 years; every few years we hear another round of grandiose claims, and
> a few years later they have evaporated. We could argue about why Lisp
> hasn't entered the mainstream, but none of this changes the basic fact
> that it hasn't.
>
> I believe that it is reasonable to give new ideas a chance and to accept
> plausible arguments that they might succeed, but when a system has been
> around for 30 years I don't think "plausible arguments" are enough anymore.
> If someone is going to argue today why Lisp should be a mainstream
> language, they must somehow explain why it hasn't succeeded in the past
> and what will happen this time to make things turn out differently.
Repeating "Lisp is dead" over and over and over again will not make it
true, just like repeating "Tk has a Motif Look and Feel" will not make it
true to someone expecting a Tk application to "feel" like Motif.
All you have to do is go down to any technical bookstore and you will find
many many books on Lisp programming, Lisp application programming and
Scheme programming. And I'm not talking about 30 year old books on Lisp,
I'm talking about books that are in their third or fourth printing and have
been published in the last few years. There is a market for these books,
otherwise the publishers would never have put these books out, nor put out
new editions of older books (e.g. Winston&Horn).
In addition to Lisp books, there are also a number of recently published
books on the Scheme dialect of Lisp. One of the best introductory books on
computer science, Abelson&Sussman's "Structure and Interpretation of
Computer Programs", uses SCHEME and not Pascal or C to introduce the
student to a variety of interesting CS problems. The fortunate few that are
able to make it in to MIT end up taking 6.001 (which uses the
Abelson&Sussman book) as their introductory computer science and
programming course, which tends to put these folks on the right track right
from the start.
Finally, I know of at least three books on GNU Emacs which discuss
Emacs-Lisp programming, and there's whole rows of books on AutoLisp
programming for AutoCAD.
(Since WINTERP uses XLISP-PLUS, I'll also mention that I know of two books
on XLISP, and one on Luke Tierney's XLISP-STAT).
Meanwhile, I know of exactly one book on TCL/Tk (Ousterhout's) that is now
available in bookstores. More importantly I haven't come across any books
on applications using TCL/Tk as an extension language (like the GNU Emacs
or AutoCAD books).
> |> Yes, TCL is a simple language -- I contend that it is too simple and too
> |> simplistic for constructing well engineered applications:
> |> ...
>
> Again, I think the large number of Tcl applications and the growing size of
> the Tcl community speak for themselves. What better evidence could there
> be that Tcl and Tk are practical for building interesting and useful
> applications?
I already answered to this in my original post when I said:
| The fact that people *can* program applications in the bourne shell, or
| tcsh, or the korn shell does not imply that a language having the above
| limitations is a good or expressive language for building applications.
Some of the problems I addressed:
| * type-overloading of strings, and lack of any real type system.
| * lack of proper automatic memory and resource management (freeing
| up data when a widget is destroyed doesn't quite cut it).
| * lack of lexical scopes for functions/procedures.
| * lack of closures (forcing programmers to use too many global
| variables).
| * Lack of object orientation in the standard TCL/Tk release.
Are clearly problems with TCL in terms of building larger applications that
scale well, and aren't mired in a sea of global references. I can't imagine
that people spent the time to develop [incr tcl] and [incr tk] unless
they were attacking a known problem.
I think the whole "popularity" line of reasoning is questionable: MS-DOS
and MS-WINDOWS are more popular than Unix/X, but many of us have good
reasons to keep working on Unix and X. Beyond that, if you're worried about
popularity, both the Lisp and TCL/Tk community are no doubt insignificant
when comparted to, say the Visual Basic community, or Actor, or other
similar packages available for MS-WINDOWS.
In other words, the popularity argument is meaningless at best, and
specious at worst. Some people are willing to pay the costs of Lisp in
return for its benefits. Others may be lured to TCL/Tk because it is small,
simple and free and includes a free toolkit. None of these have anything
to do with the fact that the language may not be good for building
GUI-based applications. People write applications in assembly too.
When discussing language features, one shouldn't confuse a trend with a
movement.
I personally couldn't give a deleted expletive about whether Lisp is more
or less popuplar than TCL/Tk or Perl, just as long as no employer of mine
ever demands that I write, maintain, or extend a TCL/Tk or Safe-TCL
program. In the mean time, I'm happy to see that we all have choices and
are not locked in to any particular form of lowest-common-denominator
groupthink (e.g. MS-DOS) -- use the best tool for the job, whether it be
C, C++, Lisp, TCL, Perl, Awk, Sed, ASN1, APL, Prolog, or whatever.
Michael Tiller
[lots of stuff deleted]
|>
|> I personally couldn't give a deleted expletive about whether Lisp is more
|> or less popuplar than TCL/Tk or Perl, just as long as no employer of mine
|> ever demands that I write, maintain, or extend a TCL/Tk or Safe-TCL
|> program. In the mean time, I'm happy to see that we all have choices and
|> are not locked in to any particular form of lowest-common-denominator
|> groupthink (e.g. MS-DOS) -- use the best tool for the job, whether it be
|> C, C++, Lisp, TCL, Perl, Awk, Sed, ASN1, APL, Prolog, or whatever.
Am I the only one who finds this paragraph self-contradicting.
"...as long as no employer of mine ever demands that I write...TCL/Tk"
followed in virtually the same breath by
"...use the best tool for the job..."
Come on.
Mike
Richard Karpinski
wholly or partially in Lisp IMHO should end all talk of Lisp
is Dead.
--
"If I cannot bring it up on my monitor and it does not interfere
with a major aspect of my physiology, like eating, sleeping, or breathing,
then it probably does not exist"
Bill Janssen
Am I the only one who finds this paragraph self-contradicting.
"...as long as no employer of mine ever demands that I write...TCL/Tk"
followed in virtually the same breath by
"...use the best tool for the job..."
With all due respect for the wonderful implementation of Tcl, I find
it difficult to think of a job for which Tcl is the best tool.
Perhaps someone could make a list?
Bill
--
Bill Janssen <jan...@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html
Niels P. Mayer
original posting appears to have expired on netcom...]
From: ous...@sprite.Berkeley.EDU (John Ousterhout)
| There are many things in Niels Mayer's article that deserve a rebuttal, I'll
| just pick a couple:
|
| |> TCL's problems of language quoting incosistency make it difficult to write
| |> higher level abstractions for UI construction -- macros, iterators,
| |> data-driven-UI-generation, etc. Not that higher level abstractions can't be
| |> done -- it's just that creating them in TCL is linguistically painful
| |> because the language uses the wrong fundamental data-type -- newline
| |> delimited STRINGs separated by spaces. In constrast LISP chose the right
| |> fundamental data-type LISTs of SYMBOLs, and consistently applies this
| |> datatype across throughout the language.
| |>
|
| This paragraph suggests that you don't understand Tcl. In fact the quoting
| rules are very simple and very consistent; I claim that it's quite
| straightforward to build higher-level constructs for UIs and I think there
| are many many examples in the Tcl community that illustrate this. One
| can make religious arguments ad nauseum, but I know of no technically
| sound evidence that lists of symbols are fundamentally better than strings.
It looks like a number of your users are also having trouble understanding
Tcl. In my opinion, this is because the quoting and parenthisation rules
are neither straighforward, simple, nor consistent. About once every week
or two, I see questions come up on comp.lang.tcl dealing with one or more
of the issues raised above. Examples of these problems have been
appended to the end of this article...
When users are having real problems, it becomes clear that the arguments
are no longer religious. In Lisp, you can get arbitrarily complex and
inscrutable once you go to extreme macro-ology and multiple levels of
backquoting. However, for the more typical cases handled by the neophyte,
the problems of quoting, time-of binding, time-of substitution, and scope
of bindings are more consistent and easier to understand in Lisp. And
when you need to, you know that there's a very nice macro capability
to back up any meta-level programming you need to accomplish.
By default, Lisp does the right thing for the case of binding at run-time,
and when you need to perform binding at evaluation time, you use
backquotes... The places where backquote substitutions happen are clearly
marked by backquoting 'commands' e.g. (,foo); all other cases look up the
value of a symbol based on the closure surrounding the code being
executed. By using closures, one may limit the extent of variables to
groups of functions or methods, an application module, or the entire
application -- closures are the basis enabling any lexically scoped Lisp
solution to scale better than TCL. And in Lisp, you don't have multitudes
of different ways of opening and closing expressions...
Furthermore, there's 30 years of history and 30 years worth of books on
Lisp programming which have dealt with these problems from the pedagogical,
technical, and style/design perspectives. Most beginners find this helpful.
Reinventing the issues which are already solved problems in Lisp, just so
that you can have a language that doesn't parenthesize like Lisp -- that is
not helpful to the beginner. It does, however, open up a whole new market
for books.
Finally, I think that having language syntax depend on newlines is a bad
idea -- I think most unix shell programmers will grudgingly agree with me
on this. I'd much rather have a Lispish syntax where you delineate your
current top-level evaluations by [ ... ] and don't bother with newlines.
Unfortunately, given people's knee-jerk response to Lisp, having such a TCL
would highlight TCL's parentage as bastard-child-of-Lisp. Something almost
Lisp-like would set-off or shatter people's preconceived panic
response. Can't do that! (Meanwhile, I eagerly await the chance/time to see
how the Dylan folks solved the problem of being politically right-thinking
with regards to syntax while retaining a Lisp core).
Well, here go the examples, cleaned from a random reading through
comp.lang.tcl articles on this site:
--------------------
From: hfv...@bcarh80a.bnr.ca (7Z31 Coop)
| In article <1994Jul21.1...@khis.com>, cha...@khis.com (David Chang) writes:
|
| [... Stuff Deleted ...]
| |> I'm trying to get the number of word "set" appeared in $file and set
| |> the scale value by using "set count [exec grep -c set $file]; .scale set $count".
| |> This doesn't work if no "set" appeared in file "$file" , so I change to use
| |> the following method (use catch) :-) Guess what ?
| |>
| [... Stuff Deleted ...]
| |>
| |> catch [exec grep -c "set" $file] retval
| |> if { $retval == 1 } {
| |> .scale set 0
| |> return 0
| |> }
| |>
| |> if { $retval != 1 } {
| |> set count [exec grep -c "set" $file]
| |> .scale set $count
| |> return 0
| |> }
| |>
| |> So my question is : How do I set the variable "count" if the return value of
| |> "grep -c" is 0 ?
|
| Try:
|
| if {[catch {set count [exec grep -c "set" $file]}]} {
| .scale set 0
| } else {
| .scale set $count
| }
| return 0
From: fri...@faw.uni-ulm.de (Davide Frisoni)
| Hello everyone,
| thanks to all people who answered my question, the main error come from a wrong use of [].
|
| I wrote :
| set code [catch [my_cprogram] err] :-(
| and now with :
| set code [catch {my_cprogram} err] :-)
| it works.
From: Rob Earhart <earh...@CMU.EDU>
| wessel@stt_even.let.ruu.nl (Wessel Kraaij) writes:
| > proc 8bitbindings {widget} {
| > bind $widget \" {set nop 0}
| > bind $widget \"\" {$widget insert insert \"}
| > bind $widget \"e {$widget insert insert \353}
| > }
| >
| > Unfortunately, this does not work, because $widget in the binding
| > script is evaluated at event time, not at bind time!
|
| proc 8bitbindings {widget} {
| bind $widget \" {set nop 0}
| bind $widget \"\" [list $widget insert insert \"]
| bind $widget \"e [list $widget insert insert \353]
| }
|
| Yeah, I stumbled on this when learning TCL, too :-)
From: dav...@london.sbi.com (David Artus)
| Long Pham (lp...@tern.NoSubdomain.NoDomain) wrote:
| : Hello tcl experts,
|
| : I'm a newbie in this area, and have a small problem while playing w/
| : tcl. So, be gentle.
|
| : Here is my problem:
| : I'm trying to create an n number of buttons, each button will call
| : a same proc upon activated. And an argument passes to the proc is
| : an variable, i.e. different value for different button. I want to
| : display the value of the argument that I passed to the proc everytime
| : I click on a button. However, the program doesn't work, it always
| : display the last value of the variable no matter what button I
| : clicked on.
|
| : set names {John Anne Mary Jim}
| : foreach b $names {
| :
| : button .$b -text $b -command {displayName $b}
| : pack .$b -side left -padx 3
|
| : }
|
| : proc displayName bname {
| : puts $bname
| : }
|
| your problem is -command {displayName $b}
|
| The {} defer evaluation of $b till the event occurs. At that time
| b is, of course, set to Jim. You probably mean -command "display $b"
| for the purposes of this playing, or in real life maybe some
| cunning way of extracting the button name, contents or whatever.
From: hfv...@bcarh80a.bnr.ca (Dan MacDonald)
|In article <1994Jul22.005941.19824@wmichgw>, 31ch...@wmich.edu writes:
||> Hello Everybody,
||>
||> I am a new user of tk/tcl. I have a question.
||>
|
|Your entire problem:
| Very simply it's the value being passed to your procedure s1 is
| always '0'. This stems from the fact that when you created the
|
| button .watch22.yes -text YES \
| -command "s1 $foo_value"
|
| you specified the command (bind command) in quotes which performs
| substitutions when created. If you enclose the command in curly
| braces the substitution will be performed later. Although the (all)
| bind command operates at global scope, this is acceptable since the
| variable foo_value is a global variable - it must be because it
| to is "bound" by the scale widget to store the value.
|
|Try: button .watch22.yes -text YES -command {s1 $foo_value}
|
|Dan MacDonald
From: f...@cam-orl.co.uk (Frank Stajano)
| In article <303o17$4...@hydrox.cs.umd.edu>, nle...@cs.umd.edu (Nathan Lewis) writes:
| |> Hi everyone,
| |>
| |> I'm still new to tcl and I'm having some trouble. I'm trying to write lines to
| |> a file. There is one line where I want to write a bunch of things to the file
| |> literally but the problem is that I want to write $variable-name to a file
| |> literally and the interpreter keeps trying to evaluate the variable and I can't
| |> seem to get it not to.
| |>
| |>
| |> Thanks alot for any help.
| |>
| |> This is the code:
| |>
| |> button $w.ok -text "EXIT" -command " ;\
| |> puts \$datafile \"set precedence_relO \$precedence_rel\" ;\
| |> puts \$datafile \"\n\n\n\" ;\
| |> puts \$datafile \"set precedence_rel {\[lindex \\$precedence_relO 0\]}\" ;\
| |> This is the line ^ This is the variable ^
| |> puts \$datafile \"\n\" ;\
| |> puts \$datafile \"set Threads [list $Threads]\" ;\
| |> puts \$datafile \"\n\" ;\
| |> puts \$datafile \"set exclusion_rel [list $exclusion_rel]\" ;\
| |> exit ;\
| |>
|
| I must admit I haven't got a very clear idea of what you are trying to do, but
| if all you want is putting out stuff literally you could use curly brackets
| instead of quotes. If instead you want to have some of the things substituted
| (like the []'s) and some not (like the $'s) then I'd say your best bet is to
| make the command a separate procedure and build up the complex string in the
| procedure with "append". Otherwise it becomes a bit too complicated to do in one
| single command line, and the code becomes difficult to read and maintain.
From: f...@cam-orl.co.uk (Frank Stajano)
| In article <ASSON.94J...@chacmool.stsci.edu>, as...@chacmool.stsci.edu (Drew Justin Asson) writes:
| [...]
| |> >proc foo {x} {
| |> > global Global_Var
| |>
| |> > if {$x == ""} {
| |> > return $Global_Var
| |> > } else {
| |> > return $x
| |> > }
| |> >}
| |>
| |>
| |> The only problem with this is that this will raise an error
| |> if no argument is provided. To do what you want, you would
| |> have to declare the argument list as:
| |>
| |> { {x ""} }
| |>
| |> Then, the code would work.
|
| You're absolutely right, thanks for pointing it out. (Using args instead of x is
| another option.)
|
| |> But, this isn't really what I wanted. I was more interested in
| |> doing something that we often do with LISP code. E.g.
| |>
| |> proc foo { {x minus-infinity} {y plus-infinity} } {
| |> ...
| |> }
| |>
|
| I can't think of a Tcl way of doing this sort of thing in the argument list. If
| someone finds one, I'd be curious to know about it.
From: s...@cs.hut.fi (Sami-Jaakko Tikka)
| In <30jdao$8...@access3.digex.net> cob...@access3.digex.net (Cary B. O'Brien) writes:
| >Why does expr { fred < sam } fail,
| >When expr { "fred" < "sam" } succeeds.
|
| When expr sees strings without quotes, it tries to convert them to
| numbers.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
== Niels Mayer -- netcom!mayer -- ma...@netcom.com ==
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Libes
+ From: ous...@sprite.Berkeley.EDU (John Ousterhout)
+ | This paragraph suggests that you don't understand Tcl. In fact the quoting
+ | rules are very simple and very consistent; I claim that it's quite
+ | straightforward to build higher-level constructs for UIs and I think there
+ | are many many examples in the Tcl community that illustrate this. One
+ | can make religious arguments ad nauseum, but I know of no technically
+ | sound evidence that lists of symbols are fundamentally better than strings.
+ It looks like a number of your users are also having trouble understanding
+ Tcl. In my opinion, this is because the quoting and parenthisation rules
+ are neither straighforward, simple, nor consistent. About once every week
+ or two, I see questions come up on comp.lang.tcl dealing with one or more
+ of the issues raised above. Examples of these problems have been
+ appended to the end of this article...
+ When users are having real problems, it becomes clear that the arguments
+ are no longer religious. In Lisp, you can get arbitrarily complex and
+ inscrutable once you go to extreme macro-ology and multiple levels of
+ backquoting. However, for the more typical cases handled by the neophyte,
+ the problems of quoting, time-of binding, time-of substitution, and scope
+ of bindings are more consistent and easier to understand in Lisp. And
+ when you need to, you know that there's a very nice macro capability
+ to back up any meta-level programming you need to accomplish.
As a computer scientist, I found Lisp beautiful and easy to learn.
But that doesn't mean I like programming in it. The heart of Lisp,
the list, models only a fraction of the algorithms and data structures
that I deal with. Everything else is 2nd class and dilutes the beauty
of the language. As soon as I wrote my first do-loop in Lisp, started
declaring my data structures, and explaining all sorts of things to
the compiler, the courtship was over. As I remember, macros were the
final straw. As you admit, they make the language inscrutable, and
since everyone uses them...
I am not defending Tcl. I am simply saying that I find your arguments
about Lisp contrived. There are obvious difficulties in Lisp to
beginners that you have conveniently forgotten. If as many people
were learning Lisp as were learning Tcl, I'm sure the number of
beginner-type questions to comp.lang.lisp would be just as high. I
actually went and looked to see what's happening in the newsgroups and
c.l.l has the same beginner questions that you can find in any
language newsgroup. Here's a classic sample:
>From: [name changed to protect the innocent]
>Subject: Book Recommendation????
>Message-ID: <2vo19p$o...@jadzia.CSOS.ORST.EDU>
>Date: 10 Jul 94 05:34:49 GMT
>
>I am new to the LISP language (studying for alomst a year) and have read
>a few books on LISP. I am interested in hard core (excuse the expression)
>programming using the LISP language. Most of the books that I have read
>have gotten confusing about halfway through. I know this may have been
>asked in the past but I would like to know what book(s) would be
>recommended for a beginner on LISP?? Any responses would be greatly
>appreciated...Thanks
This poor guy has been studying Lisp for a year, has read several
books on it and still considers himself "new to the language"?!
My point is, citing messages from confused novices doesn't prove the
language is difficult any more than messages from rabid experts proves
that the language is great.
Don Libes <li...@nist.gov>
Paul Alexander
|> Finally, I think that having language syntax depend on newlines is a bad
|> idea -- I think most unix shell programmers will grudgingly agree with me
|> on this. I'd much rather have a Lispish syntax where you delineate your
|> current top-level evaluations by [ ... ] and don't bother with newlines.
But Tcl was intended, and used by many of us, as a shell-like command
interface to applications and ALSO as an extension language. I think the
vast majority of users would be confused by a "SHELL" in which newline did
not terminate input to a command. It is in this respect that Tcl's very
simple syntax is just the job for an embedded language.
Paul Alexander
Department of Physics, University of Cambridge, Cambridge, UK
Stephen J Bevan
... As a computer scientist, I found Lisp beautiful and easy to learn.
But that doesn't mean I like programming in it. The heart of Lisp,
Lisp 1.5 perhaps, but things have moved on since then. Functions are
the heart of Scheme (I don't think Common Lisp has a heart :-)
... models only a fraction of the algorithms and data structures
that I deal with. Everything else is 2nd class and dilutes the beauty
of the language. ...
Are you implying that structures, vectors, ... etc. are all "2nd
class" in Common Lisp? Either way, what is your definition of "2nd class"?
Juergen Wagner
public domain): those using an interpreted approach, and those based
on a compiled language. The interpreted tools use a more or less
simple language to specify or actually program widgets, gadgets, and
whatever they may call them. The compiled tools emit C or C++ code
where a user may fit in his/her application code.
Both have advantages and disadvantages: interpreted languages usually
allow dynamic loading in a simple fashion, i.e., they are good for
prototyping of complex user interfaces you couldn't easily do in a
compiled environment due to the time needed for edit-compile-run
cycles. Also, compiler-based languages require an entire restart of
the application (because the patched program is a new program), while
interpreted systems can handle updates on the fly. Compiler-based
languages are more efficient for numerical calculations and other
low-level operations.
Compiling both approaches is what has been done in LISP. One of the
problems of LISP (still my favourite programming language), however,
is that it is a fully-fledged programming language with constructs a
little bit unfamiliar to usual programmers. The price you have to pay
for an elegant language like LISP: it is...umm... different.
Tcl also tries to combine the two approaches by providing an
interpreted language which is extensible by C- or C++-written
commands. However, sacrificing a real type system (LISP has a full
type system) causes problems for certain applications: take an
object-oriented database, for example. Object types and ids cannot be
simply distinguished from strings which happen to look the same. Users
have to artificially add type markers because there are only strings
in Tcl. Syntactic features must be used to differentiate between
types.
Other than that, Tcl very much resembles a LISP with BASIC elements,
and turns out to be useful for most user interface designs, although
the syntacticness of types can cause weird situations with character
or expression quoting.
As for Tk, there are also advantages and disadvantages: First of all,
it is nice to have a toolkit of relatively elaborate widgets which is
as simple to manage as Tk. Tools like XDesigner are nice, but once you
go beyond what they provide as pre-manufactured widgets, you have to
go down into the basement and dig up those Motif manuals. Also, you
may find your actual data items nested into a four-level struct. The
problems with Tk come in where compute-intensive portions of a GUI
need to be implemented. Passing data between Tcl/Tk and a C/C++
application in the form of strings simply won't be efficient enough
for such applications.
This is the point where I wished I had a more layered system at my
disposal:
Level 0 Xlib and friends
Level 1 Tk with a C/C++ interface pretty much
like SunView had
Level 2 Tcl-binding for Tk
This way, Tk would be 100% separated from Tcl, also allowing other
languages to bind more easily to the nice widgets provided. In
particular, C/C++ interfaces would be able to directly access
functions to do their high-volume data output which would be too
time-consuming when done through Tcl strings.
In a way, the purely syntactic character of data types in Tcl wouldn't
be that much of an issue any more because the critical parts, where
type semantics is lost in string conversion, could be done directly in
C or C++, or any other language replacing the level-2 binding (LISP?).
How much of Tk would be available at level 2, and how types are
handled exactly, would be left to level 2. Tcl would be a simple but
type-wise restricted language, LISP could carry through all
information.
The ultimate question always is: "Is it useful for my application? If
not, what is?" We had a project at FhG-IAO, where the GUI design was
done with a copmiler-based GUI designer. At some point, there was a
requirement to do splines. Due to problems implementing this quickly
under the GUI tool, we had to bring in UNIRAS, a huge, overkill
scientific visualization package. It sort of worked, but was an
incredible kludge to use that monstrous package only for the splines.
Little later, the entire GUI was re-done with Tcl/Tk. Not only was the
development time (including the time to learn Tcl/Tk) of the entire
GUI much shorter, but the configurability and overall flexibility was
greatly enhanced.
If I compare the results (and efforts!) for some GUI designs, I'm
happy to have a tool at my disposal which allows me to quickly
prototype GUIs without bothering much about type information and
declarations. This tool may be Tcl/Tk, it may be a LISP-based
environment. If I only have to position a few buttons, choose colors,
and plug a simple database interface program into the resulting GUI, a
tool like XDesigner would be most welcome. At WESCON'94, I'll describe
some of the experiences made in this project and others in more
detail.
IMHO, some of the previous discussion, where religious arguments came
up, lacked this view.
--Juergen Wagner
Juergen...@iao.fhg.de
gan...@csli.stanford.edu
Fraunhofer-Institut fuer Arbeitswirtschaft und Organisation (FhG-IAO)
Nobelstr. 12c Voice: +49-711-970-2013
D-70569 Stuttgart, Germany Fax: +49-711-970-2299
For more information/detail, please do "finger gan...@csli.stanford.edu".
Martin Rodgers
ma...@netcom9.netcom.com "Niels P. Mayer" writes:
> I think the whole "popularity" line of reasoning is questionable: MS-DOS
> and MS-WINDOWS are more popular than Unix/X, but many of us have good
> reasons to keep working on Unix and X. Beyond that, if you're worried about
> popularity, both the Lisp and TCL/Tk community are no doubt insignificant
> when comparted to, say the Visual Basic community, or Actor, or other
> similar packages available for MS-WINDOWS.
This is true. If you don't use VB or VC++, there are a lot of people
who won't take you too seriously. Even Actor and Smalltalk/V get heavy
criticism, coz reviewers (I'm told that one of the was Ray Duncan) use
the "Hello, World" type app (App? What a joke.) as a benchmark. Using
code like that can make even VC++ look bad, but that doesn't stop
reviewers wetting themselves over it, while all they can say about
Lisp, Smalltalk and Actor is that you _can_ use them if you want to.
They don't say you _have_ to, which is what they're saying about VB
and VC++.
That may explain why I never see any job offers for Lisp or Smalltalk,
but I see many for C++ and VB. Perhaps I'm looking in the wrong places?
After all, I'm only looking in the mainstream computing press.
Languages issues arew irrelevent when you look at them like this. It's
too easy to say, "Pay me to use your favourite language, and I'll be
happy to install it and program with it."
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
If "One likes to believe in the freedom of email", email
clipper....@cpsr.org and tell them you oppose Clipper.
This is a shareware .signature -- please pass it on!
Michael Tiller
|> In article <30p74c$q...@ef2007.efhd.ford.com> til...@solace.me.uiuc.edu (Michael Tiller) writes:
|>
|> Am I the only one who finds this paragraph self-contradicting.
|> "...as long as no employer of mine ever demands that I write...TCL/Tk"
|>
|> followed in virtually the same breath by
|> "...use the best tool for the job..."
|>
|> With all due respect for the wonderful implementation of Tcl, I find
|> it difficult to think of a job for which Tcl is the best tool.
|> Perhaps someone could make a list?
Well, I use a variety of tools some use TCL/Tk some don't. The two
most recent uses I have found for TCL/Tk were...
1) My real work (research) deals with mathematics. As part of this
research I found it necessary to write a Finite Element analysis
package. The package is written in C++ and I was quite content
to write a C++ "program" for each FEA "problem" that I wanted to
run. However after a while this got pretty tedious. Basically,
what it comes down to is the need for an input file which is
read interactively. Now I played around with some parser tools
to try to write a grammar for my input files. However, I kept
changing what kinds of elements I had and such and it got pretty
tedious. Then I decided to write the front-end in TCL. It
works great. Among the added features of using TCL...
* Expressiveness. I can use for loops and such rather than
explicit lists
* I get some added interactive capabilities. For example, in
addition to specifying the problem, I get a certain amount of
control over number of time steps and such. I can stop half
way through a simulation to examine some results
2) I'm currently working as a contractor for Ford Motor Company until
August. They had several text-based applications and they wanted
me to write some GUI stuff for them. I banged these GUIs together
pretty damn fast with the help of TCL/Tk. This has sparked a fair
amount of interest in TCL/Tk here in my department.
Now, I could have used anything I wanted for both of these projects
and I chose TCL/Tk because I felt they were the best tools for the
job. So far, I'm very happy with the results.
|>
|> Bill
|> --
|> Bill Janssen <jan...@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
|> Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
|> URL: ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html
Michael Tiller
University of Illinois
Christophe Muller
> Neils Mayer's recent post detailing the applications written
> wholly or partially in Lisp IMHO should end all talk of Lisp
> is Dead.
Lisp is not dead.
I think Lisp _and_ Tcl, and Perl etc.. will have more and more fields of
applications, it's just a matter of increasing CPU power and of ratio
hardware cost vs engineer cost (is this a fact that we could all agree on? :-).
It seems that Unix, X11, Windows, Emacs, Gcc will stay written in C (with a
small interpreter when needed) for a while, but that a lot of other
applications will be better generated in Cobol by a L4G or in C by Eiffel,
the rest, the "glue" for integrations being Tcl or Lisp code.
For this reason, a religious war between Lisp and Tcl is pointless, they
will certainly *both* have more and more adepts, and C/Fortran/Cobol less.. at
least I hope.. :-)
Cheers,
Christophe.
= % ping elvis =
= elvis is alive =
Don Bennett
> which newline did not terminate input to a command.
Do you really think so? On my machine, only csh terminates input
with a newline.
sh, ksh, and bash will prompt for additional input if you haven't
closed your quoted expressions.
The secondary prompt makes it clear (to me at least) that additional
input is expected.
--
Don Bennett (415)390-2145
d...@sgi.com
Silicon Graphics
Mathieu Longtin
In some earlier part of this discussion, somebody mentionned
a Scheme/Tk package called "STk" if I remember well. However
I can't seem to find anything about that package, does
anybody knows a ftp/www address where I could find info about
STk?
Thanks in advance
Mat
Peter da Silva
Don Bennett <d...@sgi.com> wrote:
> > I think the vast majority of users would be confused by a "SHELL" in
> > which newline did not terminate input to a command.
> Do you really think so? On my machine, only csh terminates input
> with a newline.
> sh, ksh, and bash will prompt for additional input if you haven't
> closed your quoted expressions.
% tcl
tcl>echo "hi there
=>foo"
hi there
foo
What's your point?
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"
David Eby
You can find STk 2.1 in the Scheme Repository:
ftp.cs.indiana.edu:/pub/scheme-repository/imp/STk-2.1.tar.gz
I believe this is the latest version of STk. If you just want info
without actually downloading the package, you might try sending mail
to Erick Gallesio (e...@unice.fr).
David Eby
de...@cs.indiana.edu
Martin Rodgers
li...@nist.gov "Don Libes" writes:
> As a computer scientist, I found Lisp beautiful and easy to learn.
> But that doesn't mean I like programming in it. The heart of Lisp,
> the list, models only a fraction of the algorithms and data structures
> that I deal with. Everything else is 2nd class and dilutes the beauty
> of the language. As soon as I wrote my first do-loop in Lisp, started
> declaring my data structures, and explaining all sorts of things to
> the compiler, the courtship was over. As I remember, macros were the
> final straw. As you admit, they make the language inscrutable, and
> since everyone uses them...
Which Lisp dialect was this? Is it one with structures? Arrays?
Not everything is a list. Some things are even symbols.
> This poor guy has been studying Lisp for a year, has read several
> books on it and still considers himself "new to the language"?!
I still consider myself new to C, even tho I first used it in the
early 80s. Now I'm learning C++, which looks even worse. Most of
what I consider "learning a language" to be is more than the syntax
and the symantics. It's more like style and experience.
> My point is, citing messages from confused novices doesn't prove the
> language is difficult any more than messages from rabid experts proves
> that the language is great.
Agreed. Languages are just different. I love an exchange of opinions,
but please, _please_ let's not try to "prove" anything?
David Chase
|> Lisp is not dead.
|> I think Lisp _and_ Tcl, and Perl etc.. will have more and more fields of
|> applications, it's just a matter of increasing CPU power and of ratio
|> hardware cost vs engineer cost (is this a fact that we could all agree on? :-).
But Lisp could have better syntax. On the other hand, all these other
little languages could have better semantics. For some time it has been
a pet peeve of mine that people inventing little languages, with their
syntax appropriate-to-task/audience, seem to feel it is necessary to badly
re-invent execution semantics. It-would-be-nice if people would take a
little bit of trouble to layer their new syntax on top of (for instance)
Scheme, or an interpreter built in that (continuation-passing) style (it's
NOT HARD, DAMMIT!)
And, there are those little languages with inferior syntax, which could just
as well be replaced by Scheme with a few appropriate primitives. Here, I'm
thinking of the "languages" used to program sendmail and adb.
Then again, it seems to be the norm in Computer "Science" to step on toes
instead of stand on shoulders. Carry on.
David Chase, speaking for myself
Thinking Machines Corp.
John W. Baugh Jr.
Chase) writes:
> But Lisp could have better syntax. On the other hand, all these other
> little languages could have better semantics. For some time it has been
> a pet peeve of mine that people inventing little languages, with their
> syntax appropriate-to-task/audience, seem to feel it is necessary to badly
> re-invent execution semantics.
Amen. Preach it, brother!
In addition to "unix" languages, the Matlabs and Maples of the world
could use a reasonable --or at least sane-- execution semantics.
--
John Baugh
j...@eos.ncsu.edu
Peter da Silva
David Chase <ch...@Think.COM> wrote:
> But Lisp could have better syntax.
I like TCL fine, but I strongly disagree with this. A lot of Lisp's strengths
are *due* to its unconventional syntax (as is the case with Forth, SmallTalk,
Logo, PostScript, and, yes, TCL).
I just wish Lisp didn't have all these *other* syntaxes for arrays and macros
and everything else layered on top of it. I want Lisp 1.5, damnit.
(Peter shows his age again)
Scheme looks better, these days.
Martin Rodgers
mul...@simulog.fr "Christophe Muller" writes:
> For this reason, a religious war between Lisp and Tcl is pointless, they
> will certainly *both* have more and more adepts, and C/Fortran/Cobol less.. at
> least I hope.. :-)
Agreed. Nobody will ever "prove" one language is "better" than another.
All they'll do is convince people (like me) that there are a few more
fanatics that support language X than language Y. That's hardly an
attractive feature.
Nicolas M Williams
A neat experimental language that is in some ways similar to lisp is
Icon. It is built on the concepts of success/failure (instead of
true/false boolean values), generators and control backtracking. It is
also a very functional language, about the only lisp-like features it
is missing are lambda expressions, quote and and a simple syntax
(although all expressions except for assingments can be expressed in a
form that is very similar to lisp's s-expressions). It's greatest
strength lies in text handling, though it is by no means a specialized
language. It also has most of the types that lisp has and there is a
[relatively] simple way to write variants of it (there's an
object-oriented variant for example).
Icon also has a graphics library that makes graphics programs written
in it fairly portable accross platforms and OS's.
Icon can be obtained from ftp://cs.arizona.edu/icon/ and the newsgroup
for it is comp.lang.icon.
Nick
Mike Gallo
mul...@simulog.fr "Christophe Muller" writes:
>
> For this reason, a religious war between Lisp and Tcl is
> pointless, they will certainly *both* have more and more
> adepts, and C/Fortran/Cobol less.. at least I hope.. :-)
Actually, a religious war needs no point.
--
The more I get to know people, the more I like my dog.
Wolfgang Lux
|> Icon ... is
|> also a very functional language, about the only lisp-like features it
|> is missing are lambda expressions, quote and and a simple syntax
|> (although all expressions except for assingments can be expressed in a
|> form that is very similar to lisp's s-expressions).
lisp. Should it be true that Icon has no way of representing anonymous
functions?
Wolfgang
--
Wolfgang Lux
WZH Heidelberg, IBM Germany IBM IP-Net: l...@rio.heidelbg.ibm.com
+49-6221-59-4546 VNET: LUX at HEIDELBG
+49-6221-59-3300 (fax) EARN: LUX at DHDIBMIP
Bennett Todd
>|> it difficult to think of a job for which Tcl is the best tool.
>|> Perhaps someone could make a list?
As Michael Tiller said, one things TCL/Tk is excellent at is quickly
implementing small GUIs --- particularly GUI front-ends to non-GUI
applications. And that's an excellent model for general programming; don't
put any substantial, complex functionality into a GUI program if you can
help it; instead, write substantive command-line-driven programs, and GUI
front-ends. Improves code-reusability, modularity, regression testing, and
so on.
What's more, it helps set a precedent. As recently as a few years ago,
people were willing to stand up in public and claim that C (or C++) was the
only acceptable application development language. Within the last couple of
years Perl has forced its way in as another acceptable language, but somehow
most of those same people now want to try to say that C (or C++) and Perl
are the only two acceptable languages. So write your next application in
TCL/Tk. Then the one after that in Python. Then find a little Scheme, add
some dynamic loading, and create your own language for the next one. Use a
different language for every project until they get the point that chosing
the right language for the job is part of the design process, and can be
revisited _ab_initio_ for each new design.
-Bennett
b...@sbi.com
Henry G. Baker
>mul...@simulog.fr (Christophe Muller) writes:
>|> Lisp is not dead.
>
>|> I think Lisp _and_ Tcl, and Perl etc.. will have more and more fields of
>|> applications, it's just a matter of increasing CPU power and of ratio
>|> hardware cost vs engineer cost (is this a fact that we could all agree on? :-).
>
>But Lisp could have better syntax.
The whole point of Lisp syntax is that it is trivial, and doesn't require
a full-blown parser to interpret. Unfortunately, Common Lisp's parameter
syntax completely blew that particular advantage.
Improving the 'syntax' of a language is a little like climbing a tree
to make the first step towards the moon. It doesn't accomplish very
much, but it's easy and accessible and allows one to feel superior to
those still standing on the ground. In most cases, people would be
better off dispensing with character-based languages completely (e.g.,
for graphical languages), rather than wasting everyone's time creating
additional parsing and training nightmares.
Is the syntax of Lotus 1-2-3 macros really that brilliant, that it deserves
all of the brainpower wasted on it?
After tripping over all the minor syntactic incompatibilities of Fortran,
PL/I, Pascal, C, Ada, ..., I'm sick to death of the whole syntactic mess.
Proponents of syntactic sugar keep claiming their languages are more
'readable', but this presumes that users want to waste time reading
their silly 500-page manuals in the first place. I'm sure that
Persian and Finnish are 'readable' to their natives, too, but that
doesn't mean that they are 'readable' to anyone else.
>On the other hand, all these other
>little languages could have better semantics. For some time it has been
>a pet peeve of mine that people inventing little languages, with their
>syntax appropriate-to-task/audience, seem to feel it is necessary to badly
>re-invent execution semantics. It-would-be-nice if people would take a
>little bit of trouble to layer their new syntax on top of (for instance)
>Scheme, or an interpreter built in that (continuation-passing) style (it's
>NOT HARD, DAMMIT!)
Agreed, but I think that Lisp people have ignored for too long what the
users really want/need. Some of the things they want:
* the advantages of an integrated system with both compiled & interpreted code
* the ability to construct strict (file) and lazy (Unix stream)
compositions of existing functions
* the ability to explicitly control resource usage (GC hides too much)
without creating dangling references
* the ability to encapsulate nearly anything within a protocol-conversion
wrapper
* a powerful defaulting mechanism that isn't based on _state_ and
_state variables_. (This is probably one of the most important
problems facing the functional language community.)
>And, there are those little languages with inferior syntax, which could just
>as well be replaced by Scheme with a few appropriate primitives. Here, I'm
>thinking of the "languages" used to program sendmail and adb.
>
>Then again, it seems to be the norm in Computer "Science" to step on toes
>instead of stand on shoulders. Carry on.
Progress in most fields requires a throwing away of paradigms that
bind and constrict. Perhaps it is time to stop teaching students how
to parse, so they can focus on more worthwhile pursuits?
Joseph H Allen
Henry G. Baker <hba...@netcom.com> wrote:
>In article <31377d...@early-bird.think.com> ch...@Think.COM (David Chase) writes:
>>But Lisp could have better syntax.
>The whole point of Lisp syntax is that it is trivial, and doesn't require
>a full-blown parser to interpret. Unfortunately, Common Lisp's parameter
>syntax completely blew that particular advantage.
I agree. Common lisp is hopeless. Its standard manual is longer than that
of _every_ _other_ programming language and its syntax diverged from the
lisp ideal since the introduction dotted-pairs and ' for quoting. Perhaps
ideal lisp is not powerful or convenient enough for a real language.
>Improving the 'syntax' of a language is a little like climbing a tree
>to make the first step towards the moon. It doesn't accomplish very
>much, but it's easy and accessible and allows one to feel superior to
>those still standing on the ground.
Language syntax is related to style, in the graphic arts sense. It is
important for readability and can guide programming methodology. It helps
programmers remember language syntax and provides historic continuity.
Ideal-Lisp syntax may be trivial but it is not very nice looking. Why do
you think that algorithms in every non-lisp computer journal are printed in
pseudo-Algol-60?
>Is the syntax of Lotus 1-2-3 macros really that brilliant, that it deserves
>all of the brainpower wasted on it?
I don't know what you mean by this. Like lisp, Lotus 1-2-3 macro syntax is
trivial, but also like lisp, it's terrible looking.
>After tripping over all the minor syntactic incompatibilities of Fortran,
>PL/I, Pascal, C, Ada, ..., I'm sick to death of the whole syntactic mess.
Lisp isn't so wonderful in this respect either. Although the syntax, in the
strictest sense of the word, is trivial, the language is big, redundant and
non-uniform.
For example, 'setf' takes list of pairs which don't need to be enclosed:
(setf a 10 b 20 ... ), but then structures, which could also have this
syntax, require parenthesis around its pairs: (defstruct foo (a 3) (b 4)...).
Then there's: set, setq and setf; eq, eql and equal; and let, let*, letrec
and declare. Not to mention: cond and if; do, do*, and dotimes; and
array-dimension, initialize-instance, multiple-value-bind and
with-input-from-string.
>Proponents of syntactic sugar keep claiming their languages are more
>'readable', but this presumes that users want to waste time reading
>their silly 500-page manuals in the first place.
Which programming language has a 500-page manual? Only common lisp. Even
the manuals for PL/I, Ada and Algol-68 are shorter.
>I'm sure that
>Persian and Finnish are 'readable' to their natives, too, but that
>doesn't mean that they are 'readable' to anyone else.
I suppose you'd like them to convert to esperanto.
>>On the other hand, all these other
>>little languages could have better semantics. For some time it has been
>>a pet peeve of mine that people inventing little languages, with their
>>syntax appropriate-to-task/audience, seem to feel it is necessary to badly
>>re-invent execution semantics. It-would-be-nice if people would take a
>>little bit of trouble to layer their new syntax on top of (for instance)
>>Scheme, or an interpreter built in that (continuation-passing) style (it's
>>NOT HARD, DAMMIT!)
>Agreed, but I think that Lisp people have ignored for too long what the
>users really want/need. Some of the things they want:
I agree too, most languages could use better semantics. But they don't need
lisp's syntax.
>>And, there are those little languages with inferior syntax, which could just
>>as well be replaced by Scheme with a few appropriate primitives. Here, I'm
>>thinking of the "languages" used to program sendmail and adb.
I don't see what's so great about scheme. Constructs such as
(call-with-current-continuation name (body)) certainly don't encourage the
use of it's powerful semantic capability.
The major semantic paradigms present in scheme/lisp are:
1 Closures
2 Loops through tail-recursion and lambda functions
3 Type inference
4 Self-representation through common list syntax
1 is the most important one, and is syntacticly possible with other
languages. Most functional languages have closures. Other static languages
don't have them because they do not sit well with stack-based local
variables. For a non-lisp and non-functional language with closures, try my
language Ivy.
2 and 3 are not necessary, hurt readability and can be considered semantic
sugar.
4 is the only one which is really unique to lisp. It's made redundant by 1
though, so I don't miss it.
--
/* jha...@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
rodrigo vanegas
Finally, this long thread has reached the heart of what i believe to
be the principal reason why we can't do without lisp.
In article <Ctu43...@world.std.com>, jha...@world.std.com (Joseph H Allen) writes:
> The major semantic paradigms present in scheme/lisp are:
> 1 Closures
> 2 Loops through tail-recursion and lambda functions
> 3 Type inference
> 4 Self-representation through common list syntax
> 1 is the most important one, and is syntacticly possible with other
> languages. Most functional languages have closures. Other static languages
> don't have them because they do not sit well with stack-based local
> variables. For a non-lisp and non-functional language with closures, try my
> language Ivy.
1) ML also meets this criteria. It is an impure functional language
(meaning it has assignment which is all you need to program as you
would in C), and has a pleasant non-lisp syntax.
> 2 and 3 are not necessary, hurt readability and can be considered semantic
> sugar.
2) On the contrary, using tail-recursion allows one to use the return
values of each iteration to accumulate final values. (Mail me if you
want an example.) This is not possible with WHILE or FOR loops in
C/Pascal. Although, i admit that the paren-syntax is annoying, i
still prefer to program loops with tail recursion.
3) Type inference in Lisp? This is new to me. (Someone please
enlighten me here.)
> 4 is the only one which is really unique to lisp. It's made redundant by 1
> though, so I don't miss it.
4) But this is the ultimate reason why LISP is still indispensably
unique. Lisp's macros and ultra-flexible syntax have made it the
hot-bed of language research for many many years and continues to play
that role today. (Consider MOP, CLOS, CL Condition System, and
syntax-case for Scheme.) It's not made redundant by closures at all.
You still need the macros which can manipulate code as data
self-referentially.
Even so, i will concede without prompting,that if one is not
interested in either higher-order functions or language
experimentation, the lisp parentheses become only a nuisance and
Common Lisp's size just an obstacle to delivery.
rodrigo vanegas
r...@cs.brown.edu
Henry G. Baker
>In article <hbakerCt...@netcom.com>,
>Henry G. Baker <hba...@netcom.com> wrote:
>>In article <31377d...@early-bird.think.com> ch...@Think.COM (David Chase) writes:
>>>But Lisp could have better syntax.
>
>>The whole point of Lisp syntax is that it is trivial, and doesn't require
>>a full-blown parser to interpret. Unfortunately, Common Lisp's parameter
>>syntax completely blew that particular advantage.
>
>I agree. Common lisp is hopeless. Its standard manual is longer than that
>of _every_ _other_ programming language and its syntax diverged from the
>lisp ideal since the introduction dotted-pairs and ' for quoting. Perhaps
>ideal lisp is not powerful or convenient enough for a real language.
I think a quick perusal would show that most languages are happy with syntax
_trees_. Lisp S-expressions are general trees. QED
>>Improving the 'syntax' of a language is a little like climbing a tree
>>to make the first step towards the moon. It doesn't accomplish very
>>much, but it's easy and accessible and allows one to feel superior to
>>those still standing on the ground.
>
>Language syntax is related to style, in the graphic arts sense. It is
>important for readability and can guide programming methodology. It helps
>programmers remember language syntax and provides historic continuity.
God save us from language designers who want to impose their own personal
styles on all their users. The problem is that programming styles change
rather more rapidly than languages do, leaving the programs and programmers
of the 'I know what's best for you' languages high and dry.
>Ideal-Lisp syntax may be trivial but it is not very nice looking. Why do
>you think that algorithms in every non-lisp computer journal are printed in
>pseudo-Algol-60?
And how nice looking is the numerical program in pseudo-Algol that has
to first symbolically differentiate its functional argument, before
compiling and executing it?? Lisp syntax is ideal for programs which
must analyze and/or compose other programs. Since this is one of the
most powerful software levers available, languages which make this
difficult are guaranteeing poor productivity.
As to the pseudo-Algol-60 algorithms in computer books and
journals--it's truly a shame that Knuth never really got into Lisp.
His books would be _more_ readable, and TeX might actually have been a
decent language. Sigh...
>Lisp isn't so wonderful in this respect either. Although the syntax, in the
>strictest sense of the word, is trivial, the language is big, redundant and
>non-uniform.
>
>For example, 'setf' takes list of pairs which don't need to be enclosed:
>(setf a 10 b 20 ... ), but then structures, which could also have this
>syntax, require parenthesis around its pairs: (defstruct foo (a 3) (b 4)...).
>
>Then there's: set, setq and setf; eq, eql and equal; and let, let*, letrec
>and declare. Not to mention: cond and if; do, do*, and dotimes; and
>array-dimension, initialize-instance, multiple-value-bind and
>with-input-from-string.
Touche' ! (I'll have to send you a copy of my article "If it ain't Baroque,
fix it!")
>>Proponents of syntactic sugar keep claiming their languages are more
>>'readable', but this presumes that users want to waste time reading
>>their silly 500-page manuals in the first place.
>
>Which programming language has a 500-page manual? Only common lisp. Even
>the manuals for PL/I, Ada and Algol-68 are shorter.
The PL/I manual that I used was many more than 500 pages. Algol-68 is
shorter, but only because it appears to have been LZ-compressed and
therefore incomprehensible. The Ada83 manual is shorter, but you then need
the Commentaries and the Congressional Record to figure out what the manual
says.
Look at the computer books in your nearby Bookstar. Of course, the chatty
style, the double spacing, and those silly small-format pages do a lot to
create 500++ page books.
>The major semantic paradigms present in scheme/lisp are:
>
>1 Closures
>2 Loops through tail-recursion and lambda functions
>3 Type inference
>4 Self-representation through common list syntax
>
>1 is the most important one, and is syntacticly possible with other
>languages. Most functional languages have closures. Other static languages
>don't have them because they do not sit well with stack-based local
>variables. For a non-lisp and non-functional language with closures, try my
>language Ivy.
>
>2 and 3 are not necessary, hurt readability and can be considered semantic
>sugar.
If you think that anonymous lambda functions _hurt_ readability, I'd like to
sell you some continuation-passing code which is written in Pascal/Ada style.
Now _that_ really hurts the eyes.
??????????? 'Type inference' _hurt_ readability?? Perhaps you meant type
declarations?
Joseph H Allen
I don't know Ada, but I agree, emulating continuations with Pascal is awful
(you have to pass a record via a global variable). Now if Pascal had
continuations, (and function pointers) it would be fairly nice, even without
lambda functions:
function foo():function;
var ...
begin
... (* code which sets vars *)
function bar(x:real):real;
begin
...
end.
some_proceedure(bar); (* call with continuation *)
foo:=bar; (* return with continuation *)
end.
>??????????? 'Type inference' _hurt_ readability?? Perhaps you meant type
>declarations?
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. Likewise, structures (records) are better than
lists and tuples.
Joseph H Allen
rodrigo vanegas <r...@cs.brown.edu> wrote:
>Finally, this long thread has reached the heart of what i believe to
>be the principal reason why we can't do without lisp.
>In article <Ctu43...@world.std.com>, jha...@world.std.com (Joseph H Allen) writes:
>> The major semantic paradigms present in scheme/lisp are:
>
>> 1 Closures
>> 2 Loops through tail-recursion and lambda functions
>> 3 Type inference
>> 4 Self-representation through common list syntax
>> 1 is the most important one, and is syntacticly possible with other
>> languages. Most functional languages have closures. Other static languages
>> don't have them because they do not sit well with stack-based local
>> variables. For a non-lisp and non-functional language with closures, try my
>> language Ivy.
>1) ML also meets this criteria. It is an impure functional language
>(meaning it has assignment which is all you need to program as you
>would in C), and has a pleasant non-lisp syntax.
Yeah, ML's pretty nice.
>> 2 and 3 are not necessary, hurt readability and can be considered semantic
>> sugar.
>2) On the contrary, using tail-recursion allows one to use the return
>values of each iteration to accumulate final values. (Mail me if you
>want an example.) This is not possible with WHILE or FOR loops in
>C/Pascal.
Yes it is:
while(!context.done) context=function(context);
or if you have continuations (or are using global variables):
declare context;
function()
{
operate on context;
}
while(!done) function();
Any function which is strictly tail recursive can be directly expanded this
way. More general recursive functions can't:
LIST slow_reverse(LIST a)
{
LIST b=a->next;
if(b) return a->next=0, append(slow_reverse(b),a);
else return a;
}
IMHO, loop structures should be used in place of tail recursion for
readability. Recursion should, of course, still be possible.
>3) Type inference in Lisp? This is new to me. (Someone please
>enlighten me here.)
It's not guarenteed to infer the type of everything, but lisp optimizing
compilers sure try. The more that can be inferred, the more that can be
optimized.
>> 4 is the only one which is really unique to lisp. It's made redundant by 1
>> though, so I don't miss it.
>4) But this is the ultimate reason why LISP is still indispensably
>unique. Lisp's macros and ultra-flexible syntax have made it the
>hot-bed of language research for many many years and continues to play
>that role today. (Consider MOP, CLOS, CL Condition System, and
>syntax-case for Scheme.) It's not made redundant by closures at all.
>You still need the macros which can manipulate code as data
>self-referentially.
I should have said 'nearly redundant' :-)
Simple macros can be more powerful in lisp than in any other language and
rather easily lead to parameterized classes and other syntax augmentations.
You can also do neat things like easily take the derivatives of mathematical
functions expressed in lisp. But then I don't want to express my functions
in lisp :-) A simple precidence parser is only about a hundred lines long in
any other language, so it's not that big of a deal to use lists for
representation, and infix/prefix for data entry and display.
>Even so, i will concede without prompting,that if one is not
>interested in either higher-order functions or language
>experimentation, the lisp parentheses become only a nuisance and
>Common Lisp's size just an obstacle to delivery.
Lisp is a neat idea, but to gross to use in practice.
Nick Williams
Wolfgang Lux <l...@rio.heidelbg.ibm.com> wrote:
>In article <1994Jul28.0...@cs.rit.edu>, nmw...@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?
All expressions in Icon produce results (i.e. there is no such thing as
a void typed functions as in C or CL). It also has apply/funcall like
expressions. Pointer semantics abound and there is no way to pass
pointers-to-pointers to functions (i.e. no quote function). All of which
makes Icon a heck of a lot more of a strict functional language than is
CL, though it does have variable assignment expressions, as well as
destructive functions and though it does not have lambda expressions. It
does have a feature that comes close to lambda expressions and which its
authors call "co-expressions;" these co-expressions are co-routines that
can be created more or less dynamically from regular Icon expressions.
Perhaps you should take a look at the introduction to Icon that can be
found in cs.arizona.edu:/icon/doc/tr-90.6.doc (also tr-90.6.ps.Z). Its
quite short...
>Wolfgang
>--
>Wolfgang Lux
>WZH Heidelberg, IBM Germany IBM IP-Net: l...@rio.heidelbg.ibm.com
>+49-6221-59-4546 VNET: LUX at HEIDELBG
>+49-6221-59-3300 (fax) EARN: LUX at DHDIBMIP
Nick
Henry G. Baker
>>??????????? 'Type inference' _hurt_ readability?? Perhaps you meant type
>>declarations?
>
>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. Likewise, structures (records) are better than
>lists and tuples.
Aha! We've finally smoked you out! What you are complaining about is
the lack of a good code browser which would tell you what a compiler
knows about the various constructs that it sees. Rather than have to
specify all this redundancy every time I write a program, wouldn't it
be better to have the program tell me what it thought? This would be
a much better tradeoff in terms of my time vs. the computer's time.
For what it's worth, such a code browser is much easier to write, due
to (you guessed it) Lisp's trivial syntax.
Thomas M. Breuel
|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.
Thomas M. Breuel
|
|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.
Marco Antoniotti
In article <RV.94Au...@tahoe.cs.brown.edu>,
rodrigo vanegas <r...@cs.brown.edu> wrote:
>Finally, this long thread has reached the heart of what i believe to
>be the principal reason why we can't do without lisp.
>In article <Ctu43...@world.std.com>, jha...@world.std.com
(Joseph H Allen) writes:
>> The major semantic paradigms present in scheme/lisp are:
>
>> 1 Closures
>> 2 Loops through tail-recursion and lambda functions
>> 3 Type inference
>> 4 Self-representation through common list syntax
>> 1 is the most important one, and is syntacticly possible with other
>> languages. Most functional languages have closures. Other
>> static languages
>> don't have them because they do not sit well with stack-based local
>> variables. For a non-lisp and non-functional language with
>> closures, try my
>> language Ivy.
>1) ML also meets this criteria. It is an impure functional language
>(meaning it has assignment which is all you need to program as you
>would in C), and has a pleasant non-lisp syntax.
Yeah, ML's pretty nice.
Except when you FORGET parenthesis! :-) The operator precedence rules
are so contrived that you end up stuffing the code with parenthesis
just to play it safe. :-)
>> 2 and 3 are not necessary, hurt readability and can be
>> considered semantic
>> sugar.
...
IMHO, loop structures should be used in place of tail recursion for
readability. Recursion should, of course, still be possible.
It is the nature of data that makes recursion more suitable than loops
and vice versa.
...
I should have said 'nearly redundant' :-)
Simple macros can be more powerful in lisp than in any other language and
rather easily lead to parameterized classes and other syntax augmentations.
You can also do neat things like easily take the derivatives of mathematical
functions expressed in lisp. But then I don't want to express my functions
in lisp :-) A simple precidence parser is only about a hundred lines long in
any other language, so it's not that big of a deal to use lists for
representation, and infix/prefix for data entry and display.
Have you tried the 'infix.lisp' package from the AI-repository?
>Even so, i will concede without prompting,that if one is not
>interested in either higher-order functions or language
>experimentation, the lisp parentheses become only a nuisance and
>Common Lisp's size just an obstacle to delivery.
Lisp is a neat idea, but to gross to use in practice.
As is ML, Haskell, Miranda, Prolog and I would add FORTRAN, COBOL,
PL/I and, last but not least, C/C++.
So much for the daily religion wars :)
Happy Lisping
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: mar...@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
David J. Hughes
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 - Ba...@Bond.edu.au
/ \ / / / http://Bond.edu.au/People/bambi.html
/___/ __ _ ____/ / / _
/ \ / \ / \ / / / / / \ / Senior Network Programmer, Bond University
\___/ \__// / \__/ \__/ / / / Qld. 4229 AUSTRALIA (+61 75 951450)
Richard Mlynarik
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.
Hendrik Boom
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.
Tim Bradshaw
> 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
Trevor Blackwell
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 t...@das.harvard.edu (617) 495-8912
(info and words of wit in my .plan)
Disclaimer: My opinions.
Piercarlo Grandi
>>> said:
Henry> In article <CtuG1...@world.std.com> jha...@world.std.com
Henry> (Joseph H Allen) writes:
hbaker> ??????????? 'Type inference' _hurt_ readability?? Perhaps you
hbaker> meant type declarations?
jhallen> IMHO, except for trivial programs, declarations improve
jhallen> readability because you can easily figure out what is stored in
jhallen> variables and arguments and don't have to trace constants or
jhallen> depend on operators not being overloaded. You can jump into
jhallen> the middle of a program and start modifying it without
jhallen> comprehending all of it.
A very dangerous attitude indeed, in the general case. And where it
works it has nothing to do with the manifest/latent or static/runtime
typing issue, it can be done because the program is well modularized.
jhallen> It makes your programs less general perhaps, but definitly more
jhallen> readable. Likewise, structures (records) are better than lists
jhallen> and tuples.
Agreed, lists and tuples are too general.
Henry> Aha! We've finally smoked you out! What you are complaining
Henry> about is the lack of a good code browser which would tell you
Henry> what a compiler knows about the various constructs that it sees.
Aha! We've finally smoked you out! You don't believe that programs are
about _communication_, i.e. texts that describe what the author
thinks. If you did, any extra annotations by the author are welcome,
because they enlighten the reader as to the assumptions of the author.
When I read a program I want to understand not what it does (using a
browser or a tracer), but what the author wanted to communicate with
it. _Then_ I shall check that the intent was correctly implemented.
When I see "const x" or "pure y", what I think is not "ah, a read-only
variable", I think "the author assumes that there will be no need to
change this variable's value". When I see "reducible proc p" I know that
in the author's intent the procedure's result only depends on its
arguments.
This is much more informative than just having a browser telling me
whether in fact a variable is or is not modified in a region of code
(and find a browser that will tell you whether a procedure is
reducible!). Of course I want the latter information too... But not
just that. I want to compare intent with actuality.
Henry> Rather than have to specify all this redundancy every time I
Henry> write a program, wouldn't it be better to have the program tell
Henry> me what it thought?
This redundancy is actually descriptive statements of the author's
intent. Communication, useful communication, about design choices. A
browser will not tell me anything about design choices, will only tell
me about what's there, not in the mind of the author.
Henry> This would be a much better tradeoff in terms of my time vs. the
Henry> computer's time. For what it's worth, such a code browser is
Henry> much easier to write, due to (you guessed it) Lisp's trivial
Henry> syntax.
But I still want the author's annotations, perhaps compared to the
annotations synthetized by a browser.
All this assuming that the author agrees that the purpose of a program
text is to communicate a description to the reader, and puts in
descriptive annotations. A rare thing!
Jurgen Botz
Joseph H Allen <jha...@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
>
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, jb...@mtholyoke.edu | Communications security is too important to
Northampton, MA, USA | be left to secret processes and classified
| algorithms. -- USACM
Ted Dunning
In article <PIERCARL.9...@sabi.sabi.demon.co.uk> pier...@sabi.demon.co.uk (Piercarlo Grandi) writes:
Henry> Rather than have to specify all this redundancy every time I
Henry> write a program, wouldn't it be better to have the program
Henry> tell me what it thought?
This redundancy is actually descriptive statements of the author's
intent. Communication, useful communication, about design choices.
A browser will not tell me anything about design choices, will only
tell me about what's there, not in the mind of the author.
what if my intent is to write a generalized and polymorphic procedure?
don't all those required type declarations get in the way of my
intent?
Bennett Todd
Richard Mlynarik <m...@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
b...@sbi.com
Mark Kilgard
|> * 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.
|>
|> 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
Tim Bradshaw
> 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
Joseph H Allen
It depends on the language. You could have a language which lets you
specify that a variable or function argument is any type, one of a set of
types (a union or ML style polymorphic type) or a type of a certain class.
The class method is particularly useful because then you could have any type
which has the proper attributes inherit the class specified for the argument
or variable. The class name is then used for classifying which types are
allowed. You could conceive of a system where integers are in the
whole-number class, the integer-class, and the exact-class, while floats are
in both the whole-number and integer-classes and additionally the
real-class, but not in the exact class.
A debate going on in other newsgroups is "sub-typing vs. sub-classing".
Some think that a value of certain type should be usable in a variable if
the class specified for the variable has method names which are the same as
those of the class of the type. This eliminates the need for inheritance
but I think it also prevents you from using class names as general attribute
specifiers. I would be happier with the sub-classing idea if you had method
names which did nothing but indicate the presence of certain properties that
the type has.
Thomas M. Breuel
|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.
Bryan O'Sullivan
>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: b...@cyclic.com, b...@dcs.gla.ac.uk
University of Glasgow web.gunge: http://www.scrg.cs.tcd.ie/~bos
Chris Gray
--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 c...@myrias.ab.ca [C macros - a powerful way to make bugs!]
Myrias Computer Technologies Inc. (403) 463-1337
Henry G. Baker
>* 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.
Henry G. Baker
I thought that adding cruft and complexity was the role of the ANSI/IEEE
standardization committee. :-)
Amancio Hasty Jr
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 ha...@netcom.com | ftp-site depository of all my work:
| sunvis.rtpnc.epa.gov:/pub/386bsd/X
Steven D. Majewski
>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) <sd...@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics
Ted Dunning
In article <Cu8nv...@murdoch.acc.Virginia.EDU> sd...@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.
Larry W. Virden
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: lvi...@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.
Stephen David Wray
> "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 :-)
Eyvind Ness
;; 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?
Richard A. O'Keefe
>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.
s...@sef-pmax.slisp.cs.cmu.edu
From: ma...@deshaw.com (Matthew Newman)
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...
I find TCL syntax confusing and clumsy, in the way that most Unix shells
are confusing and clumsy. I don't have time to explain what I mean by that
in detail, so feel free to consider it a cheap shot, but I've heard others
express the same opinion. I find Lisp -- even common Lisp -- much more
elegant. OK, maybe I've been living in Lisp too long to see all its flaws.
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.
Bullfeathers! We are decades *ahead* of where we might have been because
we fight amongst ourselves. A vigorous debate is the best way to make
progress. Agreeing to settle on a comfortable, shared mediocrity is death
to any field.
I will admit that usenet debates are often a waste of time -- all it takes
is a few people being noisily uninformed to drag things down, especially if
they cross post to newsgroups they don't read. (BTW, I am sending this
only to comp.lang.lisp, which I read.)
-- Scott
===========================================================================
Scott E. Fahlman Internet: se...@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213
===========================================================================
Matthew Newman
>In article <TFB.94Au...@burns.cogsci.ed.ac.uk> t...@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!).
Chris Gray
... 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?
Jeff Dalton
>> 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.
Marcus Daniels
>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.
ozan s. yigit
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. :-]
Matt Kennel
: ;; 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 c...@myrias.ab.ca [C macros - a powerful way to make bugs!]
: Myrias Computer Technologies Inc. (403) 463-1337
--
-Matt Kennel m...@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 Bitmead
> --tim
>versus:
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.
Jeff Dalton
>In article <7763623...@myrias.ab.ca> c...@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)
)
Mike Gallo
// > 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.
Larry W. Virden
> 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!
Erik Naggum
| 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.
Trevor Blackwell
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 t...@das.harvard.edu (617) 495-8912
(info and words of wit in my .plan)
Disclaimer: My opinions.
rodrigo vanegas
> 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
r...@cs.brown.edu
Raul Deluth Miller
. % 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
<rock...@nova.umd.edu> NB. public e, n, y
y =: n&|&(*&x)^:e 1
x -: n&|&(*&y)^:d 1 NB. 1 < (d*e) +.&<: (p,q)
Jeff Dalton
>Joseph H Allen <jha...@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
Jim McDonald
|> 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 mcdo...@kestrel.edu
3260 Hillview Ave. (415) 493-6871 ext. 339
Palo Alto, CA 94304 fax: (415) 424-1807
Jeff Dalton
>
>In article <CuDn...@cogsci.ed.ac.uk>, je...@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.
ch...@labs-n.bbn.com
--> In article <1994Aug13.2...@kestrel.edu> mcdo...@kestrel.edu (Jim McDonald) writes:
--> >
--> >In article <CuDn...@cogsci.ed.ac.uk>, je...@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.
well, in Allegro 4.2, COND (to my surprise) expands into IF/THEN/ELSE
nestings.
CLtL2 says it's a macro. my Explorer says it's a function. I could swear
that some years ago it was a macro on the Explorer and that it expanded
into some rats-nest of tagbody and GO and stuff like that...
-- clint
Christophe Muller
> In article <CuL4x...@cogsci.ed.ac.uk> je...@aiai.ed.ac.uk (Jeff Dalton) writes:
> --> In article <1994Aug13.2...@kestrel.edu> mcdo...@kestrel.edu (Jim McDonald) writes:
> --> >
> --> >In article <CuDn...@cogsci.ed.ac.uk>, je...@aiai.ed.ac.uk (Jeff Dalton) writes:
> --> >...
[...] (about Lisp COND readability, whether it's a function or a macro etc..)
Maybe it's time to stop now guys.. don't you think so?
Or at least, change the subject line, redirect to comp.lang.lisp, continue by
email, I don't know, DO SOMETHING! :-)
Cheers,
Christophe.
= Are you the police? -- No ma'am, we're musicians. =
John Styles
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
Jay Sekora
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 j...@bu.edu
BU Information Technology (MIME ok)
111 Cummington Street
Boston, MA 02115 +1 617 353 2780
Peter.DeRijk
: 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
Mike Suzio
>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 msu...@tiamat.umd.umich.edu |
| Marketing Director - Friday Knight Games |
| aka "That F*K*G company!" |
|+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
Peter da Silva
> 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?"
Marco Antoniotti
In article <1994Aug19.0...@reks.uia.ac.be> der...@reks.uia.ac.be (Peter.DeRijk) writes:
From: der...@reks.uia.ac.be (Peter.DeRijk)
Organization: U.I.A.
X-Newsreader: Tin 1.1 PL5
References: <777233...@aivis.demon.co.uk>
Date: Fri, 19 Aug 1994 09:56:16 GMT
Lines: 59
John Styles (jst...@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: mar...@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
Jeff Kotula
>John Styles (jst...@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 j...@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 kot...@camax.com
Camax Systems Inc. Speaking only for myself
-----------------------------------------------
Martin Brunecky
>Since we are at it... let's make some more noise.
>In article <1994Aug19.0...@reks.uia.ac.be> der...@reks.uia.ac.be (Peter.DeRijk) writes:
> '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 mar...@xvt.com (303)443-5130 ext 229 or 443-4223
Bennett Todd
In article <1994Aug22.1...@camax.com>,
Jeff Kotula <kot...@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
b...@sbi.com
S M Ryan
: 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 | smr...@netcom.com PO Box 1563
alyfan landes to fela lathere theode. | Cupertino, California
... ond lof-gearnost. | (xxx)xxx-xxxx 95013
Thomas M. Breuel
|> 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.
Geoff Lane
--
Geoff. Lane. | Internet: zza...@cs6400.mcc.ac.uk | Janet: zza...@uk.ac.mcc
CS6400 Sys Admin, Manchester Computing Centre, Oxford Rd, Manchester, M13 9PL
On a clear disk you can seek forever. -- Denning
Andre Beck
|> In article <1994Aug23.0...@xvt.com> mar...@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) Andre...@IRS.Inf.TU-Dresden.de | o |
+-o-+--------------------------------------------------------+-o-+
Bill Janssen
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 <jan...@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html
Andre Beck
|> In article <MARCOXA.94...@mosaic.nyu.edu>,
|> Marco Antoniotti <mar...@mosaic.nyu.edu> wrote:
|> > (setf a (+ b c))
|> > or
|> > (setf a #$ b+c $)
|> > Yes! Infix notation in Common Lisp!
|>
Anyone mentioned
/a b c add def
already ? I like stack languages, esp. PostScript ;)
Larry W. Virden
Nevin Liber <ne...@CS.Arizona.EDU> wrote:
:
:Actually, it is better if the "open quote" character is different than
:the "close quote" character (as David Korn did in ksh when he replaced
:the backquote `command` notation with the $(command) notation). It
:makes nesting much easier, without having to keep quoting (escaping) all
:the quoting symbols.
Don't you still have to quote a )?
$ a=$(echo This is a ) )
ksh: syntax error: `)' unexpected
$
Fernando Mato Mira
> In article <MARCOXA.94...@mosaic.nyu.edu>,
> Marco Antoniotti <mar...@mosaic.nyu.edu> wrote:
> > or
> > (setf a #$ b+c $)
> > Yes! Infix notation in Common Lisp!
>
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 mato...@epfl.ch
EPFL FAX: +41 (21) 693-5328
Phillip J. Windley
>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 | win...@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>.
Robert Sanders
>> Those who think it a waste of characters to introduce an explicit
>> name such as skip for the empty statement while "nothing" expresses
>> its semantics so eloquently, should realize that the decimal number
>> system was only possible thanks to the introduction of the character
>> "0" for the concept zero (_Discipline_ page 25).
> Although I don't like the empty string either, this seems like a silly
> reason. Then again, there are scripting languages out there which
> equate 0 with the empty string, much to the annoyance of its users (MPW
> for Macintosh). There is a distinct difference in concepts between 0
> and nothing.
I think that's the point; there was not a distinction between
nothing and the result of 1-1, and establishing one helped
mathematicians considerably. There should be a distinct difference
in concepts between a NOP and nothing.
> Only 354 more shopping days 'til my birthday (August 12th)!!
Um, speaking of concepts fundamental to mathematics... Maybe you
forgot to put the .sig-recalculator in your crontab?
-- Robert
Bill Gooch on SWIM project x7151
In article <WINDLEY.94...@jaguar.cs.byu.edu>, win...@cs.byu.edu (Phillip J. Windley) writes:
|>
|> In article <33di2b...@phage.cshl.org> wch...@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
|>
|> 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.