February 2007

Sun Mon Tue Wed Thu Fri Sat
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28      
Blog powered by TypePad

« Fusion Log Viewer | Main | April 1st »

Visual Programming

There's an interesting little discussion over on slashdot regarding visual programming. The original poster mentioned that while there were some visual languages - mentioning LabVIEW - none were considered mainstream. The discussion that followed I think really missed the point (but maybe that is just me).

Whether we like it or not, programming as it is done today is just way too hard to get to the next level. By this I'm not talking about mainstream applications (think MS Office, Orbitz website, etc), but massively parallel systems to simulate biological systems, the weather, etc. Even mundane applications need a lift to the next level in order to handle concepts such as self-healing (no, Clippy didn't help).

Consider the following:

1. Multi-threaded programming is hard, even for experts. Trying to keep in mind ABA, memory barriers, reentrancy, etc. while getting your main job done is not a simple task.

2. Performance is hard. As Rico Mariani says, you must measure, measure, measure. It is almost impossible to predict where your bottlenecks are. But consider this example of performance problems - cache-misses in the processor cache. If the next instruction or piece of data isn't already loaded into the processor, you are going to be sitting around for THOUSANDS of cycles waiting for it to come in. So - how to avoid that? Keep data and code together that reference each other. How to do that in a large application? There's not a simple answer. And besides - YOU SHOULDN'T HAVE TO CARE!

3. Errors are hard. Of course it is easy to generate errors - most programmers do it without thinking :) but what about handling errors? Pick some random piece of code in your application. Now - what would happen if your disk suddenly ran out of space? What about if the network disappeared? Got an out of memory error? How would you respond? Should this piece of code handle it or should you let it flow up to the caller? Now - realize that these types of errors could occur just about anywhere in your code. Have you thought through all possible conditions?

So what is the answer? If I knew that I would be writing this from the Caribbean rather than Austin. But I do know it will involve constantly reinventing the way we program.

Is LabVIEW the answer? In the context of this discussion, of course not. No language that exists today really addresses all the issues I mentioned. But I do believe that humans are visual creatures and that would seem to point to visual languages as being the right research direction.

Of course, I think that LabVIEW (G) is a great language. It eliminates a lot of complexity that text languages have, such as multi-threaded programming. All you have to do is look at the FPGA solution to see how LabVIEW can let a non-expert create powerful applications.

So, my question is what do you think? Where do you think LabVIEW provides the best solution? Where is it just too hard to express an idea?

Comments

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment