Thursday, August 23, 2007

In COSA, Everything Is a Process. Not So in Erlang

That is the main difference between COSA and other concurrent languages like Erlang. Whereas Erlang is only partially concurrent (it uses so-called light weight processes), COSA does not cut corners. COSA is 100% concurrent. Nothing happens in COSA unless it receives a signal. Every cell in COSA is an elementary concurrent operator that waits for a signal, does something and sends an output signal to one or more other cells. Even adding A + B is a concurrent process. A COSA program consists exclusively of cells and their environment (data).

All right. I realize that a COSA application will be rather slow on current processors compared to conventional programs, but that is not COSA’s fault. It is the fault of the computer industry for having adopted a computing model that is at least as old as Charles Babbage and Lady Ada Lovelace. The algorithmic model is just plain wrong. It is a relic from the distant past. It is not fit for the 21st century. It is the cause of the software crisis. It is the reason that complex software is unreliable. It belongs in a museum, not in our computers.

Computing will not come of age until we adopt a software model that eliminates sequential programming altogether. We must recognize the errors of our ways. We must design our multicore processors to support the correct software model, not a 150 year-old dinosaur. We must stop believing that languages are a natural way to program computers. Computer languages are primitive, period. There are inherently sequential and they are not suited for parallel computing. It is about time that the computer industry wakes up from its self-imposed stupor and realizes that it has been doing it wrong right from the start. To borrow words from Nintendo of America’s CEO, Reginald Fils-Aime, COSA is about kicking ass; COSA is about taking names. But, unlike Reggie, I am tired of playing games. I want my self-driving car now!

Sorry about the outburst. I am getting frustrated and I just had to get it out of my system. :-)

8 comments:

snakenerd said...

i have been following your discussion and read the entire cosa architecture not long ago.

it is very interesting and i'm willing to implement it in some time in the near future.

it is obvious that systems that are massively algorythmic will run slow on current processors using the COSA model, but there are many many softwares that are by nature reactive, using a very small portion of time actually running algorithms. that's where i see COSA will be actually running well.

keep on going. it is all very interesting, and i think we will get somewhere with that.

regards,
-- Fred

Shawn said...

> Sorry about the outburst. I am getting frustrated and I just had to get it out of my system.

I'm getting a little frustrated myself that this site contains post after post denouncing the faults of algorithms, Brooks, and everything about programming as it stands today, but no posts that show how to do it better. The COSA site has lots of concepts and words, but words are not enough in this field. Where's the code?

I understand you have your reasons for keeping Animal's source locked down. I understand you don't have time to implement COSA just for fun or from the goodness of your heart. It doesn't have to be done all at once, but the community will not pay attention until there's something real we can grasp and build on.

If it's too much work to implement the system and ship big programs, please slap something together in Visio or Dia to show us what a real program would look like from the development perspective. A while loop is a start, but it's not a real program. What would hello world look like (built on a console, GUI, or web app, just pick one)? How about a simple app that processes mouse clicks, retrieves data from some data system, and displays an image or some formatted text on the screen? Make assumptions that the mouse, data, and display subsystems are done and working, but show the logic of the program and its connections to the subsystems (a la http://code.whytheluckystiff.net/shoes/browser/trunk/samples/book.rb?rev=117).

What I gather from these posts is that parallel programming pundits aren't the only complainers. You want change? Show us some code. Maybe it will fly, maybe it won't, but how else will you know? Is Linus directly responsible for near half of Linux's source code? I doubt it, but he built something that the world could run with, and look how far it's come.

Louis Savain said...

You want change? Show us some code. Maybe it will fly, maybe it won't, but how else will you know?

Naw. That's not what COSA is about. COSA is about a paradigm change in computing. It's about a whole new way of building and programming computers. I am not trying to persuade programmers. That's a waste of time. Programmers are too close to the trees to see the forest. Besides, like religionists, they are prone to fanaticism and tend to knock any idea that they are not used to. As I see it, COSA is a threat to the programming profession as we know it.

COSA cannot come to life unless the CPU hardware designers make it come to life. If those guys and gals don't wake up and do the right thing, it will never get done. COSA is not rocket science. In fact, it is very close to what circuit designers are already familiar with. It is easy to understand.

The way I see it, if Linus could be motivated to work on an OS look-alike, CPU designers could be motivated to work on something a little bit more exciting than that. COSA is about Revolution with a capital R. Either it's a chicken shit idea with no merit, or the computer industry is chicken shit and does not deserve it. I am willing to work on actual code if the AMDs, Intels, Suns, IBMs, Tileras, Xilinxs of the world are willing to pay for it. Otherwise, I will just continue to bitch on my blog until the day I die. Sorry.

snakenerd said...

COSA cannot come to life unless the CPU hardware designers make it come to life. If those guys and gals don't wake up and do the right thing, it will never get done. COSA is not rocket science. In fact, it is very close to what circuit designers are already familiar with. It is easy to understand.

Why not implement a proof of concept?
Something that will run slow for obvious reasons but that will prove that, for example, failures in parts of the software will not cause catastrophic failures in the overall process? Or that it is much better to program and reuse software visually?

I think you can't stand in neither extremity in this matter: neither bitch for your entire life because hardware designers haven't given this idea a chance, nor implement everything and see in the end that it was all in vain because current hardware designers did not see the obviousness of a better solution for software implementation.

I'm interested in trying a proof of concept. If you want to think this through, I'm available.

Regards,
-- Fred

Louis Savain said...

Fred wrote:
I'm interested in trying a proof of concept. If you want to think this through, I'm available.

Fred, thanks for your offer and for your interest in COSA. I would be willing to engage in a full, or even partial, development project to implement COSA but I am currently very busy on a completely different project. My time is extremely valuable to me. I cannot shift my focus to COSA right now. I would do it only if some company was willing to invest some good money into it. And I am talking about millions here, not just a few thousands dollars.

That's what a proof of concept will require, in my opinion. Why? Because the primary claim that I am making is that there is a way to construct extremely complex software systems that are guaranteed 100% bug-free. The second claim is that a visual interface is the ideal method (in terms of productivity) of parallel programming.

To prove the claims, I would have to build an entire OS (including a database, I/O services and desktop interface) and the graphical design tools that are needed to create applications.

If you are willing to slap something together, by all means, do it. A simple COSA editor and a few cells could do it but I don't think that would be enough to convince the big guys to switch to a different kind of computer.

If the ideas that I put forward on the COSA website and on this blog are not persuasive enough to attract the kind of money I think is needed for a comprehensive project, it's not worth it to me to invest a lot of time on it. Sorry.

snakenerd said...

I think "the big guys" you're talking about will for sure invest in this idea once they see the profit coming back. This is why a proof of concept is so important. For now, COSA seems like a powerful idea but it is still too far from reality.

Although powerful, I think the COSA model is simple, and that it should not be difficult to write a COSA OS. At least the core, and leave the OS services to grow within time.

And while a COSA visual editor would make programming orders of magniture easier, it is still OK to use something like Esterel or other reactive systems language to start. Just to program simple but powerful things.

I think the idea of implementing parallel quick-sort is very good. We can even make simulations of its performance in an actual massively parallel hardware implementation.

Regards,
-- Fred

David Hopwood said...

Erlang uses a mostly-pure functional model (that is, the only impure operations are message passing and use of certain libraries) to describe the behaviour of individual processes. So it is not correct to say that it uses "a computing model that is at least as old as Charles Babbage and Lady Ada Lovelace." Babbage's machines, and Lovelace's programs, were strictly imperative.

Yes, both imperative and functional computation models are algorithmic. But the majority of problems with current software are due to it being programmed in an imperative model (with concurrency as a poorly integrated add-on), not due to it being programmed in an algorithmic model.

Louis Savain said...

Yes, both imperative and functional computation models are algorithmic. But the majority of problems with current software are due to it being programmed in an imperative model (with concurrency as a poorly integrated add-on), not due to it being programmed in an algorithmic model.

David. Thanks for your interest in my blog. The way I see it, all algorithmic programming models have the same problem. It is almost impossible to use them to enforce deterministic timing and resolve data dependencies, which are the primary requisites for reliable systems, in my opinion. If functional programs were as reliable as you claim, then Joe Armstrong would not have designed Erlang as he did. His primary goal was to create systems that remain robust in spite of software errors. It seems that Armstrong does not have as much confidence in the functional programming paradigm as you do.

I also have major problems with the linguistic approach (I think computer languages are primitive)to software construction but that's another story.