The author wrote „Higher Order Perl“ which — to my knowledge — is one of the best books on programming ever written. While it’s got Perl in its title it is really an exhaustive introduction to the functional programming paradigm while being refreshingly non-academic about the subject. BTW: In general, I think there were many great Perl book authors having written very insightful introductory text books. They were mostly fun too read and taught me more about computer science than most computer science text books I had access too.
> A few years ago I gave a conference talk in which I asserted that the
C++ macro system blows goat dick. This remark has since become
somewhat notorious, and the C++ fans hate me for it. But I did not
think at the time that this would be controversial. I was sure that
even the most rabid C++ fans would agree with me that the C++ macro
system blows goat dick, for the reasons I have just described.<p>A voice from a simpler time. Had me laughing.
Worth looking at e.g. <a href="http://p3rl.org/Keyword::Declare" rel="nofollow">http://p3rl.org/Keyword::Declare</a> for perlish macros<p>mjd rocks but 2005 was before I made custom keywords in perl "work" on CPAN, and even further before people who were competent to do so obsoleted my horrific proof of concept hack with perl core features in 5.14/5.16 - which have since allowed many cool things such as <a href="http://p3rl.org/Future::AsyncAwait" rel="nofollow">http://p3rl.org/Future::AsyncAwait</a><p>Lisp macros are, of course, still cool, and this is why I got into this sort of hackery in the first place.
I'd like to point out that the strange occurrences of the "=3D" string are due to the fact that the message was originally a "quoted-printable" encoded email and for whatever reason this artifact wasn't removed when posted to the web. Perhaps this was pipermail's fault?<p>Anyway, when reading the code, you're safe in assuming "=3D" is just a single plain old equal sign. In the "quoted-printable" encoding scheme the two characters following an equal sign are the hex value of the intended character. In effect, equal signs need to be escaped using the "=3D" sequence.<p>This drove me a little nuts as I was reading and trying to code switch between the assorted languages used in the examples.
The key line is “In Lisp, source filters never break.”<p>On a related note, <a href="https://www.youtube.com/watch?v=e1T7WbKox6s" rel="nofollow">https://www.youtube.com/watch?v=e1T7WbKox6s</a> is very much worth watching.
Lisp macros are really cool. Programming is not satisfying to me without a similar feature.<p>But, most people are happy with just typing and copy pasting stuff around. They don't care. I've shown them before and after macro refactoring code comparisons and they just stare blankly, they don't see the point.<p>They code stuff like this on a daily basis:<p><pre><code> Var stuff() As Stuff
stuff.Add(New Stuff("foo"))
stuff.Add(New Stuff("bar"))
stuff.Add(New Stuff("baz"))
</code></pre>
And they really don't have a problem with it :)
I ended up writing the equivalent of lisp macros in C++, of all languages.<p>One thing that helped greatly with that is the “defer” statement. It lets you defer a section of code to the end of the current scope. Which means you now have compile time access to the entire current scope.<p>We’re writing a compiler for custom ML hardware using MLIR. MLIR has the concept of a current insertion point when you’re building an AST.<p>emacs users will know where I’m going with this.<p>We now have a save_excursion macro which stores the current cursor, then resets it at the end of the scope automatically. So when you’re building a loop or an if statement, you normally have to call (pseudocode):<p><pre><code> make loop
set cursor to loop body
make statements inside the loop
set cursor to “after loop body”
</code></pre>
Now it’s<p><pre><code> make loop
save_excursion();
make statements inside the loop
</code></pre>
Notice that the work decreased by 25% (three lines instead of four). In C++ land especially, this is a big win.<p>The “make loop” part is actually so long that our linter breaks it onto several lines. But after making a macro for it, it looks like:<p><pre><code> affine_for(loop, idx, 0, n, 1);
make statements inside the loop
</code></pre>
And the statements in the loop can of course reference “idx”, the iteration variable, or “loop” (a first class object representing a for loop).<p>Boom, now the work is cut by 50%. Two lines of code. Technically it went from three to one, and it’s far more readable.<p>The usual lisp disciplinary rules apply. You need to be familiar with variable capture, and how to make variable names at compile time. (In C++ I use a UNIQ(x) macro, which gives me a unique name for x. You can capture it into a #define by making a second #define and passing UNIQ(x) into it. So in practice most macros like save_excursion become two #defines, since you have to reference the unique name of the variable to store the cursor.)<p>I don’t know if it’s common. I assume not. Most lispers are rightly allergic to C++. But most lispers also lose the benefits of working in a team setting — so in practice, porting as much benefit from lisp to other languages is the biggest win of all. And that requires you to learn lisp. (Interested readers should look up the Blub Paradox, then move on to studying On Lisp.)
I guess he doesn't really know the parts when lisp macros are uncool. He even had the breaking example in his slide. The x++ part also breaks in lisp and only works in scheme, or when you have to introduce gensym into your macro. scheme macros are the real thing, but are not as simple and homomorph as lisp macros. they are more like constexpr matchers. if only we would have structural matching in our languages. and then do that at compile-time.
> One obvious advantage is that there hardly <i>is</i> any syntax. You can
learn enough Lisp syntax to write useful programs in about ten
minutes<p>Perl encourages idiomatic programming styles which make collaboration difficult. I'm the eng mgr of a team which writes (among other things) Perl for big data processing applications and none of our programmers understand code the others have written without extensive (measured in weeks rather than days) analysis. I've never encountered the problem to this extent on Java code bases.
I love the idea of Lisp, but every time I have a look at CL I feel it needs a fresh reboot without a lot of the... strange, ugly, or opaque stuff I guess. For example, some things are in-place, some aren't, and I'm usually running into strange problems that are difficult to debug. Granted, I'm a layman, but it makes learning quite difficult.