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

71–80 of 152 posts

Re: True Scala complexity

#71

Post by awj »

ezyang wrote: post #47
awj wrote: post #39

Earlier quoted context omitted.

> Truly advanced, and dangerously powerful, features such as implicit conversions and higher-kinded types will in the future be enabled only under a special compiler flag. The flag will come with documentation that if you enable it, you take the responsibility. Haskell (well, the GHC compiler) has been doing this kind of things for ages. They even take the further step (which I agree with) of requiring that "dangerou…

Note that this is not perfect; frequently, in order to use a module using some language features, you need to enable these language features yourself (the interface may be in-expressible without the language extensions!) But they don't seem to obtrusive because most of the language features aren't actually that controversial. I've written about how the features interrelate here: http://blog.ezyang.com/2011/03/type-te…

Yeah, I expect, if Scala were to go this route, much the same would happen in regards to "inheriting" language features. Sometimes you can neatly tuck them away in the library, sometimes they spill out into calling code. At the least they give you some indication of what you're getting yourself into. I don't really consider that aspect of it to be a problem.

I think Scala has a few tools that, like multiple inheritance in C++ or Haskell's MultiParameterTypeClass, need to have a bit of a warning label so people avoid them until the situation screams for it.

Re: True Scala complexity

#72

Post by hythloday »

reinhardt wrote: post #29

Just wow. My eyes started glazing over at "views don’t chain. Instead, use view bounds" and he completely lost me on the next slide with generics. I had Scala in my mental TODO/Maybe list but after skimming over this post I think I'll pass.

I'd have the opposite reaction, I think: I'd want to learn a language because it introduced new concepts (and thus, terminology). It seems to me that it's a bit pointless to learn a language if you already intimately understand its theoretical underpinnings.

Re: True Scala complexity

#73

Post by Peaker »

modersky wrote: post #32

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

> Even with the flag disabled, Scala will be a more powerful language than any of the alternatives I can think of.

How is Scala more powerful than Haskell, Agda, or Coq?

Re: True Scala complexity

#74

Post by ezyang »

awj wrote: post #71
ezyang wrote: post #47

Earlier quoted context omitted.

Note that this is not perfect; frequently, in order to use a module using some language features, you need to enable these language features yourself (the interface may be in-expressible without the language extensions!) But they don't seem to obtrusive because most of the language features aren't actually that controversial. I've written about how the features interrelate here: http://blog.ezyang.com/2011/03/type-te…

Yeah, I expect, if Scala were to go this route, much the same would happen in regards to "inheriting" language features. Sometimes you can neatly tuck them away in the library, sometimes they spill out into calling code. At the least they give you some indication of what you're getting yourself into. I don't really consider that aspect of it to be a problem. I think Scala has a few tools that, like multiple inheritan…

MultiParameterTypeClasses are a fine feature! It's the ones like UndecidableInstances that you have to be careful about.

Re: True Scala complexity

#75

Post by modersky »

xyzzyrz wrote: post #62
modersky wrote: post #32

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

Ugh, sorry about comments being disabled. No idea how that happened; should be fixed now. I do want to hear feedback, flames and all, so finding that comments were off this whole time was disappointing for me too. I assure you I didn't stroll through L3. I've been using Scala for half a decade and I'm still learning it. Your reply is a bit disheartening. I don't know how else to convince you, as a long-time user of y…

Sorry for my misunderstanding regarding comments. I got frustrated by some recent Scala bashing posts that had comments disabled, and mistakenly assumed there was a pattern. I meant to respond directly to your blog, but now that the discussion on HN is in full swing, we should keep it here.

As someone who struggled myself for a long time with the design of collections until the pieces fell into place, I can understand your struggles very well. In every language there is a limit of what can be achieved, and there is a grey zone before that where things get messy. I believe that Scala collections pushed the envelope in terms of flexibility and ease of use. But repeating this feat by extending all kinds of collections and collection-like structures generically with your own operations is not at all trivial.

You are absolutely right to point out when things get messy of course, even if it would be only to serve as a warning to others who might follow you.

The question is how to avoid similar experiences in the future. One can either change the language to make simple what you found hard. But before I buy into that, I would like to see a constructive and complete proposal what one should change.

Or, one could make a better effort to delineate the limits and the grey zone. That's what I proposed. Importantly, my proposal would only apply to definitions not to usages. So I'd put implicit conversions and definitions with higher-kinded types behind a flag, but not their uses. I hope this would give pause to library designers that mix advanced features with too much abandon, but it would not hinder users of these libraries at all.

Re: True Scala complexity

#76

Post by knuttycombe »

modersky wrote: post #32

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

Implicit conversions (and implicit parameter substitution) are just about the most important feature of the Scala language, from my perspective, and I don't think it makes any sense to hide this behind a compiler switch.

Just about every modern Scala library depends upon the "implicit typeclass pattern" - many of which require that you define your own typeclasses for your own code, or at least are able to correctly create instances of framework-provided typeclasses in the appropriate implicit scope, if for no other reason than to help out the Scala compiler when it can't correctly resolve an implicit. If you start to push implicits behind a compiler flag, this will mean that fewer people will be familiar with their subtleties, and will consequently become more utterly lost when the framework provided to them becomes insufficient to satisfy their goals.

Indeed, I'd suggest that the entire history of the advancement of the Scala library ecosystem could be described as the process of the community learning to use implicits to greater and greater effect. It makes no sense to me to hobble developers by marking a feature "off limits" by default - I know that for my own usage, Scala's benefits only really became evident once I understood implicits; before that, it was simply a slightly better Java. With implicits, it's a tool that makes Java look like COBOL.

Re: True Scala complexity

#77

Post by awj »

ezyang wrote: post #74
awj wrote: post #71

Earlier quoted context omitted.

Yeah, I expect, if Scala were to go this route, much the same would happen in regards to "inheriting" language features. Sometimes you can neatly tuck them away in the library, sometimes they spill out into calling code. At the least they give you some indication of what you're getting yourself into. I don't really consider that aspect of it to be a problem. I think Scala has a few tools that, like multiple inheritan…

MultiParameterTypeClasses are a fine feature! It's the ones like UndecidableInstances that you have to be careful about.

They are, until someone makes a five parameter monster because "someday I'll want that genericity." To be honest, though, I just googled the extensions I could remember until I hit one that hinted at creating a situation where the compiler simply doesn't have enough information to compile your code.

That said, yeah, UndecidableInstances look like a much better example. Especially when googling it turns up things like this: http://lukepalmer.wordpress.com/2008/04/08/stop-using-undeci...

Re: True Scala complexity

#78

Post by awj »

joshhart wrote: post #69
modersky wrote: post #32

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

Please don't do that. I don't want to go work for some Scala shop or team in the future and find out that I'm limited to L1-only features because of management practice.

...what is to stop them from doing it now? I don't think you can fix management problems at the programming language level. Also, at least for the next five years, I doubt you'll have to worry much about those kinds of shops deciding to pick up Scala.

Re: True Scala complexity

#79

Post by soc88 »

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…

> 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

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

Sorry, but there is a bit more to it. I will gladly accept a link to a language which does all the stuff he was trying to do, but until then I'm not convinced at all.

Re: True Scala complexity

#80

Post by soc88 »

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…

You pretty much point to solutions which don't solve the problem mentioned in the blog post at all and seeing how C# extension methods basically reintroduced instanceOf checks as an implementation necessity I'm pretty sure that extension methods are the wrong way to go.
Post reply on HN