12

All programming languages I know of are written - i.e. typed out as lengths of text one way or another. But I wonder if there's any programming language where you can just drag-n-drop the whole program; to get a loop, you select this box over here and drag it to that section of the "code" over there, and so on. And if there isn't one like this, would it fly if one was invented?

Personally I don't believe it would be such a good idea, but I'd like to hear what you think.

6
  • Never say never (you said: "I don't believe it would be such a good idea") - there can be a strange situation, where the weirdest idea can performs well.
    – ern0
    Dec 5, 2010 at 22:26
  • 6
    "Would it fly?" Honestly, if I thought the flight control systems on the plane I was going on were programmed by someone doing Drag-n-drop programming, I might not get on that plane. ;D
    – glenatron
    Dec 5, 2010 at 22:48
  • Really like this question, although I wish some of the answers were longer and deeper.
    – Nicole
    Dec 5, 2010 at 23:15
  • 1
    Ironman will use it, and fly! But he doesn't exist in real world!
    – Manoj R
    Dec 6, 2010 at 6:27
  • @glenatron - So travel by train... Flight control systems are for one part finite state automatons that are build graphically and for another part control engineering systems that are built from basic blocks and assembled in GUI interfaces. The remaining is UML.
    – mouviciel
    Nov 9, 2011 at 8:27

12 Answers 12

23

Lots of outfits have done drag-and-drop programming systems.

National Instruments "Labview" is probably the best-known, and the best.

The fundamental problem they all encounter is that there is no known way to convert a Flying Code Monkey into an expert programmer and engineer. As ONE example, there is no difference to a Flying Code Monkey between an O(N^2) or O(N^3) process and an O(N log N) process, which means that they must be supplied with canned routines for the O(N log N) algorithms, that can be custom-fit into the quickie graphic kludges they will build.

The second problem they all encounter is that, when you supply the special-purpose blocks required by the first problem, overhead imposed by moving the data between the blocks starts to get expensive. I worked with one very nice such system called Rippen. When I profiled, to see where we were hurting on a HIGH!-required-performance sensor processing application, I was rather disturbed to see that some 20% of my CPU time was going to data-moving. (Since I was doing LADAR image processing, doing a fair chunk of floating-point processing on every pixel of an input image, 20% of CPU was a LOT of data-moving overhead.)

You could probably get around part 2 by going to a compiler-based system: you feed it your picture, and it compiles to a heavily-optimized executable program, but I'm not certain that would really fix the issues, and it might hurt the interactive nature of the tool.

1
  • You can in theory have a Debug and a Release (optimized) mode.
    – Job
    Dec 5, 2010 at 18:37
15

The simple answer is no.

When it comes to programming, textual input far exceeds in terms of specified information than its visual counter part.

1
  • As you go even higher and higher level, it's getting more and more chance to articulate the problem graphically. Dataflow programming is a such approach (see my answer for this question): components are given, they are black boxes, the task of the "programmer" (better term: app designer) is to just organize them into a net.
    – ern0
    Dec 5, 2010 at 22:23
12

LabVIEW is pretty graphical.

From the LabVIEW website:

LabVIEW

8
  • Huh, that looks neat. How much can you do with it? Is it specialized for just one kind of "programming", like physics, or can you use it for anything?
    – gablin
    Dec 5, 2010 at 18:32
  • 2
    Yes, there are LabVIEW professionals: lavag.org. Discussion forums: forums.ni.com. Erlang comparison: bit.ly/2yC0Tn. Compiler description: bit.ly/c6quPK. General programming example: bit.ly/cSnt5D. Use in the LHC: bit.ly/9Yp4oo. It's a niche language used all over the damn place: ni.com/solutions. It's expensive as hell, leaks abstractions left and right, installs a ton of unexplained services, and suffers from tons of amatuers. It's cross-platform, simple to parallelize, and as easy/hard as any other language out there.
    – Joe Z
    Dec 6, 2010 at 1:00
  • 2
    It runs LEGO robots. ni.com/academic/mindstorms
    – rwong
    Dec 6, 2010 at 7:31
  • 1
    @Zeke: If a VI (LabVIEW equivalent of a program or function) requires you to scroll in more than one direction, then it hasn't been written correctly.
    – oosterwal
    Feb 26, 2011 at 21:21
  • 1
    @oosterwal: You're right, it's common. Additionally, the language is quite intentionally marketed to scientists and engineers as easy to learn. Kept to small programs, this is true. As programs require more sophistication, code tends to creep rather spectacularly out of control. (Edit: Not due to the language as such, but to the well intentioned users. Full disclosure: I'm a scientist some days:)
    – Joe Z
    Feb 27, 2011 at 3:04
6

Yahoo! Pipes is probably a perfect example of a graphical language of the type you're describing; you drag-and-drop primitives (everything from data sources that you act on, to loops and conditionals) to produce a flow of information through the system.

It's highly domain-specific, but that's mostly the point; Pipes is data-centric, making visualization (rather than expression) paramount. Similarly, tutorial environments like Scratch or Sprog! emphasize the visualization of what you're working on as a learning aid; data-entry efficiency is a much lower priority in that domain.

1
  • If more amateur web app developers knew about Pipes, the world would be a better place. +1
    – Sparr
    Dec 6, 2010 at 8:29
3

Every now and then someone comes up with a drag and drop programming language or design tool that is going to "put an end to programming as we know it" and make everyone who uses it into a programmer.

The reason that none of them have actually done the job as yet and put us all out of work is that actually, no matter how much drag and drop functionality you create and no matter how user friendly you make it, the simple fact is that programming is hard.

The real disciplines of programming are as much about knowing how to solve problems, understanding how to model processes and organise data to be usable. Even understanding what is possible with a computer at all.

There is evidence (if controversial) to suggest that some people can't be taught to think this way which leads me to a couple of interesting and relevant thoughts. To start with, if you can't think this way then there are lots of programmers around, so you can always hire someone to implement an idea if you have one and you think it's worth paying for. If you can work with programming logic well enough then you might as well learn a real language rather than mess around with a relatively simple drag and drop environment.

I'm thinking of general programming here. The same thing doesn't necessarily apply in a more limited DSL type scenario where drag-and-drop might be a really useful process users who are specialists within that domain rather than IT specialists.

3
  • Programming is a complex, hard and long process, requires tons of engineer's work. That's why the industry is trying to make app developing available for non-programmers: reduce developement cost, optimize human resource usage. Also, as a programmer, I can say, that there're lot of tasks, which should be done by non-programmers, but they have no tools for that tasks, so it must be done by programmers, who 1. hate to do that kind of tasks 2. are expensive 3. are not the best people for doing that. So, I warmly welcome any idea which points that way, e.g. visual programming.
    – ern0
    Dec 5, 2010 at 22:16
  • 1
    I know why the industry is trying to do it. But my point is that if you can program, you are a programmer and people who can't program won't be able to do it any better because there are visual tools to do the same jobs that otherwise they would have had to write code for. The tools aren't the problem, the thing you have to do with them is the problem.
    – glenatron
    Dec 5, 2010 at 22:44
  • I mean programming more liberal. It's also programming, when you tell your waching machine to run wash for 5 min, dry for 10 min. Someone should give different name for different programming "layers". Is dataflow programming programming? Is spreadsheet creation (without macros)? Yes, they are, but also different kind that so-called programmers do. Anyway, there are sharp differences what programmers do, I mean, drag-and-drop modules in SuperIDE12++ with plugins VS assembly coding. Also, it's just big difference, if your platform has GC. Or: script VS compiler. "Programming" is too common term.
    – ern0
    Dec 7, 2010 at 13:49
3

The best drag and drop programming system i've seen is for the Lego Mindstorms NXT robots.

This allows you to do some quite amazing things, controlling some quite intricate functionality.

However at some point it does break down, and you need to revert to another system.
See this article: http://www.wired.com/geekdad/2007/11/the-best-progra/

It's possible though, that if this was improved, and different scenarios where catered for, the need for this would become less and less.

3
  • Do love Mindstorms (which evolved out of Lego Dacta, which had more traditional coding [a language similar to Logo/Lisp]), studied it at school 15 years ago. Excellent present for a programmer to get their kids, should they have some.
    – Orbling
    Dec 5, 2010 at 22:35
  • 1
    NXT is, actually, LabVIEW. Well, LV that's been trimmed a bit: ni.com/academic/mindstorms
    – Joe Z
    Dec 6, 2010 at 0:44
  • I never knew that, thanks! I'm very impressed with it.
    – Bravax
    Dec 6, 2010 at 9:44
2

Dataflow programming (a.k.a. flow-based programming) can be kind of. Altough, dataflow programming is not Turing-complete.

Dataflow programming is the method of creating applications, when you put component instances on the scene and connect their ports, so they form a message processing network. The components can be choosen from a library, they have consumer (input) and producer (output) ports, which are ready to connect with other components' ports.

Here's a nice example, where not even a mouse used to build a synth app, but bare hands and little cubes: http://www.youtube.com/watch?v=0h-RhyopUmc

Wikipedia articles are a good start point: http://en.wikipedia.org/wiki/Flow-based_programming http://en.wikipedia.org/wiki/Dataflow_programming

Sound generation is a typical area of dataflow programming. There are some open source synth systems: http://www.synthedit.com/ http://alsamodular.sourceforge.net/

If you have Mac, you may have a factory pre-installed Quartz Composer: http://developer.apple.com/graphicsimaging/quartz/quartzcomposer.html

I've also made a DF system with a friend of mine, but we have no visual editor yet, only script visualizer.

4
  • 3
    Why do you consider data-flow programming not to be Turing complete?
    – oosterwal
    Feb 26, 2011 at 21:30
  • PLaying around with box connections is not Turing complete. Writing components is Turing-complete (usually there're no restrictions, just the DF framework, which must be used for communicating with other components).
    – ern0
    Feb 26, 2011 at 23:52
  • 1
    The underlying hardware of any CPU is basically dataflow. How this non Turing complete construction can lead to a Turing complete system?
    – mouviciel
    Nov 9, 2011 at 8:34
  • @mouviciel My first reaction was "no, CPU is not dataflow", but it is. Anyway, this is a bad example for dataflow systems; bad design. There is only one source component (the external/internal clock), which triggers the CPU component to process the next instruction. Even if we count other parts, e.g. audio, video card, DMA system etc. as components, it's yet bad design: the components are too big and too specialized. But the idea is good, maybe it's a way to increase performance/versatility, to build computers with smaller units and connect parts like dataflow components? Smells like patent :)
    – ern0
    Nov 9, 2011 at 13:52
2

MIT's Scratch programming system is almost entirely drag-and-drop.

Google's App Inventor seems to be similar (and credits Scratch).

I wouldn't want to code anything big in either myself, but for teaching "programmer thinking", Scratch is superb. It's Real Programming, but with instant visual gratification and the snap-together blocks avoid much of the "syntax error" frustration which puts off newcomers (a view I see echoed in this article). Trying to enthuse young kids with a python commandline doesn't cut it these days.

1

This already exists, albeit possibly not in the form that you are thinking about. Two examples are Simulink and Alice.

Simulink is a graphical means of assembling dynamic system simulations. While most of the constructs are more complex than what you would usually think of as programming, things like for and if statements still can be graphically constructed. Simulink is kinda a big deal in Aerospace applications as the government and many of the big companies do their initial designs in Simulink and then apply some type of theorem prover to the Simulink "code".

Alice, is a drag and drop, programming training tool for kids. It allows kids to have fun building stories by dragging and dropping actions and objects on a sort of programming story board.

1

Prograph was a cool language that was all drag and drop. Also, Wikipedia has an article with a good sized list of visual languages.

1
  • would you mind expanding a bit on what each of these resources have and why do you recommend these as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange
    – gnat
    Aug 4, 2013 at 22:11
0

There are quite a few visual programming languages. A phone system I managed for a large call center was programmed using drag and drop modules. My uncle developed a Just-In-Time system for designing manufacturing lines that was completely drag and drop and that was 20 years ago.

I've even played a robot combat game on the PS1 that used a drag and drop programming language.

2
  • Carnage Heart, was an awesome game.
    – Ape-inago
    Dec 6, 2010 at 8:17
  • That's the one, I couldn't remember the name. I loved that game. Very clever design.
    – Pickle Pumper
    Dec 6, 2010 at 18:22
-1

Textual programming has had a nice 50 year run, but software engineering must move into the graphical realm to deal with the next level of complexity. For example, the emergence of manycore processors and the challenges of parallel programming are pushing the threading model to its limit. Frankly, I think that the software community is just arrogant thinking that there is something fundamentally different and special about programming that it would not be amenable to visualization like every other domain. Like telephone operators and many other professions, the right automation technology will enable domain experts to soon collaborate in rich simulation spaces of knowledge-based systems. The software industry is long overdue for a paradigm shift.

1
  • 2
    I would strongly disagree, here: the complexity of many real-life programs is way too high for being fully represented graphically. All the people whom I know who (1) known how to program and (2) have used LabView for a larger project have discovered that the graphical representation is inherently too heavy for working productively on larger projects. Sure, LabView is very convenient when your program fits on a single screen; but when your program starts to grow beyond the limits of a single screen, LabView is hard to use efficiently (no simple text search, rearranging blocks is painful,…). Nov 9, 2011 at 9:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.