= 27d567bc2d48d9f40e9ccc20ea370b15)
Incorrect comments on More intuitive programming languages - Less Wrong Discussion
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (89)
When modelling how distant parts fit together, you use abstraction. You don't need to model how the internals of your sort function interact with other parts of your code, you just remember that it sorts things. You're still thinking in terms of one operation at a time, just using more high-level operations.
Notice that software design best practices improve your ability to do this: separation of concerns, avoidance of mutable global variables, lack of non-obvious side effects.
From my own experience as a programmer, I think this is idealized to the point of being false. Finding a few distantly-separated, interacting regions of code which don't respect a clean abstraction is pretty common, especially when debugging (in which case there is an abstraction but it doesn't work).
This isn't really possible in many cases. Many programs are resource-constrained. And the heap, IO resources, etc, are shared state. We don't have good ways of abstracting that away. Likewise, synchronization is still a giant can of worms.