3 ms·

It seems that the author is trying to make a kind of grand statement but the epiphany isn't felt. A program without any state seems uninteresting, state without

It seems that the author is trying to make a kind of grand statement but the epiphany isn't felt. A program without any state seems uninteresting, state without logic to manipulate it seems uninteresting as well - no computer ships with only registers or only an ALU after all. It seems that we must include logic in the discussion as well but if we do, the title needs to be updated to "all programming philosophies are about programming". This is not a deliberately reductive take, I just can't think of any other meaning.

yipbub 4y ago
I found that a big jump in my quality of design was when I started thinking about what state was necessary, what transformation needed to be done, and by what entity. Before that, I used to code for the task at hand, and create data structures mostly for the task at hand. Thinking about what each program might need to know and in what format relative to it's role just made things smoother. It wasn't a large leap conceptually, but the mental model change came from a long lost hacker news comment along similar lines.
skedaddle 4y ago
"all programming philosophies are about programming" I don't think it is a reductive take. The second instance of the term here instead involves the more traditional concept program: "a regular plan of action in any undertaking" https://www.dictionary.net/program https://www.dictionary.net/program Programming (in the sense of software construction) paradigms, philosophies, indeed "languages" etc., are about regularizing plans of action for complex computational undertakings.. usually.
catapart 4y ago
I feel this, but I think it's just a thing that programmers do. It was 10 years ago when I realized that all programming methods are about dealing with (conceptualizing/architecting) state. It made a lot of stuff "simple" to me that had previously been "complex" and I got a lot of value out of that change in paradigm. Not so much that I didn't assume all my peers didn't already know it (I find I'm usually "behind the curve" when it comes to piecing obvious things together), so didn't evangelize it to anyone, but I definitely understand why someone would. It feels secret, because no one really talks directly about how all programming paradigms are about state. But once you realize it, you can start to see how a lot of high-level programmers reference it when they talk, all the time. Just something that "everybody knows", once you spend enough time working in code. Personally, it wasn't the realization that it's all about state that was particularly exciting. It was using that new interpretation to understand how I could mix and match different types within a single project, to make each separable/modular piece of it, rather than dogmatically sticking to a single paradigm throughout. I think there's a definite mental breakthrough when a programmer can confidently use multiple different state paradigms to handle what would otherwise be a clunky or unwieldy implementation in a single paradigm.

yipbub 4y ago

I found that a big jump in my quality of design was when I started thinking about what state was necessary, what transformation needed to be done, and by what entity. Before that, I used to code for the task at hand, and create data structures mostly for the task at hand. Thinking about what each program might need to know and in what format relative to it's role just made things smoother. It wasn't a large leap conceptually, but the mental model change came from a long lost hacker news comment along similar lines.

skedaddle 4y ago

"all programming philosophies are about programming" I don't think it is a reductive take. The second instance of the term here instead involves the more traditional concept program: "a regular plan of action in any undertaking" https://www.dictionary.net/program https://www.dictionary.net/program Programming (in the sense of software construction) paradigms, philosophies, indeed "languages" etc., are about regularizing plans of action for complex computational undertakings.. usually.

catapart 4y ago

I feel this, but I think it's just a thing that programmers do. It was 10 years ago when I realized that all programming methods are about dealing with (conceptualizing/architecting) state. It made a lot of stuff "simple" to me that had previously been "complex" and I got a lot of value out of that change in paradigm. Not so much that I didn't assume all my peers didn't already know it (I find I'm usually "behind the curve" when it comes to piecing obvious things together), so didn't evangelize it to anyone, but I definitely understand why someone would. It feels secret, because no one really talks directly about how all programming paradigms are about state. But once you realize it, you can start to see how a lot of high-level programmers reference it when they talk, all the time. Just something that "everybody knows", once you spend enough time working in code. Personally, it wasn't the realization that it's all about state that was particularly exciting. It was using that new interpretation to understand how I could mix and match different types within a single project, to make each separable/modular piece of it, rather than dogmatically sticking to a single paradigm throughout. I think there's a definite mental breakthrough when a programmer can confidently use multiple different state paradigms to handle what would otherwise be a clunky or unwieldy implementation in a single paradigm.