3 ms·

Of course people who use spreadsheets are programming; they're building data structures (with columns as object fields), generating values from formulas, and de

Of course people who use spreadsheets are programming; they're building data structures (with columns as object fields), generating values from formulas, and debugging the program's execution when editing cells. What develops typically don't get is that the paradigm of the programming language and environment matters a lot, triple so for people without formal training in coding. Most people who can code with a spreadsheet would be totally unable to create a very simple shell script, because the paradigm of imperative, syntax-led classic programming languages require building a mental model of a whole Turing machine in your head, which requires years of training. That's the gulf the GP was referring to; not from which people happen to use them, but from how they think about coding. The functional-reactive paradigm (and spreadsheets in particular) avoid that need, because they're highly composable so you can truly think of each part of the program in isolation, something which side-effects and program flow in imperative programs won't allow.

stormbrew 5y ago
> That's the gulf the GP was referring to; not from which people happen to use them, but from how they think about coding. I'm calling out an implicit bias that always comes up in discussions like these and I see lurking behind this sentiment, because these two things are inextricably related, not an accidental correlation. They think better in this paradigm because its a better suited paradigm to their actual work, and it fits better with things they understand already because of their experiences and knowledge. When we prioritize the "thought patterns" of professional programmers we forget this, and then we lament the lack of understanding for our field from people outside of it. Our solutions, when we look at it this way (with a stark divide between "programmers" and "non-programmers"), end up demanding that they come to our understanding instead of us to theirs. And that's basically always doomed to fail. This is important.
- TuringTest 5y ago
  > When we prioritize the "thought patterns" of professional programmers we forget this, and then we lament the lack of understanding for our field from people outside of it. Our solutions, when we look at it this way (with a stark divide between "programmers" and "non-programmers"), end up demanding that they come to our understanding instead of us to theirs. And that's basically always doomed to fail. I concur, that's a good way to put it. The "way of the programmer" requires an unnatural way of reasoning that takes a lot of effort to master, and requires a lot of short-term memory effort to mentally simulate how the code behaves. I don't even think this programming style is truly required for professional programmers either; more a by-product of how programming started as a way to feed instructions to mono-processors in the context of mathematics and physics computations on limited hardware. Symbolic business logic doesn't typically depend so strongly on the specifics of runtime execution, and recently there has been a very active movement to build new programming environments which emphasize the relationship between code and data, rather than between code and intermediate states of computation as in classical programming languages.

stormbrew 5y ago

> That's the gulf the GP was referring to; not from which people happen to use them, but from how they think about coding. I'm calling out an implicit bias that always comes up in discussions like these and I see lurking behind this sentiment, because these two things are inextricably related, not an accidental correlation. They think better in this paradigm because its a better suited paradigm to their actual work, and it fits better with things they understand already because of their experiences and knowledge. When we prioritize the "thought patterns" of professional programmers we forget this, and then we lament the lack of understanding for our field from people outside of it. Our solutions, when we look at it this way (with a stark divide between "programmers" and "non-programmers"), end up demanding that they come to our understanding instead of us to theirs. And that's basically always doomed to fail. This is important.

TuringTest 5y ago
> When we prioritize the "thought patterns" of professional programmers we forget this, and then we lament the lack of understanding for our field from people outside of it. Our solutions, when we look at it this way (with a stark divide between "programmers" and "non-programmers"), end up demanding that they come to our understanding instead of us to theirs. And that's basically always doomed to fail. I concur, that's a good way to put it. The "way of the programmer" requires an unnatural way of reasoning that takes a lot of effort to master, and requires a lot of short-term memory effort to mentally simulate how the code behaves. I don't even think this programming style is truly required for professional programmers either; more a by-product of how programming started as a way to feed instructions to mono-processors in the context of mathematics and physics computations on limited hardware. Symbolic business logic doesn't typically depend so strongly on the specifics of runtime execution, and recently there has been a very active movement to build new programming environments which emphasize the relationship between code and data, rather than between code and intermediate states of computation as in classical programming languages.