No, I meant languages (as in programming languages), not programs.
> A good way to become convinced of the power of macros is to try and write a web app in Arc to generate lots of HTML.
I'm already convinced macros are powerful. The problem is that they're also extremely error prone, and can be extremely difficult to debug when errors inevitably occur.
This isn't controversial. Land Of Lisp[1] has a section titled "Macros: Dangers and Alternatives". The elisp docs[2] contain a section on "Common Problems Using Macros". Paul Graham's On Lisp[3] contains a chapter on variable capture which consists mostly of sections on avoiding variable capture problems, followed by a chapter called Other Macro Pitfalls.
These are the people who like Lisp writing these things. The controversial thing I'm saying is that I don't think the power/danger tradeoff is worth it. That's pretty subjective and it's reasonable to disagree with that, but you can't reasonably disagree that macros are error prone when even the people writing Lisp variants are saying they are error-prone.
The best HTML generation I've experienced is with Ruby templates. They're not as terse as Lisp macros, but I don't end up having to debug them very often, and when I do end up debugging them, the bugs are usually trivial to find and fix.
> Autogeneration can be done with macros and is simpler with macros.
I have never spent hours debugging an IDE autocomplete. I have spent many hours debugging macros.
You're only looking at the positives of macros and ignoring everything I've said about the negatives.
[1] https://www.oreilly.com/library/view/land-of-lisp/9781593272...
[2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr...
[3] https://redirect.cs.umbc.edu/courses/331/fall10/resources/li...
I'd be interested to see what others consider a suitable general learning path for Lisp.
I'm just going to copy from my other post:
Land Of Lisp[1] has a section titled "Macros: Dangers and Alternatives". The elisp docs[2] contain a section on "Common Problems Using Macros". Paul Graham's On Lisp[3] contains a chapter on variable capture which consists mostly of sections on avoiding variable capture problems, followed by a chapter called Other Macro Pitfalls.
I suppose it's possible that the authors of Lisp dialects are being irrational...
> Sure you could wait many years for the 'language designer' to provide you with new syntactical support or just write it in an afternoon yourself. It's the same crazy idea as writing a new class with its methods, instead just using the pre-made class hierarchy from the language or library designer.
Given all the work that has been done in modern languages to avoid the pitfalls of classes such as multiple inheritance, this is a better example of my point than you think it is.
> Not sure who this we is, but it is not me.
> It's exactly what the Lisp Machine did: you could use the same power to shape the memory usage of your domain. It had a bunch of different garbage collectors working side by side and a programmable memory management. All that was written in Lisp itself.
The Lisp Machine is not "most cases". It's unsurprising that an attempt to run Lisp directly on hardware would need to do some direct memory access, but it's also absurd to extrapolate that to claim that this is something that is a good idea in most cases. Your average Lisp program does not and should not directly manage memory, and claiming otherwise is obviously just trying to win a silly point. I don't believe for a second that you do direct memory access in your Lisp programs on a regular basis, unless you're writing some very low-level stuff like hardware or a Lisp compiler/interpreter, and again, that's not "most cases". You're simply making a disingenuous argument here.
[1] https://www.oreilly.com/library/view/land-of-lisp/9781593272...
[2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr...
[3] https://redirect.cs.umbc.edu/courses/331/fall10/resources/li...