- Fast, fine-grain, instruction-level parallelism using MIMD. What is the point of parallelism otherwise? And please, don't tell your customers that it can only be done using SIMD. As I wrote elsewhere on this blog, using SIMD to develop software is like pulling teeth with a crowbar. You don't know how to do it with MIMD because you are a bunch of thread monkeys, that's all.
- Easy software composition. This means a graphical interface for non-algorithmic programming, among other things. It also means plug-compatible components. Just drag’m and drop’m. No more (text-based) computer languages, por favor! Computer languages are a primitive, awkward, unnecessarily complex and messy legacy from the 20th century. They are a stupid way to program computers. Only computer geeks love computer languages. The market is not about what geeks like. It's about profit, reliability, security and productivity. To give you an idea of what I'm talking about, take a look at this parallel QuickSort using COSA cells. All labels can be created by the designer/developer using a natural language of his/her choosing.
- Deterministic timing of events at the elementary operation level. Deterministic temporal order is a must for reliability. This is possible only by adopting a convention whereby all instructions (elementary operations) are parallel reactive processes and have equal durations based on a virtual system-wide clock. That is to say, they all execute in exactly one virtual cycle. This is called ‘synchronous reactive computing’ (not to be confused with synchronous messaging).
- Implicit parallelism at the design level, and by this, I don’t mean compilers that extract parallelism from crappy sequential programs. I mean the programming environment should use objects that are inherently parallel. Otherwise, you're just fooling yourself that you're doing parallel programming. Implicit parallelism is the natural way to program and that's the way it should have been from the start, even with single core CPUs.
- Explicit sequential order. Either you’re doing parallel programming or you’re not. If you are, then sequences should not be implicit but explicitly specified by the developer. Otherwise, things become hard to organize and understand.
- Automatic resolution of data dependencies. This eliminates blind code and otherwise hidden side effects of code modification. It is an essential ingredient for reliability. It can only be done using a reactive synchronous software model.
- Fast asynchronous message passing using shared memory structures. Copying an entire message to a queue a la Erlang is a joke.
- Automatic transparent scalability. The developer should never have to think about cores. Programs should take advantage of all the cores automatically.
- Impregnable security. This is possible only in a system that enforces deterministic timing.
The public wants cars, trains and buses that drive themselves and planes that fly themselves. They want automated air traffic control that never fails. Your crappy products are killing people out there, damnit! by default and otherwise. You have no excuses! If you don’t get off your sorry asses :-) right now and investigate the soundness of the COSA software model, you should all be prosecuted for gross negligence. I mean it.
PS. There is one cool thing that happened in the industry recently and that's Jeff Han's multi-touch screen technology. You people should take a good look at Jeff''s stuff and study that user interface closely because fast, touch 'n drag composition is part of the future of parallel programming.
Erlang Is Not the Solution
Nightmare on Core Street
Parallel Programming, Math and the Curse of the Algorithm
Half a Century of Crappy Computing
Parallel Computers and the Algorithm: Square Peg vs. Round Hole