Re: The Modernization of Emacs: terminology buffer and keybinding
[EMAIL PROTECTED] wrote: On Oct 8, 7:32 am, Joost Kremers [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Don't both man and those words for measurement come ultimately from words for hand (similarly to words like manual, as in labor)? no. Do not bluntly contradict me in public. I am reminded of my tai chi teacher in NYC, who used to come over to correct me and say, I used to do it that way. Or, What you are doing is good. What I do is His school is very successful. kenny -- http://www.theoryyalgebra.com/ Mother always told me, if you tell a lie, always rehearse it. If it don't sound good to you, it won't sound good to no one else. - Satchel Paige -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Matthias Benkard wrote: So this has nothing to do with freedom in /any/ sense of the word, it has to do with a political agenda opposed to the idea of private property. Freedom is inherently political, you know. You're condemning the FSF for being political, although the FSF's stated purpose is a political one. Oh, I missed that. I just saw something about software should be shared and programmers should be content with an hourly wage, not sales. kt -- http://www.theoryyalgebra.com/ We are what we pretend to be. -Kurt Vonnegut -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
Damien Kick wrote: Giorgos Keramidas wrote: On Fri, 22 Jun 2007 23:08:02 -, [EMAIL PROTECTED] wrote: So much for the free in free software. If you can't actually use it without paying money, whether for the software or for some book, it isn't really free, is it? Please do not confuse the term 'free' in 'free software' with 'gratis'. 'Gratis', i.e. 'lacking a monetary price tag' is something *very* different from the meaning of 'free' in 'free software'. Sure, but where does the infection thing come in? Suppose RMS publishes a new library call add-42, whose api is add-42, inputs n, outputs n+42, source left as an exercise, and Kenny decides he can use it, it is great. Now if Kenny uses it in his commercial software, add-42 does not somehow become less free to ride 'neath the starry skies above, don't fence me in. But RMS wants Kenny's hide. Nothing Kenny wrote derived from add-42, but RMS wants it all. Kenny happened to solve the traveling salesman problem and protein-folding and passed the fricking Turing test by using add-42 wherever he needed 42 added to a number, and RMS wants credit and ownership and control of it all. He and his license shall now dictate access and use of all that code. The handcuffs are on, and they are inscribed free. No wonder the GPL has gone nowhere. Freely. RMS reasonably wanted that add-42 not get co-opted, but that in no way necessitated the land grab that is GPL. The GPL is a gratuitous reach only fancifully justified by wanting to ensure that open source remain open. So this has nothing to do with freedom in /any/ sense of the word, it has to do with a political agenda opposed to the idea of private property. kzo -- http://www.theoryyalgebra.com/ We are what we pretend to be. -Kurt Vonnegut -- http://mail.python.org/mailman/listinfo/python-list
Re: Microsoft's Dynamic Languages Runtime (DLR)
[EMAIL PROTECTED] wrote: On May 2, 1:22 pm, sturlamolden [EMAIL PROTECTED] wrote: On Monday Microsoft announced a new runtime for dynamic languages, which they call DLR. It sits on top of the conventional .NET runtime (CLR) and provides services for dynamically typed languages like Python or Lisp (thus the cross-posting). Apparently is is distributed under a BSD-like open-source license. I am curious to know how it performs in comparison to CPython and an efficient compiled Lisp like CMUCL. Speed is a major problem with CPython but not with .NET or CMUCL, so it will be interesting to see how the DLR performs in comparison. It would be great to finally see a Python that runs on steroids, but knowing M$ bloatware my expectations are not too high. Has anyone looked at the DLR yet? What are your impression? Jim Hugunin har written about the DLR in his blog: http://blogs.msdn.com/hugunin/ To cite one of the comments: Fuck this microsoft bollocks! You just stole the Lisp runtime ideas and fucked them up by stupid it salesman lingo. (Khrishna) Sturla Molden I realize this is a stupid question, but why did you cite the most offensive comment to this blog post? Most of them were positive. Yes, but everybody hates Microsoft, so there ya go. Anyway, here is the real question: thin layer? I wonder then if anything has changed since: http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/2f9759fa3e8877eb/2b11ecfdc4a15fb4?q=rettig+clr_done=%2Fgroups%3Fq%3Drettig+clr%26hl%3Den%26lr%3D%26c2coff%3D1%26safe%3Doff%26sa%3DN%26tab%3Dwg%26_doneTitle=Back+to+Searchd#2b11ecfdc4a15fb4 Anyway, doesn't matter, just fun to see MS running up the white flag after their ballsy attempt to get CL to do the same at ILC 2005. kt -- http://www.theoryyalgebra.com/ Algebra is the metaphysics of arithmetic. - John Ray As long as algebra is taught in school, there will be prayer in school. - Cokie Roberts Stand firm in your refusal to remain conscious during algebra. - Fran Lebowitz I'm an algebra liar. I figure two good lies make a positive. - Tim Allen -- http://mail.python.org/mailman/listinfo/python-list
Re: Microsoft's Dynamic Languages Runtime (DLR)
sturlamolden wrote: On May 3, 2:15 am, Kaz Kylheku [EMAIL PROTECTED] wrote: Kindly refrain from creating any more off-topic, cross-posted threads. Thanks. The only off-topic posting in this thread is your own (and now this one). Begone. FWIW, I took Kaz's remark to be more of a joke than an actual cease-desist thing, partly because we here recorgnize that every nod to dynamic languages brings us one day closer to the ascendance of Common Lisp to Its Rightful Place on the throne and all other languages being pushed into the sea, and partly because we all actually enjoy long, drawn-out, flamewars with other NGs. For example, my guess is that the DLR/Iron Python just proves that the CLR had enough chops to support a hack like Python, but not enough to support The Greatness of Common Lisp. See how that works? :) kenny -- http://www.theoryyalgebra.com/ Algebra is the metaphysics of arithmetic. - John Ray As long as algebra is taught in school, there will be prayer in school. - Cokie Roberts Stand firm in your refusal to remain conscious during algebra. - Fran Lebowitz I'm an algebra liar. I figure two good lies make a positive. - Tim Allen -- http://mail.python.org/mailman/listinfo/python-list
Re: is laziness a programer's virtue?
Xah Lee wrote: Dear Ken, I want to thank you for your spirit in supporting and leading the lisp community, in spreading lisp the language both in what you have done technically as well as evangelization, as well as the love and knowledge attitude towards newsgroup communities in general, in part thru your numerous replies to my posts in the past years. Hey, thx, but to me recommending Lisp is like recommending water to a life form. Meanwhile, the last thing anyone can doubt is that you say what you mean and mean what you say, so all we can say about your detractors is... (as opposed to, the motherfucking pack of driveling and fuckface ignoramuses that are predominate personalities in newsgroups, ...OK, but we know this from long Usenet experience. Reaching Enlightenment means smiling on these noisemakers and having compassion for them, for they live in mean, narrow worlds and in attacking you are only reaching for the sunlight you enjoy, in however their ignorant way. The nice thing about this compassionate view is that it leaves you feeling positive and at peace within yourself, whereas the driveling and fuckface thing leaves you feeling negative and attacked. less good, for my money. ken -- http://mail.python.org/mailman/listinfo/python-list
Re: is laziness a programer's virtue?
George Neuner wrote: On 17 Apr 2007 08:20:24 -0700, Ingo Menger [EMAIL PROTECTED] wrote: On 17 Apr., 12:33, Markus E Leypold [EMAIL PROTECTED] wrote: What makes Xah a troll is neither off-topic posts nor being incoherent -- its the attitude. He's broadcasting his drivel to a number of groups not with the intention to discuss (he hardly ever answers to answers to his posts), but solely with the intention to inform the world at large about his own magnificient thoughts. This hits the nail on the head. Perhaps one could understand this behaviour on cultural grounds. In chinese culture it may be not uncommon to write something that merely sounds like great wisdom and it is nevertheless appreciated because it's a piece of calligraphic art. Trying to correct Xah's behaviour is probably impossible. Perhaps somebody could ask the chinese government to put him in jail for hurting international society :) That's going to be tough because, according to his web page, he's living in a Honda Civic somewhere in Illinois, USA. Oh, not to fear, we have The Patriots Act, if Dubbya was an Emacs fan Xah would be tanning nicely already at Gitmo. kzo -- http://www.theoryyalgebra.com/ Algebra is the metaphysics of arithmetic. - John Ray -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Brian Adkins wrote: John Nagle wrote: Neither Lisp nor Python is an industrial strength language. The infrastructure is too weak. Hosting providers and distro makers aren't concerned over whether Python works. They care if C, C++, Java, PHP, and Perl work, but not Python or LISP. Ask them. John Nagle In your excitement to post a sweeping and inaccurate generalization (you missed diss'ing Ruby), I think you may have missed the point of my post. I surely wasn't trying to restart a dead thread, I just thought it was funny that there was a similarity to a line from Princess Bride in the thread (see relevant part below that you cut out). If you want to restart a debate, please go back and reply to some serious post in the thread - don't hijack mine for your own evil purposes and cut out the good parts - did you even see the movie? Yes. I think George did, too. (I was wondering what you were up to.) :) kt George Sakkis wrote: You keep using that phrase. I don't think it means what you think it means. [Vizzini has just cut the rope The Dread Pirate Roberts is climbing up] Vizzini: HE DIDN'T FALL? INCONCEIVABLE. Inigo Montoya: You keep using that word. I do not think it means what you think it means. -- Well, I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd In this world, you must be oh so smart or oh so pleasant. -- Elwood's Mom -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
John Nagle wrote: Brian Adkins wrote: John Nagle wrote: If you want to restart a debate, please go back and reply to some serious post in the thread - don't hijack mine for your own evil purposes and cut out the good parts - did you even see the movie? If you want to post jokes... fer chrissakes, it was the OP of means what you think it means who was obviously doing Princess Bride and being reasonably funny, Brian just missed that it was deliberate. , try ... comp.lang.lisp. All the SBCL bug reports are starting to drag down the mood of this NG. kt -- Well, I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd In this world, you must be oh so smart or oh so pleasant. -- Elwood's Mom -- http://mail.python.org/mailman/listinfo/python-list
Re: Jobs: Lisp and Python programmers wanted in the LA area
Tech HR wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: On Feb 26, 6:32 am, Tech HR [EMAIL PROTECTED] wrote: Our website is currently a LAMP appication with P=Python. We are looking for bright motivated people who know or are willing to learn Python and/or Linux, Apache and MySQL system administration skills. (And if you want to convince us that we should switch over to Postgres, we're willing to listen.) This is more out of curiosity, but does it mean that you wouldn't be willing to listen about a switch from Python to Lisp? No, it doesn't mean that. In fact, there is a significant faction in the technical staff (including the CTO) who would like nothing better than to be able to use Lisp instead of Python. Ah, you must lack courage in your convictions. Unless you plan on being out of business in six months, Do the Right Thing. Use the best language. Then worry about little things like libraries and filling seats. There is a great saying, Think you can or think you cannot, either way you will be right. Something like that. But we have some pretty compelling reasons to stick with Python, not least of which is that it is turning out to be very hard to find Lisp programmers. (Actually, it's turning out to be hard to find Python programmers too, but it's easier to train a Java programmer or a Perler on Python than Lisp. Place two ads, both for Java/Perl/C programmers. One looking for folks willing to learn Python, one for those willing to learn Lisp. I guarantee you respondents to the second group will be more fun to go bar-hopping with. Oh, and twice as good at programming as the first group. You are solving the wrong problem. lisp is the best language and we cannot find Lisp programmers. The problem is not the choice of Lisp, the problem is finding people to program Lisp. They do not have to be Lisp programmers with certified scorched areas from being flamed by me on c.l.l. They just need to be great programmers, in any language. Choosing Lisp will make all of you twenty to one hundred percent happier to go to work each day and stay a little longer each night to grind out CFFI bindings for the libs you need. Hiring a good programmer to learn Lisp will have them putting in about a hundred hours a week and loving it. Tap into the energy, man. We also have fair bit of infrastructure built up in Python at this point.) Do I tell you my problems? :) kt -- Well, I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd In this world, you must be oh so smart or oh so pleasant. -- Elwood's Mom -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[EMAIL PROTECTED] wrote: Come on; you guys can't just leave this at 999 posts! Funny you should whine, i was just getting ready to sign off with: I noticed while singing the praises of auto-indentation that there was a shortcoming in The Greatest Feature Known to Editing source code, which is the ability to copy an arbitrary block of code (say, a case statement in the else branch of an if statement in a loop) with a single control-click of the mouse, viz, that I still had to reindent if it was a multiline statement. The first line of course landed exactly where I clicked so that was fine, but other lines in the block were retaining the indentation extant at the time of the click. A few glasses of...cough a few hours ago I dashed off an RFE to Franz tech support apologizing for a trivial matter but wondering if it might not be just a line or two, and lawdy-it-must-be-xmas a glass later back came a patch I am just wallowing in. interestingly, the techie happens not to have been a user of control-click, probably a hardcore keyboard guy who never touches the mouse. I started programming GUIs on a Mac 512, didn't /have/ a keyboard.*** And now the punch line: spare me the oh gosh reindentation is so easy dodge. So is a manual control-shift-p to auto-reindent after an ungainly paste, but this is definitely one of those deals where we don't notice until we stop hitting ourselves with that hammer. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm BLISS programs Just Work. Never revisited, they Never get refined. - Warnock's Explanation of Large Programs -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
greg wrote: Ken Tilton wrote: I did explain the last little fun bit (where reverse code miraculously got a case-specific signed-value parameter bound to exactly the right bit of math structure). I didn't mention that because it was addressed by another poster. The signature of the user's reverse function can be made extremely flexible if you have the foresight to define it as something like def reverse(resx, opnd, **kwds): ... Then you can later change it to def reverse(resx, opnd, signed_value, **kwds): ... and any existing reverse functions will just absorb and ignore the extra argument. However, rather than add an ever-increasing number of arguments to the signature, I think I would do it a different way: pass a single object with attributes. For the want of a better name, let's call it env for environment. The signature is then def reverse(env): ... and the body can refer to env.resx, env.opnd, env.signed_value, or whatever else is required. Looks promising. How does a generic engine that sees only a solution (a list of mathematical expressions and for each the transformations, results, and opnds logged by individual TF functions) build up this environment such that it has named attributes such as signed-value? Assume that it can examine all those opnds and results looking for tagged values such that it then knows the name of those values that have been named. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Kay Schluehr wrote: Ken Tilton schrieb: Looks promising. How does a generic engine that sees only a solution (a list of mathematical expressions and for each the transformations, results, and opnds logged by individual TF functions) build up this environment such that it has named attributes such as signed-value? Most likely it doesn't since there is no such engine. Instead local rules and combinators are encoded in classes. Hence there is nothing but an object tree and actions are threaded through recursive method calls. Most likely that is the engine of which I was speaking. :) Why does the engine consisting of internal methods make it not an engine? I think you saw the word engine and assumed I did not understand OO design. I feel a Naggum coming on... kt ps. This won't make sense unless you know about my Cells project, but the solution to a /problem/ which has attributes expr and instructions, is a declarative attribute of a problem. But that attribute is coded essentially like this: (defclass problem () (solution :accessor solution :initform (c-formula () (solve (expr self) (instructions self) k This implies that the generic reverse function is just the dual of a method call: def reverse(expr): return expr.reverse() What expr does depends on the internal representation encoded in the class of expr. This also implies that not only the form of the expression is significant but also its ( dynamic ) type. -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[EMAIL PROTECTED] wrote: Ken Tilton wrote: [EMAIL PROTECTED] wrote: Code is data is code I was hoping no one would make that mistake. :) macros are all about code is data, but code is not data in Python* so the two words code and data serve to differentiate them for Pythonistas. I disagree. I might agree. The suggest alternative where the engine would build up an environment such that a lambda could seem to be accessing a pre-defined slot-name reminded me of some of the magic I noticed when trying to port Cells to Python. If the interpreter (as it seems) gracefully handles things like that, then one could argue that Python can at least generate code to be consumed by what I would have as a macro body, and thus achieve a degree of code is data. Of course then I would point out that this would be terribly confusing and should be banned from Python for the same reason as are macros. :) I frequently write data-driven algorithms in C and Python (data is code). I occasionally write code-generators too (code is data). Just because the representation is different between code and data in those languages doesn't mean that you can't use data as code (interpreter style) or generate code as data (compiler style). (I won't bother boring you with the Python bytecode hacks or the parser module, because I think those are not terribly practical.) It's very elegant that Lisp makes the representations between code and data so similar, but it looks like you know the mantra and not the meaning if you can't apply that principle in other languages. BTW... Even in Scheme, I have to use syntax-object-datum and it's inverse to switch between the two. I suspect this has something to do with the other context that must be associated with the data to turn it into code. Probably at least the enclosing environment for lexical scoping and the line numbers for debugging or exception handling. Does Common Lisp maintain this information with it's macro expansions? If so, you have a slight difference between code and data too. If not, how do you get the line number when a problem happens in a nested macro? Moreover, if you really want to be pedantic about what is means in code is data, then you have to acknowledge that data is a superset of code, since all code is obviously data, but there are plenty of types of data that aren't used as code. Or are they? :-) * Taking questions after a keynote to ILC200? where he reiterated that Python was the same as Lisp for all intents and purposes: Norvig: Yes, John? McCarthy: Is code also data in Python? Norvig: No. End of exchange. :) Really? You're relying on an appeal to authority? Ok, I'm going to start arguing by analogy then... Analogies! My favorite! When a state trooper tells me not to drive my Corvair over 55 that is argument from authority. When Ralph Nader tells me def reverse(cls, *args): # I didn't understand what your code was doing yeah, and god forbid you should ask. :) this is the crux of the matter! Actually, it is kinda cool that you and Greg are semi-identifying the crux by saying this is the only bit I do not get, I'll skip this, move on, nothing to see here. Ok, I'll bite. What does it do? There's been more on this elsewhere and I need to get some work done, so i am afraid from now on it will have to be analogies and arguments from authority, much faster. I read through it, and it looks the code you're passing to the macro does some things like calculating the number of decimal digits and generating a 2 + a random number of that many digits to find a divisor or something. It also looks like you have some string interpolation to substitute names in your text, but as a whole, I really don't have any clue what it's all about. It looks like the macro itself is building some names on the fly and defining methods (new specializations for multimethods?) with those names. So I'm sure I'm missing something, but there is almost certainly a readable equivalent in Python (and even C). If you really want to generate dynamic names for functions, you can do that in Python by modifying the class or globals hash or whatever. A more standard way might be to be have members in the base class. There is even a multi-methods module in Python, but I've never used it. I'd guess you could add to that dynamically too. That would be a reasonable place for a pie decorator on a class, but I guess that's not allowed. Hmmm. Actually, that is the whole point, all of Python is allowed. decorators were used in PyCells, but I never got much of an idea what they did. Is there a moral equivalent of a macroexpansion for decorators so you can show the before and after? It's Python that doesn't allow you to decorate classes. (You can decorate functions, but not classes...) I made this comment as a criticism of Python since it seems like a non-orthogonal
Re: merits of Lisp vs Python
greg wrote: Ken Tilton wrote: So this: (defmethod tf-reverse (id (eql ',sub-id)) resx (drv-opnds tf drv)) ,@reverser) becomes this: (defmethod tf-reverse ((id (eql ',sub-id)) tf drv aux (opnds (drv-opnds tf drv))) (loop for resx in (results drv) ,@reverser)) I don't see why you can't just write a function that loops over the results and calls the user's reversal function for each one. That was the original coding, but notice that a derivation (DRV) is an argument to tf-reverse. Can you say encapsulation? :) What if that changes? It did. I used to have just one result per derivation, until a multi-result case came along. Since I will be having many dozens of these I might well try to keep as much code as possible out of them (encapsulation de damned g) to minimize the inevitable hit when I refactor, but I have macros so I do not have to. def reverse_multiple(skill, resx_list, opnds): for resx in rex_list: skill.reverse(resx, opnds) There's no need to macro-expand this code into every reversal function, when it can be done once as part of the framework that calls the reversal functions. Rather than go into argue mode before fully understanding the issues, please note that I am just looking to learn (without judgment) what the Python equivalent would be. Things I offer are not you can't touch this!, they are what does the Python look like?. Afterwards we can get into a pissing match. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
greg wrote: Ken Tilton wrote: The reason I post macro expansions along with examples of the macro being applied is so that one can see what code would have to be written if I did not have the defskill macro to write them for me. It seems to me your brain is somewhat stuck on the use of macros. You're looking at the expansion of your macro and assuming that you'd have to write all that code by hand if you didn't have macros. You're not thinking about alternative approaches,... I think your brain is stuck on flaming. I am not thinking about Python approaches, I am sking Pythonistas to do that. After understanding my examples. Unfortunately I do not see the latter really happening, so we are about done here. Unless there's something very subtle that I'm missing (I can't claim to follow exactly what all the code you posted does in detail) I haven't seen anything that couldn't be done quite reasonably with an appropriate data structure and ordinary functions and methods operating on that data structure. I did explain the last little fun bit (where reverse code miraculously got a case-specific signed-value parameter bound to exactly the right bit of math structure). This process works only if you then ask specifically about that (if anything was unclear--my guess is you did not try all that hard since you are in argue-mode). The other reason you may not have understodd is that that is way meta-cool, so meta I do understand if it went over your head and I would (have been) happy to explain had you asked. Time to put the game on, I think. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
greg wrote: Ken Tilton wrote: The last example showed the macro inserting code to magically produce a binding inside the reverse function. Are you sure? It looked to me like it was adding code *around* the reverse function, not inside it. I posted a Python function that achieves the same thing by calling the existing reverse function. You are thinking about the results iteration, where you broke encapsulation. I just reminded you of the magical signed-value binding in a reply to another post of yours. btw, when looking back at the rest of the code I was reminded I had done something even wilder (well, maybe as wild) in the transforming code itself. I say wilder in the sense of it being way cool, having a flying-without-a-net feeling, yet making coding of dozens and dozens of these transformations simpler, terser, and less buggy. Someone had me laughing when they said the actual application of a macro was nice and simple, but the macro itself was scary. It reminded me of a cranky but sweet old guy on a project who was outraged upon learning I was using a finite state machine to handle a shaky exchange between two processes. He maintained that I was foisting a crazy scheme on the bank which no one would be able to maintain. He actually forced me to defend it in a group code review, the first they ever had, so don't think it was a normal process for them, this was war. After my demonstration on how the FSM would react to either or both processes going south at any point in the exchange, the crank pronounced his satisfaction with the approach and said, OK, that is simple. The infinite-state thing is complicated, but the way it works is simple. That really made the whole thing worthwhile. :) I'm still trying, but some of the code you posted is rather impenetrable without knowing a lot more about the details of your system. I'm doing my best to show some Python demonstrating the gist of what could be done. Great. That's the spirit. But how do we move forward if you just express global confusion? See if you can understand the magical binding of the parameter signed-value. The reverse function will be called by the engine to reverse a mathematical transformation, in this case simply taking the absolute value. The generic engine has no way of knowing out of all the targets, results, and operands (targets from a before expression relocated in their incarnation in the expression operated on) recorded by a transformation to pass in that position. When I code that reverse function, I just want to work on the signed-value, as identified in hard-code fashion by the transformation. ie, All I need do is coordiate the TF and its reverser. If the reverser needs something else, say the coefficient (this would be a add-like-terms TF), I just go to the add-like-terms and have it tag the coefficients with the symbol 'coefficient, then I can code: (reverse (coefficient literal-part)...) Ah. Time to refactor. I will have multiple coefficients, and when multiples are expected I want all the input math forms searched for those tagged coefficient. Any ideas out there? :) It is so tempting to add an s and have the macroexpansion look for a trailing s in the symbol-name, but then I am bound to have some singular and in s. Ah, grep to the rescue: (reverse (literal-part coefficient+)...) Sweet. By using + I can even have the macroexpansion insert an assertion that there is at least one. Of course there should be at least two or this TF would not fire. And so it goes... :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[EMAIL PROTECTED] wrote:
Ken Tilton wrote:
Andrew Reilly wrote:
That all looks like data.
No, not reverse, the part you did not understand. I do not mean what the
code was doing, I meant that it was code.
Code is data is code
I was hoping no one would make that mistake. :) macros are all about
code is data, but code is not data in Python* so the two words code and
data serve to differentiate them for Pythonistas.
* Taking questions after a keynote to ILC200? where he reiterated that
Python was the same as Lisp for all intents and purposes:
Norvig: Yes, John?
McCarthy: Is code also data in Python?
Norvig: No.
End of exchange. :)
- even in Python:
This could be tougher than I thought.
skills_table = [
{
title: Absolute Value,
annotations: [Bleah bleah, ho hum, etc...],
hints: [and so on, etc...],
reverse : (lambda x: whatever(x))
That does not demonstrate that code is data, that demonstrates that a
lambda is a first-class object (and, yes, Python's lambda is lame).
You will know you have code as data when you can write Python code that
takes apart whatever(x) and produces oh-now-I-get-it(y). As part of
the language, such that Python applies your transforming code for you
whenever it sees whatever. (Hell, even C has a preprocessor.)
},
{
title: Square Root,
annotations: [Bleah bleah, ho hum, etc...],
hints: [and so on, etc...],
reverse : (lambda x: someother(x))
},
# etc...
]
Of course those lambdas are crippled in Python (and not really
necessary in this bogus example)... But that's without trying to be
clever:
class AbsoluteValue:
title=Absolute Value
annotations=[Some list, goes here]
@classmethod
def reverse(cls, *args):
# I didn't understand what your code was doing
yeah, and god forbid you should ask. :) this is the crux of the matter!
Actually, it is kinda cool that you and Greg are semi-identifying the
crux by saying this is the only bit I do not get, I'll skip this, move
on, nothing to see here.
pass
defskill(AbsoluteValue)
That would be a reasonable place for a pie decorator on a class, but
I guess that's not allowed.
Hmmm. Actually, that is the whole point, all of Python is allowed.
decorators were used in PyCells, but I never got much of an idea what
they did. Is there a moral equivalent of a macroexpansion for decorators
so you can show the before and after?
I doubt this second example would be
considered Pythonic in any case...
exactly what we are looking for in this cultural exchange: how would
Python handle what I am doing with macros in the reverse functions? Make
it as slick and programmer-friendly (cuz I may get to a hundred of these
before I am done with Algebra I) as possible. When all the Pythonistas
proclaim it optimal, then we compare and contrast.
This, btw, is the Tilton Test for language comparison: Not measurements
of programmer effort, rather examination of perfect equivalent code.
PyCells vs Cells would be an amazing case, because that is some hairy
functionality.
Not the code. In reverse.
Why not?
Is, too! (ie, I am kinda looking for a specific question that conveys
understanding of the use case.)
Python has plenty of other flaws that I can't happily work around, and
I do think Lisp is more flexible. However, I think your example is
readable enough with a data driven algorithm in most any popular
language. All of the data is visible to the reverse(...) method.
Maybe I missed something in your example, but I think you aren't trying
hard enough. :-)
Precisely. I am not trying at all. I am coding between visits to Usenet.
This use case just popped up and was pretty simple (at first, before I
got to the reverse function) so I dropped it off. This is a wild macro,
not farm-bred, deliberately crafted to embarrass macro. A real live
natural comes up all the time working wouldn't want to code without it
macro. I could have searched my code base to find more brutal cases, but
this is short and sweet and unforced and uncontrived and wheres my
thesaurus?
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it. -- Elwood P. Dowd
I'll say I'm losing my grip, and it feels terrific.
-- Smiling husband to scowling wife, New Yorker cartoon
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
greg wrote: Ken Tilton wrote: McCarthy: Is code also data in Python? Norvig: No. I don't think that was the right answer. Norvig is a smart guy. He was talking to John McCarthy. He gave the right answer. :) He should have said Yes, and then shown McCarthy eval() and exec. No, in those cases the Python interpreter is still dealing with the code, not the user's application code. As a meta-developer (to coin a word) I want to be able to write code that takes apart other code I write to do useful things with it /without writing a parser for my chosen language/. I just found a bug in ACL that might be instructive. The defskill macro I have been writing might be coded like this: (defskill abs-value (category Algebra I Real Numbers) ) (I am kinda mirroring defclass here, which looks like: (defclass name superclasses* (slot-defs*) ...and then optional sub-specs each keyed by the first symbol.. (:documentation chya) (:metaclass...) (:default-initargs))) Come to think of it, I might have made /my/ options :keywords just to make the resemblance stronger (and yes I am digressing into the bit about how Lispniks by convention stay recognizable with new syntax). Anyway, I decided to do a little auto QA and add an assertion to make sure I did not inadvertently leave out the category option (long story, I am not usually so anal), so defskill starts like this: (defmacro defskill (id body skill-info) (assert (find 'category skill-info :key 'car))... That is just normal list code. The macro signature destructures the code I write inside the defskill invocation into an id and a list of following code (body skill-info says bind the rest of the code to the local variable skill-info as a list). the (find ... :key 'car) walks down the list taking the car (first) of each list and comparing against that which is being sought. Simple ol' Lisp. I then expand the (somewhat) validated data/code: (loop with sub-id = id for (q . q-def) in skill-info collecting (ecase q (category return desired Lisp code) ...etc...) q for quality or attribrute. Not o for option. :) Again, using standard loop destructuring on the option code/data. Y'all need to get over it: we really are writing code that eats code/data to produce code. Unaided by any parser other than the same destructuring mechanisms we use on data. ken ps. I forgot the bug. I coded in the end: (defskill |Absolute Value| ...etc..) Where |absolute value| should be treated as a single symbol, and is by the ACL compiler. An interactive macroexpand, however, misses that that is one symbol and defskill (if you followed the Lisp) dies trying to take the car of the atom VALUE (a symbol). k -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: Ken Tilton [EMAIL PROTECTED] writes: Man that whole thing is messy. I do not see much difference, except that the character count is 25% less in the macro version: The macro calls aren't so bad, but the macro definition is pretty horrendous. (a) /Precisely/ :) (b) Omigod, that macro is trivial (except I forgot how to reach out two levels of backquote to get a parameter and had to kludge it!). You just aren't used to thinking at a level where one is writing code to write code. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: Ken Tilton [EMAIL PROTECTED] writes: btw, you called the defskill messy (repeated below) messy. The only text not specific to absolute value is D-E-F-S-K-I-L-L. No, the messiness was not in the macro instantation (defskill blah...), but in the defmacro that tells the compiler how to expand it. Again, that is precisely the point of macrology (in cases like this). When a pattern will repeat a sufficient number of times, and a function cannot handle the job, we do a little extra work (write some meta-code) to make dozens (or hundreds) of applications as minimalist as possible. That makes them concise, readable, and maintainable. Python function defs are lightweight enough that I don't experience a big pain from using an extra one for a thing like that. Check out the latest, plz. The example has grown now beyond what a function can do, I think. meanwhile, I have not seen how Python lets you avoid revisiting dozens of instances when changes to a mechanism are required. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Andrew Reilly wrote: On Thu, 14 Dec 2006 03:01:46 -0500, Ken Tilton wrote: You just aren't used to thinking at a level where one is writing code to write code. Firstly, I'm looking into lisp because my current python project is too full of boilerplate :-) and too slow. Coming from a C and assembler background, I'm *used* to meta-programming, and do it all the time. I even use python, Matlab and bash to write C, sometimes :-) However, in this particular instance, I'm inclined to wonder why meta-programming is the right answer, rather than just doing all of the interpolation and what-not at run-time, based on a big table of your algebra rules? I am afraid I do not see what alternative you are suggesting. I especially do not see how interpolation is in play. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Ken Tilton wrote: Andrew Reilly wrote: On Thu, 14 Dec 2006 03:01:46 -0500, Ken Tilton wrote: You just aren't used to thinking at a level where one is writing code to write code. Firstly, I'm looking into lisp because my current python project is too full of boilerplate :-) and too slow. Coming from a C and assembler background, I'm *used* to meta-programming, and do it all the time. I even use python, Matlab and bash to write C, sometimes :-) However, in this particular instance, I'm inclined to wonder why meta-programming is the right answer, rather than just doing all of the interpolation and what-not at run-time, based on a big table of your algebra rules? I am afraid I do not see what alternative you are suggesting. I especially do not see how interpolation is in play. [Guessing pending your clarification] Interpolation does happen at runtime. This not about the actually quite rare use of macrology to move certain calculations to compile time, this is about getting dozens of transformation-specifc rules written to fit into a larger mechanism (by having the right arguments and returning the right kinds of results, with a minimum of boilerplate and a maximum of resiliency in the face of refactoring. The reason I post macro expansions along with examples of the macro being applied is so that one can see what code would have to be written if I did not have the defskill macro to write them for me. I sugest one start there, by comparing before and after. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: Ken Tilton [EMAIL PROTECTED] writes: Again, that is precisely the point of macrology (in cases like this). When a pattern will repeat a sufficient number of times, and a function cannot handle the job, But this is not a case where a function can't handle the job. Is, too. Check out the latest, plz. The example has grown now beyond what a function can do, I think. meanwhile, I have not seen how Python lets you avoid revisiting dozens of instances when changes to a mechanism are required. I'm missing what the difficulty is. Your terse response does not provide enough for me to. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Andrew Reilly wrote: Each skill seems to have a title, a list of annotations, and a list of hints (and a reverse, which I don't understand). There's the problem. That all looks like data. No, not reverse, the part you did not understand. I do not mean what the code was doing, I meant that it was code. Couldn't you do that with a table containing those fields, and key it off the defskill argument (or even the title?) at startup? Not the code. In reverse. Then you don't have to worry about re-factoring the code: there's only going to be one piece of code, driven by a table. What if it turns into an SQL lookup during refactoring? I only mentioned interpolation because it seemed likely that you might want to be mutating these strings to be more specific to what your student was actually doing. Interpolation does not mean what you think it means. :) That's OK, I figgered it out. Yes, that is what the program does, it substitutes terms from the student's problem to produce a hint or annotation. The function is called expand. Because the text is like a macro. :) I didn't expect that 42 was necessarily the right answer... No, but it so happens any #STR...# token is a literal bit of math encoded as an ascii string. That gets translated to proper math notation (by which I mean, what you would see in tex output). During template conversion. So this hint is just saying to the kid, Dude, |-42|=42, |42|=42, get over it. To back out a bit, here, and get back to the meat of the matter: if one is using Python, then it's because one doesn't much care about performance, I'll try again: this has nothing to do with performance. and it's reasonable to do expansions, pattern matching and domain specific language creation/use at run-time. After all, that's how the language itself works, mostly. The last example showed the macro inserting code to magically produce a binding inside the reverse function. It would be easier to compare and contrast with the Python equivalent if someone had posted such, but your troops have fallen back to Fort So What? and pulled up the drawbridge. Peace. Out. Ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Robert Uhl wrote: Ken Tilton [EMAIL PROTECTED] writes: meanwhile, I have not seen how Python lets you avoid revisiting dozens of instances when changes to a mechanism are required. I think his solution would have been to use: def foo(**args): everywhere, and call it like this foo(bar=baz) Of course that makes calls pretty verbose, but it would prevent having to visit every function/method every time the signature changes. As long they'd all been set up initially to use keyword args like that. And of course one would lose some of the compile-time benefits of compiler signature checking. It's not optimal, but I think it'd get the job done. Cue Steve and his Turing Equivalence rant. hint And as the mechanism has elaborated, neato things like signature flexibility were not enough to keep Python in the game. Or at least people stop offering Python equivalents, at which point we could have contrasted and compared. Python /does/ have a lot of reflection and meta-capability, as I know from an abortive attempt to port Cells there. So perhaps something was possible. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Robert Uhl wrote: Christophe [EMAIL PROTECTED] writes: Robert Uhl a écrit : The argument from popularity is invalid. French units have overtaken standard units, Never heard of that French unit thing. Unless you talk about that archaic unit system that was in use before the metric system was created. I use 'French units' instead of the term 'metric system' because the latter means 'measurement system,' and of course could validly be applied to _any_ system. Now we know how one contractor ended up using English units when the other was using French units and an entire Mars mission was lost: they were both using the metric system. [cue NASA aopologist Ron (or his sidekick Al) for some scenery-chewing outrage over my condescension and arrogance.] ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Ken Tilton wrote: Paul Rubin wrote: Ken Tilton [EMAIL PROTECTED] writes: Have you read On Lisp by Paul Graham? It is on-line. Just the preface will do, I think, maybe also Chapter One where he raves on macros. Do you think he is mistaken? Confused? Lying? Mutant? I remember Paul Graham's piece about macros that made him sound like someone who went nuts with them, as is certainly possible to do. But you could have just flipped thru the rest of the pages to see if he /had/ gone nuts with them! In my experience, good coders write for clarity and that includes in their use of Lisp macros. All in all Lisp's macro system is something like the C preprocessor. Yes, you can obfuscate things horribly with it, but you can also use it to make things clearer, and that's what good programmers do. One has to be from the US and of a certain age to remember this, but this old line from a commercial for high-octane gasoline says it for me: power to be used, not abused. Here is a bit of concrete I just tossed off: (defmacro defskill (id body skill-info) `(progn ,@(loop with sub-id = id for (q . q-def) in skill-info collecting (ecase q ((title annotations hints) `(defmethod ,(intern (conc$ 'skill- q)) ((tf-id (eql ',sub-id))) ,@q-def)) It lets me code this: (defskill absolute-value (title Absolute Value) (annotations Take the absolute value of #op#. The vertical bars around #op# mean 'the absolute value of' #op#. Absolute value of #strn# is the 'distance' of #strn# from zero. Absolute value is always zero or positive: #str|n|=n#, and #str|-n|=n#.) (hints What do those vertical bars around #op# mean? Have you learned about 'absolute value'? Absolute value can be thought of as the 'distance' of a value from zero on the number line, and distance is always positive. The rule is:#str|-n|=|n|##str=n#. Can you apply that to #op#? Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#. To get the absolute value of a number such as #op#, we simply drop any minus sign.)) ...and get this: (PROGN (DEFMETHOD SKILL-TITLE ((TF-ID (EQL 'ABSOLUTE-VALUE))) Absolute Value) (DEFMETHOD SKILL-ANNOTATIONS ((TF-ID (EQL 'ABSOLUTE-VALUE))) Take the absolute value of #op#. The vertical bars around #op# mean 'the absolute value of' #op#. Absolute value of #strn# is the 'distance' of #strn# from zero. Absolute value is always zero or positive: #strn=n#, and #str-n=n#.) (DEFMETHOD SKILL-HINTS ((TF-ID (EQL 'ABSOLUTE-VALUE))) What do those vertical bars around #op# mean? Have you learned about 'absolute value'? Absolute value can be thought of as the 'distance' of a value from zero on the number line, and distance is always positive. The rule is:#str-n=n##str=n#. Can you apply that to #op#? Some examples: #str+42=42#, #str-42=42#, and #str0=0#. To get the absolute value of a number such as #op#, we simply drop any minus sign.)) The above is how my upcoming death-defying interactive Algebra tutor-in-a-drum (You'll laugh! You'll cry!) will know how to coax some befuddled teen through |-42| - 42 if they get stuck. And a hundred other subskills (so there will be a hundred of these definitions). If I hire someone they will look at defskill and not fall to the ground frothing at the mouth. They likely will not even macroexpand it because it is self-explanatory. If they wonder if there are other options they can alt-. to the source. The language has been extended, but I followed a pattern familiar to Lispniks. Zero confusion results. If I decide not to use generic method dispatch to look up the hints I just have to change the macro and then write a DEFUN (no dispatch on type) to, say, look up the symbol in a hash table. hth,ken ps. I won't mention the other benefit, which is that I want educators to edit these if they have a better idea on how to tutor absolute value. I am not mentioning it because I am as impatient with superfluous syntax as a non-programmer would be. k pps. How would Python do this? Is it possible to avoid committing to an implementation mechanism? Compare and contrast. k -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
greg wrote:
Ken Tilton wrote:
pps. How would Python do this?
Here's one way it could look:
defskill(absolute-value,
title = Absolute Value,
annotations = [
Take the absolute value of #op#.,
The vertical bars around #op# mean 'the absolute value of' #op#.,
Absolute value of #strn# is the 'distance' of #strn# from zero.,
Absolute value is always zero or positive: #str|n|=n#, and
#str|-n|=n#.
],
hints = [
What do those vertical bars around #op# mean?,
Have you learned about 'absolute value'?,
Absolute value can be thought of as the 'distance' of a value from
zero on the number line, and distance is always positive.,
The rule is:#str|-n|=|n|##str=n#. Can you apply that to #op#?,
Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#.,
To get the absolute value of a number such as #op#, we simply drop
any minus sign.
]
)
Is it possible to avoid committing to an
implementation mechanism?
The defskill function could do just about anything with this.
Here's one possibility:
skills = {}
class Skill:
pass # fill in whatever methods you need here
def defskill(name, title, annotations, hints):
skill = Skill()
skill.title = title
skill.annotations = annotations
skill.hints = hints
skills[name] = skill
This gives you a dictionary of Skill instances indexed by name,
each one having a title and lists of annotation and hint strings.
The rest of the system can process this however required.
Ok, not too bad, not much syntax in there. But now I have a tougher
requirement for you, which I noticed only after posting. (I tried
running the damn thing and it whined about not knowing how to reverse
absolute-value (to clone one problem into a similar problem).) A
reversal must be able to yield any given a result, and sometimes must
use given operands already settled on by the larger reversing algorithm.
In the simpler case, to reverse absolute-value with result 42 we produce
either |42| or |-42|. In the more complicated case, the multiply-literal
reverser may discover 6 is an operand and 42 is the result (meaning it
does no randomization, it just supplies the (* 6 7) reversal. Why am I
telling you all this? I don't know. The point is, we need code (not just
data) in defskill (apologies for nasty formatting):
(defmacro defskill (id body skill-info)
`(progn
,@(loop with sub-id = id
for (q . q-def) in skill-info
collecting (ecase q
((title annotations hints)
`(defmethod ,(intern (conc$ 'skill- q))
((tf-id (eql ',sub-id)))
(list ,@q-def)))
(reverse
`(defmethod tf-reverse ((id (eql ',sub-id))
resx opnds)
(declare (ignorable resx opnds))
,@q-def))
--- (Abbreviated) Example --
(defskill absolute-value
(title Absolute Value)
(annotations
Absolute value is always zero or positive: #str|n|=n#, and
#str|-n|=n#.)
(hints
What do those vertical bars around #op# mean?)
(reverse
(ensure-cloning resx
(make-instance 'mx-number
:value (loop with op1 = (car opnds)
with log = (max 1 (ceiling (log (abs (value op1)) 10)))
for n = (* (signum (value op1))
(+ 2 (random (expt 10 log
when (/= n (value op1))
return n)
:representation (representation resx)
-- Producing -
(progn (defmethod skill-title ((tf-id (eql 'absolute-value))) (list
absolute value))
(defmethod skill-annotations ((tf-id (eql 'absolute-value)))
(list absolute value is always zero or positive: #strn=n#,
and #str-n=n#.))
(defmethod skill-hints ((tf-id (eql 'absolute-value)))
(list what do those vertical bars around #op# mean?))
(defmethod tf-reverse ((id (eql 'absolute-value)) resx opnds)
(declare (ignorable resx opnds))
(ensure-cloning resx
(make-instance 'mx-number :value
(loop with op1 = (car opnds) with log = (max 1 (ceiling
(log (abs (value op1)) 10))) for n =
(* (signum (value op1)) (+ 2 (random (expt 10
log when (/= n (value op1)) return n)
:representation (representation resx)
How close can Python get when code is involved? The reverse function
signature is fixed, so can lambda help?
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it. -- Elwood P. Dowd
I'll say I'm losing my grip, and it feels terrific.
-- Smiling
Re: merits of Lisp vs Python
Paul Rubin wrote: Ken Tilton [EMAIL PROTECTED] writes: don't know. The point is, we need code (not just data) in defskill (apologies for nasty formatting): Man that whole thing is messy. I can't for the life of me understand why it's so important to use a macro for that. Even in Lisp, I'd probably set up the reverse thingie as an auxiliary function. And when you got to skill 42 and you discovered you needed a new optional argument to the reversal method you would throw up your hands and register for bartending school rather than go edit the other 41. defskill is writing my code for me. When things change, I have it write different code. Implementation is hidden, even from the programmer. I am one step removed from the code when writing a macro. This is the meta in metaprogramming. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Ken Tilton wrote:
Paul Rubin wrote:
Ken Tilton [EMAIL PROTECTED] writes:
don't know. The point is, we need code (not just data) in defskill
(apologies for nasty formatting):
Man that whole thing is messy.
I do not see much difference, except that the character count is 25%
less in the macro version:
(defskill absolute-value
(title Absolute Value)
(annotations
Absolute value of #strn# is the 'distance' of #strn# from zero.
Absolute value is always zero or positive: #str|n|=n#, and
#str|-n|=n#.)
(hints
Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#.
To get the absolute value of a number such as #signed-value#, we
simply drop any minus sign.)
(reverse
(ensure-cloning resx
(make-instance 'mx-number
:value (loop with op1 = (car opnds)
with log = (max 1 (ceiling (log (abs (value op1)) 10)))
for n = (* (signum (value op1))
(+ 2 (random (expt 10 log
when (/= n (value op1))
return n)
:representation (representation resx)
(defmethod skill-title ((tf-id (eql 'absolute-value)))
(list absolute value))
(defmethod skill-annotations ((tf-id (eql 'absolute-value)))
(list absolute value of #strn# is the 'distance' of #strn# from zero.
absolute value is always zero or positive: #strn=n#, and #str-n=n#.))
(defmethod skill-hints ((tf-id (eql 'absolute-value)))
(list some examples: #str+42=42#, #str-42=42#, and #str0=0#.
to get the absolute value of a number such as #signed-value#, we
simply drop any minus sign.))
(defmethod tf-reverse ((id (eql 'absolute-value)) resx opnds)
(declare (ignorable resx opnds))
(ensure-cloning resx
(make-instance 'mx-number :value
(loop with op1 = (car opnds) with log = (max 1 (ceiling (log (abs
(value op1)) 10))) for n =
(* (signum (value op1)) (+ 2 (random (expt 10 log when
(/= n (value op1)) return n)
:representation (representation resx)
Let's lose the strings and count again, since they are a fixed cost. OK,
now the macro version is 30% shorter.
I can't for the life of me understand
why it's so important to use a macro for that.
Pythonistas, when arguing about macros, always seem to forget that one
of the primary design imperatives of Python is cleaner code. Indentation
is use to avoid single characters { and }. But when macros come up you
all suddenly become the Mavis Beacon of programmers.
And, again, perhaps the bigger thing going on here is that the 30% is
boilerplate code representing implementation, which can change.
I don't know, perhaps the best argument against macros is that no
Pythonista wants them. That is actually a damn good reason.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it. -- Elwood P. Dowd
I'll say I'm losing my grip, and it feels terrific.
-- Smiling husband to scowling wife, New Yorker cartoon
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: Ken Tilton [EMAIL PROTECTED] writes: Man that whole thing is messy. I can't for the life of me understand why it's so important to use a macro for that. Even in Lisp, I'd probably set up the reverse thingie as an auxiliary function. And when you got to skill 42 and you discovered you needed a new optional argument to the reversal method you would throw up your hands and register for bartending school rather than go edit the other 41. I don't see the problem. Python uses keyword args sort of like Lisp's, and the called function (if it asks) receives a dictionary containing any keyword args not bound explicitly in the arg list. So you can invent new args whenever you want. I am not making this up. I just decided to change the signature to the reversal function(s). I had been clever, trying to pass in just what I deemed necessary from a transformation (TF) data structure that needed reversing, now I recall -- because I needed something else from the TF -- I should never try to be smart, just pass in the whole frickin TF (duh). So this: (defmethod tf-reverse (id (eql ',sub-id)) resx (drv-opnds tf drv)) ,@reverser) becomes this: (defmethod tf-reverse ((id (eql ',sub-id)) tf drv aux (opnds (drv-opnds tf drv))) (loop for resx in (results drv) ,@reverser)) I pass in drv (a derivation, a part of a transformation) because (I forgot) reversal code has to reverse each derivation of a TF separately. In the new macroexpansion I preserve the bindings RESX and OPNDS expected by the 41 (not really, but it could be) existing uses of the defskill macro, and then gasp move an iteration across possible multiple results (RESXs) of a TF into the generate tf-reverse method (and the poor body of code has no idea I did that). At this point if I had to redo these manually we can forget bartending school, I'd be going straight to the Betty Ford clinic . btw, you called the defskill messy (repeated below) messy. The only text not specific to absolute value is D-E-F-S-K-I-L-L. Expanding that into tidy separate methods adds 25% of dead weight boilerplate. In 4-5 separate toplevel definitions instead of one. How is that less messy? ken (defskill absolute-value (title Absolute Value) (annotations Take the absolute value of #signed-value#. The vertical bars around #signed-value# mean 'the absolute value of' #signed-value#. Absolute value of #strn# is the 'distance' of #strn# from zero. Absolute value is always zero or positive: #str|n|=n#, and #str|-n|=n#.) (hints What do those vertical bars around #signed-value# mean? Have you learned about 'absolute value'? Absolute value can be thought of as the 'distance' of a value from zero on the number line, and distance is always positive. The rule is:#str|-n|=|n|##str=n#. Can you apply that to #signed-value#? Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#. To get the absolute value of a number such as #signed-value#, we simply drop any minus sign.) (reverse (ensure-cloning resx (make-instance 'mx-number :value (loop with op1 = (car opnds) with log = (max 1 (ceiling (log (abs (value op1)) 10))) for n = (* (signum (value op1)) (+ 2 (random (expt 10 log when (/= n (value op1)) return n) :representation (representation resx) -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Ken Tilton wrote: Ken Tilton wrote: Paul Rubin wrote: Ken Tilton [EMAIL PROTECTED] writes: don't know. The point is, we need code (not just data) in defskill (apologies for nasty formatting): Man that whole thing is messy. I do not see much difference, except that the character count is 25% less in the macro version: (defskill absolute-value (title Absolute Value) (annotations Absolute value of #strn# is the 'distance' of #strn# from zero. Absolute value is always zero or positive: #str|n|=n#, and #str|-n|=n#.) (hints Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#. To get the absolute value of a number such as #signed-value#, we simply drop any minus sign.) (reverse (ensure-cloning resx (make-instance 'mx-number :value (loop with op1 = (car opnds) with log = (max 1 (ceiling (log (abs (value op1)) 10))) for n = (* (signum (value op1)) (+ 2 (random (expt 10 log when (/= n (value op1)) return n) :representation (representation resx) (defmethod skill-title ((tf-id (eql 'absolute-value))) (list absolute value)) (defmethod skill-annotations ((tf-id (eql 'absolute-value))) (list absolute value of #strn# is the 'distance' of #strn# from zero. absolute value is always zero or positive: #strn=n#, and #str-n=n#.)) (defmethod skill-hints ((tf-id (eql 'absolute-value))) (list some examples: #str+42=42#, #str-42=42#, and #str0=0#. to get the absolute value of a number such as #signed-value#, we simply drop any minus sign.)) (defmethod tf-reverse ((id (eql 'absolute-value)) resx opnds) (declare (ignorable resx opnds)) (ensure-cloning resx (make-instance 'mx-number :value (loop with op1 = (car opnds) with log = (max 1 (ceiling (log (abs (value op1)) 10))) for n = (* (signum (value op1)) (+ 2 (random (expt 10 log when (/= n (value op1)) return n) :representation (representation resx) Even better. That (car opnds) up there is an unpleasant hard-coding that must align with how operands get recorded by the transformation code that built the TF log entry that is being reversed. Ewww. What the first opnds is supposed to be is the signed value of which the absolute vale is being taken. Wouldn't it be nice to just say signed-value?: We can just look at the reverse option now: (defskill absolute-value (reverse (signed-value) (ensure-cloning resx (make-instance 'mx-number :value (loop with svn = (value signed-value) with log = (max 1 (ceiling (log (abs svn) 10))) for n = (* (signum svn)(+ 2 (random (expt 10 log when (/= n svn) return n) :representation (representation resx) A major point here is that the above (trust me) is the exact syntax of FLET and LABELS in Lisp. The big hobgoblin (and precise objection offered by GvR) is that macro use yields unrecognizably (in this case) Lisp code. But we love lisp and its patterns, and one ethic for macro writers is to follow those patterns in extending the language. Maybe that poor horse can be allowed to rest in peace, or must we flog it some more for youse people? Now operands and results get tagged at TF time with symbols. How on earth does a local variable of the same name get bound to the operand logged at TF time? Easy, look it up. But where is the code? Not outside the function; the caller of the reversal function does not know which logged operand to pass in which function parameter position. So the lookup code has to be in the reverse function source, like this: (defmethod tf-reverse ((id (eql 'absolute-value)) tf drv aux (opnds (drv-opnds tf drv))) (declare (ignorable opnds)) (let ((signed-value (tf-drv-lookup tf drv 'signed-value))) = (loop for resx in (results drv) do (ensure-cloning resx (make-instance 'mx-number :value (loop with svn = (value signed-value) with log = (max 1 (ceiling (log (abs svn) 10))) for n = (* (signum svn) (+ 2 (random (expt 10 log when (/= n svn) return n) :representation (representation resx)) WordPerfect says thats 405 characters, 64 words vs 241/38 for the actual source. Now in this case I happen to be just starting on this mechanism, so i do not really have 42 I do not have to change, but I am about to start churning these things out and I expect refinements to continue. No problem. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing
Re: merits of Lisp vs Python
Pascal Costanza wrote: Paul Rubin wrote: 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. That was my stance for about seven years of intense Lisp. Then the author of Practical Common Lisp did a nice job of breaking the whole mess up into sensible chunks and I picked it up. If one programs Lisp, one should learn Loop -- it is definitely worth the bother. I def regret not learning it sooner. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: Pascal Costanza [EMAIL PROTECTED] writes: You can start with loop by using only the simple and straightforward constructs, and slowly move towards the more complicated cases when necessary. The nice thing about loop is that with some practice, you can write code that more or less reads like English. Yeah, but I'd also get English-like imprecision. Anyway, If I wanted to write code that reads like English, I'd write in Cobol. That was my stance until g There /is/ a second Lispy syntax for LOOP, btw. But the goofier syntax is also where lies part of the win, so learn that. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: Ken Tilton [EMAIL PROTECTED] writes: The loop language is so complicated and confusing that I never bothered trying to learn it. That was my stance for about seven years of intense Lisp. Then the author of Practical Common Lisp did a nice job of breaking the whole mess up into sensible chunks and I picked it up. If one programs Lisp, one should learn Loop -- it is definitely worth the bother. I def regret not learning it sooner. I don't really code in Lisp any more, I never felt a need for loop when I was coding in Lisp, and I'm trying to move towards a style of programming without loops (i.e. I'm playing with Haskell, which doesn't have loops), giving me even less need for a hairy loop macro. Oh, my. time to trot out my hey, X is cool, let's use it for everything! rant. Freud may not have said, Sometimes a cigar is just a cigar., but sometimes (er, always) iteration is best handled with an iteration construct. Any craftsman can tell you, use the right tool for the job. the nice thing about Lisp's many paradigms is that the developer does not become a slave to any paradigm. I think all-rules-all-the-time Prolog is the poster boy for paradigm slavery. (I did try for a famous two months to use Prolog as a general-purpose programming language.) Just the sentence I'm trying to program without loops simply screams category error, if you think about it. Mind you, I had great fun using a Logo which did not have iteration. Now I have fun with CL. They call it a big ball of mud, but I do not thnk there is a tool in that chest I have not used, just because that tool fit the problem best. It only looks like a ball of mud if one does not right much code, and that describes most Lispniks, so no wonder we ended up with Scheme. Oops, wrong flamewar. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: Ken Tilton [EMAIL PROTECTED] writes: Oh, my. time to trot out my hey, X is cool, let's use it for everything! rant. Somehow it's something other than a rant if X is Lisp? Ah, your discriminator misfired. Keep your eye on the bouncing rant: I was not espousing any language, I was espousing matching the tool to the task. That segued into my Lisp ball of mud rant, but, hell, even C offers iteration along with recursion. That observation turns the rant back on all-x-all-the-time languages, including I would note Steele's constraint programming language, which at first used a constraint to do variable assignment. Speaking of Cells... :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Markus Triska wrote: Ken Tilton [EMAIL PROTECTED] writes: I think all-rules-all-the-time Prolog is the poster boy for paradigm slavery. (I did try for a famous two months to use Prolog as a general-purpose programming language.) Don't expect to learn Prolog properly in so little time. Lawdy, no, but I had all those Art of Prolog and Craft of Prolog and a couple other books and I was staring at pages of intense code just trying to do basic stuff. I had not learned prolog, but I could see the masters writing hairy code to basic stuff so I concluded...run away! run away! :) I think the other thing that got me was cuts, which I translated as did we say unification all the time? sorry... :) To your previous question whether the ~180 lines of Lisp code in some online book constitute an industrial strength Prolog: only if the following ~180 lines of Prolog code implement an industrial strength Lisp. snip lisp-in-Prolog Way cool. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Robert Uhl wrote: Stephen Eilert [EMAIL PROTECTED] writes: So, let's suppose I now want to learn LISP (I did try, on several occasions). What I would like to do would be to replace Python and code GUI applications. Yes, those boring business-like applications that have to access databases and consume those new-fangled web-services and whatnot. Heck, maybe even code games using DirectX. GUIs are a weak point, or were last I looked. LW comes with CAPI, portable across the big 3. ACL has Common Graphics on win32, and I think they have Gtk bindings elsewhere (just guessing, really). Everyone has Ltk, Cells-Gtk, and Celtk. (Two Tks, one Gtk if that is not clear). ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Harry George wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Kay Schluehr wrote: is rapidly replacing Perl, and Ruby is simultaneously and even more rapidly replacing Python. Really? Given its small base, the percentage increases in Ruby use (for any reason) can look quite impressive. I've see data suggesting Ruby is replacing Perl and maybe Java. But I've yet to see data which shows people dropping Python and moving to Ruby. Where do I find that data? You missed it? Google fight: http://www.googlefight.com/index.php?lang=en_GBword1=Pythonword2=Ruby Python wins, 74 to 69.3. And there is no Monty Ruby to help. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
André Thieme wrote: mystilleef schrieb: Ken Tilton wrote: Lisp has all the cool qualities you like in your pets, plus native compilation in most implementations, plus maturity and a standard, plus a better OO, plus macros, plus a dozen more small wins. Including automatic indentation. :) Better OO? You mean the one that doesn't support basic encapsulation and is retardedly cumbersome to use? There's a reason I said, I'd never use Lisp for OO not even when I'm high. Gimme Python, Eiffel or Smalltalk anyday, not the retarded add-on package bolted on CL. What do you mean with encapsulation in this context? Mr. mystilleef's remarks struck me as needlessly contentious and perhaps unavoidably ignorant, hence unworthy of response. YMMV. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
greg wrote: Bill Atkins wrote: 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. For selecting a single form, that's true. For more than one form (such as selecting some, but not all, of the statements in a loop body) it's not much different. But my point was that I don't find manually reindenting the lines to be a chore. He made it sound like you have to laboriously go through and adjust the lines one by one, but it's not like that at all. You shift them all at once in a block. It is a gray area. Manually maintaining indentation does not have to be a laborious chore to slow down development. I believe it was in the mid 1980s when I turned to the developer sitting next to me and said, I wonder how much time I spend re-tabbing my code? That was probably Vax Basic or COBOL. I /think/ the editor had a block-tab capability, and I think I used same in some C IDES, but to be honest retabbling a few lines was not such a laborious chore g that I would first do the select operation to be able to use it. Also, Python does not support a functional style of programming so the line is the only meaningful textual entity. In this sense the primitiveness of Python makes editing easier. Finally, Python is just a (fine) scripting language. Which means one does not tackle hard problems with it, the kind one figures out as one goes. That means less refactoring, and less refactoring means less slicing and dicing of the code. Seeing as you asked, how much Python code have you or Ken edited? See above. Not Python, but out the wazoo in other languages. Remember, we are not Lisp-only aliens, we program all the languages you program, plus one. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
greg wrote: [EMAIL PROTECTED] wrote: So if you guys would just fix your language by adding homogeneous syntax and all that it brings with it (macros, compilers, etc) we'd be happy to use your version of Lisp, and all its great libraries, instead of ours! :-) But if we did that, it wouldn't be Python any more, it'd be Lisp. And someone would then have to invent Python. Let Python be Python, let Lisp be Lisp. It's all good. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: On Fri, 08 Dec 2006 08:50:41 -0800, George Sakkis wrote: André Thieme wrote: On the other hand can I see difficulties in adding macros to Python, or inventing a new object system, or adding new keywords without changing the sources of Python itself. Actually, an even bigger difficulty is the rejection of programmable syntax by Guido, both for the near and distant future: Why is that a difficulty? Like Guido, I think that's an ADVANTAGE. Programmable syntax is not in Python's future -- or at least it's not for Python 3000. The problem IMO is that everybody will abuse it to define their own language. And the problem with that is that it will fracture the Python community because nobody can read each other's code any more. http://mail.python.org/pipermail/python-3000/2006-April/000286.html. I couldn't have said it better myself. No, but you could have quoted it more completely g: But please save your breath. Programmable syntax is not in Python's future -- or at least it's not for Python 3000. The problem IMO is that everybody will abuse it to define their own language. And the problem with that is that it will fracture the Python community because nobody can read each other's code any more. The last time c.l.l and c.l.p went to friendly war over macros we kept wondering why macros were any less comprehensible than functions or classes. Here it is!: It's one thing to read code that calls an external function whose meaning you have to guess from its name. It's quite another thing to realize that you can't even know for sure where the function calls are. Let's not go there. GvR seems to be thinking of something like the loop macro, which in its most commonly used syntax (it has two!) constitutes a distinct and unlispy language. If that is how macros were normally used (LOOP is quite abnormal) then, yikes, every macro could introduce a new language to be mastered. U, that is not how macros are used normally. And it is a helluva lot of work to erect a new syntax as LOOP does, so it is not exactly tempting. So... is GvR being scared off by a straw man? The other possibility is that he is just trying to justify not doing it because it would be so hard without the regular syntax of Lisp, including parens, and with the JIT module resolution problem discussed earlier in his remarks. Understandable. A final good reason is, hey, we already /have/ Lisp, Python needs to be different in order not to get absorbed into the mother of all languages. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: On Fri, 08 Dec 2006 14:52:33 -0500, Ken Tilton wrote: Aahz wrote: In article [EMAIL PROTECTED], Mark Tarver [EMAIL PROTECTED] wrote: I'm looking at Python and I see that the syntax would appeal to a newbie. Its clearer than ML which is a mess syntactically. But I don't see where the action is in Python. Not yet anyway. Lisp syntax is easy to learn. And giving up an order of magnitude is a high price to pay for using it over Lisp. Speaking as someone who had been programming for more than twenty years before learning Python (including a brief gander at Lisp), and also referring to many years of observations of newcomers to Python: Python's syntax also appeals to experienced programmers. 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. No programming language is easy to read, Well, you've just blown your credibility out the water with that nonsense. I am delighted to learn I had any to begin with. Perhaps you are thinking of individual lines of code being easy to read. Sure. I am talking about algorithms. Code cannot be read as if it were the Sunday comics. At any interesting level of complexity, one has to slow down and effectively hand-execute code in one's mind, not just read it as one reads natural language (and some of that makes one slow down to, no matter how well known are the individual words and grammar). and no Lisp programmer stopped using Lisp because they had been using it for a month and just could not get used to reading it. Or, to put it another way: No programmer who learned Lisp ever gave up before he learned Lisp. That would be the obvious retort, but my observation was empirical, so I am afraid you need numbers, not word games. You seem awfully hostile, by the way. Won't that make it harder to conduct an intelligent exchange of value to lurkers? I wonder, how many people gave up trying to learn Lisp because the language was too hard for them to read? Anyone like to bet that the number was more than zero? Sorry, no one ever discovered Lisp, decided it would be great for programming, started learning it and then gave up because they could not handle the syntax. The syntax is actually easier to master because of its regularity, and lisp-aware editors handle the parentheses such that they disappear in a month. Your position is untenable. It relies on this idea that all these Lisp programmers not only handle Lisp syntax effortlessly but also praise it as a significant advantage, they have all mastered several non-Lispy languages, but...what? They are mutants? Who just happen to have no problem with C and Java and Prolog and COBOL and Basic? Probably not. If you are saying someone will glance at a Lisp book and say they cannot understand it, well, that is not very interesting is it? ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
tmh wrote: snip Time for some more wine. ...and then just cut and paste the snipped bit into: http://wiki.alu.org/The_Road_to_Lisp_Survey ...if you are not there already. The survey questions are optional and what you wrote is perfect as is. Tough call on what goes in: http://wiki.alu.org/RtL_Highlight_Film Candidates: If you use it for a year, you won't want to use anything else. I've gained more insight into coding in the last 6 months then in the previous 15 years. I'd go with: Yet again, that could be the wine. :) kt -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: It is a good thing that not every hare-brained idea that some random programmer comes up with can be implemented as part of the core language. Well, that's the FUD/strawman, but nothing more. Just a hobgoblin to keep the Pythonistas from straying. But you have an excuse: Lispniks always /talk/ about macros giving us the ability to create a DSL. But no one does. :) Macros mostly hide implementation -- always a good thing -- where functions cannot. This, btw, is why Norvig brushing off macros with the ability to use regex to parse a DSL was so disappointing. I guess your other excuse is that your BDFL says the same thing. All in all, this is getting pretty funny. I am starting to picture you all (including GvR) running around with your hands over your ears going woo-woo so you cannot hear what we are saying. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: Do you know the Paul Graham piece Beating the Averages? It's at: http://www.paulgraham.com/avg.html The error in it is that Lisp is really just another Blub. http://weblog.raganwald.com/2006/10/are-we-blub-programmers.html There we find: But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages... Blub is good enough for him, because he thinks in Blub. What is up the power continuum from Lisp? ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: 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? We just know the Turing Complete thing cannot be used to duck language feature comparisons because the whole point of language comparison is how much pain does each language spare me?, where a Turing machine is ranked as the ultimate in programming pain. This might be because the whole point of a programming language is to spare us the pain of toggling switches on the back of an ENIAC. Anything any language can do is possible in any other language,... At what cost? hint ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: On Fri, 08 Dec 2006 22:02:59 +0200, Alex Mizrahi wrote: you have an expression 3 + 4 which yields 7. you have an expression 4 * 1 which yields 4. if you paste 3 + 4 in place of 1, you'll have 4 * 3 + 4 = 16. as we know, * is commutative, but 3 + 4 * 4 = 19. so result depends on implicit operator precendence rules. in lisp, if you paste (+ 3 4) in (* 4 1), you'll have (* 4 (+ 3 4)), and it does not depend on order of operands, (* (+ 3 4) 4) yields same results. you do not have to remember precendence rules Speaking as somebody who programmed in FORTH for a while, that doesn't impress me much. Prefix/postfix notation is, generally speaking, more of a pain in the rear end than it is worth, even if it saves you a tiny bit of thought when pasting code. Except, of course, it doesn't really save you any thought. You can't just expect to paste an expression randomly into another expression and have it do the right thing. Tell that to the unlimited number of monkeys I have over hear generating my next application. You might also read what I wrote earlier in this thread about how I leveraged the parens thing to edit code in logical chunks instead of chunks of text. If you think about it, that is exactly how code should be edited. But I am fascinated: Python text can be edited randomly because it uses infix? Or did you just throw in randomly because your point sounded so weak without it? :) Oh, it will compile all right. But it won't do the right thing! Since you -- not the compiler -- have to understand the semantics of what you are pasting where, and paste the right expression into the right place, the effort saved by not using infix notation is less than the effort needed to mentally translate between prefix and infix. Has it ever occurred to you that you might be the one translating? Because you are, you just do not know it. The only time I translate is when I have to express a multi-operator math formula in Lisp: (eql y (+ (* m (expt x 2)) b)) I threw an exponent into the slope-intercept form of a line for the heck of it. Gotta tell you, I do not have to code a lot of math formulas in Lisp, and I would definitely download and infix-eating macro if I did. Aside from that, you are the one translating. Prefix is terribly natural to the mind. Think about it. Add it all up. Add the tax and price and tip. Those are imperative, this one functional: the sum of the parts. The only time one hears infix in speech is when one is reading math notation. So... put two and two together. If you are one of those people who actually think in prefix notation, then I raise my hat to you while backing away slowly. Be careful backing away from yourself. :) I remember talking to a Welsh chap who had experienced the transition to a decimal system for money from the good old days of shillings, etc. He said he still had to translate pennies to shillings, even though the decimal system was less ornate. What mattered was the habit, not the clarity of representation. The good news is in my earlier point: you already are using prefix. Even in programming. What does a functionall look like? fn(p1,p2,p3) Lisp just moved the left parenthesis in front of the fn so the logical chunk (function+parameters) is also a textual chunk neatly packaged and editable between matching parens. (And actually, I'll give you one point: I've been hitting my head against a brick wall over a particular problem, and I think your email just gave me a clue how to solve it. Sometimes prefix/postfix notation is the right tool for the job. See, I can learn from Lisp.) I think that was A Message From God(tm). :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: 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? Anything any language can do is possible in any other language, if you are willing to write your own libraries. I do not think you know what are macros. You are talking about functionality, macros are about the syntax. To achieve what Lisp developers do with macros you would need to write a preprocessor (and indeed this has been done when the need was great enough) to run thru the code expanding all the uses of the preprocessor language. But then your edit-run cycle is broken unless your IDE will let you specify a preprocessor and take care of seamlessly running it, but then what do you debug? And then you cannot just toss off a macro, it becomes an exercise in compiler development and now you have dozens of preprocessors running on each cycle. Ew. And debug them. Let's not forget the debugging and testing, unless you'd like us to believe that Lisp code never contains bugs. Lisp developers so often gloss over that: Oh, feature X is *easy*, I could write it in a couple of macros. Two or three. Maybe thirty. Or forty, max. And they would work the right way first time. Do you really talk to a lot of Lisp developers, or were you making that up? :) Of course implementing an object system is a big job. Your fantasy about Lisp programmers misses the point to which you respond: after they had done all the work to implement an object system, they were able to make it look like Lisp had always had CLOS, without changing the compiler. Keep those fat pitches coming. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: On Sat, 09 Dec 2006 02:29:56 -0500, Ken Tilton wrote: David Lees wrote: Those raving about Lisp are quite accomplished at all those other languages, and know about what they are talking. Such a sweeping generalization. Every person who raves about Lisp is also accomplished with other languages. Yeah, right. I believe you, even if millions wouldn't. Ah, but that is because you are not a careful thinker, you just like sounding off on Usenet. Me, too! Think, Steve, think: do you think we pay the rent with /Lisp/ jobs?! If logic does not work for you, try this: http://wiki.alu.org/RtL_Highlight_Film Behind each sound bite is a full survey response, one question being what other languages do you use?. I doubt the Pythonistas weighing in on this thread ever got far at all with Lisp, so... should they really be offering comparative analysis? I hit my hand with a hammer once. Cool, first you use the lame Turing Completeness thing, now you are arguing by analogy, which does not work because now we have to argue about how well the analogue maps onto the topic. When I switched Lisps after several years of Lisp I also had to switch IDEs (not using Emacs+ILisp). I hated the new IDE. I also told myself to wait thirty days before worrying about it, since obviously it might just be a matter of habit. Now when I port things back to the first Lisp I hate that IDE (except I know a couple of weeks would turn it around). Now it may be distressing to you that I am talking about something closer to programming languages than is hammering ones hand, and for that I apologize in advance. :) I didn't keep going until I was an expert in hitting-own-hand-with-hammer before deciding that hitting my hand with a hammer was not for me. Did I do the wrong thing? Should I have kept going until I was an expect at it? (Of course, writing Lisp isn't precisely like hitting one's hand with a hammer. With the hammer, the endorphins kick in eventually, and it can become quite pleasant...) Personally, I never like Lisp syntax; Clearly some people, some fanatic judging by this thread :) think easily in prefix. I am not one of them. Yeah, you are, you just did not use it heads down for a month. The sheer arrogance of this claim is astounding. Actually, this is comp.lang.lisp. It isn't astounding at all. Exactly, and Usenet. Not the Supreme Court. We can speak casually. We can also speak cordially. hint I don't know, maybe lisp coders actually are more intelligent than ordinary mortals, No, it's the Lisp that makes them so effective. I was joking in my original remark. But not about Lisp programmers being better looking. :) but it has been my experience that they have absolutely no grasp whatsoever of the way most (many? some?) people think. And I'm not talking about can't-walk-and-think-at-the-same-time people either, I'm talking about bright, intelligent people who, nevertheless, don't agree with lisp coders. As you will soon realize because you are such an open, intellectually-honest person and will do the reading I recommended, most of us came to Lisp late in our programming careers, having used and excelled at (in my case) Apple Integer Basic, Microsoft Basic, 6502 Assembler, COBOL, any DEC Basics, C, Logo, and now Lisp (chosen over the new C++ because the latter seemed like evry bit the horror it turned out to be). I have done enough Python to appreciate the cleanliness of the code and its power, and enough Java... well, after Lisp it is impossible to find anything in some other language that would tempt one to work much in it. My point is that we grasp what you think because we /are/ you, we have worked alongside you, and we are very good at your language. And we use Lisp and gloat about it and piss everyone off with our smugness. It can't be helped--Lisp is that good. The way to tell if you spent enough time on Lisp is to look at Lisp code. If you see any parentheses, you have not spent enough time. They disappear in a month. If the parentheses are that meaningless, why do you need them? Meaningless? Who said that? Did you say that? Someone said that. :) I said they disappear. I am not looking at parens, I am looking at the code structure, as manifested by (you'll like this) the indentation, the indentation provided automatically when I kerplunk control-shift-P (I think, my fingers know). You like analogies. When i tried on my first glasses I said I can see the frames!. the glasses guy said, That is because you are looking for them. Something like that. With the editor handling the parens 90% of the time, I do not have to thnk about or look for them. btw, change all the ()s to []s and I /do/ see them. Possibly they would go away with time, but I have a hunch that []s might not go away, two cornery or something. The typical Pythonista values clean code but trembles in the face
Re: merits of Lisp vs Python
Alex Mizrahi wrote: (message (Hello 'Ken) (you :wrote :on '(Sat, 09 Dec 2006 04:26:02 -0500)) ( KT keep the Pythonistas from straying. But you have an excuse: Lispniks KT always /talk/ about macros giving us the ability to create a DSL. But KT no one does. :) certainly there's no reason to make a new DSL each day, but sometimes they are good. i've recently posted an example of DSL to do queries to RDF data base -- i find it's very helpful. That is different. Your very objective /was/ a language. Naturally, you created one. I am talking about PGs suggestion that the best way to solve a problem is to create a language for that problem and then use it. What I think happens more often is the other thing Graham said: building up CL to be a better language for the problem. So the language is still predominantly and visibly CL, and here and there are chunks of macrology hiding a crapload of boilerplate. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Bjoern Schliessmann wrote: Ken Tilton wrote: Note also that after any amount of dicing I simply hit a magic key combo and the editor reindents everything. In a sense, Lisp is the language that handles indentation best. Erm ... because there's an editor for it that indents automatically? Or did I miss the point? I think so, but you did not say enough for me to understand /your/ point. It sounded like you were using sarcasm to point out to me exactly what I had just said. We might want to punt on this. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: 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. But that isn't to say that the syntax of Lisp is for everybody. yeah, I think it is. Folks don't vary that much. If every Lisp programmer also reports parens disappearing at about thirty days, any given non-Lispnik can pretty much bet on the same experience. And since no one can produce a witness who worked fulltime on Lisp for thirty days and gave up on it because it was a great language but they could not handle the syntax, or a witness who stayed with Lisp because it is a great language even though to this day they have trouble reading the synatx... Far from it -- I'd be willing to bet that Lisp developers are a self-selected group of far above average intelligence. I think the early adopter is distinguished not so much by greater intelligence as by restlessness and rebelliousness and a little lunacy. We lack the knack of happiness. Many of the stories on the RtL reveal folks who sought A Better Way after mastering other languages. And by Better Way, sorry, we mean why do I have to forever worry about the damn paper tape on this Turing machine!. We do not really like programming, we like thinking about problems and using a computer to solve them. 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, ... I spend about 90% of my time thinking and writing code, and read it only to understand how something works or why it broke. And then I am looking at parentheses no more than you are looking at the lines of resolution on a TV when watching Baywatch. I am looking at a mechanism and how it works. ...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. My suspicion goes the other way, and is based not on punctuation, rather on imperative vs functional. In Lisp every form returns a value, so I do not have all these local variables around that, in the strecth of an interesting function, take on a stream of values and transformations to finally come up with some result, meaning to understand code I have to jump back and forth thru the code to see the lineage of a value and figure out its net semantics. Too much like work. Everybody else does, and gravitate to languages which might not be better but are good enough. No, they gravitated to a language that was closer to what they already knew, C or Java (which also mimicked C to pick up those users). Later charms of Python were a great community and library support. Lisp simply does not have the latter, one is forever rolling one's own bindings to C libs. (If my post leads to any Lisp developer's already swollen head exploding from pride, my job here is done *wink*) They can't get any bigger. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: Some languages are too expressive. :) Look, all snarkiness aside, it just isn't true that stuff like this is impossible in other languages. If Wolfram Fenske had said stuff like this isn't easy in many other languages he would have been right. Remember, Lisp macros are like being able to run a preprocessor on an ad-hoc basis. Without Lisp compilers (er, should I say the Lisp reader?) understanding macros and macro functions, not even Lisp could transform source code this way. We won't have an intelligent discussion on macros until this gets better understood. Macros are not about what one can do at run-time, they are about what happens at compile time. If your compiler/preprocessor/IDE are not going to cooperate, then embedding a preprocessed language in Python is so hard as to be unfeasible. I also would not quibble over impossible vs. incredibly hard. The bottom line is that at a pretty low level hard becomes aint gonna happen. And if he had said and stuff like this carries risks as well as benefits he would have come across as less of a language fanatic. One of the risks with Python is the ease with which you can modify the built-ins. An expression like list(2, 3, 4) doesn't necessarily create a list from 2, 3, and 4, because the built-in list could be redefined. (In practice, that's not often a real problem, because experienced Python developers simply learn not to needlessly or confusingly shadow built-ins. Well, duuh. This the Great Strawman, that Lisp programmers (a) love having a powerful language (b) so they can produce unreadable code. This nonsense is an implicit concession that you have no point at all. It's not the best system, but it works well enough in practice.) But at least the basic syntax and keywords of the language are known to be constant. 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. I have to admit you are probably still catching up on what I have written today. then, no doubt, we'd take you guys more seriously. But we don't hear that -- we hear Lispers going on and on about how great it is that they can easily redefine every corner of the language. You have this tendency as your paragraphs grow to get sillier and sillier and make up more and more hobgoblin crap, I suppose as you sense the weakness of your case. Can you point to where someone said that? No, of course not. Get a grip, will you, this could be a useful cultural exchange, but not with your hysterics. why do you need macros then if you are just using them as functions? Why not use functions? Hint: famous Lisp style rule: never use a macro where a function will do. Not sure it is worth wasting more time on you at this point or I would offer examples. Could you calm down a bit and stop making things up? ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Pascal Bourguignon wrote: Kirk Sluder [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED], mystilleef [EMAIL PROTECTED] wrote: 1). More and better mature standard libraries (Languages don't matter, libraries do). 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. I've not seen a convincing explanation as to why imported macros from some library are so much more evil than imported functions. In both cases one might have to dig into documentation and/or comments to understand exactly what that imported snippit is doing. And the difference with a library function is? Uh, that was his point. And if you all dig back thru this thread you will find me quoting GvR on the difference, which is (paraphrasing) with macros you do not even know where the function calls are. I think he is talking about a loop-like erection of a new language. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
mystilleef wrote: Bill Atkins wrote: Are any of these not subjective? Objectivity is in the eye of the beholder. 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. But CLOS is the best OO there is. The OMG said so. It can do anything any other OO can do. Why /specifically/ would you not use it? This type of thread has no educational value unless one is specific; we already know what the posters like and prefer, so the only added value comes from being specific about language details. And funny put-downs. :) 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. Hopefully, because any sizeable app will have its sum functionality compartmentalized into internal little sub-APIs. These five/ten data structures and functions have been created to handle this recurring problem faced by higher-order functions. Sometimes dealing with that API requires boilerplate code to be written. Set things up. Make a call. Check the return status for xyz. etc etc. That boilerplate can become a macro, such as WITHOUT-C-DEPENDENCY: (defmacro without-c-dependency (body body) `(let (*call-stack*) ,@body)) *CALL-STACK* is internal to Cells and should not be exposed. It is cool that all I need do to defeat the entire Cells engine is bind one special variable, but maybe someday that will get hairier. if so, no problem, I just change the macro. Btw, without special variables, you would need: (let ((save-stack *call-stack*) (setf *call-stack* nil) your code here, possibly trapping errors (setf *call-stack* save-stack)) If you want to use a function instead of a macro and still hide the boilerplate, it would have to be: (without-c-dependency (lambda () your-code-here)) Not the end of the world and at least one Lisp legend thinks that makes macros unnecessary. 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. You and GvR are thinking of the case where a macro is used to create a whole new syntax, like LOOP (a mildly controversial part of standard Lisp). I have written more macros than you can imagine and only once even came close to it (but the language was just a list of things to do, nothing incomprehensible). I have never seen a macro which introduced a new language. Of course, we all keep saying this and you all keep repeating the opposite, so we do appreciate the excuse to repeatedly explain how macros are really used. :) The benefits of extending a language in a domain specific manner are exaggerated. Careful, there are laws now against cruelty to straw men. My observation is that macros are important to Lisp and it's derivative because they lack libraries to begin with. Damn! Exactly which macro would have saved me creating bindings to OpenGL? (I think you have a little category error going here.) Common problems solved using macros in Lisp and friends are solved using specialized libraries in most other languages. Damn! Exactly which macro would have saved me creating bindings to OpenGL? (I think you have a little category error going here.) And I like the specialized libraries route. Damn! Exactly which macro would have saved me creating bindings to OpenGL? (I think you have a little category error going here.) Meta-programming just doesn't tickle my fancy. It just spells maintainance nightmare. The whole idea of meta-programming is reducing coding and simplifying maintenance, so I have to wonder how much experience you have writing macros. Could you post a few? Macros come into play when we find a pattern in out code that is a level more abstract than straight token replacement (ala C) will support. My simple example above is just about avoiding typing LAMBDA, which I hate. :) More interesting macros take a look at the input source to the acro invocation and, instead of subsituting in a fixed template as does the C preprocessor, actively assembles template bits and input bits to produce the final result. Of course one has to be clever enough to see higher-order patterns and appreciate the vast productivity increase available in return for the effort of thinking through a macro -- well, i should note that often I do not create the macro until I see also that this bit of internal API will be coming up often enough (or will be changing often enough as I come to understand it) to
Re: merits of Lisp vs Python
Eric Pederson wrote: No programmer who learned Lisp ever gave up before he learned Lisp.That would be the obvious retort, but my observation was empirical, so I am afraid you need numbers, not word games. You seem awfully hostile, by the way. Won't that make it harder to conduct an intelligent exchange of value to lurkers? I wonder, how many people gave up trying to learn Lisp because the language was too hard for them to read? Anyone like to bet that the number was more than zero?Sorry, no one ever discovered Lisp, decided it would be great for programming, started learning it and then gave up because they could not handle the syntax. Uh. Clearly no one would be dumb enough to admit it in front of the entire usenet world, right? The good news is that I was just trying to flush out a live specimen. The bad news is that after some tests we want to dissect you. - Mr. NoOne P.S. I am still going to get back to it when I get some time, really. LISP seems intriguing and superior, almost a magical Rubik's cube waiting for me. I just stumbled across Python in the meantime and code started flowing - I got distracted. Oh, shucks, that is not gave up because they could not handle the syntax. You have me wondering if I would have switched from C to Lisp had Python been what itis now back in '95. Obviously the simple transition would have been attractive. OTOH I had done extensive LOGO (and loved it) and experimented heavily with Prolog, so syntax would not scare me. The immaturity of Python would have been an issue because I had just gotten sliced up pretty badly with bleeding edge stuff I tried at the same time (trying desperately to avoid C++). I beat on the C preprocessor like I was its daddy, so macros might have made sense to me even without having played with them. Giving up cycles I would not like all other things being equal. And to tell you the truth, novelty tends to make me more productive, not less, because fresh brain cells perforce get pulled into play. Sounds like I would have dabbled in both, and then Lisp would have won because I recall the first two weeks being pretty much astonished whooping and hollering over how great Lisp was. But Python has a lot of that, too. I have CL ( Scheme) on all my machines awaiting my focus I'll join the flock any day now. :-) I've just been busy. There is a cost to learning and I've not had the spare change to date. But New Years resolutions need to be made: I could get up a couple hours early and spend some quality time with CL, do a daily hour jog, and eat a really heathly breakfast. Writing myself a note on this. P.P.S. Undoubtedly not learning a syntax either means not enough time was put in or the student lacked proper intelligence. Intelligence to understand syntax? Isn't it memory (and not so much that the correlation with intelligence would matter)? This punctuation means this, that punctuation means that, and the precedence is this. One of the big wins of Lisp is that it is just (verb object*) 95% of the time. Maybe you mean functional vs imperative requires intelligence? That I might buy. A little. But then Lisp handles imperative, too. You just get laughed at it if you post it to c.l.l. This will always bias the significance of learning syntax as a factor in choice of language to be under reported. That's OK, I am looking for the person so bright they have the self-confidence to expose their failure. Then we do not have to dissect them, we can ask them to introspect and get useable data. But you did not say anythng about having a problem with Lisp at all let alone the syntax and indeed offer some quotes that could go in the RtL Highlight Film, so you are useless. No fee for you. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: Ken Tilton [EMAIL PROTECTED] writes: yeah, I think it is. Folks don't vary that much. If every Lisp programmer also reports parens disappearing at about thirty days, any given non-Lispnik can pretty much bet on the same experience. I think an editing program that balances parens automatically is near indispensible for writing Lisp code. I would say indispensible full stop. I can't stand writing Lisp without Emacs. Emacs or an Emacs-like editor (or at least Lisp-ware editor) provided by the Lisp environment. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
André Thieme wrote: Ken Tilton schrieb: The last time we went thru this a Pythonista finally said, Oh, I get it. These five lines of code I have to write all the time (two setup, one func call, two cleanup) can be collapsed into one or two. The thread will be hard to miss in Google groups (two years back?) and the epiphany appears right at the end of the thread. hint Functional programming is the solution here, not Lisp. No, you do not understand. The Pythonista figured it out: a function would not do. You could make that with a new function (in Python), that takes a function (and its args, don't remember the correct syntax). def foo(function, args): setup(1) setup(2) function(args) cleanup(1) cleanup(2) The nice thing in Lisp would now be to save a lambda with the macro. In Python one would fill the name space with throw away functions that get called only one time. Omigod. Is that what you meant? You think macros are unnecessary because one could hard-code their expansions as separate functions? And that would constitute hiding the boilerplate? What happens when the boilerplate changes? game over ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
André Thieme wrote: Ken Tilton schrieb: André Thieme wrote: Ken Tilton schrieb: The last time we went thru this a Pythonista finally said, Oh, I get it. These five lines of code I have to write all the time (two setup, one func call, two cleanup) can be collapsed into one or two. The thread will be hard to miss in Google groups (two years back?) and the epiphany appears right at the end of the thread. hint Functional programming is the solution here, not Lisp. No, you do not understand. The Pythonista figured it out: a function would not do. What do you mean? I am saying use Google groups to find the thread and find out the use case contributed by a Pythonista in the midddle of a similar thread that conveyed to his satisfaction the value of macros. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: Rightly or wrongly, people fear... So when people fear wrongly we burn whatever witches we must to reassure them? that Lisp's macros push Lisp closer to that hypothetical anything-goes language than is healthy. Maybe that's a problem of perception rather than a problem of fact, but you have to ask, why do people perceive Lisp that way? Could it be because of people like J Shrager who writes things like this? Can't you just expand the language via macros to create whatever facility of this sort [major new features with new syntax] you need... The context was CLOS. Something that big needs new syntax. But what you do not know is that the syntax is Lispy, so learning it is tantamount to understanding new function names, as even Pythonistas must do (tho a few of you seem to think Pythonistas are incapable of learning g). (This thread, dated 8 Dec 2006 16:14:44 -0800) Or Wolfram Fenske: All the interesting features that haven't originated from Lisp (e. g. OO from Smalltalk) could in turn easily be implemented in Lisp with a couple of macros. Right, something big like an OO. (This thread, dated 8 Dec 2006 23:38:02 -0800) To someone outside of Lisp, that looks like I can make Lisp look like any language I like in just a few lines. On the contrary, on the rare case when it happens (CLOS, my Cells package) one is obliged by exactly the hobgoblins you fear to remain true to lisp patterns when extending Lisp. And there are patterns in macro usage as well: (my-macro optional arguments to macro expansion my-macro-forms+) Your hands must be getting sore from banging that drum so hard and so long -- has it ever occurred to you that good programmers concerned with power do not obfuscate code? And now you have read a dozen messages from serious Lispniks trying to tell you that that is not the case, and you persist. We love the chance to preach to the unsaved, so we are indebted to you for the many chances to clarify, but something tells me I should check the c.l.p archives to make sure I am not chatting away happily with the village idiot. :) And that implies that to read a Lisp program, one might need to be able to read code that looks like Lisp, or Smalltalk, or Prolog, or Fortran, or all of those, or whatever bizarre syntax the developer wanted it to look like. I don't want to think, I just want to bang on de drum all day. I don't want to learn, just want to bang on de drum all day. My point isn't whether or not their claims are correct (a couple of macros? really?) but that things like this feed the perception... Ah, well at least you are copping to witch-burning. Thx. And it isn't really that much comfort to be told that good Lisp developers know not to do stupid things with macros. Hmm, didn't we see that as a comforter for some powerful Python mechanism earlier in this thread? Sure. But in the real world of programming, most developers aren't good developers, they are merely average Two questions: do you really voluntarily use libraries from crappy developers? Second, you think a language can stop people from writing bad code? Java tried, and look where that got the language. Elsewhere a Pythonista (Mr. Rubin?) bemoaned this thread's appearance of Pythonistas shrinking from power... could you two get together? :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
greg wrote: Bill Atkins wrote: And mistakes in nesting show up as mistakes in indenting. Er, hang on a moment... how do you *know* when you've got a mistake in indending? You must be visually verifying the indentation... rather like one does with Python code... Absolutely, and you are not disagreeing with Mr. Atkins, tho you seem to think you are. But with Lisp one does not have to clean up the indentation manually after thrashing away at ones code. As I type each right parens I eyeball its partner as the editor highlights it to make sure I have not missed anything, then give the re-indent command and eyeball the result. It /is/ still possible to screw up because I work fast and loose, but only very rarely do I end up with a parens in the wrong place, and then the compiler finds something to whine about. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: On Sat, 09 Dec 2006 14:55:13 -0800, Paul Rubin wrote: Steven D'Aprano [EMAIL PROTECTED] writes: Now, if you want to tell me that, despite all the talk, Lisp coders don't actually create new syntax or mini-languages all that often, that they just use macros as functions, then the question becomes: why do you need macros then if you are just using them as functions? Why not use functions? Macros let you write what amounts to functions that don't evaluate their arguments. Think of the endless clpy wars over the ternary conditional operator. [snip] That is trivial to do with a macro I know that. It was more of a rhetorical question -- Lispers are either trying to emphasis the radical nature of what you can do with macros, or understate it and make them seem just like functions. Yep, both. The first is rare. CLOS is one, my Cells (ported this summer to PyCells as part of SoC 2006) is another. The latter is the norm. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: The day has not yet arrived that nobody ever needs to edit code in a plain, vanilla text editor. Gee, 200kloc of Lisp and I have not got there yet. Keep banging that drom, Steve. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: If that's the best example of what macros can be used for, frankly I'm unimpressed. We're shocked. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: On Sat, 09 Dec 2006 22:06:29 -0500, Ken Tilton wrote: As I type each right parens I eyeball its partner as the editor highlights it to make sure I have not missed anything, Er, weren't you one of the people claiming that you don't notice parens when you're reading or writing Lisp code? Steve, you seem to be doing everything you can to make what is basically a decent cultural exchange unpleasant, mostly by bellowing like some mad rogue elephant over and over again about macros, now by trying to play gotcha. I said they disappear. They do. I do not see parens when I look at code. The watching of the matching is only after furious thrashing during refactoring, and even then it is unconscious most of the time because we are usually also indenting as we go. I presume you look to see if your indentation is correct while you are indenting, with no more effort than I eyeball the highlighted parens. You think that some gotcha is somehow going to miraculously reveal that I do in fact have trouble with parentheses? Now /that/ would be dumb of you. So, if you're still seeing parentheses, does that mean you've been coding Lisp for less than a month? I see you figured it our for yourself. Obviously I love parentheses and would hate to program without them, so obviously your gotcha falls short. I myself am simply delighted. I decided I should indeed check out if I was up against the c.l.p village idiot. Nope, turns out you are the Master of FUD: http://www.itwire.com.au/content/view/7359/53/ According to Steven D'Aprano, operations manager of longstanding open source services firm Cybersource, Microsoft's new game of attempting to strike fear into the heart of Linux users by invoking the spectre of patent infringements may soon take an ominous new twist. Mr D'Aprano believes that Microsoft may well use similar tactics employed by its proxy the BSA six years ago when it raided the offices of guitar string maker Ernie Ball with armed marshalls and found a few machines with non-compliant software. I love it, you turning FUD on the FUDster, MS. Good for you! A whole article with nothing but your unsubstantiated guesses as to Microsoft suing someone! I do not who impresses me more, you giving such an interview or the reporter who printed it... no, you guys are allowed to screw up, the editor should be shot. Hey, Steve, save that crap for Microsoft, will you? peace. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Mark Tarver wrote: How do you compare Python to Lisp? Lisp programmers are smarter and better looking. And better programmers. Not sure if that is what you were after, though. What specific advantages do you think that one has over the other? http://www.googlefight.com/index.php?lang=en_GBword1=parenthesesword2=white+space Ouch. hth,kt -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Bjoern Schliessmann wrote: Alex Mizrahi wrote: (message (Hello 'Bjoern) BS Can you give an example? I cannot imagine how homogenity always BS results in easiness. homogenity means that i can cut any expression and paste in any other expression, and as long as lexical variables are ok, i'll get correct results -- i don't have to reindent it or whatever. Ah, so *that's* what you meant ... but I don't really understand the ease of it. Code in the abstract exists as a tree of trees. With parens, we now have textual markers delimiting these trees. That means I can point to any arbitrary subtree by pointing to its left or right parens, and tell the editor to copy or delete that chunk of logic. And now I am manipulating chunks of program logic instead of text. One simple but hopefully illustrative example: suppose I have an if statement with two big branches. My code then looks like: (if (condition) (big-branch-1)(big-branch-2)) Please remember that any of those fakes can be arbitrarily deep nested expressions. Now during refactoring, I decide bb-2 processing goes elsewhere, maybe somewhere upstream in the logic. So I double-click and then drag-and-drop, or cut and paste. Then I double-click on the entire if statement, and then do a control-click on the then condition, control-click happening to mean paste what I am clicking. Suddenly the then is the whole form. (And, yes, this means my vendor took away from me the normal copy-and-drop associated with control click g, but I could modify things to get it back if I really cared.) Of course the next question has to be, how often does that come up? When refactoring it sometimes feels like I do nothing else. :) It turns out that this is an insanely natural way to work with code. Note also that after any amount of dicing I simply hit a magic key combo and the editor reindents everything. In a sense, Lisp is the language that handles indentation best. hth, ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Aahz wrote: In article [EMAIL PROTECTED], Mark Tarver [EMAIL PROTECTED] wrote: I'm looking at Python and I see that the syntax would appeal to a newbie. Its clearer than ML which is a mess syntactically. But I don't see where the action is in Python. Not yet anyway. Lisp syntax is easy to learn. And giving up an order of magnitude is a high price to pay for using it over Lisp. Speaking as someone who had been programming for more than twenty years before learning Python (including a brief gander at Lisp), and also referring to many years of observations of newcomers to Python: Python's syntax also appeals to experienced programmers. 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. No programming language is easy to read, and no Lisp programmer stopped using Lisp because they had been using it for a month and just could not get used to reading it. So I think you are just making things up. :) 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. Haha, what's the score? And how much time is left in the first quarter? :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
George Sakkis wrote: [EMAIL PROTECTED] wrote: Okay, since everyone ignored the FAQ, I guess I can too... Mark Tarver wrote: How do you compare Python to Lisp? What specific advantages do you think that one has over the other? (Common) Lisp is the only industrial strength language with both pure compositionality and a real compiler. What Python has is stupid slogans (It fits your brain. Only one way to do things.) and an infinite community of flies that, for some inexplicable reason, believe these stupid slogns. These flies are, however, quite useful because they produce infinite numbers of random libraries, some of which end up being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python is rapidly replacing Perl, and Ruby is simultaneously and even more rapidly replacing Python. Each is closer to Lisp than the last; the world is returning to Lisp and is dragging the flies with it. Eventually the flies will descend upon Lisp itself and will bring with them their infinite number of random libraries, and then things will be where they should have been 20 years ago, but got sidetracked by Tcl and other line noise. I know we shouldn't feed the trolls, but this one was particularly amusing to resist the urge. The joke about lisp's world domination in some unspecified point in the future never fails to bring a good chuckle. I heard it's scheduled right after strong AI and before time travel, is this still the plan? A quick look at http://www.tiobe.com/tpci.htm may be helpful as a reality check before you go back to your ivory tower (interesting how close in ratings and growth is the Lisp/Scheme entry with another dinosaur, Cobol). And it interesting that VB is almost three times better than Python, and that a Honda could kick a Lamboghini's ass for it at Laguna Seca: http://www.googlefight.com/index.php?lang=en_GBword1=lamborghiniword2=ford Come on, COBOL is a great language, even has macros (copy ... replacing) and the worlds greatest case statement, evaluate. We are proud to be its neightbor. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
David Lees wrote: [EMAIL PROTECTED] wrote: Okay, since everyone ignored the FAQ, I guess I can too... Mark Tarver wrote: How do you compare Python to Lisp? What specific advantages do you think that one has over the other? (Common) Lisp is the only industrial strength language with both pure compositionality and a real compiler. What Python has is stupid slogans (It fits your brain. Only one way to do things.) and an infinite community of flies that, for some inexplicable reason, believe these stupid slogns. These flies are, however, quite useful because they produce infinite numbers of random libraries, some of which end up being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python is rapidly replacing Perl, and Ruby is simultaneously and even more rapidly replacing Python. Each is closer to Lisp than the last; the world is returning to Lisp and is dragging the flies with it. Eventually the flies will descend upon Lisp itself and will bring with them their infinite number of random libraries, and then things will be where they should have been 20 years ago, but got sidetracked by Tcl and other line noise. Hmmm. The last time I fooled around with Lisp was 1966 from the Lisp 1.5 Manual Published by MIT in cloth. It was interesting and different from the other languages I was using, Algol 60, Basic and Macro assembler for the GE-235 and GE-635. When I read some of the over the top type hype by Lisp enthusiasts (like the stuff above) it feels like a flash back to the mid 60's. Not sure I understand why, unless you mean folks were raving about Lisp in the 60s. Today's raving is about a much different language, though the core elegance remains, and is as much about the contrast with other languages as it is about the pleasure of Lisp itself. Those raving about Lisp are quite accomplished at all those other languages, and know about what they are talking. I doubt the Pythonistas weighing in on this thread ever got far at all with Lisp, so... should they really be offering comparative analysis? Personally, I never like Lisp syntax; Clearly some people, some fanatic judging by this thread :) think easily in prefix. I am not one of them. Yeah, you are, you just did not use it heads down for a month. The way to tell if you spent enough time on Lisp is to look at Lisp code. If you see any parentheses, you have not spent enough time. They disappear in a month. The typical Pythonista values clean code but trembles in the face of macros, which exist to hide boilerplate. That means the only thing showing in any given block of code is exactly the interesting variable and function names. Talk about readability. Computer languages are tools and everyone should pick the ones that they are most comfortable and productive with. No, languages are not interchangeable. Python is a fine language, but Lisp is much more expressive/powerful. Six years ago, when I drifted back into programming, I had to learn about Object Oriented programming and C++. I used Python as a means to update my programming skills (limited though they are) by 30 years or so. It was a wonderful intro to OO and served me well. I ended up writing all kinds of little things for work (simple HTTP servers for load testing, ECAD hacks for the ASIC guys, even a register level chip simulator) Even better, I find it a pleasure to write small utilities, to prototype C code and generally do things quickly. I use it by choice to get things done, not because it is mandated. At my current job as a Systems Engineer for a large aerospace firm, I do not program daily, but when I need to write a quick hack, I always use Python. Much of Lisp's power would be lost on a non-programmer, but Lisp might make a programmer out of a non-programmer if they had it in them. You might have the right language for you because what Python does have is lotsa libraries, and if you are just hacking scripts to glue together libraries the expressiveness of Lisp is more than offset by the better library support in Python. ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: logo design
Xah Lee wrote: Logo LISP Xah Lee, 2006-12 Ken Tilton wrote: «Small problem. You forget that Ron Garret wants us to change the name of Common Lisp as the sure-fire way to make it more popular (well, hang on, he says it is necessary, not sufficient. Anyway...) I do not think we can safely pick a new logo until we have our new name.» Changing a language's name is not something that can be easily done, and is unnatural and takes concerted effort, and is very difficult for it to be successful. However, creating a (universally recognized) logo for the language, is easily done, and in fact the use of a logo or some representative image is inevitable and wide-spread, willy-nilly. For example, although there are no official logos for lisp, but as you know, there are several logos or images of various forms that are already used widely, either to represent lisp the language family, or to represent the Common Lisp language. And, for various Scheme implementation, they almost all had a logo of their own. Example: above: The “twisty AI font” LISP logo. Used by http://lisp.org/ as early is 2001. above: The “earth in parenthesis” logo, used by http://lisp.org/ as of 2006-12. above: Conrad Barski's “alien technology” lisp web-badges (source ↗), which appeared in 2005. above: Manfred Spiller's “lizard” lisp web-badge (source ↗), which appeared in 2005. As these examples shows, that the use of a logo is needed in practice. However, it wouldn't help if there are one hundred different logos to represent the same thing. The point of logos, is to have a memorable, graphical representation. In modern, capitalistic, societies filled with information, the use of logos is inevitable. Just look around you at this very moment, you probably can identify tens of logos, and for each logo, you probably recognize what they represent. Logos, is merely a graphical representation of a entity, whose textual analogous counterpart are names. Since there is a need for logos, we might as well get together and agree to have one official logo for lisp the language. That way, it solidifies the purpose of the logos in use. Note that, although we have the beautiful “lisp lizard” and “alien technology” graphics, but because of their graphic content and in particular the embedded slogan, they do not fit as a logo, but more as web-badges. Web-badges serve slightly different purpose than logos. It is more for the purpose of promotion, than representation. For the same reason, there are mascots. For example, Java the language, has a official logo of a smoking coffee cup,.. A subtle execution of the tip of a tongue pressed against the upper teeth with sprays of spittle coming out either side probably is not what you had in mind. Hmmm. Then we change the spelling to Lithp, and never have to hear that stupid joke again. Our slogan can be Thay it loud, thay it proud.*, and we already have the frickin lambda. hth,kt Or Out With Lithp!. k -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it. -- Elwood P. Dowd I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: logo design
alex23 wrote: Xah Lee wrote: No personal offense intended, but human animal's history is what? 3000 years at least in recorded history? And, all you can think of is what, the view points of a fraction of your personal life span? Thank god evolution spat you out to lead us all to the light, huh? No personal offense intended, but you're a boring, elitist prick. Actually, no, Xah is pretty cool, give him a chance. hth, kt -- Cells: http://common-lisp.net/project/cells/ I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: The Semicolon Wars as a software industry and human condition
Xah Lee wrote: • What Languages to Hate, Xah Lee, 2002 http://xahlee.org/UnixResource_dir/writ/language_to_hate.html Nonsense. This is technology, not religion. Technologists in fact have a responsibility to identify and use the best tools available. Xah, you are getting soft in your old age. :) hth, kenny -- Cells: http://common-lisp.net/project/cells/ I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: Reddit broke - should have remained on Lisp?
Luis M. González wrote: Alok wrote: While posting a comment on http://www.reddit.com I got an error page with the following curious statement on it. reddit broke (sorry) looks like we shouldn't have stopped using lisp... See screenshot at http://photos1.blogger.com/blogger/1773/1980/1600/reddit-broke.jpg Whether they truly repent not using lisp or otherwise, their site appears to be 3 times slower ... Alok I don't know if this is true or not, but blaming a language for a poor development is a little bit ridiculous... Well, Reddit said it, not us, and they were probably joking, but it may well be that the bug would not have happened if they were using Lisp. Could an infinite number of engineers doing code reviews eventually found the bug before the end of the universe? The reality is that every project has finite resources, all the better reason not to stress the team with the wrong language. kenny (making Rahul happy by being f'ed by OpenGL bugs) -- Cells: http://common-lisp.net/project/cells/ I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
TONIGHT! Lisp group beerfest in NYC, PyCells to be discussed
The royal We has just learned that His Kennyness will be honoring the boozehounds of LispNYC with His Presence tonight (deets below). He will come bearing Celtk and news of PyCells, though the top billing tonight goes to SoC student Extraordinaire Samantha Kleinberg. kenzo Please join us for our next meeting on Tuesday, June 13th from 7:00 to 9:00 at Westside Brewery. With Summer of Code being here, this is a great opportunity to talk and drink regarding the students and their projects! Hope to see you there! Directions: Westside Brewery in the VIP room 340 Amsterdam Ave. (On the West side of Amsterdam Ave., 76th-77th) Directions by subway: 1-2-3-9 (the red line) to 72nd or 79th and Broadway. From 72nd, walk up Amsterdam (not Broadway). From 79th, walk east one long block to Amsterdam and turn right/south. Directions by car: 79th street exit from west side highway, down West End Ave or Broadway to 76th, turn left and one or two blocks to Amsterdam. -- Cells: http://common-lisp.net/project/cells/ I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Joe Marshall wrote: Xah Lee wrote: in March, i posted a essay What is Expressiveness in a Computer Language, archived at: http://xahlee.org/perl-python/what_is_expresiveness.html I was informed then that there is a academic paper written on this subject. On the Expressive Power of Programming Languages, by Matthias Felleisen, 1990. http://www.ccs.neu.edu/home/cobbe/pl-seminar-jr/notes/2003-sep-26/expressive-slides.pdf Has anyone read this paper? And, would anyone be interested in giving a summary? The gist of the paper is this: Some computer languages seem to be `more expressive' than others. But anything that can be computed in one Turing complete language can be computed in any other Turing complete language. Clearly the notion of expressiveness isn't concerned with ultimately computing the answer. Felleisen's paper puts forth a formal definition of expressiveness in terms of semantic equivilances of small, local constructs. In his definition, wholescale program transformation is disallowed so you cannot appeal to Turing completeness to claim program equivalence. Expressiveness isn't necessarily a good thing. For instance, in C, you can express the addresses of variables by using pointers. You cannot express the same thing in Java, and most people consider this to be a good idea. Thanks for the summary. Me, I would like to see a definition of expressiveness that would exclude a programming mechanism from things to be expressed. If the subject is programmer productivity, well, I write programs to get some behavior out of them, such as operating an ATM cash dispenser. If I need to keep a list of transactions, I need to express the abstraction list in some data structure or other, but below that level of abstraction I am just hacking code, not expressing myself -- well, that is the distinction for which I am arguing. heck, in this case I will even give you as thing to express getting back multiple values from a function. That comes up all the time, and it can be an aggravation or a breeze. But then I would score C down because it does not really return multiple values. One still has some heavy lifting to do to fake the expressed thing. But I would still give it an edge over java because Java's fakery would have to be a composite object -- one could not have a primary return value as the function result and ancillary values somewhere else. kt -- Cells: http://common-lisp.net/project/cells/ I'll say I'm losing my grip, and it feels terrific. -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
Re: John Bokma harassment
Tim N. van der Leeuw wrote: [EMAIL PROTECTED] wrote: I agree there are limits to you right to free speech, but I believe Xah Lee is not crossing any boundaries. If he starts taking over newspapers and TV stations be sure to notify me, I might revise my position. Immanuel Perhaps he's not crossing boundaries of free speech, but he's repeatedly crossing boundaries on usenet nettiquette, even though repeatedly he's being asked not to do so. This would be a more compelling argument if people on newsgroups everywhere did not regularly carry on the most inane threads, often off-topic to begin with, but mostly threads that stray from something relevant to the NG to insert just about anything, ending only when Hitler is reached. And I am talking about NG regulars who really do usually talk about stuff specific to the NG. Those are the worst spammers of c.l.l, anyway. Xah's stuff, as wild as it is, is at least technical, and it is only an article here and an article there. John Bokma on the other hand well, I have to go write to the dorks at dreamhost now. kenny -- http://mail.python.org/mailman/listinfo/python-list
Re: John Bokma harassment
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! :) 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. kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Ben wrote: This kind of discussions between two groups of people, neither of who know the other person's language very well just wind me up something chronic! I must say, it is pretty funny how a flamewar turned into a pretty interesting SoC project. Anything that makes programming more fun is good, and I hope the Lisp true way explodes into my head at some point. Here is an excerpt of an excerpt from famous Gears demo. I notice it really makes concrete what Lispniks are talking about in re macros and multi-line lambda (pity about the formatting): (defmodel gears-demo (window) ((gear-ct :initform (c-in 1) :accessor gear-ct :initarg :gear-ct)) (:default-initargs :title$ Rotating Gear Widget Test :kids (c? (the-kids (mk-stack (:packing (c?pack-self)) (mk-row () (mk-button-ex ( Add (incf (gear-ct .tkw (mk-button-ex (Remove (when (plusp (gear-ct .tkw)) (decf (gear-ct .tkw) (mk-entry :id :vtime :md-value (c-in 10))) (make-instance 'gears :fm-parent *parent* :width 400 :height 400 :timer-interval (max 1 (or (parse-integer (fm^v :vtime)) :junk-allowed t) 0))) Don't worry, Lispniks cannot read that either. It is a delarative construction of a hierarchical GUI. That is such a common task, that I have rolled up a bunch of GUI-building macrology so that just the stuff specific to this GUI gets typed in. Since the Gears widget is a custom widget I have no macrology for that, and the wiring shows in the expression :fm-parent *parent* (which itself leverages Lisp special variables). And no, I cannot remember all my macrology. I can certainly read it and easily modify my GUI, because all the wiring is hidden, but if I have to build a new GUI I cut and paste from other GUIs. Let's look at just one form, which I believe destroys Alex's whole case for naming every lambda: (mk-button-ex (Remove (when (plusp (gear-ct .tkw)) (decf (gear-ct .tkw) mk-button-ex (a) makes fun of MS$ naming standards and (b) expands to: (make-instance 'button :fm-parent *parent* :text remove :on-command (c? (lambda (self) (when (plusp (gear-ct .tkw)) (decf (gear-ct .tkw)) The above is what one really needs to write to stick something in my GUI framework, but who wants to look at all of that when most of it is boilerplate? I need :fm-parent *parent* on every label and widget because of some internals requirements, I just do not want to look at it or have to remember to code it all the time (the latter not being a huge problem because I really am cutting/pasting when I build a new GUI). Is mk-button-ex some mysterious new language construct that will make multi-programmer projects collapse in a heap of programmer-specific constructs inscrutable to anyone else on the team? (a) mk-button-ex kinda tells you (1) it makes a button and (2) no, this is not part of Common Lisp, so where is the confusion? (b) control-alt-. in my IDE shows me: (defmacro mk-button-ex ((text command) rest initargs) `(make-instance 'button :fm-parent *parent* :text ,text :on-command (c? (lambda (self) (declare (ignorable self)) ,command)) ,@initargs)) Looks a lot like the expansion, right? That is really important in making macrology easy. Once one has mastered the syntax (` , @), writing a macro gets as natural as writing out the code. (In case you are wondering, in my little example I did not need any other customizations on the button, so it is hard to make out what the initargs are doign up there. here is how they would work (also getting a little fancier by actually disabling the Remove button, not just making it do nothing when pressed, if the gear count is zero): (mk-button-ex (Remove (decf (gear-ct .tkw))) :fore-color 'red ;; Tcl/Tk will understand :enabled (c? (plusp (gear-ct .tkw becomes: (make-instance 'button :fm-parent *parent* :text remove :on-command (c? (lambda (self) (decf (gear-ct .tkw :fore-color 'red :enabled (c? (plusp (gear-ct .tkw [ps. Do not try that at home, i invented the enabled thing. It really should be the Tk syntax, which I forget.] ie, I created mk-button-ex because, jeez, every button I put in a GUI I /know/ needs its own label and its own command (and the parent thing), but there are other options, too. They have to be supported if the macro is to get used all the time (we want that), but I do not want to make them positional arguments without identifying
Re: A critic of Guido's blog on Python's lambda
Lasse Rasinen wrote: Ken Tilton [EMAIL PROTECTED] writes: If you want to insist on how perfect your code is, please go find ltktest-cells-inside.lisp in the source you downloaded and read the long comment detailing the requirements I have identified for data integrity. Then (a) tell me how your code fails at integrity, (b) fix it, and (c) tell me again how easy Cells is. :) Found it and read it; it was most enlightening. I claim my system fulfills the first three requirements(*), while most likely failing gloriously on the two last ones. sigh From #1: recompute all and (for efficiency) only state computed off X (directly or indirectly through some intermediate datapoint) Bzzzt! Another 47hrs, directions from a mentor, and a reference implementation and you /still/ do not even understand the requirements, let alone have a working port. The good news is that it is not an integrity requirement that is being missed, it is the efficiency requirement I snuck in there. The bad news is, see below. Want to find the efficiency shortcoming yourself, or should I tell you? You are entitled to the latter given the rules of the game (simulating a pythonista student making off with five thousand undeserved dollars). :) I'll postpone (b) while I've had a chance to think it over(**), but in the face of the evidence I'm willing to admit my earlier work estimates (which should have had a smiley next to them anyway ;-) were in error. Aw, shucks, then I will admit that, before today, I never actually looked at your code. :) Well, I followed the URL and glanced at it, but I missed the use of the timestamp. Speaking of which, Holy Granularity, Batman! You use Time.time() to determine currency of a computation?!: time() Return the time as a floating point number expressed in seconds since the epoch, in UTC. Note that even though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second. One /second/?! Exactly how slow is Python? I know you guys love that issue as much as Lispniks. In un-compiled Lisp: CTK(4): (loop repeat 2 do (print (get-internal-real-time))) 464033837 464033837 And you have no idea how slow PRINT is. btw, I thought Python was portable. What is with the Time class and not all systems...? Check out the Lisp: (defun zoom () (loop with start = (get-internal-real-time) while (= start (get-internal-real-time)) count 1 into cities-destroyed finally (format t ~a cities destroyed in 1/~a of a second cities-destroyed internal-time-units-per-second))) internal-time-units-per-second is (from the standard): Constant Value: A positive integer, the magnitude of which is implementation-dependent. So we vary, too, but my Lisp has to tell me so I can normalize. Anyway, running that repeatedly I get pretty wild variation. My high score is: CTK(18): 11637 cities destroyed in 1/1000 of a second My low was under a thousand! I guess I have to wait until we cross a millisecond boundary: (defun zoom () (symbol-macrolet ((now (get-internal-real-time))) (loop with start = (loop for mid = now while (= mid now) finally (return now)) while (= start now) count 1 into cities-destroyed finally (format t ~a cities destroyed in 1/~a of a second cities-destroyed internal-time-units-per-second Ok, now I am consistently taking out about 11.5k Russian cities. And you need to fix your system. Just use a counter -- does Python have bignums? if not, you'll have to worry about wrapping. (the sound you hear is a project schedule slipping. g) I won't admit to destroying Moscow, though. See (*). Sorry, you actually /have/ violated the data integrity requirement. You confess below to missing this one: a corollary: should a client observer SETF a datapoint Y, all the above must happen with values current with not just X, but also with the value of Y /prior/ to the change to Y. Well, how can you claim integrity when some values do not get recalculated until the world has moved on to state N+2, if you will? State N+1 had the information that headed off the launch. Bye bye, Kremlin. The easiest way to construct such a scenario would be with an ephemeral cell. As you know... oops. Maybe you do not. Well, spreadsheets are kinda steady state in orientation. Given a world of other values, this is what my value should be. But what about events? You have been using your version of PyCells in real-world applications for a while... oops. No you have not. Well, when you start trying to handle events from an event loop, you will discover a need to model events. (Trust your mentor.) You need a slot that can be assigned normally, propagate according to the above rules and regulations, and then revert to a null state
Re: A critic of Guido's blog on Python's lambda
Lasse Rasinen wrote: Ken Tilton [EMAIL PROTECTED] writes: if any concepts have survived to the Python version. Since Python's object model is sufficiently different, the system is based on rules being defined per-class... That will be a total disaster for PyCells, if true. But I do not think it is. You just need a constructor that takes some slot initializers, and initialize the slots to one of: a normal value; an InputCell itself initialized with a starting value, if only nil; or a RuledCell itself initialized with a lambda. Hmm, just tried it: class A(cells.cellular): ... def __init__(self): ... self.a = cells.InputCell(10) ... self.b = cells.RuleCell(lambda self: self.a+1, self, None) a = A() a.a 10 a.b 11 So it does work out-of-the-box ;-) So why exactly did you say that the differences in the object model made it impossible? I was really stunned by that claim. And you sounded so confident. What went wrong there? It was trivial, right? How did you miss that? PyCells looks like it will be a project for SoC2006, so you may as well relax. You really want to start a SoC project on something that takes about two weeks ... You sound so confident. :) Do you know the deliverables? I know you do not know Cells. You say you looked at the code -- it does not show. I can also tell you have not done much serious programming, or you would know that twelve weeks is more like twelve minutes than three months. A new test suite, documentation (a first, there is none now), a full port of Cells in all their ten years of sophisticated evolution and variety (no, not your stupid pet trick), and as a demo project an entire cells-driven GUI, probably a port of my new Celtk (+ Cells Tk) work, all in a language without macros, without special variables, with a more modest OO system, and limited first class functions... oh, I think we'll keep him busy. :) Now since you are such a genius, maybe you can help with something. Trust me on this: this is one place where macros would be able to hide a ton of implementation wiring it does no one any good to look at, and actually turns into a maintenance nightmare whenever Cells might get revised. Is there any experiemntal macro package out there for Python? Maybe a preprocessor, at least? Or are there ways to actually hack Python to extend the syntax? My honest guess is that Cells will port readily to Python but leave everyone very interested in finding some way to hide implementation boilerplate. Got anything on that? kenny -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Ben wrote: Nothing you have described sounds that complicated, and you never come up with concrete objections to other peoples code (apart that it took 10 years to write in Lisp, so it must be really hard) Oh, now I have to spend an hour dissecting any code you people toss-off that does no more than pick the low-hanging fruit? I do not spend enough time on Usenet already? :) Why are you running a SoC project for PyCells... You do not even know what Cells are and have not taken the trouble to understand, so i will save my breath. Pythonistas will love PyCells, I promise. Please recall that it is not just me, there is a ton of prior and current art. if you dislike the language so much. There is a difference between disliking a language and thinking PyCells might end up persuading folks that macros and/or true lambda might be worth the trouble to extend the language. Try to think a little more precisely, OK? Thx. People who do like Python can implement it if they need it (which I haven't seen any good examples that they do) Please don't force a student to create a macro system just to port a system to Python, You are getting hysterical, sit down, breathe. I asked a question, because (unlike you) I can see where this is going. But as you say... There are already plenty of ways to hide complicated functionality, I know. And that is why the mentor is a Pythonista, not me. I made a simple inquiry as to the options available should Python have trouble hiding the wiring. just looking ahead a little (as are the student and mentor). Something wrong with thinking ahead a few moves? You on the other hand have made up your mind about something you admit you do not understand, have now ascribed to me a half dozen sentiments I do not hold, and are feeling absolutely miserable because you think this is a flamewar. No, we are just discussing language synatx and how it impacts language semantics, which has led inadvertently to a few of us starting an SoC project to put together a Python version of a very successful dataflow hack I did for Lisp. I use it every day, and it just plain makes me smile. I wrote more code than you can imagine Before Cells, and have now used them intensively and in more ways than you can imagince since. Even if the wiring cannot be hidden, the productivity win will be trememndous. Note that this translates ineluctably to programming will be more fun. Even you will love them. :) kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Ken Tilton wrote: Ben wrote: Nothing you have described sounds that complicated, and you never come up with concrete objections to other peoples code (apart that it took 10 years to write in Lisp, so it must be really hard) Oh, now I have to spend an hour dissecting any code you people toss-off that does no more than pick the low-hanging fruit? I do not spend enough time on Usenet already? :) I want to clarify something. I did look at the code. It was the same thing we had with Cells after four-five hours. Yet the author admitted he had looked at the Cells source, so he should have known he had not implemented, inter alia, synapses, kid-slotting, ephemerals, optional laziness, and worst of all he had omitted the data integrity mechanism encapsulated by with-integrity. In the next exchange we discover he missed the ability to author Python instances individually while mistakenly thinking it was impossible. Exactly how much time am I supposed to spend on someone not willing to spend enough time to understand Cells? I recognize, tho, a kindred spirit more interested in writing their own code than reading and understanding someone else's. :) You too are more eager to flame me over misperceived slights to The Sacred Python than in Python having a wicked cool constraints package, and I am wasting too much time on you. I recognize, tho, a fellow Usenet dlamewar enthusiast. :) kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Lasse Rasinen wrote: [I trimmed some of the newsgroups away; this mostly concerns Python and Lisp] Ken Tilton [EMAIL PROTECTED] writes: Lasse Rasinen wrote: Ken Tilton [EMAIL PROTECTED] writes: if any concepts have survived to the Python version. Since Python's object model is sufficiently different, the system is based on rules being defined per-class... That will be a total disaster for PyCells, if true. But I do not think it is. You just need a constructor that takes some slot initializers, and initialize the slots to one of: a normal value; an InputCell itself initialized with a starting value, if only nil; or a RuledCell itself initialized with a lambda. Hmm, just tried it: [snip example] So it does work out-of-the-box ;-) So why exactly did you say that the differences in the object model made it impossible? I was really stunned by that claim. And you sounded so confident. What went wrong there? It was trivial, right? How did you miss that? Simple: I didn't think to try that before you asked. I did not say the differences in the object model made it impossible, I said the system is based on rules defined per-class. Oh, please: Since Python's object model is sufficiently different, the system is based on rules being defined per-class. I also think(*) that while one would have the option to define per-instance rules, in a Python implementation one would structure the code so that common rules would be class-related,.. What has Python got to do with it? What you describing is the way every OO system other than a prototype-based system works. It is why OO failed to deliver on the Grail of object reuse: every time you need different behavior, you need a new subclass. Literal values only go so far in making instances authorable. But when an instance can have a rule with itself as an argument, and when instances exist in a runtime hierarchy navigable up and down such that rules have effectively global scope, yowza, now you have authorability, amd now you have object reuse. and the per-instance rules would be used less frequently, used only when you absolutely need them. You will see, but not until you have the capability. Then you will discover you absolutely need them all the time. GUIs are dynamic things, so you cannot just author a widget with a literal value, it has to be a rule sensitive to the state of other GUI elements and the model itself, which might be changing underfoot in response to I/O events. I happened to be discussing this just now over in comp.lang.tcl, comparing Cells with Actions, a kindred package motivated by this: Two large problems exist for developers of such user interfaces. One is the need to constantly synchronize the controls with the ever-changing state of the application or data. When no text is selected, for example, the cut and copy buttons should be disabled. Another problem is that as programs evolve over time it can become tedious and error prone to update the parts of the code that act upon these controls. Found here: http://www.tcl.tk/community/tcl2004/Papers/BryanOakley/oakley.pdf (*) Unfounded Gut Feeling(TM); if your project is successful, we can revisit this prediction in September ;-) No need for gut feelings. Anyone working in GUIs knows the problem (stated by Mr Oakley above) and many partial solutions exist, such as Tcl/Tk's builtin mechanisms for automatic state management. They called the company ActiveState for a reason, you know. :) One person did his homework. vasilsi margioulas sent me cells-gtk, a two-week marriage of cells and Gtk derived from my Cells-Tk effort. He was curious if Cells would be useful. he decided, yes. :) PyCells looks like it will be a project for SoC2006, so you may as well relax. You really want to start a SoC project on something that takes about two weeks ... You sound so confident. :) Indeed. Having reread the post I do think the tone was possibly a tad arrogant. However: A new test suite, documentation (a first, there is none now), a full port of Cells in all their ten years of sophisticated evolution and variety (no, not your stupid pet trick), and as a demo project an entire cells-driven GUI, probably a port of my new Celtk (+ Cells Tk) work, all in a language without macros, without special variables, with a more modest OO system, and limited first class functions... oh, I think we'll keep him busy. :) I did not know all this. The list above does sound like a full summer of work ;) I assumed that PyCells referred to the core dependency tracking module which (even now) does not sound like a such huge task, especially when one has the reference implementation ;-) I think the real problem here is that you have no idea how fast twelve weeks can go while programming. The hourly beep on my wristwatch sounds like a metronome. As for Cells being so damn easy, well, yeah, that is how we get sucked into these ten year projects
Re: A critic of Guido's blog on Python's lambda
Lasse Rasinen wrote: Ken Tilton [EMAIL PROTECTED] writes: ps. flaming aside, PyCells really would be amazingly good for Python. And so Google. (Now your job is on the line. g) k Here's something I wrote this week, mostly as a mental exercise ;-) It's fun, right? But what you have is a complete wreck. :) The whole code is available at http://www.iki.fi/~lrasinen/cells.py, I'll include a test example below. Feel free to flame away ;-) (As for background: I like CL better as a language, but I also like Python a lot. However, I was employed for 3 years as a developer and maintainer in a Python data mining application, so I'm more fluent in Python than CL.) The code is mostly based on Kenny's descriptions of Cells in the following messages: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] In addition, I have looked at the CL source code briefly, but I'm not sure if any concepts have survived to the Python version. Since Python's object model is sufficiently different, the system is based on rules being defined per-class... That will be a total disaster for PyCells, if true. But I do not think it is. You just need a constructor that takes some slot initializers, and initialize the slots to one of: a normal value; an InputCell itself initialized with a starting value, if only nil; or a RuledCell itself initialized with a lambda. Trust me, you lose a vast amount of power unless different instances of the same class can have different rules for the same slot. ... (however, if you define a rule by hand in the __init__ function, it'll work also. I think; haven't tested). I can possibly be persuaded to fix bugs in the code and/or to implement new features ;-) PyCells looks like it will be a project for SoC2006, so you may as well relax. But I understand if you want to keep going, it is great fun. btw, I have met more than a few people who had done something like Cells independently, and there are many full-blown similar implementations around. Mine is just the best. g Kidding, i do not really know, there are so many. Features: - Tracks changes to input cells dynamically (normal attributes are not tracked) Ha! All your rules depend on the input cell itself! How about A depends on B depends on C? :) - Callbacks for changes (see caveats) - Requires Python 2.4 for the decorator syntax (@stuff) - Should calculate a cell only once per change (haven't tested ;-) Quite hard to test deliberately, but it happens in nature. But it will not happen until you do A-B-C. Once you have /that/ working, make A the input, then have B and C both use A. But also have B use C, and jiggle things around until A happens to think it should update B first, then C. What happens is that B runs and uses C, but C has not been updated yet. C is inconsistent with A, but is being used to calculate a new value for B which does see the new value of A. Mismatch! B will get sorted out in a moment when C gets recalculated and tells B to calculate a second time, but meanwhile after the first recalculation of B the on-change callback for that got invoked, missiles were launched, and Moscow has been destroyed. Caveats: - The input cell callbacks are not called with the class instance as the first argument, while the rule cell callback are. This is mostly due to laziness. And unacceptable! have fun. :) kenny ps. In the getattr for any Cell-mediated slot, look to see if parent is non-nil. If so, set up a dependency. k -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Michele Simionato wrote: jayessay wrote: I was saying that you are mistaken in that pep-0343 could be used to implement dynamically scoped variables. That stands. Proof by counter example: from __future__ import with_statement import threading special = threading.local() def getvar(name): return getattr(special, name) def setvar(name, value): return setattr(special, name, value) class dynamically_scoped(object): def __init__(self, name, value): self.name = name self.value = value def __context__(self): return self def __enter__(self): self.orig_value = getvar(self.name) setvar(self.name, self.value) def __exit__(self, Exc, msg, tb): setvar(self.name, self.orig_value) if __name__ == '__main__': # test setvar(*x*, 1) print getvar(*x*) # = 1 with dynamically_scoped(*x*, 2): print getvar(*x*) # = 2 print getvar(*x*) # = 1 If you are not happy with this implementation, please clarify. Can you make it look a little more as if it were part of the language, or at least conceal the wiring better? I am especially bothered by the double-quotes and having to use setvar and getvar. In Common Lisp we would have: (defvar *x*) ;; makes it special (setf *x* 1) (print *x*) ;;- 1 (let ((*x* 2)) (print *x*)) ;; - 2 (print *x*) ;; - 1 kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Alexander Schmolck wrote: jayessay [EMAIL PROTECTED] writes: Michele Simionato [EMAIL PROTECTED] writes: I was interested in a proof of concept, to show that Python can emulate Lisp special variables with no big effort. OK, but the sort of proof of concept given here is something you can hack up in pretty much anything. Care to provide e.g. a java equivalent? I think the point is that, with the variable actually being just a string and with dedicated new explicit functions required as accessors, well, you could hack that up in any language with dictionaries. It is the beginnings of an interpreter, not Python itself even feigning special behavior. perhaps the way to go is to take the Common Lisp: (DEFVAR *x*) *x* = special_var(v=42) ;; I made this syntax up that could make for cleaner code: *x*.v = 1 print *x*.v - 1 (Can we hide the .v?) But there is still the problem of knowing when to revert a value to its prior binding when the scope of some WITH block is left. Of course that is what indentation is for in Python, so... is that extensible by application code? Or would this require Python internals work? kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Alexander Schmolck wrote: Ken Tilton [EMAIL PROTECTED] writes: In Common Lisp we would have: (defvar *x*) ;; makes it special (setf *x* 1) (print *x*) ;;- 1 (let ((*x* 2)) (print *x*)) ;; - 2 (print *x*) ;; - 1 You seem to think that conflating special variable binding and lexical variable binding is a feature and not a bug. What's your rationale? Transparency. That is where power comes from. I did the same things with Cells. Reading a slot with the usual Lisp reader method transparently creates a dependency on the variable. To change a variable and have it propagate throughout the datamodel, Just Change It. Exposed wiring means more work and agonizing refactoring. kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Alexander Schmolck wrote: Duane Rettig [EMAIL PROTECTED] writes: Alexander Schmolck [EMAIL PROTECTED] writes: Ken Tilton [EMAIL PROTECTED] writes: In Common Lisp we would have: (defvar *x*) ;; makes it special (setf *x* 1) (print *x*) ;;- 1 (let ((*x* 2)) (print *x*)) ;; - 2 (print *x*) ;; - 1 You seem to think that conflating special variable binding and lexical variable binding is a feature and not a bug. What's your rationale? I will expand on my earlier transparency rationale with a further rationale for transparency: I do not need no stinkin' rationale. A special variable is still a variable. They should be set, read, and bound (say, by let) the same way as any other variable. You need a rationale. It sounds as if you want some noisey syntax to advertise the specialness. I do not think the Python community will appreciate you messing up their pretty code. You are right about one thing: specialness needs advertising. You know what we do in Lisp? We obediently name special variables with bracketing *s, like *this*. Too simple? A bug is a non-conformance to spec. There is a world beyond specs, you know. If copies of allegro CL accidently sent out death-threats to the US president on a weekly basis, because someone at franz accidently or purposefully left in some pranky debugging code the fact that this behaviour would likely neither violate the ansi spec nor any other specs that ACL officially purports to adhere to wouldn't make it any less of a bug (or help to pacify your customers). Kenny's statement was specifically about Common Lisp No Kenny's statement was about contrasting the way something is done in python and the way something is done in common lisp (with the implication that the latter is preferable). Close, but no. The question I was weighing in was has Michele replicated special variables?. My implication was, Not yet -- can you match the transparency?, and it was an honest question, I do not know. Again, transparency is a qualitative difference. I liked your solution better, btw, because it does minimize the noise. For fun, you should call the class ** instead of special, so we end up with:**.b = 42 We'll understand. :) Of course the way something is done in common lisp is almost tautologically in closer agreement with the ansi common lisp spec than the way it is done in python, so agreement with the clhs is not a useful criterion when talking about design features and misfeatures when contrasting languages. Again, no, it is not the spec, it is the highly-valued Python quality of clean code. Also, the consistency of treating variables as variables, regardless of some special/dynamic quality. Some background. Lisp is a big language, and I am self taught and do not like to read, grew up in Lisp in isolation. Not many Lispers in the exercise yard. Discovered special variables only when we hired an old hand who gently corrected a howler: (let* ((old-x *x*)) (setf *x* 42) (setf *x* old-x)) I still laugh at that. Anyway, as soon as I learned that, I was able to make Cells syntax infinitely more transparent. And guess what? It also made dependency identification automatic instead of cooperative, and when I rebuilt a huge Cells-based app I discovered two or three cases where I had neglected to publish a dependency. It's a mystery, but somehow simpler syntax... oh, wait, this is c.l.python, I am preaching to the choir. I just don't think the way special variable binding (or variable binding in general[1]) is handled in common lisp is particularly well designed or elegant. See above. There is nothing like a concrete experience of implementing a hairy library like Cells /without/ leveraging specials and then converting to specials. Talk about an Aha! experience. I mean, bugs ran screaming from their nests simply because of the implementation change-- we call that A Message From God that the design has taken a correct turn. Special variables and lexical variables have different semantics and using convention and abusing[2] the declaration mechanism to differentiate between special and lexical variables doesn't strike me as a great idea. I know what you mean, but I like reading tea leaves, and I find it fascinating that *this* somehow eliminates all ambiguity. Background: don't know where I might find it, but I once saw a thread demonstrating the astonishing confusion one could create with a special variable such as a plain X (no *s). Absolutely mind-bogglingly confusing. Go back and rename the special version *x*, and use *x* where you want to rebind it. Result? Utterly lucid code. Scary, right? I can certainly think of problems that can occur because of it (E.g. ignoring or messing up a special declaration somewhere; setf on a non-declared variable anyone? Sh*t, you don't respond to compiler warnings? Don't blame CL for your
Re: A critic of Guido's blog on Python's lambda
Paul Rubin wrote: Alexander Schmolck [EMAIL PROTECTED] writes: (defvar *x*) ;; makes it special (setf *x* 1) (print *x*) ;;- 1 (let ((*x* 2)) (print *x*)) ;; - 2 (print *x*) ;; - 1 You seem to think that conflating special variable binding and lexical variable binding is a feature and not a bug. What's your rationale? I thought special variables meant dynamic binding, i.e. (defvar *x* 1) (defun f () (print *x*) ;; - 2 (let ((*x* 3)) (g))) (defun g () (print *x*)) ;; - 3 That was normal behavior in most Lisps before Scheme popularlized lexical binding. IMO it was mostly an implementation convenience hack since it was implemented with a very efficient shallow binding cell. That Common Lisp adapted Scheme's lexical bindings was considered a big sign of CL's couthness. So I'm a little confused about what Ken Tilton is getting at. Paul, there is no conflict between your example and mine, but I can see why you think mine does not demonstrate dynamic binding: I did not demonstrate the binding applying across a function call. What might be even more entertaining would be a nested dynamic binding with the same function called at different levels and before and after each binding. I just had the sense that this chat was between folks who fully grokked special vars. Sorr if I threw you a curve. kenny -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Everything else responded to separately, but... I'd like to see a demonstration that using the same binding syntax for special and lexical variables buys you something apart from bugs. Buys me something? Why do I have to sell simplicity, transparency, and clean syntax on c.l.python? kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
sross wrote: I do wonder what would happen to Cells if I ever want to support multiple threads. Or in a parallel processing environment. AFAIK It should be fine. In LW, SBCL and ACL all bindings of dynamic variables are thread-local. Ah, I was guilty of making an unspoken segue: the problem is not with the *dependent* special variable, but with the sequentially growing numeric *datapulse-id* (the ID) that tells a cell if it needs to recompute its value. The ID is not dynamically bound. If threads T1 and T2 each execute a toplevel, imperative assignment, two threads will start propagating change up the same dependency graph... shudder Might need to specify a main thread that gets to play with Cells and restrict other threads to intense computations but no Cells? Actually, I got along quite a while without an ID, I just propagated to dependents and ran rules. This led sometimes to a rule running twice for one change and transiently taking on a garbage value, when the dependency graph of a Cell had two paths back to some changed Cell. Well, Cells have always been reengineered in the face of actual use cases, because I am not really smart enough to work these things out in the abstract. Or too lazy or something. Probably all three. kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Boris Borcic wrote: Ken Tilton wrote: Now if you are like most people, you think that means X. It does not. As far as natural language and understanding are concerned, to mean means conformity to what most people understand, Humpty Dumpties notwithstanding. Nonsense. You are confusing that quality of natural language with most people's quality of being sloppy readers, or in your case, a sloppy thinker. Misapplying an analogy is not a question of usage -- when I said spreadsheet and they thought of spreadsheets, so far so good, right? -- it just sloppiness and laziness. I do it, too, all the time. :) Life is too short, we get by precisely by using partial information. You remind me of American educators recent (past several decades, that is) history of apologizing for asking students to work and softening the curriculum until they all get A's. Here is another analogy. Sometimes people hit the gas and think they hit the brake pedal. They crash around a parking lot pushing the gas pedal down harder and harder. Did they take out the brake pedal to avoid that confusion? No, they put an interlock between the brake and the ignition key. Same thing. :) kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Boris Borcic wrote: Bill Atkins wrote: 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. Not even efficiency of debugging ? A real problem with macros is that run-time tracebacks etc, list macro outputs and not your macro'ed source code. And that becomes an acute problem if you leave code for somebody else to update. Or did lisp IDEs make progress on that front ? AllegroCL now shows macros in the stack frame. Relatively recent feature, and their IDE really stands out above the rest. kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
[Sorry, I missed this one originally.] David C. Ullrich wrote: On Tue, 09 May 2006 05:35:47 -0500, David C. Ullrich [EMAIL PROTECTED] wrote: On Mon, 08 May 2006 18:46:57 -0400, Ken Tilton [EMAIL PROTECTED] wrote: [...] If you, um, look at the code you see that cells.a = 42 triggers cells.__setattr__, which fires a's callback; the callback then reaches inside and sets the value of b _without_ going through __setattr__, hence without triggering b's callback. In Cells you can't have A depend on B and also B depend on A? That seems like an unfortunate restriction - I'd want to be able to have Celsius and Farenheit, so that setting either one sets the other. Set Kelvin, and make Celsius and Fahrneheit functions of that. ie, There is only one datapoint, the temperature. No conflict unless one creates one. Realized later that I hadn't thought this through. I'd been assuming that of course we should be allowed to have A and B depend on each other. Hence if a change in A propagates to a change in B that change in B has to be a non-propagating change - thought I was just so clever seeing a way to do that. I think it could be arranged, if one were willing to tolerate a little fuzziness: no, there would be no strictly correct snapshot at which point everyone had their right value. Instead, A changes so B recomputes, B changes so A recomputes... our model has now come to life, we just have to poll for OS events or socket data, and A and B never get to a point where they are self-consistent, because one or the other always needs to be recalculated. I sometimes wonder if the physical universe is like that, explaining why gravity slows time: it is not the gravity, it is the mass and we are seeing system degradation as the matrix gets bogged down recomputing all that matter. [Cue Xah] But duh, if that's how things are then we can't have transitive dependencies working out right; surely we want to be able to have B depend on A and then C depend on B... (And also if A and B are allowed to depend on each other then the programmer has to ensure that the two rules are inverses of each other, which seems like a bad constraint in general, something non-trivial that the programmer has to get right.) Right, when I considered multi-way dependencies I realized I would have to figure out some new syntax to declare in one place the rules for two slots, and that would be weird because in Cells it is the instance that gets a rule at make-instance time, so i would really have to have some new make-instance-pair capability. Talk about a slippery slope. IMO, the big constraints research program kicked off by Steele's thesis withered into a niche technology because they sniffed at the trivial spreadsheet model of linear dataflow and tried to do partial and multi-way dependencies. I call it a bridge too far, and in my experience of Cells (ten years of pretty intense use), guess what?, all we need as developers is one-way, linear, fully-specified dependencies. So fine, no loops. If anything, if we know that there are no loops in the dependencies that simplifies the rest of the programming, no need for the sort of finagling described in the first paragraph above. Actually, I do allow an on-change callback (observer in Cells parlance) to kick off a toplevel, imperative state change to the model. Two cells who do that to each other will run until one decides not to do so. I solve some GUI situations (the classic being a scrollbar thumb and the text offset, which each at different times control the other, by having them simply set the other in an observer. On the second iteration, B is setting A to the value A has already, so propagation stops (a longstanding Cells feature). These feel like GOTOs, by the way, and are definitely to be avoided because they break the declarative paradigm of Cells in which I can always look at one (anonymous!) rule and see without question from where any value it might hold comes. (And observers define where they take effect outside the model, but those I have to track down by slot name using OO browsing tools.) But this raises a question: Q: How do we ensure there are no loops in the dependencies? Elsewhere I suggested the code was: (let ((*dependent* this-cell)) (funcall (rule this-cell) (object this-cell))) It is actually: (let ((*dependents* (list* this-cell *dependents*))) (funcall (rule this-cell) (object this-cell))) So /before/ that I can say: (assert (not (find this-cell *dependents*))) Do we actually run the whole graph through some algorithm to verify there are no loops? The simplest solution seems like adding the cells one at a time, and only allowing a cell to depend on previously added cells. It's clear that that would prevent loops, but it's not clear to me whether or not that disallows some non-looping graphs. As you can see, the looping is detected only when
Re: A critic of Guido's blog on Python's lambda
Chris F Clark wrote: David C Ullrich asked: Q: How do we ensure there are no loops in the dependencies? Do we actually run the whole graph through some algorithm to verify there are no loops? The question you are asking is the dependency graph a directed acyclic graph (commonly called a DAG)? One algorithm to determine if it is, is called topological sort. That algorithm tells you where there are cyclces in your graph, Yep. But with Cells the dependency graph is just a shifting record of who asked who, shifting because all of a sudden some outlier data will enter the system and a rule will branch to code for the first time, and suddenly depend on on some new other cell (new as in never before used by this cell). This is not subject to static analysis because, in fact, lexically everyone can get to everything else, what with closures, first-class functions, runtime branching we cannot predict... fuggedaboutit. So we cannot say, OK, here is the graph of our application model. All we can do is let her rip and cross our fingers. :) kenny -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Ketil Malde wrote: Sometimes the best documentation is the code itself. Sometimes the best name for a function is the code itself. Absolutely. When I take over someone else's code I begin by deleting all the comments. Then I read the code. If a variable or function name makes no sense (once I have figured out what they /really/ do) I do a global change. Pretty soon the system is documented. And I usually find a couple of bugs as the renaming produces things like: count = count + weight I think one good argument for anonymous functions is a hefty Cells application, with literally hundreds of rules. The context is set by the instance and slot name, and as you say, the rule speaks for itself: (make-instance 'frame-widget :bounds (c? (apply 'rect-union (all-bounds (subwidgets self) Why do I have to give that a name? And if the algorithm gets hairier, well, why is the reader looking at my code? If the reader is debugging or intending to modify the rule, they damn well better be looking at the code, not the name and not the comments. (Never a problem with my code. g) kenny -- Cells: http://common-lisp.net/project/cells/ Have you ever been in a relationship? Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems. -- http://mail.python.org/mailman/listinfo/python-list
