(His remarks in normal font, mine (PM's) in italics)
As far as all of my questions I think I was right when I said that we are coming to the same solution from two different perspectives. The systems I think you built FBP for are massive systems. Up to hundreds of transactions per sec. The systems I work on are relatively small and focus more on maintainability/flexibility. I would love to work on such a massive system in the future but it's probably not going to happen in the near term. I see now that you basically have developed a framework in which data flows and pools up and then flows again.
I think for programmers like myself not having the extra requirement of needing to have a massively scalable system (especially in client side development). With that said I see a lot that will make a lot of sense to pull out of your writings and experiences.
So it's been a couple months now and I'm still super excited about this stuff, I'm a little saddened though because I think my needs only require something FBP like. An Actionscript version of FBP is going to be a very reduced feature set though it will still be great to use.
Now Python would be a real good place for a full real implementation of your ideas. It's a language that's really starting to take off. Any plans for that?
Re other stuff, I think you have nailed the important points, and I like your analogy of a river in a forest! The thing that's hard is the language question: if you peruse the wiki, I think you will find references to every language under the sun. Re Python, there is Stackless Python, someone else is playing with TCL/TK, a guy in Belgium is running it under Scala, someone else suggested D... Somebody tried a Ruby version... I have a C# version, a C++ version, etc. Back in the old days, I interfaced FBP with PL/I, FORTRAN, PROLOG, etc., etc. And FBP and SQL go well together, of course.
I am not keen on dynamic typing languages, although I recognize their appeal to programmers - in my view, they make development of small systems easier, but are harder to build big systems with, and reduce maintainability. But there is a role for them... There is an older type-free language called REXX (you may know it), and I did quite a pretty application using REXX, an Assembler version of FBP and a graphics package - do a find on PRORES in http://www.jpaulmorrison.com/fbp/scrmgr.htm for more info!
I think what we are missing is another basic concept of FBP - namely that every component should be able to be written in a different language. No one language can do everything, nor should it try. So, what is the most universal base that they can all interface with? After all, you basically only need a suspendable receive and a suspendable send - the rest is icing on the cake! Now there is preemptive multitasking and non-preemptive multitasking - can one do both in one base?... At one time I thought my C++ version could be the base - but that is non-preemptive - "green threads" - see also http://www.jpaulmorrison.com/cgi-bin/wiki.pl?ExecutionEnvironments .
Another possibility might be bytecode... I really don't know - maybe you can work out a viable strategy. What are they programming the new grid computing systems in? And I know some people say Fortran is good enough - dinosaurs :-)
As far as interlanguage communication you hit the nail on the nose there. Steve Yegge is an engineer at Google that I saw give a talk at Google I/O in San Francisco. Essentially, in his opinion, virtual machines are the path to interlanguage communication but a good solution is probably 10 years off.
Another much less performant but much more flexible option is to use web services. However, if I'm to be using FBP I probably really care about performance.
As far as using FBP on Actionscript: I think Actionscript 3 needs it's own implementation because the pseudo threading I am using currently is extremely slow. It'd be much faster if I made a hybrid with a more event based architecture.
What about functional languages like Erlang and Haskell? FBP seems remarkably like Functional programming but allowing its usage in an OOP world. Erlang uses TCP to interact with other Erlang modules on the network, I'm not sure how easy it is to get it to talk to other languages (aside from C).
So to sum up this long ramble...
In regards to FBP in small single threaded applications I think there should be a separate way of going about it that enable you to pick up the reusability and decoupling perks without necessarily having to try to use the concurrency (since in single threaded worlds it doesn't help). It wouldn't quite be FBP but it'd be similar enough to show case the concepts. I wish I had the opportunity to work on a larger system so that I could get a better feel for the needs of such systems. In the meantime, I think the best way for me to learn more about FBP is to learn more about large highly performant systems and the different design considerations that go into them. Any good books you'd like to point me to?