Hacker News Reader

    It's crazy that in these slides he says "I wanted a
    hipster language" -- most languages use [] for arrays so I 
    used (). WHY!!!!? Just to be different? No actual real 
    advantage? That's a terrible reason and a great way to 
    make it hard for new people to adopt your language.

You might not get it, but the slide makes fun of knee-jerk reactions like those shown in your comment.

Scala does things for a good reason. Not caring to figure out the reason doesn't mean the language is wrong.

Care to point out the reason then? Not sure why you assumed I don't care to find out, especially given I've stated that I've been using Scala since 2009 and love the language.

It's () instead of [] because it's a regular function call. It's related to the scalability thing that Odersky also mentions (as much functionality in libraries as possible, rather than in the language).

I'm assuming it's to unify the `apply()` operation between collections (maps, sequences, arrays, etc). The collection library derives from a trait hierarchy, and an array is one of these collection types.

Not just between collections, but functions as a whole. An indexed sequenced is essentially a mapping (read: function) from the integers to whatever the element type is. Scala makes that explicit, rather than creating another mapping operator, as though they failed to notice the symmetry.

I would characterize this sort of thinking as one of the core principles of the language design. The designers search for underlying generality and bring it to the surface of the language. This can be a little frustrating at times, since humans aren't necessarily geared toward abstraction. But investment in understanding the abstractions pays off again and again.

The square brackets are used already for type parameters on types. I do think they are easier to read than angle brackets are, for some reason. There was some discussion on this point in the Rust community as well recently where it was noted several people found square brackets easier to read and wanted to emulate Scala here (and another group wanting emulate D, using () for both!).

Another reason is that an IndexedSeq is really itself a function (extends Function1), so the parens are literally function application, not some specially interpreted syntax for indexing.

When it comes to arrays, they use () to emphasize the fact that this is a function- arr(1) is arr.apply(1)- instead of directly accessing an element like other languages.

Scala makes sense and has a logic behind all its reasons, but sometimes it seems to go against convention for the sake of its own philosophy.

I love how this is the only thing that people seemed to comment on. And I appreciate everyone's suggestion of unifying function calls being a good thing plus other aesthetics.

But does that mean everyone agrees with the rest?

> It's crazy that in these slides he says "I wanted a hipster language" -- most languages use [] for arrays so I used (). WHY!!!!? Just to be different? No actual real advantage? That's a terrible reason and a great way to make it hard for new people to adopt your language.

func<Future<List<Option<String>>>> vs func[Future[List[Option[String]]]]

Which one is easier on your eyes?

>>func<Future<List<Option<String>>>> vs func[Future[List[Option[String]]]]

>Which one is easier on your eyes?

i don't get the joke here. Or are you seriously implying that one is in someway better than the other? (i'm curious as i've been in the industry for more than two decades, so my eyes just filter that crap automatically anyway)

I am seriously implying that one is easier on the eyes than other.

Granted I'm biased as I'm primarily a scala dev these days but I've always preferred the square brackets over the angle brackets. At least for me it is actually more readable.

Angle brackets aren't even very readable, couple that with the fact that they are also OPERARTORS and you are looking at some major complexity in your parser to distinguish between bracket usage and operator usage (possible, but requires looking ahead, worse syntax errors).

Or just terrible syntax choices like in Java or Rust.

Or, maybe, perhaps:

func(Future(List(Option(String))))

Err, no... One is a type construction, the other is function application. It sure helps if these are different...

Conceivably, it could be application of a type constructor to type arguments, where parens control precedence, not application:

    Func (Future (List (Option String)))

That's really not a fair comparison here. With a monospaced font, it's much more comparable:

  func<Future<List<Option<String>>>>
  func[Future[List[Option[String]]]]

>It's almost like being an alien, coming to Earth, and trying to learn to have sex with humans from someone who is bi-sexual and into every fetish there is.

compare that to Java - landing and learning how to do it in 16th century somewhere like Spain - engaging in that sinful activity in the most vanilla and least sensual way with only purpose of procreation and only when. Thanks God progress can't be stopped :)

Indeed. If you make something expressive then some people are going to express themselves in obtuse ways. There is no way out of that tradeoff. Of they don't have to share the code with anyone else then it's fine. But if you have a team and you don't code review for clarity then you are in trouble no matter what language you are using. The other thing is that the expressivity of Scala makes it actually possible to make your code even clearer.

> It's crazy that in these slides he says "I wanted a hipster language" -- most languages use [] for arrays so I used (). WHY!!!!? Just to be different? No actual real advantage? That's a terrible reason and a great way to make it hard for new people to adopt your language.

Parentheses for array and map access really bugged me until I grokked functors. They're really all doing the same thing, and the mathematical symmetry of using the same syntax for all of them is very pleasing.

:+= and +:= are very unidiomatic. No they're not banned entirely and maybe they should be, but I think that would make certain people even more upset. But what you're supposed to use is x :+ y and x +: y; with either one x ends up before y, and if you got them the wrong way around then it won't compile. Likewise ::: versus :: - if you get it wrong, it won't compile (at least if you're using wartremover and/or strict compiler flags. Again, it would be nice to remove these misfeatures entirely - but given how much fuss there is about enterprise use and backwards compatibility, Scala has chosen to put a lot of effort into ensuring that old code still compiles).

You missed my point. Symbols are cryptic.

It's very rare that you'd need to read the difference between x :+ y and x +: y, or x :: y and x ::: y. All of those give very similar results (a list of x followed by y), so it's good that they look similar. If you know one and not the others, the very fact that they look similar is a big hint that they're doing something similar.

I disagree 100%.

Prepend and append are very different. And you do need to know, because for many scala collections one is O(N) and the other is O(1) [1], plus the importance of knowing order.

The difference between x :: y and x ::: y could mean List(List(1), 2, 3) versus List(1, 2, 3).

[1] http://docs.scala-lang.org/overviews/collections/performance...

> Prepend and append are very different. And you do need to know, because for many scala collections one is O(N) and the other is O(1) [1], plus the importance of knowing order.

You know the order, at least in idiomatic code; "x :+ y" x comes before y, "x +: y" x comes before y. (There's a misfeature where you can sometimes write x +: y as y +: x, but don't do that; use brackets if you need to (x +: y))

O(N) versus O(1) is sometimes important but it is a detail IMO; anyone who cared about the distinction would already be reading the code very carefully, it's precisely the sort of thing that a casual reader should be able to gloss over.

> The difference between x :: y and x ::: y could mean List(List(1), 2, 3) versus List(1, 2, 3).

Exactly. Which the type system will catch; if you're using wartremover that will be an immediate error (inferred type containing Any), if not then you'll see an error as soon as you try to actually use the result.

To me :+ versus +: isn't obvious compared to saying .prepend or .append, which is my point. I shouldn't have to look that up.

As far as :: versus :::, depending on type inference it can be a much more later error that is confusing. The type error messages are cryptic compared to what it could say. Worse, if you then take it and serialized it to JSON or something then you won't even get a compile error, so it may not be for a while that you even realize there's and error and that can be hard to trace down depending on your code.

I really am failing to see why you're defending this. It's like trying to defend programming without a debugger because you have printf. Why not make things clearer, always? Why can't error messages be easier to understand and more human friendly? Shouldn't that be the goal?

.prepend wouldn't be able to use the : magic; once you're used to it "x :+ y"/"x +: y" is more intuitive than "x append y"/"x prepend y" because in the first example x always ends up before y.

> As far as :: versus :::, depending on type inference it can be a much more later error that is confusing. The type error messages are cryptic compared to what it could say. Worse, if you then take it and serialized it to JSON or something then you won't even get a compile error

Which is why you should use wartremover and strict compile flags ( https://tpolecat.github.io/2014/04/11/scalac-flags.html ), so that won't happen. (It would be nice to make these things completely illegal by default, but not nice enough to break backward compatibility over)

> I really am failing to see why you're defending this. It's like trying to defend programming without a debugger because you have printf. Why not make things clearer, always? Why can't error messages be easier to understand and more human friendly? Shouldn't that be the goal?

I think people really underestimate the value of conciseness. The difference between a function or class that fits on one screen and one that doesn't is really huge. For commonly-used operations, I'd rather pay the upfront cost of learning the symbols and be able to read shorter code forever.

Of course there's a tradeoff, and I do think certain scala libraries lean too far to the symbolic side. Sometimes I like to think about a programming language that didn't allow any symbols (e.g. you'd write arithmetic like "(1 plus 2) times 3"). But the extra characters aren't free.