What is the purpose of Scala programming language?

Question

It is my opinion that every language was created for a specific purpose. What was Scala created for and what problems does it best solve?

Solution 1

One of the things mentioned in talks by Martin Odersky on Scala is it being a language which scales well to tackle various problems. He wasn't talking about scaling in the sense of performance but in the sense that the language itself can seem to be expanded via libraries. So that:

val lock = new ReentrantReadWriteLock
lock withReadLock {
   //do stuff
}

Looks like there is some special syntactic sugar for dealing with j.u.c locks. But this is not the case, it's just using the scala language in such a way as it appears to be. The code is more readable, isn't it?

In particular the various parsing rules of the scala language make it very easy to create libraries which look like a domain-specific language (or DSL). Look at scala-test for example:

describe("MyCoolClass") { 
  it("should do cool stuff") {
     val c = new MyCoolClass
     c.prop should be ("cool")
  }
} 

(There are lots more examples of this - I found out this one yesterday). There is much talk about which new features are going in the Java language in JDK7 (project coin). Many of these features are special syntactic sugar to deal with some specific issue. Scala has been designed with some simple rules that mean new keywords for every little annoyance are not needed.

Solution 2

Another goal of Scala was to bridge the gap between functional and object-oriented languages. It contains many constructs inspired (i.e. copied from!) functional languages. I'm thing of the incredibly powerful pattern-matching, the actor-based concurrency framework and (of course) first- and higher-order functions.

Of course, your question said that there was a specific purpose and I've just given 3 separate reasons; you'll probably have to ask Martin Odersky!

Solution 3

One more of the original design goals was of course to create a language which runs on the Java Virtual Machine and is fully interoperable with Java classes. This has (at least) two advantages:

• you can take advantage of the ubiquity, stability, features and reputation of the JVM. (think management extensions, JIT compilation, advanced Garbage Collection etc)
• you can still use all your favourite Java libraries, both 3rd party and your own. If this wasn't the case, it would be a significant obstacle to using Scala commercially in many cases (mine for example).

Solution 4

Agree with previous answers but recommend the Introduction to An Overview of the Scala Programming Language:

The work on Scala stems from a research effort to develop better language support for component software. There are two hypotheses that we would like to validate with the Scala experiment. First, we postulate that a programming language for component software needs to be scalable in the sense that the same concepts can describe small as well as large parts. Therefore, we concentrate on mechanisms for abstraction, composition, and decomposition rather than adding a large set of primitives which might be useful for components at some level of scale, but not at other levels. Second, we postulate that scalable support for components can be provided by a programming language which unifes and generalizes object-oriented and functional programming. For statically typed languages, of which Scala is an instance, these two paradigms were up to now largely separate. (Odersky)

I'd personally classify Scala alongside Python in terms of which problems it solves and how. The conspicuous difference and occasional complaint is Type complexity. I agree Scala's abstractions are complicated and at times seemingly convoluted but for a few points:

1. They're also mostly optional.
2. Scala's compiler is like free testing and documentation as cyclomatic complexity and lines of code escalate.
3. When aptly implemented Scala can perform otherwise all but impossible operations behind consistent and coherent APIs. From Scala 2.8 Collections:

For instance, a String (or rather: its backing class RichString) can be seen as a sequence of Chars, yet it is not a generic collection type. Nevertheless, mapping a character to character map over a RichString should again yield a RichString, as in the following interaction with the Scala REPL:

scala> "abc" map (x => (x + 1).toChar)
res1: scala.runtime.RichString = bcd

But what happens if one applies a function from Char to Int to a string? In that case, we cannot produce a string as result, it has to be some sequence of Int elements instead. Indeed one gets:

"abc" map (x => (x + 1))
res2: scala.collection.immutable.Vector[Int] = Vector(98, 99, 100)

So it turns out that map yields different types depending on what the result type of the passed function argument is! (Odersky)

Solution 5

Since it's functional and uses actors (as I understand it, please comment if I've got this wrong) it makes it very easy to scale nearly anything up to any number of CPUs.

That said, I see Scala as kind of a test bed for new language features. Throw in the kitchen sink and see what happens.

My personal opinion is that for any apps involving a team of more than 3 people you are more productive with a language with Very Simple and Restrictive Syntax just because the entire job becomes more how you interact with others as opposed to just coding to make the computer do something.

The more people you add, the more time you are going to spend explaining what ?: means or the difference between | and || as applied to two booleans (In Java, you'll find very few people know).

View more solutions

Comments

[skaffman]

All true, but also true of many other JVM-based languages. What distinuishes Scala from the others? Superficially, its headline features are already available in other JVM languages.

[oxbow_lakes]

He didn't ask what distinguishes Scala from other JVM languages

[oxbow_lakes]

That's why all large software projects are written for the Universal Turing Machine

[oxbow_lakes]

Haha - you know more about Scala than I do, skaffman - feel free to edit my answer!

[Svante]

This seems like an aspect of Greenspun's tenth rule.

[Svante]

Bill, what you describe seems to be the basic premise of Java to me.

[Bill K]

Yes, I really appreciate Java, but it's getting way too complex. With the addition of Generics it is now more difficult to create a generic class (which removes one of the biggest advantages--that creating a class is as easy as using one). They are talking about adding more syntax. I'd take some syntax away, remove all variable types but private and probably put hard limits on the size of methods and number of methods per object; but you are right, simplicity is one of the biggest differentiators for Java.

[Bill K]

Not that there isn't a place for kitchen sink languages! Ruby is really interesting, Scala has some awesome concepts, etc. It's just that I wouldn't want to work in any language but java if I were forced to work with a group that didn't really "Live" programming (which always seems to be the case).

[Bill K]

I agree with this but see it as a pretty huge negative. Maintaining software involves learning just enough to solve your problem and move on, not having to understand how some language changes a syntax. Also I think that every developer's primary concern should be how do I make this easiest for the next guy to come along and work on it. That's why we use comments, development patterns and well-written code. From this point of view I don't really see Scala as being useful in many cases however it rocks for experimental code, small teams and code that you expect to replace rather than maintain

[oxbow_lakes]

I love the idea that you should only have to know enough about how to solve your problem and no more. Presumably you take the same attitude towards your car - and got upset after driving into your garage and then finding you don't know how to make it go backwards to get it out again. Usually there is a place for being proactive and prepared.

[deed02392]

For me the idea that I could come to review existing code and find myself needing to look up all kinds of odd re-definitions of keywords I'm used to in other languages (think how poorly variables are often named), concerns me. I think this is what @BillK Was getting at.

[Bill K]

@oxbow_lakes bad analogy. It's more like dealing with rental cars--standards give us a common location for the steering wheel and other common tools. If every individual who drives a car could permanently change implementations of each component it would be a fun car but the next guy trying to back out of the garage might accidentally hit the nitrous instead. You could study the manual for 2 hours before leaving the aiprot with your rental (Assuming the last driver even scribbled his mods into the manual)--that would be proactive and prepared I guess, but what a pain.

[Tim Harper]

@BillK I've been programming in Scala for over a year and am finding the code quite easy to maintain. I don't agree with your assessment for experimental code. Scala is a solid, feature-rich and well-designed language; and, it's getting better.

[Bill K]

@TimHarper That's interesting. What is your team's makeup? I usually consider maintainability in terms of how easy it is to hire new people and how quickly they come up to speed on your codebase. It's also good to consider how quickly the code can be picked up dry (without any help from the existing team--as in bringing it back for a patch after the creating team has left.) It always seems to me like the more "Features" a language has, the less it fits any of these maintainability goals.

[Tim Harper]

We've recently added 2 new engineers to our back-end team. It's certainly been a deep dive for them, but they've each been able to start making contributions within the first two weeks. (coming from C# / Java backgrounds)