Hacker News Reader

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.

Minor correction: Coda isn't our CEO.

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.

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.

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.

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.

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

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.

Yup. This week's cabal anguish:

http://www.reddit.com/r/haskell/comments/qxopq/announcing_th...

http://www.reddit.com/r/haskell/comments/qwj5j/the_cabal_of_...

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.