Re: merits of Lisp vs Python

[Bill Atkins]

Bjoern Schliessmann <[EMAIL PROTECTED]> writes:

> I think you acknowledged that the syntax is different and not
> borrowed?

Um, so does that mean that Python couldn't have borrowed other
features?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

"Mark Tarver" <[EMAIL PROTECTED]> writes:

> How do you compare Python to Lisp?  What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here.  This is
> just a question for my general education.
>
> Mark

What was the reasoning behind cross-posting this to c.l.p and c.l.l?
This type of question inevitably leads to controversy.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Paul Rubin  writes:

> Huh?  Are you saying Lisp systems never release new versions?  And you

He's pretty clearly not saying that.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

[EMAIL PROTECTED] (Aahz) writes:

> I would say that your statement about Lisp syntax is wrong.  Not that it
> is technically inaccurate, but that it completely misses the point, so
> much so that it is wrong to say it.  One of the key goals of Python is
> readability, and while it is indeed easy to learn the rules for Lisp
> syntax, observational experience indicates that many people (perhaps even
> the vast majority of people) find it difficult to learn to read Lisp
> programs.

You see, this is what I meant by "controversy."  As much as I'd like
to ignore this whole discussion, I will eventually read something like
the above and feel compelled to respond, thus ensuring that the thread
continues until eventually everyone gives up and we end upexactly
where we started. (thanks again, Mark Tarver)

This is a silly claim.  What observational experience are you talking
about?  Lisp is delightfully readable.  In fact, I find it more
readable than any other language.  Why do you think that is?  Could it
be because I use Lisp on a daily basis?  Could that also explain why
Python seems more readable than Lisp to you?

> As for your claims about speed, they are also nonsense; I doubt one
> would find an order of magnitude increase of speed for production
> programs created by a competent Lisp programmer compared to programs
> created by a competent Python programmer.

Nonsense?  Hardly.  Most Lisp implementations compile to native code,
and can take advantage of fifty years of research into making Lisp
compile into efficient code.  You are correct, though: the difference
would probably be a little more than an order of magnitude.

> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers.  Think about it.

OK, I'm thinking about it.  What was supposed to happen?

(BTW, which millions are you talking about?  The millions that went
into the AI boom in the 1980's?)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

3Paul Rubin  writes:

> Lisp just seems hopelessly old-fashioned to me these days.  A

Indeed.  All the excitement nowadays is centered around youngster
interpreted languages that support type-edit-run development only and
are controlled by a single person.  Standardized, mature languages
with good compilers and interactive development just can't keep up
with these modern trends.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> I've read all the arguments against significant indents/whitespace, or
> in favour of braces, and while there are a few minor good points they
> make, a few edge cases where Python's significant indentation is
> sub-optimal, overall I believe that the famous reaction of programmers to
> Python and whitespace is simply them being more like cats than usual:
>
> "It's different, anything different is frightening, I don't like it, hiss
> hiss spit!!!"

What about "It's wrong, it's wrong, hiss hiss spit!" ?

I want to be able to change my code and let the editor indent the
result; if I make extensive changes to a section of Python code, I
have to review it afterward and make sure I haven't introduced any
subtle indentation mistakes.  Compare

(let ((x 'blah))
 (if (eql x 'foo)
  (print "blah")
 (print "bloo"

This could quite conceivably be the result of a lot of refactoring
of (admittedly silly) code.  But now I just press C-M-q and, pow:

(let ((x 'blah))
  (if (eql x 'foo)
  (print "blah")
  (print "bloo")))

All happily-indented.  And mistakes in nesting show up as mistakes in
indenting.  Who could ask for anything more?  Python requires me to
review the structure of the code to make sure I haven't inadvertantly
broken it.  Why?

Why do I need Python to enforce my indentation (potentially leading to
bugs) when my editor can indent my code perfectly because the syntax
of Lisp is so free of special cases?

> But Lisp's syntax is so unlike most written natural languages that that it
> is a whole different story. Yes, the human brain is amazingly flexible,
> and people can learn extremely complex syntax and grammars (especially if
> they start young enough) so I'm not surprised that there are thousands,
> maybe tens or even hundreds of thousands of Lisp developers who find the
> language perfectly readable.

Most programming languages are nothing like natural languages
(thankfully - ever heard of something called COBOL?).  Lisp's syntax
is trivial to lean, and its semantics are very precise.

> But that isn't to say that the syntax of Lisp is for everybody. Far from
> it -- I'd be willing to bet that Lisp developers are a self-selected group
> of far above average intelligence. That would explain why so many of them
> seem to be so much more comfortable with higher-order functions than most
> other people -- even intelligent people. 
>
> (Looking back, I'm embarrassed about my first reaction to factory
> functions all those years ago. Hiss hiss spit. But even with added
> familiarity, there comes a time where one has to question the benefit of
> sufficiently high-order functions. If you are writing a factory function
> that returns factory functions that return factory functions that return
> the functions that you needed in the first place, chances are you really
> need to rethink your tactics.)
>
> If I'm right, then maybe Lisp is "better" in some absolute sense, *for
> those who can use it*. For those who can't, it isn't just a matter of
> (say) the syntax being hard to read because it is unfamiliar, but it
> being objectively harder to use.
>
> An interesting study would be to track people's eyeballs as they read
> code, or look at how much oxygen their brain uses. Do Lisp coders do more
> work to read Lisp than Python coders do to read Python? I suspect they do,
> but successful Lisp coders don't notice. Everybody else does, and
> gravitate to languages which might not be "better" but are "good enough".
>
> (If my post leads to any Lisp developer's already swollen head exploding
> from pride, my job here is done *wink*)

I'm afraid you're on the wrong track.  Any programmer can pick up Lisp
and be productive in it these days.  Please don't try to make Lisp
seem more mysterious or elitist than it really is.  It's just a
programming language, and anyone can learn it:

  http://www.gigamonkeys.com/book
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>
>> if Common Lisp didn't have CLOS, its object system, I could write my own
>> as a library and it would be just as powerful and just as easy to use as
>> the system Common Lisp already provides.  Stuff like this is impossible
>> in other languages.
>
> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?

Of course, but you have to realize that Turing-completeness is a
useless concept when comparing languages.  C and Python are both
Turing-complete.  So: write me some code in each that reads in a line
of text, splits it on spaces and stores the result in an array.  Which
would you rather write?  Which will be shorter and more easily changed
and straightforwardly grasped in the future?

QED.  Turing-completeness is irrelevant when comparing languages.
Take it as a given.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

"mystilleef" <[EMAIL PROTECTED]> writes:

> Mark Tarver wrote:
>> How do you compare Python to Lisp?  What specific advantages do you
>> think that one has over the other?
>>
>> Note I'm not a Python person and I have no axes to grind here.  This is
>> just a question for my general education.
>>
>> Mark
>
> Advantages of Python:
>
> 1). More and better mature standard libraries (Languages don't matter,
> libraries do).
> 2). Multiple programming paradigms (including functional style
> programming see itertools, functools, operator modules (lambda, map,
> filter, reduce, sum etc builtins), higher order functions, list
> comprehension, blah, blah)
> 3). Better OO implementation. (I used to hate OO until I started using
> Python)
> 4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
> said. Bindings for almost any lib worth using, at least on *nix)
> 5). Clearer syntax.
> 6). Better namespace management. (nobody ever talks about this, but
> Python seems to be one of the few languages that gets symbol management
> right from a users perspective)
> 7). Easier packaging and distribution system.
> 8). Ubiquity! Python is everywhere. Lisp, bleh.
> 9). Relatively good docs (PHP has better).
> 10). Fewer perceived community assholes. Large community.
> 11). Less fragmentation.

Are any of these not subjective?

> Advantages of Lisp:
>
> Learning a functional language can improve your programming range and

Lisp is much more than a functional language.

> depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
> when there's mind bending Haskell. I'd go as far as saying I believe
> Haskell has a better fate than Lisp.

Yeah, that's pretty far.

> On Lisp Macros:
>
> I think they are overrated, and in general cause more harm than good.
> It's the reason I find Lisp-like programs difficult to grok, maintain
> and extend. Cos every smart ass wants to needlessly write his own mini
> language to the point of absolute obfuscation. Naturally, I'm supposed
> to be awed by his mischievous cleverness.

Uh huh.  Can you cite examples of this?  Sounds like you're just
making stuff up here.  Contrary to popular belief, writing a Lisp
macro that warps your mind and introduces a totally un-CL-like
semantics is extremely difficult.  Most of the people who are good
enough at CL to do it (I'm certainly not one of them) are also
experienced enough to know when it's the right choice.

And Lisp environments all support getting the macroexpansion,
documentation, and source of any unfamiliar macro you might happen
upon, so really this is not as much of a problem as you might
fantasize it to be.

> Conclusion:
>
> The semantics or features of a language is almost irrelevant today.
> Developers want to put the lego pieces together, they don't want to
> make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
> was popular in the 70s, but it's boring and expensive today. Today,
> when a developer needs to solve a problem, the question they ask is,
> "Is there a library for that?". If the answer is no, they a more likely
> to switch to a language that provides a library that solves their
> problem. The challenge for developers today is software architecture,
> robustness and scalability, not language purity or semantics. The Lisp,
> and to an extent Haskell, community will never ever ever grok this.
> They'll continue to wonder why an "inferior" language like Python keeps
> getting popular. It will always escape them that it might be because
> Python is actually easier to use for most people to write "real world"
> applications. It has good usability.

I don't agree with a lot of what you say in this paragraph, but I
you're right that libraries are crucial.  That's why I wish there were
more people writing Lisp libraries instead of being scared away by
sheer fabrications like the stuff that's appearing in this thread.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?

"Can you imagine if carpenters were like computer scientists?  Some of 
 them would argue that it's not necessary to own a hammer because the 
 butt of a screwdriver is naildriver-complete." 
  -- Barry Margolin in comp.lang.lisp 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Paul Rubin  writes:

> There is just not that much boilerplate in Python code, so there's
> not so much need to hide it.

Well, of course there is.  There are always going to be patterns in
the code you write that could be collapsed.  Language has nothing to
do with it; Lisp without macros would still be susceptible to
boilerplate.

Here's a concrete example:

  (let ((control-code (read-next-control-code connection)))
(ecase control-code
  (+break+
(kill-connection connection)
(throw :broken-by-client))
  (+status+
(send-status-summary connection))
  ((+noop+ +keep-alive+
  ;; +X+ indicates a constant

The standard ECASE macro encapsulates this pattern: Compare the
variable control-code to +break+.  If the two are EQL, then run the
code provided in the +break+ clause.  Likewise for +status+.  In the
last clause, the test-form is a list, so the generated code will
compare control-code to either +noop+ or +keep-alive+.  If it is EQL
to either, it runs the body of that clause, which happens to be blank
here.  The E in ECASE stands for "error," so if control-code doesn't
match any of these choices, the generated code will signal an error
with the following text "CONTROL-CODE fell through ECASE expression;
was not one of: +BREAK+, +STATUS+, +NOOP+, +KEEP-ALIVE+".  All of that
boilerplate is handled by the macro.  In Python, I would need to do
something like:

  control_code = connection.read_next_control_code()
  if control_code == +break+:
connection.kill()
throw blah
  else if control_code == +status+:
connection.send_status_summary()
  else if control_code == +noop+ || control_code == +keep_alive+:
  else:
error "CONTROL_CODE fell through conditional cascade; was not one of 
+BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"

To change what control codes you want to check for, you need to add
conditionals for them and keep the error text relevant.  The reality
is that a computer could be doing this for you, leaving your code
simpler and more easily changed.

Now someone will complain that the ECASE code means nothing until I
understand ECASE.  Yep.  But once you understand ECASE, you can look
at that code and, *at a glance*, see how control flows through it.  In
the equivalent Python code, I need to walk through each conditional
and make sure they're all following the same pattern.  If you're not
convinced, extend the example to 12 different control codes.

Note also that ECASE is just expanding to the COND conditional.  There
is nothing mind-bending (or even mind-twisty) going on inside of it.
It's simply a way of expressing a common syntactic pattern in
higher-level terms.  To prove that macros are not the frightening
beasts you guys are making them out to be:

CL-USER 13 > (let ((*print-case* :downcase))
   (pprint (macroexpand '(ecase control-code
   (+break+ 
(kill-connection connection)
(throw :broken-by-client))
   (+status+
(send-status-summary connection))
   ((+noop+ +keep-alive+))

(let ((#:g17558 control-code))
  (case #:g17558
(+break+ (kill-connection connection) (throw :broken-by-client))
(+status+ (send-status-summary connection))
((+noop+ +keep-alive+))
(otherwise (conditions::ecase-error #:g17558 '(+break+ +status+ (+noop+ 
+keep-alive+))

If you treat the #:G17548 as just a weirdly-named variable, you can
see that the code is just expanding into the standard CASE macro.  I
can in turn expand this CASE to:

CL-USER 14 > (let ((*print-case* :downcase))
   (pprint (macroexpand '(case #:g17558
   (+break+ 
(kill-connection connection) (throw 
:broken-by-client))
   (+status+
(send-status-summary connection))
   ((+noop+ +keep-alive+))
   (otherwise (conditions::ecase-error 
#:g17558 '(+break+ +status+ (+noop+ +keep-alive+

(let ((#:g17559 #:g17558))
  (cond ((eql '+break+ #:g17559) (kill-connection connection) (throw 
:broken-by-client))
((eql '+status+ #:g17559) (send-status-summary connection))
((or (eql '+noop+ #:g17559) (eql '+keep-alive+ #:g17559)) nil)
(t (conditions::ecase-error #:g17558 '(+break+ +status+ (+noop+ 
+keep-alive+))

COND is the Lisp conditional form.

As you can see, ECASE does not blow your mind, but simply names and
standardizes a common pattern of code.  It expands into standard
macros.  And ECASE is so easy to write that most Lisp programmers have
extended versions of it in their personal libraries.  And most of
these are named GENERIC-CASE or STRING-CASE, etc. and m

Re: merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
> "Oh yes, macros give you great power, and with great power comes great
> responsibility. Be careful." then, no doubt, we'd take you guys more
> seriously. But we don't hear that -- we hear Lispers going on and on about

And, of course, we do say that.  Nobody wants people running around
writing incomprehensible macros.  How does that help anyone?
Fortunately, it's not a problem in practice, because most macros map
quite straightforwardly to Lisp constructs and almost no one has the
time or the intelligence to write the mini-languages that seem to be
terrifying you so much.

> how great it is that they can easily redefine every corner of the
> language. Do you blame people for *believing them* and imagining that
> reading Lisp code is like following some ghostly will-o-the-wisp across a
> swamp, where nothing is what it seems and the landscape is forever
> shifting?

"every corner of the language"?  Please.  Why are you so post-happy
when it's quite obvious that you don't know enough about Lisp to
attack it?

Most programmers do not write macros that are incredibly difficult to
understand.  Beginners might, but beginners might also write
incomprehensible code in Java or Python.  As you learn Lisp, you learn
to keep your macros tied to the underlying Lisp.  You learn to make
the expansions into function or method defintions, instead of
reinventing the wheel.  You leverage what Lisp offers, instead of
redefining it.

The only times you are really going to find completely alien semantics
are in textbooks (like Prolog in Lisp), in very ambitious and large
projects where the new semantics are the only reason you'd use the
code in the first place (like Franz's AllegroProlog or Marco
Baringer's CPS transformer), or in code written by beginners.  Please
stop spreading FUD about this.  In real life, macros make coding more
pleasant and make your code more maintainable.  They are something to
embrace, not something to fear.

To provide a more solid example, Peter Seibel's book _Practical Common
Lisp_ (full text at http://www.gigamonkeys.com/book) provides a set of
classes for parsing binary files.  Some user code provided in the
book:

(define-binary-class id3v2.3-tag (id3-tag)
  ((extended-header-size (optional :type 'u4 :if (extended-p flags)))
   (extra-flags  (optional :type 'u2 :if (extended-p flags)))
   (padding-size (optional :type 'u4 :if (extended-p flags)))
   (crc  (optional :type 'u4 :if (crc-p flags extra-flags)))
   (frames   (id3-frames :tag-size size :frame-type 
'id3v2.3-frame

This code very closely mirrors the standard DEFCLASS in Common Lisp,
so a maintainer knows right away what to expect.  The macro expands
into DEFCLASS and DEFMETHOD forms.  There's nothing mysterious going
on here; the macro is just a friendlier syntax for expressing an idea.
What I get from this are methods that read binary data into objects of
the class that I've just defined (*).  That's all - methods and a
class.  There is no mind-bending going on at all here.  It's true of
course that I have to understand how the macro works.  But without it,
I'd have to write and/or read through a lot of similar-looking code
for handling binary data.  Which would you prefer?

Without a macro like this, the code required would be the definition
of boilerplate.  Instead of specifying declaratively the order and
type of fields in the binary file, I would write code to read each
field from the file and then store the result in an object.  I'd also
have to take into account fields that are optional.  This is ugly and
boring code.  Did I mention that DEFINE-BINARY-CLASS also defines
methods to save these objects back to binary files?  Because it does.

So why not write this code once and then take advantage of it in the
future to get more expressive, less boring programs?



*  If you don't believe me, here is the expansion of the code I cited above:

http://paste.lisp.org/display/31799

Just methods and a class.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Bill Atkins <[EMAIL PROTECTED]> writes:

> "every corner of the language"?  Please.  Why are you so post-happy
> when it's quite obvious that you don't know enough about Lisp to
> attack it?

In addition to macros that define classes or methods, a common macro
is the WITH-* macro, which sets up some kind of context, runs the body
inside that context, and then does some cleanup.

For example, my Lisp vendor, LispWorks, provides the macro MP:WITH-LOCK :

(mp:with-lock (*the-big-lock*)
  (do-something-atomic)
  (something-else)
  (almost-odone))

The generated first seizes a process lock called *THE-BIG-LOCK*, runs
the code in the body and then releases the lock.  I never have to
worry that I've taken a lock without releasing it, because LispWorks
has encoded that behaviour into MP:WITH-LOCK (and if they handn't,
this macro is trivial to write).

Now I can tell if I'm keeping a lock around too long because all the
code that appears inside this WITH-LOCK is all the code that I'm
locking.  Further, the generated code is surrounded by an
UNWIND-PROTECT, which means that if an error is raised or anything
abnormal happens in the dynamic scope of the UNWIND-PROTECT, Lisp will
run cleanup code as it flees back up the stack.  So if there is an
error in my code, it does not prevent other processes from seizing
that lock, because it will be released as the error is signaled.

Here is the expansion:

CL-USER 7 > (write (macroexpand '(mp:with-lock (*the-big-lock*)
   (do-something-atomic)
   (something-else)
   (almost-odone)))
   :pretty t :case :downcase)
(let ((#:g17553 *the-big-lock*))
  (when (mp:process-lock #:g17553)
(unwind-protect
(progn (do-something-atomic) (something-else) (almost-odone))
  (mp::in-process-unlock #:g17553
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

"mystilleef" <[EMAIL PROTECTED]> writes:

> Bill Atkins wrote:
>> Are any of these not subjective?
>
> Objectivity is in the eye of the beholder.

Well, for example, "Lisp uses a fully-parenthesized notation for
writing programs" and "Python has significant whitespace" are both
objective facts.  Agreed?  There's nothing subjective about those two
facts.  Do any of your points approach that level of objectivity?

>> Lisp is much more than a functional language.
>
> Maybe so. But I've only ever appreciated its functional aspects. I
> wouldn't choose Lisp or its derivatives for OO related tasks even if
> I'm high.

Ah yes.  Glad you went into so much detail.

>> Uh huh.  Can you cite examples of this?  Sounds like you're just
>> making stuff up here.  Contrary to popular belief, writing a Lisp
>> macro that warps your mind and introduces a totally un-CL-like
>> semantics is extremely difficult.  Most of the people who are good
>> enough at CL to do it (I'm certainly not one of them) are also
>> experienced enough to know when it's the right choice.
>
> Any sizable Lisp applications will make extensive use of macros. Emacs
> and magic ( the web framework) come to mind. My experience has shown
> that nobody but the person who writes the DSL extension can maintain
> their code. 

What experience is this?

> The benefits of extending a language in a domain specific
> manner are exaggerated. 

Great, it's settled then!

(Look elsewhere in this thread for my post about Peter Seibel's
DEFINE-BINARY-CLASS macro.)

> My observation is that macros are important to
> Lisp and it's derivative because they lack libraries to begin with.
> Common problems solved using macros in Lisp and friends are solved
> using specialized libraries in most other languages. And I like the

Macros are not a substitute for libraries, nor are libraries a
substitute for macros.  Having macros lets you build more powerful and
more expressive libraries.

> specialized libraries route. Meta-programming just doesn't tickle my
> fancy. It just spells maintainance nightmare.

So it's not just macros but metaprogramming as a whole that bothers
you?  You must have an enjoyable time writing programs.

>> And Lisp environments all support getting the macroexpansion,
>> documentation, and source of any unfamiliar macro you might happen
>> upon, so really this is not as much of a problem as you might
>> fantasize it to be.
>
> How's this a good thing? I don't need a Python environment to grok
> Python code.

Nor do you need it to grok Lisp code.  The environment is there to
make your life better.  I was merely responding to your original claim
that it's impossible to make sense of code that uses macros.

>> I don't agree with a lot of what you say in this paragraph, but I
>> you're right that libraries are crucial.  That's why I wish there were
>> more people writing Lisp libraries instead of being scared away by
>> sheer fabrications like the stuff that's appearing in this thread.
>
> People only contribute to things they understand and appreciate. More
> people would be writing Lisp libraries if it was worthwhile.
> Apparently, it doesn't seem to be. A few years ago, I tried to write an
> editor is Scheme. The experience was appalling. I was able to write a
> fully functional prototype editor in less than a week in Python.
> Shockingly, at the time, I had no experience in Python. Guess which
> community I was inclined to contribute to afterwards. I hear stories
> similar to mine time and again, yet the Lisp community won't take heed.
> They'd rather squeal about the superiority of macros and whine about
> their frustrations in Python news groups.

Hmm.  Anecdotal evidence about Scheme (a vastly and fundamentally
different language from Common Lisp).  Again, you've clinched it for
me.

I do believe that the "squealing and whining about macros" was a
response to Pythonistas claiming that macros are not useful.  This was
in turn in response to a foolishly (trollishly?) cross-posted
question.  It is not as if we have invaded your newsgroup.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

"mystilleef" <[EMAIL PROTECTED]> writes:

>> Macros are not a substitute for libraries, nor are libraries a
>> substitute for macros.  Having macros lets you build more powerful and
>> more expressive libraries.
>>
> And not having them helps you build less powerful and expressive
> libraries?

If you told me a turbocharger makes a car accelerate faster, and I
said, "So not having a turbochanger helps your car accelerate slower?"
what would be your reaction?

>> > How's this a good thing? I don't need a Python environment to grok
>> > Python code.
>>
>> Nor do you need it to grok Lisp code. The environment is there to
>> make your life better.  I was merely responding to your original claim
>> that it's impossible to make sense of code that uses macros.
>>
>
> Not impossible, just painstaking.

No more so than seeing a function you don't understand.  Please be
realistic here.  Read through the other posts in this thread, where
this same issue is refuted ad nauseam.

>> Hmm.  Anecdotal evidence about Scheme (a vastly and fundamentally
>> different language from Common Lisp).  Again, you've clinched it for
>> me.
>>
>
> I don't believe my experience would have been marginally different had
> I used Common Lisp.

Well, believe it.  The languages are very different, although they
appear superficially similar to anyone who isn't familiar with both.
The similarity is much like that between Python and Ruby.  The two
appear to have very similar syntax, but anyone who knows both knows
that they're quite different underneath.

>> I do believe that the "squealing and whining about macros" was a
>> response to Pythonistas claiming that macros are not useful.  This was
>> in turn in response to a foolishly (trollishly?) cross-posted
>> question.  It is not as if we have invaded your newsgroup.
>
> Pythonistas are not saying macros are not useful. They are saying their
> usefulness in overrated, exaggerated and needless in the context of
> Python. They are saying they don't see what they are missing and along
> with the rest of the world couldn't give a damn whether or not it is
> ever implemented in Python. Okay, I can't speak for all Pythonistas,
> but that's what I'm saying.

Of course they're overrated - *because you don't have them*.  It would
be amusing to see how Python's collective tune would change if Guido
issued a royal edict that "Python 3000" (hehehehe) will support
syntactic extensions.  If Python had macros, would you really
complain, or would you appreciate the extra expressive power?

On the other hand, I am willing to agree with all of you Pythoners
that Python is winning in the library department.  So are Perl and
Ruby.  It would be silly for me to claim that libraries are
"overrated," just because other languages have more of them.  The
truth is that I would like to have macros, libraries, and Lisp's
interactive development model, all at once.

But your claim upthread that Lisp doesn't have libraries because it's
not "worthwhile" is unfounded.  When all of the AI companies collapsed
in the late 80's and early 90's, Lisp went comatose by association.
The revival of Lisp as a tool for doing modern programming dates back
only to about 2000 or so.  So six years along, we are behind other
languages that have had active communities for ten years (Ruby),
fifteen years (Python), and nearly twenty years (Perl).  I am not
worried about the future of Lisp libraries.  We already have some:

 - CL-PPCRE, a pure-Lisp regular expression package that is faster than Perl's
 - Hunchentoot, a complete web server and web development framework
 - CAPI, a proprietary but excellent GUI library
 - CommonSQL (and CLSQL, its open-source offspring)
 - parenscript, an embeddable Lisp that compiles to Javascript, letting 
   you use macros in your Javascript code
 - assorted useful libraries, like MD5, base64, SDL, XML parsers, web
   page fetchers, testing frameworks
 - bindings to the common C libraries, like GD, Tk, Gtk+

We will get there, in time.  Lisp is still the only language in
history to linger in "mostly dead" status for a decade and then be
resurrected; it is capable of more surprises yet.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Bill Atkins <[EMAIL PROTECTED]> writes:

> worried about the future of Lisp libraries.  We already have some:
>
>  - CL-PPCRE, a pure-Lisp regular expression package that is faster than Perl's
>  - Hunchentoot, a complete web server and web development framework
>  - CAPI, a proprietary but excellent GUI library
>  - CommonSQL (and CLSQL, its open-source offspring)
>  - parenscript, an embeddable Lisp that compiles to Javascript, letting 
>you use macros in your Javascript code
>  - assorted useful libraries, like MD5, base64, SDL, XML parsers, web
>page fetchers, testing frameworks
>  - bindings to the common C libraries, like GD, Tk, Gtk+

Lest anyone interpret that list as exhaustive: http://www.cl-user.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

"Carl Banks" <[EMAIL PROTECTED]> writes:

>> You're right, in part: My implicitly linking Python's pros or cons with
>> its stupid marketing hype is, I think, an ad hominem argument.
>
> Ahem.  Calling Python programmers "flies".

For what it's worth, I don't think this was called for, either.

> Whatever, fanboy.

Weak.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Paul Rubin <http://[EMAIL PROTECTED]> writes:

> Bill Atkins <[EMAIL PROTECTED]> writes:
>> Lest anyone interpret that list as exhaustive: http://www.cl-user.net/
>
> What have you got for concurrency?  How would you write a
> multi-threaded web server in Lisp?

Multithreading is not a standard part of ANSI CL, but in practice all
Lisps (with the major exception of the CLISP implementation) support
threading.  

Hunchentoot is, in fact, a multi-threaded web server written in Lisp.
:)  There are also others, like AllegroServe and Araneida.

There are compatibility layers that smooth over some of these
implementation-dependent areas of Common Lisp.  Bordeaux-threads is
the package that provides a common interface to the different
threading implementations:

  http://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

"Paddy" <[EMAIL PROTECTED]> writes:

> Fast. Very fast!

You hit it on the head.  Interpreted langauges were the efficiency
breakthrough we've all been waiting for.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Sat, 09 Dec 2006 17:01:15 -0500, Ken Tilton wrote:
>
>>> How's this a good thing? I don't need a Python environment to grok
>>> Python code.
>> 
>> How would that be a bad thing? Do you do a lot of programming without a 
>> Python environment. But I love the wall of flak you are throwing up. :)
>
> Actually, yes, sometimes it is useful to print code out and read it on the
> train, or in the bath, without the advantage of syntax highlighting,
> pretty-printing, parenthesis-balancing or code folding. Not necessarily as
> pleasant as having all those things, but it is nice that working Python
> code is, by definition, already formatted correctly for pretty printing.
> Even if you're stuck on some god-forsaken Windows PC with just Notepad,
> you can still read Python code.
>
> Now, *writing* Python code with Notepad isn't as easy, but it is still
> doable. How about Lisp code?

Of course we can read Lisp without IDE's; we look for indentation cues
just as you guys do.

> That's not a criticism of Lisp exactly, but a reminder to think about not
> just what problem you're trying to solve, but what resources you will have
> to solve it. If you *know* that you're going to need to edit code by
> ssh-ing across an high-latency connection to a machine without Emacs, then
> Lisp will probably not be the best solution.

Oh no?  Emacs lets you save and write files over an SSH connection,
even if you end up in the strange straw man situation you're
describing ("yeah, but can you edit Lisp if your keyboard doesn't have
paren keys?").
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

>> Or (defmethod name :after ..)?
>
> I don't even know what that means. 

And yet you continue to post as if you know Common Lisp...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

"Paddy" <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] wrote:
>
>> > Python has to rely more on using the right algorithm...
>>
>> This sound familiar: "Macros are dangerous!"
> Yes. I changed my opinion on advocating Python having macros in one
> of our long threads on the subject. Maintainance counts.

Yes, it does, but that should take you to exactly the opposite
conclusion.

>> "Compilers make you lazy."
> This is new to me. In fact, for the compiled languages available to me.
> Using them *first* would be the difficult choice.

These are not real sentences, but if you're saying that compiled
languages make programming more difficult, then you're simply using
the wrong compiled languages.  Lisp is a dynamic language that also
supports compilation to native code.

> Unlike Lisp, Python does not have a ubiquitous compiler. It is
> therefore
> made to interface nicely with compiled languages. Other compiled

What on earth does this mean?  You're saying that because Python
doesn't have a compiler, it can interface more easily to compiled
languages?  That's nonsense.

Further, most Lisp implementations support an interface to C that
doesn't require you to write and compile C code in order to use C
extensions in Lisp.  Can Python do the same more "nicely" than Lisp?

> language users see the need for dynamic interpreted languages like
> Python and maintain links Python such as the Boost Python C++
> wrapper. IronPython for .NET, Jython for Java.
> Lisp is its own interpreter and compiler, which should be a great
> advantage, but only if you don't make the mistake of ignoring the
> wealth of code out there that is written in other languages.

Um.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

greg <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] wrote:
>> compilers are GREATLY facilitated by having a
>> macro facility because (at first blush) all you need to do is to
>> macro-expand down to something you know how to turn into code.
>
> There's no way you could compile Python to efficient
> machine code just by macro expansion. You'd also need
> some very heavy-duty type inferencing.

When I used to use Ruby a lot, I believed this line that the Ruby
community fed itself (and apparently Python feeds itself as well):
Ruby/Python has to be interpreted because it's too dynamic.  This is
wrong, of course.  A compiler shifts a lot of decisions that an
interpreter would have to make at runtime to compile-time.  There is
no reason a dynamic language can't enjoy this efficiency.  On the
other hand, if Python is doing a hash lookup on every function call,
as Alex Mizrahi claims, compilation may not do much to smooth over
such awkwardness.

> Python is extremely dynamic, even more so than Lisp.
> That's why compiling Python is hard, not because it
> doesn't have macros.

Uh huh.  "More so than Lisp"?  Just making stuff up now?

Despite its dynamism, Lisp is quite compilable.  For example, I can
redefine classes, functions, macros, etc. at runtime and compiled code
referring to the old code will still work.  You are conflating
dynamism with interpretedness, and that's incorrect.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

greg <[EMAIL PROTECTED]> writes:

> When moving a set of statements in Python, you
> are usually selecting a set of complete lines,
> cutting them out and then pasting them in
> between two other lines somewhere else.

You're missing Ken's point, which is that in Lisp an s-expression
represents a single concept - I can cut out the second form of an IF
and know that I'm cutting the entire test-form.  I don't have to
choose the correct "set of complete lines" to correctly move code
around.

> Having edited both Lisp and Python code fairly
> extensively, I can't say that I find editing
> Python code to be any more difficult or error
> prone.

How extensively?

> On the plus side, Python makes less demands on the
> capabilities of the editor. All you really need
> is block-shifting commands. Bracket matching is
> handy for expressions but not vital, and you
> certainly don't need bracket-based auto-indenting.

Oh, please.  So we should restrict the power of the languages we
choose just to make sure that our code can be edited in Notepad?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

greg <[EMAIL PROTECTED]> writes:

>> A compiler shifts a lot of decisions that an
>> interpreter would have to make at runtime to compile-time.  There is
>> no reason a dynamic language can't enjoy this efficiency.
>
> I'm not saying that it's impossible to compile
> Python, only that's there's a lot more to it than
> just macro expansion. The OP was saying something
> like "If you added macros, you might get a compiler
> for free", which is clearly far from true.

Yeah, my mistake - I simply glided right past the "just by macro
expansion."  Oops.  :)

>> Despite its dynamism, Lisp is quite compilable.
>
> Please correct me if I'm wrong, but as I understand,
> getting efficient code out of a Lisp compiler requires
> putting type declarations into the source.
>
> If you put the same declarations into a piece of
> Python code, then of course it would be fairly
> straightforward to compile it efficiently. But it
> wouldn't really be dynamic Python any more.

Type declarations can squeeze out extra efficiency, but vanilla Lisp
without type declarations will still beat Python, both because the
language is designed to compile well and because compilers for Lisp
are generally very mature.  So it is not the case that type
declarations are the only thing that make Lisp efficient.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

greg <[EMAIL PROTECTED]> writes:

>>>Having edited both Lisp and Python code fairly
>>>extensively,
>>
>> How extensively?
>
> Enough to know what I'm talking about. Tens
> of thousands of lines of Lisp and Scheme, and
> hundreds of thousands of lines of Python, I
> would estimate.
>
> Seeing as you asked, how much Python code have
> you or Ken edited?

To be honest, very little Python code.  But I have manually indented
and rearranged enough code in other line-based languages to appreciate
the convenience of s-expression-based commands.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Paul Rubin  writes:

> Pascal Costanza <[EMAIL PROTECTED]> writes:
>> May you have tried the wrong Lisp dialects so far:
>> 
>> (loop for i from 2 to 10 by 2
>>do (print i))
>
> The loop language is so complicated and confusing that I never
> bothered trying to learn it.  I always used simpler primitives to
> write loops and it was always enough.

I think you're missing out.  If you don't find LOOP appealing, look
for the ITERATE package.  ITERATE is a more Lispy, more extensible
replacement for LOOP.

>> This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
>> you should implement this using recursion, but you really don't have
>> to. ;)
>
> You can't really use that much recursion in Lisp because of the lack
> of guaranteed TCO.  I think that makes it reasonable to say that
> Scheme is a functional language but Lisp is not.  ("Functional" = it's
> reasonable to code in a style where the only way to connect variables
> to values is lambda binding (maybe through syntax sugar), so all loops
> are implemented with recursion).

You should be pragmatic about this - I have never used a CL
implementation that didn't do TCO optimization (indeed, are there
any?).  Although the standard doesn't require it, I treat it as a de
facto requirement and don't worry too much about it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

I V <[EMAIL PROTECTED]> writes:

> On Sun, 10 Dec 2006 03:18:07 -0500, Bill Atkins wrote:
>> We're not counting lines here, you goon.  We're talking about how
>> expressive constructs are and how closely they match your concept of
>> what you want to do.  The conditional example is lower-level; you're
>> talking to the interpreter instead of saying what you want to achieve.
>> You're having to repeat things because that's what the language asks
>> of you, instead of describing in a higher-level way what you're
>> actually doing.
>
> To be a little provocative, I wonder if the idea that you're "talking to
> the interpreter" doesn't apply more to lisp than to python; you can have
> any syntax you like, as long as it looks like an AST. 

Uhhh?

> One of the things I've always found off-putting about lisp as that all the
> syntax looks the same. In Algol-derived languages, each syntactic
> construct has a fairly distinctive appearance, so when, for instance, I
> encounter a for loop, I can quickly recognize that that's what it is, and
> bracket out the "scaffolding" and pick out the details that interest me.
> With lisp, I can't do that, I have to read through the sexp, decide on
> what syntax it is, and then remind myself where to look for the relevant
> specific details.

"Decide on what syntax it is"?  Examples?

> Now, this might well be just due to my comparative lack of familiarity
> with lisp; I'd be interested to hear if you lisp people find different
> lisp constructs as visually distinctive as constructs in python (or other
> similar languages). But I think what people are getting at when they
> complain about "all the brackets" in lisp may actually be this issue of
> a visual distinction between different constructs (this is also a reason
> why having a limited number of syntactic constructs can be helpful - there
> are a probably a  limited number of stereotypical layouts a programmer can
> keep in their mind at once).

We rely on indentation for readability just as you guys do.  Lisp
programs are not chaotic arrangements of parentheses and symbols; code
structure is made apparent through indentation.

(Why are people from c.l.p calling parentheses "brackets"?)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

greg <[EMAIL PROTECTED]> writes:

> Ken Tilton wrote:
>
>> McCarthy: "Is code also data in Python?"
>> Norvig: "No."
>
> I don't think that was the right answer. He should have
> said "Yes", and then shown McCarthy eval() and exec.
>
> Code isn't quite as *convenient* to work with as data
> in Python as it is in Lisp, but that doesn't mean it
> can't be done.

This sounds like the Turing argument, because that convenience makes
all the difference.  Raw, unparsed text is nothing like trees of
symbols and objects when it comes to transforming or analyzing code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

greg <[EMAIL PROTECTED]> writes:

> André Thieme wrote:
>>  (aif (timeConsumingCalculation)
>>  (use it))
>
> I think the answer is that you just wouldn't do
> that in Python at all. Having magic variables
> spring into existence in your local namespace
> as a side effect of calling something is just
> not Pythonic. (It is very Perlish, on the other
> hand.)

Anaphoric macros are controversial in CL, too, for just that reason.
But there are a parallel set of macros that explicitly bind a variable
so you can get the convenience without the weirdness:

(bif (items (remove-if-not #'useful-p big-list-o-items))
  (format t "~D items~%" (length items))
  (format t "Nothing useful.~%"))

You can rewrite the expression in the grandparent as:

  (aif (result (timeConsumingCalculation))
(use result)

or, more idiomatically:

  (awhen (result (time-counsuming-calculation))
(use result))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Paul Rubin  writes:

>> In fact, all previously correct programs continue to work as before,
>> and in addition, some hitherto incorrect programs become correct.
>> That's an increase in power: new programs are possible without losing
>> the old ones.
>
> There's more to power than making more programs possible.  We also
> want to be able to distinguish correct programs from incorrect ones.
> Lisp has the power to eliminate a large class of pointer-related
> errors that are common in C programs, so Lisp is more powerful than C
> in that regard.  Increasing the number of programs one can write in
> the unfounded hope that they might be correct is just one way to
> increase power.  You can sometimes do that by adding features to the
> language.  Increasing the number of programs you can write that are
> demonstrably free of large classes of errors is another way to
> increase power.  You can sometimes do that by REMOVING features.
> That's what the Lisp holdouts don't seem to understand.
>
>> Right. GC gets rid of /program errors/. Pure functional programming
>> gets rid of /programs/.
>
> GC also gets rid of programs.  There are programs you can write in C
> but not in Lisp, like device drivers that poke specific machine
> addresses.

I'm sure this would be news to the people who wrote the operating
system for the Lisp machine.

What makes you think that a Lisp implementation couldn't provide this?

-- 
There are three doors. Behind one is a tiger. Behind another: the
Truth. The third is a closet... choose wisely.

(remove-if (lambda (c) (find c ";:-")) "a;t:k-;[EMAIL PROTECTED];p:i-.:e-d:u;")
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Paul Rubin  writes:

> [EMAIL PROTECTED] writes:
>> I should assume you meant Common Lisp, but there isn't really any
>> reason you couldn't
>> 
>>  (poke destination (peek source))
>
> That breaks the reliability of GC.  I'd say you're no longer writing
> in Lisp if you use something like that.  Writing in this "augmented
> Lisp" can be ok if well-localized and done carefully, but you no
> longer have the guarantees that you get from unaugmented Lisp.  By
> adding one feature you've removed another.

Whatever do you mean?  The portion of memory used for memory-mapped
registers is simply excluded from GC; everything else works as normal.
All modern Lisps (yes, *Common* Lisps) support a foreign-function
interface to talk to C libraries.  Data involved with these kinds of
interface is ignored by the GC, for obvious reasons.  Do you claim
that these implementations are not truly Lisps?

-- 
There are three doors. Behind one is a tiger. Behind another: the
Truth. The third is a closet... choose wisely.

E-mail me at:
  (remove-if (lambda (c) (find c ";:-")) "a;t:k-;[EMAIL 
PROTECTED];p:i-.:e-d:u;")
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

This is not a response to any particular post, but rather to the
general argument that macros are not as useful as we Lispers claim.

Here is a fairly complete GUI RSS reader in 90 lines of Lisp (the GUI
code itself is 90 lines, but it makes use of some RSS reading/writing
code I had laying around and two public CL libraries: s-xml and
trivial-http).  The code employs a handy macro called DEFINE-INTERFACE
that LispWorks provides with their CAPI toolkit.  I hope this will be
useful as an illustration of what macros (and Lisp in general) can do,
and as an example of what a moderately practical CL application looks
like.

The application presents a list of feeds and allows the user to add
new feeds or to delete existing feeds.  The feeds are presented as a
tree, with each channel acting as a parent to several items.  The user
can refresh all of the feeds with the "Refresh All" button.
Double-clicking on any item will display its description field (as in
the screenshot).  Each channel shows the number of unread articles and
the articles are arranged so that the unseen articles appear before
the articles that have already been read.

Important things to note:

 1) the DEFINE-INTERFACE syntax closely resembles the syntax of the
standard DEFCLASS macro, so newcomers have a basic idea of what
DEFINE-INTERFACE is going to do

 2) the expansion ( http://galoot.org/~bill/code/rss-reader/expanded.lisp )
of just the DEFINE-INTERFACE is quite involved, a testament to
the amount of work the macro saves

 3) much of the GUI can be specified declaratively because of the
DEFINE-INTERFACE syntactic abstraction, and this declarativeness
makes it very easy for maintainers to understand what's going on

 4) even without knowing the implementation of DEFINE-INTERFACE and
even without prior experience with it, one can make good guesses
about what it does

 5) the GUI code is stunningly concise

Here is the GUI code alone:  

  < http://galoot.org/~bill/code/rss-reader/rss-gui.lisp >

Here is a screenshot of the application in development:

  < http://galoot.org/~bill/code/rss-reader/development.png >

and two screenshots of the application in use

  < http://galoot.org/~bill/code/rss-reader/in%20action.png >
  < http://galoot.org/~bill/code/rss-reader/in%20action%202.png >

Here are the support files:

  < http://galoot.org/~bill/code/rss-reader/ >

Here is an OS X universal binary (run at your own risk; I've only
done very basic testing):

  < http://galoot.org/~bill/code/rss-reader/BarebonesRSS.app.tar.gz >

Enjoy.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re:

[Bill Atkins]

John Bokma <[EMAIL PROTECTED]> writes:
>
> Isn't it crazy that one person is allowed to create such a huge mess 
> everytime he posts?

Isn't it crazy that one person willfully creates such a mess every
time Xah posts?  Shush!

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

"Kay Schluehr" <[EMAIL PROTECTED]> writes:

> And then the 12th vanished Lisper returns and Lispers are not
> suppressed anymore and won't be loosers forever. The world will be

The mark of a true loser is the inability to spell 'loser.'  Zing!

> them as zealots, equipped with the character of suicide bombers. No,

A very reasonable comparison.  Yes, the more I think about it, we Lisp
programmers are a lot like suicide bombers.

Doofus.

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

[EMAIL PROTECTED] (Alex Martelli) writes:

> Ken Tilton <[EMAIL PROTECTED]> wrote:
>...
>> > Absolutely.  That's why firms who are interested in building *seriously*
>> > large scale systems, like my employer (and supplier of your free mail
>...
>> > Obviously will not scale.  Never.
>> > 
>> > Well... hardly ever!
>> 
>> You are talking about being incredibly popular. I was talking about 
>
> Who, me?  I'm talking about the deliberate, eyes-wide-open choice by
> *ONE* firm -- one which happens to more or less *redefine* what "large
> scale" computation *means*, along many axes.  That's got nothing to do
> with Python being "incredibly popular": it has everything to do with
> scalability -- the choice was made in the late '90s (and, incidentally,
> by people quite familiar with lisp... no less than the reddit.com guys,
> you know, the ones who recently chose to rewrite their side from Lisp to
> Python...?), based on scalability issues, definitely not "popularity"
> (Python in the late '90s was a very obscure, little-known language).
>
>> kenny (who is old enough to have seen many a language come and go)
>
> See your "many a language" and raise you one penny -- besides sundry
> Basic dialects, machine languages, and microcode[s], I started out with
> Fortran IV and APL, and I have professionally programmed in Pascal (many
> dialects), Rexx, Forth, PL/I, Cobol, Lisp before there was a "Common"
> one, Prolog, Scheme, Icon, Tcl, Awk, EDL, and several proprietary 3rd
> and 4th generation languages -- as well of course as C and its
> descendants such as C++ and Java, and Perl. Many other languages I've
> studied and played with, I've never programmed _professionally_ (i.e.,
> been paid for programs in those languages), but I've written enough
> "toy" programs to get some feeling for (Ruby, SML, O'CAML, Haskell,
> Snobol, FP/1, Applescript, C#, Javascript, Erlang, Mozart, ...).
>
> Out of all languages I know, I've deliberately chosen to specialize in
> Python, *because it scales better* (yes, functional programming is
> _conceptually_ perfect, but one can never find sufficiently large teams
> of people with the right highly-abstract mathematical mindset and at the
> same time with sufficiently down-to-earth pragmaticity -- so, for _real
> world_ uses, Python scales better). When I was unable to convince top
> management, at the firm at which I was the top programmer, that the firm
> should move to Python (beyond the pilot projects which I led and gave
> such stellar results), I quit, and for years I made a great living as a
> freelance consultant (mostly in Python -- once in a while, a touch of
> Pyrex, C or C++ as a vigorish;-).
>
> That's how come I ended up working at the firm supplying your free mail
> (as Uber Tech Lead) -- they reached across an ocean to lure me to move
> from my native Italy to California, and my proven excellence in Python
> was their prime motive. The terms of their offer were just too
> incredible to pass by... so, I rapidly got my O1 visa ("alien of
> exceptional skills"), and here I am, happily ubertechleading... and
> enjoying Python and its incredibly good scalability every single day!
>
>
> Alex

How do you define scalability?

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

"Martin P. Hellwig" <[EMAIL PROTECTED]> writes:

> Bill Atkins wrote:
> 
>>
>> How do you define scalability?
>>
> http://www.google.com/search?hl=en&q=define%3Ascalability&btnG=Google+Search
>
> ;-)
>
> -- 
> mph

OK, my real question is: what features of Python make it "scalable"?

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

[EMAIL PROTECTED] (Alex Martelli) writes:

> Ken Tilton <[EMAIL PROTECTED]> wrote:
>...
>> Looks like dictionaries are no match for the ambiguity of natural 
>> language. :) Let me try again: it is Python itself that cannot scale, as
>> in gain "new power and capability", and at least in the case of lambda
>> it seems to be because of indentation-sensitivity.
>
> In my opinion (and that of several others), the best way for Python to
> grow in this regard would be to _lose_ lambda altogether, since named
> functions are preferable (and it's an acknowledged Python design
> principle that there should ideally be just one obvious way to perform a
> task); GvR used to hold the same opinion, but changed his mind recently,
> alas, so we'll keep the wart.
>
> But, quite apart from the whole issue of whether it's desirable to
> languages to change massively ("add new power and capability" meaning
> new enriched features in the language itself), your whole argument is
> bogus: it's obvious that _any_ fundamental design choice in an artefact
> will influence the feasibility and desirability of future design choices
> in future releases of that same, identical artefact.  At a syntax-sugar
> level, for example, Lisp's choice to use parentheses as delimiter means
> it's undesirable, even unfeasible, to use the single character '(' as an
> ordinary identifier in a future release of the language.  Considering
> this to mean that Lisp "cannot scale" is just as ridiculous as
> considering that Python "cannot scale" by not having an elegant way to
> make lambdas heavier and richer -- totally laughable and idiotic.  ``An
> unneeded feature "cannot" be added (elegantly) in future releases of the
> language'' is just as trivial and acceptable for the unneded feature
> ``allow ( as an ordinary single-character identifier'' as for the
> unneded feature ``allow unnamed functions with all the flexibility of
> named ones''.

Not so infeasible:

  (let ((|bizarrely(named()symbol| 3))
 (+ |bizarrely(named()symbol| 4))

   ;; => 7

And in any case, enforced indentation is a policy with vastly more
serious consequences than the naming of identifiers.

>> By contrast, in On Lisp we see Graham toss off Prolog in Chapter 22 and
>
> Oh, is that the same Graham who writes:
>
> """
> A friend of mine who knows nearly all the widely used languages uses
> Python for most of his projects. He says the main reason is that he
> likes the way source code looks. That may seem a frivolous reason to
> choose one language over another. But it is not so frivolous as it
> sounds: when you program, you spend more time reading code than writing
> it. You push blobs of source code around the way a sculptor does blobs
> of clay. So a language that makes source code ugly is maddening to an
> exacting programmer, as clay full of lumps would be to a sculptor.
> """
> ...?  [[ I suspect that friend is in fact a common friend of mine and
> Graham's, the guy you also mention later in your post, and who
> introduced Graham and me when G recently came talk at Google (we had
> "brushed" before, speaking in the same sessions at conferences and the
> like, but had never "met", as in, got introduced and _talked_...;-). ]]
> 
> But, no matter, let's get back to Graham's point: significant
> indentation is a large part of what gives Python its own special beauty,
> uncluttered by unneeded punctuation.  And while you, I, Graham, and that
> common friend of ours, might likely agree that Lisp, while entirely
> different, has its own eerie beauty, most people's aesthetics are poles
> apart from that (why else would major pure-FP languages such as *ML and
> Haskell entirely reject Lisp's surface syntax, willingly dropping the
> ease of macros, to introduce infix operator syntax etc...? obviously,
> their designers' aesthetics weigh parenthesized prefixsyntax negatively,
> despite said designers' undeniable depth, skill and excellence).
>
>
> Alex

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

[EMAIL PROTECTED] (Alex Martelli) writes:

> Bill Atkins <[EMAIL PROTECTED]> wrote:
>...
>> > ``allow ( as an ordinary single-character identifier'' as for the
>> > unneded feature ``allow unnamed functions with all the flexibility of
>> > named ones''.
>> 
>> Not so infeasible:
>> 
>>   (let ((|bizarrely(named()symbol| 3))
>>  (+ |bizarrely(named()symbol| 4))
>> 
>>;; => 7
>
> Read again what I wrote: I very specifically said "ordinary
> *single-character* identifier" (as opposed to "one of many characters
> inside a multi-character identifier").  Why do you think I said
> otherwise, when you just quoted what I had written?  (Even just a
> _leading_ ( at the start of an identifier may be problematic -- and just
> as trivial as having to give names to functions, of course, see below).

Well, the same technique can obviously be used for:

 (let ((|(| 3)))
   (+ |(| 4)))
 ;; => 7

The length of the identifier is irrelevant...

>> And in any case, enforced indentation is a policy with vastly more
>> serious consequences than the naming of identifiers.
>
> So far, what was being discussed here isn't -- having to use an
> identifier for an object, rather than keeping it anonymous -- trivial.
> Python practically enforces names for several kinds of objects, such as
> classes and modules as well as functions ("practically" because you CAN
> call new.function(...), type(...), etc, where the name is still there
> but might e.g. be empty -- not a very practical alternative, though) --
> so what?  Can you have an unnamed macro in Lisp?  Is being "forced" to
> name it a "serious consequence"?  Pah.

Common Lisp does not support unnamed macros (how would these be
useful?), but nothing stops me from adding these.  What use case do
you envision for anonymous macros?

> Anyway, I repeat: *any* design choice (in a language, or for that matter
> any other artefact) has consequences.  As Paul Graham quotes and
> supports his unnamed friend as saying, Python lets you easily write code
> that *looks* good, and, as Graham argues, that's an important issue --
> and, please note, a crucial consequence of using significant
> indentation.  Alien whitespace eating nanoviruses are no more of a worry
> than alien parentheses eating nanoviruses, after all.

It *is* an important issue, but it's also a subjective issue.  I find
Lisp to be far prettier than any syntax-based language, so it's far
from an objective truth that Python code often looks good - or even at
all.

Plus, I can easily write code that looks good without using a language
that enforces indentation rules.  Lisp's regular syntax lets Emacs do
it for me with a simple C-M-a C-M-q.  What could be easier?

>
>
> Alex

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

[EMAIL PROTECTED] (Alex Martelli) writes:

> Ken Tilton <[EMAIL PROTECTED]> wrote:
>...
>> True but circular, because my very point is that () was a great design
>> choice in that it made macros possible and they made CL almost 
>> infinitely extensible, while indentation-sensitivity was a mistaken 
>> design choice because it makes for very clean code (I agree 
>> wholeheartedly) but placed a ceiling on its expressiveness.
>
> Having to give functions a name places no "ceiling on expressiveness",
> any more than, say, having to give _macros_ a name.
>
>
>> As for:
>> 
>> >  At a syntax-sugar
>> > level, for example, Lisp's choice to use parentheses as delimiter means
>> > it's undesirable, even unfeasible, to use the single character '(' as an
>> > ordinary identifier in a future release of the language.
>> 
>> (defun |(| (aside) (format nil "Parenthetically speaking...~a." aside))
>> => |(|
>> (|(| "your Lisp /is/ rusty.")
>> => "Parenthetically speaking...your Lisp /is/ rusty.."
>> 
>> :) No, seriously, is that all you can come up with?
>
> Interestingly, the SECOND lisper to prove himself unable to read the
> very text he's quoting.  Reread carefully, *USE THE ***SINGLE***
> CHARACTER* ... *AS AN ORDINARY IDENTIFIER*.  What makes you read a
> ``PART OF''  that I had never written?  You've shown how to use the
> characters as *PART* of an identifier [[and I believe it couldn't be the
> very start]], and you appear to believe that this somehow refutes my
> assertion?

Now I see what the problem is here - you just don't know what you're
talking about.  The identifier in Ken's and my samples *is* a single
character identifier.  The vertical bars tell the Lisp reader that
what's between them is exempt from other reading rules.

 (symbol-name '|(| ) => "("

 (length (symbol-name '|(| )) => 1

> Are you ready to admit you were utterly wrong, and (while it is indeed
> true that my Lisp is rusty) there is nothing in this exchange to show
> it, as opposed to showing rustiness in your ability to understand
> English?  Or shall we move from polite although total dissent right on
> to flamewars and namecalling?

Believe it or not, _you_ got it wrong.

> The point is, OF COURSE any design choice places limitations on future
> design choices; but some limitations are even DESIRABLE (a language
> where *every* single isolated character could mean anything whatsoever
> would not be "expressive", but rather totally unreadable) or at least
> utterly trivial (syntax-sugar level issues most typically are). Wilfully
> distorting some such limitation as meaning that one language "can scale"
> (when EVERY language inevitably has SOME such limitations) is not even
> funny, and clearly characterizes a polemist who is intent on proving a
> preconceived thesis, as opposed to an investigator with any real
> interest in ascertaining the truth of the matter.

Having to name a variable "paren" instead of "(" is not a serious
restriction.  I can't think of a single situation where being able to
do so would be useful.

That said, raw, out-of-the-box Common Lisp can accomodate you if you
both a) need variables named "(" and b) are unwilling to use the bar
syntax.  Simply redefine the parenthesis characters in the readtable
(a matter of four function calls) and get this abomination:

 {let {{( 3}}
   {+ ( 5}}

Lisp places no restrictions on you, even when your goal is as silly as
this one.

>> > Oh, is that the same Graham who writes:
>> 
>> So we are going to skip the point I was making about Common Lisp being
>> so insanely extensible? By /application/ programmers? Hell, for all we
>> know CL does have a BDFL, we just do not need their cooperation.
>
> Yes, we are, because the debate about why it's better for Python (as a
> language used in real-world production systems, *SCALABLE* to extremely
> large-scale ones) to *NOT* be insanely extensible and mutable is a
> separate one -- Python's uniformity of style allows SCALABILITY of
> teams, and teams-of-teams, which is as crucial in the real world as
> obviously not understood by you (the law you misquoted was about adding
> personnel to a LATE project making it later -- nothing to do with how
> desirable it can be to add personnel to a large and growing collection
> of projects, scaling and growing in an agile, iterative way to meet
> equally growing needs and market opportunities).

Buh?  The project doesn't have to be late for Brooks's law to hold;
adding programmers, so goes Brooks reasoning, will always increase the
time required to complete the project because of various communication
issues.

> This specific debate grew from your misuse of "scalable" to mean or
> imply "a bazillion feechurz can [[and, implicitly, should]] be added to
> a language, and therefore anything that stands in the way of feechuritis
> is somehow holding the language back".  That's bad enough, even though
> in its contextual misuse of "scalable" it breaks new ground, and I don't
> want to waste even mor

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

[EMAIL PROTECTED] (Alex Martelli) writes:

> Bill Atkins <[EMAIL PROTECTED]> wrote:
>...
>> >
>> > Read again what I wrote: I very specifically said "ordinary
>> > *single-character* identifier" (as opposed to "one of many characters
>> > inside a multi-character identifier").  Why do you think I said
>> > otherwise, when you just quoted what I had written?  (Even just a
>> > _leading_ ( at the start of an identifier may be problematic -- and just
>> > as trivial as having to give names to functions, of course, see below).
>> 
>> Well, the same technique can obviously be used for:
>> 
>>  (let ((|(| 3)))
>>(+ |(| 4)))
>>  ;; => 7
>> 
>> The length of the identifier is irrelevant...
>
> But it cannot be a SINGLE CHARACTER, *just* the openparenthesis.
>
> Wow, it's incredible to me that you STILL can't read, parse and
> understand what I have so clearly expressed and repeated!

Read my other post.  It's incredible that you STILL haven't considered
the possibility that you're just wrong.

>
>> Common Lisp does not support unnamed macros (how would these be
>> useful?), but nothing stops me from adding these.  What use case do
>> you envision for anonymous macros?
>
> None, just like there is none for anonymous functions -- there is
> nothing useful I can do with anonymous functions that I cannot do with
> named ones.

Sure there are.

Does Python have any support for closures?  If so, ignore this point.
But if not, what about examples like this:

  (defun make-window (window observer)
;; initialization code here
(add-handler window 'close
 (lambda (event)
(notify observer event)))
;; more code)

Being able to keep pass around state with functions is useful.

There are also cases where a function is so trivial that the simplest
way to describe it is with its source code, where giving it a name and
putting it at the beginning of a function is just distracting and
time-consuming.  E.g.:

  (remove-if (lambda (name)
   (find #\- name :test #'char=))   
 list-of-names)

What's the sense of giving that function its own name?  It's much
clearer to simply write it in place.  Yes, it's _possible_ to use
named functions, but in this case its functionality is so simple that
it's clearer to simply type it in place.  Why is this expressiveness a
bad thing, aside from its power to wreck an indentation-significant
language?

>
>> > Anyway, I repeat: *any* design choice (in a language, or for that matter
>> > any other artefact) has consequences.  As Paul Graham quotes and
>> > supports his unnamed friend as saying, Python lets you easily write code
>> > that *looks* good, and, as Graham argues, that's an important issue --
>> > and, please note, a crucial consequence of using significant
>> > indentation.  Alien whitespace eating nanoviruses are no more of a worry
>> > than alien parentheses eating nanoviruses, after all.
>> 
>> It *is* an important issue, but it's also a subjective issue.  I find
>> Lisp to be far prettier than any syntax-based language, so it's far
>> from an objective truth that Python code often looks good - or even at
>> all.
>
> The undeniable truth, the objective fact, is that *to most programmers*
> (including ones deeply enamored of Lisp, such as Graham, Tilton, Norvig,
> ...) Python code looks good; the Lisp code that looks good to YOU (and,
> no doubt them), and palatable to me (I have spoken of "eerie beauty"),
> just doesn't to most prospective readers.  If you program on your own,
> or just with a few people who share your tastes, then only your taste
> matters; if you want to operate in the real world, maybe, as I've
> already pointed out, to build up a successful firm faster than had ever
> previously happened, this *DOESN'T SCALE*. Essentially the same issue
> I'm explaining on the parallel subthread with Tilton, except that he
> fully agrees with my aesthetic sense (quoting Tilton, "No argument. The
> little Python I wrote while porting Cells to Python was strikingly
> attractive") so this facet of the jewel needed no further belaboring
> there.

And I'm sure Kelly Clarkson sounds better *to most listeners* but that
doesn't mean she's a better musician than Hendrix.  The fact that most
people are used to ALGOL-like languages does not mean that ALGOL-like
languages are more aesthetically pleasing on their own merits.

>> 
>> Plus, I can easily write code that looks good without using a language
>> that enforces indentation rules.  Lisp&#x

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

[EMAIL PROTECTED] (Alex Martelli) writes:

> Yes, we are, because the debate about why it's better for Python (as a
> language used in real-world production systems, *SCALABLE* to extremely
> large-scale ones) to *NOT* be insanely extensible and mutable is a
> separate one -- Python's uniformity of style allows SCALABILITY of
> teams, and teams-of-teams, which is as crucial in the real world as
> obviously not understood by you (the law you misquoted was about adding
> personnel to a LATE project making it later -- nothing to do with how
> desirable it can be to add personnel to a large and growing collection
> of projects, scaling and growing in an agile, iterative way to meet
> equally growing needs and market opportunities).
>
> This specific debate grew from your misuse of "scalable" to mean or
> imply "a bazillion feechurz can [[and, implicitly, should]] be added to
> a language, and therefore anything that stands in the way of feechuritis
> is somehow holding the language back".  That's bad enough, even though
> in its contextual misuse of "scalable" it breaks new ground, and I don't
> want to waste even more time re-treading *old* ground as to whether the
> "*insane* extensibility" afforded by macros is a good or a bad thing in
> a language to be used for real-world software production (as opposed to
> prototyping and research).

It's interesting how much people who don't have macros like to put
them down and treat them as some arcane art that are too "*insane*"ly
powerful to be used well.

They're actually very straightforward and can often (shock of shocks!)
make your code more readable, without your efficiency taking a hit.

For example, at work I recently had to generate PDF reports in PHP.
Certain sections would need to be indented, and then once they were
done, I wanted to move back out to the previous level of indentation.
I ended up with stuff like this (totally made up on the spot, but
conveys the general idea):

function out_main_text( ) {
  $old_indent = $pdf->indentation;
  $pdf->indent_to( $pdf->indentation + 4 );

  out_header();
  out_facts();

  $pdf->set_indentation( $old_indent );
}

function out_header() {
  $old_indent = $pdf->indentation;
  $pdf->indent_to( $pdf->indentation + 4 );

  $pdf->write( "some text" );

  $pdf->set_indentation( $old_indent );
}

function out_facts() {
  $old_indent = $pdf->indentation;
  $pdf->indent_to( $pdf->indentation + 4 );

  out_some_subsection();
  out_another_subsection();

  $pdf->set_indentation( $old_indent );
}


Obviously, this is very much pseudocode.  The point is that managing
indentation was a hassle, because each of these subfunctions indents
to a new position.  This can pretty clearly get tedious, and is
definitely error-prone, especially when you consider that different
groups of functions are called depending upon the input and that some
of the functions might return early.

But why should I have to worry about any of this?  Why can't I do:

  (with-indentation (pdf (+ (indentation pdf) 4))
 (out-header)
 (out-facts))

and then within, say out-facts:

  (with-indentation (pdf (+ (indentation pdf) 4))
(write pdf "some text"))

More readable, and no bookkeeping to worry about.  This is great!  And
here's the macro:

  (defmacro with-indentation (pdf new-value &body body)
(let ((old-indent (gensym)))
  `(let ((,old-indent (indentation pdf)))
(unwind-protect (progn ,@body)
  (setf (indentation pdf) ,old-indent)

Bam, all of that bookkeeping, all of those potential errors have taken
care of themselves.  WITH-INDENTATION will expand into code that uses
UNWIND-PROTECT to ensure that the indentation always gets returned to
its previous value, even if an exception occurs or the code within
calls RETURN.  The WITH-INDENTATION call sets up an environment where
there is a new indentation level in effect, and then cleans it up when
it's done.  I can nest these to my heart's content.

Obviously, to someone totally unfamiliar with Lisp, the contents of
that macro are pretty daunting.  But you're crazy if you argue that
having WITH-INDENTATION around isn't an improvement over manually
ensuring that indentation gets saved and restored for every function
call.

I could even generalize this (as CLISP does) to this:

  (letf (((indentation pdf) (+ 4 (indentation pdf
(write "some text"))

Now I can use LETF to temporarily set any value at all for as long as
the code inside is running, and to restore it when it's done.

Macros rock.

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

I V <[EMAIL PROTECTED]> writes:

> On Sat, 06 May 2006 21:19:58 -0400, Bill Atkins wrote:
>> There are also cases where a function is so trivial that the simplest
>> way to describe it is with its source code, where giving it a name and
>> putting it at the beginning of a function is just distracting and
>> time-consuming.  E.g.:
>> 
>>   (remove-if (lambda (name)
>>(find #\- name :test #'char=))   
>>  list-of-names)
>> 
>> What's the sense of giving that function its own name?  It's much
>> clearer to simply write it in place.  Yes, it's _possible_ to use
>> named functions, but in this case its functionality is so simple that
>> it's clearer to simply type it in place.  Why is this expressiveness a
>> bad thing, aside from its power to wreck an indentation-significant
>> language?
>
> Well, you can do that with python's current,
> non-indentation-significance-wrecking, lambda syntax, so I don't think
> that's a particularly persuasive example. Note also that the only
> limitation python has on where you can define functions is that you can't
> define them inside expressions (they have to be statements), so you could
> define a named function right before the call to remove-if, which removes
> some of the advantage you get from the lambda (that is, the function
> definition is not very far from when it's used). 
>
> Actually, I think the limitation on python that is operative here is not
> significant whitespace, but the distinction between statements and
> expressions.
>
> (crossposts trimmed)

You're right, I was replying to Alex's assertion that "there is
nothing useful I can do with anonymous functions that I cannot do with
named ones."

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

[EMAIL PROTECTED] (Alex Martelli) writes:

> Bill Atkins <[EMAIL PROTECTED]> wrote:
>...
>> Believe it or not, _you_ got it wrong.
>
> Acknowledged: Common Lisp is even MORE insane (note that the quote
> "INSANELY extensible" is from Tilton) than I believed -- I'm pretty sure
> that the Lisp dialects I used in 1979-1981 didn't go to such crazy
> extremes, and neither did Scheme.
>
>> Buh?  The project doesn't have to be late for Brooks's law to hold;
>> adding programmers, so goes Brooks reasoning, will always increase the
>> time required to complete the project because of various communication
>> issues.
>
> And here is where we check if you're as gracious about admitting your
> errors, as I am about mine.  Brooks' law is:
>
> """Adding manpower to a late software project makes it later."""
>
> These are Brooks' words, literally.  OK so far?

You are correct.

I posted too hastily.  Here is what my paragraph ought to have said:

 Buh?  The project doesn't have to be late for Brooks's law to hold;
 adding programmers *in the middle of a project*, so goes Brooks
 reasoning, will always increase the time required to complete the
 project because of various communication issues.

Agree?

> Your claim, that adding programmers will ALWAYS increase the time, is
> not just wrong, but utterly ridiculous.  I can't put it better than the
> wikipedia:
> """
> Misconceptions
>
> A commonly understood implication of Brooks' law is that it will be more
> productive to employ a smaller number of very talented (and highly paid)
> programmers on a project than to employ a larger number of less talented
> programmers, since individual programmer productivity can vary greatly
> between highly talented and efficient programmers and less talented
> programmers. However, Brooks' law does not mean that starving a project
> of resources by employing fewer programmers beyond a certain point will
> get it done faster.
> """
>
> Moreover, check out the research on Pair Programming: it scientifically,
> empirically confirms that "two heads are better than one", which should
> surprise nobody.  Does this mean that there aren't "various
> communication issues"?  Of course there are, but there's no implied
> weighting of these factors wrt the _advantages_ of having that second
> person on the team (check the Pair Programming literature for long lists
> of those advantages).
>
> Only empirical research can tell us where the boundary is -- when
> productivity is decreased by going from N to N+1.  A lot depends on
> imponderable issues such as personality meshes or clashes, leadership
> abilities at hands, methodology used, etc.  All of this is pretty
> obvious, making your assertion that Brooks held otherwise actionable (as
> libel, by Brooks) in many legislations.

Hahaha.

> As it happens, I also have examples in which adding (a few carefully
> selected) people to a software project that WAS (slightly) late put that
> project back on track and made it deliver successfully on schedule.
> Definitely not the "pointy-haired boss" management style of "throwing
> warm bodies at the problem" that Brooks was fighting against, but,
> consider: the project's velocity has suffered because [a] the tech lead
> has his personal (usually phenomenal) productivity hampered by a painful
> condition requiring elective surgery to abate, and [b] nobody on the
> team is really super-experienced in the intricacies of cryptography, yes
> some very subtle cryptographic work turns out to be necessary.  One day,
> the tech lead calls in -- the pain has gotten just too bad, he's going
> for surgery, and will be out of the fray for at least one week.
>
> I still remember with admiration how my Director reacted to the
> emergency: he suspended two other projects, deciding that, if THEIR
> deadlines were broken, that would be a lesser damage to the company than
> if this one slipped any further; and cherrypicked exactly two people --
> one incredibly flexible "jack of all trades" was tasked with getting up
> to speed on the project and becoming the acting TL for it, and an
> excellent cryptography specialist was tasked to dig deep into the
> project's cryptography needs and solve them pronto.
>
> So, We Broke Brooks' Law -- the cryptographer did his magic, and
> meanwhile the JOAT ramped up instantly and took the lead (kudos to the
> Jack's skills, to the clarity and transparency of the previous TL's
> work, to the agile methodologies employed throughout, AND to the
> uniformity of style of one l

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

"Serge Orlov" <[EMAIL PROTECTED]> writes:

> Ken Tilton wrote:
>> It is vastly more disappointing that an alleged tech genius would sniff
>> at the chance to take undeserved credit for PyCells, something probably
>> better than a similar project on which Adobe (your superiors at
>> software, right?) has bet the ranch. This is the Grail, dude, Brooks's
>> long lost Silver Bullet. And you want to pass?
>>
>> C'mon, Alex, I just want you as co-mentor for your star quality. Of
>> course you won't have to do a thing, just identify for me a True Python
>> Geek and she and I will take it from there.
>>
>> Here's the link in case you lost it:
>>
>>  http://www.lispnyc.org/wiki.clp?page=PyCells
>>
>> :)
>>
>> peace, kenny
>>
>> ps. flaming aside, PyCells really would be amazingly good for Python.
>> And so Google. (Now your job is on the line. ) k
>
> Perhaps I'm missing something but what's the big deal about PyCells?
> Here is 22-lines barebones implementation of spreadsheet in Python,
> later I create 2 cells "a" and "b", "b" depends on a and evaluate all
> the cells. The output is
>
> a = negate(sin(pi/2)+one) = -2.0
> b = negate(a)*10 = 20.0
>
> === spreadsheet.py ==
> class Spreadsheet(dict):
> def __init__(self, **kwd):
> self.namespace = kwd
> def __getitem__(self, cell_name):
> item = self.namespace[cell_name]
> if hasattr(item, "formula"):
> return item()
> return item
> def evaluate(self, formula):
> return eval(formula, self)
> def cell(self, cell_name, formula):
> "Create a cell defined by formula"
> def evaluate_cell():
> return self.evaluate(formula)
> evaluate_cell.formula = formula
> self.namespace[cell_name] = evaluate_cell
> def cells(self):
> "Yield all cells of the spreadsheet along with current values
> and formulas"
> for cell_name, value in self.namespace.items():
> if not hasattr(value, "formula"):
> continue
> yield cell_name, self[cell_name], value.formula
>
> import math
> def negate(x):
> return -x
> sheet1 = Spreadsheet(one=1, sin=math.sin, pi=math.pi, negate=negate)
> sheet1.cell("a", "negate(sin(pi/2)+one)")
> sheet1.cell("b", "negate(a)*10")
> for name, value, formula in sheet1.cells():
> print name, "=", formula, "=", value
>

I hope Ken doesn't mind me answering for him, but Cells is not a
spreadsheet (where did you get that idea?).  It does apply the basic
idea of a spreadsheet to software - that is, instead of updating value
when some event occurs, you specify in advance how that value can be
computed and then you stop worrying about keeping it updated.

Incidentally, is this supposed to be an example of Python's supposed
"aesthetic pleasantness"?  I find it a little hideous, even giving you
the benefit of the doubt and pretending there are newlines between
each function.  There's nothing like a word wrapped in pairs of
underscores to totally ruin an aesthetic experience.

P.S. Is this really a spreadsheet?  It looks like it's a flat
hashtable...

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

Bill Atkins <[EMAIL PROTECTED]> writes:

> Incidentally, is this supposed to be an example of Python's supposed
> "aesthetic pleasantness"?  I find it a little hideous, even giving you
> the benefit of the doubt and pretending there are newlines between
> each function.  There's nothing like a word wrapped in pairs of
> underscores to totally ruin an aesthetic experience.

I don't mean to suggest that your code in particular is hideous -
sorry if it came off that way.  It's just that Python code seems a
disappointingly un-pretty after all the discussion about its beauty in
this thread.

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

"Serge Orlov" <[EMAIL PROTECTED]> writes:

> Bill Atkins wrote:
>> "Serge Orlov" <[EMAIL PROTECTED]> writes:
>>
>> > Ken Tilton wrote:
>> >> It is vastly more disappointing that an alleged tech genius would sniff
>> >> at the chance to take undeserved credit for PyCells, something probably
>> >> better than a similar project on which Adobe (your superiors at
>> >> software, right?) has bet the ranch. This is the Grail, dude, Brooks's
>> >> long lost Silver Bullet. And you want to pass?
>> >>
>> >> C'mon, Alex, I just want you as co-mentor for your star quality. Of
>> >> course you won't have to do a thing, just identify for me a True Python
>> >> Geek and she and I will take it from there.
>> >>
>> >> Here's the link in case you lost it:
>> >>
>> >>  http://www.lispnyc.org/wiki.clp?page=PyCells
>> >>
>> >> :)
>> >>
>> >> peace, kenny
>> >>
>> >> ps. flaming aside, PyCells really would be amazingly good for Python.
>> >> And so Google. (Now your job is on the line. ) k
>> >
>> > Perhaps I'm missing something but what's the big deal about PyCells?
>> > Here is 22-lines barebones implementation of spreadsheet in Python,
>> > later I create 2 cells "a" and "b", "b" depends on a and evaluate all
>> > the cells. The output is
>> >
>> > a = negate(sin(pi/2)+one) = -2.0
>> > b = negate(a)*10 = 20.0
>> >
>> > === spreadsheet.py ==
>> > class Spreadsheet(dict):
>> > def __init__(self, **kwd):
>> > self.namespace = kwd
>> > def __getitem__(self, cell_name):
>> > item = self.namespace[cell_name]
>> > if hasattr(item, "formula"):
>> > return item()
>> > return item
>> > def evaluate(self, formula):
>> > return eval(formula, self)
>> > def cell(self, cell_name, formula):
>> > "Create a cell defined by formula"
>> > def evaluate_cell():
>> > return self.evaluate(formula)
>> > evaluate_cell.formula = formula
>> > self.namespace[cell_name] = evaluate_cell
>> > def cells(self):
>> > "Yield all cells of the spreadsheet along with current values
>> > and formulas"
>> > for cell_name, value in self.namespace.items():
>> > if not hasattr(value, "formula"):
>> > continue
>> > yield cell_name, self[cell_name], value.formula
>> >
>> > import math
>> > def negate(x):
>> > return -x
>> > sheet1 = Spreadsheet(one=1, sin=math.sin, pi=math.pi, negate=negate)
>> > sheet1.cell("a", "negate(sin(pi/2)+one)")
>> > sheet1.cell("b", "negate(a)*10")
>> > for name, value, formula in sheet1.cells():
>> > print name, "=", formula, "=", value
>> >
>>
>> I hope Ken doesn't mind me answering for him, but Cells is not a
>> spreadsheet (where did you get that idea?).
>
> It's written on the page linked above, second sentence: "Think of the
> slots as cells in a spreadsheet, and you've got the right idea". I'm
> not claiming that my code is full PyCell implementation.

Unfortunately, it's *nothing* like a full PyCell implementation.  I
explained what Cells is above.  It is not merely a spreadsheet - it is
an extension that allows the programmer to specify how the value of
some slot (Lisp lingo for "member variable") can be computed.  It
frees the programmer from having to recompute slot values since Cells
can transparently update them.  It has to do with extending the object
system, not with merely setting tables in a hash and then retrieving
them.

>> It does apply the basic
>> idea of a spreadsheet to software - that is, instead of updating value
>> when some event occurs, you specify in advance how that value can be
>> computed and then you stop worrying about keeping it updated.
>
> The result is the same. Of course, I don't track dependances in such a
> tiny barebones example. But when you retrieve a cell you will get the
> same value as with dependances. Adding dependances is left as an
> exercise.
>
>>
>> Incidentally, is this supposed to be an example of Python

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

[EMAIL PROTECTED] writes:

> Bill Atkins wrote:
>> Buh?  The project doesn't have to be late for Brooks's law to hold;
>> adding programmers, so goes Brooks reasoning, will always increase the
>> time required to complete the project because of various communication
>> issues.
>
> 1. This is not what Brooks says. Brooks was talking about late
>projects. Please provide a supporting quote if you wish to continue
>to claim that "adding programmers will always increase the time
>required to complete the project".

The "always" in my claim should not be there, I admit.  Brooks didn't
claim that.

I refer you to pages 17 - 18 of The Mythical Man-Month:

  Since software construction is inherently a systems effort - an
  exercise in complex interrelationships - communication effort is
  great...Adding more men then lengthens, not shortens, the schedule.

It is totally absurd to assume that, simply because a project has not
yet passed its deadline, it will somehow become immune to the kinds of
things Brooks is talking about.  His thesis is that adding programmers
to an already-in-progress project will cause a delay, because the new
programmers must be brought up to speed.  It does not matter if the
project is eight weeks late or has only been active for a month.  This
issue still remains:

  The two new men, however competent and however quickly trained, will
  require training in the task by one of the experienced men.  If this
  takes a month, 3 man-months will have been devoted to work not in
  the original estimate. (p. 24, TMM-M)

Brooks's Law mentions only late projects, but the rest of his
discussion applies to adding programmers in the middle of *any*
project.

Is this really so radical an idea?

> 2. There has to be a mechanism where an organization can add
>developers - even if it is only for new projects. Python advocates

Obviously.

>would say that getting developers up to speed on Python is easy
>because:
>
> - it fits most programmers brains i.e. it is similar enough to
>   languages that most programmers have experience with and the
>   differences are usually perceived to beneficial (exception:
>   people from a Java/C/C++ background often perceive dynamic
>   typing as a misfeature and have to struggle with it)
> - the language is small and simple
> - "magic" is somewhat frowned upon in the Python community i.e.
>   most code can be taken at face value without needing to learn a
>   framework, mini-language, etc. (but I think that the Python
>   community could do better on this point)

These are not things I look for in a programming language.

>
>I'm sure that smarter people can think of more points.
>
>> Fair enough. But what does Python offer above any garbage-collected
>> language that makes it so scalable?
>
> See above point - you can more easily bring programmers online in your
> organization because most programmers find Python easily learnable.
> And, as a bonus, it is actually a pretty flexible, powerful language.
>  
> Cheers,
> Brian
>

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

"Chris Uppal" <[EMAIL PROTECTED]> writes:

> Bill Atkins wrote:
>
>> But why should I have to worry about any of this?  Why can't I do:
>>
>>   (with-indentation (pdf (+ (indentation pdf) 4))
>>  (out-header)
>>  (out-facts))
>>
>> and then within, say out-facts:
>>
>>   (with-indentation (pdf (+ (indentation pdf) 4))
>> (write pdf "some text"))
>>
>> More readable, and no bookkeeping to worry about.  This is great!  And
>> here's the macro:
> . [...]
>
> Can you explain to a non-Lisper why macros are needed for this ?  I'm a
> Smalltalker, and Smalltalk has no macros, nor anything like 'em, but the
> equivalent of the above in Smalltalk is perfectly feasible, and does not
> require a separate layer of semantics (which is how I think of true macros).
>
> aPdf
> withAdditionalIndent: 4
> do: [ aPdf writeHeader; writeFacts ].
>
> and
>
> aPdf
> withAdditionalIndent: 4
> do: [ aPdf write: '... some text...' ].
>
> Readers unfamiliar with Smalltalk may not find this any easier to read that
> your Lisp code, but I can assure them that to any Smalltalker that code would
> be both completely idiomatic and completely transparent.  (Although I think a
> fair number of Smalltalkers would choose to use a slightly different way of
> expressing this -- which I've avoided here only in order to keep things
> simple).

To be honest, all I know about Smalltalk are the parts of it that were
grafted onto Ruby.  But if your example is doing the same as my code,
then I can't say that there's much of an advantage to using a macro
over this.

>
>> Macros rock.
>
> I have yet to be persuaded of this ;-)

My favorite macro is ITERATE, which was written at MIT to add a
looping mini-language to CL.  There is a macro called LOOP that is
part of Common Lisp, but ITERATE improves upon it in lots of ways.

The cool thing about ITERATE is that it lets you express looping
concepts in a language designed explicitly for such a purpose, e.g.

  (iter (for x in '(1 3 3))
(summing x))  => 7

  (iter (for x in '(1 -3 2))
(finding x maximizing (abs x))) => -3

  (iter (for x in '(a b c 1 d 3 e))
(when (symbolp x)
  (collect x)))  => (a b c d e)

This is a tiny, tiny chunk of what ITERATE offers and of the various
ways these clauses can be combined.  But it should be obvious that
being able to express loops this way is going to make your code much
more concise and more readable.

But it gets even better: since ITERATE is a macro, the code passed to
it is error-checked and analyzed at compile-time, and then converted
to primitive Lisp forms - also at compile-time.  What this means is
you get all this extra expressive power at absolutely no runtime cost.

At the risk of causing brains to explode, here is what the third ITER
form expands into:

(LET* ((#:LIST17 NIL)
   (X NIL)
   (#:RESULT16 NIL)
   (#:END-POINTER18 NIL)
   (#:TEMP19 NIL))
  (BLOCK NIL
(TAGBODY
  (SETQ #:LIST17 '(A B C 1 D 3 E))
 LOOP-TOP-NIL
  (IF (ATOM #:LIST17) (GO LOOP-END-NIL))
  (SETQ X (CAR #:LIST17))
  (SETQ #:LIST17 (CDR #:LIST17))
  (IF (SYMBOLP X)
  (PROGN
   NIL
   (PROGN
(SETQ #:TEMP19 (LIST X))
(SETQ #:END-POINTER18
(IF #:RESULT16
(SETF (CDR #:END-POINTER18) #:TEMP19)
(SETQ #:RESULT16 #:TEMP19)))
#:RESULT16))
  NIL)
  (GO LOOP-TOP-NIL)
 LOOP-END-NIL)
#:RESULT16))

This is obviously not something any sane programmer would sit down and
write just to get an efficient loop.  But this code is highly tuned;
for instance, it tracks the end of the list it's building up to save
time.  I, as a programmer, get all this expressiveness and efficiency
for free.  I think that's awesome.

There are lots more examples of macros.  My second favorite macro to
use as an example are Peter Seibel's macros for processing binary files:

  http://gigamonkeys.com/book/practical-parsing-binary-files.html

He builds a set of macros so that in the next chapter he can define an
ID3 tag reader and writer with:

(define-tagged-binary-class id3v2.3-frame ()
  ((id(frame-id :length 4))
   (size  u4)
   (flags u2)
   (decompressed-size (optional :type 'u4 :if (frame-compressed-p flags)))
   (encryption-scheme (optional :type 'u1 :if (frame-encrypted-p flags)))
   (grouping-identity (optional :type 'u1 :if (frame-grouped-p flags
  (:dispatch (find-frame-class id)))

The macro generates code for methods that let you read and write ID3
files in a structured way - and it can of course be used fo

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

[EMAIL PROTECTED] writes:

> Bill Atkins wrote:
>> [EMAIL PROTECTED] writes:
>>
>>> Bill Atkins wrote:
>>>> Buh?  The project doesn't have to be late for Brooks's law to hold;
>>>> adding programmers, so goes Brooks reasoning, will always increase the
>>>> time required to complete the project because of various communication
>>>> issues.
>>> 1. This is not what Brooks says. Brooks was talking about late
>>>projects. Please provide a supporting quote if you wish to continue
>>>to claim that "adding programmers will always increase the time
>>>required to complete the project".
>>
>> The "always" in my claim should not be there, I admit.  Brooks didn't
>> claim that.
>>
>> I refer you to pages 17 - 18 of The Mythical Man-Month:
>>
>>   Since software construction is inherently a systems effort - an
>>   exercise in complex interrelationships - communication effort is
>>   great...Adding more men then lengthens, not shortens, the schedule.
>>
>> It is totally absurd to assume that, simply because a project has not
>> yet passed its deadline, it will somehow become immune to the kinds of
>> things Brooks is talking about.
>
> Right. But only when a project is late does Brooks say that adding
> programmers will always make it later (the claim that you made). In
> other cases he says "Add manpower, ..., this may or may not help". That
> seems intuitively obvious to me. If the programmers being added require
> extensive training [1] by the team to become productive, and their
> contribution to the project will be smaller than that amount (e.g. it
> is a small or nearly completed project) then their net impact on the
> project will be negative. If, OTOH, the new programmers are able to
> quickly understand the project/organization/technologies and almost
> immediately make useful contributions, then they are likely to have a
> net positive impact.

There is another essay in TMM-M that discusses the difference between
essential complexity and accidental complexity.  You might think
Python is really swell, and I might think Common Lisp is really swell,
but at the heart of it there is still what Brooks calls "essential
complexity" - the difficulty of mapping a complicated real-world
situation into a model a computer can handle.  So I think using Python
or Lisp will help get rid of a lot of the accidental complexity that
would arise from using C or C++, but it can only do so much; there is
still a lot of complexity involved even in projects that are written
in very high-level languages.  IMHO.

>>> 2. There has to be a mechanism where an organization can add
>>>developers - even if it is only for new projects. Python advocates
>>
>> Obviously.
>
> It's good that you agree. I think that the ability to add new
> productive developers to a project/team/organization is at least part
> of what Alex means by "scaleability". I'm sure that he will correct me
> if I am wrong.
>
>>> [list of proposed Python advantages snipped]
>> These are not things I look for in a programming language.
>
> Fair enough. That doesn't mean that these advantages aren't important
> to others or, in some situations, objectively important in the survival
> of a project/organization.

Sure, agreed.

> For example, imagine that Google had used language X instead of Python
> to develop their tools (assume they started with 10 expert X
> programmers). Expert X programmers are Y percent more productive than
> expert Python programmers. Now Google wants to grow aggressively and
> needs 100 times more developer productivity (and expects to need even
> more productivity in the future). If it is harder to find/hire/create
> experts in language X than Python, then Y will have to be large to make
> language X a better choice than Python. Also, if non-expert Python
> programmers can be more productive than non-expert X programmers, then
> Python also has an advantage. Eric Raymond claims that Python has very
> high initial productivity and that becoming an expert is fairly easy.
>
> BTW, I'm not saying that Common Lisp fits X in this example.
>
> Cheers,
> Brian
>
> [1] I'm considering introducing bugs or misdesigns that have to be
> fixed
> as part of training for the purposes of this discussion. Also the
> time needed to learn to coordinate with the rest of the team.
>

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

Bill Atkins <[EMAIL PROTECTED]> writes:

> There are still more!  _On Lisp_ has a lot of interesting ones, like
> an embedded Prolog interpreter and compiler:
>
>   (<-- (father billsr billjr))
>   (?- (father billsr ?))
>
>   ? = billjr

Actually, these might not be implemented as macros.

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

Alexander Schmolck <[EMAIL PROTECTED]> writes:

> [trimmed groups]
>
> Ken Tilton <[EMAIL PROTECTED]> writes:
>
>> yes, but do not feel bad, everyone gets confused by the /analogy/ to
>> spreadsheets into thinking Cells /is/ a spreadsheet. In fact, for a brief
>> period I swore off the analogy because it was so invariably misunderstood.
>> Even Graham misunderstood it.
>
> Count me in.
>
>> 
>> But it is such a great analogy! 
>> 
>> > but what's the big deal about PyCells?
>> > Here is 22-lines barebones implementation of spreadsheet in Python,
>> > later I create 2 cells "a" and "b", "b" depends on a and evaluate all
>> > the cells. The output is
>> > a = negate(sin(pi/2)+one) = -2.0
>> 
>> > b = negate(a)*10 = 20.0
>> 
>> Very roughly speaking, that is supposed to be the code, not the output. So 
>> you
>> would start with (just guessing at the Python, it has been years since I did
>> half a port to Python):
>> 
>> 
>>v1 = one
>>a = determined_by(negate(sin(pi/2)+v1)
>>b = determined_by(negate(a)*10)
>>print(a) -> -2.0 ;; this and the next are easy
>>print(b) -> 20
>>v1 = two ;; fun part starts here
>>print(b) -> 40 ;; of course a got updated, too
>> 
>
> do you mean 30?
>
> I've translated my interpretation of the above to this actual python code:
>
> from math import sin, pi
> v1 = cell(lambda: 1)
> a = cell(lambda:-(sin(pi/2)+v1.val), dependsOn=[v1])
> b = cell(lambda: -a.val*10, dependsOn=[a], 
>  onChange=lambda *args: printChangeBlurp(name='b',*args))
> print 'v1 is', v1
> print 'a is', a # -2.0 ;; this and the next are easy
> print 'b is', b # 20
> v1.val = 2 # ;; fun part starts here
> print 'v1 now is', v1
> print 'b now is', b # 30 ;; of course a got updated, too
>
>
> I get the following printout:
>
> v1 is 1
> a is -2.0
> b is [cell 'b' changed from <__main__.unbound object at 0xb4e2472c> to 20.0,
> it was not bound]20.0
> [cell 'b' changed from 20.0 to 30.0, it was bound ] v1 now is 2
> b now is 30.0
>
> Does that seem vaguely right?
>
>> The other thing we want is (really inventing syntax here):
>> 
>>on_change(a,new,old,old-bound?) print(list(new, old, old-bound?)
>
> Is the above what you want (you can also dynamically assign onChange later
> on, as required or have a list of procedures instead)?
>
>> 
>> Then the print statements Just Happen. ie, It is not as if we are just hiding
>> computed variables behind syntax and computations get kicked off when a value
>> is read. Instead, an underlying engine propagates any assignment throughout
>> the dependency graph before the assignment returns.
>
> Updating on write rather than recalculating on read does in itself not seem
> particularly complicated.
>
>> My Cells hack does the above, not with global variables, but with slots (data
>> members?) of instances in the CL object system. I have thought about doing it
>> with global variables such as a and b above, but never really seen much of
>> need, maybe because I like OO and can always think of a class to create of
>> which the value should be just one attribute.
>
> OK, so in what way does the quick 35 line hack below also completely miss your
> point?
>
>
> # (NB. for lispers: 'is' == EQ; '==' is sort of like EQUAL)
>
> def printChangeBlurp(someCell, oldVal, newVal, bound, name=''):
> print '[cell %r changed from %r to %r, it was %s]' % (
> name, oldVal, newVal, ['not bound', 'bound '][bound]),
>
> _unbound = type('unbound', (), {})() # just an unique dummy value
> def updateDependents(dependents):
> seen = {}
> for dependent in dependents:
> if dependent not in seen:
> seen[dependent] = True
> dependent.recalculate()
> updateDependents(dependent._dependents)
> class cell(object):
> def __init__(self, formula, dependsOn=(), onChange=None):
> self.formula = formula
> self.dependencies = dependsOn
> self.onChange = onChange
> self._val = _unbound
> for dependency in self.dependencies:
> if self not in dependency._dependents:
> dependency._dependents.append(self)
> self._dependents = []
> def __str__(self):
> return str(self.val)
> def recalculate(self):
> newVal = self.formula()
> if self.onChange is not None:
> oldVal = self._val
> self.onChange(self, oldVal, newVal, oldVal is not _unbound)
> self._val = newVal
> def getVal(self):
> if self._val is _unbound:
> self.recalculate()
> return self._val
> def setVal(self, value):
> self._val = value
> updateDependents(self._dependents)
> val = property(getVal, setVal)
>
>
>
> 'as

Here's how one of the cells examples might look in corrupted Python
(this is definitely not executable):

  class FallingRock:
def __init__(self, pos):
  define_slot( 'velocity', lambda: self.accel * self.elapsed )
  define_slot( 'pos', lambda: self.accel * (

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

Bill Atkins <[EMAIL PROTECTED]> writes:

> Alexander Schmolck <[EMAIL PROTECTED]> writes:
>
>> [trimmed groups]
>>
>> Ken Tilton <[EMAIL PROTECTED]> writes:
>>
>>> yes, but do not feel bad, everyone gets confused by the /analogy/ to
>>> spreadsheets into thinking Cells /is/ a spreadsheet. In fact, for a brief
>>> period I swore off the analogy because it was so invariably misunderstood.
>>> Even Graham misunderstood it.
>>
>> Count me in.
>>
>>> 
>>> But it is such a great analogy! 
>>> 
>>> > but what's the big deal about PyCells?
>>> > Here is 22-lines barebones implementation of spreadsheet in Python,
>>> > later I create 2 cells "a" and "b", "b" depends on a and evaluate all
>>> > the cells. The output is
>>> > a = negate(sin(pi/2)+one) = -2.0
>>> 
>>> > b = negate(a)*10 = 20.0
>>> 
>>> Very roughly speaking, that is supposed to be the code, not the output. So 
>>> you
>>> would start with (just guessing at the Python, it has been years since I did
>>> half a port to Python):
>>> 
>>> 
>>>v1 = one
>>>a = determined_by(negate(sin(pi/2)+v1)
>>>b = determined_by(negate(a)*10)
>>>print(a) -> -2.0 ;; this and the next are easy
>>>print(b) -> 20
>>>v1 = two ;; fun part starts here
>>>print(b) -> 40 ;; of course a got updated, too
>>> 
>>
>> do you mean 30?
>>
>> I've translated my interpretation of the above to this actual python code:
>>
>> from math import sin, pi
>> v1 = cell(lambda: 1)
>> a = cell(lambda:-(sin(pi/2)+v1.val), dependsOn=[v1])
>> b = cell(lambda: -a.val*10, dependsOn=[a], 
>>  onChange=lambda *args: printChangeBlurp(name='b',*args))
>> print 'v1 is', v1
>> print 'a is', a # -2.0 ;; this and the next are easy
>> print 'b is', b # 20
>> v1.val = 2 # ;; fun part starts here
>> print 'v1 now is', v1
>> print 'b now is', b # 30 ;; of course a got updated, too
>>
>>
>> I get the following printout:
>>
>> v1 is 1
>> a is -2.0
>> b is [cell 'b' changed from <__main__.unbound object at 0xb4e2472c> to 20.0,
>> it was not bound]20.0
>> [cell 'b' changed from 20.0 to 30.0, it was bound ] v1 now is 2
>> b now is 30.0
>>
>> Does that seem vaguely right?
>>
>>> The other thing we want is (really inventing syntax here):
>>> 
>>>on_change(a,new,old,old-bound?) print(list(new, old, old-bound?)
>>
>> Is the above what you want (you can also dynamically assign onChange later
>> on, as required or have a list of procedures instead)?
>>
>>> 
>>> Then the print statements Just Happen. ie, It is not as if we are just 
>>> hiding
>>> computed variables behind syntax and computations get kicked off when a 
>>> value
>>> is read. Instead, an underlying engine propagates any assignment throughout
>>> the dependency graph before the assignment returns.
>>
>> Updating on write rather than recalculating on read does in itself not seem
>> particularly complicated.
>>
>>> My Cells hack does the above, not with global variables, but with slots 
>>> (data
>>> members?) of instances in the CL object system. I have thought about doing 
>>> it
>>> with global variables such as a and b above, but never really seen much of
>>> need, maybe because I like OO and can always think of a class to create of
>>> which the value should be just one attribute.
>>
>> OK, so in what way does the quick 35 line hack below also completely miss 
>> your
>> point?
>>
>>
>> # (NB. for lispers: 'is' == EQ; '==' is sort of like EQUAL)
>>
>> def printChangeBlurp(someCell, oldVal, newVal, bound, name=''):
>> print '[cell %r changed from %r to %r, it was %s]' % (
>> name, oldVal, newVal, ['not bound', 'bound '][bound]),
>>
>> _unbound = type('unbound', (), {})() # just an unique dummy value
>> def updateDependents(dependents):
>> seen = {}
>> for dependent in dependents:
>> if dependent not in seen:
>> seen[dependent] = True
>> dependent.recalculate()
>> updateDependents(dependent._dependents)
>> class cell(object):

Re: A critic of Guido's blog on Python's lambda

[Bill Atkins]

[EMAIL PROTECTED] writes:

> Alex Martelli wrote:
>> Steve R. Hastings <[EMAIL PROTECTED]> wrote:
>>...
>> > > But the key in the whole thread is simply that indentation will not
>> > > scale. Nor will Python.
>> >
>> > This is a curious statement, given that Python is famous for scaling well.
>>
>> I think "ridiculous" is a better characterization than "curious", even
>> if you're seriously into understatement.
>>
>
> When you consider that there was just a big flamewar on comp.lang.lisp
> about the lack of standard mechanisms for both threading and sockets in
> Common Lisp (with the lispers arguing that it wasn't needed) I find it
> "curious" that someone can say Common Lisp scales well.
>

It's not all that curious.  Every Common Lisp implementation supports
sockets, and most support threads.  The "flamewar" was about whether
these mechanisms should be (or could be) standardized across all
implementation.  It has little to do with CL's ability to scale well.
You simply use the socket and thread API provided by your
implementation; if you need to move to another, you write a thin
compatibility layer.  In Python, since there is no standard and only
one implementation that counts, you write code for that implementation
the same way you write for the socket and thread API provided by your
Lisp implementation.

I still dislike the phrase "scales well," but I don't see how
differences in socket and thread API's across implementations can be
interpreted as causing Lisp to "scale badly."  Can you elaborate on
what you mean?

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: John Bokma harassment

[Bill Atkins]

Ken Tilton <[EMAIL PROTECTED]> writes:

> C'mon, John Bokma (and everyone else dumb enough to crosspost their
> shushing to every group on the crosspost list -- why do they do that?
> So Xah will hear them six times? No, they want everyone to see how
> witty they are when they tell Xah off. Now /that/ is spam) is the
> problem.

+12 !

-- 
You fool! You fell victim to one of the classic blunders! The most
famous is, "Never get involved in a land war in Asia", but only
slightly less well-known is this: "Never go in against a Sicilian when
death is on the line"!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: John Bokma harassment

[Bill Atkins]

John Bokma <[EMAIL PROTECTED]> writes:

> Ken Tilton <[EMAIL PROTECTED]> wrote:
>
>> Ben Bullock wrote:
>>> "Xah Lee" <[EMAIL PROTECTED]> wrote in message 
>>> news:[EMAIL PROTECTED]
>>> 
 If you believe this lobbying to my webhosting provider is unjust,
 please write to my web hosting provider [EMAIL PROTECTED]
>>> 
>>> 
>>> Why don't you just change your provider? It would take less time than
>>> this. 
>> 
>> Are you joking. "Just change your provider?" Do you have a little
>> button on your computer that says "Change provider"? Cool! :)
>
> No, it will cost Xah money. In the end he will be with a bullet proof 
> hoster, like other kooks on Usenet, or get the message.
>
>> C'mon, John Bokma (and everyone else dumb enough to crosspost their 
>> shushing to every group on the crosspost list -- why do they do that?
>
> So other people can read that reporting Xah *does* have an effect. A lot 
> of people think that a kill file is the only solution.

You win my unofficial contest for "Usenet Tool of the Year."  It is
not difficult to skip to the next file or to add a sender to a
killfile.  It is certainly less of a hassle than all this complaining
you do.

Life is short, John Bokma.  There are more important things in the
world than tattling on Xah to his host.  Maybe you can start
experiencing them if you learn to make use of the 'next message' key.

>> So Xah will hear them six times? No, they want everyone to see how
>> witty they are when they tell Xah off.
>
> So you haven't noticed that Xah does just hit & run posting? 

I've noticed it - but have you?  

It would be only one post that could easily be ignored, if not for all
this rubbish that you and people like you feel the need to post (sure,
I realize I'm contributing to the problem).  Isn't "hit & run posting"
better than a thread full of nonsense?

-- 
You fool! You fell victim to one of the classic blunders! The most
famous is, "Never get involved in a land war in Asia", but only
slightly less well-known is this: "Never go in against a Sicilian when
death is on the line"!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: John Bokma harassment

[Bill Atkins]

John Bokma <[EMAIL PROTECTED]> writes:

> If Xah posts to just one group, on topic, the problem is gone. But Xah
> is spamvertizing his website, and hence posts to 5 groups (since I guess
> that's a limit GG sets, not Xah), so he doesn't care that a post on
> whitespace in Python ends up in a group on Java or Perl. 

[snip]

> -- 
> John   MexIT: http://johnbokma.com/mexit/
>personal page:   http://johnbokma.com/
> Experienced programmer available: http://castleamber.com/
> Happy Customers: http://castleamber.com/testimonials.html

Interesting.  Doesn't your signature contain advertisements for your
website?  Aren't you posting to five different groups?

-- 
You fool! You fell victim to one of the classic blunders! The most
famous is, "Never get involved in a land war in Asia", but only
slightly less well-known is this: "Never go in against a Sicilian when
death is on the line"!
-- 
http://mail.python.org/mailman/listinfo/python-list