As a tangentaly related point...
Has any visual programming language ever been successful?
The guys at Epic are really pushing their blueprint system, and a lot of people like it... but its inherantly tied to the engine.
DRAKON – An algorithmic visual programming language
11–20 of 55 posts
Re: DRAKON – An algorithmic visual programming language
#12what are some advantages/disadvantages of visual programming languages compared to text based ones?
I did a fair amount of work with LabVIEW long ago. I also played with another visual language for the Mac that was floating around in the 90s. This isn't a slam against LabVIEW, which would be unfair in any event since it's been that long and their product has changed a lot.
Advantage: It seemed easy for beginners to learn how to do simple things, such as sequencing the operations and measurement in a lab experiment or instrument prototype. That's pretty cool.
Disadvantages: 1) For me, I happen to suffer from severe eyestrain and wrist / neck fatigue when dealing with tiny graphics and fine mouse work. I would not be able to program a graphical language all day.
2. My impression that it's hard to modify / refactor code because of the laborious manual effort needed to move graphics around. Programs tend to become unwieldy when they expand beyond one screen.
3. I think that text is the easiest and quickest way to prototype a new programming language idea, and there is rapid evolution and proliferation of both text based languages and programming tools like specialized editors and environments. It's also easier to port a text based language to a new machine. I think that evolution would be slower if people had to develop a graphical framework to try out a new language. It's also very easy to share source code, either full programs or snippets, on the Internet via text, even across different languages with a bit of manual translation.
Re: DRAKON – An algorithmic visual programming language
#13what are some advantages/disadvantages of visual programming languages compared to text based ones?
If the algorithm is to be distributed over multiple processors capable of executing different instructions, it is best represented as dataflow. (Dataflow algorithms are directed graphs, with data flowing along edges between vertices, each of which contains a single processing step.) This is because dataflow captures all the parallelism inherent in the algorithm without the programmer having to assign tasks to processors explicitly. While text-based dataflow languages exist, the directed graphs which comprise dataflow programs are more naturally represented graphically.
Having started down the dataflow route, further advantages then manifest themselves: most program development can be done by drag and drop, rather than typing; strong type checking can be done while edges are being drawn; the directed graphs used to draw code can double as completely general data structures; and the graphics libraries used to develop the language can be made available to the programmer.
The visual dataflow programming language I am developing is described here: http://web.onetel.com/~hibou/fmj/FMJ.html
Some visual languages, such as DRAKON and GRAIL, are based on conventional flowcharts showing flow of control, rather than flow of data. Flow of control, however, can be adequately represented as text.
Re: DRAKON – An algorithmic visual programming language
#14The editor:
http://drakon-editor.sourceforge.net/
(it is at the bottom of Wiki page but added it here for quicker access).
Also Stepan Mitkin gave an Erlang Factory talk this year about the Erlang backend for DRAKON:
Re: DRAKON – An algorithmic visual programming language
#15what are some advantages/disadvantages of visual programming languages compared to text based ones?
I did a fair amount of work with LabVIEW long ago. I also played with another visual language for the Mac that was floating around in the 90s. This isn't a slam against LabVIEW, which would be unfair in any event since it's been that long and their product has changed a lot. Advantage: It seemed easy for beginners to learn how to do simple things, such as sequencing the operations and measurement in a lab experiment…
1. Not all visual languages are the same, just as not all text-based languages are the same. The main problem is there aren't many in widespread use, and they tend to be quite specialized, so you might not find one which you're completely happy with.
2. Programs, or rather functions/procedures/subroutines should, with very few exceptions, be displayable on a single screen. If they are larger, they should be split up. This applies whether the language is textual or graphical. Moving graphics around should make no difference to how a dataflow program executes.
3. Yes, it's easier to develop a new text-based language, because so much research has been done on them, and you don't need to develop an editor along with the language. But there are hundreds in active use, which are constantly evolving. If you want a new set of features, you can add it to an existing language or create your own dialect. Visual code must have either a text or binary representation of the source which can be shared. It may not be human-readable but that's not the intention.
Re: DRAKON – An algorithmic visual programming language
#16Using SQLite for persistence is quite interesting!
Re: DRAKON – An algorithmic visual programming language
#17As a tangentaly related point... Has any visual programming language ever been successful? The guys at Epic are really pushing their blueprint system, and a lot of people like it... but its inherantly tied to the engine.
LabVIEW's graphical language G has been around for a while and is widely used for certain kinds of things. Enough people hate it to consider it successful.
Re: DRAKON – An algorithmic visual programming language
#18Earlier quoted context omitted.
I did a fair amount of work with LabVIEW long ago. I also played with another visual language for the Mac that was floating around in the 90s. This isn't a slam against LabVIEW, which would be unfair in any event since it's been that long and their product has changed a lot. Advantage: It seemed easy for beginners to learn how to do simple things, such as sequencing the operations and measurement in a lab experiment…
1. Not all visual languages are the same, just as not all text-based languages are the same. The main problem is there aren't many in widespread use, and they tend to be quite specialized, so you might not find one which you're completely happy with. 2. Programs, or rather functions/procedures/subroutines should, with very few exceptions, be displayable on a single screen. If they are larger, they should be split up.…
[deleted]
Re: DRAKON – An algorithmic visual programming language
#19As a tangentaly related point... Has any visual programming language ever been successful? The guys at Epic are really pushing their blueprint system, and a lot of people like it... but its inherantly tied to the engine.
Max/MSP is pretty widely used for music and audio: https://cycling74.com/products/max/
Re: DRAKON – An algorithmic visual programming language
#20As a tangentaly related point... Has any visual programming language ever been successful? The guys at Epic are really pushing their blueprint system, and a lot of people like it... but its inherantly tied to the engine.
Depends what you mean by successful. Most industrial Programmable Logic Controllers (PLCs) can be programmed with a visual language, typically function block diagrams. The blocks are then functions and the lines represent a data value and not necessarily the direction of program flow. Once you want to get beyond basic flow control and into things like loops or state machines, then one would typically make a custom block or entire program using structure text, or some variant of C, etc.