Earlier in my career, I had the honor of reviewing a part of the UML spec which involved a very surreal phone meeting with one of my heroes in this industry, Jim Rumbaugh. The area was on the UML's Action Semantics. At the time it was a separate spec but it is now intertwined in the Superstructure document as UML's Action behavior.
The idea according to Jim was to provide a sort of assembly language that all software behavior could map to. But I thought it provided a more powerful concept, that of the Action itself. An Action is a unit of behavior that has inputs, does some processing, and produces outputs. The outputs of one action feeds into the inputs of other actions. The "Ah-ha" is that all actions that have their inputs satisfied theoretically run in parallel.
This concept isn't new. Hardware designers have been thinking this way forever. I believe Petri nets present a similar idea in mathematical terms. But what struck me was this was a really powerful paradigm that can make it easier for programmers to write highly parallel programs. What was needed, though, was a good, 2-dimensional programming language that allowed programmers to create actions and hook up the inputs and outputs quickly and, of course, with minimal typing. But something like that really wasn't an objective for UML.
It's probably one of the reasons I'm keenly watching Eclipse's Modeling project. Aside from a great framework for creating domain specific languages, it has the capabilities that would be needed to build this "Action" language. And with a good back end that produced code for today's multi-core clusters, I really think this could be a good way to help programmers meet Intel's challenge that "Software has to double the amount of parallelism that it can support every two years" to catch up to the what the hardware guys are doing.
Hi,
ReplyDeleteIsn't what MapReduce algorithms are about ?
It was invented by Google labs I think but I'm not sure.
InfoQ has an article about it.
Regards,
Cédric
Interesting. Thanks for the pointer. I'll definitely take a look. From my very quick look it looks like MapReduce is specific to data crunching, where my ideas on Actions are more generic. But I like the quote that "Programmers find the system easy to use" for highly parallel jobs. It definitely shows the need for new paradigms.
ReplyDeleteThis actions thing kind of sounds like lazy functional programming in languages like Haskell. All functions in Haskell are pure, meaning they have no side effects (with a few exceptions to allow IO). This means that any function can effectively be run in parallel with any other function. I'm not sure how well this scales in practice though.
ReplyDeleteVisual programming is another issue all together. There has been a lot of research in this area for a long time but it has never taken off. I believe its because its actually very hard to express complex algorithms in a graphical way without it becoming a complete mess on your screen. A textual language allows you to express a lot of semantics in not a lot of space. Combine a textual programming language with an IDE and you have an incredibly powerful development model.
As for MapReduce, its a wonderful example of functional programming in practice. Here is a fun article on MapReduce.
I guess my main concern with doing this textually is how do you map outputs of one action (or function) to inputs of another. Today we have to declare variables to do that. My idea is that you can simply draw a line from the output connector on one action to the input connector on another. My hope is that that would be faster and less error prone. Interesting in theory anyway...
ReplyDeleteActually, what you describe sounds kind of like Simulink.
ReplyDeleteIt sounds like you're describing Prograph, a visually-oriented, data-driven programming language.
ReplyDeleteMaybe one Design Pattern could be the answer?
ReplyDeletewhen I finish the book about them, I will know it ;-)