Re: Sweeter Emacs Lisp

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

>>      (defun tag-desc-stripped (tag)
>>        (upcase (replace-regexp-in-string "[<\\/> ]" "" (car tag))))
>>
>> hard to read,
>
> This is still a trivial example. And no, now I don't, having spent a
> couple of years or so writing Elisp. But I still remember that reading
> functions "from inside out" was one of the harder parts,

I've never understood what people mean by "reading from the inside out".
In C, that statement would have been

upcase(replace_regexp_in_string("[<\\/> ]", "", car(tag)));

Of course, if you've only programmed dotted languages like Java, you may
have a problem.  (That goes without saying in any context, though.)

> especially with the level of nesting that one can often observe in
> core Emacs packages.

There's a cultural element, though.  C people have a tendency to assign
values to variables more, so you get a more imperative style.
(Especially since you have to do a lot of manual memory management
stuff, often.)

> Here are some appreciative opinions with better examples:
>
> http://blog.8thlight.com/colin-jones/2011/03/27/clojure-mad-science-an-evil-threading-macro-experiment.html

Yeah. that's pretty much incomprehensible and confirms my prejudices
against the taste level of the Clojure people.  Are you sure they
haven't managed to squeeze monads into the language, too?  For extra
academic brownie points?

> Incidentally, Clojure has a shorter reader macro for anonymous
> functions. Yours would look like this:
>
>   #(replace-regexp-in-string "[<\\/> ]" "" %)

*barf*

I love how Emacs Lisp (and Common Lisp) eschew all these syntactical
tricks.  They have dead simple syntaxes, and makes reading code clear
and easy.  You get constructs that are unambiguous and general, even
though they're somewhat longer than Perly stuff like the above.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/