- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
Made with KolourPaint and screenshots from Kate (with the GitHub theme).
Made with KolourPaint and screenshots from Kate (with the GitHub theme).
Because sometimes that
let
can be replaced by other things likeconst
. Which can be managed statically by the machine and not by my (imperfect) ability to know if it’s mutated or notI think you can do
const thing = ... as const
to lock down the mutation?So is
let
in some languages. In Rust, you have to constantly opt out from immutability withlet mut
, which makes writing more procedural code feel like you’re fighting with the compiler, and otherwise I don’t really see the rationale behind full functional coding. I only had a bug caused only once by unwanted mutation, the hardest part fixing it was to learn the proper use of my debugger tool.Ok but, in the second example you typically just put final or const in front of the type to denote immutability. I still don’t see the advantage to the first declaration.
oh for sure, but I think that’s the rarer case for language implementions. Having a consistent structure with alternative keywords in static positions is just easier to develop an AST for. Personally my favorite language doesn’t even allow for const values (except by convention) so it’s really just a matter of preference
Is it rarer? I think a lot of modern languages go for the first option but pretty much all C style languages use the latter. It’s probably a wash for which is more popular I’d think.
I’m talking about quantity not the popularity of a given language. There are certainly a number of popular languages that follow that convention