3 ms·

Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. And Clojure seems to have developed idioms around simplic

Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. And Clojure seems to have developed idioms around simplicity. Scala, on the other hand, has wildly diverging sets of best practices. The feature set is huge, attempting to appeal to pure functional programmers in their academic ivory towers, and the grizzled Java developers who believe OOP is the one true way, and everyone in between. It's easy to -say- that there are 5000 ways to do the same thing in a LISP, and only 5-10 ways to do the same thing in Scala (both statements being hyperbolic, presumably; there are infinitely many ways of doing each, after all), the meaningful variations you are likely to see in the wild are far, far lower in Clojure than Scala. And will likely be based on different understandings/expressions of the problem, rather than on different language subsets that the author prefers.

pekk 12y ago
If macros are agreed by all Lisp users to be a "use rarely" thing, then why is internet Lisp advocacy so strongly focused on macros as an advantage of Lisp over the rest of the world?
- sls 12y ago
  Rarely isn't never. I'd join in the recommendation above to read pg's "On Lisp" to get a sense of the sort of things one can accomplish with a few small macros. But just as a sampler, if your language has a preprocessor phase where source code is manipulated by source code you provide, you can add control structures. Maybe your language has a loop construct but no way to iterate through a collection without explicit indices. You can add that, and it will be a first-class control structure that gets to control evaluation and everything. You do not have to file a feature request and drum up support and wait five years to get it.
- lostcolony 12y ago
  To give an analogy (not a great one, but a reasonable one), think of reflection on the JVM. Is it something to use all the time (even if it was fast)? No. Is it incredibly powerful and incredibly useful for certain classes of problems? Yes. Is it a strong advantage for languages with reflection vs those that have nothing comparable? Yes.
deleted 12y ago
[deleted]
lispm 12y ago
> Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. Not really. This best practice is for beginners and mid-level programmers. They either write macros for the wrong purpose or in problematic ways. Thus they should avoid macros. Still they need to use macros, since languages like Common Lisp provide a lot of functionality through macros. To get past that stage a book like 'On Lisp' by Paul Graham helps. Many, but not all, advanced programmers will use and write a lot of macros.
- nickik 12y ago
  Thats just not true in clojure. Good librarys in clojure have a data interface, function to produce that data and maybe a thin macro layer to make it a little more easy to use. While 'On Lisp' is a cool book, I rarly find the really advanced macro stuff usful. Once in awhile, you want to have something like a really good pattern matching compiler, and then your macros come in handy. But day to day, you dont need them much.
  - lispm 12y ago
    Let's look at some Common Lisp example: https://github.com/Wukix/LambdaLite/blob/master/lambdalite.lisp https://github.com/Wukix/LambdaLite/blob/master/lambdalite.l... This is a recent tiny in-core database. The code is using LOTS of macros. It also implements a few non-trivial macros. Half of the code is implemented as macros. Code like that is not unusual in Lisp.
  - deleted 12y ago
    [deleted]
- lostcolony 12y ago
  Sure, if your code is only going to be touched by LISP experts, and/or has a sufficiently strong separation from that being touched by the novices/intermediates (i.e., like a library), macro away. There's a reason I qualified it with "generally" and "rarely".
imanaccount247 12y ago
>attempting to appeal to pure functional programmers in their academic ivory towers That's not where we live.

pekk 12y ago

If macros are agreed by all Lisp users to be a "use rarely" thing, then why is internet Lisp advocacy so strongly focused on macros as an advantage of Lisp over the rest of the world?

sls 12y ago
Rarely isn't never. I'd join in the recommendation above to read pg's "On Lisp" to get a sense of the sort of things one can accomplish with a few small macros. But just as a sampler, if your language has a preprocessor phase where source code is manipulated by source code you provide, you can add control structures. Maybe your language has a loop construct but no way to iterate through a collection without explicit indices. You can add that, and it will be a first-class control structure that gets to control evaluation and everything. You do not have to file a feature request and drum up support and wait five years to get it.
lostcolony 12y ago
To give an analogy (not a great one, but a reasonable one), think of reflection on the JVM. Is it something to use all the time (even if it was fast)? No. Is it incredibly powerful and incredibly useful for certain classes of problems? Yes. Is it a strong advantage for languages with reflection vs those that have nothing comparable? Yes.

deleted 12y ago

[deleted]

lispm 12y ago

> Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. Not really. This best practice is for beginners and mid-level programmers. They either write macros for the wrong purpose or in problematic ways. Thus they should avoid macros. Still they need to use macros, since languages like Common Lisp provide a lot of functionality through macros. To get past that stage a book like 'On Lisp' by Paul Graham helps. Many, but not all, advanced programmers will use and write a lot of macros.

nickik 12y ago
Thats just not true in clojure. Good librarys in clojure have a data interface, function to produce that data and maybe a thin macro layer to make it a little more easy to use. While 'On Lisp' is a cool book, I rarly find the really advanced macro stuff usful. Once in awhile, you want to have something like a really good pattern matching compiler, and then your macros come in handy. But day to day, you dont need them much.
- lispm 12y ago
  Let's look at some Common Lisp example: https://github.com/Wukix/LambdaLite/blob/master/lambdalite.lisp https://github.com/Wukix/LambdaLite/blob/master/lambdalite.l... This is a recent tiny in-core database. The code is using LOTS of macros. It also implements a few non-trivial macros. Half of the code is implemented as macros. Code like that is not unusual in Lisp.
- deleted 12y ago
  [deleted]
lostcolony 12y ago
Sure, if your code is only going to be touched by LISP experts, and/or has a sufficiently strong separation from that being touched by the novices/intermediates (i.e., like a library), macro away. There's a reason I qualified it with "generally" and "rarely".

imanaccount247 12y ago

>attempting to appeal to pure functional programmers in their academic ivory towers That's not where we live.