merits of Lisp vs Python

[Ken Tilton]

Re: merits of Lisp vs Python



Ken Tilton wrote:

>
>
Paul Rubin wrote:
>

>Ken Tilton <kentilton@gmai l.comwrites:
>>

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

[Paul Rubin]

Re: merits of Lisp vs Python

Ken Tilton <kentilton@gmai l.comwrites:

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. There's no need to invent and program all that new syntax
when Python's existing syntax does the job perfectly well.

I don't know, perhaps the best argument against macros is that no
Pythonista wants them. That is actually a damn good reason.

I've wanted macros from time to time, but this isn't a situation that
calls for them. They're just less important in Python than in Lisp.
Python already has enough syntax to not constantly need new syntax
extensions.

[Ken Tilton]

Re: merits of Lisp vs Python



Paul Rubin wrote:

Ken Tilton <kentilton@gmai l.comwrites:
>

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

[Paul Rubin]

Re: merits of Lisp vs Python

Ken Tilton <kentilton@gmai l.comwrites:

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. Python
function defs are lightweight enough that I don't experience a big pain
from using an extra one for a thing like that.

[Ken Tilton]

Re: merits of Lisp vs Python



Ken Tilton wrote:

>
>
Ken Tilton wrote:
>

>>
>>
>Paul Rubin wrote:
>>

>>Ken Tilton <kentilton@gmai l.comwrites:
>>>
>>>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 my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

[Ken Tilton]

Re: merits of Lisp vs Python



Paul Rubin wrote:

Ken Tilton <kentilton@gmai l.comwrites:
>

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

[Ken Tilton]

Re: merits of Lisp vs Python



Paul Rubin wrote:

Ken Tilton <kentilton@gmai l.comwrites:
>

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

[jurgen_defurne]

Re: merits of Lisp vs Python


Ken Tilton wrote:

George Sakkis wrote:

JShrager@gmail. com 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
>compositionali ty 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_GB&word1=lamborghini&word2=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

Well, Cobol still has the largest and most easy to comprehend system
for doing decimal arithmetic.

Jurgen

[Andrew Reilly]

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

[Ken Tilton]

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

[Paul Rubin]

Re: merits of Lisp vs Python

Ken Tilton <kentilton@gmai l.comwrites:

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.

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.

[Ken Tilton]

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
>interpolatio n 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] "Interpolat ion" 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

[David Golden]

Re: merits of Lisp vs Python

William James wrote:

Actually, it's 'among', not 'amongst', except to those who are
lisping, degenerate pansies.
>

lisping: "amongst" ="amongthpt" ?

"amongst" is a fairly common british english variant of "among".

Some pronunciations and usages "froze" when they reached the
>  American shore. In certain respects, American English is closer to
>  the English of Shakespeare than modern British English is.

In certain respects, modern British English is closer to the
English of Shakespeare than American English is.

In this particular case, in Shakespeare's actual time, we can be pretty
sure ([1],[2]) that "parenthesi s" meant the inserted parenthetical
phrase.

I do admit that since the later extension to round brackets themselves
is mentioned at link [2] below (and OED) as first appearing in 1715,
and given your later british examples, I was Just Wrong to lay sole
blame on the americans for it.


[1]
The Arte of English Poesie by George Puttenham, 1589

http://www.gutenberg.org/etext/16420

Chap. XIII
"""
[Sidenote: _Parenthesis_, or the Insertour]
Your first figure of tollerable disorder is [_Parenthesis_] or by an
English name the [_Insertour_] and is when ye will seeme for larger
information or some other purpose, to peece or graffe in the middest of
your tale an vnnecessary parcell of speach, which neuerthelesse may be
thence without any detriment to the rest. The figure is so common that
it
needeth none example, neuerthelesse because we are to teache Ladies and
Gentlewomen to know their schoole points and termes appertaining to the
Art, we may not refuse ro yeeld examples euen in the plainest cases, as
that of maister _Diars_ very aptly.
_But now my Deere_ (_for so my loue makes me to call you still_)
_That loue I say, that lucklesse loue, that works me all this ill._

Also in our Eglogue intituled _Elpine_, which we made being but eightene
yeares old, to king _Edward_ the sixt a Prince of great hope, we
surmised
that the Pilot of a ship answering the King, being inquisitiue and
desirous to know all the parts of the ship and tackle, what they were, &
to what vse they serued, vsing this insertion or Parenthesis.
_Soueraigne Lord (for why a greater name
To one on earth no mortall tongue can frame
No statelie stile can giue the practisd penne:
To one on earth conuersant among men.)_

And so proceedes to answere the kings question?
_The shippe thou seest sayling in sea so large, &c._

This insertion is very long and vtterly impertinent to the principall
matter, and makes a great gappe in the tale, neuerthelesse is no
disgrace
but rather a bewtie and to very good purpose, but you must not vse such
insertions often nor to thick, nor those that bee very long as this of
ours, for it will breede great confusion to haue the tale so much
interrupted.

"""

[2] http://www.etymonline.com/index.php?term=parenthesis
[3] http://rhetoric.byu.edu/Figures/P/parenthesis.htm

[josephoswaldgg@hotmail.com]

Re: merits of Lisp vs Python


Neil Cerutti wrote:

On 2006-12-13, josephoswaldgg@ hotmail.com
<josephoswald@g mail.comwrote:

Try reading again. In Lisp, you use () and *your editor*
automatically indents according to the universal standard, or
you leave it sloppy until other folks reading your code
convince you to get a proper programming editor. Indentation
does not get out of sync with semantics because the editor
virtually never misses parentheses that the Lisp compiler sees.
Expressions keep the same meaning even if you have to start
breaking them across lines, etc.

>
Yes, it's the same way in Python. Of course, not everything is an
expression in Python, so it's not saying quite as much.

I fail to see how it is the same in Python. I go into a Lisp buffer
white-space area, and press <Taband absolutely nothing changes about
my program. There are two reasons for this: I am using a dumb editor
that puts a Tab in that my compiler doesn't care about, or I am using
the moral equivalent of Emacs, which reads <Tabas "put this line on
the standard Lisp indentation level, as determined by the
non-whitespace characters in the area."

In Python, I hit that <Taband the smartest editor in the world would
have to say "Oh, you want to put this line on a different indentation
level, possibly including this line as part of the if: consequences
block above. Hope that helps!"

In Python, you group in your mind, and press indentation keys
to make it happen in your editor. The editor cannot help that
much, because it cannot read your mind. White space screwups in
copy-paste cannot be fixed by the editor automatically, because
it cannot read the original programmer's mind, and you have to
fix it manually, and risk screwing it up.

>
It is very easy a manual process, possibly as simple as selecting
the correct s-expr and pasting it into the right place in your
code.

How does a manual correction process come out as simple as "don't
bother fixing the indentation if you don't care."?

This is exactly the questionable math that I was questioning in the
original post.

[Andrew Reilly]

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
>>interpolati on 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] "Interpolat ion" 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