Hacker News Reader

Comment by joev | Hacker News Reader

David is spot on when it comes to the complexity of the documentation; it's great that it's exhaustive, but it would be nice to have the "here's how to use it" documentation near the "here's how to implement your own collection type" doc.

Another trend I see in Scala is the abuse of symbols-as-method names. I see a lot of Scala (and Lift) code that looks like

  val foo = bar ~-> 45 <~< "Fred" %% x

with little commonality of convention.

View on HN

Scala is one of those languages where you need to employ some restraint in order to use it effectively. I think Lift in particular suffers from too enthusiastic a use of the more esoteric language features.

I just think the patterns for what makes a good library interface haven't completely coalesced yet. One can introduce horrifically complex interfaces in Ruby as well, but the best libraries expose a simple, consistent interface.

I hope that's an exaggeration. I'm just starting to look into scala as a directional language for our team (new projects), but if real-life scala code tends toward that sort of ugliness we'll stay with java.

Define real-life Scala code.

It is absolutely possible to write code like that in Scala.

It is also possible to write code that is to read and understand and which makes perfect sense.

It all depends on the programmer.

Well, when I say "tends toward" what I mean is if I have an average team of programmers, when I look through the code a year after the project starts, is this what I'm going to find?

I realize expert programmers can write legible code in any language, in the same way Tiger Woods can best me over 18 holes using only a five iron. But there are some languages, like C++, that tempt mediocre programmers into writing illegible code. That's a big strike against, IMO.

I doubt you'll have to worry about that specific problem with a team of average programmers. They won't be naming new functions with pure symbols, which is what that code represents. Just don't tell them Scala allows that and you should be fine. If they figure it out, outlaw it and require the use traditional descriptive English camelcase.

If you can use the map function from collections and if you understand why function with one argument has the following signature[1]:

    Function1 [-T1, +R]

Then you should be fine

[1] Explanation here: http://stackoverflow.com/questions/5277526/real-world-exampl...

Scala code http://engineering.foursquare.com/2011/01/21/rogue-a-type-sa...

Take a look at the APIs of some of the libraries you are likely to use, before you get scared off by how complex the syntax can potentially be.

As someone who has seen scala, but never really wrote anything in it, what in heaven's name does that statement do?

It does whatever you want it to do. ~->, <~<, and %% are just method names. It parses like:

    val foo = bar.~->(45).<~<("Fred").%%(x)

If those same methods were called a, b, and c instead, it would parse like:

    val foo = bar.a(45).b("Fred").c(x)

Yes, some people abuse symbolic method names. Unless your method makes overwhelming sense with a symbolic name (+, -, *, etc), just don't do that. But this problem isn't unique to Scala; poor names can strike in any language. If I called my method "slfjowierlksdfjnas", that'd be bad too. But most developers have enough common sense to choose reasonable names for their methods.

Reply on news.ycombinator.com