Of Lisp Macros and Washing Machines
Vladimir Sedach explains the purpose of the Lisp macro and comments on some of the reasons for its absence from "modern" programming systems:
"I used to like arguing over the Internet about this subject. There are many good technical and management/organizational arguments you can make for and against macros. What I've come to realize is they're all pretty much irrelevant. The entire point of programming is automation. The question that immediately comes to mind after you learn this fact is - why not program a computer to program itself? Macros are a simple mechanism for generating code, in other words, automating programming. Unless your system includes a better mechanism for automating programming (so far, I have not seen any such mechanisms), _not_ having macros means that you basically don't understand _why_ you are writing code. This is why it is not surprising that most software sucks - a lot of programmers only have a very shallow understanding of why they are programming. Even many hackers just hack because it's fun. So is masturbation. This is also the reason why functional programming languages ignore macros. The people behind them are not interested in programming automation. Wadler created ML to help automate proofs. The Haskell gang is primarily interested in advancing applied type theory. Which brings me to my last point: as you probably know, the reputation of the functional programming people as intelligent is not baseless. You don't need macros if you know what you are doing (your domain), and your system is already targeted at your domain. Adding macros to ML will have no impact on its usefulness for building theorem provers. You can't make APL or Matlab better languages for working with arrays by adding macros. But as soon as you need to express new domain concepts in a language that does not natively support them, macros become essential to maintaining good, concise code. This IMO is the largest missing piece in most projects based around domain-driven design."
Those who build and program computer systems appear to have forgotten that such things were once intended to be labor-saving tools, rather than expensive space heaters. The whole point of automation is not to build planned-obsolescent crud faster than ever. Rather, it is to reduce the need for drudge work so that human beings can get on with the business of enjoying life:
"My mother explained the magic with this machine the very, very first day. She said, "Now Hans, we have loaded the laundry; the machine will make the work. And now we can go to the library." Because this is the magic: you load the laundry, and what do you get out of the machine? You get books out of the machines, children's books. And mother got time to read for me. She loved this. I got the "ABC." This is where I started my career as a professor, when my mother had time to read for me. And she also got books for herself. She managed to study English and learn that as a foreign language. And she read so many novels, so many different novels here. And we really, we really loved this machine. And what we said, my mother and me, "Thank you industrialization. Thank you steel mill. Thank you power station. And thank you chemical processing industry that gave us time to read books.""
Thank you industrialization. Thank you steel mill. Thank you power station. And thank you chemical processing industry that gave us time to read books.
But no thank you Microsoft. No thank you spreadshi^Heets. No thank you Unix. No thank you C++. No thank you unmodifiable syntax. No thank you von Neumann architectures. No thank you unrepentant snake oil industry that has lured us into performing the same old menial tasks by mouse instead of by lever and duped almost everyone involved into thinking of this as some kind of progress.
The misadventures of the personal computer are merely a symptom of an underlying (possibly incurable) disease. At some point, people forgot what industrialization was supposed to be for. What would it take to make them remember?
[...] blog post discusses the importance of automation in programming, but makes some pretty deep statements about economics in [...]
[...] This post was Twitted by ikki_tousen [...]
[...] If you like it, you might want to head over to Loper OS to see what Stanislav Datskovskiy has to say about it. This entry was posted in General and tagged Lisp. Bookmark the permalink. ← [...]
Macros, as seen in Lisp, primarily support abstractions with slight differences in evaluation order or mechanics. This application of macros would be a largely redundant feature for Haskell language, where developers use explicit abstractions (arrows, monads, etc.) to model control flow orthogonal to its abstraction mechanism.
Similarly, macros can be used for 'code-walking', which is redundant in a language with explicit staging abstractions.
Lisp is very flexible for 'automation of programming' - i.e. it has a lot of expressive power, especially by combining macros with global state (e.g. to build multi-method dispatch tables).
But there are opportunity costs to maintain that flexibility. A minor sacrifice of rarely or never used expressive power might offer greater support for composition, optimization, parallelism, distribution, heterogeneous memory (e.g. compiling to FPGA or CUDA), runtime upgrade, secure or open architectures, generic reuse. There is an 'window of sane development' between automating our actions and controlling their costs or consequences.
The lack of expressiveness (including the lack of macros) is a problem of not just Haskell but also all almost all non-Lisp languages. The big problem with Haskell in particular is that it is purely functional. Well it is nice to have have the advantages of immutability, however, side effects are the foundation of all fundamentally useful programs. Clojure strikes at a fine balance by using persistent data structures (most importantly the singly-linked list) well also embracing side effects.
I think the problem with macros is that they do not always compile and do not always work fine. Debugging macros is hard by any definition, because you have to reason about both what is written and what goes on behind the scenes. A macro is great if the same genius is both writing the macro and using it, otherwise it sucks, in practical terms.
With a function things are much easier - one know what gets in, and you can tell the author of the function what has gone wrong; much easier then trying to understand how the macro did unwind; with macros the additional complexity is that one has to understand what the user of the macro was trying to do.
[...] Interesting “My mother explained the magic with this machine the very, very first day. She said, “Now Hans, we have loaded the laundry; the machine will make the work. And now we can go to the library.” Because this is the magic: you load the laundry, and what do you get out of the machine? You get books out of the machines, children’s books. And mother got time to read for me. She loved this. I got the “ABC.” This is where I started my career as a professor, when my mother had time to read for me. And she also got books for herself. She managed to study English and learn that as a foreign language. And she read so many novels, so many different novels here. And we really, we really loved this machine. And what we said, my mother and me, “Thank you industrialization. Thank you steel mill. Thank you power station. And thank you chemical processing industry that gave us time to read books.”” Source [...]
David Graeber: On Bureaucratic Technologies & the Future as Dream Time
http://www.youtube.com/watch?v=-QgSJkk1tng
Where are the flying cars and thinking machines?
Wadler did not create ML, R Milner did. http://www.cl.cam.ac.uk/~mjcg/papers/HolHistory.pdf (and many other credible sources)