Scala Macros: “Oh God Why?”
blog.empathybox.com
Scala Macros: “Oh God Why?”
1–10 of 57 posts
Re: Scala Macros: “Oh God Why?”
#2I seems to be a rather common tension in open source projects developed by research institutions.
The goal of users of those projects is immediate usability which clashes with goals of developers, research.
I have some doubts where one can get PHD (publish an article with high citation index) by improving a compiler error messages. As opposed to adding a new cool feature to the language/compiler, cryptic error messages be damned.
Re: Scala Macros: “Oh God Why?”
#3Macros make language design experimentation easier. This issue is not orthogonal to tackling the other issues the OP cares about.
There are good reasons to doubt the overall value of macros in production code - I won't argue this either way - but OCaml has had success by separating the macro expansion mechanism (camlp4) from the main language. People who want macros can have them, people who want a production language without macros can have that too.
Re: Scala Macros: “Oh God Why?”
#4The author doesn't even know what macros are: "I understand macros to provide two things (1) forced code in-lining and (2) a kind of non-strict semantics or lazy evaluation of arguments"
Re: Scala Macros: “Oh God Why?”
#5I seems to be a rather common tension in open source projects developed by research institutions. The goal of users of those projects is immediate usability which clashes with goals of developers, research. I have some doubts where one can get PHD (publish an article with high citation index) by improving a compiler error messages. As opposed to adding a new cool feature to the language/compiler, cryptic error messag…
True.
I still think it is a shame that neither Red Hat nor Jet Brains has joined forces with Scala/Typesafe. Both of these companies know how to ship products and make developers happy. This is something that Typesafe has to learn now. On the other hand, Red Hat and Jet Brains need to learn how to do language research... (which may actually be harder, once they go beyond fixing the obvious Java flaws).
Re: Scala Macros: “Oh God Why?”
#6The author doesn't even know what macros are: "I understand macros to provide two things (1) forced code in-lining and (2) a kind of non-strict semantics or lazy evaluation of arguments"
What else do you think macros provide?
As a former professional Common Lisp dev, those two features strike me as the real difference between a macro and function call.
Re: Scala Macros: “Oh God Why?”
#7The author doesn't even know what macros are: "I understand macros to provide two things (1) forced code in-lining and (2) a kind of non-strict semantics or lazy evaluation of arguments"
What else do you think macros provide? As a former professional Common Lisp dev, those two features strike me as the real difference between a macro and function call.
Scala already has @inline and call-by-name, so it doesn't need macros for either purpose.
Macros in Scala are primarily of interest for metaprogramming; it's a fairly natural direction for Scala to take, given that Scala has always positioned itself as a language that supports internal DSLs.
Re: Scala Macros: “Oh God Why?”
#8The post raises a few good points -- those are real problems in using Scala -- but the problems are mostly a result of the compiler targeting the JVM as its primary backend. Obviously, a JVM-based language can leverage a rich infrastructure of libraries, but it also will have to deal with the fact that the JVM is primarily designed for Java, not as a more general backend (such as the LLVM or the CLR).
(That the compiler is slow has other reasons, but is also something that they've been working on simultaneously for 2.10, so it's not as though that has been pushed aside by macros.)
Re: Scala Macros: “Oh God Why?”
#9The listed points are valid, but they are by far not as easy as the author thinks they are. I don't say they are not improvable, but they are not 'little things' that need to get fixed before new features come in. For example, the jars are large because every closure needs its own class (thank you jvm!). Compile time is high because of type inference. Error messages and stack traces are cryptic, because you do high-level programming but get low-level diagnostics. etc.
Re: Scala Macros: “Oh God Why?”
#10The author doesn't even know what macros are: "I understand macros to provide two things (1) forced code in-lining and (2) a kind of non-strict semantics or lazy evaluation of arguments"
What else do you think macros provide? As a former professional Common Lisp dev, those two features strike me as the real difference between a macro and function call.
For Common Lisp, think also of reader macros.
Similarly, in syntactically richer languages, macros could add syntactic constructs that are not akin to function application. With sufficiently powerful macros, you can add, for example, new infix operators, a new form of switch/case or a new way to declare variables.