Python syntax in Lisp and Scheme

[Pascal Costanza]

Christopher C. Stacy wrote:

JAVA has multi-methods with non-congruent arglist.
(It doesn't have multiple inheritence, but that doesn't
matter to dynamic type dispatching, except maybe in how
you implement searching your handler tables.) In JAVA,
the correspondance of the "signature" of the function call
and the method definition are what's important;
and there are no restricting "generic functions".

public class RandomAccessFile extends Object,implements DataOutput {
public void write(byte[] b) throws IOException;
public void write(byte[] b, int off, int len) throws IOException;
...
}

Maybe this is just a terminological issue, but in my book these are not
multi-methods. In Java, methods with the same name but different
signatures are selected at compile time,

When the selection is done is immaterial. The point is that it's done at
all. There's no reason why the same algorithm that is used to select
methods at compile time can't also be used to select methods at run time.
The claim that congruent argument lists are necessary for multi-method
dispatch is clearly false.

and this is rather like having
the parameter types as part of the method name.

No. It's the "system" keeping track of the types, not the user. That's
the key. The fact that C++ and Java just happen to do it at compile time
rather than at run time is a red herring.

This can lead to subtle bugs. Here is an example in Java:

These "subtle bugs" are a reflection of the limitation of compile-time
type inference in Java, not a limitation of multi-method dispatch with
non-congruent argument lists.

OK, you're right. It seems to me that the common terminology uses
"multiple dispatch" for method selection at runtime and "method
overloading" for method selection at compile time. (for example, see
http://www.wikipedia.org/wiki/Multiple_dispatch )

However, maybe it would be better to instead talk about static and
dynamic dispatch, which also reflects the analogy to static and dynamic
typing.

According to this proposed terminology, Java would be a language that
uses single dynamic dispatch and multiple static dispatch. C++ would be
a language that generally uses multiple static dispatch but allows for
single dynamic dispatch. Smalltalk uses single dynamic dispatch and no
multiple dispatch whatsoever.

Sounds good.


Pascal

 

[Alexander Schmolck]

I was criticising the graphical aspect on a discrimination stand-point.

For example, the difference between the latin glyphs for "ka" and "ga"
is bigger than that between the corresponding kana glyphs.

Hear, hear: a lisper arguing for trading off simplicity, extensibility[1] and
regularity for discriminatability

Maybe someone more proficient in Japanese might want to correct me, but I
really suspect it isn't worth it, actually. I don't think the heightened
discrimnatibility is needed that much and in fact would often even be
detrimental because a certain semantic compound often changes from
unvoiced to voiced (or from "big" to "little" TSU) in a fairly regular manner
in compound words (e.g. TETSU
(iron); $BE4!($F$D(B and HAN $BHD!($O$s(B(plate, inter alia) ->
TEPPAN, $BE4HD!((B $B$F$C$Q$s(B'iron plate/teppan cooking';
there is no TETSUHAN to confuse it with, AFAIK, so the fact that the
similarity between compound and parts is retained in the kana (unlike the
romanji transliteration) is likely to be rather desirable).

'as

[hmm, never tried embedding japanese characters in usenet posting, hope it
works :|]



[1] yep, I mean it: katakana have actually be straighforwardly extended
relatively recently to provide better transliterations for (mainly
English) loan words.

 

[Dave Benjamin]

Duh... sorry, that should read:
print range(5).map({ |x| return x + 2 })

I either case it will be [2, 3, 4, 5, 6]

Yeah yeah yeah, I really should read what I write before I post. But you
know what I mean, damnit! =)

Instead of lambda use list comprehensions:

print [x+2 for x in range(5)]

Unnamed code blocks considered evil , use named instead (functions).

Why are they evil? Does being anonymous automatically make you evil?

For instance, I always thought this was a cooler alternative to the
try/finally block to ensure that a file gets closed (I'll try not to
mess up this time... :

open('input.txt', { |f|
do_something_with(f)
do_something_else_with(f)
})

Rather than:

f = open('input.txt')
try:
do_something_with(f)
do_something_else_with(f)
finally:
f.close()

Now, I suppose you could always do:

def with_open_file(filename, func):
f = open(filename)
try:
func(f)
finally:
f.close()

# ...

def thing_doer(f):
do_something_with(f)
do_something_else_with(f)
with_open_file('input.txt', thing_doer)

But the anonymous version still looks more concise to me.

With nested scopes you can do amazing things. I myself was used to code
blocks due to perl background, but python idiom are not worse to say the
least.
For example:

class C(object):
...
def aprop():
def reader(self): return 0
def writer(self,newval): pass
return reader, writer
aprop=property(aprop())

Yeah, wasn't something like that up on ASPN? That's an interesting
trick... are you sure it's not supposed to be "property(*aprop())"
though? (who's being pedantic now? =)

Dave

 

[Kenny Tilton]

A good one...

I think Python's problem is its success. Whenever something is
succesful, the first thing people want is more features. Hell, that is
how you know it is a success. The BDFL still talks about simplicity, but
that is history. GvR, IMHO, should chased wish-listers away with "use
Lisp" and kept his gem small and simple.

 

[Andrew Dalke]

Doug Tolton:

Yes and I have repeatedly stated that I disagree with it. I simply do
not by that allowing expressiveness via high level constructs detracts
from the effectiveness of the group. That argument is plainly
ridiculous, if it were true then Python would be worse than Java,
because Python is *far* more expressive.

I disagree with your summary. Compare:

The argument is that expressive power for a single developer can, for
a group of developers and especially those comprised of people with
different skill sets and mixed expertise, reduce the overall effectiveness
of the group.

Notice the "can". Now your summary is:

...allowing expressiveness via high level constructs detracts
from the effectiveness of the group

That implies that at least I assert that *all* high level constructs
detract from group effectiveness, when clearly I am not saying
that.

Apparently you can't read very well. I simply stated that I believe our
point of contention to be that issue, I never stated I believe that
because it's some vague theory inside my head.

Nor can you, because I did not say that. I said that the arguments you
use to justify your assertions could be stronger if you were to include
cases in your history and experience which show that you understand
the impacts of a language feature on both improving and detracting from
a group effort. Since you do have that experience, bring it up. But
since your arguments are usually along the lines of "taking tools out
of your hands", they carry less weight for this topic.

(Ambiguity clarification: "your hands" is meant as 2nd person singular
possessive and not 2nd person plural.

No, what I was referring to wasn't estimation. Rather I was referring
to the study that found that programmers on average write the same
number of lines of code per year regardless of the language they write
in.

McConnell's book has the same study, with outliers for assembly
and APL. Indeed, I mentioned this in my reply:

Therefore the only way to increase productivity is to write
software in a language that uses less lines to accomplish something
productive. See Paul Grahams site for a discussion.

I assume you refer to "Succinctness is Power" at
http://www.paulgraham.com/power.html

It does not make as strong a case as you state here. It argues
that "succintness == power" but doesn't make any statement
about how much more succinct Lisp is over Python. He doesn't
like Paul Prescod's statement, but there's nothing to say that
Python can't be both easier to read and more succinct. (I am
not making that claim, only pointing out that that essay is pure
commentary.)

Note also that it says nothing about group productivity.
If it takes me 5% longer to write a program in language X
then language Y, but where I can more easily use code and
libraries developed by others then it might be a good choice
for me to use a slightly less succinct language.

Why don't people use APL/J/K with it's succinctness?

I also disagree with Graham's statement:

the most accurate measure of the relative power of
programming languages might be the percentage of
people who know the language who will take any job
where they get to use that language, regardless of the
application domain.

I develop software for computational life sciences. I would
do so in Perl, C++, Java, even Javascript because I find
the domain to be very interesting. I would need to be very
low on money to work in, say, accounting software, even if
I had the choice of using Python.

You are saying that Python and Perl are similarly compact?!?
You have got to be kidding right?
Perl is *far* more compact than Python is. That is just ludicrous.

Yes. In this I have a large body of expertise by which to compare
things. Perl dominates bioinformatics sofware development, and the
equivalent Python code is quite comparable in side -- I argue that
Python is easier to understand, but it's still about the same size.

It's always nice just to chuck some arbitrary table into the
conversation which conveniently backs some poitn you were trying to
make, and also conveniently can't be located for anyone to check the
methodology.

"Can't be located"!?!?! I gave a full reference to the secondary material,
included the full quote (with no trimming to bias the table more my way),
gave the context to describe the headings, and gave you a reference
to the primary source! And I made every reasonable effort to find both
sources online.

Since you can't be suggesting that I tracked down and destroyed
every copy of McConnell's book and of the primary literature (to make
it truely unlocatable) then what's your real complaint? That things exist
in the world which aren't accessible via the web? And how is that my
fault?

If you want some real world numbers on program length check here:
http://www.bagley.org/~doug/shootout/

If I want some real world numbers on program length, I do it myself:
http://pleac.sourceforge.net/
I wrote most of the Python code there

Still, since you insist, I went to the scorecard page and changed
the weights to give LOC a multipler of 1 and the others a multiplier
of 0. This is your definition of succinctness, yes? This table
is sorted (I think) by least LOC to most.

SCORES
Language Implementation Score Missing
Ocaml ocaml 584 0
Ocaml ocamlb 584 0
Ruby ruby 582 0
Scheme guile 578 0
Python python 559 0
Pike pike 556 0
Perl perl 556 0
Common Lisp cmucl 514 0
Scheme bigloo 506 1
Lua lua 492 2
Tcl tcl 478 3
Java java 468 0
Awk mawk 457 6
Awk gawk 457 6
Forth gforth 449 2
Icon icon 437 7
C++ g++ 435 0
Lisp rep 427 3
Haskell ghc 413 5
Javascript njs 396 5
Erlang erlang 369 8
PHP php 347 9
Emacs Lisp xemacs 331 9
C gcc 315 0
SML mlton 284 0
Mercury mercury 273 8
Bash bash 264 14
Forth bigforth 264 10
SML smlnj 256 0
Eiffel se 193 4
Scheme stalin 131 17

So:
- Why aren't you using Ocaml?
- Why is Scheme at the top *and* bottom of the list?
- Python is right up there with the Lisp/Scheme languages
- ... and with Perl.

Isn't that conclusion in contradiction to your statements
that 1) "Perl is *far* more compact than Python is" and 2)
the implicit one that Lisp is significantly more succinct than
Python? (As you say, these are small projects .. but you did
point out this site so implied it had some relevance.)

I just don't buy these numbers or the chart from Mcconell on faith. I
would have to see his methodolgy, and understand what his motivation in
conducting the test was.

I invite you to dig up the original paper (which wasn't McConnell)
and enlighten us. Until then, I am as free to agree with McConnell --
more so because his book is quite good and comprehensive with
sound arguments comparing and contrasting the different
approaches and with no strong hidden agenda that I can detect.

It still wasn't relevant to Macros. However, because neither of you
understand Macros, you of course think it is relevant.

My lack of knowledge not withstanding, the question I pose to
you is, in three parts:
- is it possible for a language feature to make a single programmer
more expressive/powerful while hindering group projects?
- can you list three examples of situations where that's occured?
- can you list one example where the increased flexibility was, in
general, a bad idea? That is, was there a language which would
have been better without a language feature.

Note that I did not at all make reference to macros. Your statements
to date suggest that your answer to the first is "no."

Andrew
(e-mail address removed)

 

[Andrew Dalke]

(e-mail address removed):

So either the syntax doesn't make a whole hell of a lot of difference
in readability, or readability doesn't make a whole hell of a lot of
difference in utility.

Or the people who prefer the awesome power that is Lisp and
Scheme don't find the limited syntax to be a problem.

Andrew
(e-mail address removed)

 

[Pascal Costanza]

Doug Tolton:



I assume you refer to "Succinctness is Power" at
http://www.paulgraham.com/power.html

It does not make as strong a case as you state here. It argues
that "succintness == power" but doesn't make any statement
about how much more succinct Lisp is over Python.

He provides more information at http://www.paulgraham.com/icad.html


Pascal

 

[Karl A. Krueger]

Haha... that's really funny... except the last one. Not that I'm a
Python purist (a big fan, yes, but not a purist), but I rarely complain
about its slowness. Java is too easy of a target for that one... =)

*laugh* I use Python more often in my job than I use Lisp, Perl, or any
other language, except possibly the Unix shell. It really is not among
the speedier ones for a lot of tasks. (Neither is Java, but I have
thankfully avoided having to do any real work in Java.) Python's
strength, for the kind of projects I work on in it, is its regularity
and the extensive standard library for things like talking to network
applications.

I moved to Python for such things from Perl, after realizing that I
really did not want to implement a database-backed application in a
language that required messy explicit dereferencing when dealing with
complex data structures. I'd much rather deal with a list of lists of
tuples than a list of references to lists of references to tuples,
getting back things like "ARRAY<#fhqwhgads>" when I missed a dereference
character.

But you're taking my list of myths too seriously. Not all C programs
are riddled with security bugs either.

Incidentally, I regard objections to "the whitespace thing" in Python
and objections to "the parenthesis thing" in Lisp as more or less the
same. People who raise these objections are usually just saying "Ick!
This looks so unfamiliar to me!" in the language of rationalizations.
I guess a philosopher would say that I am an emotivist about notation
criticisms.

 

[Paul Rubin]

I think Python's problem is its success. Whenever something is
succesful, the first thing people want is more features. Hell, that is
how you know it is a success. The BDFL still talks about simplicity,
but that is history. GvR, IMHO, should chased wish-listers away with
"use Lisp" and kept his gem small and simple.

That's silly. Something being successful means people want to use it
to get things done in the real world. At that point they start
needing the tools that other languages provide for dealing with the
real world. The real world is not a small and simple place, and small
simple systems are not always enough to cope with it. If GVR had kept
his gem small and simple, it would have remained an academic toy, and
I think he had wide-reaching ambitions than that.

 

[Sean Ross]

Yeah, wasn't something like that up on ASPN? That's an interesting
trick... are you sure it's not supposed to be "property(*aprop())"
though? (who's being pedantic now? =)

Hi.

The idiom/recipe is at
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205183

Sean

 

[Dave Benjamin]

Hi.

The idiom/recipe is at
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205183

Thanks, Sean.

 

[Mike Rovner]

Why are they evil? Does being anonymous automatically make you evil?

For instance, I always thought this was a cooler alternative to the
try/finally block to ensure that a file gets closed (I'll try not to
mess up this time... :

open('input.txt', { |f|
do_something_with(f)
do_something_else_with(f)
})

Rather than:

f = open('input.txt')
try:
do_something_with(f)
do_something_else_with(f)
finally:
f.close()

"Explicit is better than implicit"

Even your example clearly shows that try block is much more readable and
understandable.
That's why it's being considered evil by majority of python developers.

But the anonymous version still looks more concise to me.

Python prioritize things diferently than other languages.
It's not an APL. "Readability counts"

Yeah, wasn't something like that up on ASPN? That's an interesting
trick... are you sure it's not supposed to be "property(*aprop())"
though? (who's being pedantic now? =)

Yeah, right. Thanks for pointing out.

Mike

 

[Andrew Dalke]

Pascal Costanza:

He provides more information at http://www.paulgraham.com/icad.html

The page I referenced (http://www.paulgraham.com/power.html)
appears to be a refinement of some ideas on that page.

It's somewhat funny that on the page I mentioned he says:

So any language comparison where you have to meet a predefined
spec is testing slightly the wrong thing.

while on the page you reference he gives a comparison between various
languages based on a predefined spec. And he uses as his test case
something I've not needed. By comparison, following Kenny Tilton's
lead, the Bagley Shootout Page suggests that in an aggregate of small
but non-trivial problems, OCaml is the most succinct language, with
Python roughly comparable to Lisp/Scheme.

I have run across his pages before, and have a hard time
symphathizing with his view of things. For example, the start of
the icad essay mentions that Lisp is already "kind of unusual"
compared to C because it includes a full interpreter. But
effectively all Python programs shipped include a full interpreter
as well, and many give access to that interpreter, so I don't
see what's unusual about it. Ditto for Tcl apps. Even some of
my command-line perl apps included a way to pass in perl
code on the command line, as for a search filter.

The phrase "they had hard-headed engineering reasons for
making the syntax look so strange." reminds me of the statement
"better first rate salespeople and second rate engineers than
second rate salespeople and first rate engineers" (and better
first rate both). That's saying *nothing* about the languages;
it's saying that his viewpoint seems to exclude the idea that
there are hard-headed non-engineering reasons for doing things."

Consider one of those "hard-headed engineering reasons", at
http://www.paulgraham.com/popular.html

It has sometimes been said that Lisp should use first and
rest instead of car and cdr, because it would make programs
easier to read. Maybe for the first couple hours. But a hacker
can learn quickly enough that car means the first element
of a list and cdr means the rest. Using first and rest means
50% more typing. And they are also different lengths, meaning
that the arguments won't line up when they're called,

That to me is a solid case of post hoc ergo proper. The
words "1st" and "rst" are equally as short and easier to
memorize. And if terseness were very important, then
what about using "." for car and ">" for cdr? No, the reason
is that that's the way it started and it will stay that way
because of network effects -- is that a solid engineering
reason? Well, it depends, but my guess is that he wouldn't
weight strongly the impact of social behaviours as part of
good engineering. I do.

And entirely off the topic of programming, his essay at
http://www.paulgraham.com/nerds.html
has little resonance with my memory of high school.

Andrew
(e-mail address removed)

 

[Daniel Silva]

Consider one of those "hard-headed engineering reasons", at
http://www.paulgraham.com/popular.html

It has sometimes been said that Lisp should use first and
rest instead of car and cdr, because it would make programs
easier to read. Maybe for the first couple hours. But a hacker
can learn quickly enough that car means the first element
of a list and cdr means the rest. Using first and rest means
50% more typing. And they are also different lengths, meaning
that the arguments won't line up when they're called,

That to me is a solid case of post hoc ergo proper. The
words "1st" and "rst" are equally as short and easier to
memorize. And if terseness were very important, then
what about using "." for car and ">" for cdr? No, the reason
is that that's the way it started and it will stay that way
because of network effects -- is that a solid engineering
reason? Well, it depends, but my guess is that he wouldn't
weight strongly the impact of social behaviours as part of
good engineering. I do.

It hasn't stayed that way for me:

(define first car)
(define rest cdr)



- Daniel

 

[Dave Benjamin]

"Explicit is better than implicit"

In that case, why do we eschew code blocks, yet have no problem with the
implicit invocation of an iterator, as in:

for line in file('input.txt'):
do_something_with(line)

This is not to say that I dislike that behavior; in fact, I find it
*beneficial* that the manner of looping is *implicit* because you can
substitute a generator for a sequence without changing the usage. But
there's little readability difference, IMHO, between that and:

file('input.txt').each_line({ |line|
do_something_with(line)
})

Plus, the first example is only obvious because I called my iteration
variable "line", and because this behavior is already widely known. What
if I wrote:

for byte in file('input.dat'):
do_something_with(byte)

That would be a bit misleading, no? But the mistake isn't obvious. OTOH,
in the more explicit (in this case) Ruby language, it would look silly:

open('input.txt').each_line { |byte|
# huh? why a byte? we said each_line!
}

I think this is important to point out, because the implicit/explicit
rule comes up all the time, yet Python is implicit about lots of things!
To name a few:

- for loops and iterators
- types of variables
- dispatching via subclass polymorphism
- coercion (int->float, int->long...)
- exceptions (in contrast with Java's checked exceptions)
- __magic_methods__
- metaclasses
- nested scopes (compared to yesteryear's lambda x, y=y, z=z: ...)
- list comprehensions

In all of the above cases (with a bit of hesitation toward the voodoo of
metaclasses) I think Python is a better language for it. On the other
hand, Perl's implicit $_ variable is a good example of the hazards of
implicitness; that can be downright confusing. So, it's not cut and dry
by any means.

If all you're saying is that naming something is better than not naming
something because explicit is better than implicit, I'd have to ask why:

a = 5
b = 6
c = 7
d = a + b
e = c / 2
result = d + e
return result

Is any better than:

....
return (a + b) + (c / 2)

To me, it's the same issue. Why should I have to name something that I'm
just going to return in the next statement, or pass as a parameter, and
then be done with it? Does that really increase either readability or
understandability? Why should I name something that I'm not going to ask
for later?

Even your example clearly shows that try block is much more readable and
understandable.
That's why it's being considered evil by majority of python developers.

Readability is a moving target. I think that the code block syntax
strikes a nice balance between readability and expressiveness. As far as
what the majority of Python developers consider evil, I don't think
we've got the stats back on that one.

Python prioritize things diferently than other languages.
It's not an APL. "Readability counts"

This is nothing like APL... if anything, it's like Smalltalk, a language
designed to be readable by children! I realize that APL sacrificed
readability for expressiveness to an uncomfortable extreme, but I really
think you're comparing apples and oranges here. List comprehensions are
closer to APL than code blocks.

Dave

 

[Dave Benjamin]

|return { |x, y|
| print x
| print y
|}
|It's unambiguous because no dictionary literal would ever start with
|'{|', it looks almost identical to a certain other language <g>

Btw. I think Dave is thinking of Ruby as that "certain other language."
But Clipper/xBase used the same syntax for the same thing before Ruby
was a glimmer in Matz' eye. I'm not sure if that's where he got it
though... it might be from somewhere older I don't know about.

Busted. =) I could be wrong, but I thought Ruby got its code blocks from
Smalltalk, since both languages support them, and both have collections that
support "collect", "select", and "invoke", aka "map", "filter", and
"reduce", using code blocks. The syntax isn't exactly the same, but it's
very similar.

My coworker used to be a Clipper programmer, and he gets a sparkle in his
eye when he reminisces about the code blocks of old.

Dave

 

[Kenny Tilton]

(e-mail address removed):



Or the people who prefer the awesome power that is Lisp and
Scheme don't find the limited syntax to be a problem.

OK, here you are saying that only a certain subset of programmers have
the genetic makeup necessary to prefer the unlimited syntax. Unlikely.

It is nice that you also say this strongly correlates with those who
like their programming languages to be powerful. But my guess is that
that genetic thing won't hold up: if everyone who tries Lisp for more
than two weeks gets used to the parens, and then after two months would
not want to edit any other way, then what makes me think anyone who
likes programming (even the ones in your imagination who do not want
powerful languages) would love the syntax.

({function | macro | special-form} arguments*) => values*

Roughly speaking (I'm no BNFer) but... hellasweet! You can chant
"simplicity" as much as you like, but /that/ is simple.

In C i put "int x;" at the top level and I have a global. In Lisp I am
at first astonished to see I have to type (defparameter x) or defvar or
defconstant. Wordy! Wordy! Wordy! But eventually I realize. Oh, why is
the C "x" a global? There is no difference between that declaration and
the one in:

void zzzz () {
int x;
.....}

Oh, well, you see, it is at the top level. ie, Weird things like a form
being at the top level have huge unspoken implications. But with Lisp
there is a great honking special form (macro?) such as "defparameter"
that grabs you by the lapels and screams "GLOBAL!!!". But most of all,
it manages to get the job done with The One True Syntax, using a
dedicated macro instead of a special syntax (top-levelness) to establish
the semantics.

You call that "limited"? Yer just flaming.

Anyway, the point is: fuggedaboutit. Lisp syntax is unlike all the other
languages you have ever used, so it seems bizarre to the unitiated. But
go to c.l.l. and flame the syntax and you will discover it is something
Lispniks love. Including those who have used and excelled at all the
other languages. And, as you concede, these are people who groove on the
power of Lisp. Doesn't that make folks think they better go check out
for themselves what these folks have discovered?

http://alu.cliki.net/The RtLS by Road

Don't forget your Lisp-aware editor.

 

[Michael Geary]

Andrew Dalke:

The phrase "they had hard-headed engineering reasons for
making the syntax look so strange." reminds me of the statement
"better first rate salespeople and second rate engineers than
second rate salespeople and first rate engineers" (and better
first rate both). That's saying *nothing* about the languages;
it's saying that his viewpoint seems to exclude the idea that
there are hard-headed non-engineering reasons for doing things."

Consider one of those "hard-headed engineering reasons", at
http://www.paulgraham.com/popular.html

It has sometimes been said that Lisp should use first and
rest instead of car and cdr, because it would make programs
easier to read. Maybe for the first couple hours. But a hacker
can learn quickly enough that car means the first element
of a list and cdr means the rest. Using first and rest means
50% more typing. And they are also different lengths, meaning
that the arguments won't line up when they're called,

That to me is a solid case of post hoc ergo proper. The
words "1st" and "rst" are equally as short and easier to
memorize. And if terseness were very important, then
what about using "." for car and ">" for cdr? No, the reason
is that that's the way it started and it will stay that way
because of network effects -- is that a solid engineering
reason? Well, it depends, but my guess is that he wouldn't
weight strongly the impact of social behaviours as part of
good engineering. I do.

It's pretty funny when you consider that car and cdr were named after the
Contents of Address Register and Contents of Decrement Register on the IBM
704. Now that's a solid engineering reason!

(I'm not knocking Lisp; in fact, this discussion has whetted my appetite to
explore it.)

-Mike

 

[Doug Tolton]

Andrew Dalke:



It's pretty funny when you consider that car and cdr were named after the
Contents of Address Register and Contents of Decrement Register on the IBM
704. Now that's a solid engineering reason!

(I'm not knocking Lisp; in fact, this discussion has whetted my appetite to
explore it.)

-Mike

Graham does admit in that the reasons for the choice were mostly
historical. However, he uses them because he likes the fact that they
are shorter than first and rest.

If you read his design goals for Arc you will note that he is a big fan
of very terse operators.

 

[Andrew Dalke]

Me:
Kenny Tilton:

OK, here you are saying that only a certain subset of programmers have
the genetic makeup necessary to prefer the unlimited syntax. Unlikely.

Yes, it is very unlikely that I would say that...

Oh wait. I didn't.

I prefer speaking in English even if Navajo might be a better language
for expressing certain concepts. That doesn't mean that preference
is part of my genetic makeup.

I prefer the mambo basic over the salsa basic when dancing.
Doesn't mean that's part of my genetic makeup.

({function | macro | special-form} arguments*) => values*

Roughly speaking (I'm no BNFer) but... hellasweet! You can chant
"simplicity" as much as you like, but /that/ is simple.

Actually, you could have a more minimal language with

(name arguments*) => values*

but Lispers must have decided that *some* syntax makes
things easier.

And you can get still more minimal with FORTH where the
syntax is

WORD *

But with Lisp
there is a great honking special form (macro?) such as "defparameter"
that grabs you by the lapels and screams "GLOBAL!!!".

The word "global" would scream "GLOBAL!!!" a bit more.

But most of all,
it manages to get the job done with The One True Syntax, using a

TOTS? If there was no need for backwards compatibility, I'll
argue that swapping [] and () would be better, since I don't need
to use shift to use the [ or ] characters. (On a US keyboard. And
yes, I know I could swap the keyboard layout.) Assuming there
was no other code in the world and no other Lisp programmers,
wouldn't that be a better syntax?

You call that "limited"? Yer just flaming.

Yes, I'm calling it limited. I didn't say limiting, which appears to
be what you read.

No, I'm not flaming.

But go to c.l.l. and flame the syntax and you will discover it is something
Lispniks love.

In case you hadn't noticed, this is cross posted on c.l.l.

I am fully aware of M-expressions for Lisp. I know about
Dylan and it's Lispishness in a infix language. I know that
Lispers enjoy their syntax. I know it's the source of the ability
to support macros and other on-the-fly code manipulation.

I am not asking any of them -- nary a soul -- to abandon Lisp.
Nor am I flaming the syntax.

What I said was that Python is *not* an application of
Greespun's Tenth Rule of programming because 1) it isn't
bug-ridden, and 2) because Python explores ideas which
which had no influence on Lisp's development -- user
studies of non-professional programmers.

Where are the user studies which suggested () over [], or that
"car" is better than "first"/"1st" or that "cdr" is better than
"rest"/"rst"?

Yes, I know that the early teletypes might not have had
[ or ], and that car and cdr come from register names on
the machine Lisp was first implemented on. If that's
indeed the justification then there may be a Lisp-ish language
which is equally as powerful, equally as elegant, etc *and*
which is slightly easier to learn and type. But it wasn't chosen,
and it won't be used because of good social reasons: a huge
existing code base and people who now have Lisp "in their
fingers" and don't want to retrain for the slight advantage
that others might get.

"The One True Syntax" indeed.

(Okay, I admit it. That one line was flaming *you*, but not
c.l.l'ers as a class.)

And, as you concede, these are people who groove on the
power of Lisp. Doesn't that make folks think they better go check out
for themselves what these folks have discovered?

Sure. More power to them. For me, it looks like my
next really different language to learn might be OCaml. ("really
different" because I needed to learn some Javascript recently,
and I don't find it different enough to give a different view of
the world.)

Andrew
(e-mail address removed)