Scala: Where it came from, Where it's going

I have seen people who were average Java programmers who were afraid (right to their bones) pick it up even if out of coercion rather than willingness :P and start to like it.

I don't understand why people suggest Java, Scala is better in every imaginable way. Also there maybe more than one ways to do things, but I don't get why that is a problem. Code comes from within a person like art and it's bound to be different. Don't the large projects always have different style? I don't see how sane code albeit written in different styles would become unmaintainable/unreadable.

My perspective of dev'ing in scala since 2009 (and I love scala):

"Scala isn't that complicated, just takes some time to learn."

Scala is complicated. Like really potentially super complicated, and the compiler error messages can be hyper-cryptic. It was written by academics (versus "developers") and it shows.

New developers will end up asking someone else a basic language question about every 10 minutes, mostly because they don't even know what to google for.

I've been using it for years and I still have to lookup prepending versus appending to lists because I can't remember if it's x :+= y or x +:= y, let alone ::: versus :: versus ++ or ++=.  Really? Why not #!:@## while we're at it?

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.

It doesn't help that there are 50 ways to do the same thing and the language is totally agnostic as to what you should do. 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.

---

It would be really great if they could canonicalize the language in the way that python has, and once having done so further simplify their syntax so mere mortals can use it effectively. Programming is hard enough without the language being difficult, too.

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.

http://www.quora.com/Why-is-LinkedIn-getting-rid-of-Scala

Existentials should always be a last resort, so it's ok if their syntax is a bit cumbersome; I find the forSome style a lot less confusing in its implications (e.g. "why can't I add a String to a List[_ <: String]" is a common newcomer question) and it avoids confusion with higher-kinded types. So if anything I'd rather drop the List[_] syntax, and use List[T] forSome {type T} exclusively. (Eliminating existentials entirely would be nice, but they're needed for Java interop).

The dotty approach of replacing type parameters with type members fills me with fear. Type parameters are simple and reliable; type members are confusing and the compiler often needs more help to get them right. I can appreciate the desire to not have two features that overlap, but this is removing the feature that works well in favour of the feature that doesn't.

Monads for effects work really well, and the community is just starting to get a library stack together that makes them easy - look at e.g. http4s for where the grassroots innovation is. They're simple to reason about because they're just ordinary types following the ordinary rules, and we have a lot of library support for making them easy to work with. By contrast implicits are still the most confusing and error-prone part of the language - look at all the trouble people have with Future and ExecutionContext. The example given in the slideshow looks like a perfect use case for scalaz Kleisli. Rather than another specialized language feature, the truly scalalike solution would be to make it easier for "function literals" to have user-defined types - perhaps k{ body } to have body be promoted to a Kleisli, a la s"" interpolators.

Scala gets a lot right, and I don't think I'd ever be tempted away to Haskell - strictness and impurity are simply too useful. Some parts can't be changed - subtying is here to stay (and needed for interop), and much as I wish tuples could be replaced with HLists, they probably can't. That by itself is enough to leave room for a successor to eat Scala's lunch. But for now it's a brilliant language, fun and safe and commercially viable; I really do love the language, and a few of these things (union types) could make it even better. But too many of these ideas feel like missteps.

The idea of cleaning up the syntax a bit (XML, procedure, etc..) is great, but I'm not sure to understand what's "A better treatment of effects" (slide 44)? What's intended?

"Objects done well provide a lightweight module system (in the sense of ML). The requirement for a good module system is something that's often overlooked when all you do is a simple application, but its lack becomes painfully apparent for large systems and systems that are maintained over time. You can go the SML route and provide a module system and a functional core language. But then there's the pressure that you want to generalize your modules to be more flexible, which means you want them to become recursive and first-class. If you do that, you end up with a de-facto object system in addition to your core language of algebraic data types and functions. Scala's approach of unifying modules and objects is more parsimonious: The same constructs define the core language and the module language. So Scala is simpler, in the sense that fewer concepts are needed to describe the total feature set."

Others have already commented on this, and I have nothing more to add, but I do find myself doubtful about whether the "Scala is simpler" is justified. Scala has always been multi-paradigm, so I don't think of it as simple -- and, again, that can be a strength or a weakness. I'm reflecting on what was written here: http://scala-programming-language.1934581.n4.nabble.com/OOP-...

One issue I have with it. I don't think it's complex, but I think people are not spending the right time learning it. People learn the subset of features they like and stay with it, and because there are so many ways to skin a cat with it, everyone have their own style. It could have benefit from the concept that other languages have of "there is always one best way to do things". I mean, on one hand I can write 20 lines of Java in 10 lines of Scala or less (and enjoy it 100X more) but I can do it in 1000X different ways.

We use scala on a company wide basis and even though everyone is very expressive, well, everyone is VERY expressive.

I think that if a company enforces strict scala style rules, best practices and sticks to it (using automatic style / structure rules that throw compile errors / warnings and need special care to turn off) than Scala can be a big asset to a company.

I'm sure there could have been a better solution to someone who needs a statically typed, OO/FP hybrid language that runs on the JVM. But currently Kotlin / Ceylon are not there for my taste. And the others, are either not JVM languages or not OO, or not statically typed.

There is a group of very passionate people in EPFL and TypeSafe and the scala community that don't follow Martin like a heard. there are at least 2 well known forks of Scala compiler, one large fork of scala collections (by one of Scala's greatest committers and also later greatest critique). Criticism is accepted and no one follows blindly around the founder's opinions (although I think he is doing a good job so far navigating it)

I mean, Scala is perhaps over-featured, perhaps can be a little complex if you use it to write libraries (until you spend some time actually learning it), perhaps it gives you too much strength, but even if it's experimental, academic, theoretical, then it's an experimental / academic / theoretical super fun language that I can actually use at work! how crazy is that? I think Scala is beautiful, a pure joy to use, and I'm so lucky I can use it instead of Java 8 or any other language in the world. Until Kotlin / Ceylon is mature enough, Scala is the answer to anyone targeting the JVM and want a modern language. Clojure is cool and hip, but I find it much less productive personally, and much more complex, sorry, maybe I'm not smart enough (and, as I said, I prefer static typing)

If you are a Java developer and never tried it, don't believe the lies, Scala will grow on you. and unless you are a constant naysayer / devil's advocate, you'll never go back.