worldsayshi
September 1st, 2010, 08:52 PM
Textual programming is in most cases the only way to go as of today (if you know any actually usable/serious non-textual programming methods, tell me!). And the command line shell is still a vital tool for doing anything out of the ordinary (or is it?).
While time apparently brings us an ever increasing amount of gui applications each for narrow purposes there seems to be no gui capable of handling such a generic case as that of constructing efficient algorithms or putting together a set of machine interpretable commands*.
Maybe one of the issues are that of "application isolation". One gui app cannot speak the others, leaving apps to do single tasks, left limited to the whatever results the app can produce alone. In Android there seems to be a (-n early) suggestion how to solve such issue.
Another issue would be that the programmer seldom would see what the machine sees in a graphical (non-textual) programming environment, or rather, what shows on the screen would be conceptually further away from the zero's and one's than traditional programming languages. The interface would become high-level and non-generic.
The third and probably most relevant issue might be the difficulty in finding generic ways of visualizing abstract concepts and relating them to each other. Though-maps and node-maps and whatnot has severe limitations in visualizing lots of complexity (at least at first and second glance).
Given the success of gui's it might/should/can seem redundant to mention why a graphical programming interface would be a step forward. Just saying that it should be graphical/non-textual interface doesn't really convey any pro's though. It can mean a lot of things. To some implied meaning of the term graphical programming interfaces, or rather visual programming interfaces, are already a reality. Modern developing environments offer lots of visual aid. But I'm rather targeting the actual visualization/manifestation of the source code. In that area, little progress has been made (to the extent of my knowledge).
Looking at that area, I think that much can be gained for trying out new paradigms. Visual programming methods might be what is required to turn programming competence mainstream. Just look at any other computer related interface method. Few of those that have become mainstream have been so before there have been a visual way of doing it. Visualized working tools can, if done right, mean lowered learning curves.
*= Or whatever it is we do when we are coding away
PS
Please don't be to hard on me for the use of terms. Some expressions are used in a quite liberal way in lack of better known words (English is not my native language).
While time apparently brings us an ever increasing amount of gui applications each for narrow purposes there seems to be no gui capable of handling such a generic case as that of constructing efficient algorithms or putting together a set of machine interpretable commands*.
Maybe one of the issues are that of "application isolation". One gui app cannot speak the others, leaving apps to do single tasks, left limited to the whatever results the app can produce alone. In Android there seems to be a (-n early) suggestion how to solve such issue.
Another issue would be that the programmer seldom would see what the machine sees in a graphical (non-textual) programming environment, or rather, what shows on the screen would be conceptually further away from the zero's and one's than traditional programming languages. The interface would become high-level and non-generic.
The third and probably most relevant issue might be the difficulty in finding generic ways of visualizing abstract concepts and relating them to each other. Though-maps and node-maps and whatnot has severe limitations in visualizing lots of complexity (at least at first and second glance).
Given the success of gui's it might/should/can seem redundant to mention why a graphical programming interface would be a step forward. Just saying that it should be graphical/non-textual interface doesn't really convey any pro's though. It can mean a lot of things. To some implied meaning of the term graphical programming interfaces, or rather visual programming interfaces, are already a reality. Modern developing environments offer lots of visual aid. But I'm rather targeting the actual visualization/manifestation of the source code. In that area, little progress has been made (to the extent of my knowledge).
Looking at that area, I think that much can be gained for trying out new paradigms. Visual programming methods might be what is required to turn programming competence mainstream. Just look at any other computer related interface method. Few of those that have become mainstream have been so before there have been a visual way of doing it. Visualized working tools can, if done right, mean lowered learning curves.
*= Or whatever it is we do when we are coding away
PS
Please don't be to hard on me for the use of terms. Some expressions are used in a quite liberal way in lack of better known words (English is not my native language).