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

21–30 of 57 posts

Re: Scala Macros: “Oh God Why?”

#21

Post by cageface »

CookWithMe wrote: post #5
vrotaru wrote: post #2

I 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).

As much as I personally like Scala I understand why a lot of people are taking a wait & see attitude. I think it's not too unreasonable to imagine that a less ambitious Java++ like Kotlin might find the traction that has so far eluded Scala.

Re: Scala Macros: “Oh God Why?”

#22

Post by sausagefeet »

billjings wrote: post #16

I'd like to single out this line from the linked article: "Unlike Java, type signatures in Scala don’t really explain idiomatic usage to mortals very well." This is a great diagnosis of one of the big issues with Scala's style of static typing. Everyone knows that the type descriptions take a bit to grok compared to a C-style languages. Why? Well, in C-style languages, a function definition is itself a representation…

Ii have not used Scala but I have found the opposite to be true in Ocaml and Haskell. The type definition of a function is quite often sufficient information to infer the usage. I think this is because of the type variables. Looking at the definition of fold in Ocaml, for example, it becomes very obvious what is the input output init and the signature of your function from the type where such information generally seems to be less clear in C-like languages.

Re: Scala Macros: “Oh God Why?”

#23

Post by hp »

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.

The Scala community is more of a blend on this front. It has FP aficionados, but it's also in production use and has commercial contributors focusing on practical issues. If Scala continues to gain popularity, it will probably continue to get more of a practical focus (there are only so many FP geeks in the world).

The other thing with Scala is that it compiles to bytecode; once compiled, it's just Java. And you can always use any Java library. So there's that base of a very solid JVM runtime and very solid ecosystem of libraries that's always there.

Re: Scala Macros: “Oh God Why?”

#24

Post by soc88 »

sausagefeet wrote: post #22
billjings wrote: post #16

I'd like to single out this line from the linked article: "Unlike Java, type signatures in Scala don’t really explain idiomatic usage to mortals very well." This is a great diagnosis of one of the big issues with Scala's style of static typing. Everyone knows that the type descriptions take a bit to grok compared to a C-style languages. Why? Well, in C-style languages, a function definition is itself a representation…

Ii have not used Scala but I have found the opposite to be true in Ocaml and Haskell. The type definition of a function is quite often sufficient information to infer the usage. I think this is because of the type variables. Looking at the definition of fold in Ocaml, for example, it becomes very obvious what is the input output init and the signature of your function from the type where such information generally se…

The same is pretty much true with Scala.

The only exception where the signatures are really long and complex are parts of the collection infrastructure, because Scala developers tried to make it work as intuitively for users as possible: E.g. making non-collection classes support collection operations, always returning the most "precise" type, etc. etc, which is very hard and painful work not done in any other language to this day.

In the end while I hope signatures get shorter and more like the use case signatures already existing in documentation, I don't think it matters much.

Untyped languages have more or less no useful signature at all and they are still pretty much alive.

Re: Scala Macros: “Oh God Why?”

#25

Post by sreque »

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 language: this is what Martin Odersky had to say on the subject (see http://www.scala-lang.org/node/12494):

"The intention of macros, and of Scala's language design in general, is to simplify things. We have already managed to replace code lifting by macros, and hopefully other features will follow.... Optimizations such as on Range.foreach are another use case. I believe that in the long run macros can be a simplifying factor."

Macros therefore can actually satisfy at least one of the complaints the Yammer CEO made about the language: slow foreach loops, along with simplifying the language in general.

Re: Scala Macros: “Oh God Why?”

#26

Post by fadzlan »

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…

You are right. But I think the point that the author makes is that pure(or almost pure) open source project will have only "interesting" contribution, where as by far what makes a programming language usable are those "unglamorous" fundamental things.

Yes, whoever contributes can choose whatever they wanted to contribute. But most successful project, companies or startup or anything else for that matter, involves doing things that most people would rather do, but necessary.

When you choose a programming language for your business, your business/life or anything related to it will depends on the language. I think its fair for anyone to choose a language to make sure those necessary boring stuff are robust in the language.

Those who contribute can choose what to contribute. Those who consume, can choose what they want to consume. Probably all of us have been on both side of the fence, so I would say its a fair assessment.

Re: Scala Macros: “Oh God Why?”

#27

Post by boredandroid »

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…

This would make sense if it were just a question of getting all the feature boxes checked off and implemented. The fact is though, in language design each feature tends to complicate everything else. For example, I suspect good error messages, debuggability, and IDE support are all set back by this.

Re: Scala Macros: “Oh God Why?”

#28

Post by sreque »

boredandroid wrote: post #27
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…

This would make sense if it were just a question of getting all the feature boxes checked off and implemented. The fact is though, in language design each feature tends to complicate everything else. For example, I suspect good error messages, debuggability, and IDE support are all set back by this.

Read my post in the same reply level. The creator of the language believes macros will actually make the language simpler. This is made possible by the fact that other language can be re-described and re-implemented in terms of macros, possibly even turning some language features into libraries. In his interview with InfoQ recently, we learn that his long-term goal is to decrease the size of the language in the future if possible. Directly from http://www.infoq.com/articles/odersky-scala-interview:

InfoQ: There has been some debate in the Scala community about the need to add features versus keeping it lean. Can you give us a sense of where Scala is headed? Does Scala need to become a bloated multiparadigm and multipurpose language to be considered mainstream?

Martin: I think the consensus is very much that we keep it lean. Scala is a compact language despite its enormous spread of use cases because it has always tried hard to unify things. The same concepts describe objects and functions and components. Instead of adding features, Scala has very powerful abstraction capabilities that let users define similar features themselves in libraries. In the future my ambition is to make Scala an smaller language, not a larger one. I know it is hard, but we will try.

Re: Scala Macros: “Oh God Why?”

#29

Post by noelwelsh »

smanek wrote: post #6
baconserker wrote: post #4

The 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.

Macros provide new binding constructs. That is their number one use in my 10+ years of Scheme programming.

Re: Scala Macros: “Oh God Why?”

#30

Post by noelwelsh »

fadzlan wrote: post #26
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…

You are right. But I think the point that the author makes is that pure(or almost pure) open source project will have only "interesting" contribution, where as by far what makes a programming language usable are those "unglamorous" fundamental things. Yes, whoever contributes can choose whatever they wanted to contribute. But most successful project, companies or startup or anything else for that matter, involves doi…

In this case the OP's point is moot because every single one of his gripes is being addressed by Typesafe, the company that is backing Scala. They have a team working on the Eclipse plugin. They have recently released a new documentation site. They are addressing binary compatibility with the Migration Manager. etc.
Post reply on HN