RE: The world needs process-orientation

[tjoccam@xxxxxxxxxxx]

> An observation from a guy who have been trying to promote Erlang for years:
> new paradigms are only adopted when there is a business case for it. I
tried to argue three years ago that Erlang would be ideal for one of our
products, but since it required throwing away a lot of legacy code the
pay-back time was too big so it went nowhere.
> Right now I am trying again and this time there is a business case that
will open new markets and reduce the cost of our systems. The reason is
that Erlang allows us to do things that is much harder to do in C, but
the thing that has made the managers above me listen is not that it is
Erlang with higher quality and faster development time, no, it is the
business side of it that has changed the scenario.

Well-taken observations, Torben - since I haven't had an academic job for
24 years, I've experienced similar imperatives. But I have drifted into
the next part of the story.

I survived on the business-case basis for 10 years (since the fall of the
Transputer around 1995), but the pickings finally got too thin and I got
dumped. The new feature is that code has become so huge and impacted with
irrational constructs that the decision makers will no longer listen to a
proposal for fixing what they themselves admit does not work. (The
technical people will, but top management vetoes them, in favor of an
incremental programming model they tell me is called the "ant farm", in
which redesign, or even knowledge of design, is forbidden. This has
happened to me twice in the last few months.)

> <SNIP>

> So apart from making good business using COP

Is there a good reason for using this acronym? Everyone else seems to have
settled on "process-oriented programming". Unanimity, if possible, helps
in being heard.

> I think that an increased
> focus on the following enablers can help speed up the process (some of
it taken from previous mails in the threads):
>    * Provide COP as libraries/extensions to existing programming
> languages.
>    * Create a GUI library that shows the benefits of getting the logic
> in the right place (see http://ltiwww.epfl.ch/sJava/index.html for an
example).
>    * Provide good debuggers so that it becomes easy to handle the change
> in paradigms.
>    * Write "Choose the right tool for the job%