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

True Scala complexity

yz.mit.edu

Post reply on HN
Print view View original

11–20 of 152 posts

Re: True Scala complexity

#11

Post by jobeirne »

dkhenry wrote: post #7
jashkenas wrote: post #3

Fantastic post. The most salient excerpt for me: def filterMap[B,D](f: A => Option[B])(implicit b: CanBuildFrom[?,B,D]): D def filterMap[B,D Option[B])(implicit b: CanBuildFrom[?,B,D]): D def filterMap[B,D Option[B])(implicit b: CanBuildFrom[?,B,D]): D def filterMap[B,D[B]](f: A => Option[B])(implicit b: CanBuildFrom[?,B,D[B]]): D[B] def filterMap[B,D[B] Option[B])(implicit b: CanBuildFrom[?,B,D[B]]): D[B] def filter…

That is a nice feature of dynamic languages, however you lose strong typing. I think the thing to take away is Scala hasn't gotten the perfect blend of these two yet. You can't make that competly generic map filtering extension yet. However you can make a less portable alternative. So you make you decision on what is more important.

> however you lose strong typing

You lose static typing; strong typing is different: http://en.wikipedia.org/wiki/Strong_typing

Re: True Scala complexity

#12

Post by akeefer »

jashkenas wrote: post #3

Fantastic post. The most salient excerpt for me: def filterMap[B,D](f: A => Option[B])(implicit b: CanBuildFrom[?,B,D]): D def filterMap[B,D Option[B])(implicit b: CanBuildFrom[?,B,D]): D def filterMap[B,D Option[B])(implicit b: CanBuildFrom[?,B,D]): D def filterMap[B,D[B]](f: A => Option[B])(implicit b: CanBuildFrom[?,B,D[B]]): D[B] def filterMap[B,D[B] Option[B])(implicit b: CanBuildFrom[?,B,D[B]]): D[B] def filter…

In Gosu, it's pretty much the same (though enhancements are statically dispatched and thus subject to a different set of limitations):

enhancement MyEnhancement : T[] { function filterMap() { . . . } }

Roughly the same in C# with extension methods, though with C# you explicitly import the extension method while in Gosu they're automatically always there (sort of good, sort of bad). Again, not exactly the same as the dynamic language examples, but enhancements/extension methods do allow you to extend existing classes in a reasonable fashion while still being amenable to all the other advantages static typing gives you.

Re: True Scala complexity

#13

Post by xyzzyrz »

harryh wrote: post #8

A lot of the items the post author describes as complex you can't do at all in other languages. "Simple things should be simple, complex things should be possible." - Alan Kay I don't think the blog author gives particularly great examples of simple things that are made complex by the language. He simply gives examples of things that are inherently complex that scala at least makes possible.

"Notice how several of the problems I pinpoint above are of the form, “How do I accomplish this expression that isn’t even possible in many other languages?” And these are mostly static build issues, which are far from the worst fates imaginable. Certainly, if you don’t care at all about clumsy code or resorting to escape hatches or “writing Java in Scala,” it’s frequently possible to bang out mostly-type-safe Scala while side-stepping battles against the compiler straitjacket. Plus, let’s not lose sight of all the things Scala brings to the table, none of which I’ve described. If there’s one thing more time-consuming than illustrating the complexities of the Scala language, it’s illustrating all the advantages, and I’ve already spent more time on this post than I’d care to admit."

Re: True Scala complexity

#14

Post by akeefer »

harryh wrote: post #8

A lot of the items the post author describes as complex you can't do at all in other languages. "Simple things should be simple, complex things should be possible." - Alan Kay I don't think the blog author gives particularly great examples of simple things that are made complex by the language. He simply gives examples of things that are inherently complex that scala at least makes possible.

I have to respectfully disagree. First of all, the things he shows aren't inherently complex: adding an additional function to the existing collections library is something that's possible in other languages in less confusing ways (see other examples in this post). The various concepts required to solve the problem in Scala like implicits and higher kinds might be inherently complex, but the problem he's trying to solve isn't inherently complex. And while the Scala solution might not be 100% identical to, say, just adding the method directly to a class in Ruby (since in Scala it's type-safe, etc. etc.) that's still missing the point. The point is that if you sit down and say "I want to add a method to all my collections that works like the existing methods," in Scala it requires an understanding of a huge number of complicated intersecting concepts, whereas in other languages it doesn't.

Secondly, excusing complexity by saying "it makes things possible that wouldn't otherwise be possible" isn't really enough of a justification. The question is: do those exact things need to be possible? Or is there some way that gets me 90% of the way there without the complexity, and that's good enough? More power isn't always better, which was a big part of the point of the article. Just dismissing it by saying "well, the complexity lets you do powerful things" doesn't really refute the point of the article, it totally misses it.

There's a tradeoff to be made. You might make those tradeoffs differently than I would, which is totally understandable, but we should at least be able to have a conversation about the fact that there is such a tradeoff without people dimissing statements like "Scala is complex" out-of-hand.

Re: True Scala complexity

#15

Post by harryh »

akeefer wrote: post #14
harryh wrote: post #8

A lot of the items the post author describes as complex you can't do at all in other languages. "Simple things should be simple, complex things should be possible." - Alan Kay I don't think the blog author gives particularly great examples of simple things that are made complex by the language. He simply gives examples of things that are inherently complex that scala at least makes possible.

I have to respectfully disagree. First of all, the things he shows aren't inherently complex: adding an additional function to the existing collections library is something that's possible in other languages in less confusing ways (see other examples in this post). The various concepts required to solve the problem in Scala like implicits and higher kinds might be inherently complex, but the problem he's trying to so…

"adding an additional function to the existing collections library is something that's possible in other languages"

Is it possible in other statically compiled strongly typed languages? I don't think so?

The advantages/disadvantages of static vs. dynamic languages seem out of scope for the "is scala too complex?" question.

Re: True Scala complexity

#16

Post by harryh »

xyzzyrz wrote: post #13
harryh wrote: post #8

A lot of the items the post author describes as complex you can't do at all in other languages. "Simple things should be simple, complex things should be possible." - Alan Kay I don't think the blog author gives particularly great examples of simple things that are made complex by the language. He simply gives examples of things that are inherently complex that scala at least makes possible.

"Notice how several of the problems I pinpoint above are of the form, “How do I accomplish this expression that isn’t even possible in many other languages?” And these are mostly static build issues, which are far from the worst fates imaginable. Certainly, if you don’t care at all about clumsy code or resorting to escape hatches or “writing Java in Scala,” it’s frequently possible to bang out mostly-type-safe Scala…

Yes, the post author says much the same thing as I just did. I just thought it was worth specifically mentioning in the discussion thread (in case some people didn't make it all the way through the blog post).

Re: True Scala complexity

#17

Post by akeefer »

harryh wrote: post #15
akeefer wrote: post #14

Earlier quoted context omitted.

I have to respectfully disagree. First of all, the things he shows aren't inherently complex: adding an additional function to the existing collections library is something that's possible in other languages in less confusing ways (see other examples in this post). The various concepts required to solve the problem in Scala like implicits and higher kinds might be inherently complex, but the problem he's trying to so…

"adding an additional function to the existing collections library is something that's possible in other languages" Is it possible in other statically compiled strongly typed languages? I don't think so? The advantages/disadvantages of static vs. dynamic languages seem out of scope for the "is scala too complex?" question.

See my examples below for how to do it in Gosu (via enhancements). In C# it's pretty much the same (via extension methods). Both are statically typed languages. Again, not 100% the same as Scala, and each comes with a different set of tradeoffs than the Scala approach (i.e. they're statically dispatched in Gosu), but they're certainly both reasonable, and much "simpler", solutions to the problem of "how do I add a filterMap function to all arrays or collections that works pretty much how I want it to."

Re: True Scala complexity

#18

Post by harryh »

akeefer wrote: post #17
harryh wrote: post #15

Earlier quoted context omitted.

"adding an additional function to the existing collections library is something that's possible in other languages" Is it possible in other statically compiled strongly typed languages? I don't think so? The advantages/disadvantages of static vs. dynamic languages seem out of scope for the "is scala too complex?" question.

See my examples below for how to do it in Gosu (via enhancements). In C# it's pretty much the same (via extension methods). Both are statically typed languages. Again, not 100% the same as Scala, and each comes with a different set of tradeoffs than the Scala approach (i.e. they're statically dispatched in Gosu), but they're certainly both reasonable, and much "simpler", solutions to the problem of "how do I add a fi…

Very interesting. I'm gonna go read more about this stuff now. Thanks!

Re: True Scala complexity

#19

Post by nickik »

dkhenry wrote: post #6

After reading a bunch of these articles and really walking away unimpressed this one is fantastic. It does a great job of showing how cryptic you can make Scala code. It also shows that the same topic on which half the article is spent explaining can be boiled down to four lines of less "Scala Like" code. As a pragmatic user of Scala I don't see why the fact that you _can_ do some amazing but cryptic things with the…

Some languages show that you can do these things in a simple way. For example I impmentet a Persisten Vector for Dylan (very common lisp like language) in about 3 sessions. It was the first time I wrote dylan code befor that I only read on dylan. Its working and fiels like a "native" collection allready.

I guess it would take me the same amount of time fully understand this article. Other people in this thread have shown how easy it is in other languages too.

Re: True Scala complexity

#20

Post by [deleted] »

cgh wrote: post #10
dkhenry wrote: post #7

Earlier quoted context omitted.

That is a nice feature of dynamic languages, however you lose strong typing. I think the thing to take away is Scala hasn't gotten the perfect blend of these two yet. You can't make that competly generic map filtering extension yet. However you can make a less portable alternative. So you make you decision on what is more important.

Just to be pedantic, you lose static typing. Ruby (and Python, etc.) are strongly, dynamically typed languages.

[deleted]
Post reply on HN