11–20 of 22 posts
Edit: There is also Agilent VEE.
We find visual based programming in the form of CAD used in construction, aviation, semiconductors, etc. They are big complex programs and, of course, expensive. If you can use visual tools to layout billions of transistors, then you could use it to write programs. But ... the techniques for moving between levels of abstraction in software haven't been understood yet. Systems like Scratch and Alice provide visual pro…
A second reason is that higher level languages for mechanical design hasn't been successful. my guess it's because mechanical objects are very cost sensitive, so people use low level tools, similar to embedded developers using c+asm.
On the other hand , if you look at fpga and chip design , where complexity has exploded and transistors price really plummeted , you see a move to higher and higher level textual languages, from the schematic systems used in the past.
Another interesting use case for visual languages is visual domain specific languages. metacase has some success with this. my guess is that visual languages can be much easier for domain experts to use and understand, in some cases.
Anyway, I think a framework that includes a web-based data handling thing might be a success.
Earlier quoted context omitted.
GUI layout is not programming; it's GUI layout. (Or, more concretely: it's specifying a dataset.) When software construction is finally "solved", visual representations and interfaces will be common. Our current mechanisms are simply too crude, lacking sufficient methods of abstraction, to work well. In fact, they do the opposite and point out what deep flaws exist in the current state of the art.
HTML, CSS, XML, SQL, JSON, YAML, and other configuration languages are also not programming; they're specifying a dataset. I can basically guarantee that any large project will have large quantities of them, though, and that code will have bugs. For that matter, Lisp is not programming; it's specifying a dataset. Except, well, it actually is programming, because you can execute that dataset. When you push it far enou…
To me, HTML, CSS, XML, etc. are not code and do not have real bugs; they have design flaws and syntax flaws, just as a picture may need more red or blue. (But note that I'm not sure there's a right answer here, and I certainly respect you and your opinion.)
I also think that it's not about abstractions but better abstraction mechanisms which work to reduce complexity at any level. It may get more complex, but you can manage that complexity much more skillfully. I am absolutely confident that we can find better abstraction mechanisms.
It already has succeeded in one very limited area: GUI component layout. People use XCode/Netbeans Matisse/DreamWeaver all the time to build their UIs. It fails in other areas because code is remarkably info-dense, and if you split that out into individual components, it takes a huge amount of screen space and visual manipulation for even simple subroutines. I encourage you to take a simple function and draw out the…
GUI layout is not programming; it's GUI layout. (Or, more concretely: it's specifying a dataset.) When software construction is finally "solved", visual representations and interfaces will be common. Our current mechanisms are simply too crude, lacking sufficient methods of abstraction, to work well. In fact, they do the opposite and point out what deep flaws exist in the current state of the art.
GUI layout in the sense of creating a series of instructions for a computer to automatically create and display the same image is much closer to programming than you're making it out to be. In fact, I would say that it is programming at a higher level, as you're not producing an image - you're producing code that tells the computer how to produce that image. If that's not programming, I don't know what is.
The same reason visual writing hasn't caught on. Our brains are wired for textual language. It's generally hard to express highly abstract ideas with just pictures.
The same reason visual writing hasn't caught on. Our brains are wired for textual language. It's generally hard to express highly abstract ideas with just pictures.
The Egyptians would like to disagree with you. The Chinese, Japanese and other ideographic cultures are right behind them in line.
Earlier quoted context omitted.
Ideographic writing is still sequential text.
In the same sense that picture books are sequential text.
In contrast, every natural language that I've seen, along with every remotely successful programming language, uses a one dimensional sequence of words and/or symbols with an implicit grammatical structure. That is probably no coincidence.