Does anyone feel we are still in the silent film era of computer programming? Will we ever advance from text editors into something else and leave Vim,
Emacs etc. forever behind for good?
The 80-column IBM punch card was invented in 1928 and here we are almost 100 years later writing programs as a sequence of 80-column lines of text. It seems pretty obvious to me that we're stuck in a local maximum. I don't think visual programming is the solution but there must be another alternative. Sort of like how databases are based on text but are much more than text.
The proper response to "640K ought to be enough for anybody" is virtual memory, not 1280K.
People used to complain about Macromedia Director only having 24 layers, so they increased it to 48. But then what are you supposed to do if you want to make a map of the United States: leave out Alaska and Hawaii?
Think about it: why are you writing a textual comment right now and not sending a picture, video, sound clip of your message ? That would be much less "silent film"-ish, no ?
If you ask me : because I can "scan" in 10 seconds a page of different replies, something which would be impossible to do visually or aurally.
This is why 10-minute videos of "how to" in programming always enrage me. Though of course it makes a lot of sense for visual tasks such as 3D animation.
Software is currently described by written text that is transformed by other process (compilers/interpreters) to a different state and then executed. Often the execution does not work as expected due to undefined conditions or states within the "mathematical language", or misunderstanding of the scope or memory allocation or release, etc.
There certainly could and should be visual representations of state, memory utilization, registers, variable values and execution sequence based on the textual conditions described. Contrasts of expected execution vs actual.
Perhaps using GPT-3 that is taught each programming language and then a designer can specify the behavior and GPT-X* can build a solution that can be formally verified as provable. Then generate test cases and show the flow and proof of correct execution based on test conditions.
> Often the execution does not work as expected due to undefined conditions or states within the "mathematical language", or misunderstanding of the scope or memory allocation or release, etc.
nah, 90%+ of bugs are already present in the "paper" specification in my experience, without any programming language involved (and I'm mostly writing in C++ which is prone to the issues you mention).
I do! I am currently in the very early stages of creating a VR-based language. I believe that if we can represent programs more intuitively to our spatial, visual, and tactile senses, we can unlock more programming potential in more people.
The language from scratch, yeah. I have experience with UE4, so I'm going to be using that. Too early for screenshots, I'm still in the planning phase.
Basically I'm spending my time on a whiteboard thinking up simple programs (fibonacci sequence, graph traversal, etc), then drawing them out how I imagine they could be represented in a 3d environment. From that, I am distilling ideas of how to represent data types and algorithms in a way that doesn't look like spaghetti.
I hope not. The 'advancement' from text editing to something else would in all likelihood not be an advancement at all but a retardation instead. There is a reason that the invention of writing is the basis of civilization. The only way for leaving text editing to be left behind is if all these big companies forbid ordinary users to do any programming besides a very dumbed-down/graphical version of it. I am sure they would very much like this but it would be a form of tyranny.
"Plain text" writing using a "text editor", is much more limited in its expressiveness than writing on a piece of paper. There is no reason to believe that a character grid somehow is the pinnacle of programming.