I have my own to add which I'll tackle if I ever get smart enough. Code is horrible right now. The problem is that code is written linearly, when in our minds it is a graph. It's usually a bad sign when our minds see things differently than our computers do. I think if we could properly abstract the concepts, and change both our linear list of functions and our unsorted list of files to a single graph structure, we could understand our software so much better. I guess I'm thinking of UML diagrams with code, but in a way that feels natural to code in the first place, even for a beginner, not as a commented afterthought.
I just read an article today or yesterday about the reason that VIM's cursor keys are h,j,k,l or whatever.
I think the reason that code is ASCII text is pretty much the same reason VIM's cursor keys are h,j,k,l. All they had was a terminal so it had to be ASCII.
If you think about it, all information is structured and multidimensional. But people can only make one sound at a time, so information must be serialized to be communicated.
There are some easy starting points for understanding why we should get away from pure ASCII source code. One of them is to try first coding a complex UI with pure text and then build the same UI using a graphical editor with widgets.
Another one is this: just answer this question -- why can't I represent division in my source code using a numerator over a divisor the way that we are taught to write mathematics? Should we continue to pretend that we are required to edit our code on terminals from 1979?
As you suggest, this is definately a legacy issue of being tied to the teat of a 1980's terminal. People still like to edit in simple editors.
I've viewed it as a Model-View-Controller problem, where everyone is attempting to merge the Model and View into one. Technically your editor should be worrying about the View. It can draw division however you configure it to. But when saving to a Model source file, that should be portable, without any (or very little) formatting embedded in it (e.g. MultiMarkdown).
You should be able to customize your editor, much like swapping out a CSS file on a website, and skin it to your desires.
We talked about exactly this at a Camp Smalltalk almost a decade ago. If it had flown, at least one computer language (Smalltalk) could've allowed each programmer to have their own customized code formatting (View) while the code was actually stored as the Abstract Syntax Tree nodes.
I've been thinking exactly the same thing! My workaround so far has been to use IDEs that have some project management features, and separate the code into separate files.
Nice! I've started using files to separate logic, I recently went from 3 tiered (GUI/code/libraries) to 4 tiered (GUI design/GUI action code/data structures and algorithms/libraries) and added folders for elements (like a custom made back arrow image) and IO samples to run my programs on. Making my software structured like this has helped, but it's far from where you can see even a simple algorithm in it's graphical form that I see in my mind, as that algorithm would all be in a single section of my structure. I'll have to look into the separate files idea, though perhaps I'll build my own custom code editor, I'm skilled in things like that, perhaps I could pull it off.
