[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: The world needs process-orientation
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.
This is related to the old saying between news reporters: "Don't tell it
- show it.".
Just talking about how great Concurrency Oriented Programming (COP) is
will not move anything - there needs to be concrete evidence that it is
good for the bottom line to convince the decision takers that taking a
risk could be rewarded. "Nobody has been fired for choosing Microsoft or
code in C".
So apart from making good business using COP 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" kind of articles.
Regarding the last point: I think a lot of people are tired of hearing
about silver bullets, so a more mature approach to the benefits of a new
paradigm might bring more dividends than blindly arguing that COP is the
answer to all problems. There might be such articles around - I do not
have the time to read everything that is published - but a good article
about how some of the system is dealt with using OOP and some of it by
COP to give a better overall result would, in my view, make it easier to
convince the decision takers.
Getting a good GUI example on the table is also important since that
part of a product seems to be one of the first things people want to
judge things on.
Cheers,
Torben
p.s. The views above are not necessarily those of my employer.
-----Original Message-----
From: owner-java-threads@xxxxxxxxxx
[mailto:owner-java-threads@xxxxxxxxxx] On Behalf Of tjoccam@xxxxxxxxxxx
Sent: 11 June 2006 23:49
To: neil@xxxxxxxxxxxxxxxxx
Cc: Marc L. Smith; occam-com@xxxxxxxxxx; java-threads@xxxxxxxxxx; Jim
Sack; Tom Dickson
Subject: RE: The world needs process-orientation
Neil, Marc and all,
Let me weigh into the language discussion, because I think there is an
elephant or two in the living room...
[Marc L. Smith <mlsmith@xxxxxxxxx> writes:]
>> In other words, Neil makes a very insightful point regarding sub-
>> optimal (baby) steps! The masses have moved at a glacial pace from
>> assembly-level abstractions to C-like code, to C++ (aside: ever
>> notice that most C++ programmers are really programming in C, except
>> possibly for using cin and cout?), to Java.
But most programmers are not programming even in C, but in a subset of C
that is essentially generic block-structured von Neumann code. The
syntax of C makes this easy, and the specialized weird aspects of C
syntax (like "'ptr=&array' means the same as 'ptr=array' means the same
as
'ptr=&array[0]'") are avoided by all smart programmers.
[neil@xxxxxxxxxxxxxxxxx writes:]
> One thing that really amazes
> me is this:
>
> http://www.gnu.org/prep/standards/html_node/Source-Language.html#Sourc
> e-Language
>
> GNU state quite clearly that everyone should use C.
> <SNIP>
> C
> works, C runs on everything, you'd have to give me a good reason not
> to write in C.
> <SNIP>
> Microsoft accuse the GPL of being viral - they are almost right in
> this case! It allows C to spread virally. As you may notice, I have
> a particular dislike of C, but I don't think I'm wrong.
I think you've missed the point. All you need to do is open your editor
and type in #include <unistd.h> #include <stdio.h> #include
<stdlib.h> #include <string.h>
/* and other libraries documented in tools' man files */ int main(int
argc, char *argv[]) {
/* comment and code */
exit(0);
}
Then marshal the necessary resources and you can code ANYTHING... Apply
compiler and linker, set up and execute a script, and you are running.
On any system. Including parallel code (or a reasonable facsimile, using
bash lines ending in "&" and pipes or sockets).
Here's the point: the everybody-does-it utility of C code has nothing to
do with its insecure, metaphoric, bad features like deep stack usage,
weak typing, pointers instead of abbreviations, etc. A nearly identical
syntax was used for Perl, Java, etc, and a nearly identical syntax can
be used for a clean, simple process-oriented language WITH ACCOMPANYING
OS AND SCRIPTING MEANS. The generic programmer will hardly notice he has
totally changed his foundations.
What everyone forgets is that, historically, C preceded occam and Unix
preceded the 8086 and DOS. That means that in addition to the branch
toward increased metaphor and complexity (OO, GUIs, threads, virtual
everything), there USED TO BE a branch toward small, transparent, real
addressed, parallel-responsive coding. It died off for accidental
reasons:
real mode and DOS because of the silly 1MB memory limit, and occam
because it was self-crippled (worked only on the Transputer, and
couldn't stand on its own but had to use C/DOS/Unix tools on the system
level).
That's why I don't agree with augmenting already bloated and practically
unusable modern languages with process-oriented constructs. It would
actually be easier to build from the assembler foundation, and it would
still look like C, and be much, much easier to learn. But this time
we've got to include scripting, OS and boot, even if in a stripped down
form (like DOS). The "impossible to program" IBM Cell would be the
perfect platform.
> C allows
> programmers to write the most insecure vulnerable code of any
language.
> So those interested in security have two main solutions - drop C for
> a better tool, or educate programmers on how to write secure code.
> Sound familiar?! Yet year after year, programmers plug away writing
> buffer overflow-vulnerable code in C, because C prevails, and
> education (certainly at the degree level) rarely if ever teaches how
> to write code securely. Microsoft had to essentially re-train their
> *entire* development teams and totally change their attitude
> (throughout the
> organisation) to security in order to turn things around. That's now
> paying off, but it goes without saying that it seems unlikely a
> similar change would occur with regards to concurrency. Still, secure
> programming is still usually done in C, but with the education to
> understand what is going on.
That's a good example of what my proposal would, as a side-effect,
solve.
It would be no more complex than C, but have power-on to power-off
resource accounting, and therefore be perfectly secure.
Larry