| com | muni | ty | “get into the Flow” | ||
| com | muni | ca | ting | ||
| com | pu | ting | |||
| ------------- | + | ||||
| com | muni | pu | ting | .org | |
The world is parallel, so why not model it like that.
As parallel modeling is then more direct,
why is sequential programming usually considered way easier?
Idea: It is a matter of habit and lack of (access to?) user-friendly powerful tools
Let's build on the proven/proving technology named Communicating Sequential Processes (CSP), or more specifically Occam(-like languages),
and enhance them with some ideas that decades of technical developments made feasible:
schematics are not just static illustrations: We often start out scribbling schematics on a piece of paper, and then start all over in a slower, more error-prone mode (coding) on the computer. Sounds inefficient, right? As these schematics have a 1-to-1 relationship with code, they're just 2 different views of the same thing. So design one (based on your preference for the situation) and get the other(s) for free.
I'm thinking a custom UI on a huge multi-touch screen ...
Open Development: web-based, open standards, open source code in distributed version control system, open communication. That's just a given, a proven method. Cooperation. Interesting stuff to build on: concurrency.cc,
Multithreading for Javascript,
"Threads suck", by Brendan Eich,
stratifiedJS,
Occam-Pi people referring to Brendan Eich's bit
Open Execution: The browser is omnipresent.
Occam's channels over the internet have been done before, but the processes were running in a Java applet (not exactly omnipresent and stable). Can we improve on that?
Maybe use browser-native webworker (threads), channels via SJAX or Websockets.
Have a repository of actual processes?
Some possible implementation details: