Why scala is still keeping var in it?

I have seen that due to having this var keyword many programmers in scala are writing bad codes. I think if there would no existence of this , we would not face some nasty codes. Can’t scala remove this keyword from it ?

No – Scala is very specifically multi-paradigm, and traditional-style OO code absolutely requires var. That’s less common in Scala than it once was, but there is still plenty of extant code using it.

(It’s also common in older-style Akka code, where it is less dangerous when used properly.)

Probably more importantly, there are times, especially when writing relatively low-level code (central data structures and the like), or critical high-performance code, where var can occasionally be very useful.

Finally, var is often just fine when used in a function, provided you know what you are doing – that isn’t as dangerous than var members in a data structure. (Although you can still get yourself in trouble if you use it casually.)

The thing that people tend to misunderstand is that, in idiomatic Scala, var should be treated as an advanced feature, not one for beginners. Most languages treat var as something that you teach to students on day 1, because it is easy for small problems, but it has the problem that it tends to foul up large-scale programming, so those students learn habits that get problematic in real-world environments. It should be instead considered a power tool, to be used only when needed and when you really know what you are doing. That doesn’t mean “never”; it means “rarely, and with care”.

(I would love to have it behind a language import, personally, to discourage its usage, but IMO it’s way too late to do that.)


In that case scala can introduce an annotation like @mutable needs to be set with val will indicate the val is mutable. Then it will be considered as "

var should be treated as an advanced feature

I think this will help the beginner programmer keep away form unintentional var and think like functional programmer.

But Scala isn’t only about functional programming. It is also about OOP.

I don’t agree with this sentence. In my opinion var for beginers depends on the context and the goal: Do you want to use Scala to teach oriented object programming, functional, both ? Do your students have an oriented object background ?

If your students only know about OOP, var can be used to make an OO version of an exercice/a project then compare it with a more functional design.


I want to point out that right now there is a push to get Scala used more in teaching. The best way to grow the community is to make sure that more people are learning the language. The number of colleges that have departments that want to introduce students to programming in a purely functional manner is small. Highlighting the flexibility of Scala to support more than just pure functional programming is, IMO, essential to getting it taught more broadly.


If people really want to taste the OOP there is the most popular OOP language in jvm market. The reason people want to peep over scala is to be introduced with functional programming. Yes, scala is kept slight closed to java but it also needs to ensure some area secured that beginner can not make unintentional mistake.

Not only in case of var, there are lots functional programming things for using those we need to depend on other libraries. Sometimes seems funny.

Mr. @MarkCLewis I totally agree with you. But, I saw many courses are taught on scala in many platforms. But somehow they are not focusing on functional scala. They think “using lambda with collection is functional programming language

And it is a limited form of functional programming. It is highly declarative, involves treating functions as first-class objects, and is typically done in a way that avoids mutation. Of course, if you want to really get fully functional you need to make your entire code base take advantage of those things, not just occasionally bits.

I will also note that if a teacher is looking for a language to teach purely functional programming, they will generally go to Haskell because it does so much more to enforce that paradigm. The motivation to teach Scala is really that it isn’t going to completely force you to do everything functionally.

1 Like

jducoeur answered it well, but I will add one point. I work on R&D for air traffic control automation, and I find that there are algorithms that I need to develop that would be much harder to implement without var. They are always within a function (or method) and so are perfectly safe with var. If I was forced to spend five times as long to develop these algorithms just to avoid var for no good reason, I would seriously consider abandoning Scala.


@Russ I agree with you. I had projects I did so you mentioned. But, it is all about protecting from unintentional mistake. Why not a new annotation like @mutable annotation with val which will behave like var.

After having taught introductory programming using Scala at university level since 2016 I am totally convinced that the learning of many concepts in software design benefit from the contrasting of similarities and differences between ideas. This is especially the case when understanding the difference and similarities between values that are assigned only once and values that are mutable.

Understanding flow of control and abstraction of values into names, parameters, functions etc. really benefit from being able to experiment with similarities and differences with imperative effects together with the alternative way of computing new values from existing values instead of updating in place. This is how we learn new things - by contrasting and generalizing and combining and separating. So not having mutable variables in a beginner programming language would make my job as a teacher much more difficult and the emerging world view of my students too narrow and too shallow IMHO.

Analogous: I guess that a teacher of English as a foreign language would not complain that there are too many synonyms in the English language, and use that as an argument for ditching English in favor of the more limited (but more principled) language of Esperanto. :slight_smile:


I don’t like the annotation approach – I tend to be a bit obsessive about extra boilerplate in my code. I would be willing to consider an optional compiler setting to provide a warning if a var is used at the top level in a class (making the class mutable, as opposed to within a method or function, where a var does not make the class mutable).


Annotations should not define the semantics of the thing annotated. They provide data for functions on those things. A mutable annotation does not satisfy this property.

In favour of the var, i’dd like to remark that when working with ScalaJS, use of vars is quite common when addressing elements on the webpage. Sometimes you directly want to change the content of a visible element and on other occasions you couple to variables inside some js library. I would not like it if my code get littered with lots of annotations this way.

Scala is a gateway drug to Functional Programming, and I hope it stays that way. :wink:

While my Functional Programming has improved, and I rarely need var, sometimes, when I am wrestling with a complex idea, I revert to imperative programming, including var. When I have the code working, I refactor it to Functional Programming.

I agree that var is an advanced Scala feature, but for newbies and even old farts like me, it’s actually a simple feature that is a stepping stone to better code later.


I think that is only part of the story and is a bit misleading. There are perfectly good uses for local variables in functions and methods, and they do not make the enclosing class mutable. And while it is true that variables can always be avoided, I would argue that doing so is not necessarily always the best practice. Some algorithms are much easier to develop using variables, and I would argue that they can also often be easier to read and understand with variables. In those cases, bending over backwards to avoid a var is silly and pedantic – at the expense of the subsequent maintainers of your code.


Not to beat a dead horse, but let me make one more point. If you look at books on algorithms, even advanced ones, you will find that many if not all of them use variables. (Is anyone aware of a book on algorithms that does not use variables?) So why shouldn’t a programming language allow them? And why shouldn’t they be considered perfectly acceptable for appropriate uses? Think about it. Why should you have to figure out how to avoid them in programming an algorithm, whether you are developing it from scratch or translating it from published code or pseudocode? And perhaps that is why Haskell has never been widely adopted.

It’s a slightly weak point: most of those core algorithm books date back to the relatively early days of programming, decades before the abstractions required to make functional programming pleasant had been refined. I mean, they generally don’t talk about objects or classes in the modern sense, either – they were generally built around old-fashioned data structures and imperative programming, because even OO hadn’t been invented yet.

And I think it depends on how you define “algorithm”. To a substantial degree, I think of Functional Programming in Scala as the modern equivalent of an algorithm textbook – it’s just tending to operate at a higher level of abstraction than those original ones did.

Mind, I somewhat agree with your point: there are some algorithms that are just plain easier with a local variable or three, and there isn’t any reason to eschew them. But I think you’re using the word “algorithm” a bit narrowly here…


var is sometimes critical for performance. I’ve needed them for low-memory and high-performance computing; allocating new memory can take a long and uncontrolled time.

Sometimes var just makes the code easier for us humans to read, especially algorithms. That’s often undervalued. In Scala I can make my code map the pseudocode in Cormen line-for-line, even when I apply it to custom structures. The code is easier to verify.

I think there’s still a PhD waiting for the student who can make a heap with functional programming. Last I looked someone had proven it was possible, but had not provided the algorithm.

But that’s @jducoeur’s point, no? Books are written in imperative style, so code is written in imperative style, so books are written in imperative style,… This is not evidence that imperative style is inherently easier to grasp for humans (although it very well may be for a given concrete algorithm). It’s just that this is what you’re most likely to learn and do first, so it seems more “intuitive” from that point on.

Curiously, it was a Doctor of Philosophy thesis rather than a PhD, turned into a book later on. :slight_smile: