I thought that adding cruft and complexity was the role of the ANSI/IEEE
   standardization committee.  :-)

:      (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".

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.

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

        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 . . .  :-)

|   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.

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

  (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))

% 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.

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.

|> 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.

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...

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.

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.

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.

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.

   John Styles (jsty...@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: marc...@cs.nyu.edu

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...]

        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.

--

In article <1994Aug22.143416.29...@camax.com>,

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.

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.