←back to thread

John Carmack on mutable variables

(twitter.com)
498 points azhenley | 1 comments | 31 Oct 25 02:34 UTC | HN request time: 0.223s | source
Show context
y0ned4 ◴[31 Oct 25 09:22 UTC] No.45769960[source]▶
When I started programming in Haskell, where all variables are immutable, I felt like I was in a straitjacket

Then, suddenly, the enlightenment

replies(5): >>45770377 #>>45770438 #>>45770896 #>>45771052 #>>45771863 #
kypro ◴[31 Oct 25 10:23 UTC] No.45770377[source]▶
I've had this experience with going from PHP and JS to typed languages. Many years ago I was a type sceptic, but after being forced to use them, I now can't stand not having strict typing.

I'm sure others have written about this, but these days I think good code is code which has a very small area of variability. E.g code which returns a value in a single place as a single type, has a very limited number of params (also of single type), and has no mutable variables. If you can break code into chunks of highly predictable logic like this it's so so much easier to reason about your code and prevent bugs.

Whenever I see methods with 5+ params and several return statements I can almost guarantee there will be subtle bugs.

replies(3): >>45770944 #>>45773328 #>>45774936 #
1. runevault ◴[31 Oct 25 18:10 UTC] No.45774936[source]▶
Personally I'd tweak your last sentence to "return statements in the middle of a function."

Early returns at the very top for things like None if you pass in an Option type don't increase the risk of bugs, but if you have a return nested somewhere in the middle it makes it easier to either write bugs up front or especially have bugs created during a refactor. I certainly have had cases where returns in the middle of a beefy function caused me headaches when trying to add functionality.