Parallel Programming For the Arduino 140
blackbearnh writes "As more non-traditional programmers start playing around with embedded platforms like the Arduino, the limitations and complications of interrupt-driven event handling can become an annoying barrier to entry. Now a group of academics have ported the parallel-processing language Occam to the Arduino. In an interview on O'Reilly Answers, Matt Jadud of Allegheny College describes how Occam helps artists using the Arduino in their installations, and how the advent of low-cost computing platforms is changing the educational experience for proto-makers in school. 'Basically, an artist or a tinkerer or a hacker has a goal. They don't really care about learning Occam. They don't care about how this language is different from C. They just want to make a cat door that keeps their cat out when the cat comes back with a mouse. Or they want to make some kind of installation piece. Trying to focus as much on the user and the possible goals they might have is what's motivating our work right now.'"
What is this gay shit? (Score:-1, Insightful)
What have I won?
Re:That kind of thinking... (Score:2, Insightful)
Arduinos are allowed to have security holes.
Re:That kind of thinking... (Score:5, Insightful)
Next up I suppose you're going to complain about how Legos don't force you to learn proper civil engineering before building things?
"simple" threading (Score:5, Insightful)
just implement simple threading
Sure, and they could just learn to fly too, instead of relying on some convenient form of transportation that solves the problem for them.
Threads are the famed "simple, clean and wrong" general solution to parallel programming tasks. The *concept* and *implementation* of threads can be simple, sure, but if you're working on anything other than simple problems, the trouble of keeping track of everything that's going on can become very challenging very quickly.
a whole other language just for one problem.
It's a big problem. Learning another language is generally a smaller problem. Particularly if you're the kind of Real Programmer(TM) that we're probably going to hear can manage with threads just fine.
Re:Threads (Score:2, Insightful)
Occam was intended as a reply to all the problems that can happen with threading, The ides with Occam is that a lot of the things that can go wrong with threads simply cannot happen in Occam. Think of it as Java to threading's C. Just as you cannot create random pointers in Java, you cannot lock random mutexes in Occam (which doesn't have mutexes),
Traditional threading really is assembler level coding for parallelism; Occam tries to move to a high level language.
Re:Why do people struggle with this so much? (Score:4, Insightful)
A race condition between two processes is easy. A race condition between three is several times harder. Race conditions between a half dozen processes? Forget about it, at least for the hobbyist.
Race conditions can be notoriously difficult to program around. You can go from 20 lines of code to 200 in a heartbeat with just one or two of them. Get five or six, and your 20 line program needs a thousand lines to deal with it all. That's pretty ridiculous, especially for hobbyists.
If you've got a tool to eliminate the problem completely, why would you poopoo it?
Re:That kind of thinking... (Score:5, Insightful)
Repeat after me: people who don't want to learn programming will make lousy programmers.
Fine then: the statement above is garden-variety developer egocentric stupidity. TFS' statement is right, these folks want to get their work done, but the specific tools are irrelevant. The qualities of those tools for the task are the only things that matter.
It's insulting and stupid to propose that those looking to program and leverage an *Arduino* for their personal projects are somehow slackers uninterested in learning. Maybe they're just interested in learning what they want to, not what you want them to. I've walked the path of deep knowledge of programming, CS, etc. I've put my thousands and thousands of hours in. It's a good one for those who enjoy it, but it's not the end-all, be-all for all people.
Lots of people "want to learn", but at the same time they don't have that "ten thousand hours to mastery" to invest in a new domain (here, programming/CS). There's a spectrum here: on one end, the deep knowledge of an experienced programmer. On the other, those who want and need to access the power of programming but don't want to be burdened with oceans of complexity and specialized domain knowledge. I'll apply an existing term, "end-user programming", for this.
The most successful end-user programming environment by far is the spreadsheet. It provides simple, tabular model and some fairly rich programming capabilities within its scope. Another great example is the Max/MSP/Jitter environment [cycling74.com] for real-time audio/video signal processing -- very popular in the computer music and visuals world. Labview-based [wikipedia.org] systems (which includes the Lego Mindstorms stuff) are another great example. Each of these environments is rich enough to allow programming, learning, and exploration. And all provide environments that are tailored to specific problem domains.
There's a place in the middle, often called by programmers "tools for the task", where a programmer doesn't have to bend over backwards to address certain hairy problem domains. Libraries, frameworks, and programming languages can all meet these needs in their various ways -- even to the extreme that it transforms what some people consider the nature of "programming".
Re:Threads (Score:3, Insightful)
PAR is not the important part of Occam. The fact that all message passing is synchronous and there is zero aliasing is what is important (it prevents a ton of errors, makes automatic reasoning about the programming much easier too). You can do synchronous message passing in any language, you can try to program aliasing free in any language too ... but few people do. They'd rather create abstractions for mutex locking and then rely on programming convention and programmer infallibility for their correct use.
Modern Occam isn't 80's Occam by the way, creating complex data structures is much easier and you can pass data by reference for instance (the local reference gets destroyed when passed).
Re:That kind of thinking... (Score:3, Insightful)
But they do make promises that they cannot keep. The abstractions they offer leak, so when a developer works with these abstractions, the code develops weird bugs and slowdowns.
No, what forces developers face issues outside their domain of experience is that modern computers still don't have artificial intelligence. Consequently, when the frameworks start leaking, they start leaking hard. You end up acquiring a lot of knowlede and habits just to work around the oddities caused by the mess.
Frameworks and high-level languages are a good thing, but using them requires more, not less, expertize, since you need to know not only them but the underlaying system too - because that system will find a way to peek in.
Perhaps, but it also describes the history of weird little bugs that keep on creeping in from the leaky abstractions in every framework. Sooner or later you end up fighting the framework because it's limited in some way; fixing every such instance results in unbelievably convoluted frameworks that are really their own programming languages. At that point it would probably be better to just scrap the whole thing and start over with a newer, higher-level language.