Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala Macros: “Oh God Why?”

blog.empathybox.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: Scala Macros: “Oh God Why?”

#41

Post by tikhonj »

cageface wrote: post #20
hp wrote: post #17

The bug in this post is thinking that if you have someone willing to contribute feature X to an open source project, they were also available to contribute feature Y. Open source patches are all itch-scratchings. For Scala macros, it's a researcher at EPFL, I believe. I don't think you could write a thesis about fixing bugs in the IDE. So this contributor was not available to submit IDE bugfixes; they _were_ availabl…

Sure, but the communities behind all the FP languages seem to share this same weakness. For obvious reasons, they attract people much more interested in hacking on funky compiler techniques than on mundane things like I/O libraries and documentation. In contrast, I think Python and Ruby both owe a lot of their success to the people willing to put a lot of energy and polish into this essential but less glamorous work.

I don't know, this has not been my experience with Haskell at all. Not only do plenty of people work on all sorts of libraries (there are some really great web frameworks, for example), but they also work on all sorts of "less interesting" stuff. For example, there are some people working to improve Hackage, which is the site that contains Haskell's libraries and their documentation, and Haskell has really good support in Emacs (which is much better than good IDE support!).

Re: Scala Macros: “Oh God Why?”

#42

Post by bkudria »

sreque wrote: post #25
hp wrote: post #17

The bug in this post is thinking that if you have someone willing to contribute feature X to an open source project, they were also available to contribute feature Y. Open source patches are all itch-scratchings. For Scala macros, it's a researcher at EPFL, I believe. I don't think you could write a thesis about fixing bugs in the IDE. So this contributor was not available to submit IDE bugfixes; they _were_ availabl…

I want to emphasize your post with even more information. I believe the person implementing macros is actually a first-year PhD student at EPFL and he decided to do his first major project on porting a Nemerle-like macro system to Scala ( http://www.scala-lang.org/node/10978 ). Of course he isn't going to do a project on making Scala's documentation as rock solid as PHP's! Also, as for why macros are being put in the…

Minor correction: Coda isn't our CEO.

Re: Scala Macros: “Oh God Why?”

#43

Post by gclaramunt »

mindslight wrote: post #32
smanek wrote: post #6

Earlier quoted context omitted.

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.

The other difference is (of course) what the macro returns - more code to be compiled, which enables things like binding of new symbols/types/etc. The most important part is that the generated code is adjacent to user code, so the two are lexically coupled. But in CL land, you probably take the codegen for granted and the lexical coupling doesn't matter as much. Although, Scala specifically, I ran away from. The lang…

what do you use when have to use the JVM?

Re: Scala Macros: “Oh God Why?”

#44

Post by anonymoushn »

soc88 wrote: post #15

I think many people share some concerns about macros, especially the need for good error messages. A far as I know Scala's language designers have been against including macros for a long time. So the proposal for macros has to be damn good if they change their opinion. Macros are supposed to be a replacement for writing compiler plugins in many cases (compare with Java annotation processing vs. Java compiler plugins…

As far as I can tell, value classes provide the performance of primitives with primitives. Is there a way to make a value class that contains more than one primitive, so that you could have semantics similar to those of a struct in C?

Re: Scala Macros: “Oh God Why?”

#45

Post by anonymoushn »

TylerE wrote: post #12
ghusbands wrote: post #10

Earlier quoted context omitted.

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.

Scala already has plenty of syntactic sugar for chaining method calls, so you can write stuff like: myObj explode 10 times which translates into myObk.explode.10.times() Through the magic of implicits, you can make any builtin type auto-cast to your wrapper type, so there really is no need for syntactic macros - scala is already DSL-enabled.

My experience has been that these features are great but not free. I often have to choose between writing expressive, elegant, DRY code that is mind-numbingly slow or writing Fortran in Scala. Much of the time our needs are better met by writing Fortran in Scala, but with a macro system it would at least be DRY Fortran.

Re: Scala Macros: “Oh God Why?”

#46

Post by mindslight »

gclaramunt wrote: post #43
mindslight wrote: post #32

Earlier quoted context omitted.

The other difference is (of course) what the macro returns - more code to be compiled, which enables things like binding of new symbols/types/etc. The most important part is that the generated code is adjacent to user code, so the two are lexically coupled. But in CL land, you probably take the codegen for granted and the lexical coupling doesn't matter as much. Although, Scala specifically, I ran away from. The lang…

what do you use when have to use the JVM?

The emergency exit. (sorry, couldn't help it)

I tried to use the JVM for a long time, I really did. I thought the advantages of multiple implementations, platform flexibility, and a common type system were fantastic. The fundamental problem is that no matter the skin, when you want to peek through the abstraction you're still fundamentally writing Java. I absolutely detest the Java language itself, as it's basically what should come out of a compiler, not be fed into one (I realize this criticism is about 15% unfair given that Java did actually introduce some new concepts to mainstream programming but implemented them in the VM rather than the compiler, but it has really failed to keep up with the times).

At this point if I were using the JVM, it would most likely be to make use of some hypothetical damn good libraries. In that case, as I'd be gluing together things that are already typed, I'd use whatever dynamic language seemed prudent. The Java type system is an everpresent fact of life on the JVM, and I'm now of the opinion that trying to use a second type abstraction concurrently is foolish (especially if one wants to run their code on anything other than Hotspot). I think Clojure is an amazing piece of work, and would still be using it, but its lack of importance on typed data structures really kills my ability to reason while developing new abstractions (the lack of well-supported algebraic data types and pattern matching especially). Taken together, those last two points imply that a statically typed JVM language has to utterly commit itself to the Java type system. If I absolutely needed to write a library on the JVM, I would look into and most likely go with Ceylon/Kotlin (or Gosu if they ever actually did a source release), but failing those probably write java-in-kawa for the straightforward class definitions with macros to ease the pain.

In any case, I'd be damn certain of exactly what I was writing beforehand. The Java ecosystem is absolute garbage for prototyping.

Re: Scala Macros: “Oh God Why?”

#47

Post by eli_gottlieb »

cageface wrote: post #20
hp wrote: post #17

The bug in this post is thinking that if you have someone willing to contribute feature X to an open source project, they were also available to contribute feature Y. Open source patches are all itch-scratchings. For Scala macros, it's a researcher at EPFL, I believe. I don't think you could write a thesis about fixing bugs in the IDE. So this contributor was not available to submit IDE bugfixes; they _were_ availabl…

Sure, but the communities behind all the FP languages seem to share this same weakness. For obvious reasons, they attract people much more interested in hacking on funky compiler techniques than on mundane things like I/O libraries and documentation. In contrast, I think Python and Ruby both owe a lot of their success to the people willing to put a lot of energy and polish into this essential but less glamorous work.

If you want the mundane stuff done, do it yourself or pay someone to do it for you.

Re: Scala Macros: “Oh God Why?”

#48

Post by retronym »

odersky wrote: post #34

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 c…

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.

Re: Scala Macros: “Oh God Why?”

#49

Post by cageface »

eli_gottlieb wrote: post #47
cageface wrote: post #20

Earlier quoted context omitted.

Sure, but the communities behind all the FP languages seem to share this same weakness. For obvious reasons, they attract people much more interested in hacking on funky compiler techniques than on mundane things like I/O libraries and documentation. In contrast, I think Python and Ruby both owe a lot of their success to the people willing to put a lot of energy and polish into this essential but less glamorous work.

If you want the mundane stuff done, do it yourself or pay someone to do it for you.

Around 2002-2003 I did put a lot of effort into improving the Common Lisp and OCaml ecosystems. My lesson learned was that there's only so much I can do as an individual and that the right kind of pragmatic culture has to exist beforehand.

Re: Scala Macros: “Oh God Why?”

#50

Post by cageface »

tikhonj wrote: post #41
cageface wrote: post #20

Earlier quoted context omitted.

Sure, but the communities behind all the FP languages seem to share this same weakness. For obvious reasons, they attract people much more interested in hacking on funky compiler techniques than on mundane things like I/O libraries and documentation. In contrast, I think Python and Ruby both owe a lot of their success to the people willing to put a lot of energy and polish into this essential but less glamorous work.

I don't know, this has not been my experience with Haskell at all. Not only do plenty of people work on all sorts of libraries (there are some really great web frameworks, for example), but they also work on all sorts of "less interesting" stuff. For example, there are some people working to improve Hackage, which is the site that contains Haskell's libraries and their documentation, and Haskell has really good suppo…

I haven't spent much time with Haskell lately but the last time I did Cabal was still way less polished and useful than Ruby's gem system or even Python's pip/distutils stuff. Robust, easy to use package management is step one in getting any new language off the ground, IMO.
Post reply on HN