merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:

>> something like:
>> 
>>   control_code = connection.read_next_control_code()
>>   if control_code == +break+:
>>     connection.kill()
>>     throw blah
>>   else if control_code == +status+:
>>     connection.send_status_summary()
>>   else if control_code == +noop+ || control_code == +keep_alive+:
>>   else:
>>     error "CONTROL_CODE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"
>
> Your Python syntax is rather wonky, but that's incidental.

What is wonky about it?  The use of +foo+ symbols from the Lisp?  Is
there some particular bit of wonkiness you can point out that will
make me think you've done anything but intentionally misunderstand my
post?

> Nine lines, including handling the case where control_code is none of the
> four constants. Ten if you add the "pass" statement that it actually
> needs. And it is completely self-contained, with no external functions or
> macros to understand.
>
> Saving one line of code, at the expense of having another block of code to
> write or understand -- is that really the best example of what macros are
> used for in practice? You don't really save writing any boilerplate code,
> except for else clause, unless you're claiming that "if" and "elif" is
> boilerplate. Fine, you claim them as boilerplate. I'm going to claim all
> those unnecessary brackets as boilerplate.

We're not counting lines here, you goon.  We're talking about how
expressive constructs are and how closely they match your concept of
what you want to do.  The conditional example is lower-level; you're
talking to the interpreter instead of saying what you want to achieve.
You're having to repeat things because that's what the language asks
of you, instead of describing in a higher-level way what you're
actually doing.

> Yes, I know the parser needs them. But as so many people keep telling me,
> once you've been writing Lisp code for a month, you don't even notice the
> brackets. That makes them unnecessary for the developer, and therefore
> something the computer should handle on its own. You've already split
> expressions with whitespace, why should you have to use brackets as well?
> That's just boilerplate.

This simply means that the parentheses do not stand out.  It doesn't
mean that they *literally* cease to become visible (unless I have
perhaps missed out on Lisp enlightenment).

Obviously, this doesn't mean that they are "unnecessary."  They are
necessary to give Lisp its regular structure, which 1) makes macros
possible, 2) allows easy movement through and automatic indentation of
code and 3) is aesthetically pleasant, which leads to easier
maintenance.  Brackets are no more boilerplate than the significant
whitespace in Python is boilerplate (that is, they're not boilerplate
at all).

> Okay, I'm impressed that ecase can pick up on the four constants being
> tested against, and feed their names (rather than merely their values)
> into an error message. Python has nothing like that, and if you only have
> three or four things to test against, *and* they have names, that could be
> a useful thing to do. And if I've understood correctly, that's more a
> feature of Lisp's symbols than of macros.

But you haven't understood it correctly, of course.  The only reason
this works is that the macro is passed the unevaluated code, which
still has the original symbols that the programmer used.  It can
insert these into the generated code as it pleases.  I feel that
should be clear to someone who claims to know as much Lisp as you do.

> But if you're testing against fifty different values, well, is it really
> useful for your error message to list all fifty names? Or do you have
> another macro ecase-with-lots-of-tests?

Is it really useful?  Yes, it is.

> If that's the best example of what macros can be used for, frankly I'm
> unimpressed. Yes, I can see some benefit. But I don't see that the benefit
> is worth the added complexity. Maybe there are more complex tasks that
> macros are better suited for. 

Did you read the DEFINE-BINARY-CLASS macro I mentioned elsewhere?
Where did you get the notion that ECASE was the best example of where
macros can be used?  Why am I responding to another of your absurd
posts?