Live data from Hacker News

Scala Macros: “Oh God Why?”

blog.empathybox.com

51–57 of 57 posts

Re: Scala Macros: “Oh God Why?”

#51
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…

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.

Re: Scala Macros: “Oh God Why?”

#52

Earlier quoted context omitted.

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 point is not whether you have sufficient information to infer the usage. Do you have to infer the idiom at all? Usage is homomorphic with declaration in C, so this step is unnecessary.

I don't follow what you mean, I'm saying a list of function types contains vastly more useful information than a list of C function types.

Re: Scala Macros: “Oh God Why?”

#53
post #12

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.

It translates to myObk.explode(10).times.

Re: Scala Macros: “Oh God Why?”

#54
post #41

Earlier quoted context omitted.

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.

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

Re: Scala Macros: “Oh God Why?”

#55
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…

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

Re: Scala Macros: “Oh God Why?”

#56
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…

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.

Re: Scala Macros: “Oh God Why?”

#57
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…

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?
Post reply on HN