<script src="https://cdn.freecodecamp.org/testable-projects-fcc/v1/bundle.js"></script>
<!--
Hello Camper!
For now, the test suite only works in Chrome! Please read the README below in the JS Editor before beginning. Feel free to delete this message once you have read it. Good luck and Happy Coding!
- The freeCodeCamp Team
-->
<nav id="navbar">
<div class="nav-header">
<div id="header-img">
<img src="https://cucumber.io/img/scala.png">
</div>
<header>Scala Documentation</header>
</div>
<ul>
<li><a class="nav-link" href="#Introduction">Introduction</a></li>
<li><a class="nav-link" href="#History">History</a></li>
<li><a class="nav-link" href="#Scala_and_Java">Scala and Java</a></li>
<li><a class="nav-link" href="#Hello_world">Hello world</a></li>
<li><a class="nav-link" href="#Expressions">Expressions</a></li>
</ul>
</nav>
<main id="main-doc">
<section class="main-section" id="Introduction">
<header>Introduction</header>
<article>
<p>
Scala is a general-purpose programming language providing support for object oriented programming, functional programming and a strong static type system. It was designed to be concise and address criticisms of Java.
</p>
<p>
Scala source code is intended to be compiled to Java bytecode, so that the resulting executable code runs on a Java virtual machine. Scala provides language interoperability with Java, so that libraries written in either language may be referenced directly in Scala or Java. Like Java, Scala is object-oriented, and uses a curly-brace syntax reminiscent of the C programming language. Unlike Java, Scala has many features of functional programming languages like Scheme, Standard ML and Haskell, including currying, type inference, immutability, lazy evaluation, and pattern matching. It also has an advanced type system supporting algebraic data types, covariance and contravariance, higher-order types (but not higher-rank types), and anonymous types. Other features of Scala not present in Java include operator overloading, optional parameters, named parameters, and raw strings. Conversely, a feature of Java not in Scala is checked exceptions, which have proved controversial.
</p>
<p>
The name Scala is a portmanteau of scalable and language, signifying that it is designed to grow with the demands of its users.
</p>
</article>
</section>
<section class="main-section" id="History">
<header>History</header>
<article>
<ul>
<li>The design of Scala started in 2001 at the École Polytechnique Fédérale de Lausanne (EPFL) (in Lausanne, Switzerland) by Martin Odersky. It followed on from work on Funnel, a programming language combining ideas from functional programming and Petri nets.</li>
<li>
Odersky formerly worked on Generic Java, and javac, Sun's Java compiler.
</li>
<li>
After an internal release in late 2003, Scala was released publicly in early 2004 on the Java platform. A second version (v2.0) followed in March 2006.
</li>
<li>
On 17 January 2011, the Scala team won a five-year research grant of over €2.3 million from the European Research Council.
</li>
<li>
On 12 May 2011, Odersky and collaborators launched Typesafe Inc. (later renamed Lightbend Inc.), a company to provide commercial support, training, and services for Scala. Typesafe received a $3 million investment in 2011 from Greylock Partners.
</li>
</ul>
</article>
</section>
<section class="main-section" id="Scala_and_Java">
<header>Scala and Java</header>
<article>
<p>
As mentioned earlier, Scala was designed to address the criticisms of Java. In an interview with Martin Odesrky, he discusses his experience with Java and how he tried to improve it.
</p>
<h4><strong>Working to improve Java</strong></h4>
<blockquote cite="https://www.artima.com/scalazine/articles/origins_of_scala.html">
... Phil Wadler and I decided take some of the ideas from functional programming and move them into the Java space. That effort became a language called Pizza, which had three features from functional programming: generics, higher-order functions, and pattern matching. Pizza's initial distribution was in 1996, a year after Java came out. It was moderately successful in that it showed that one could implement functional language features on the JVM platform.
<br>
<br>
Then we got in contact with Gilad Bracha and David Stoutamire from the Sun core developer team. They said, "We're really interested in the generics stuff you've been doing; let's do a new project that does just that." And that became GJ (Generic Java). So we developed GJ in 1997/98, and six years later it became the generics in Java 5, with some additions that we didn't do at the time. In particular, the wildcards in Java generics were developed later independently by Gilad Bracha and people at Aarhus university.
</blockquote>
<h4>Designing a language better than Java</h4>
<blockquote>
Now, during the Pizza and GJ experience I sometimes felt frustrated, because Java is an existing language with very hard constraints. As a result, I couldn't do a lot of things the way I would have wanted to do them—the way I was convinced would be the right way to do them. So after that time, when essentially the focus of my work was to make Java better, I decided that it was time to take a step back. I wanted to start with a clean sheet, and see whether I could design something that's better than Java. But at the same time I knew that I couldn't start from scratch. I had to connect to an existing infrastructure, because otherwise it's just impractical to bootstrap yourself out of nothing without any libraries, tools, and things like that.
<br>
<br>
So I decided that even though I wanted to design a language that was different from Java, it would always connect to the Java infrastructure—to the JVM and its libraries.
<br>
<br>
... We wanted to create something that would be at the same time practical and useful and more advanced than what we could achieve with Java. We started working on this language, which we came to call Scala, in about 2002. The first public release was in 2003. A relatively large redesign happened early 2006. And it's been growing and stabilizing since.
</blockquote>
<h4>Constraints on improving Java</h4>
<blockquote>
In the generics design, there were a lot of very, very hard constraints. The strongest constraint, the most difficult to cope with, was that it had to be fully backwards compatible with ungenerified Java. The story was the collections library had just shipped with 1.2, and Sun was not prepared to ship a completely new collections library just because generics came about. So instead it had to just work completely transparently.
<br>
<br>
That's why there were a number of fairly ugly things. You always had to have ungenerified types with generified types, the so called raw types. Also you couldn't change what arrays were doing so you had unchecked warnings. Most importantly you couldn't do a lot of the things you wanted to do with arrays, like generate an array with a type parameter T, an array of something where you didn't know the type. You couldn't do that. Later in Scala we actually found out how to do that, but that was possible only because we could drop in Scala the requirement that arrays are covariant.
<br>
<br>
When Java first shipped, Bill Joy and James Gosling and the other members of the Java team thought that Java should have generics, only they didn't have the time to do a good job designing it in. So because there would be no generics in Java, at least initially, they felt that arrays had to be covariant. That means an array of String is a subtype of array of Object, for example. The reason for that was they wanted to be able to write, say, a “generic” sort method that took an array of Object and a comparator and that would sort this array of Object. And then let you pass an array of String to it. It turns out that this thing is type unsound in general. That's why you can get an array store exception in Java. And it actually also turns out that this very same thing blocks a decent implementation of generics for arrays. That's why arrays in Java generics don't work at all. You can't have an array of list of string, it's impossible. You're forced to do the ugly raw type, just an array of list, forever. So it was sort of like an original sin. They did something very quickly and thought it was a quick hack. But it actually ruined every design decision later on. So in order not to fall into the same trap again, we had to break off and say, now we will not be upwards compatible with Java, there are some things we want to do differently
</blockquote>
</article>
</section>
<section class="main-section" id="Hello_world">
<header>Hello world</header>
<article>
To get started with writing Scala open <a href="https://scalafiddle.io/">ScalaFiddle</a>
and write your first "Hello world" Scala code:
<code>println("Hello world")</code>
</article>
</section>
<section class="main-section" id="Expressions">
<header>Expressions</header>
<article>
<p>Expressions are computable statements. </p>
<code>1 + 1</code>
You can output results of expressions using println.
<code
>println(1) // 1
println(1 + 1) // 2
println("Hello!") // Hello!
println("Hello," + " world!") // Hello, world!
</code>
</article>
<article>
<h3>Values</h3>
<p>You can name results of expressions with the val keyword.</p>
<code
>val x = 1 + 1
println(x) // 2
</code>
<p>Named results, such as x here, are called values. Referencing a value does not re-compute it.
</p>
<p>
Values cannot be re-assigned.
</p>
<code
>x = 3 // This does not compile.
</code>
Types of values can be inferred, but you can also explicitly state the type, like this:
<code
>val x: Int = 1 + 1
</code>
<p>Notice how the type declaration Int comes after the identifier x.
</p>
<p>
You also need a ":"
</p>
</article>
<article>
<h3>Variables</h3>
Variables are like values, except you can re-assign them. You can define a variable with the var keyword.
<code
>var x = 1 + 1
x = 3 // This compiles because "x" is declared with the "var" keyword.
println(x * x) // 9
</code>
As with values, you can explicitly state the type if you want:
<code
>var x: Int = 1 + 1
</code>
</article>
</section>
</main>
!
