The language is actually C (you can also use Python, etc. I think the original underlying language was a variant of Oberon). The painful part was the graphical editor, or, I'd say, the idea of using graphics for programming instead of text. Imagine aligning all these rectangles and then realizing that you got a part of algorithm wrong: now you'll have to realign everything!
I think it would be much easier to edit some textual representation, and then use a program to convert it to the graphical one, if you want to read it this way.
This reminds me of a coworker who uses National Instruments' LabView's graphical programming capabilities to parse text files. Graphical programming is just not suitable for some tasks.
I see this a lot in LabVIEW projects (using it for things in which it is cumbersome). I think it is a symptom of the "golden hammer syndrome". LabVIEW is really, really efficient for some things and people become highly proficient at it. Unfortunately, those same folks are apt to use it for things in which it is ill-advised like text-parsing.
I like to think of graphical programming languages as DSL's: when they're aimed at the right problem, they're like a hot knife through butter compared to a general purpose tool. But when you start using DSL's for things in which they are not intended you end up with nightmarishly obscure codebases.
But seriously, these look just like the flowcharts that were all over CS in the seventies. And the code that's generated (based on the examples from edent and dchest) is basically unmaintainable GOTO-hell that looks like what you get from decompiling code without symbols...
I'd be curious to see what gets generated for the parallelism stuff, tho.
This has sat in my bookmarks far too long. Visual programming techniques are very different and vastly under developed compared to the plethora of other 'toy languages' that get more development.
Gotta love software docs that show getting drunk on various amounts of vodka as an explanation of their select statement!
This actually looks useful -- the simple set of rules they suggest make a lot of sense for general flowchart readability, and these could be easily shared with business partners of only a half-technical mindset.
I was curious how you would handle event driven architectures with it, however -- or is that outside the intended scope?
Strictly speaking all programming languages are visual. Except ones are much easier to write because typing on a computer today is way faster than drawing.
Once drawing becomes more productive (which I don't see exactly how, to be honest) then diagram-based languages will raise their heads. Until then, no, thank you.
20 years ago, during the peak of the CASE hype, there used to be several others.Borland ObjectVision, IBM VisualAge, Siemens EasyCase were some of them.
Problem of all this tools is: It's proven that they don't scale.
The sample programms that come with them all look nice and tidy, but god beware if you have to solve some real problem with real error handling.
Right now Matlab Simulink&Stateflow (+some kind of code generator) is the only system usable for fingerpainting programms of significant size.
Is there a textual input representation to go along with the visual analysis one? I love using flowcharts to explain and comprehend complicated things, but the UIs for actually drafting them haven't quite made it into the 1960s yet and are painful as hell. Going from the video, this tool is better than most but still lots of modal button-hunting and handle-dragging and manual alignment.
The .drn file format is a SQLite database but it looks like it encodes the coordinates of the elements directly rather than storing symbolic relationships and doing a layout. If you could use a Graphviz-like language to describe the diagrams but add the Drakon rules for structure and layout (and presentation) I'd be a lot more enthusiastic.
Hey, maybe we will get to ObjectVision all over again, only this time it can work! Or continue to be developed, at least.
I remember putting in around 30 hours on a consulting project trying to use ObjectVision 2.1 (I think that was the version - been a while) before finally giving up and going to FoxPro in disgust... Had to keep project deadlines.
I think this is great for getting non-technical stakeholders into the development process.
Nearly anyone should be able to understand a flowchart and also make improvements and understand why that feature is more or less difficult to implement.
