9 ms·

As "michael" points out in the comments on the article, this has already been invented, it's called a macro and has been available for decades in various LISPs.

As "michael" points out in the comments on the article, this has already been invented, it's called a macro and has been available for decades in various LISPs. Wikipedia lists a number of other languages [1] that support macros. [1] https://en.wikipedia.org/wiki/Macro_(computer_science)#Syntactic_macros https://en.wikipedia.org/wiki/Macro_(computer_science)#Synta...

johan_larson 9y ago
Lisp: The language of the future. Always has been. Always will be.
- pjmlp 9y ago
  In some alternative universe Lisp, Smalltalk and Mesa/Cedar would have won the love of mainstream computing, instead of us slowly catching up with the past. Oh well.
  - Ygg2 9y ago
    Isn't that essentially JavaScript land? Where the glut of libraries and different ways to do same thing causes JS fatigue?
    - pjmlp 9y ago
      JavaScript still lacks quite a few design improvements. JS fatige is caused by a culture that creates packages for single functions.
- agumonkey 9y ago
  I think that was Fare who said there's no syscall or drivers, only bytes, you can nicely generate them in CL, so that's it.
bananicorn 9y ago
There's other languages with rather powerful macro systems too, red for example: http://www.red-lang.org/2016/12/entering-world-of-macros.html http://www.red-lang.org/2016/12/entering-world-of-macros.htm...
aaron-lebo 9y ago
I'd argue that macros are overrated and abstractions like blocks underused.
pjc50 9y ago
The one thing in programming language design you can be sure of is that it's never time for Lisp. (This is a joke, but it's also a serious point; people keep thinking of Lisp as the "king over the water" that will one day return and save them, which keeps people from looking at the reasons why Lisp never achieved mass adoption. Or arguing that Lisp cannot fail, it can only be failed.)
- zitterbewegung 9y ago
  Lisp failing mass adoption ? Common Lisp had a large amount of adoption. Emacs lisp has a really big install base . Clojure is pretty popular also . Do you mean wide adoption ? I agree that lisp has issues marketing itself.
- arethuza 9y ago
  I do find myself wondering why, when I was paid to develop in Lisp for ~6 years (and PostScript at the same time, but that's another story) and really enjoyed using it and frequently find myself extolling the virtues of macros, loop or CLOS that I've never actually used it on a project since then (and I do quite a few side projects just to play with new languages). Edit: I think you're downvotes are bit harsh and as a Scot I appreciate the "king over the water" reference - people get all romantic about the Jacobites without thinking too much about what their policies might have been.
  - fsloth 9y ago
    " I've never actually used it on a project since then" The recurring cost of maintaining and deploying a working Lisp system is perceived by you to be higher than the benefits the language begets?
    - arethuza 9y ago
      To be honest - I'm not sure why I've never used it again, probably attracted by shiny new things rather than something I last used over 20 years ago.
simias 9y ago
The problem with having powerful macros is always the same: as a project grows and grows you end up inventing your own little dialect of the language which is opaque to any 3rd party reading your code unless they take the time to unravel your macros. I think Rust did two things right in that regard: firstly the macro invocations are always suffixed with '!' so you know it's not a regular function call right away. Secondly Rust macros are so quirky, ugly and painful to implement that you only ever use them as a last resort, so people tend not to abuse them too much.
- flavio81 9y ago
  >as a project grows and grows you end up inventing your own little dialect of the language which is opaque to any 3rd party reading your code unless they take the time to unravel your macros. This is bad use of macros, or an ugly macro system. Macros, at least in Lisp, made code even clearer to understand; because they let you create the constructs that make the problem domain map more directly, straightforwardly, easily, to the programming language. So they reduce line count, they reduce need for kludges or workarounds. They allow more straight code. But this is within the Land of Lisp, where writing a macro isn't something "advanced" nor "complex" nor "esoteric". In the Lisp world, writing a macro is 95% similar to writing a run-of-the-mill function.
  - jdmichal 9y ago
    No true Scotsman would ever write macros in such a confusing manner! But really, this is a recognized problem of Lisp, and has been called the Lisp Curse. [0] One is never programming in "just Lisp", but rather in Lisp plus some half-baked DSL haphazardly created by whoever wrote the program in the first place. Also, don't confuse readability with understanding. Yes, DSLs are typically easier to read, but only after you come to understand the primitives of the language. When every program has its own DSL with its own primitives, even programs that do similar things... That becomes quite a burden. [0] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
    - 9y ago
fsloth 9y ago
The author of the blog, Martin Sustrik, is the original author of ZeroMQ. His late colleague in the project, Pieter Hintjens, extolled the virtue of effectively macro based code generation, especially using a "macro language" GSL: https://github.com/imatix/gsl https://github.com/imatix/gsl Which has some previous discussion about it: https://news.ycombinator.com/item?id=11558007 https://news.ycombinator.com/item?id=11558007 I would imagine Martin has gone through the path of discussing macros long time ago, and for some reason or other does not refer to them here.
Tarean 9y ago
Macros are less nice in non-lispy languages. If the language ast and syntax aren't iconomorphic then you add a learning curve and need to insulate users from compiler internal changesy quasy quoting doesn't work everywhere. In a compiled languange first class macros also add significant compile time. A couple languages have them like nim's macros , haskell's TemplateHaskell extension and Rusts compiler plugins, though.
- tome 9y ago
  > iconomorphic Do you mean "homoiconic"?

johan_larson 9y ago

Lisp: The language of the future. Always has been. Always will be.

pjmlp 9y ago
In some alternative universe Lisp, Smalltalk and Mesa/Cedar would have won the love of mainstream computing, instead of us slowly catching up with the past. Oh well.
- Ygg2 9y ago
  Isn't that essentially JavaScript land? Where the glut of libraries and different ways to do same thing causes JS fatigue?
  - pjmlp 9y ago
    JavaScript still lacks quite a few design improvements. JS fatige is caused by a culture that creates packages for single functions.
agumonkey 9y ago
I think that was Fare who said there's no syscall or drivers, only bytes, you can nicely generate them in CL, so that's it.

bananicorn 9y ago

There's other languages with rather powerful macro systems too, red for example: http://www.red-lang.org/2016/12/entering-world-of-macros.html http://www.red-lang.org/2016/12/entering-world-of-macros.htm...

aaron-lebo 9y ago

I'd argue that macros are overrated and abstractions like blocks underused.

pjc50 9y ago

The one thing in programming language design you can be sure of is that it's never time for Lisp. (This is a joke, but it's also a serious point; people keep thinking of Lisp as the "king over the water" that will one day return and save them, which keeps people from looking at the reasons why Lisp never achieved mass adoption. Or arguing that Lisp cannot fail, it can only be failed.)

zitterbewegung 9y ago
Lisp failing mass adoption ? Common Lisp had a large amount of adoption. Emacs lisp has a really big install base . Clojure is pretty popular also . Do you mean wide adoption ? I agree that lisp has issues marketing itself.
arethuza 9y ago
I do find myself wondering why, when I was paid to develop in Lisp for ~6 years (and PostScript at the same time, but that's another story) and really enjoyed using it and frequently find myself extolling the virtues of macros, loop or CLOS that I've never actually used it on a project since then (and I do quite a few side projects just to play with new languages). Edit: I think you're downvotes are bit harsh and as a Scot I appreciate the "king over the water" reference - people get all romantic about the Jacobites without thinking too much about what their policies might have been.
- fsloth 9y ago
  " I've never actually used it on a project since then" The recurring cost of maintaining and deploying a working Lisp system is perceived by you to be higher than the benefits the language begets?
  - arethuza 9y ago
    To be honest - I'm not sure why I've never used it again, probably attracted by shiny new things rather than something I last used over 20 years ago.

simias 9y ago

The problem with having powerful macros is always the same: as a project grows and grows you end up inventing your own little dialect of the language which is opaque to any 3rd party reading your code unless they take the time to unravel your macros. I think Rust did two things right in that regard: firstly the macro invocations are always suffixed with '!' so you know it's not a regular function call right away. Secondly Rust macros are so quirky, ugly and painful to implement that you only ever use them as a last resort, so people tend not to abuse them too much.

flavio81 9y ago
>as a project grows and grows you end up inventing your own little dialect of the language which is opaque to any 3rd party reading your code unless they take the time to unravel your macros. This is bad use of macros, or an ugly macro system. Macros, at least in Lisp, made code even clearer to understand; because they let you create the constructs that make the problem domain map more directly, straightforwardly, easily, to the programming language. So they reduce line count, they reduce need for kludges or workarounds. They allow more straight code. But this is within the Land of Lisp, where writing a macro isn't something "advanced" nor "complex" nor "esoteric". In the Lisp world, writing a macro is 95% similar to writing a run-of-the-mill function.
- jdmichal 9y ago
  No true Scotsman would ever write macros in such a confusing manner! But really, this is a recognized problem of Lisp, and has been called the Lisp Curse. [0] One is never programming in "just Lisp", but rather in Lisp plus some half-baked DSL haphazardly created by whoever wrote the program in the first place. Also, don't confuse readability with understanding. Yes, DSLs are typically easier to read, but only after you come to understand the primitives of the language. When every program has its own DSL with its own primitives, even programs that do similar things... That becomes quite a burden. [0] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
  - 9y ago

fsloth 9y ago

The author of the blog, Martin Sustrik, is the original author of ZeroMQ. His late colleague in the project, Pieter Hintjens, extolled the virtue of effectively macro based code generation, especially using a "macro language" GSL: https://github.com/imatix/gsl https://github.com/imatix/gsl Which has some previous discussion about it: https://news.ycombinator.com/item?id=11558007 https://news.ycombinator.com/item?id=11558007 I would imagine Martin has gone through the path of discussing macros long time ago, and for some reason or other does not refer to them here.

Tarean 9y ago

Macros are less nice in non-lispy languages. If the language ast and syntax aren't iconomorphic then you add a learning curve and need to insulate users from compiler internal changesy quasy quoting doesn't work everywhere. In a compiled languange first class macros also add significant compile time. A couple languages have them like nim's macros , haskell's TemplateHaskell extension and Rusts compiler plugins, though.

tome 9y ago
> iconomorphic Do you mean "homoiconic"?