Re: Lambda: the Ultimate Design Flaw
In article [EMAIL PROTECTED], =?iso-8859-1?Q?Fran=E7ois?= Pinard [EMAIL PROTECTED] wrote: [Aahz] [François] Many of us are using Python today, week after week, year long. So let's be pragmatic. Python is what it became and now is. Let's not define it as a memory from the past nor as a futuristic dream. You're free to continue using 1.5.2. [...] Sure, of course. Yet, our friendly argument is sliding away from was it originally was. The point was about not asserting in this forum that Python has only one way to do it, because this is not true anymore. The principle has been, it may be back in some distant future, but now it is not. You're conflating two different things: * Whether Python currently has only one way to do things * Whether Python has a design goal of only one way to do things I'll agree that Python currently has many examples of more than one way to do things (and even Python 3.0 won't remove every example, because anything more complicated than a Turing Machine has more than one way to do things). But I won't agree that Only One Way has been abandoned as a design principle. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
On Apr 7, 2005 1:15 AM, Greg Ewing [EMAIL PROTECTED] wrote: Scott David Daniels wrote: Aahz wrote: You just can't have your cake and eat it, too. I've always wondered about this turn of phrase. I seldom eat a cake at one sitting. You need to recursively subdivide the cake until you have a piece small enough to fit in your input buffer. Then the atomicity of the cake-ingestion operation will become apparent. +1 QOTW -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
[Aahz] I'll agree that Python currently has many examples of more than one way to do things (and even Python 3.0 won't remove every example [...]). But I won't agree that Only One Way has been abandoned as a design principle. To summarize, instead of saying Python has only one way to do it, rather say Python will eventually have only one way to do it, and with such a wording, nobody will not be mislead. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
On 7 Apr 2005 11:11:31 -0400, [EMAIL PROTECTED] (Aahz) wrote: You're conflating two different things: * Whether Python currently has only one way to do things * Whether Python has a design goal of only one way to do things I'll agree that Python currently has many examples of more than one way to do things (and even Python 3.0 won't remove every example, because anything more complicated than a Turing Machine has more than one way to do things). But I won't agree that Only One Way has been abandoned as a design principle. I would add that the meaning is: Python has one obvious best way to do things. Meaning that the most obvious and clearest way, the way that comes to mind first, will in most cases, also be the best way. I seem to remember reading it put in that way some place at some time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Greg Ewing wrote: Scott David Daniels wrote: Aahz wrote: You just can't have your cake and eat it, too. I've always wondered about this turn of phrase. I seldom eat a cake at one sitting. You need to recursively subdivide the cake until you have a piece small enough to fit in your input buffer. Then the atomicity of the cake-ingestion operation will become apparent. Ok course according to Tarski we can cut the cake up so it increases in volume. The slices have to be immeasurable, but the final volume can be almost anything. I bet that makes cake buffering harder to plan for. -paradoxically yrs- Robin Becker -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Robin Becker wrote: Greg Ewing wrote: Scott David Daniels wrote: Aahz wrote: You just can't have your cake and eat it, too. I've always wondered about this turn of phrase. I seldom eat a cake at one sitting. You need to recursively subdivide the cake until you have a piece small enough to fit in your input buffer. Then the atomicity of the cake-ingestion operation will become apparent. Ok course according to Tarski we can cut the cake up so it increases in volume. The slices have to be immeasurable, but the final volume can be almost anything. I bet that makes cake buffering harder to plan for. -paradoxically yrs- Robin Becker Not at all - we just apply the same division techniques to the buffer space until we can map the pieces of cake one-to-one onto the buffers. stick-that-in-your-cakehole-ly y'rs - steve -- Steve Holden+1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Steve Holden wrote: Not at all - we just apply the same division techniques to the buffer space until we can map the pieces of cake one-to-one onto the buffers. That technique can be applied to layer cakes, but not all real cakes. Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Ulrich Hobelmann wrote: alex goldman wrote: I personally think GOTO was unduly criticized by Dijkstra. With the benefit of hindsight, we can see that giving up GOTO in favor of other primitives failed to solve the decades-old software crisis. The fault of goto in imperative languages is that it has no arguments, thus creating spaghetti of gotos and assignments. Continuations rule! While continuations are a very interesting abstraction, the improvement of structured programming was to be able to prove properties of your programs in time linear to the size of the program instead of quadratic. I don't see how giving arguments to the GOTO would help there. Ciao, Perle -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
In article [EMAIL PROTECTED], =?iso-8859-1?Q?Fran=E7ois?= Pinard [EMAIL PROTECTED] wrote: [Aahz] I'll agree that Python currently has many examples of more than one way to do things (and even Python 3.0 won't remove every example [...]). But I won't agree that Only One Way has been abandoned as a design principle. To summarize, instead of saying Python has only one way to do it, rather say Python will eventually have only one way to do it, and with such a wording, nobody will not be mislead. Let's go back to the original comments, shall we? [...] for Pythons ideal of having one canonical, explicit way to program. No doubt it once was true, but I guess this ideal has been abandoned a few years ago. My honest feeling is that it would be a mis-representation of Python, assertng today that this is still one of the Python's ideals. Your claim that the ideal has been abandoned is just plain wrong. In addition, nobody has ever said Python has only one way to do it. The actual principle from ``import this`` is There should be one-- and preferably only one --obvious way to do it. Some people have advocated that Python's motto should be There's Only One Way as a counterpoint to Perl's TMTOWTDI -- but that's different from the design principle. Which I repeat has not been abandoned, but should be understood to exist alongside eighteen other design principles for Python. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Aahz [EMAIL PROTECTED] Pinard [EMAIL PROTECTED] wrote: Sure, of course. Yet, our friendly argument is sliding away from was it originally was. The point was about not asserting in this forum that Python has only one way to do it, because this is not true anymore. The principle has been, it may be back in some distant future, but now it is not. You're conflating two different things: * Whether Python currently has only one way to do things * Whether Python has a design goal of only one way to do things I'll agree that Python currently has many examples of more than one way to do things (and even Python 3.0 won't remove every example, because anything more complicated than a Turing Machine has more than one way to do things). But I won't agree that Only One Way has been abandoned as a design principle. The statement in the Zen of Python is There should be one-- and preferably only one --obvious way to do it. The splits into two related statements: There should be [at least] one obvious way to do it. There should preferably be only one obvious way to do it. Commentary: While 'should' can mean 'must', it can also mean something something softer, like desireability and preference. In Pythonese, it has (as far as I know) such softer meanings, with 'must' used when 'must is meant. In the second sentence, preference is made explicit. The presence of 'obvious' is obviously not accidental. Without it, and with 'should' replaced with 'must', we eventually end up with any of numerous simple, possibly interesting, and mostly practically useless Turing-equivalent systems. The qualifier 'obvious' does not exclude non-obvious ways. For example, the obvious way, in Python, to add 1 and 2 to get 3 is '1+2'. Two non-obvious (certainly for the beginner) ways are '1 .__add__(2)' [space required] and 'import operator; operator.add(1,2)'. Unfortunately, 'obvious' too often get elided in the discussion of this principle. For some, its because it is so obviously needed that it seems to not need to be said. For others, it appears to be because they are not fully cognizant of it. The result can be people talking past each other. And, of course, obviousness is somewhat in the mind of the beholder. The first sentence provides impetus to add new features that 'should be' present but are not. At this point, that mostly means new library modules. The second principle inhibits (but not absolutely prevents) adding 'obvious' redundancy. When exceptions are made, the principle of not breaking code prevents deleting the old except after a while and very occasionally. The inhibitory principle does encourage attempts to relegate the old to a less obvious status by treatments in the tutorial and manuals. The inhibitory principle is certainly still alive. Function decorators barely made it past. The proposal to extend them to classes has so far been rejected by GvR since class decorators seem redundant with metaclasses. And lots else has been ignored or rejected. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
François Pinard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] To summarize, instead of saying Python has only one way to do it, As I explained in response to Aahz, what Tim Peters wrote was that Python 'should preferably have only one obvious way to do it'. Omission of the crucial qualifiers 'should preferably' and 'obvious' misleads any discussion. rather say Python will eventually have only one way to do it, and with such a wording, nobody will not be mislead. The actual design principle, as opposed to the impossible oversimplification, does not, in my opinion, mislead. It is applied to every new proposal, most of which get rejected. What I can't tell is whether you wish Python had added less new stuff or had already dumped more old stuff. For myself, I wish the next version would be 3.0 and slimmed down a bit. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Ron_Adam [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Python has one obvious best way to do things. More exactly, 'should preferably have' rather than 'has'. Meaning that the most obvious and clearest way, the way that comes to mind first, will in most cases, also be the best way. I seem to remember reading it put in that way some place at some time. import this # The Zen of Python tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
On Thu, 7 Apr 2005, Frank Wilde wrote: Continuations rule! While continuations are a very interesting abstraction, the improvement of structured programming was to be able to prove properties of your programs in time linear to the size of the program instead of quadratic. I don't see how giving arguments to the GOTO would help there. By allowing you to build your own control structures, whose properties you prove once before using them to prove properties in the programs that use them. -- [EMAIL PROTECTED] There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
On Thu, 7 Apr 2005 17:49:39 -0400, Terry Reedy [EMAIL PROTECTED] wrote: Ron_Adam [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Python has one obvious best way to do things. More exactly, 'should preferably have' rather than 'has'. Meaning that the most obvious and clearest way, the way that comes to mind first, will in most cases, also be the best way. I seem to remember reading it put in that way some place at some time. import this # The Zen of Python tjr ;-) Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
Sunnan == Sunnan [EMAIL PROTECTED] writes: Sunnan It's just that I'm having a hard time matching that quote Sunnan to what I though python was about. I thought boring code Sunnan was considered a virtue in python. (Explicit is better Sunnan than implicit, sparse is better than dense.) Boring code is code that numbs your senses with constant flow of boilerplate crap, memory management and redundant type declarations and general blah blah that you skip when you are trying to figure out what a piece of code does. It's a code that you wish you could train a monkey to write for you while you go for lunch. Think C++ or Java. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
Ville Vainio wrote: Boring code is code that numbs your senses with constant flow of boilerplate crap, memory management and redundant type declarations and general blah blah that you skip when you are trying to figure out what a piece of code does. The python code I've read so far has looked like that. Not type declarations, but lng class declarations. Also, Guido recently urged people to explicitly write recursions rather than to use reduce - which I thought was completely in line with what I've seen as python's goals: readability/understandability as more important than terseness/non-boringness. It's a code that you wish you could train a monkey to write for you while you go for lunch. Think C++ or Java. Oh, yes. C++ and Java can be super boring. C++ can also be pretty hard to understand - it's not all boilerplate. I'm not saying Python is always boring (maybe I've just been in an easily bored mood when I've read Python stuff), and I'm not saying that boring is always bad. Yesterday, I read some marketing prop describing a proprietary IDE (don't remember what language) as exciting, and I went Ugh, no thanks! Give me calm computing. And then I thought - wait: I just ranted about boringness on comp.lang.python. Can't boring and calm sometimes mean the same thing? -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
Sunnan == Sunnan [EMAIL PROTECTED] writes: Sunnan Ville Vainio wrote: Sunnan Also, Guido recently urged people to explicitly write Sunnan recursions rather than to use reduce - which I thought was Sunnan completely in line with what I've seen as python's goals: Sunnan readability/understandability as more important than Sunnan terseness/non-boringness. The problem w/ reduce is that it's not intuitive. You'll have to stop to think what the code w/ reduce does - effectively converting it to a normal loop (not recursion!) in your head. It's a net loss when you compare it to just reading an explicit loop as written in code. Sunnan Yesterday, I read some marketing prop describing a Sunnan proprietary IDE (don't remember what language) as Sunnan exciting, and I went Ugh, no thanks! Give me calm Sunnan computing. And then I thought - wait: I just ranted about Sunnan boringness on comp.lang.python. Can't boring and calm Sunnan sometimes mean the same thing? Not for me at least. 'Boring' implies a certain sense of frustration, not getting anywhere and generally feeling like you are wasting your time. Human attention is a limited resource, and being bored leads to loss of attention. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
Sunnan: The python code I've read so far has looked like that. Not type declarations, but lng class declarations. What do you mean? Lots of repetitive self.variable=variable in the __init__ method? Use of classes when you would use closures? Or maybe you are comparing with CLOS classes, which are pretty slim, since the (multi)methods are defined outside them? Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
[Aahz] [François] Many of us are using Python today, week after week, year long. So let's be pragmatic. Python is what it became and now is. Let's not define it as a memory from the past nor as a futuristic dream. You're free to continue using 1.5.2. [...] Sure, of course. Yet, our friendly argument is sliding away from was it originally was. The point was about not asserting in this forum that Python has only one way to do it, because this is not true anymore. The principle has been, it may be back in some distant future, but now it is not. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Aahz wrote: You just can't have your cake and eat it, too. I've always wondered about this turn of phrase. I seldom eat a cake at one sitting. -Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
On Apr 6, 2005 4:42 PM, Scott David Daniels [EMAIL PROTECTED] wrote: I've always wondered about this turn of phrase. I seldom eat a cake at one sitting. Clearly you're just not trying. ;-) -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
Sunnan wrote:
Aahz wrote:
(snip)
print foo is, foo
Is the space added automatically? (Like awk does, if you add a comma.)
Yes. But you can also format it how you like:
print foo is %s and that's a good news, my friends % foo
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Simon Brunning [EMAIL PROTECTED] writes: On Apr 6, 2005 4:42 PM, Scott David Daniels [EMAIL PROTECTED] wrote: I've always wondered about this turn of phrase. I seldom eat a cake at one sitting. Clearly you're just not trying. ;-) :-))) John -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
Sunnan == Sunnan [EMAIL PROTECTED] writes: Sunnan It's just that I'm having a hard time matching that quote Sunnan to what I though python was about. I thought boring code Sunnan was considered a virtue in python. There's a difference between unsurprising and boring. The coffee I drank this afternoon, for instance, did not surprise me, but I still enjoyed it. -- Greg Ewing, Computer Science Dept, University of Canterbury, Christchurch, New Zealand http://www.cosc.canterbury.ac.nz/~greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Scott David Daniels wrote: Aahz wrote: You just can't have your cake and eat it, too. I've always wondered about this turn of phrase. I seldom eat a cake at one sitting. You need to recursively subdivide the cake until you have a piece small enough to fit in your input buffer. Then the atomicity of the cake-ingestion operation will become apparent. -- Greg Ewing, Computer Science Dept, University of Canterbury, Christchurch, New Zealand http://www.cosc.canterbury.ac.nz/~greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
In article [EMAIL PROTECTED], [EMAIL PROTECTED] says... Artie Gold wrote: Torsten Bronger wrote: The whole text seems to be a variant of http://www.artima.com/weblogs/viewpost.jsp?thread=98196. Tschö, Torsten. Ya think? ;-) Heh. I was glad that Torsten pointed it out; I didn't get what was funny about the joke until then. Please consider joining the International Sarcasm Society. Our motto is Like We Need YOUR Support. == Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News== http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups = East and West-Coast Server Farms - Total Privacy via Encryption = -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
T.D. Lassagne wrote: Please consider joining the International Sarcasm Society. Our motto is Like We Need YOUR Support. I *recognize* sarcasm; I just don't think it's very funny. Now parody, which this turned out to be, I can appreciate. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Hi All-- Aahz wrote: Given the tension of the various requirements, I think that Python has broken only one way as little as possible, with the full intention of getting closer to its ideal when the time comes to break backward compatibility. I wrote my mayalib package under 1.3.0. It still runs perfectly well. I will only have to rewrite parts of it when the string module goes away. Everything else works, and will continue to work for the forseeable future. That's actually less change than happened with C over the same time period. But there, the language didn't change, just the environment around it--includes, libs, where things lived, etc. Metta, Ivan -- Ivan Van Laningham God N Locomotive Works http://www.andi-holmes.com/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
Aahz wrote: Note very, VERY, *VERY* carefully that the quote says nothing about boring code. The quote explicitly refers to reams of trivial code as boring -- and that's quite true. Consider this distinction: Thank you for this important clarification. if foo == 'red': print 'foo is red' elif foo == 'blue': print 'foo is blue' versus print foo is, foo Is the space added automatically? (Like awk does, if you add a comma.) I'm sure you can think of many other examples -- real examples -- if you put your mind to work; Guido's point is about the essential necessity of refactoring and rewriting code for conciseness and clarity. Which is a good point to make in almost any language, for code that is to be maintained. Sunnan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Artie Gold wrote: Torsten Bronger wrote: The whole text seems to be a variant of http://www.artima.com/weblogs/viewpost.jsp?thread=98196. Tsch, Torsten. Ya think? ;-) Heh. I was glad that Torsten pointed it out; I didn't get what was funny about the joke until then. -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
Tim Peters wrote: [Aahz] The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR [Sunnan] Can anyone please point me to the text that quote was taken from? I tried to use a search engine but I only found quotations, not the source. That's because it was originally in email to a company-internal mailing list. If you're willing to move to Fredericksburg, VA and work for Zope Corp, perhaps they'll let you in to the PythonLabs list archives. Fair warning: I work for Zope Corp, and I'm not sure I can get into those archives. So don't switch jobs _just_ for that. It's just that I'm having a hard time matching that quote to what I though python was about. I thought boring code was considered a virtue in python. (Explicit is better than implicit, sparse is better than dense.) Because what is boring? The opposite of dense, tense, intense. Utterly predictable; it's like the combination of all my prejudices. Even before I knew, I thought Bet Python separates statements from expressions. Sunnan PS. (People easily offended can substitute boring for readable in the above text.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
On Sat, 02 Apr 2005 00:40:15 -0500, Steve Holden [EMAIL PROTECTED] wrote: The danger in GOTO is that it allows the undisciplined programmer to develop a badly-structured solution to a programming problem. A disciplined programmer will write well-structured code with whatever tools come to hand. regards Steve And how that becomes really clear when you want to modify a large program that uses GOTOs librally. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
In article [EMAIL PROTECTED], Sunnan [EMAIL PROTECTED] wrote: [Aahz] The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR It's just that I'm having a hard time matching that quote to what I though python was about. I thought boring code was considered a virtue in python. (Explicit is better than implicit, sparse is better than dense.) Because what is boring? The opposite of dense, tense, intense. Utterly predictable; it's like the combination of all my prejudices. Even before I knew, I thought Bet Python separates statements from expressions. Note very, VERY, *VERY* carefully that the quote says nothing about boring code. The quote explicitly refers to reams of trivial code as boring -- and that's quite true. Consider this distinction: if foo == 'red': print 'foo is red' elif foo == 'blue': print 'foo is blue' versus print foo is, foo I'm sure you can think of many other examples -- real examples -- if you put your mind to work; Guido's point is about the essential necessity of refactoring and rewriting code for conciseness and clarity. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Torsten Bronger wrote: Hallchen! Daniel Silva [EMAIL PROTECTED] writes: Shriram Krishnamurthi has just announced the following elsewhere; it might be of interest to c.l.s, c.l.f, and c.l.p: http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html The Fate Of LAMBDA in PLT Scheme v300 or Lambda the Ultimate Design Flaw About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp hackers who missed them from their past experience. To this collection, Scheme added a lexically-scoped, properly-functioning LAMBDA. But, despite of the PR value of anything with Guy Steele's name associated with it, we think these features should be cut from PLT Scheme v300. [...] The whole text seems to be a variant of http://www.artima.com/weblogs/viewpost.jsp?thread=98196. Tsch, Torsten. Ya think? ;-) --ag -- Artie Gold -- Austin, Texas http://it-matters.blogspot.com (new post 12/5) http://www.cafepress.com/goldsays -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Artie Gold wrote: Torsten Bronger wrote: Hallöchen! Daniel Silva [EMAIL PROTECTED] writes: Shriram Krishnamurthi has just announced the following elsewhere; it might be of interest to c.l.s, c.l.f, and c.l.p: http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html The Fate Of LAMBDA in PLT Scheme v300 or Lambda the Ultimate Design Flaw About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp hackers who missed them from their past experience. To this collection, Scheme added a lexically-scoped, properly-functioning LAMBDA. But, despite of the PR value of anything with Guy Steele's name associated with it, we think these features should be cut from PLT Scheme v300. [...] The whole text seems to be a variant of http://www.artima.com/weblogs/viewpost.jsp?thread=98196. Tschö, Torsten. Ya think? ;-) --ag Wow, the original is much funnier than the joke! (Because it's meant seriously) plus the lambda is slower than the list comprehension - ROTFL! -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Daniel Silva wrote: We think dropping FILTER and MAP is pretty uncontroversial; (filter P S) is almost always written clearer as a DO loop (plus the LAMBDA is slower than the loop). Even more so for (map F S). In all cases, writing the equivalent imperative program is clearly beneficial. How about using srfi-42 instead of those nasty do loops? It's pretty clean: (list-ec (: a lis) (* a a)) is equivalent to (map (lambda (a) (* a a)) lis) Before I discovered srfi-42, my code often had hideous things like: (append-map (lambda (item) (map (lambda (inner) (* inner inner)) (cdr item))) lis) to return (1 4 9 16 25 36 49 64 81) for a lis that's '((a 1 2 3) (b 4 5 6) (c 7 8 9))). This becomes even neater: (list-ec (: item lis) (: inner (cdr item)) (* inner inner)) Have a happy first of april! -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Hallchen! Daniel Silva [EMAIL PROTECTED] writes: Shriram Krishnamurthi has just announced the following elsewhere; it might be of interest to c.l.s, c.l.f, and c.l.p: http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html The Fate Of LAMBDA in PLT Scheme v300 or Lambda the Ultimate Design Flaw About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp hackers who missed them from their past experience. To this collection, Scheme added a lexically-scoped, properly-functioning LAMBDA. But, despite of the PR value of anything with Guy Steele's name associated with it, we think these features should be cut from PLT Scheme v300. [...] The whole text seems to be a variant of http://www.artima.com/weblogs/viewpost.jsp?thread=98196. Tsch, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
The Fate Of LAMBDA in PLT Scheme v300 or Lambda the Ultimate Design Flaw Why drop LAMBDA? Why not? Isn't all code eventually anonymous and relocatable? -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
On Thu, 31 Mar 2005 23:30:42 -0800, Erik Max Francis wrote: Daniel Silva wrote: Shriram Krishnamurthi has just announced the following elsewhere; it might be of interest to c.l.s, c.l.f, and c.l.p: http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html April Fool's Day again, eh? Yes and no. In the Python community, we're taking all of that pretty seriously. The scheme community may not seriously be thinking of getting rid of those things, but it's hardly impossible that some people think it might be better off without it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
[Sunnan] [...] for Pythons ideal of having one canonical, explicit way to program. No doubt it once was true, but I guess this ideal has been abandoned a few years ago. My honest feeling is that it would be a mis-representation of Python, assertng today that this is still one of the Python's ideals. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Jeremy Bowers [EMAIL PROTECTED] writes: On Thu, 31 Mar 2005 23:30:42 -0800, Erik Max Francis wrote: Daniel Silva wrote: Shriram Krishnamurthi has just announced the following elsewhere; it might be of interest to c.l.s, c.l.f, and c.l.p: http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html April Fool's Day again, eh? Yes and no. In the Python community, we're taking all of that pretty seriously. The Python community takes many things pretty seriously. Whitespace and Guido come to mind. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Jeremy Bowers wrote: Yes and no. In the Python community, we're taking all of that pretty seriously. The scheme community may not seriously be thinking of getting rid of those things, but it's hardly impossible that some people think it might be better off without it. Lambda is a primitive in Scheme; in some implementations of scheme it's used to implement things like temporary variables (let), sequences (begin) and looping (named let/letrec). Python has other ways of doing these things; and removing things that has been obsoleted or superfluous makes sense, for Pythons ideal of having one canonical, explicit way to program. Having a few very abstract primitives that the rest of the language can theoretically be built upon is one of the reasons why Scheme/Lisp can work as a programmable programming language. Scheme is like Go - a few abstract rules that can be combined in endless, sprawling ways. Python is like (hmm, better let some pythonista answer this. I'm thinking of a game with a clear thematical connection (like Monopoly or The Creature that Ate Sheboygan) and a few explicit rules that combine in ways that is supposed to have a clear, readable, consistent result). Maybe shogi? (I don't usually read comp.lang.python and I really don't want to offend anyone. My apologies if this post is either annoyingly obvious (and thus contains only stuff that's been said a million times), or totally wrong.) Sunnan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
alex goldman wrote: Daniel Silva wrote: At any rate, FOLD must fold. I personally think GOTO was unduly criticized by Dijkstra. With the benefit of hindsight, we can see that giving up GOTO in favor of other primitives failed to solve the decades-old software crisis. The fault of goto in imperative languages is that it has no arguments, thus creating spaghetti of gotos and assignments. Continuations rule! -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
In article [EMAIL PROTECTED], =?iso-8859-1?Q?Fran=E7ois?= Pinard [EMAIL PROTECTED] wrote: [Sunnan] [...] for Pythons ideal of having one canonical, explicit way to program. No doubt it once was true, but I guess this ideal has been abandoned a few years ago. My honest feeling is that it would be a mis-representation of Python, assertng today that this is still one of the Python's ideals. Mind providing evidence rather than simply citing your feelings? Yes, there's certainly redundancy in Python right now, but a large portion of that will go away in Python 3.0. So where's the abandonment of the ideal? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Daniel Silva [EMAIL PROTECTED] writes: [...] So now FOLD. This is actually the one we've always hated most, because, apart from a few examples involving + or *, almost every time we see a FOLD call with a non-trivial function argument, we have to grab pen and paper and imagine the *result* of a function flowing back in as the *argument* to a function. Plus, there are *more* arguments coming in on the side! This is all absurdly complicated. Because almost all the examples of FOLD we found in practice could be written as a simple loop with an accumulator, this style should be preferred, perhaps with us providing a simple helper function to abstract away the boilerplate code. At any rate, FOLD must fold. Couldn't you leave it in for just another month? And during the remaining month, we'll just call it the APRIL FOLD. -- Tom Breton, the calm-eyed visionary -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
On 1 Apr 2005 20:00:13 -0500, [EMAIL PROTECTED] (Aahz) wrote: In article [EMAIL PROTECTED], =?iso-8859-1?Q?Fran=E7ois?= Pinard [EMAIL PROTECTED] wrote: [Sunnan] [...] for Pythons ideal of having one canonical, explicit way to program. No doubt it once was true, but I guess this ideal has been abandoned a few years ago. My honest feeling is that it would be a mis-representation of Python, assertng today that this is still one of the Python's ideals. ^--in particular?? That makes for a complex sentence ;-) Mind providing evidence rather than simply citing your feelings? Yes, there's certainly redundancy in Python right now, but a large portion of that will go away in Python 3.0. So where's the abandonment of the ideal? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
Aahz wrote: The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR Can anyone please point me to the text that quote was taken from? I tried to use a search engine but I only found quotations, not the source. Sunnan -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
[Aahz] The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR [Sunnan] Can anyone please point me to the text that quote was taken from? I tried to use a search engine but I only found quotations, not the source. That's because it was originally in email to a company-internal mailing list. If you're willing to move to Fredericksburg, VA and work for Zope Corp, perhaps they'll let you in to the PythonLabs list archives. Fair warning: I work for Zope Corp, and I'm not sure I can get into those archives. So don't switch jobs _just_ for that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
[Aahz] =?iso-8859-1?Q?Fran=E7ois?= Pinard [EMAIL PROTECTED] wrote: No doubt it once was true, but I guess this ideal has been abandoned a few years ago. My honest feeling is that it would be a mis-representation of Python, assertng today that this is still one of the Python's ideals. Mind providing evidence rather than simply citing your feelings? The important word was honest, not feeling. :-) Yes, there's certainly redundancy in Python right now, [...] See here, I'm not asking you for proofs. :-) but a large portion of that will go away in Python 3.0. And when will that be? The principle of there is only way to do it was observable in Python 1.5.2, and started to disappear at that time. How many years between 1.5.2 and 3.0? So where's the abandonment of the ideal? Many of us are using Python today, week after week, year long. So let's be pragmatic. Python is what it became and now is. Let's not define it as a memory from the past nor as a futuristic dream. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Aahz wrote: In article [EMAIL PROTECTED], =?iso-8859-1?Q?Fran=E7ois?= Pinard [EMAIL PROTECTED] wrote: [Sunnan] [...] for Pythons ideal of having one canonical, explicit way to program. No doubt it once was true, but I guess this ideal has been abandoned a few years ago. My honest feeling is that it would be a mis-representation of Python, assertng today that this is still one of the Python's ideals. Mind providing evidence rather than simply citing your feelings? Yes, there's certainly redundancy in Python right now, but a large portion of that will go away in Python 3.0. So where's the abandonment of the ideal? Mind providing evidence rather than citing your opinions? I don't see any evidence that Python 3.0 will adopt Turing-machine-like canonical algorithms, and anything more complex is (at least from a theoretical point of view) merely syntactic sugar. regards Steve -- Steve Holden+1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
alex goldman wrote: Daniel Silva wrote: At any rate, FOLD must fold. I personally think GOTO was unduly criticized by Dijkstra. With the benefit of hindsight, we can see that giving up GOTO in favor of other primitives failed to solve the decades-old software crisis. What software crisis? Knuth (among others) has demonstrated that it's possible to do structured programming in assembly language (though I have to say that not all his MIX was particularly well-structured). The danger in GOTO is that it allows the undisciplined programmer to develop a badly-structured solution to a programming problem. A disciplined programmer will write well-structured code with whatever tools come to hand. regards Steve -- Steve Holden+1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Lambda: the Ultimate Design Flaw
Shriram Krishnamurthi has just announced the following elsewhere; it might be of interest to c.l.s, c.l.f, and c.l.p: http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html The Fate Of LAMBDA in PLT Scheme v300 or Lambda the Ultimate Design Flaw About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp hackers who missed them from their past experience. To this collection, Scheme added a lexically-scoped, properly-functioning LAMBDA. But, despite of the PR value of anything with Guy Steele's name associated with it, we think these features should be cut from PLT Scheme v300. We think dropping FILTER and MAP is pretty uncontroversial; (filter P S) is almost always written clearer as a DO loop (plus the LAMBDA is slower than the loop). Even more so for (map F S). In all cases, writing the equivalent imperative program is clearly beneficial. Why drop LAMBDA? Most Scheme users are unfamiliar with Alonzo Church (indeed, they don't even know that he was related to Guy Steele), so the name is confusing; also, there is a widespread misunderstanding that LAMBDA can do things that a nested function can't -- we still recall Dan Friedman's Aha! after we showed him that there was no difference! (However, he appears to have since lapsed in his ways.) Even with a better name, we think having the two choices side-by-side just requires programmers to think about their program; not having the choice streamlines the thought process, and Scheme is designed from the ground up to, as much as possible, keep programmers from thinking at all. So now FOLD. This is actually the one we've always hated most, because, apart from a few examples involving + or *, almost every time we see a FOLD call with a non-trivial function argument, we have to grab pen and paper and imagine the *result* of a function flowing back in as the *argument* to a function. Plus, there are *more* arguments coming in on the side! This is all absurdly complicated. Because almost all the examples of FOLD we found in practice could be written as a simple loop with an accumulator, this style should be preferred, perhaps with us providing a simple helper function to abstract away the boilerplate code. At any rate, FOLD must fold. --The PLT Scheme Team -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Daniel Silva wrote: Shriram Krishnamurthi has just announced the following elsewhere; it might be of interest to c.l.s, c.l.f, and c.l.p: http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html April Fool's Day again, eh? -- Erik Max Francis [EMAIL PROTECTED] http://www.alcyone.com/max/ San Jose, CA, USA 37 20 N 121 53 W AIM erikmaxfrancis If you can't fight and you can't flee, flow. -- Robert Elliot -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
Daniel Silva wrote: At any rate, FOLD must fold. I personally think GOTO was unduly criticized by Dijkstra. With the benefit of hindsight, we can see that giving up GOTO in favor of other primitives failed to solve the decades-old software crisis. -- http://mail.python.org/mailman/listinfo/python-list
