You must log in or register to comment.
Const everything by default
If you need to mutate it, you don’t, you need to refactor.
Dogmatic statements like this lead to bad, messy code. I’m a firm believer that you should use whatever style fits the problem most.
Although I agree most code would be better if people followed this dogma, sometimes mutability is just more clean/idiomatic/efficient/…
Define your terms before relying on platitudes. Mutability isn’t cleaner if we want composition, particularly in the face of concurrency. Being idiomatic isn’t good or bad, but patterned; not all patterns are universally desirable. The only one which stands up to scrutiny is efficiency, which leads to the cult of performance-at-all-costs if one is not thoughtful.
That is a… strange take.
Random example, imagine a variable that holds the time of the last time the user moved the mouse. Or in a game holding the current selected target of the player. Or the players gold amount. Or its level. Or health. Or current position.
In all those cases, the answer is to swap in a new variable and throw the old one away.
Legit question because i think I’m misunderstanding. But if its a const, how are you able to swap or replace it?
It’s only a const within a function. You can pass the value to another function and changing it as it’s passed. For example:
const int foo = 1 other_func( foo + 1)In functional programming, you tend to keep track of state on the stack like this.
Aaah okay i get it now :) that makes a lot more sense.
Sorry, I want to make an app that works, not a perfect art piece.
The app working isn’t good enough, it needs to be maintainable. From a professional perspective, unmaintainable code is useless code.
Code that mutates everywhere is generally harder to reason about and therefore harder to maintain, so just don’t do it (unless there’s literally no other practical way, but genuinely these are very rare cases)
The only const in life is to const all the things.
Ngl, it’d solve a lot of bugs
can someone explain please?
In functional programming, everything is seen as a mathematical function, which means for a given input there is a given output and there can be no side effects. Changing a variable’s value is considered a side effect and is thus not possible in pure functional programming. To work around this, you typically see a lot of recursive and higher order functions.
Declaring all values as const values is something you would do if you’re a diehard functional programmer, as you won’t mutate any values anyway.
thanks, kinda understand
What is the best practice then when you want to update a variable’s value?
Depends on how deep down the rabbit hole you want to go :p
- creating a new variable that contains the updated value
- recursion (e.g. it’s not possible to make a loop that increments i by 1, but it is possible to turn that loop into a function which calls itself with i+1 as argument)
- avoiding typical types of operations that would update variable values. For example instead of a for loop that updates every element of a list, a functional programmer will use the map function, which takes a list and a function to apply to each element of that list to create an updated list. There’s several more of these very typical functions that are very powerful once you get used to using them.
- monads (I’m not even gonna try to explain them as I hardly grasp them myself)
A monad is just a monoid in the category of endofunctors, what’s the problem?
Why even use variables in the first place? Just place the values directly into your code. If you need to change a value, that’s just bad planning. Hell, why even use values either? Just run a loop on the INC instruction until you get the value you need. It’s just efficient programming.
you mean
let.and then letting Hindley-Milner do the rest
I oscillate between using more functional paradigms and more object-oriented ones. is that normal?
I use a linter BTW(TypeScript) if that is a useful info.I think using both is normal. Closures and objects are duals of each other. Do whatever is understandable and maintainable, neither paradigm is magic.
Is the duality statement meant to be true in a technical sense?
Yeah! For example, if the language allows closures to capture state, they can act like properties on an instance.
I don’t see the duality
A closure is a function with captured state. An object is state with methods.
