True Visual Programming

eberta writes "We are still stuck with text programming for the most part. I can think of only a few truly visual programming environments like LabView and none are really mainstream for application development. Being recently unemployed and having ample spare time, I have started a pet project to work on my own version, GIPSpin (Graphical Interface Programming System). With multithreading becoming an increasing issue in software development, I'm wondering why hasn't there been more focus on visual programming. I see so much possibility of making coding easier and handling threading issues semi-automatically by allowing the user to graphically guide the auto-threading AI. Right now it seems the industry is focused on figuring out how to get just small chunks of code auto-threaded either through hardware or compiler technology, with longer term solutions like OpenMP still text based environments."

Comments

It's inefficient

[0x461FAB0BD7D2]

There are ways of visual programming right now, such as WYSIWYG HTML editors (Dreamweaver, Nvu, Frontpage) and Visual Basic.

However, I can't see this happening for Perl, PHP, C, Java, etc. Everyone has their own style of coding with their own ideas, many of which are abstract and cannot be effectively visualized. To make an IDE which effectively deals with all the quirks programming has would be quite a feat, but would be so bulky that text-based programming would be the most efficient.

There might be a place for visual programming in rapid application development or some simple programs/scripts like HTML pages and the like. Beyond that, I'd doubt it.

Because...

[Anonymous Coward]

I'm wondering why hasn't there been more focus on visual programming

Because in the 1980's people realized that visual programming was a dead-end idea. Trust me, one of the products I work with lets you program "workflows" using a visio-like toolkit. It's the most unproductive thing I've ever had to use.

Seriously, researchers have beaten this one to death already. Even as far back as The Mythical Man Month it was already recognized that graphical/visual programming would not give us any improvements on efficiency.

I guess the old addage of "reinventing lisp, badly" still holds true. "Computer Science" sure seems to ignore a lot of its past research.

Problems with 'Visual Programming'

[drspliff]

Visual Programming has always been a sort of industry goal, every product you see out there is trying to make it easier on the developer, be it UML or another modelling software, iMatix's Libero or another code generation framework.

One of the reasons I think Visual Programming won't catch on for a long time, or will take serious innovational leap is because with existing solutions the developer looses too much control over the path of execution, optimizations, memory management and all the other lower-level stuff we developers have to tinker with.

There have been numerous frameworks which have tried to bridge the gap, one that sticks in my mind is SilverStream's/Novell's exteNd Composer/Director. They follow the basic roles of a point-and-click programming environment, flow layout, assisted statement creation etc.

But there is only so much you can do before you end up just writing solid code again. I don't want to sound like an elite-ist, but personally I think all these high-level visual programming environments will lead to 'Joe Blogs' developing your [name critical financial or business application here].

And not to mention the thousands of zealots out there who you'll have to bring kicking and screaming into the new 'visual' era.

Rant or rave, new developments in this area can be a great aid to experienced developers, but in the wrong hands they can cause more harm than good (Visual Basic anybody?)

Moderate: -5 Zealot bait

INPUT DEVICES

[ericandrade]

Computer interfaces suck.

Programming languages are visual and depend on the computer screen or whatever the computer outputs. Changing the way it is disposed on the screen is just trying to make it cute.

The major restraint right now on programming is INPUT.

The mouse dates back 50 years,
the keyboard's even older than that, and it's designed to slow down users! (both cause +RSI and other crap, and are very slow and innacurate)

For example, where are dual cursors?
There needs to be more OS implementations and design to have superinterfaces. Make the long, tedious, well planned out programming that will accelerate future programming. And think out of the box: Future programming will not be done with a keyboard and a mouse.

http://sloan.stanford.edu/MouseSite/1968Demo.htm l

Why can Stephen Hawkings write speeches, scientific texts and do tons of complex things with a single thumb clic?

Where are the standards for new interface developpement?
The OS developpements to support the hardware?

Screens are getting bigger, why do I have to rely on a menu in the top left of the screen if i'm working in the bottom right of a 2nd screen?

Design and manufacture of new technology is slowed down by the limited ways we have to transfer, collect, manage and create the complex data we have to deal with. F*ck Moore's law! With the keyboard and mouse, the bottleneck is between us and it. The idle time prooves it.

Computer's are an instrument. Instruments are allways hard to master. They evolve. They're not supposed to only get cuter.

Imagine a computer using 50% of it's processing power to know what you want /to say/it to do... /rant

Re:INPUT DEVICES

[pavon]

The mouse dates back 50 years
The steering wheel dates back 1000s of years, yet we still use it because it is an effective interface.

the keyboard's even older than that, and it's designed to slow down users!
No it wasn't - that's a myth. Besides the best text entry devices which are designed to be as efficient as possible, such as Dvorak (use it myself) and chording, are only incrementally better than QWERTY - not the revolutionary jump you are looking for.

For example, where are dual cursors?
Dead on the research table where they belong. They never provided any significant improvement in performance, and even slowed users down due to having to stop and think about what they were doing - even after spending a significant time learning the system.

Why can Stephen Hawkings write speeches, scientific texts and do tons of complex things with a single thumb clic?
You can too - on a cell phone. They are smart ways to make the most of limited input capabilities; however, they are incredibly slow compared to the keyboard and mouse, and no one would choose to use one unless it was the only option available.

With the keyboard and mouse, the bottleneck is between us and it. The idle time prooves it.
Yet, much of the idle time is due to user thinking, not slow user input - you don't notice yourself being slow, because you are preoccupied, but you do notice when the computer slows you down even slightly. Honestly, ever since I learned to to touch-type, I have been able to type as fast as I can think, and there isn't really any reason for me to want to input text faster. Once I get a wacom tablet, I'll likely be able to say the same about the 2d/3d graphics work (err play) that I do.

Most of the instances where I notice the computer slowing me down - making me do more work then I ought to - is due to poor design and integration of the software, not the keyboard and mouse. For example, I had to start up and entirely separate program just to spell-check this post.

Where are the standards for new interface developpement?
I don't know - why haven't you come up with one?

But we *do* think visually

[TuringTest]

Humans think of the world using language, but we also think of the world using visual, spatial, temporal, sensorial... reasoning.

Do ask a real psychologist, she will say that there are different kinds of think. Textual is best suited for abstract, logical reasoning. But associative thinking is often better done visually. In the Programmer's Guide to the Mind you have an interesting classification of all these.

A programming environment should take care of all these kinds of thought, not just support the logic abstractions as they do now. A promising field of research is Programming By Example. This programming style tries to build the final program by using concrete reasoning over samples of data, instead of forcing you to think of the general, abstract procedure.

Re:I like it!

[Jerf]

Keep going, and don't let the nattering neybobs of negativism here at /. get you down.

You know, I understand what you're getting at here, but you need to understand where the "nattering naybobs" are coming from. We're not saying "We've never seen this before and we're sure it won't work, don't try, fingers stuck in my ear, blah blah blah!" We're saying "We've seen several implementations of this idea, they all suck in the same fundamental way, and we've never seen anybody with a functional solution to the suckage problem."

You want to try your hand at it, be my guest. If you have taken the time to understand history, what has failed in the past, the problems encountered by others, and you still want to try, well, go for it. It's your time.

But if you think, and I get this vibe from the original poster, "Hey, there's nobody who's tried this great idea, I think I'll start a project on it!"... you're fucked, plain and simple, and throwing a bit of water on that ethusiasm is a favor, right up there with "Your first programming project should not be a real-time strategy RPG." Encouragement is great and all, but you should not encourage someone who's just been mountaineering for a week to take on Everest. Discouragement can be a positive thing.

At the very least, educate yourself before starting. There's a lot of failure in this field.

Two of my "general principles" come into play here:

1. "When a lot of other very smart people have tried to solve the problem, but you think you have the answer, you almost certainly don't, and you certainly don't if it seems 'simple' or 'obvious' to you." This fits that in spades; a lot of very smart people have tried this and failed.
2. "There exists a lot of solutions that only work in demos, or worse yet, when you just 'imagine' it in your head, but crash and burn when faced with the real world. Anything works in a demo, or in your head, even the absolutely impossible. If you've never seen it outside of a demo, there's a reason." And that fits this whole "graphical programming" to a T; it's trivial to create an "ooo, ahh" demo with the execution flying around the screen, two or three 'if's and a "for". But there aren't very many functions, let alone programs, that work with two 'if's and a for loop. (Another thing that fits here is many interesting AI solutions in academia that are claimed to be generally powerful, with varying justification, but in five years of working with the solution they've only managed one very particular demo.)

Go for the gusto, but if you just close your eyes and hum when people try to explain why it's a hard problem, you're dooming yourself from the getgo and wasting your time.