Lately I’ve been thinking a bit about why programmers have preferences for different programming languages. Like, why is it that I want a language that is (speaking informally)
flexible (lets me do things many ways)
dynamic (decides what to do at run time rather than compile time)
reflexive (let’s me change the program source while it’s running, or change how to interpret a computation)
and other people want the opposite:
rigid (there’s one right way to do something)
static (decides what to do at compile time, often so much so that static analysis is possible)
fixed (the same code is guaranteed to always behave the same way no matter the execution context)
And I think a reasonable argument might be a difference in how much different programmers value the creation of a Cartesian boundary in the language, i.e. how much they want to be able to reason about the program as if it existed outside the execution environment. My preference is to move along the “embedded” end of a less-to-more Cartesian-like abstraction dimension of program design, preferring abstractions that, if not less hide the underlying structure, then at least more make it accessible.
This might not be perfect as I’m babbling a bit to try to build out my model of what the difference in preference comes from, but seems kind of interesting and a possible additional example of where this kind of Cartesian-like boundary gets created.
Not all programming is solipsistic. If you are trying to deliver to a lot of different end users and environments, its useful to have front loaded checking and predictable behaviour.
Lately I’ve been thinking a bit about why programmers have preferences for different programming languages. Like, why is it that I want a language that is (speaking informally)
flexible (lets me do things many ways)
dynamic (decides what to do at run time rather than compile time)
reflexive (let’s me change the program source while it’s running, or change how to interpret a computation)
and other people want the opposite:
rigid (there’s one right way to do something)
static (decides what to do at compile time, often so much so that static analysis is possible)
fixed (the same code is guaranteed to always behave the same way no matter the execution context)
And I think a reasonable argument might be a difference in how much different programmers value the creation of a Cartesian boundary in the language, i.e. how much they want to be able to reason about the program as if it existed outside the execution environment. My preference is to move along the “embedded” end of a less-to-more Cartesian-like abstraction dimension of program design, preferring abstractions that, if not less hide the underlying structure, then at least more make it accessible.
This might not be perfect as I’m babbling a bit to try to build out my model of what the difference in preference comes from, but seems kind of interesting and a possible additional example of where this kind of Cartesian-like boundary gets created.
I’m interested in fixed*, but with the ability to write programs that write programs.
(For a particular purpose.)
*and maybe the other things you grouped with it?
Not all programming is solipsistic. If you are trying to deliver to a lot of different end users and environments, its useful to have front loaded checking and predictable behaviour.