Re: merits of Lisp vs Python
On Tue, 12 Dec 2006 16:35:48 +1300, greg wrote: > When a Lisp compiler sees > >(setq c (+ a b)) > > it can reasonably infer that the + is the built-in numeric > addition operator. But a Python compiler seeing > >c = a + b > > can't tell *anything* about what the + means without > knowing the types of a and b. They might be numbers, or > strings, or lists, or some user-defined class with its > own definition of addition. That may be true, but lisp's numeric addition operator knows how to add fixnums, bignums, rationals and whatever the lisp name for floating points is (imprecise?) -- something that not many (if any) processor instruction sets can manage. So that's still type-dependent dispatch, which isn't going to get us to the speeds that we actually see reported unless there's extra stuff going on. Type inference? Declarations? Cheers, -- Andrew -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
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? It's for output to a human, isn't it? It's not as though it needs to be particularly fast? Maybe I'm just not digging the example sufficiently. That's likely: I've yet to write my first lisp program... Cheers, -- Andrew -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
On Thu, 14 Dec 2006 04:06:26 -0500, Ken Tilton wrote: > Ken Tilton wrote: >> Andrew Reilly wrote: >>> 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. Please pardon my woeful grasp of lisp: that's probably why I'm off-beam here. It seemed to me that the bulk of your macro-ified/templated version was taking some text and a "reverse" operation and creating the methods of an object, or generic functions or ?? Each skill seems to have a title, a list of annotations, and a list of hints (and a reverse, which I don't understand). That all looks like data. Couldn't you do that with a table containing those fields, and key it off the defskill argument (or even the title?) at startup? 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. 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. I didn't expect that "42" was necessarily the right answer... 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, 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. When one finds that one *does* care about performance, that doesn't leave much wriggle room, though... -- Andrew -- http://mail.python.org/mailman/listinfo/python-list
Re: The Importance of Terminology's Quality
On Thu, 21 Aug 2008 02:36:39 +, sln wrote: >>Whats os interresting about all this hullabaloo is that nobody has coded >>machine code here, and know's squat about it. >> >>I'm not talking assembly language. Don't you know that there are >>routines that program machine code? Yes, burned in, bitwise encodings >>that enable machine instructions? Nothing below that. >> >>There is nobody here, who ever visited/replied with any thought >>relavence that can be brought foward to any degree, meaning anything, >>nobody >> >>sln > > At most, your trying to validate you understanding. But you don't pose > questions, you pose terse inflamatory declarations. > > You make me sick! Could you elaborate a little on what it is that you're upset about? I suspect that there are probably quite a few readers of these posts that have designed and built their own processors, and coded them in their own machine language. I have, and that was before FPGAs started to make that exercise quite commonplace. But I don't see how that's at all relevant to the debate about the power or other characteristics of programming languages. Certainly anyone who's programmed a machine in assembly language has a pretty fair understanding of what the machine and the machine language is doing, even though they don't choose to bang the bits together manually. Hope you get better. -- Andrew -- http://mail.python.org/mailman/listinfo/python-list
Re: If Scheme is so good why MIT drops it?
On Sun, 26 Jul 2009 09:31:06 -0400, Raffael Cavallaro wrote: > On 2009-07-26 09:16:39 -0400, a...@pythoncraft.com (Aahz) said: > >> There are plenty of expert C++ >> programmers who switched to Python; > > "plenty" is an absolute term, not a relative term. I sincerely doubt > that the majority of python users were formerly *expert* C++ > programmers. > >> your thesis only applies to the >> legions of people who found it difficult to learn C++ in the first >> place. > > No, my thesis applies to the overwhelming majority of programmers who > found it more difficult to *master* (i.e., not merely use) C++ as > opposed to mastering python. BTW, this is a *complement* not a dis; > python is a better language than C++ precisely because it is more > sensibly and elegantly designed than C++ and therefore easier to master. Isn't it widely accepted that the number of people who have mastered C++ is about five? All of the rest of us just struggle... [I know enough of C++ to avoid it whenever I can, and to not use it for my own projects. I'm happy with a mix of C, python and lisp(or scheme).] -- Andrew -- http://mail.python.org/mailman/listinfo/python-list
