Don't most languages use prefix notation? For example puts("type
your name."); seems quite similar to (print "type your name"). Why
is one prefix and the other something else? Prefix notation is also
common in English. We say "Put the letter in the slot" not "letter
put slot." Or "the letter put in the slot". I am puzzled by the
complaint that a drawback of Lisp is its use of prefix notation.
I agree that a complex math expression can be difficult in prefix,
but the same expression is usually difficult in infix as well.
* Origin: The Interocitor*AI/Robotics*214-258-1832 (1:124/2206)
···············@f2206.n124.z1.fidonet.org (Michael Fleming) writes:
Don't most languages use prefix notation? For example puts("type
your name."); seems quite similar to (print "type your name"). Why
is one prefix and the other something else? Prefix notation is also
common in English. We say "Put the letter in the slot" not "letter
put slot." Or "the letter put in the slot". I am puzzled by the
complaint that a drawback of Lisp is its use of prefix notation.
I agree that a complex math expression can be difficult in prefix,
but the same expression is usually difficult in infix as well.
* Origin: The Interocitor*AI/Robotics*214-258-1832 (1:124/2206)
(a) Imperatives in English are prefix, but declarative sentences are
infix (degnerating to postfix when there's no second argument); ``I
drink tea'', ``She abhores jazz'', ``This is an aardvark'', ``I swim''.
(b) In any case, ``infix'' is rather a weak term, sicne many
(programming) language structures ae mixfix; if-then-else-(endif),
while-do-(endwhile), etc, as well as providing infix operators.
(c) Infix operators are not confined to the usual mathematical ones;
consulting a piece of code I've just de-iconised, I see the following
infixes:
. x.f, evaluate x and apply f to it
->> val ->> var, assign and preserve value
-> val -> var, assign, don't preserve value
== x == y, x is-identical-to y (test)
/== x /== y, x isn't the same thing as y
:: x :: y, list with head x and tail y
> x > y, numeric greater-than
- x - y, numeric subtraction
+ x + y, numeric addition
>< x >< y, turn into strings and concatenate
*I* find ``x == y'' easier to read than ``(== x y)'' or ``(eq x y)'',
and at this point Your Kilometerage May Vary.
--
Regards | "Always code as if the guy who ends up maintaining your code will be
Kers. | a violent psychopath who knows where you live." - John F. Woods
Date: Wed, 27 Jan 1993 05:22 EST
From: Chris Dollin <····@hplb.hpl.hp.com>
*I* find ``x == y'' easier to read than ``(== x y)'' or ``(eq x y)'',
and at this point Your Kilometerage May Vary.
You hit the nail on the head when you said "*I* find". The only
reasonable conclusion one can draw about this bickering over syntax is,
that it is pointless. What syntax people prefer is a matter of taste.
I believe that an important point that is being lost in the shuffle is
whether or not the language is malleable enough to provide "control
abstraction" (analogous to the way classes, structures, etc., provide
data abstraction). If the language cannot provide good control
abstraction, then *it's not good enough*. (Of course, the lack of
control abstraction does not render a language useless any more than the
lack of data abstraction does -- it just makes life much more difficult
than it needs to be, and really, isn't programming is hard enough
already?)
In my opinion, almost every modern programming language fails to provide
control abstraction. One reason Lisp manages to provide it is that the
syntax of the language makes it easy to use Lisp as its own meta-
language. There are other ways to do this (e.g., add features to the
language that allow the language to talk about its own parsed
representation), but to the best of my knowledge, there aren't any
languages that do this in any serious way.
From: Richard Fateman
Subject: COBOL is a mainstream language. So what? (was Re: Lisp vs English)
Date:
Message-ID: <1k6fec$9c8@agate.berkeley.edu>
Lisp is not a mainstream language, but COBOL is. Perhaps BASIC also.
(You may think C and Fortran are mainstream, but I'm not sure how
you are measuring.) COBOL is, in some ways being replaced by
"4th generation languages". Not by C or C++. Certainly not by LISP.
How come?
1. COBOL is standardized. (CL is getting that way, maybe.)
2. COBOL is or was a required language for US gov't procurement.
3. COBOL became the defacto standard for a commercially important segment
of the computer buying community because of 1 & 2.
4. It would be pointless to argue in this newsgroup about the relevant
syntax and semantics of COBOL vs. Lisp.
5. COBOL existed at the right time and place to fill a particular niche.
Not the niche filled by LISP, but a niche. LISP's niche is smaller,
perhaps.
How is it that people reading (or writing) here think that C is a mainstream
language?
Perhaps because they perceive that the niche for C programs is better
known and/or larger. What is that niche?
1. writing UN*X operating systems.
2. writing compilers, interpreters (including Lisp interpreters!), editors.
3. writing other low-to-middle level code that needs access to OS utilities
and should, itself, be useful as a utility (i.e. small in size).
4. (ugh) education, since some educators think that popular = good.
Some people would claim Fortran is a mainstream language (although
the number of people using COBOL totally swamps the Fortran community).
My argument here would be that there is a niche, and frankly, Fortran,
in its various versions, pretty much fills that niche as a (mostly batch)
numeric processing language.
Lisp pretty much fills its niche (competing perhaps with Prolog?, competing
amongst dialects? competing with C?)
If your idea of mainstreaming Lisp is that you should do something to
it so that it would invade other niches, I'm not sure how to do that,
but making it small/fast/efficient would make it more plausible.
Providing a front end for COBOL or a front end for C, which would
erase all syntactic or semantic differences (ugh!) does not seem like
a winning idea ...
Demonstrations of superiority in a niche -- the way the 4GLs are
displacing COBOL -- may be the way to broaden the appeal of CL...
Write truly great programs in Lisp to solve important and
widespread problems -- and rely on Lisp in such a way that the
program can't be rewritten in C "to save space/time/money..".
Symbolic mathematics programs like Macsyma and Reduce looked like this,
until people wrote similar systems in C (Maple, Mathematica).
--
Richard J. Fateman
·······@cs.berkeley.edu 510 642-1879
From: Marco Antoniotti
Subject: Re: COBOL is a mainstream language. So what? (was Re: Lisp vs English)
Date:
Message-ID: <MARCOXA.93Jan27145008@image.nyu.edu>
OK, I'll jump in!
In article <··········@agate.berkeley.edu> ·······@peoplesparc.Berkeley.EDU (Richard Fateman) writes:
Lisp is not a mainstream language, but COBOL is. Perhaps BASIC also.
(You may think C and Fortran are mainstream, but I'm not sure how
you are measuring.) COBOL is, in some ways being replaced by
"4th generation languages". Not by C or C++. Certainly not by LISP.
How come?
1. COBOL is standardized. (CL is getting that way, maybe.)
Common Lisp IS getting that way and EULISP too.
Demonstrations of superiority in a niche -- the way the 4GLs are
displacing COBOL -- may be the way to broaden the appeal of CL(OS)...
Write truly great programs in Lisp to solve important and
widespread problems -- and rely on Lisp in such a way that the
program can't be rewritten in C "to save space/time/money..".
I perfectly agree with this.
Symbolic mathematics programs like Macsyma and Reduce looked like this,
until people wrote similar systems in C (Maple, Mathematica).
But not with this second point. If you check the low level guts of
Mathematica (e.g. to interface it with some C++, Fortran or COBOL code
through the remote evaluation facilities - I do not know about Maple),
you will recognize that its core is actually.... a Lisp interpreter.
Somebody else already pointed this out. But the flame about syntax is TOTALLY
pointless. The REAL problems with CL(OS) are well known and none of them
has to do with syntax. They have all surfaced in this flame. My
personal opinio is that now there are better conditions to make CL(OS) a
more widespread language. This has happened because of a number of
historical reasons:
- CMU CL(OS) was not available until a little more than a year ago. If you
wanted CL(OS) performance you had to go to a Lisp vendor. I have nothing
against Lisp vendors, but the price difference was all there.
- WCL now addresses the problem of CL(OS) in a UNIX environment.
- Until a month ago there was NO commercial implementation of CL(OS) on
PC's at a reasonable price. (Somebody has correctly pointed out that
installing a C++ on a PC is not something that you do with two
diskettes anymore). The best commercial implementations available on PC
purportedly offer better development environment than any C++
environment on the same platform.
There are other reasons to believe that CL(OS) has now better chances than
only two years ago.
As far as I am concerned I still believe that Lisp's have some edge on
different languages as far as the programming process is taken into
account. If I must program in C/C++ I'll do it. As well as COBOL.
Having said so, I conclude agreeing with those who pointed out that
the ~R directive is too much English-centric (or English-centered ?!?
:).
I want a Swaili version of ~R in the standard.
Have a nice day
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
B. Brecht
From: Jeff Dalton
Subject: Re: COBOL is a mainstream language. So what? (was Re: Lisp vs English)
Date:
Message-ID: <8304@skye.ed.ac.uk>
In article <·····················@image.nyu.edu> ·······@cs.nyu.edu (Marco Antoniotti) writes:
>OK, I'll jump in!
>
>In article <··········@agate.berkeley.edu> ·······@peoplesparc.Berkeley.EDU (Richard Fateman) writes:
>
> Lisp is not a mainstream language, but COBOL is. Perhaps BASIC also.
> (You may think C and Fortran are mainstream, but I'm not sure how
> you are measuring.) COBOL is, in some ways being replaced by
> "4th generation languages". Not by C or C++. Certainly not by LISP.
>
> How come?
> 1. COBOL is standardized. (CL is getting that way, maybe.)
>
>Common Lisp IS getting that way and EULISP too.
Scheme is already an IEEE standard, and the Revised Reports work
fairly well as de facto standards. Everyone knows this already,
of course, but there's a tendency to forget about Scheme when
criticizing Lisp.
> Demonstrations of superiority in a niche -- the way the 4GLs are
> displacing COBOL -- may be the way to broaden the appeal of CL(OS)...
> Write truly great programs in Lisp to solve important and
> widespread problems -- and rely on Lisp in such a way that the
> program can't be rewritten in C "to save space/time/money..".
>
>I perfectly agree with this.
>
> Symbolic mathematics programs like Macsyma and Reduce looked like this,
> until people wrote similar systems in C (Maple, Mathematica).
One problem for Lisp is that many people are convinced that a C
version will be faster and smaller before they've actually tried
it. And often they're right.
For instance, there have been Prologs written in C that were fairly
fast. Prolog implementors were willing to spend the time to write
these systems and were convinced that Lisp was not a viable
alternative, in large part because they didn't want the overhead of
Lisp's general GC, but also because they though Lisp would be too
slow in other ways. (Yes, I know about LM Prolog, etc.)
At one point, I got together with one of the Prolog implementors here
who was well-disposed towards Lisp to see if we could test these
assumptions. We picked one frequently executed operation to test,
namely to dereference a "variable" until a non-variable was reached
(ie, follow a chain of pointers of type A until finding something
that is not of type A), and decided that Lisp was unacceptably
slow.
Now, I'm not convinced that Lisp has to be slow at this. There's
presumably some way to write it that's reasonably fast. Moreover,
there were other benchmarks in which Lisp was as fast as, or faster
than, C. But it looked like we'd have a lot of trouble convincing
anyone that Lisp was a practical alternative.
-- jd
From: Larry Wall
Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <1993Jan28.210414.14069@netlabs.com>
In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
: I believe that an important point that is being lost in the shuffle is
: whether or not the language is malleable enough to provide "control
: abstraction" (analogous to the way classes, structures, etc., provide
: data abstraction). If the language cannot provide good control
: abstraction, then *it's not good enough*.
The question is, of course, good enough for what?
: (Of course, the lack of
: control abstraction does not render a language useless any more than the
: lack of data abstraction does -- it just makes life much more difficult
: than it needs to be, and really, isn't programming is hard enough
: already?)
Depends on what you trade away to get your abstraction. Abstraction
doesn't come for free. Abstraction is most appealing to those folks
who are highly intelligent. By definition, they're in the minority.
Ordinary people tend to avoid abstraction: "Forget that ivory tower
stuff, just get the job done."
People learn to love Lisp from they're instructors, fine. I'm not
saying we shouldn't try to teach people to do abstraction. But
let's not expect people to like doing what they don't like to do.
Castigating the Huddled Masses for huddling is a mild form of snobbery.
: In my opinion, almost every modern programming language fails to provide
: control abstraction. One reason Lisp manages to provide it is that the
: syntax of the language makes it easy to use Lisp as its own meta-
: language. There are other ways to do this (e.g., add features to the
: language that allow the language to talk about its own parsed
: representation),...
Gee, when you point out the upside of Lisp's narcissism, it's central.
When I point out the downside, you tell me I'm stuck in 1972.
: ...but to the best of my knowledge, there aren't any
: languages that do this in any serious way.
Thank goodness. Simplify here, complexify everywhere else. TANSTAAFL.
Your turn to have the last word.
Larry Wall
·····@netlabs.com
Date: Thu, 28 Jan 1993 16:04 EST
From: Larry Wall <·····@netlabs.com>
In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
: I believe that an important point that is being lost in the shuffle is
: whether or not the language is malleable enough to provide "control
: abstraction" (analogous to the way classes, structures, etc., provide
: data abstraction). If the language cannot provide good control
: abstraction, then *it's not good enough*.
The question is, of course, good enough for what?
: (Of course, the lack of
: control abstraction does not render a language useless any more than the
: lack of data abstraction does -- it just makes life much more difficult
: than it needs to be, and really, isn't programming is hard enough
: already?)
Depends on what you trade away to get your abstraction. Abstraction
doesn't come for free. Abstraction is most appealing to those folks
who are highly intelligent. By definition, they're in the minority.
Ordinary people tend to avoid abstraction: "Forget that ivory tower
stuff, just get the job done."
Of course abstraction doesn't come for free. The question is, does the
investment made in abstraction pay for itself (or make a profit) down
the road. The answer for data abstraction is a pretty clear yes, and
has been for over twenty years. Most Lisp afficionados will claim that
the answer is yes for "control abstraction" as well.
People learn to love Lisp from they're instructors, fine. I'm not
saying we shouldn't try to teach people to do abstraction. But
let's not expect people to like doing what they don't like to do.
Castigating the Huddled Masses for huddling is a mild form of snobbery.
On the contrary, assuming that the majority of programmers are "huddled
masses" is a veiled form of arrogance. I guess I just don't know what
"ordinary people" you are talking about. Surely anyone clever and
patient enough to learn C or perl can learn about abstraction, which is
after all, in its most basic and useful form, just a formal name for the
simple concept of naming or abbreviating a common idiom.
: In my opinion, almost every modern programming language fails to provide
: control abstraction. One reason Lisp manages to provide it is that the
: syntax of the language makes it easy to use Lisp as its own meta-
: language. There are other ways to do this (e.g., add features to the
: language that allow the language to talk about its own parsed
: representation),...
Gee, when you point out the upside of Lisp's narcissism, it's central.
When I point out the downside, you tell me I'm stuck in 1972.
You will probably not find many people who think that linguistic
introspection is a form of narcissism.
: ...but to the best of my knowledge, there aren't any
: languages that do this in any serious way.
Thank goodness. Simplify here, complexify everywhere else. TANSTAAFL.
Again, the burden is on you to show exactly what has been complexified.
Your turn to have the last word.
OK. Um, here, let's try this:
As an experienced assembly-language and microcode programmer and an avid
user of Teco from its PDP-10 days, I am sympathetic with your desire to
play with primitive languages, because it can be fun to hack when all
the odds are against you. Unfortunately, some people just don't have
time to indulge in that simple pleasure. They need programming
languages that allow them to write serious software in bounded time.
They need languages that allow old programs to be re-read years later
without huge effort. I no longer have that luxury, so I mostly (but not
exclusively) use Lisp. It pleases me that some people do have the
luxury of time, or never need to go back and look at their old code; let
them use Teco and C++. Or more likely they're using Cobol and Fortran
only because they have to, which is a shame.
From: Jeff Dalton
Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <8306@skye.ed.ac.uk>
In article <····················@SUMMER.SCRC.Symbolics.COM> ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>
> Date: Wed, 27 Jan 1993 05:22 EST
> From: Chris Dollin <····@hplb.hpl.hp.com>
>
> *I* find ``x == y'' easier to read than ``(== x y)'' or ``(eq x y)'',
> and at this point Your Kilometerage May Vary.
How about the choice between
1: (and e1
e2
e3)
2: e1 &
e2 &
e3
3: e1
& e2
& e3
4: e1 & e2 & e3
where the e_i are of different lengths, or requre > 1 line?
What if there are some other ands and ors in there too?
More than 3 expressions?
I think prefix notation stands up fairly well here. You see
the "and" and you know right away you have a conjunction.
You can immediately see what expressions are at top level
in this conjunction. This tends to be harder to see with
infix notation. You have to find the end of e1 and see
that the main connective is "&". You have to see that the
next connective on the same level is also "&" and not,
say, "|". And so on.
-- jd
From: Chris Dollin
Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <KERS.93Feb2092416@cdollin.hpl.hp.com>
In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
[Hacking the quoted text a little to eliminate an intermediary]
> From: Chris Dollin <····@hplb.hpl.hp.com>
>
> *I* find ``x == y'' easier to read than ``(== x y)'' or ``(eq x y)'',
> and at this point Your Kilometerage May Vary.
How about the choice between
1: (and e1
e2
e3)
2: e1 &
e2 &
e3
3: e1
& e2
& e3
4: e1 & e2 & e3
where the e_i are of different lengths, or requre > 1 line?
What if there are some other ands and ors in there too?
More than 3 expressions?
Choice (4), of course, whenever expressions are short enough. When
they're not, choice (3). (I've tried, but don't like, choice (2), and
used (1) when writing Lisp.)
I think prefix notation stands up fairly well here. You see
the "and" and you know right away you have a conjunction.
Yes, and then I have to carry that knowledge forward while I look at
the operands. I know I've had that problem reading Lisp -- too many
operators ``waiting in the wings''. This may be a preference, a piece
of Deep Psychology, or personal wiring. I don't know.
You can immediately see what expressions are at top level
in this conjunction. This tends to be harder to see with
infix notation.
Layout.
You have to find the end of e1 and see
that the main connective is "&". You have to see that the
next connective on the same level is also "&" and not,
say, "|". And so on.
Which is true, but doesn't seem to matter in practice -- a well-laid-out
piece of code makes these things obvious, in infix languages as in
Lisp. Without some sort of objective testing, arguments on these lines
are likely to be fruitless.
I stand to the position in the quote above -- *I* find infix easier than
prefix. Perhaps it would be better to say I prefer a plurality of
notations to just the one. I'm not saying everyone else should too
(although I want to!).
--
Regards, | ``Wandering minstrels are fogging my brain | Judy Tzuke
Kers. | And weird intellectuals are doing the same.'' | Higher & Higher
From: hume smith
Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <EMCOOP.93Feb2131505@bcars148.bnr.ca>
In article <·················@cdollin.hpl.hp.com> ····@hplb.hpl.hp.com (Chris Dollin) writes:
How about the choice between
1: (and e1
e2
e3)
2: e1 &
e2 &
e3
3: e1
& e2
& e3
4: e1 & e2 & e3
You can immediately see what expressions are at top level
in this conjunction. This tends to be harder to see with
infix notation.
Layout.
You have to find the end of e1 and see
that the main connective is "&". You have to see that the
next connective on the same level is also "&" and not,
say, "|". And so on.
Which is true, but doesn't seem to matter in practice -- a well-laid-out
piece of code makes these things obvious, in infix languages as in
Lisp. Without some sort of objective testing, arguments on these lines
are likely to be fruitless.
it's true, of course. (and e1 e2 e3) is no easier to read than e1 && e2 && e3
for hairy en. (i might adopt layout 3 myself for my C stuff... hadn't thought
of that one...) the only thing i can think to mention, and it's pretty trivial,
is that since Lisp has so little syntax and fully explicit precedence, it's
much easier to make a context-sensitive editor for Lisp that can keep things
pretty-printed as you go. compare with the difficulty of making an editor
to align e1&&e2||e3&&e4 sensibly.
I stand to the position in the quote above -- *I* find infix easier than
prefix. Perhaps it would be better to say I prefer a plurality of
notations to just the one. I'm not saying everyone else should too
(although I want to!).
i find Lisp to be a lot more conducive to good layout practice - whether because
it's more necessary or just easier to do, i can't tell. grouped prefix is
certainly a hell of a lot easier to read than the ungrouped postfix of postscript,
forth, and asyst.
--
Hume Smith Honour sick and davey cris-cross
··········@acadiau.ca McTruloff sentimie
······@bnr.ca A parsnip inner pair threes.
From: Jeff Dalton
Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <8334@skye.ed.ac.uk>
In article <···················@bcars148.bnr.ca> ······@bnr.ca (hume smith) writes:
> (and e1 e2 e3) is no easier to read than e1 && e2 && e3
I find (and e1 e2 e3) esier to read when the expressions are very short
(like single variables) and when the conjunction has to be formatted
over several lines. There are conbinations of AND, OR, etc, where I
find infix easier to read.
From: Jeff Dalton
Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <8333@skye.ed.ac.uk>
In article <·················@cdollin.hpl.hp.com> ····@hplb.hpl.hp.com (Chris Dollin) writes:
>In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>
> I think prefix notation stands up fairly well here. You see
> the "and" and you know right away you have a conjunction.
>
>Yes, and then I have to carry that knowledge forward while I look at
>the operands.
Not hard, especially if procedures are fairly short, as they are in
well-written Lisp.
> I know I've had that problem reading Lisp -- too many
>operators ``waiting in the wings''. This may be a preference, a piece
>of Deep Psychology, or personal wiring. I don't know.
Perhaps you've just been reading badly-written Lisp.
> You can immediately see what expressions are at top level
> in this conjunction. This tends to be harder to see with
> infix notation.
>
>Layout.
That's right, and still harder to see.
> You have to find the end of e1 and see
> that the main connective is "&". You have to see that the
> next connective on the same level is also "&" and not,
> say, "|". And so on.
>
>Which is true, but doesn't seem to matter in practice -- a well-laid-out
>piece of code makes these things obvious, in infix languages as in
>Lisp.
I find it clearer in Lisp in this case (ie, a multi-line AND),
comparing well-laid-out code in both cases. There are cases where
I find infix easier to read.
I don't expect everyone to agree. On the other hand, I would like
everyone to accept that prefix notation is good enough so that the
decision could reasonably go either way.
> Without some sort of objective testing, arguments on these lines
>are likely to be fruitless.
What is this supposed to show? Whether I (and other people who
like Lisp syntax) are wrong about which we find easier to read?
>I stand to the position in the quote above -- *I* find infix easier than
>prefix. Perhaps it would be better to say I prefer a plurality of
>notations to just the one. I'm not saying everyone else should too
>(although I want to!).
And I stand by mine that prefix notation stands up fairly well here.
Are you disagreeing with me about that? I can't really tell.
From: Chris Dollin
Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
Date:
Message-ID: <KERS.93Feb9091715@cdollin.hpl.hp.com>
In article ... ····@aiai.ed.ac.uk (Jeff Dalton) writes:
[``>'' is me]
> Without some sort of objective testing, arguments on these lines
>are likely to be fruitless.
What is this supposed to show? Whether I (and other people who
like Lisp syntax) are wrong about which we find easier to read?
Sorry -- I wasn't making myself clear enough.
When we (that is, people on either side of the argument) say that
something is easier to read, we are making statements based on our
subjective experience. (All right; *I* am, and -- evidence to the
contrary not having been presented -- I thing everyone else is too.)
We can argue till we're blue in the face, but if all we're doing is
verbalising our preferences, we won't learn very much. If we want to
find out which notation *is* easier to read, we won't do it by
ediscussion; we'd have to do it by experiment. Preliminary to such
experiment, we'd have to agree terms (such as, what do we mean by
``easier to read'') and populations (for whom is it easier).
Now, such an experiment could have several different results.
It might show that, despite my subjective experience, I actually
find prefix easier to read than infix, perhaps after some calibration
training.
It might show that *you* find infix easier to read than prefix.
It might show that we each find our (subjectively) preferred notations
(objectively) easier to read.
Analysis might show that there are associated symptoms -- perhaps
blue-eyed people find infix easier and brown-eyed people find prefix
easier. Perhaps left-handers prefer prefix. Perhaps this, perhaps that.
But we don't have the data. If there are any well-done studies on
the psychology of programming languages, I'd be interested in references.
But I know better than to treat my preferences as anything other than
anecodotal information, especially when I can feel them leaping up and
down and shouting, ``It's *obvious* that infix is better!''.
>I stand to the position in the quote above -- *I* find infix easier than
>prefix. Perhaps it would be better to say I prefer a plurality of
>notations to just the one. I'm not saying everyone else should too
>(although I want to!).
And I stand by mine that prefix notation stands up fairly well here.
Are you disagreeing with me about that? I can't really tell.
I was making a subjective statement -- that's why I emphasised *I* --
without denying that you find prefix easier, or that it ``stands up
fairly well''. Wasn't I responding to someone who said (roughly) ``but
how do you make these cases clear in infix notation? Isn't prefix
in these cases?'' (to which my answer was, ``No, it seems to depend on
your preferences.'').
I have this strong conviction that a variety of notations is better than
one -- that, without denying the use of prefix, one can advocate infix,
postfix, or mixfix notation. But it's a conviction, not a fact, even though
(to me) it seems to be supported by the (anecdotal) evidence.
--
Regards, | "You're better off not dreaming of the things to come;
Kers. | Dreams are always ending far too soon." - Caravan.