merits of Lisp vs Python

[Chris Mellon]

On 12/14/06, Ken Tilton <kentilton at gmail.com> wrote:
>
>
> 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
>

I think this specific sub-thread is a great example of what a lot of
people roll their eyes about when Lispers start talking, and it's a
great contrast to the foot stomping earlier where all the Lispers were
swearing that macros didn't complicate anything.

You start out with a fairly simple task, and use a macro instead of a
function even though you don't need to. That's "Arguments against LISP
101" right there. Then, you're (by your own indication - I find the
lisp code unreadably idiomatic) overly clever and spend several
iterations walking around in circles making your macro more clever,
rather than fixing your problem (spending too much time creating
clever genericness is a trap I'm sure many programmers have fallen in,
I've done it myself, but I have a feeling that Lispers are more
susceptible than most).

You finally have your macro doing all the cleverness you need, and
(again by your own account, I can't judge the code on any merit other
than "this looks like garbage to me") it's getting nasty and
contrived.

So you went from "look how simple and powerful this macro is", in a
trivial case that didn't even need a macro to "well, it's ugly and
nasty and idiomatic, but look how powerful this macro is!". This is
exactly the sort of thing that I (and, in my experience, many Python
programmers) strive to avoid in our work, and the readability and
clarity (more than simple character counts) of Python is a tool that
helps me achieve this goal.

I'd produce an equivalent Python version, but since you're totally
unclear in why you're adding these changes, and I can't read the lisp
well enough to see what it's doing, you're going to have to back up a
few steps if you want a Python implementation of your final solution.
I expect, however, that I wouldn't use a function at all = I'd make it
a data driven solution, because it (seems to be) a data oriented
problem.

> --
> 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
>