Hacker News Reader

Comment by elehack | Hacker News Reader

I think it depends a lot on what you're wanting out of the language.

If your primary goal is Java sans pain, then Xtend, Kotlin, or perhaps Groovy should fit reasonably well and have a gentle-ish learning curve. Both Xtend and Kotlin seem to be designed particularly for this niche, with a dash of Scala-is-too-complex mixed in to their marketing materials.

If you're wanting an interesting new language that goes beyond traditional Java thought patterns, however, Scala (or Clojure) seems like a much better option. Both Scala's type system and its deep and insightful fusion of OO and functional thought make it a far more interesting language to think about and work with.

IMO, YMMV, etc. of course.

View on HN

Scala to me feels like the C++ of Java. There's a billion language features and each time I try to learn a new one, I run into gotchas and inconveniences. I'm not convinced an average or even above-average programmer can keep all that stuff straight in his head, cognitive energy that's better spent on actual programming.

For instance, what the heck is the method

GenTraversableLike.++[B >: A, That](that: GenTraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]): That

? That is all one method definition. Famous Java-isms like Enum<E Extend Enum<E>> are tame in comparison.

Things like this are the #1 reason I haven't embraced Scala, despite this constant itch I have to learn strongly typed functional programming. And who knows if they might capriciously change Scala tomorrow, like the time they decide to break binary compatibility of type signatures in compiled Scala classes, after which I spent an hour trying to figure out why the heck my IDE was reporting type errors everywhere.

The method ++ adds one collection to another. The specific type signature you are looking at is for the most general possible parallel collection. Obviously in that case the type signature will be complex - it needs to enable the compiler to determine the type of (Set(Superclass()).par ++ List(Subclass(), Subclass2())).

In practice, type signatures written in application code rarely look like that.

Don't get me wrong - Scala is complex. If you don't need the JVM, Haskell is far simpler and cleaner. But you are exaggerating the complexity of it.

>Haskell is far simpler

I disagree. If anything, both Scala and Haskell are comparable to C++ in terms of complexity. Haskell is in fact, a bottomless pit.

During your descent into madness, you may encounter functors, monads, comonads, free monads, higher ranked types, arrows, zippers, existentially/universally quantified types, GADTs, kinds, and the other 300 extra compiler extensions that people use on a daily basis.

Documentation is provided in the form of academic research papers.

Not that I'm saying it's not an exciting journey, but it is a long journey.

At it's core, Haskell is very simple. Functions are always curried. There is no subtyping. Typeclasses are the only method of polymorphism.

Everything you mentioned above is just a library on top of this.

In contrast, Scala has java-style subtyping built into the language, along with traits which are a weird mishmash of typeclasses and interfaces. There is quite a bit of complexity surrounding functions/methods. You have implicits to think about. Heck, just look at the type signatures in both languages and compare.

C++'s complexity stems from the fact that it's one big leaky abstraction on top of C with a ton of warts, not because it derives from complex academic or conceptual depth.

I'm not saying Haskell is easy. I'm just saying they are categorically different kinds of complexity.

Yes, not all complexities are created equal.

Haskell, and to a bit of a lesser extent Scala, have a lot of their complexity arise from combinatorial explosion of interactions of simple features.

Also, relentless abstraction (particularly in Haskell). Yes, you can think of lots of things as arrows. But does it necessarily make it easier to write a particular problem to do so, or does the cognitive load required to maintain the abstraction <-> problem mapping outweigh the benefit of casting it as the abstraction?

I've also found my Scala experience to feel disturbingly reminiscent of C++ (and I have grown to love Scala). I find a significant difference, though, in that C++ has a lot of complexity, while Scala has a lot of complex emergent behavior from a few simple core ideas (and the complexities needed to work out their details).

Then there's the library, where yes, you see a hairy mess like that. Very difficult to read and understand, but it is a powerful combination of relatively simple and orthogonal concepts. Which doesn't necessarily mitigate the complexity.

FWIW, you rarely need to write code with types that complex, and there is talk in the Scala community of how to simplify the presentation of methods with complex types in the documentation. But that doesn't make it more approachable today.

I understand your reaction, as I have felt similar feelings myself.

Would you feel the same way if we applied the situation to English instead of programming languages?

I rather like knowing that there are people who can express thoughts in English that are above my immediate comprehension, and would be loathe to replace English with some other language that prevented them from so doing.

It would feel like Harrison Bergeron applied to programming languages.

http://en.wikipedia.org/wiki/Harrison_Bergeron

Reply on news.ycombinator.com