[odersky]

The blog post and tweets seem to say the Scala community only cares about fancy language stuff and not about the developer experience. Nothing could be further from the truth. Take Typesafe for example. We have three full time engineers on staff to improve the Scala IDE for Eclipse. We made a lot of progress and are continuing to do so. Nobody pays us for any of that; we do it because we know that IDE experience is crucial for Scala developers. Typesafe is just one company and it cannot pour unlimited resources into all aspects of Scala development, so we need to rely on the community for that. And the community does step up to the task. One of the criticism was on documentation. I wonder whether people have recently looked at http://docs.scala-lang.org/ ? In my mind, that's community-driven development at its best!

Why macros? I was a long-time sceptic. I now tend to think about them differently because I believe we hit on a brilliantly simple scheme that can express a lot of different use-cases. In particular we'll be able to do the analogue of Microsoft's LINQ with macros. And we can express optimizations such as turning foreach applications into while loops. And we can remove a lot of compiler plugins. And finally it looks like we can remove down the road several special cases in the language and the compiler. So macros might pay for their own complexity handily. But I should also say that at present this is a SIP, a Scala Improvement _Proposal_. It's not yet accepted. And part of the current proposal is also that macros will be enabled only under a special compiler flag.

[stuhood]

We definitely appreciate the work that you and Typesafe are doing: thanks! I apologize for my brusque reaction in that tweet.

Regarding macros: it's quite clear that they simplify the job of the compiler writer: you can provide more features, more efficiently to the end user. But every feature has a cost, and increasing the end user's surface area onto the language by providing 1) macros, 2) new features enabled by macros, is very much a double edged sword. Being enabled by a compiler flag definitely helps to minimize end-user exposure to the former.

Macros in lisps can be used as a replacement for many of the features that Scala provides, including call-by-name parameters, (certain types of) implicits, and many uses of generics. If we could deprecate some of those features in Scala by replacing them with macros, then this would seem like more of a net win to me. But that doesn't seem likely: instead we will probably have all N, and Scala programmers will need to decide which of the growing list of ways to accomplish cat-skinning is best.

[modersky]

I am very much aware of the double-edge sword nature of macros, and therefore follow and aid their progress with much trepidation. The single thing that sold be was that macros by themselves already could replace a compiler phase, which did code reification (i.e. generate ASTs at run-time; something that's needed for LINQ like technologies). So in that sense, macros, if they arrive, would already have paid for themselves. Concerning possible misuse, I believe the best thing we can do is give an option to developers. So we plan to enable macro definitions only if a special import is present. Something like:

import language.macros

Of course that will not prevent misuse, but it will make it much easier to enforce policies, if someone desires that.

[sreque]

It's been shown formally that call-by-name semantics and call-by-value semantics cannot be expressed via the other using macros (see http://www.ccs.neu.edu/scheme/pubs/scp91-felleisen.ps.gz).

Also, macros cannot be used in Scheme to implement implicits because implicits, like type classes, rely on static type information. I have actually heard of an attempt to implement type classes in Scheme and it required manual type annotations in all use cases. And, while it hasn't been formally proven, intuitively implicits and typeclasses feel like the kind of languages features that would be difficult, if not impossible, to implement with classic macros.

I feel like you have some pre-conceived notions, both about what macros can and can't do, and about what affect they will have on the Scala language when added. However, as others more knowledgeable than me have already pointed out, macros have already managed to simplify the language as is, and their full potential has yet to be untapped. I would suggest giving them a chance.

[retronym]

And macros aren't just for optimizations -- they can also provide additional compile time checks, for example checking that regex strings are well-formed, or that the arguments to printf, or printf-style interpolated strings, match the provided format specifiers.

[denka]

Mr. Gosling attributes many strengths of Java to the fact that while designing it he and his team were working with technical writers, so that language, platform, and documentation were developed in parallel. Additionally, he attributes the need to explain stuff to writers as an important mechanism to influence the quality of the design itself. I wonder if this positive learning was taken benefit of with regards to Scala. Community-driven is great in principle, but after-the-fact, afterthought appearance that this approach creates is unfortunate.

[emolitor]

Many parallels to the negative feedback AOP received when it first appeared on developer horizons. It took a while for people to see where they did and did not fit logically into their problem solving toolkit. I can't predicate the future but Macro's fit into a similar bucket. I don't see them as a tool I would apply everyday but on the occasion I needed them the alternatives are blunt instruments.

I'm certainly not an expert in this area and have only toyed around with the SIP and Retronym's examples so take everything I say with a huge grain of salt. But I do hope everyone critical of the SIP and the concept has at least done the same.

[igor-petruk]

Compiler flag would make code part of the projects dependent on this flag and thus make compilation process more complex in terms of choices how you compile. Developers may end up just enable this flag always, which kills the purpose of the flag. I sounds more reasonable just keeping compilation to scalac *.scala

[athiguna]

You guys really think that code that looks like this - https://github.com/twitter/scalding/blob/master/src/main/sca... is more readable and maintainable than just Java?

[dimeni]

I can't wait for scala's macros! Every time expressiveness, conciseness, and performance converge it is a thing of beauty.