RE: The world needs process-orientation

[tjoccam@xxxxxxxxxxx]

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#Source-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