Macros are good, but in order to understand why there are good you have to lift your head out of the common mindset of most developers that spend half their days configuring their application in some poorly designed XML-based DSL that's only necessary because doing the same thing in their programming language is too awkward. They coincidentally spend the other half of their days writing code in the same basic procedural style they learned as a kid, copying and pasting bits of code everywhere and making a general highly-coupled mess because they don't how to do it any better.

It has been said that at any given point, every project implements their own programming language, usually as some kind of DSL, and they do it really really badly. I've seen this borne out in practice in EVERY commercial project I've worked on. I've seen it, I've lived, and I continue to live it every day. Macros are one of the ways out of this mess that we've created for ourselves. While a lot of macro research is still cutting edge, slowly different techniques are becoming more proven and starting to disseminate more and more into mainstream languages and runtimes. The problems you mention with macros have honestly already been dealt with in the past decade or two.

I've dealt with people like you at work before. Your kind are those that stare at any abstraction they don't understand with immediate suspicion and reject it without any real consideration. They refuse to learn new things or improve their programming abilities or toolset. While this in of itself isn't a crime, they hold the rest of the industry back by rejecting superior technologies as they come along because they refuse to take the time understand them.

Your kind and mine, sir, are in direct opposition.

Well said. I'm reminded of the pg's Blub paradox, and Rich Hickey's recent quote, "I can't read German; does that make it unreadable?" both at the same time.

I think a better analogy is struggling to understand odd (spoken) english dialects: yes, they are speaking english, but not the variant(s) you know.

I don't understand what you are trying to say.

On one hand you are saying that most projects you have worked on end up creating their own language, usually as some kind of DSL. Then you argue that the way to counter this is to ... give people more tools to craft DSLs.

So what are you trying to say?

PS: you seem to make a lot of assumptions about me based on ... what exactly? I don't believe we've met and whatever you are "in direct opposition" to is simply a straw man you have imagined.

Macros have their place, but not as the primary basis of a language (sorry, Lisp), where most things unnecessarily become macros to avoid explicit function literals or quoting. Then to do anything reasonable you're using several language "extensions" at any one given time, which can only compose in ways the macro writers forsaw. Most of what is done with Lisp macros can be done with first-class function literals, in a way that makes it pretty clear that non-linear control flow is going on.

Macros in Scala? I don't know, the language already seems quite complex without introducing custom syntax. But if they're more of an occasionally-used compiler extension for specific internal DSLs rather than a by-example use-them-everywhere, I don't see them hurting.

That being said, I'm quite enjoying taking a break from JVM hell and doing some exploratory programming in Racket. If special forms are well documented, widely used, and syntax checked, the extra mental overhead isn't burdensome.

You make some valid points, but they would be better made if you toned down your rhetoric about people who work on programming languages.

I'm an engineer at heart. One of the hardest things that I have to do on a daily basis is to ask myself where what I think is cool conflicts with what the user needs. Or indeed if my cool idea will harm the user. As engineers we tend to focus on the cool bit. I too have fallen into that trap and I expect to do it many times in the future. But I try to be aware that this can and will happen.

I think asking language nuts (which isn't limited to those who write compilers, but also extends to practitioners with deep knowlede) to be aware of this is particularly important in that people look to them for enlightenment and advice -- and when they do harmful things it has a huge multiplier effect.

This is a very valid concern, and we keep it in mind. Several really fancy ideas were rejected simply because that added too much complexity or could get out of hand quickly. That's why, for one, the main page of the project says that "Scala macros ... cannot change syntax of Scala".

Some people from our team do have a painful experience with Lisp-style macros, so we try especially hard to find a minimally useful yet conceptually clean approach to compile-time metaprogramming (we are sure, though, that this sweet spot exists).

And that's why we stress the importance of feedback and appreciate it. Thanks for sharing your thoughts!