4 ms·

Here's a random line from the Scala standard collections library: def :+[B >: A, That](elem: B)(implicit bf: CanBuildFrom[Repr, B, That]): That This is from t

by jbooth 12y ago

Here's a random line from the Scala standard collections library: def :+[B >: A, That](elem: B)(implicit bf: CanBuildFrom[Repr, B, That]): That This is from the standard collections library. In Java, I've got a List.add function. In case it's not clear from the name, 'add', I can click through to the implementation and it's pretty obvious what's happening. In Scala, I've got +, ++, +:, :+, and a bunch of other nonsensical bullshit, and when I click through to the implementation? Even less sense. Whenever I use a standard scala collection, I have no idea what it's actually doing. Additionally, everything favors allocation-happy overly-clever immutable wrappers rather than a simple ArrayList which will smoke those immutable implementations in real-world performance. The cure is far worse than the disease, here.

imanaccount247 12y ago
How on earth does "I don't like operators" support your claim?
- jbooth 12y ago
  The claim was that scala code is very difficult to read and idiomatic scala code, as evidenced by their collections library, brings along a ton of conceptual overhead that creates much more complexity than it eliminates. That line alone drives home the point for me, you can read the rest of scala.collection.immutable if you need more convincing.
  - yarou 12y ago
    First and foremost, I think you need to read about Blub. [0] Also, idiomatic Scala code is perfectly readable. You have no right to complain about readability until you've dealt with spaghetti code written for Megacorp Inc, that completely ignores the fundamentals of structured programming. :) [0] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
  - imanaccount247 12y ago
    The claim was that you need to know category theory. Your post is still there, we can still read it. It does not make much sense to pretend it says something other than what it says.
bad_user 12y ago
For a Scala developer that signature makes sense. You want to add an element of type B to your collection with elements of type A, however the addition of an element of type B may not be supported (e.g. you may want to add a String to a BitSet and get in return a plain Set[Any]), so the above works only as long as there is a builder available that can build the new collection. The function also works on covariant collections, because it's building a new collection (i.e. it's for immutable collections), so it doesn't have the covariance gotcha of arrays. Scala's collections have some quirks, but not as many as .NET's collections and you're actually comparing apples to oranges, because you won't find the equivalent of an "add" that returns a new collection instead of modifying the old one in .NET. This is what happens when you pass judgement unto things you don't understand. Working with immutable data-structures is really, really awesome and Scala's API for these collections is very friendly and very type-safe - as in, if you feel the need to use `isInstanceOf` / `asInstanceOf`, then you're probably doing something wrong ;-) And I really wish that C# would grow up a little in this regard, as modern programming languages need immutable collections as well, with a nice API to go along with it. And btw - working with Option is super awesome, no category theory needed. That said, as I was saying in another comment, I'm really excited about this announcement, because this is mostly about the runtime, not the language. You can run things built with Scala on top of .NET right now by means of IKVM. And the JVM finally has some credible competition.
- jbooth 12y ago
  I agree that Option types are great, so great that I'm happy to work in a much 'weaker' language, use option types, and solve 90% of the problems that more 'theoretically robust' languages address with none of their downsides. As far as not understanding how awesome immutable data structure are.. I'd take a step back before you make assumptions about what other people understand. Do you know anything about cache hierarchy and memory models on modern CPUs? Performance is important to some of us.
  - teacup50 12y ago
    > Do you know anything about cache hierarchy and memory models on modern CPUs? Yes. > Performance is important to some of us. ... and in those cases, you don't have to use data structures that model your problem domain poorly. The problem isn't "immutable data structures" or "theoretically robust" languages. The problem is finding ways to express computations and their constraints in a way that can be efficiently modeled for your problem domain.
teacup50 12y ago
You're conflating a lot of unrelated issues here by lashing out against things you seemingly don't understand.
yohanatan 12y ago
The operators on collections always have alternate named forms. I actually instinctively skip over the operators when perusing the documentation and have no trouble at all finding what I need.
ssmoot 12y ago
Pointing to CBF is a complete straw-man. You're rarely actually going to _see_ that signature (the docs actually simplify it for you), and in practice, it's completely meaningless to 99.9% of Scala you'll ever see. You might as well consider it pixie-dust. + for one, ++ to add a collection, the others are generally going to apply to Cons-like. It takes all of a couple minutes to let these sink in. Use a mutable.MutableList if that's what you want. Or just use ArrayList. All this is about as pure FUD as I've ever seen...
- hibikir 12y ago
  It isn't FUD: It's just the kind of thing that turns newbies out of Scala. Your typical Java developer is used to just look inside the code of whatever library they are using, and find a very straightforward implementation. Scala collections avoid a lot of boilerplate with canBuildFrom, SeqLike and suck, but simple and straightforward they are not. It takes quite a while before it stops reading like Japanese. And IMO yes, a lot of symbolic methods in collections make relatively little sense. Don't forget that list also has ::, :::, +:, :+ and :\. There's more than a few, and there are no textual versions of them, for those that don't have them all memorized. They are a bit of a relic from the time Martin thought that /: was a good idea. It's fortunate that now only the scalaz people keep doing such things, because excessive use of symbolic operations hurt language adoption. And he doesn't even get into other early confusion points, like how we have =>, <-, and ->, or how decomposing Seqs is not exactly pretty. Last week I had to help a guy that had been using Scala for 6 months to understand the 'punched in the face' operator :_* So no, it's definitely not FUD. Are they issues that hurt my day to day Scala use? Not at all. Scala is my favorite language. Being able to use it instead of Java or Clojure is worth a good 15K a year for me.But that doesn't mean that I have forgotten some of the little things that made the learning curve tough at first. Thanks the heavens that I managed to end up finding a Scala job where I could learn from one Bill Venners.
  - ssmoot 12y ago
    Maybe this is a Java developer thing. Everybody decried Ruby's 107 methods on Array. Then Fowler came out with "fluent-interfaces", and how often do you see someone make the claims that Ruby's Array is indicative of a general badness because it has a lot of methods and you can't memorize them all in an hour as a newbie? scala.collection is the same deal. :\? Sure it's not a good idea. I wouldn't debate that. Who uses that? foldLeft/foldRight. And what's the deal with trying to memorize the entire interface anyways? 8 or so years with Ruby, writing libraries with over 4 million downloads (https://rubygems.org/profiles/ssmoot https://rubygems.org/profiles/ssmoot), and there are definitely methods in Ruby's Array I'm unfamiliar with. So what? While :: and ::: look a little foreign, I don't think asking people to learn them if they want to work with Lists in a Functional manner is anymore difficult than learning what the "spaceship operator" does in Ruby. And it's optional. You don't have to use them. But they're usage will probably be the smaller part in the grand scheme of things. Pattern Matching and accomplishing functional recursion with immutable data is the bigger picture. Outside of that context (and the REPL I guess, for convenience) you're just not going to see either of those operators very often (IME). You don't use a "splat" (aka 'punched in the face'? That's a new one to me) operator very often. It's actually one of the few semi-pattern-matchy areas of Ruby so it comes pretty naturally for me. You don't become a pro overnight. You can trust I'd be teaching infrequently used idioms in Ruby to a developer who'd only been using it for six months. Been there, done that. ;-) I guess where I'm coming from is using CBF to claim Scala is a confusing, indecipherable language. Everyone's had that argument. I don't know that anyone wants to stand up and claim it's the best. But it works. Actually using it is a non-issue since you don't actually explicitly use it. And look at the docs. They're actually pretty great overall. It just bothers me I suppose that someone interested in exploring Scala would be dissuaded by something that's only ever been a problem for 1% of 1% of Scala developers. If you're just looking to swap in Play to replace Rails, odds are you'll never run into any of these CBF "concerns". At all. That's the very definition of "FUD" IMO. For every CBF in Scala there's a Calendar in Java. Languages aren't perfect. CBF is probably a wart. But it's a hidden one. If you let it scare you off from Scala that's sad, because it really has about as much to do with day to day Scala development as array.c (https://github.com/ruby/ruby/blob/trunk/array.c https://github.com/ruby/ruby/blob/trunk/array.c) has to do with Ruby development.

by jbooth 12y ago

imanaccount247 12y ago

How on earth does "I don't like operators" support your claim?

jbooth 12y ago
The claim was that scala code is very difficult to read and idiomatic scala code, as evidenced by their collections library, brings along a ton of conceptual overhead that creates much more complexity than it eliminates. That line alone drives home the point for me, you can read the rest of scala.collection.immutable if you need more convincing.
- yarou 12y ago
  First and foremost, I think you need to read about Blub. [0] Also, idiomatic Scala code is perfectly readable. You have no right to complain about readability until you've dealt with spaghetti code written for Megacorp Inc, that completely ignores the fundamentals of structured programming. :) [0] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- imanaccount247 12y ago
  The claim was that you need to know category theory. Your post is still there, we can still read it. It does not make much sense to pretend it says something other than what it says.

bad_user 12y ago

For a Scala developer that signature makes sense. You want to add an element of type B to your collection with elements of type A, however the addition of an element of type B may not be supported (e.g. you may want to add a String to a BitSet and get in return a plain Set[Any]), so the above works only as long as there is a builder available that can build the new collection. The function also works on covariant collections, because it's building a new collection (i.e. it's for immutable collections), so it doesn't have the covariance gotcha of arrays. Scala's collections have some quirks, but not as many as .NET's collections and you're actually comparing apples to oranges, because you won't find the equivalent of an "add" that returns a new collection instead of modifying the old one in .NET. This is what happens when you pass judgement unto things you don't understand. Working with immutable data-structures is really, really awesome and Scala's API for these collections is very friendly and very type-safe - as in, if you feel the need to use `isInstanceOf` / `asInstanceOf`, then you're probably doing something wrong ;-) And I really wish that C# would grow up a little in this regard, as modern programming languages need immutable collections as well, with a nice API to go along with it. And btw - working with Option is super awesome, no category theory needed. That said, as I was saying in another comment, I'm really excited about this announcement, because this is mostly about the runtime, not the language. You can run things built with Scala on top of .NET right now by means of IKVM. And the JVM finally has some credible competition.

jbooth 12y ago
I agree that Option types are great, so great that I'm happy to work in a much 'weaker' language, use option types, and solve 90% of the problems that more 'theoretically robust' languages address with none of their downsides. As far as not understanding how awesome immutable data structure are.. I'd take a step back before you make assumptions about what other people understand. Do you know anything about cache hierarchy and memory models on modern CPUs? Performance is important to some of us.
- teacup50 12y ago
  > Do you know anything about cache hierarchy and memory models on modern CPUs? Yes. > Performance is important to some of us. ... and in those cases, you don't have to use data structures that model your problem domain poorly. The problem isn't "immutable data structures" or "theoretically robust" languages. The problem is finding ways to express computations and their constraints in a way that can be efficiently modeled for your problem domain.

teacup50 12y ago

You're conflating a lot of unrelated issues here by lashing out against things you seemingly don't understand.

yohanatan 12y ago

The operators on collections always have alternate named forms. I actually instinctively skip over the operators when perusing the documentation and have no trouble at all finding what I need.

ssmoot 12y ago

Pointing to CBF is a complete straw-man. You're rarely actually going to _see_ that signature (the docs actually simplify it for you), and in practice, it's completely meaningless to 99.9% of Scala you'll ever see. You might as well consider it pixie-dust. + for one, ++ to add a collection, the others are generally going to apply to Cons-like. It takes all of a couple minutes to let these sink in. Use a mutable.MutableList if that's what you want. Or just use ArrayList. All this is about as pure FUD as I've ever seen...

hibikir 12y ago
It isn't FUD: It's just the kind of thing that turns newbies out of Scala. Your typical Java developer is used to just look inside the code of whatever library they are using, and find a very straightforward implementation. Scala collections avoid a lot of boilerplate with canBuildFrom, SeqLike and suck, but simple and straightforward they are not. It takes quite a while before it stops reading like Japanese. And IMO yes, a lot of symbolic methods in collections make relatively little sense. Don't forget that list also has ::, :::, +:, :+ and :\. There's more than a few, and there are no textual versions of them, for those that don't have them all memorized. They are a bit of a relic from the time Martin thought that /: was a good idea. It's fortunate that now only the scalaz people keep doing such things, because excessive use of symbolic operations hurt language adoption. And he doesn't even get into other early confusion points, like how we have =>, <-, and ->, or how decomposing Seqs is not exactly pretty. Last week I had to help a guy that had been using Scala for 6 months to understand the 'punched in the face' operator :_* So no, it's definitely not FUD. Are they issues that hurt my day to day Scala use? Not at all. Scala is my favorite language. Being able to use it instead of Java or Clojure is worth a good 15K a year for me.But that doesn't mean that I have forgotten some of the little things that made the learning curve tough at first. Thanks the heavens that I managed to end up finding a Scala job where I could learn from one Bill Venners.
- ssmoot 12y ago
  Maybe this is a Java developer thing. Everybody decried Ruby's 107 methods on Array. Then Fowler came out with "fluent-interfaces", and how often do you see someone make the claims that Ruby's Array is indicative of a general badness because it has a lot of methods and you can't memorize them all in an hour as a newbie? scala.collection is the same deal. :\? Sure it's not a good idea. I wouldn't debate that. Who uses that? foldLeft/foldRight. And what's the deal with trying to memorize the entire interface anyways? 8 or so years with Ruby, writing libraries with over 4 million downloads (https://rubygems.org/profiles/ssmoot https://rubygems.org/profiles/ssmoot), and there are definitely methods in Ruby's Array I'm unfamiliar with. So what? While :: and ::: look a little foreign, I don't think asking people to learn them if they want to work with Lists in a Functional manner is anymore difficult than learning what the "spaceship operator" does in Ruby. And it's optional. You don't have to use them. But they're usage will probably be the smaller part in the grand scheme of things. Pattern Matching and accomplishing functional recursion with immutable data is the bigger picture. Outside of that context (and the REPL I guess, for convenience) you're just not going to see either of those operators very often (IME). You don't use a "splat" (aka 'punched in the face'? That's a new one to me) operator very often. It's actually one of the few semi-pattern-matchy areas of Ruby so it comes pretty naturally for me. You don't become a pro overnight. You can trust I'd be teaching infrequently used idioms in Ruby to a developer who'd only been using it for six months. Been there, done that. ;-) I guess where I'm coming from is using CBF to claim Scala is a confusing, indecipherable language. Everyone's had that argument. I don't know that anyone wants to stand up and claim it's the best. But it works. Actually using it is a non-issue since you don't actually explicitly use it. And look at the docs. They're actually pretty great overall. It just bothers me I suppose that someone interested in exploring Scala would be dissuaded by something that's only ever been a problem for 1% of 1% of Scala developers. If you're just looking to swap in Play to replace Rails, odds are you'll never run into any of these CBF "concerns". At all. That's the very definition of "FUD" IMO. For every CBF in Scala there's a Calendar in Java. Languages aren't perfect. CBF is probably a wart. But it's a hidden one. If you let it scare you off from Scala that's sad, because it really has about as much to do with day to day Scala development as array.c (https://github.com/ruby/ruby/blob/trunk/array.c https://github.com/ruby/ruby/blob/trunk/array.c) has to do with Ruby development.