Are Variables Evil?

Now that we know that "Software Engineering is Engineering", let's get back to Scala. Scala is often called a postfunctional or object-functional language. Its designers noticed that object orientation and functional orientation do not contradict each other. Look, for example, at these assumptions:

Object orientation

• Every value is an object
• Every operation is a method call

Functional orientation

• Every operation is a function call
• Every function is a value you can assign to variables or pass to other functions

Scala

• Every value is an object
• Every operation is a method call
• Every method is a function
• Every function is an object

But there is more to what is meant by words "functional programming". Sometimes it means programming without variables. Or at least without changeable variables. Again there is no contradiction to OO programming. We can program without changing variables in a pure OO language, but special languages usually make it much easier. I bet you've already benefited from an absence of variables. Think SQL. Or even Java. Look at this example from the book:

Software Engineering is Engineering

Ultimately, real advances in software development

depend upon advances in programming techniques,

which in turn mean advances in programming languages.

-- Jack W. Reeves, 1992.

I hope you liked the previous article "Why We're Writing the Same Code Over and Over". I think the idea of Abstraction cost is very useful in particular for understanding the progress of software development industry. Another important thing in that regard is seeing the right parallels to other industries.

There are a lot of people arguing what is software development: engineering or craftsmanship? But it is a false dichotomy.

The usual argument is that there are software development projects the exact outcome of which is hard to predict, so software development must not be engineering. But engineering projects in more traditional industries also differ greatly in predictability of exact outcome.

c2.com/cgi/wiki?WhatIsSoftwareDesign

Years ago I read an article that completely changed how I thought about software design.
...
The name of the article is What Is Software Design? It was written by JackReeves and published in The C++ Journal Vol. 2, No. 2. 1992.
...
Essentially the point is this. When the original phases of software development were laid down, they were just plain wrong. Requirements, Design, Implementation, and Test are not what we think they are. Design is not something that you do only before you code. Implementation is not the act of coding. We can see this if we look realistically at what they are in other engineering disciplines.

Why We're Writing the Same Code Over and Over

As we saw in the previous article "Understanding at a lower price", Scala provides more fine-granular code reuse than a Java-like language. When in Java you either reuse a whole module as-is or write a new similar one from scratch, in Scala you often just reuse smaller sub-modules.

You can think "What stops me from doing the same thing in Java?" Well, actually you can define similar sub-modules. But defining and using them often will be so much more complex than just doing some copy-paste that it is not worth it.

Let's continue with the collections processing example. There are libraries for Java collections that allow you to assemble your collection processing part of code from predefined parts similarly to what you find in Scala. But almost nobody uses them. Let's write an equivalent to the one simple line of Scala from the previous article. This Java code is written using Guava (former Google Collections) library:

Scala. Understanding at a Lower Price.

I hope "Why Scala?" article sparked enough interest to dive into even more code.

Here is an edited quote from Oleg Ilyenko's blog:

hacking-scala.posterous.com/essential-scala-collection-functions

Let me ask you a question. How many times you wrote similar code?

case class User(id: Int, userName: String)

val users: List[User] = // ....
val resultUsers = new ArrayBuffer[User]

for (i <- 0 until users.size) {
    if (users(i).userName != "test") {
        resultUsers += users(i)
    }
}

Many imperative languages like Java, C, C++ have very similar approach for iteration. Some of them have some syntactic sugar (like Java for each loop). There are many problems with this approach. I think the most important annoyance is that it’s hard to tell, what this code actually does. Of course, if you have 10+ years Java experience, you can tell it within a second, but what if the body of the for is more involving and has some state manipulatin? Let me show you another example:

Scala vs Java Code Example

I hope "Why Scala?" article sparked enough interest to actually dive into some code.

Here is a Scala vs Java code example from stackoverflow:

up vot40down voteaccepted

Let's improve stacker's example and use Scala's case classes: case class Person(firstName: String, lastName: String) The above Scala class contains all features of the below Java class, and some more - for example it supports pattern matching (which Java doesn't have). Scala 2.8 adds named and default arguments, which are used to generate a copy method for case classes, which gives the same ability as the with* methods of the following Java class.

Why Scala?

Because you write as little code as in Ruby, yet have Java-like IDE experience with compilation errors highlighting as you type, reliable refactorings, etc.


And in this case the whole is greater than the sum of the parts. Some examples:

• You write less bugs in Ruby than in Java, because you write less code.
• You write less bugs in Java than in Ruby, because there is a clever compiler to catch them.

In Scala you write less bugs, because you write less code.
In Scala you write less bugs, because there is even more clever compiler, that catches more bugs for you.

• Java is faster than Erlang, because JVM is faster than Erlang VM.
• Erlang is faster than Java, because it is easier to write scalable applications with it.

Scala is faster, because JVM is faster than Erlang VM.
Scala is faster, because it is easier to write scalable applications with it.