3 ms·
While I agree with you on visual programming, I think another issue raises itself: we are used to linear text editors - write one line after another - because t
by vegabook 11y ago
While I agree with you on visual programming, I think another issue raises itself: we are used to linear text editors - write one line after another - because they fit the way the computer works. Even breaking code down hierarchically as we do (functions, modules) still breaks a linear process into many linear processes. Yet increasingly as problems become more asynchronous / parallel, I sometimes wish for a more sophisticated code-creation paradigm, one where, for example, there would be some kind of two dimensional or even multidimensional visual representation of the logic of the program (even if those were each composed of linear text blocks). It's always possible to represent multiple dimensions in a lower-dimensional medium, but it becomes harder to conceptualize. So we have code folding tools, we have NERDTree etc to help us manage all the blocks, but sometimes I wonder if I could have some kind of multidimensional VIM that would allow the visual structure of my code more directly to map to the logic flow.
I have taken to coding on a 4k 40 inch monitor (highly recommended - the BDM4065UC from Philips is so good I bought two) because it allows to me see so much more of my code and the way the flow will jump around, to have it all in front of my eyes kinda thing, and I wonder if it would be even better to add some visual tools in there to do conditional flow control.
- flowerpot 11y agoCouldn't agree more. Code is highly dimensional while our text editors are two dimensional at best. In case you don't know these talks I think you will enjoy The Future of Programming and Inventing on Principle both by Bret Victor.
- RyanZAG 11y agoNot sure about this. If we're writing a scientific study with nothing to do with computers, we still use the standard "write one line after another" to describe the processes and methods we use. Sequential lists and trees may be a natural property of our reality in the same way gravity is? As you say, when problems become more complex it becomes more difficult to reason about when dealing with a linear flow. But as with writing a report, the key is in the layout. The solution to a problem like that may be simply defining your abstractions better in your code so that each logical block is contained and understandable -- the same as with a section in a report. Basically it's the age-old programming logic: instead of having large chunks of code where you have to reason through complex logic, create abstractions so that the complex flow is defined in an obvious way. There will still be complex pieces, but they can be pushed to leaf nodes in other classes/files and can be backed by formal algorithms with logical proofs. So, well, standard best practices from the 1960s and still standard best practices today. Why? Because it seems to fit with the laws of reality.
- vegabook 11y agohave to say - am not sure about it either! I'm simply intrigued by the question, namely, why do we still use linear tools for multidimensional problems? I think you have posited an excellent answer in that it's basically intrinsic to how we think and manage complexity, not only in CS.