HN Explorer

Why Scala is a must-learn language even if you don't plan to use it.

3 points by amichail ↗ HN
Learning Scala teaches you the state of the art in programming language design. So even if you don't plan to use it, at least you will be familiar with advanced programming language concepts that you may not have learned at university.

23 comments

[ 4.4 ms ] story [ 62.3 ms ] thread
davidw
How so?
amichail
Some things that you could learn:

* important concepts such as f-bounded polymorphism, covariance, contravariance, implicit parameters and methods, etc.

* traits that solve the diamond problem with multiple inheritance

* functional programming concepts including monads

* advanced concurrency concepts via the actors library

* pattern matching via case classes and extractors

* that type inference can make you highly productive in a statically typed language

mooneater
I'm sure you have good reasons for what you said about Scala. But as someone who does not know Scala, the post is not motivating.

Could you state the case for scala, in terms that someone not familiar with it, could appreciate?

amichail
Are you familiar with most of these concepts already?
anamax
> that type inference can make you highly productive in a statically typed language

Oh really? Type declarations and the like are at most 10% of code. That means that eliminating the need to type them, which is what type inference does, can't decrease code size by more than 10%. It's unlikely that that 10% takes more than 10-15% of development time.

runningskull
10-15% of software development time is a lot. A whole lot. I'm not commenting on whether type inference saves that much time, but if it does, it's undoubtedly worth it.
anamax
While 10-15% was generous, 5% is "worth it". However, "worth it" isn't the relevant standard - the claim was "can make you highly productive". 10-15% isn't a "highly productive" difference.
anamax
> * important concepts such as f-bounded polymorphism, covariance, contravariance, implicit parameters and methods, etc.

The fact that those are important concepts in Scala doesn't make them important concepts.

> traits that solve the diamond problem with multiple inheritance

There are lots of solutions to the diamond problem. The fact that scala uses traits doesn't make traits important.

> * pattern matching via case classes and extractors

Again, so what?

Scala is full of elegant mechanisms to solve problems that resulted from design choices. The elegance of those mechanisms or their importance to scala doesn't make them important. After all, one might reasonably have made different design decisions, making them irrelevant.

amichail
Many people are not aware of the issues. This would be a learning experience for them that starts from a familiar base.
anamax
Not so fast.

The claim was that scala is special. However, the argument doesn't support that claim. It's a list of "me-toos" and hyperbole.

For example, every language with multiple inheritance has some mechanism to deal with diamonds. Type inference is useful/interesting, but it doesn't result in "highly productive".

paulgb
Scala looks cool and all, but how is it better than ocaml, haskell, etc.?

That isn't rhetorical.

amichail
It's more familiar to Java programmers and uses the Java platform. You can learn its advanced concepts incrementally starting from a familiar base. Also, it doesn't force you to program in a functional manner as with Haskell.
bcater
But I LIKE functional programming.
paulgb
Me too, but I don't like being forced to program functionally if I feel imperative programming would be more readable, efficient, or fast. Certain tasks are more suited for functional programming than others.

That said, I don't mind languages like Haskell where imperative programming doesn't fit in well conceptually. It's just that I wouldn't use languages like that for everything.

jorgeortiz85
I don't have much first-hand experience with Haskell (I pretty much know only what I've read about it), so I'll address only OCaml.

Scala does a much better job of unifying object-oriented and functional programming than OCaml does. OCaml's OO-system feels tacked on; an afterthought rather than a careful consideration of the original design. In Scala, a function is an object and an object is a function. There are many ways in which the line between functional and object-oriented fades.

The C/Java/Python/Ruby school of syntax that Scala comes from is much more familiar to me than the ML school of syntax that OCaml comes from.

Scala doesn't have the distinction between "+" and "+.":

  powerbook58:~ jeortiz$ ocaml
        Objective Caml version 3.09.3
  # 1 + 1;;
  - : int = 2
  # 1.0 + 1;;
  This expression has type float but is here used with type int
  # 1.0 +. 1;;
  This expression has type int but is here used with type float
  # 1.0 +. 1.0;;
  - : float = 2.
Scala has access to any Java library.

That said, I don't want to come across as bashing on OCaml; I'm merely pointing out some differences. OCaml is a great language (that was a joy to learn) and for many applications it can be a better choice than Scala.

ricky_clarkson
I think Scala is a must-learn language IF you plan to use it. If you're on the JVM, and for some reason CAL doesn't work for you then Scala might well be the best thing available.

However, for learning interesting and useful stuff, I'd probably point people more towards Haskell.

marketer
I tried using liftweb for a project once, but was discouraged by the heavy dependency on maven. Also, liftweb is undergoing huge churn, especially in the database modeling.
mullr
I concur, having faced similary problems. Scala's association with java has, so far, been more of a curse than a blessing. But it is an interesting language.

To me, scala feels like a language with headroom, to use audio parlance. It's easy to get started, since you can code in pretty conventional ways. It has sophisticated things to learn about that you can use to write more expressive code, but the key differentiator from Haskell, say, is that you don't need to know all these to get things done. With scala you can hit the ground running.

jorgeortiz85
Scala's association with Java is a mixed blessing, but I think the net effect is positive.

Haskell, Python, Ruby, and OCaml were created in 1990, 1991, 1995, and 1996, respectively. Literally decades of work have gone into building libraries for these languages, in everything from web protocols to cryptography to machine learning. Scala was released in 2003 (and Scala 2.0, released in 2006, was a complete rewrite). Yet despite being so young, having access to any Java library makes Scala instantly useful. The language team can focus on the core language, and any library you can imagine is just a Google search away.

To give two examples: Adding support for AMQP and XMPP to lift meant writing two thin wrappers over the equivalent Java libraries. You could use the Java libraries directly, but the wrappers take advantage of Scala's Actors, which are the best thing since sliced bread when it comes to concurrency.

The JVM is also the most ubiquitous deployment platform ever. Yes, maven is mysterious and I mostly don't understand how it works. But it works, and it gives me a WAR file, and deploying a WAR is as easy as dropping it into any webapp container.

Could Scala-the-language be prettier if it wasn't tied to the Java platform? Probably.

Would Scala-the-platform be viable today if it didn't have full access to Java-the-platform? Unlikely.

It's hard to overstate the importance of the JVM platform to growing a new language. For Scala, it's the difference between a language that is an academic curiosity and a language I can use to solve real problems now.

marketer
I use F# at work. Guess what? My code is basically C#, with a thin F# layer. Ocaml doesn't give you the luxury of the .NET framework, which can be seen as a blessing in disguise, because your code tends to be much more functional. The libraries make a huge part of the flow in a 'real' program. To some extent, it's good that scala tries to wrap the conventional standard libraries, to make the flow seem more scala-like.
[deleted]
(comment deleted)
jorgeortiz85
(Disclaimer: I'm a liftweb committer.)

I'm sorry you were discouraged by maven. I've found maven to be a huge productivity boost, especially when compared to the alternatives. Though I'll admit it's mostly "black magic" to me. Half the time I don't know what exactly it's doing. But since it "just works", I find it really doesn't matter that much that I don't understand it.

Also, most of the "churn" is in new features. There are 6-12 production apps running off of lift's trunk, so check-in's very, very rarely break backwards compatibility. There is an effort to re-work the ORM layer and make it much, much more powerful (it'll be much more than just ORM). This work is proceeding cautiously though. There will be ample warning before the old ORM is deprecated and thrown out.

If you want to give lift a second chance, I'd encourage you to use the mailing list as a resource (liftweb@googlegroups.com). People are very friendly and generally very willing to answer questions.

marketer
That's cool that you're a committer, I think scala/lift are very promising, and look forward to using them in the future.

If everything is working well, maven can be a huge productivity boost. I'm sure the decision to use maven was to make the learning curve smaller. But I get an uneasy feeling when maven is being used for every aspect of the project, including creating it, compiling it, running it, updating the libraries, deploying it, importing to eclipse, etc...

The best way to use maven is to set up a stable local repository, and be _careful_ when you update them. Archtypes can be upgraded server-side on the fly, and this can cause problems if you're not careful about versioning.

By default, however, people won't set up local copies of maven repositories. And despite the best intentions of liftweb.org, and ibiblio.org, neither organization has a vested interest in your project, and they suffer from downtime frequently. liftweb was down for over a day at one point. You couldn't create a blank project template, or update the dependencies. It's a risky dependency.