Re: Accumulator

[Paul Prescod <address@hidden>]

Paul Graham wrote:
> 
> 
> (He means http://www.paulgraham.com/icad.html.  At least, I don't
> think I said this on ll1-discuss.)

Yes, thanks. Just thought that people there might be interested.

>...
> 
> It's not the function that holds state.  The variable holds
> state, and the function has a handle on it.  You can see the
> difference when you consider several functions that refer
> to the same variable.  Which incidentally is something you
> can't do with the hack of simulating a closure using a
> method plus fields to hold the values.

You just pass the value to each constructor.

> > For one thing, the mathematical meaning of
> > the word "function" sort of implies statelessness.
> 
> I think programming languages long ago discarded the idea
> that subroutines were functions in this sense.  The mathematical
> idea of a function also implies no side effects, for example.

I agree that people do not think of functions purely mathematically. I
think my point stands: most people are not used to closures and will
prefer a more explicit means to the same end. An APL programmer could
complain that Python is a pain because you have to loop over values
explicitly but I think that's easier to read also. Python is not
supposed to be the union of all existing languages. Rather, it offers
you a way to do everything that you can do in most other languages,
hopefully with only a little more code.

>...
> If it is Lisp-biased, why does Perl do so well?  Or Smalltalk?

Smalltalk was pretty directly Lisp based and Perl got its functional
features from Lisp.

http://www.perl.com/doc/FAQs/FAQ/oldfaq-html/Q3.14.html

> Actually, I was surprised how badly Python did.  I had till
> then believed the story that Python was equivalent to Lisp
> except for macros.  

I don't think Guido ever intended that! Python programmers should do
things in the Python way. State + Behaviour = Instance, not closure.

> .... I was kind of shocked, for example, to
> find that you can't put the same things in the body of a
> lambda expression as you can in a named function.  That
> just seems like a bug to me.

You're right, it is a bug. But you're missing something. Adding lambda
to an OO language was a bug to start with. Guido hasn't "fixed" lambda
because he wants it to go away. Trying to be Lisp was the mistake.

"Q. What feature of Python are you least pleased with? 

Guido: Sometimes I've been too quick in accepting contributions, and
later realized that it was a mistake. One example would be some of the
functional programming features, such as lambda functions. lambda is a
keyword that lets you create a small anonymous function; built-in
functions such as map, filter, and reduce run a function over a sequence
type, such as a list."

He wrote that before Python had grown readable alternatives to map,
filter and apply. It is even more true now that you can do stuff like
this:

mult3 = [3 * x for x in numbers]
evens = [x for x in numbers if x % 2 == 0]

Also, lambda in Python is merely syntactic sugar for the function
definition feature that Python has had since 1.0. It is a crippled form
of an existing feature. A clear bug that arose from "Lambda envy."
Features stolen from Haskell, SmallTalk and Icon have actually achieved
more success in Python. So Python is growing towards something but it
isn't Lisp. ;)

>...
> Even within the Lisp world there is debate about this.  Scheme
> set! doesn't return the new value.  I personally think this is
> excessively governessy.  You can always not use the returned
> value if you don't want to.

It's a little bit different. set! has something in the method name that
indicates it has a side effect. foo() doesn't.

>...
> A Cadillac sedan would be more understandable to the vast
> majority of American drivers than a Porsche 911.  That does
> not make it a better car.

I use Python (and not Common Lisp and will probably not use Arc) because
I fundamentally don't feel that there is any need in the programming
world to have languages that cater either to "doofuses" or to race car
drivers. 

First, I think it would also be inappropriate to apply the adjective to
people who don't have the time to become language experts because they
spend their day 

 * inventing the Web (<http://www.w3.org/2000/10/swap/#L88>), 
 * or researching Mayan Calendar systems
(<http://www.pauahtun.org/tools.html), 
 * or doing molecular dynamics
(<http://www.python.org/workshops/1997-10/proceedings/beazley.html>) 
 * or doing biology (<http://www.biopython.org/>) or ...
 * or going to high school
(<http://www.python.org/workshops/2000-01/proceedings/papers/elkner/pyYHS.html>) 

Second, I know that language geeks who like to learn languages and know
dozens of them (typically including Lisps) who still often choose it to 

 * build web application frameworks (<http://www.zope.org>) 
 * and ecommerce sites (<http://www.lyra.org/greg/CaseStudy/>) 
 * and do knowledge management
(<http://www.fourthought.com/Thoughts/Presentations/>) 
 * and build distributed file systems (<http://mnet.sourceforge.net/>) 
 * and teach AI (http://www.norvig.com/python/python.html) 
 * and hack search engines
(http://groups.google.com/groups?hl=en&selm=gat-1902021257120001%40eglaptop.jpl.nasa.gov&rnum=1)
...
 * and skip high school (<http://www.aaronsw.com/>) 

To me the integration of those many communities is a really important
form of scalability. I can cobble together code that builds on the stuff
from the domain experts and hard-core programmers and then offer it up
as a library to the high school students. And I very seldom have the
sense that the high schoolers feel like they've been handed an out of
control power tool nor that the power users feel that they've been
handed a toy. Maybe there is a tradeoff here but it remains to be
demonstrated. Many previous Common Lisp programmers (and even more
previous Scheme programmers) are quite happy with Python. 

By the way, this isn't theory. I have made had jobs writing really
complicated Python code which I throw across the wall to domain experts
(document analysts) who embed it in customer solutions.

>...
> Also, if a language is designed for dufuses, you should
> not be disappointed if it loses to other languages in
> technical comparisons.  

What technical comparison? ;)

Python was not designed to be the world's most powerful language: there
is no such thing as "most powerful" for all things. But you haven't
really shown that Common Lisp is more powerful for even ONE thing. A
conversion of a Lisp idiom to non-idiomatic Python is not really a
technical comparison. Do something real. Show me thirty lines of
convoluted Python that compress to ten lines of readable Common Lisp.

>...
> Mutable closures, as you call them, are pretty useful.  If I
> remember correctly, every page generated by the Viaweb editor
> used this technique.

You get equivalent power in Python through a different means. Objects
and closures are isomorphic.

> As for macros, none of Lisp's features exists in isolation.
> Macros would be not be nearly as good without rest parameters,
> or lexical scope.

Python has rest (as well as keyword) parameters and lexical scope (but
not what you might call rebindable lexicals).

>...
> > Also, if anyone has time, I would be curious what the Common Lisp
> > equivalent of the class-based version looks like.
> >
> 
> God only knows.

Are you saying it is hard to translate this into Common Lisp?

class acc:
	def __init__(self, start):
		self.cur = start
	def inc(self, howmuch):
		self.cur += howmuch
	def dec(self, howmuch):
		self.cur -= howmuch

a = acc(20)
a.inc(5)
a.dec(3)
print a.cur

It wasn't a trick question.

 Paul Prescod