Hacker News new | ask | show | jobs
by Risord 2463 days ago
I don't either consider living without local mutable variables and loops as a clear improvement. But I do think that designing your application such way that it won't rely (or rely as little as possible) on spooky actions at a distance is.
2 comments

Sure, but that's a best practice in every language. Saying "this language makes you do the thing you swear you're doing anyway" doesn't sound like a practical difference.

The second-order effect of "everyone has to do what you're claiming you do" is meaningful, yes. But it's really hard to convince programmers there's value there. Look how many people still say C is a fine language, you just have to not mess up. And not rely on any library that messes up. It's really tough to market the thing everyone should be doing anyway as a feature, even when the difference between "should do" and "is required to do" is huge in practice.

I like pragmatic definition of FP by Eric Normand: We recognize separation between data, calculations (pure functions) and actions (impure stuff) while using always simplest category.

To me it seems like especially juniors would get benefit from this separations. So is it more like: "this language makes you do the thing that experienced programmers do once a while and juniors avoid [purity] at all costs". It would be interesting to see how juniors would work with functional(-first) language. Would they be able to craft same not-even-god-knows-what-it-does piece of art? What I have seen so far lot of side effects is typically required.

Oh local variables in languages like Forth or Factor are handy. I have not yet gotten used to stack-shuffling. Will I ever? :D
Don't have experience about stack oriented languages nor sure is this relevant reply.

But to clarify: local mutable variables are fine because effect of changing value is clear due well specified scope. Mutation is not observable from outside of a function.

Opposite is true for using mutable data structures (with immutable variables): scope of effect must be checked manually, it's easy to leak function abstraction and with 3rd party code all the bets are off.