For a powerful counter-example, look at the industry-standard visual effects system Houdini, made by SideFX. Houdini programs (actually referred to as 'scenes') are comprised of lazily-evaluated pure functions operating on a variety of data structures representing geometry, textures, shaders and so on. The system provides encapsulation, and an embedded expression language for cases where mathematical notation is more concise.
The curious thing about the world's most talented Houdini programmers is that they don't consider themselves programmers at all; their job titles normally include the term 'artist'. I've worked with people who wrote whole procedural simulations, image processing algorithms and shaders, who swore that they could not do programming.
As a seasoned coder by the time I first encountered Houdini, it took me months to get my head around it. It took me days to put together systems artists were able to build in hours. The lesson was: my knowledge of text-based, imperative programming was not directly transferrable to the node-based, procedural world.
Therefore, don't trust the judgement of a text-based programmer who declares that the tools of a visual programmer suck - it's not just a different dialect or different language, but a different medium entirely. And, effective visual programming systems are out there, but they don't have 'programming' written on them, because 'programmers' are not the target market.
Yesterday I discovered that a friend of mine is very used to many ideas in the functional programming world. She is an accountant, using Excel.
If you squint you eyes a little, Excel can be seen as functional programming: No mutable data, very short, pure functions that transform individual variables... data abstraction using intermediary tables... filter/map using pivot tables... reduce using ranges...
It is funny how much the advice of Excel wizards resembles common programming practices.
It's a question of problem domain. Would I rather design a shader using a visual graph system or text? Probably the graph system. Would I rather build a user interface using Interface Builder or pure code? Probably Interface Builder. But there are plenty of cases where a visual tool will be more cumbersome than text, perhaps because no visual tool has yet been built to deal with a given problem domain, perhaps because it's not really amenable to visual representation.
I think one of the advantages of a visual paradigm (at least for MevisLab) is that it forces modularity of all components. To avoid the wire-frame spaghetti, functionality can be encapsulated in containers with well-defined input/output ports, which makes that functionality trivially reusable in other contexts.
The productivity increase over competing frameworks is remarkable - I've seen a feature-complete demo delivered to a physician in 3 days. An experienced MS-level engineer took 3 months to implement comparable functionality in a Python/C++ framework.
Visual programming is excellent for certain niches, such as audio/video signal processing and the associated automation logic. Examples include Blender's and Maya's compositing nodes systems, virtual modular synthesizers, so-called "open architecture" sound processors, Pure Data, Audiomulch, and many others (including my own Palace Designer for my startup Nitrogen Logic).
When your problem consists mainly of taking some kind of input data, slicing it, processing it, altering it in separate branches, and recombining it, a dataflow-based visual programming system is an incredibly useful tool.
Yep, for this "pipeline/processing" type of workflow, I've seen several good examples of visual editors. It feels like it should be possible to implement most of the standard unix commandline tools in this kind of environment. With a system like that, you'd be able to let users create essentially shellscripts, but with a lower barrier of entry.
I'd really like to see that project. Time to stop procrastinating, I guess :)
Edit: This kind of system would also facilitate having multiple inputs/outputs and typed data - stuff that's fairly complex to get right in the actual commandline.
A pity that it's just another opinion about that topic. The main reason why "method X" doesn't feel comfortable the same way as coding is, that you code most of your time and trained your brain to think like that. If you teach your brain to work in other methods to generate programs, then you might actually feel more comfortable doing them instead of coding.
I think the 2 main reasons we still write text to talk to our computers lies in a) the training level most creators of new programming languages have in text I/O and b) that it's much easier, at least for computers and software nowadays, to parse text compared to parsing pictures. In fact I'm 100% sure that all visual programming software these days will underneath translate your graphical programs to text or byte strings. So you still interact textwise, it's just hidden underneath.
And because we just talk opinions here, let me add that: I believe that a way to programm with speaking or visual paradigms (maybe not the ones we have today) will probably improve the usability of programming, because untrained people can relate easier to things they can see and "touch", which is in my believe the reason, that the mouse is much more often used then the keyboard, even though it is often less efficient on current computers.
Yes, I don't think we are close yet to anything revolutionary, but, at least intuitive, the combination of visual programming, speak, AR, ILP (and other AI automated programming) can result in something more efficient and/or less error prone in the future. Nothing we have now in visual programming has that but we need to go somewhere from here and textual language are not bringing us enough advantages fast enough to curb the millions of software bugs produced every year.
Industrial control systems are often excellent candidates for visual programming, particularly because much of the logic is conditional and combinational in nature (that is, IF X AND Y OR (P OR Z AND NOT Y) AND NOT ALARM) THEN OPEN VALVE), so they are often programmed in a language called "ladder logic" [1] or "relay logic". Such an approach lets you very quickly see what condition is "breaking" the chain that enables the output to actuate.
After some Googling, here's a screen capture [2] of what it looks like in practice (from the vendor of RSLogix).
On the other hand, if your logic is highly non-combinational (requires latches or states), then such a language can indeed become incredibly annoying to both write and debug, in which case you can often elect to use a traditional programming paradigm (as shown in the top right of [2]).
[2] http://www.rockwellautomation.com/rockwellsoftware/design/rs... The picture for the main sequencer might be read as "If you're not out of Ingredient A, and you're not out of Ingredient B, and you're not out of Vanilla, ...". There needs to be a "lighted green" path from the left to the output for the device to turn on; if it doesn't, then non-green element(s) are the reasons why the output is blocked.
Unreal's Kismet (http://www.unrealengine.com/features/kismet/) has been quite successful. There are a lot of little bits of scripting that go into a game where this kind of language makes perfect sense.
Make a whole game with a visual language? No thanks! Give game designers the ability to just drag stuff around when they need to tweak behaviors? Yes, please!
A note about "game designers" might be in order: a game designer can be someone with little technical experience. "Game designer" is a broad spectrum of people from almost-artists (some kinds of level design for example) through full fledged programmers (sometimes titled "Technical designers").
The main problem, I think, is that it retains the vestigial features of being designed by electrical engineers who just refused to take any lessons from the 50+ years of experience we have had with programming languages.
---> Readability
You fall into the trap of thinking a flow diagram is an easier way to understand things. You are wrong. On any project that is not trivial, it's impossible to look at things and grok what they are doing or even what they are part of, or why that cable is going into that other system. You want to know what that cable does? Better follow it through the wormhole to see what variable it is! Realized you need a variable from somewhere else? Good luck bringing it over without a) creating a rat's nest or b) making it not obvious that it is coming from miles away. I could show you a simple for loop with an iteration variable, building up an array as it goes, and it'd take you a minute to get what it does. Readability sucks. Ignored lesson #1.
---> Refactoring
Fundamentally, the way you build code in labview tends to cause the problem where stuff gets added on all the time and it's all spaghetti. Granted, you can split things out into smaller modules initially (and interfacing them sucks). But there is no simple way to refactor things after you've written spaghetti. And because it's hard to manage external imports, you will write spaghetti. Ignored lesson #2.
---> Spatial Issues
The spatial paradigm is a culprit in many of these cases. Part of the problem is that it's hard to create spatial scope and visually import variables from elsewhere, all the while making the imports clear and easy to inspect all at once.
Don't even think of keeping things tidy, wires will be everywhere, and the auto-arranger doesn't work well.
You want to add code? Well, you should have left space for it in the first place! Now you have to move all your code aside to make space for the new stuff. Are you fucking kidding me?
So, you want to copy and paste. Good luck. All your wires disappear and since you haven't memorized what the code looks like, and you have to understand the code again before rewiring everything. Just like how you have to rename variables after copy-paste except dumber and takes much longer. This is why refactoring is hard.
---> Modern Tools
Version control you say? Forget about it! No diffs, no patches, no merging, no collaborative coding. Do NOT EVER EVER use anything but the master copy of the code (tm) or otherwise you'll end up with two versions and no one will know what is in which etc. Unit testing? Costs $1500 and is total junk regardless. Continuous integration? What is that even?
---> The UI
The UI has its own misgivings. Slow as balls even on a fast computer. Limited undo (are you shitting me?). Undo history used to disappear after you saved, maybe they fixed that. The window management is a mess. Sometimes when you try to quit, it says you made changes but you have no idea what changed. Good luck if you accidentally dragged some fucking wire somewhere so that now your robot flips out when reading gyro input. You can't know.
---> The Libraries
Extremely verbose and difficult to use. (especially math and strings).
Labview is just an all-round bad experience. Like I said, they've learned NOTHING from modern programming. And yet they tout this ignorance to you (and unsuspecting electrical engineers) with pride. This is just what I have off the top of my head. I don't even have my hate-list with me (yes, I compiled one to let off steam every time something was frustrating).
Labview was also the first thing that came to my mind.
In my experience, apart from complex number-crunching (for which it does have a stripped down textual-code vi), I found it easier to work with than java. I think that is more related to my hatred of unnecessary state (which an OOP only model supports). In Labview, the easiest way to store state is to pass the output of the vi (function) into its input at the next time it is called.
I still don't enjoy using Labview, but I haven't felt like there was something I couldn't do in it (in terms of resulting program).
Labview was the first thing that came to my mind as well. everyone thought I would love it (I am an electrical engineer) and assumed i would relate to a schematic representation to code. some may like it, but I find it far too verbose to draw code with wires and functions. I find that I far prefer writing a for loop with text than putting a window in and hiding everything behind drop downs, hidden windows and wires that go off the screen.
I was forced to use it for some time. I used to bang my head in frustration working out how to wire something up that I'd know how to do in two lines of code.
That, and I was using the built in fitter to fit a straight line, that would randomly screw up the fit on data almost identical to that which it worked on the previous iteration.
I've seen a few good examples of visual programming that work.
(1) Scratch. Scratch is just so much fun. When I have weeks where I'm totally burned out from coding, I can really enough playing around with scratch.
(2) There are quite a few proprietary systems for ETL and data analysis that support the creation of processing pipelines. Often you're snapping together relational operators much in the style of programming Apache Pig. I know data analysts who love working with these systems and when I've needed to make small changes to their analysis pipelines I've found it wasy.
At work, we had a short experimental phase with using a visual programming tool to create web applications[1]. For simple CRUD applications it was actually really nifty. But as soon as you get to more complex logic, it turned into a nightmare.
I think part of the reason is that a chart or a graph is great to give you an overview, to transport the gist of a message, to convey informal information. Programming on the other hand is all about hard, precise logic. Text is a much better medium to present this. And it's much easier to divide and conquer in text form, with meaningful function and variable names.
For example, how would you represent the following simple code snippet graphically?
if (!customer.hasOrderedSince(DateTime.Now.SubtractYear(1)) {
offerCoupon(10);
}
In the aforementioned platform, this would be one rhombus (representing the if statement). You'd have to click it to see what the condition actually is. If you have a complex flow, you'd have to click all nodes to see what's actually going on. In text form, it should ideally fit onto one page and is much easier to grasp and debug.
Someone brought up that GUIs and mouse input has been successful, and that's true. But there is big difference between using a computer, doing small atomic tasks with it, and programming one.
I am an "enterprise" programmer currently working on an invoice automation project. Since invoice approval processes vary across clients, we provide a (3rd party) workflow designer to personalize/customize the process.
And it sucks.
It sucks exactly for the reasons in the article. It sounds great and looks great for simple processes. But that isn't the reality of approval processes and integrating with existing systems. The complexity of these "visual" workflows grows exponentially with the complexity of the real process. Complex to the point where it can no longer be easily tweaked and maintained by the original designers/maintainers much less the client.
Yes, there are some systems that apparently work great: visual effects (which sounds much more functional (in the programming sense) than real world programming), and Scratch: to help kids make games. Scratch is inherently simple and I bet if you asked someone who has a history in programming what it is like to scale a program up in Scratch, you find the same thing. That it starts off great, but as complexity of requirements increase linearly, complexity of the "program" increases logarithmically. That they wish they could just port it to something like Python or at the very least, embed a language in it.
(Side note: I wonder if this says something about (natural) language as well. No natural language looks like a visual workflow. Not even hieroglyphics. You gain much more expressiveness and flexibility by the simplicity of the concepts. It doesn't get much simpler than a single linear string of words. And I think programming languages gain the same expressiveness and flexibility by having those characteristics.)
Just because it hasn't been done well doesn't mean it can't be. And as other comments have pointed out, visual programming works extremely well in domain-specific contexts; the challenge is to translate that to general-purpose programming.
The core of the problem is twofold: first, visualisation of higher-order functions in a way that doesn't suck; second, an easy way to move back and forth between details and the big picture. Those are two things at which text is already very, very effective.
Though the project is still very young, my horse in this race is a statically typed concatenative programming language. Visual programming is naturally point-free, and visualisation of higher-order functions is actually rather easy if you have static typing. Most importantly, the program can be edited textually or graphically.
I regularly see comments and articles here that indicate a desire for such a tool. They give me the resolve to keep working to fill that gap.
Scratch is awesome and as I mention in the article, one of the strengths of visual programming is that it requires much less training before you are able to actually "do" stuff. However, just because you can* do something doesn't mean it's the most optimal or the easiest way to do it.
Playmaker is not designed to replace all text-based programming in Unity but replace it in the use cases where it excels. For what most people want to do most of the time in this context, a visual language is easier to write in, debug in and maintain.
I agree with you that Playmaker isn't designed to replace all text-based programming and I believe that the tool works well for what it was designed for, namely to allow artists to do a lot of stuff without having to wait for the programmers and to allow people to do all of that, for lack of a better word, "brainless" programming that most programming actually is.
But when it comes to debugging and maintenance, I'm not so sure. Especially when it comes to debugging; I see no reason why that should be easier with a visual language.
Textual and alternative graphical representations for programs can be used interchangeably, text is just parsed
into trees of symbols after all.
This feels like a pretty obvious thing to do: are there programming environments out there that let you switch the view back and forth between textual and nontextual representations, designed to have good aesthetics/readability/editability in both forms?
On the other hand, there's a lot of concepts that can't be articulated clearly in a programming language but are pretty clear if you draw a picture. For, example, specifying the boundaries of critical sections in the system with many classes. This applies to pen & paper diagrams though. No idea whether there's a sane way to turn such diagrams into visual programming tool.
I agree that text is better in long turn. Such as
tex is better than word.
command line is better than GUI.
Yes, I mean "in long turn", otherwise it may be not true.
I've been kicking around the idea of building a visual programming language for about a week, so this article is well timed for me.
Let me throw out a counter hypothesis, please feel free to tell me where I'm wrong.
I can imagine that, when you have to build a complex program out of a bunch of boxes, and it gets to the point where a simple for-loop requires a bunch of boxes, that the whole program would be way, way too complicated.
This is the same problem if you wrote a java app, only it all fit in a single file, and every class of the java frameworks were also defined in that file-- it would be a massive file and damn hard to understand.
So, I think the same solution should work for a visual programming language: Modules (as they're called in erlang) or Classes (in Java etc.)
So, at the highest level, your program would be a small collection of boxes with lines between them. Maybe these are the major features of your app.
If you clicked on a box, you'd be drilling down into that level and you'd see how that feature was built. And it would be composed of a series of boxes- each of which was probably akin to a module or a class.
And if you clicked on one of those boxes, you'd be down into that module or class, and it is also composed of modules or classes.
You could drill down this way, until you ultimately got to the lowest level boxes which are akin to lines of code or components of a line of code in a text based language.
I think that would be visually easy to manage-- you'd only be dealing with a relatively small number of boxes and pipes at a time, and conceptually drilling down and pulling back is someting that I think non-programmers would be able to understand.
(Plus drilling all the way down would be something that programmers want to do, but non-programmers (the presumed target of a visual programming language) might not care about.)
Second hypothesis: If it makes no sense to drill all the way down, then at some point, when you drill down you're dropped into text based code. Thus the higher levels of abstraction could be done visually, but the components themselves could be done with text-- sort of a hybrid approach that might give the best of both worlds.
Thoughts? (and I'd love pointers if anyone knows of a system like this that is open source.)
Also, If I did try to build this thing, it would be my first ever language. I'd love to have a checklist of the basic components of a computer language that I could work form... otherwise I'm afraid I'll implement what I need and probably miss something, or do it wrong. But havent' found any good guides so far.
I've been working on a side project in the area for a while now. I think what you say with the boxes is pretty sensible and similar to how I see it - all I'll add is that its not just the 'bottom' that needs to be text-based. Some things are just best represented by text - even when you are looking at them in high level or abstracted (especially names of things, numbers, human-use things like addresses, etc.), whilst other things really need no textual representation at all, even if we are familiar with them that way (loops and other control strucutres, as well as graphics [say no to hex-based RGB!], etc.).
My advice is if you want to make it - just start. I farted around for a while thinking 'someone must have done something similar before and have some recommendations', but never really found much helpful (just alot of noisy people pointing to 1970s visual programming systems that failed for reasons that aren't really applicable to a modern project).
[+] [-] nezumi|13 years ago|reply
The curious thing about the world's most talented Houdini programmers is that they don't consider themselves programmers at all; their job titles normally include the term 'artist'. I've worked with people who wrote whole procedural simulations, image processing algorithms and shaders, who swore that they could not do programming.
As a seasoned coder by the time I first encountered Houdini, it took me months to get my head around it. It took me days to put together systems artists were able to build in hours. The lesson was: my knowledge of text-based, imperative programming was not directly transferrable to the node-based, procedural world.
Therefore, don't trust the judgement of a text-based programmer who declares that the tools of a visual programmer suck - it's not just a different dialect or different language, but a different medium entirely. And, effective visual programming systems are out there, but they don't have 'programming' written on them, because 'programmers' are not the target market.
[+] [-] Derbasti|13 years ago|reply
If you squint you eyes a little, Excel can be seen as functional programming: No mutable data, very short, pure functions that transform individual variables... data abstraction using intermediary tables... filter/map using pivot tables... reduce using ranges...
It is funny how much the advice of Excel wizards resembles common programming practices.
[+] [-] podperson|13 years ago|reply
[+] [-] bugsbunnyak|13 years ago|reply
I think one of the advantages of a visual paradigm (at least for MevisLab) is that it forces modularity of all components. To avoid the wire-frame spaghetti, functionality can be encapsulated in containers with well-defined input/output ports, which makes that functionality trivially reusable in other contexts.
The productivity increase over competing frameworks is remarkable - I've seen a feature-complete demo delivered to a physician in 3 days. An experienced MS-level engineer took 3 months to implement comparable functionality in a Python/C++ framework.
[+] [-] nitrogen|13 years ago|reply
When your problem consists mainly of taking some kind of input data, slicing it, processing it, altering it in separate branches, and recombining it, a dataflow-based visual programming system is an incredibly useful tool.
[+] [-] undantag|13 years ago|reply
I'd really like to see that project. Time to stop procrastinating, I guess :)
Edit: This kind of system would also facilitate having multiple inputs/outputs and typed data - stuff that's fairly complex to get right in the actual commandline.
[+] [-] erikb|13 years ago|reply
I think the 2 main reasons we still write text to talk to our computers lies in a) the training level most creators of new programming languages have in text I/O and b) that it's much easier, at least for computers and software nowadays, to parse text compared to parsing pictures. In fact I'm 100% sure that all visual programming software these days will underneath translate your graphical programs to text or byte strings. So you still interact textwise, it's just hidden underneath.
And because we just talk opinions here, let me add that: I believe that a way to programm with speaking or visual paradigms (maybe not the ones we have today) will probably improve the usability of programming, because untrained people can relate easier to things they can see and "touch", which is in my believe the reason, that the mouse is much more often used then the keyboard, even though it is often less efficient on current computers.
[+] [-] tluyben2|13 years ago|reply
[+] [-] pacala|13 years ago|reply
http://en.wikiquote.org/wiki/Incorrect_predictions
http://www.lhup.edu/~dsimanek/neverwrk.htm
[+] [-] davorb|13 years ago|reply
He said that X is most likely not possible because of Y (where Y is a function of X).
[+] [-] barik|13 years ago|reply
After some Googling, here's a screen capture [2] of what it looks like in practice (from the vendor of RSLogix).
On the other hand, if your logic is highly non-combinational (requires latches or states), then such a language can indeed become incredibly annoying to both write and debug, in which case you can often elect to use a traditional programming paradigm (as shown in the top right of [2]).
[1] http://en.wikipedia.org/wiki/Ladder_logic
[2] http://www.rockwellautomation.com/rockwellsoftware/design/rs... The picture for the main sequencer might be read as "If you're not out of Ingredient A, and you're not out of Ingredient B, and you're not out of Vanilla, ...". There needs to be a "lighted green" path from the left to the output for the device to turn on; if it doesn't, then non-green element(s) are the reasons why the output is blocked.
[+] [-] Ogre|13 years ago|reply
Make a whole game with a visual language? No thanks! Give game designers the ability to just drag stuff around when they need to tweak behaviors? Yes, please!
A note about "game designers" might be in order: a game designer can be someone with little technical experience. "Game designer" is a broad spectrum of people from almost-artists (some kinds of level design for example) through full fledged programmers (sometimes titled "Technical designers").
[+] [-] grueful|13 years ago|reply
For anything reasonably complex, it is by far the slowest language I've worked in.
It's still 100% worth it for its use case, and 90% of what you'd want it for is not all that complex.
[+] [-] makmanalp|13 years ago|reply
The main problem, I think, is that it retains the vestigial features of being designed by electrical engineers who just refused to take any lessons from the 50+ years of experience we have had with programming languages.
---> Readability
You fall into the trap of thinking a flow diagram is an easier way to understand things. You are wrong. On any project that is not trivial, it's impossible to look at things and grok what they are doing or even what they are part of, or why that cable is going into that other system. You want to know what that cable does? Better follow it through the wormhole to see what variable it is! Realized you need a variable from somewhere else? Good luck bringing it over without a) creating a rat's nest or b) making it not obvious that it is coming from miles away. I could show you a simple for loop with an iteration variable, building up an array as it goes, and it'd take you a minute to get what it does. Readability sucks. Ignored lesson #1.
---> Refactoring
Fundamentally, the way you build code in labview tends to cause the problem where stuff gets added on all the time and it's all spaghetti. Granted, you can split things out into smaller modules initially (and interfacing them sucks). But there is no simple way to refactor things after you've written spaghetti. And because it's hard to manage external imports, you will write spaghetti. Ignored lesson #2.
---> Spatial Issues
The spatial paradigm is a culprit in many of these cases. Part of the problem is that it's hard to create spatial scope and visually import variables from elsewhere, all the while making the imports clear and easy to inspect all at once.
Don't even think of keeping things tidy, wires will be everywhere, and the auto-arranger doesn't work well.
You want to add code? Well, you should have left space for it in the first place! Now you have to move all your code aside to make space for the new stuff. Are you fucking kidding me?
So, you want to copy and paste. Good luck. All your wires disappear and since you haven't memorized what the code looks like, and you have to understand the code again before rewiring everything. Just like how you have to rename variables after copy-paste except dumber and takes much longer. This is why refactoring is hard.
---> Modern Tools
Version control you say? Forget about it! No diffs, no patches, no merging, no collaborative coding. Do NOT EVER EVER use anything but the master copy of the code (tm) or otherwise you'll end up with two versions and no one will know what is in which etc. Unit testing? Costs $1500 and is total junk regardless. Continuous integration? What is that even?
---> The UI
The UI has its own misgivings. Slow as balls even on a fast computer. Limited undo (are you shitting me?). Undo history used to disappear after you saved, maybe they fixed that. The window management is a mess. Sometimes when you try to quit, it says you made changes but you have no idea what changed. Good luck if you accidentally dragged some fucking wire somewhere so that now your robot flips out when reading gyro input. You can't know.
---> The Libraries
Extremely verbose and difficult to use. (especially math and strings).
Labview is just an all-round bad experience. Like I said, they've learned NOTHING from modern programming. And yet they tout this ignorance to you (and unsuspecting electrical engineers) with pride. This is just what I have off the top of my head. I don't even have my hate-list with me (yes, I compiled one to let off steam every time something was frustrating).
[+] [-] gizmo686|13 years ago|reply
[+] [-] K2h|13 years ago|reply
[+] [-] jliechti1|13 years ago|reply
[+] [-] misnome|13 years ago|reply
That, and I was using the built in fitter to fit a straight line, that would randomly screw up the fit on data almost identical to that which it worked on the previous iteration.
[+] [-] PaulHoule|13 years ago|reply
(1) Scratch. Scratch is just so much fun. When I have weeks where I'm totally burned out from coding, I can really enough playing around with scratch.
(2) There are quite a few proprietary systems for ETL and data analysis that support the creation of processing pipelines. Often you're snapping together relational operators much in the style of programming Apache Pig. I know data analysts who love working with these systems and when I've needed to make small changes to their analysis pipelines I've found it wasy.
[+] [-] aufreak3|13 years ago|reply
[+] [-] smartician|13 years ago|reply
I think part of the reason is that a chart or a graph is great to give you an overview, to transport the gist of a message, to convey informal information. Programming on the other hand is all about hard, precise logic. Text is a much better medium to present this. And it's much easier to divide and conquer in text form, with meaningful function and variable names.
For example, how would you represent the following simple code snippet graphically?
if (!customer.hasOrderedSince(DateTime.Now.SubtractYear(1)) { offerCoupon(10); }
In the aforementioned platform, this would be one rhombus (representing the if statement). You'd have to click it to see what the condition actually is. If you have a complex flow, you'd have to click all nodes to see what's actually going on. In text form, it should ideally fit onto one page and is much easier to grasp and debug.
Someone brought up that GUIs and mouse input has been successful, and that's true. But there is big difference between using a computer, doing small atomic tasks with it, and programming one.
[1] http://www.outsystems.com
[+] [-] thebigshane|13 years ago|reply
And it sucks.
It sucks exactly for the reasons in the article. It sounds great and looks great for simple processes. But that isn't the reality of approval processes and integrating with existing systems. The complexity of these "visual" workflows grows exponentially with the complexity of the real process. Complex to the point where it can no longer be easily tweaked and maintained by the original designers/maintainers much less the client.
Yes, there are some systems that apparently work great: visual effects (which sounds much more functional (in the programming sense) than real world programming), and Scratch: to help kids make games. Scratch is inherently simple and I bet if you asked someone who has a history in programming what it is like to scale a program up in Scratch, you find the same thing. That it starts off great, but as complexity of requirements increase linearly, complexity of the "program" increases logarithmically. That they wish they could just port it to something like Python or at the very least, embed a language in it.
(Side note: I wonder if this says something about (natural) language as well. No natural language looks like a visual workflow. Not even hieroglyphics. You gain much more expressiveness and flexibility by the simplicity of the concepts. It doesn't get much simpler than a single linear string of words. And I think programming languages gain the same expressiveness and flexibility by having those characteristics.)
[+] [-] evincarofautumn|13 years ago|reply
The core of the problem is twofold: first, visualisation of higher-order functions in a way that doesn't suck; second, an easy way to move back and forth between details and the big picture. Those are two things at which text is already very, very effective.
Though the project is still very young, my horse in this race is a statically typed concatenative programming language. Visual programming is naturally point-free, and visualisation of higher-order functions is actually rather easy if you have static typing. Most importantly, the program can be edited textually or graphically.
I regularly see comments and articles here that indicate a desire for such a tool. They give me the resolve to keep working to fill that gap.
[+] [-] politician|13 years ago|reply
[+] [-] jjtheblunt|13 years ago|reply
[+] [-] Turing_Machine|13 years ago|reply
http://scratch.mit.edu/
More than 2.7 million pieces of software, all created with a visual programming tool, and mostly by little kids.
Yes, most of them are simple (though there are some impressively complex projects on there). So what?
[+] [-] davorb|13 years ago|reply
Scratch is awesome and as I mention in the article, one of the strengths of visual programming is that it requires much less training before you are able to actually "do" stuff. However, just because you can* do something doesn't mean it's the most optimal or the easiest way to do it.
[+] [-] batista|13 years ago|reply
So you just repeated the complain of the author (that it only works for simple stuff), and yet you act like you challenged it.
[+] [-] teamonkey|13 years ago|reply
[+] [-] davorb|13 years ago|reply
But when it comes to debugging and maintenance, I'm not so sure. Especially when it comes to debugging; I see no reason why that should be easier with a visual language.
[+] [-] nuromancer|13 years ago|reply
[+] [-] zurn|13 years ago|reply
This feels like a pretty obvious thing to do: are there programming environments out there that let you switch the view back and forth between textual and nontextual representations, designed to have good aesthetics/readability/editability in both forms?
[+] [-] rumcajz|13 years ago|reply
[+] [-] guilloche|13 years ago|reply
[+] [-] pinchyfingers|13 years ago|reply
[+] [-] nirvana|13 years ago|reply
Let me throw out a counter hypothesis, please feel free to tell me where I'm wrong.
I can imagine that, when you have to build a complex program out of a bunch of boxes, and it gets to the point where a simple for-loop requires a bunch of boxes, that the whole program would be way, way too complicated.
This is the same problem if you wrote a java app, only it all fit in a single file, and every class of the java frameworks were also defined in that file-- it would be a massive file and damn hard to understand.
So, I think the same solution should work for a visual programming language: Modules (as they're called in erlang) or Classes (in Java etc.)
So, at the highest level, your program would be a small collection of boxes with lines between them. Maybe these are the major features of your app.
If you clicked on a box, you'd be drilling down into that level and you'd see how that feature was built. And it would be composed of a series of boxes- each of which was probably akin to a module or a class.
And if you clicked on one of those boxes, you'd be down into that module or class, and it is also composed of modules or classes.
You could drill down this way, until you ultimately got to the lowest level boxes which are akin to lines of code or components of a line of code in a text based language.
I think that would be visually easy to manage-- you'd only be dealing with a relatively small number of boxes and pipes at a time, and conceptually drilling down and pulling back is someting that I think non-programmers would be able to understand.
(Plus drilling all the way down would be something that programmers want to do, but non-programmers (the presumed target of a visual programming language) might not care about.)
Second hypothesis: If it makes no sense to drill all the way down, then at some point, when you drill down you're dropped into text based code. Thus the higher levels of abstraction could be done visually, but the components themselves could be done with text-- sort of a hybrid approach that might give the best of both worlds.
Thoughts? (and I'd love pointers if anyone knows of a system like this that is open source.)
Also, If I did try to build this thing, it would be my first ever language. I'd love to have a checklist of the basic components of a computer language that I could work form... otherwise I'm afraid I'll implement what I need and probably miss something, or do it wrong. But havent' found any good guides so far.
[+] [-] twelvechairs|13 years ago|reply
My advice is if you want to make it - just start. I farted around for a while thinking 'someone must have done something similar before and have some recommendations', but never really found much helpful (just alot of noisy people pointing to 1970s visual programming systems that failed for reasons that aren't really applicable to a modern project).
[+] [-] reirob|13 years ago|reply
It is an algorithmic visual programming language developed for the Buran space project (Russian space project)