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.
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.
Also: ’ Introducing Assignment invalidates the Substitution Model of Evaluation and violates Referential Transparency - as explained in SICP (the Wizard Book)’ Introducing Assignment invalidates the Substitution Model of Evaluati… (please download the slides to see properly-looking ones).
Which is basically just saying that Haskell is a huge mistake.
Not sure about numeric programming, but my (limited) experience with Haskell in other areas is quite different, and when I look for people discussing numeric programming in Haskell, the pain points seem to be elsewhere, see e.g. this thread.
I don’t think this correctly summarizes the opinions expressed in this thread. It has been pointed out that vars definitely have their place in a hybrid language like Scala for more OO leaning code bases and that you may want to use them in an FP context for performance reasons and for instances where local mutable state actually makes code more legible (ensuring this use is well encapsulated and doesn’t leak, though).
Personally I don’t think this speaks against marking them an “advanced” feature, though. (But I wouldn’t strongly advocate it, either.) I try to be cautious with introducing mutable state even when coding in Java. And I don’t mind adding the occasional language feature import. If I were working on a code base that has justification for using vars all over the place, I’d probably rather be complaining about the general lack of support for a custom project prelude than about this specific constraint.
In the context of learning FP, to me vars look like stabilizer/training wheels, indeed. I’d think it’s much harder to go from bike with stabilizer wheels to bike proper than going from balance bike to bike proper - it’s really hard to unlearn stuff. Thus I’d be very skeptical about introducing vars early if the goal is learning FP from scratch.
Just as “assume” means it makes an “ass of u and me”, it’s generally accepted that “assignment” means “I’m an ass, I meant …” because the value of the variable always turns out to be different from the intended value.
From the SICP book: "if we wish to model state variables by ordinary symbolic names in the programming language, then the language must provide an assignment operator to enable us to change the value associated with a name
…
Here are the definitions of balance and withdraw:
Decrementing balance is accomplished by the expression
(set! balance (- balance amount))
This uses the set! special form, whose syntax is
(set! <name> <new-value>)
Here <name> is a symbol and <new-value> is any expression. Set! changes <name> so that its value is the result obtained by evaluating <new-value>. In the case at hand, we are changing balance so that its new value will be the result of subtracting amount from the previous value of balance.
Why bother, though? Do you find bugs that way? I don’t–I introduce new ones instead.
I write simple stuff functionally because it’s easier. But for some algorithms, I find that the constraints of operating functionally (especially at acceptable speed) get in the way. In such cases, I use mutability to implement the algorithm.
But then—I’m done! Why would I change the easier-to-grok code into another form where it will be harder to modify and understand later? No thanks!
If I want it to look immutable from the outside, I wrap it somehow. But the core stays mutable.
@Ichoran We all program differently, perceive problems differently and solve problems differently. I bother because that works for me. The feature I like the most is that Scala lets us perceive and solve problems differently, although when this feature is abused, I do get upset… It’s allowable to be different, but when collaborating we should be mindful of others.
And, yes, I do sometimes find bugs that way, but I appreciate that you strive to introduce new ones
