Functional bros be like

image of a hand-drawn owl with text: Wanted, Haskell, enemy of the ★mutable★ state

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/...
- I agree somewhat, but I'd also say any codebase needs some level of "dogmatic" standard (ideally enforced via tooling). Otherwise you still end up with bad, messy code (I'd even say messier, as you don't even get consistency)
- 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.
I'd agree with the first half, but not the second. Sometimes mutability allows for more concise code, although in most cases it's better to not mutate at all
- I feel like I should maybe have put a "probably" in there
  
  After all "there's no silver bullet", but in anything but a few edge cases, the rule applies, IMO
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)
Scala user unite! There are dozens of us, dozens!
- Scala? Can we reimplement it in Rust?
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.

Ngl, it'd solve a lot of bugs

The only const in life is to const all the things.

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.

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?

you mean let.

and then letting Hindley-Milner do the rest

let there = "light"

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.
- that's a nice way to look at it. thanks!
- Is the duality statement meant to be true in a technical sense?
I also do that. Very simple stuff, especially of those that are easy to optimize for the compiler, are often very close to functional programming paradigms.
Avoid shared mutable state like the plague in any paradigm and you'll be fine
- state management crying in the corner
I use a combination of both. Objects are declared const, all members are set in the constructor, all methods are const. It doesn't really work for some types of programs (e.g. GUIs) but for stuff like number crunching it's great.
- I heavily use classes while working on back end, and when I'm making a really self-contained logic, such as a logger or an image manipulation service.
  but since most frontend stuff heavily leans on functional side, I go with it

Needs more monads

Me irl

SSA