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.
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.
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.
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.
By “algorithms”, I guess I am referring mainly to numerical algorithms. I certainly don’t claim to be an expert in that area, but I do develop some very specialized little algorithms for my work in air traffic control automation.
Sometimes getting an algorithm right can be a real challenge for a non-genius, and not allowing variables just makes it that much more difficult in some cases. Not all algorithms are straight mapping and filtering, and if you are using fold to avoid variables, I think the code underneath it uses variables anyway.
In the past, I would sometimes get an algorithm to work using variables, then rework it to eliminate the variables. But eventually I realized that eliminating the variables is a waste of time unless it can be done fairly easily. And if it is hard to do, it is likely to diminish the clarity of the code.
It would be interesting to see if the heavy-duty number crunchers use variables (e.g., finite element analysis, computational fluid dynamics, weather modeling). I would be surprised if they don’t use many variables, but I don’t really know.
@Russ @dwalend regarding some algorithms being easier or harder to grasp/learn using (im)mutability, allow me to share the following in case you find it of interest: Quicksort - a whistle-stop tour of the algorithm in five languages an…
Oh, I’m sure that’s true in many cases, and it’s part of my original point, way up at the top: low-level code definitely sometimes benefits from (or even requires) a
var or three, which is one of the reasons why it’s necessary. I’m primarily talking about business logic, which I think is where most programmers spend most of their time nowadays.
As for numerical analysis in particular, I honestly don’t know. I’ve seen people do it FP-style, but it’s not my focus, so I have no idea what the speed tradeoffs are.
And that’s why I am convinced that Haskell made a huge mistake not allowing variables. It may be a great language for learning FP principles, but it hampers productivity, at least for developing numerical algorithms. It’s like running with ankle weights – good for training parhaps, but not so great for actual productivity.
Sorry, but I get a bit annoyed by the notion that the only reason for variables in Scala is to provide training wheels for novices trying to learn FP.