MIT creates picture-driven programming for the masses

Re:MIT creates picture-driven programming for the masses by physcab on Friday January 22, 2010 @10:11AM (#1069771)

There already is a visual scripting environment--its called LabView and its terrible. LabView is used mostly by scientists who want to control their experiments but don't want to learn how to program. It's very effective when dealing with hardware and you just want to get it working. But if it doesn't work, you're screwed because its very difficult to debug.

That's actually the problem I forsee with the visual scripting environment. There is no better single point of instruction than a compiler error or syntax error highlighting. If you try to circumvent that process to make it more "accessible" to the public, you're going to keep your visual programmers in the dark as to what is actually occurring.

[ Parent | on HN ]

Re:MIT creates picture-driven programming for the masses by sp332 on Friday January 22, 2010 @11:01AM (#1069881)

Did you even read the article? This isn't a visual scripting environment, it's an intuitive way to use Python to do image processing.

Edit: here's a paper with examples. http://groups.csail.mit.edu/uid/projects/sikuli/sikuli-uist2...

[ Parent | on HN ]

Re:MIT creates picture-driven programming for the masses by physcab on Friday January 22, 2010 @12:37PM (#1070138)

Ah. You're right. I misread it. However, I stand by my points on visual scripting in general. Even if there is a way to automate certain tasks via GUI elements, you are placing a great deal of trust on the system to operate as expected.

I do quite a bit of research in machine learning, and I can say that these systems are never perfect. Building an abstraction on top of an image processing technique is interesting, but I really wonder how a system like that can be debugged if something goes wrong.

[ Parent | on HN ]

Re:MIT creates picture-driven programming for the masses by mtomczak on Friday January 22, 2010 @11:13AM (#1069904)

For the record (though as other commenters have pointed out, this rant on LabView is off-topic): LabView is a very successful tool that is used by many programmers in various fields, not just instrumentation. LabView does have compiler errors and syntax error highlighting; they don't look the same as in a text-focused language, but since G is a programming language, it has its own syntax and errors can occur.

Programming languages are an abstraction. G is just another abstraction. I've used BASIC and C compilers with terribly cryptic, useless errors too; the errors had more to do with flaws in the compiler and IDE than the language itself. If errors in LabView are cryptic or obtuse, I would assume something similar.

[ Parent | on HN ]