4 ms·

I'm in the midst of learning Scala, and I assure you I'm motivated to learn it. However, at first pass, it appears to include all the worst aspects of Perl, Py

by steven2012 12y ago

I'm in the midst of learning Scala, and I assure you I'm motivated to learn it. However, at first pass, it appears to include all the worst aspects of Perl, Python, etc. The one thing I hate is when a language has multiple ways to do things, and you have to memorize them because it's not obvious. This is why I despise Perl with all my heart. For example, the whole "class.function(x)" being equivalent to "class function x" annoys the hell out of me. Having _ as a overloaded magic symbol is another perlism that also annoys me. It either means the implied array member in a function OR it is used to tell the compile that you're passing in a function to a variable. I hate this. Why bother using the same magic symbol? There are a ton of other things about Scala like this that I hate because it's non-obvious and things you just have to memorize. That said, I'm still motivated to learn it and understand Scala, but I'm worried I'm wasting my time.

eklavya 12y ago
> Having _ as a overloaded magic symbol is another perlism that also annoys me. It either means the implied array member in a function OR it is used to tell the compile that you're passing in a function to a variable. I hate this. I have no idea what you are talking about.
- zak_mc_kracken 12y ago
  He's probably referring to the passing of partially applied functions. I've never quite understood why you need `_` as well: you are already defining your function with the strange Curry syntax (f(param1)(param2)), you shouldn't need to pass "f _" to tell the compiler that on top.
hibikir 12y ago
Being able to use dots and parenthesis or not has a very good reason for being: It makes the concept of operators disappear. In a custom class, a + b is the same as a.+(b), instead of doing it the Java way, where blessed Java libraries can do things that are impossible for my own extensions. The C++ way of supporting such a thing relies on very specific sequences of what can be an operator, and what cannot, making things actually harder. At the cost of making writing in-language DSL easier, like the one in ScalaTest, the language lets people do really ugly things, if they don't like other people reading their code. It's a tradeoff. I like to be able to have an assertion that goes " myVal should contain("A")", and that be valid ScalaTest code, with very good error handling, but I see how others can disagree. Undescore is overloaded in a few more ways that you are listing too, as a wild card in case statements and type definitions. My favorite is how we can turn a sequence into a vararg by using the Punched-In-The-Face operator, :_. That nonsense really means that we are providing a type annotation (:), and the actual type to use should be whatever it is(_), but as a vararg (). If you know the exact type, you could go : Int, but really, :_ works the same way. Now, as you go through Scala, the darkest realization is not that it has too many features, but that it's possible reach a point where you think it doesn't have enough. I have spent most of the week bemoaning the fact that shapeless' HLists are not anywhere near as easy to use as I'd like because the type system needs even more power.
- sagichmal 12y ago
  > I like to be able to have an assertion that > goes "myVal should contain("A")", and that > be valid ScalaTest code, with very good error > handling, but I see how others can disagree. This is so clearly a false economy! What you gain there in expressiveness you lose tenfold in ambiguity — and not just in that line, but in the latticework of exceptions you now have to keep suspended in your mind as you read every other line of code. It just doesn't make sense to me that you'd prefer things that way.

eklavya 12y ago

> Having _ as a overloaded magic symbol is another perlism that also annoys me. It either means the implied array member in a function OR it is used to tell the compile that you're passing in a function to a variable. I hate this. I have no idea what you are talking about.

zak_mc_kracken 12y ago
He's probably referring to the passing of partially applied functions. I've never quite understood why you need `_` as well: you are already defining your function with the strange Curry syntax (f(param1)(param2)), you shouldn't need to pass "f _" to tell the compiler that on top.

hibikir 12y ago

Being able to use dots and parenthesis or not has a very good reason for being: It makes the concept of operators disappear. In a custom class, a + b is the same as a.+(b), instead of doing it the Java way, where blessed Java libraries can do things that are impossible for my own extensions. The C++ way of supporting such a thing relies on very specific sequences of what can be an operator, and what cannot, making things actually harder. At the cost of making writing in-language DSL easier, like the one in ScalaTest, the language lets people do really ugly things, if they don't like other people reading their code. It's a tradeoff. I like to be able to have an assertion that goes " myVal should contain("A")", and that be valid ScalaTest code, with very good error handling, but I see how others can disagree. Undescore is overloaded in a few more ways that you are listing too, as a wild card in case statements and type definitions. My favorite is how we can turn a sequence into a vararg by using the Punched-In-The-Face operator, :_. That nonsense really means that we are providing a type annotation (:), and the actual type to use should be whatever it is(_), but as a vararg (). If you know the exact type, you could go : Int, but really, :_ works the same way. Now, as you go through Scala, the darkest realization is not that it has too many features, but that it's possible reach a point where you think it doesn't have enough. I have spent most of the week bemoaning the fact that shapeless' HLists are not anywhere near as easy to use as I'd like because the type system needs even more power.

sagichmal 12y ago
> I like to be able to have an assertion that > goes "myVal should contain("A")", and that > be valid ScalaTest code, with very good error > handling, but I see how others can disagree. This is so clearly a false economy! What you gain there in expressiveness you lose tenfold in ambiguity — and not just in that line, but in the latticework of exceptions you now have to keep suspended in your mind as you read every other line of code. It just doesn't make sense to me that you'd prefer things that way.