merits of Lisp vs Python

[jayessay]

It's simply that newer language designs by definition have more of an
experience base to build on than older ones, if the designers care to
make use of it.

Agreed. Indeed, that was the underlying guiding principle in putting
together CL. *ML being older than CL didn't have any more opportunity
in this respect.

ML's designers were quite aware of what it was like to write Lisp
code. Lisp (like anything else) has good and bad points, and ML's
designers were able to examine these in retrospect and try to
improve on them.

I'm sure you're right on that. Of course it's vice-versa as well.

Are there any Lisp devotees who have done serious development in ML?

There are some here (cll) who appear to have, but I don't know them
personally.


/Jon

 

[Robert Uhl]

Why is selecting a valid s-expression easier than selecting a python
block ? If you mistakenly select an extra parenthesis or omit one, it's
the same thing. Having said that, I find this problem is mostly
academic in both languages with modern editors...

Or even nearly 30 year old editors; emacs provides support for
error-free selection of s-expressions, although to be frank I still
don't use them as often as I should.

 

[jayessay]

I'm talking about the way Lisp is actually used, not what contortions
one can do with macros.

But this _is_ the way it's actually used. I think this is a key point
that many people here don't understand. _If_ the construct you
mention, really had any underlying use/goodness, for someone who
wanted it, they would simply add it with the nice syntax and all.
Also note that most of this would not involve macros - that would only
be a final step to add the "nice" syntax.

This isn't any sort of "contortion", it's simply how things are
actually done. And indeed, in this case, the macrology would be
pretty straight forward and simple as opposed to "contorted" (which
I'm sure there are cases of).

The way one does OOP in Lisp is with CLOS.

I'm not sure your construct has anything necessarily to do with "OOP"
(which is a pretty nebulus concept). But even if it did, what you can
really say is that CLOS is the preferred/standard way to do it in CL.
If you have other requirements that don't quite fit, you don't try
pounding them into the round hole. There have been a few people here
in the last few months who have wanted to do just that. Of course you
can get quite a distance in this respect via the MOP and may not need
or want to do more.


/Jon

 

[jayessay]

even more dynamic than Lisp. I mean "dynamic" in a less good way--
there is a huge amount of state scattered all through a running Python
program, that the application can modify at random and whose contents
the working of really fundamental operations like method invocation.
It's just a big mess and I'd get rid of it if I could. It reminds me
of like old time Lisp programs that pervasively used property lists on
symbols to attach random attributes to the symbol, instead of using
something like defstruct to make multi-field data values.

Indeed. Or even worse - default dynamic binding for everything.


/Jon

 

[jayessay]

That may be true, but lisp's numeric addition operator knows how to add
fixnums, bignums, rationals and whatever the lisp name for floating points
is (imprecise?)

float. Of which there are several flavors.

http://www.lispworks.com/documentation/HyperSpec/Body/t_float.htm

sets can manage. So that's still type-dependent dispatch, which
isn't going to get us to the speeds that we actually see reported
unless there's extra stuff going on. Type inference? Declarations?

Yes - both are typically involved.


/Jon

 

[Robert Uhl]

Robert Uhl a écrit :


Never heard of that French unit thing. Unless you talk about that
archaic unit system that was in use before the metric system was
created.

I use 'French units' instead of the term 'metric system' because the
latter means 'measurement system,' and of course could validly be
applied to _any_ system.

 

[Robert Uhl]

Saying that the French units are technically worse than standard units
is a troll of very poor quality and a very weak argument.

It was just an example that the argument from popularity is invalid.
However, I (and many others) would argue that optimisation for unit
conversion is the wrong choice when designing a system of measures. But
this is not the venue for such a discussion, so I'll stop now

--
Robert Uhl <http://public.xdi.org/=ruhl>
....It [the Mexican dictatorship] has demanded us to deliver up our arms,
which are essential for our defence, the rightful property of freemen,
and formidable only to tyrannical governments...
--Texas Declaration of Independence

 

[Rob Thorpe]

I use 'French units' instead of the term 'metric system' because the
latter means 'measurement system,' and of course could validly be
applied to _any_ system.

A good term to use, if your audience is likely to understand it, is "SI
units".

The current units used in science and for most measurements are
"Systeme International d'unites" Units. The original metric system is
not really used anymore, SI is slightly different.

 

[Ken Tilton]

I use 'French units' instead of the term 'metric system' because the
latter means 'measurement system,' and of course could validly be
applied to _any_ system.

Now we know how one contractor ended up using English units when the
other was using French units and an entire Mars mission was lost: they
were both using the metric system.

[cue NASA aopologist Ron (or his sidekick Al) for some scenery-chewing
outrage over my condescension and arrogance.]

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[jayessay]

You're forgetting that CL tried to be more or less backwards
compatible with its predecessors

You're mistaken, I'm not forgetting this. And despite this being
true, CL added several "new" things that (again through actual
experience) were deemed sufficiently understood to add (CLOS,
conditions, and such).

mistakes from the past. Scheme went somewhat further than CL at
cleaning things up,

But, Scheme was before CL (and indeed CL took some things from
Scheme). Of course Scheme too has continued to evolve.

and Scheme's aficionados think CL is a clumsy old kludge as a
result

Well, if you lower into "flamewar" talk, CL aficionados have similar
things to say about Scheme. But that is just irrelevant silly
flamage.

But it's still a Lisp dialect. The ML's, for their part,
were able to start from scratch.

There are Lisps like this as well (EuLisp sort of and now Arc). But
really, how is "starting from scratch" really an advantage?
Especially from a _practical_ point of view. Admittedly, I used to
think the same, but now think that is just wrong. Again, the example
of The Calculus and such come to mind...


/Jon

 

[Willem Broekema]

Does this count as a "children of a lesser Python"?

This sounds like a quite derogatory first question. CLPython is not a
dead and abandoned project, nor is execution speed its main goal, nor
are Python semantics bended anywhere (it can run the Pie-thon
benchmark). Sure, some recently introduced language features are
missing, but with just a little effort that's solved...

Moreover, in Common Lisp source code analysis and manipulation can be
expressed easily. CLPython thus provides ample opportunities to analyze
type inference or caching schemes. Most of that is unexplored
territory, I think. I like the journey so far.

How does clpython implement Python's immutable strings, for example?

Normal Python strings are represented by normal Lisp strings. Instances
of subclasses of 'str' are represented by CLOS instances. That's for
performance reasons. This dual-representation aspect is nicely hidden
behind macros, so that even in the code of CLPython itself there's no
need to worry, or even know, about it.

Why not take a look in the code -- I'll be happy to explain things.

- Willem

 

[tac-tics]

I use 'French units' instead of the term 'metric system' because the

other was using French units and an entire Mars mission was lost: they
were both using the metric system.

LISP is better than Python, because it does not have a American
Empirical Measurements library, preventing horrible spaceborne
disasters.

 

[Ravi Teja]

Pretty much;-)

Fewer features, worse performance. Why use 'em?

Usability. Especially when users quote a very significant difference
here.

 

[Slawomir Nowaczyk]

On Tue, 12 Dec 2006 20:38:14 -0800

#> > > Because it's the language for which indentation is automatically
#> > > determinable. That is, one can copy/paste a chunk of code, hit a
#> > > key and suddenly everything is nicely indented.
#> >
#> > Cool, so in other languages I need to set block marks like () and
#> > {} and also indent the code for readability, and in Python I indent
#> > only. From my POV that's less work.
#>
#> Try reading again. In Lisp, you use () and *your editor*
#> automatically indents according to the universal standard,

How does that differ from "In Python, you use <TAB> and your editor
automatically indents according to the universal standard"?

#> or you leave it sloppy until other folks reading your code convince
#> you to get a proper programming editor.

Well, in Python you never need to leave it sloppy.

#> Indentation does not get out of sync with semantics because the
#> editor virtually never misses parentheses that the Lisp compiler
#> sees.

What makes you think Python indentation ever gets out of sync with
semantics?

#> In Python, you group in your mind, and press indentation keys to make
#> it happen in your editor.

In Lisp, you group in your mind, and press parentheses keys to make it
happen in your editor.

#> The editor cannot help that much, because it cannot read your mind.

The editor cannot help that much, because it cannot read your mind.

--
Best wishes,
Slawomir Nowaczyk
( (e-mail address removed) )

You can't wake a person who is pretending to be asleep.

 

[Slawomir Nowaczyk]

On Sun, 10 Dec 2006 10:11:37 -0500

#> Lisp has all the cool qualities you like in your pets, plus native
#> compilation in most implementations, plus maturity and a standard, plus
#> a better OO, plus macros, plus a dozen more small wins. Including
#> automatic indentation.

Automatic indentation? Wow, that's cool... we in Python need to press
RET and sometimes even use this ugly ":" or "<TAB>" key to get proper
indentation.

Oh, wait, you mean you need to type "(" and ")" in Lisp?

What's automatic about *that*???

--
Best wishes,
Slawomir Nowaczyk
( (e-mail address removed) )

Grossman's Law: Complex problems have simple,
easy-to-understand, wrong answers.

 

[Slawomir Nowaczyk]

On Sun, 10 Dec 2006 17:11:20 +0200

#> Steven D'Aprano wrote:
#>
#> > So which is it? If Lisp is so self-evidently better than every other
#> > language, and if nobody has any fears or concerns with Lisp, why is Lisp a
#> > fringe language?

#> Because shifting to lisp somewhere in the middle of
#> your project or carear is VERY EXPENSIVE STEP.

Doesn't that say something about Lisp? Switching to most other useful
languages is a nice experience.

Luckily, that claim is obviously false.

--
Best wishes,
Slawomir Nowaczyk
( (e-mail address removed) )

Integrated Software: A single product that deftly performs hundreds
of functions that the user never needs and awkwardly performs
the half-dozen he uses constantly.

 

[Slawomir Nowaczyk]

On Sat, 09 Dec 2006 21:59:58 -0500

#> > Could it be because of people like J Shrager who writes things like this?
#> >
#> > "Can't you just expand the language via macros to create whatever facility
#> > of this sort [major new features with new syntax] you need..."
#>
#> The context was CLOS. Something that big needs new syntax.

Really? What if we *do not want* anything that big in Python?

#> > (This thread, dated 8 Dec 2006 23:38:02 -0800)
#> >
#> > To someone outside of Lisp, that looks like "I can make Lisp look like any
#> > language I like in just a few lines."
#>
#> On the contrary,

And you are the right person to say how things look like for *someone
outside Lisp* exactly why?

#> Your hands must be getting sore from banging that drum so hard and so
#> long -- has it ever occurred to you that good programmers concerned
#> with power do not obfuscate code?

Has it ever occurred to you that some of us need to read code written by
not-so-good programmers?

#> We love the chance to preach to the unsaved, so we are indebted to
#> you for the many chances to clarify, but something tells me I should
#> check the c.l.p archives to make sure I am not chatting away happily
#> with the village idiot.

Would you do me a favour and check the same thing on c.l.l while you are
at it?

#> > And that implies that to read a Lisp program, one might need to be
#> > able to read code that looks like Lisp, or Smalltalk, or Prolog, or
#> > Fortran, or all of those, or whatever bizarre syntax the developer
#> > wanted it to look like.
#>
#> "I don't want to think, I just want to bang on de drum all day. I
#> don't want to learn, just want to bang on de drum all day."

Too bad for you.

Steven has a valid point here, BTW.

#> > Sure. But in the real world of programming, most developers aren't
#> > good developers, they are merely average
#>
#> Two questions: do you really voluntarily use libraries from crappy
#> developers?

Voluntarily as in "in my work place"? I mean, I *am* voluntarily staying
employed, if you wish look at it this way...

#> Second, you think a language can stop people from writing bad code?

No. But writing bad code can be made more or less difficult.

--
Best wishes,
Slawomir Nowaczyk
( (e-mail address removed) )

"Consequences, shmonsequences! So long as I'm rich!" -- Daffy Duck

 

[Kaz Kylheku]

And for any of you who are rejecting this because you don't want to
learn or use Emacs, Raffael's point is even true in the Vi family of
editors ("nvi" & "vim", at least). The "y%" command yanks (copies)
everything through the matching paren into the anonymous buffer;
"d%" deletes likewise [and saves in the anonymous buffer]; "p" (or "P")
pastes after (or before) the current location. All can be prefixed
with a buffer ("Q-register") name for more flexibility.

If you're on Vim, you also have the "ib" and "ab" commands that work
under visual selection. You repeat them to broaden the selection to the
next level of nesting.

 

[Paul Boddie]

This sounds like a quite derogatory first question.

I wouldn't take it that way: it's only a quote from an opinion piece
about alternative Python implementations (albeit a contentious one).

CLPython is not a dead and abandoned project, nor is execution speed
its main goal, nor are Python semantics bended anywhere (it can run
the Pie-thon benchmark). Sure, some recently introduced language
features are missing, but with just a little effort that's solved...

What would it take to get Python people more interested in it? I've
been monitoring the site [1] and the mailing list [2] for some time,
but nothing particularly visible seems to be happening. And wouldn't a
more prominent announcement be the first step to some real publicity? I
think it only got announced on comp.lang.lisp [3] with someone picking
up on it in comp.lang.python. Perhaps getting it on the python.org
front page would attract some attention, although I accept that a lot
of Python developers would rather mess around writing C than writing
Lisp.

Anyway, I'm happy to hear that you're still working on CLPython.

Paul

P.S. Follow-ups set to comp.lang.python.

[1] http://trac.common-lisp.net/clpython/
[2] http://common-lisp.net/pipermail/clpython-devel/
[3] http://groups.google.com/group/comp.lang.lisp/msg/57ae88c5f9a59143

 

[David Golden]

Actually, in English, "parenthesis" means the bit in between the
brackets.

The various kinds of brackets (amongst other punctuation marks
including, in most english texts, commas) *demarcate* parentheses.

Wikipedia's "Parenthesis (rhetoric)" is, at time of writing, the correct
British English definition, citing the OED:
http://en.wikipedia.org/wiki/Parenthesis_(rhetoric)

"An explanatory or qualifying word, clause, or sentence inserted into a
passage with which it has not necessarily any grammatical connection,
and from which it is usually marked off by round or square brackets,
dashes, or commas"

The use of round brackets to demarcate parentheses in america eventually
somehow led to round brackets themselves being called parentheses in
america, but that usage still makes little sense to many native
speakers of British (or Hiberno-) English outside the computing field.

It's like calling a quotation mark a "quote" instead of a "quotation
mark". And lo, guess who does that too...

Calling round brackets "parenthesis marks" would be acceptable but
perhaps ambiguous in British English, probably needing further
qualification like "double quotation mark", "single quotation mark".