21–28 of 28 posts
Earlier quoted context omitted.
Does Erlang handle the stack better? In most languages this would blow up if N got big enough.
Yes. Erlang has tail recursion which helps prevent that http://learnyousomeerlang.com/recursion
Earlier quoted context omitted.
Agreed. Erlang is another language with single assignment, i.e. every variable assignment target must have a new name. It's incredibly easy to see what calculations and conditions affect the final outcome.
How do you do a for loop in Erlang or something that sums up a value ?
> If we look to a language like Haskell we see that reassigning variables, in general, is frowned upon (is it even possible?) This is perfectly valid Haskell: main = do let a = 7 print a let a = 9 print a but you'll get a warning for it: tmp.hs:4:7: warning: This binding for ‘a’ shadows the existing binding bound at tmp.hs:2:7
The warning says it right away, the first a is shadowed, not reassigned, here. The difference is that when a is reassigned the 7 is lost, while it should be still around when shadowed. I don‘t know of a way to access the 7 in this example however.
I'm having a hard time understanding why they should be treated any differently than normal variables. I suppose the way that I view parameters is as regular variables who are initialized to values provided by the caller. Is there any argument against default mutability which still makes sense when viewing parameters from this perspective?
I think immutability of arguments should be optional by using a const keyword, like in c: int add(const int a, const int b);
I'm having a hard time understanding why they should be treated any differently than normal variables. I suppose the way that I view parameters is as regular variables who are initialized to values provided by the caller. Is there any argument against default mutability which still makes sense when viewing parameters from this perspective?
The difference between a local variable and a function argument is that altering the argument has an effect outside the function, and that the effect is invisible in that calling the function doesn't tell you that it will change the argument's value. It is a minor sin in the case of e.g. massaging data to turn NaNs into 0s or provide default values. It is also fine in the case of performance-critical code: c string m…
I'm having a hard time understanding why they should be treated any differently than normal variables. I suppose the way that I view parameters is as regular variables who are initialized to values provided by the caller. Is there any argument against default mutability which still makes sense when viewing parameters from this perspective?
The difference between a local variable and a function argument is that altering the argument has an effect outside the function, and that the effect is invisible in that calling the function doesn't tell you that it will change the argument's value. It is a minor sin in the case of e.g. massaging data to turn NaNs into 0s or provide default values. It is also fine in the case of performance-critical code: c string m…
And yes, passing a reference or pointer by value enables you to have effects that are visible outside the function, but if you copied the reference or pointer value to a local variable, you still could have effects visible outside the function, so that isn't a question of how arguments should be treated; it's a general question of how functions should behave.
I feel the author isn't going far enough- make all variables immutable by default unless explicitly declared otherwise, and even then highly discouraged. Where mutable variables are needed, I prefer to hide that logic inside a method that exists solely to do that dirty business on an abstract level, not specific to my business logic. That let's me test the 'dirty' mutable method in an isolated place and removes a who…
Historical anecdote: Algol-68 disassociated variable assignment from mutability already 50 years ago. Whenever mutability was desired, a reference to a mutable value holder was used. Example of immutable assignment: int n = 2 Example of reference to mutable value: ref int n = (heap int := 2) However, in order to make Algol-68 code look more similar to Algol-60, they introduced backwards-compatible shorthands, so for…