What's better about Ruby than Python?

[Andrew Dalke]

Kenny Tilton
> C? does something similar to what you think, but at with an order of
> magnitude more power. Estimated. :) Here is how C? can be used:
>
> [.. some lisp example ...]

You have got to stop assuming that a description in Lisp is
intuitive to me.  I don't know anywhere near enough of that
language to know what's normal vs. what's novel.

> So I do not have to drop out of the work at hand to put /somewhere else/
> a top-level function which also caches,

Didn't you have to "drop out of the work at hand" to make the macro?

I tried to understand the lisp but got lost with all the 'defun' vs
'function' vs 'funcall' vs 'defmodel' vs 'defclass' vs 'destructuring-bind'
I know Lisp is a very nuanced language.  I just don't understand
all the subtleties.  (And since Python works for what I do, I
don't really see the need to understand those nuances.)

> Cool. But call cachedCall "memoize". :) Maybe the difference is that you
> are cacheing a specific computation of 3, while my macro in a sense
> caches the computation of arbitrary code by writing the necessary
> plumbing at compile time, so I do not have to drop my train of thought
> (and scatter my code all over the place).

Sure, I'll call it memoize, but I don't see what that's to be prefered.
The code caches the result of calling a given function, which could
compute 3 or could compute bessel functions or could compute
anything else.   I don't see how that's any different than what your
code does.

And I still don't see how your macro solution affects the train
of thought any less than my class-based one.

> That is where Lisp macros step up--they are just one way code is treated
> as data, albeit at compile time instead of the usual runtime
consideration.

The distinction between run-time and compile time use of code is
rarely important to me.  Suppose the hardware was 'infinitely' fast
(that is, fast enough that whatever you coded could be done in
within your deadline).  On that machine, there's little need for
the extra efficiencies of code transformation at compile time.  But
there still is a need for human readablity, maintainability, and code
sharing.

And for most tasks these days, computers are fast enough.

                    Andrew
                    dalke at dalkescientific.com