Re: A chip too far? Where is your solution Mr Larkin?

On Tue, 19 Aug 2008 20:53:38 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

John Larkin wrote:
On Tue, 19 Aug 2008 17:23:58 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

John Larkin wrote:
On Tue, 19 Aug 2008 15:07:51 GMT, Jan Panteltje
<pNaonStpealmtje@xxxxxxxxx> wrote:

A chip too far? Where is your solution Mr Larkin?
http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm?postversion=2008081405

Blowing in the wind, all blowing in the wind.
1. A new programming language, accompanied with a new way of teaching
programming.
That might help a bit. But there are a lot of very important legacy
applications already out there. Like it or not we are tied into the
existing applications codebase.
2. A new OS, which uses a nanokernel approach and wastes processors in
the name of reliability.
Can't fault the idea of keeping the Ring0 protected kernel as small as
possible, or giving users the least privileges needed to do their job.
But wasting performance for reliablity though is never going to fly -
not least because most times it would not have the desired effect.

Hardware enforced memory protection for threads on a timesliced CPU can
be made every bit as reliable as giving each one a physical CPU just a SMOP.
3. Ultimately, a new multicore cpu architecture that exerts much more
hardware control over the things that programmers tend to screw up.
You mean like enforcing bounds checking on array and pointer access?

Pointers have to be the first thing to go. And of course array bounds
should be checked, but all that can do is crash a program, which was
going to crash sooner or later anyhow.

Pointers are OK provided you can only trash your own memory space.
Anything else and you should get squashed flat.

We are programming antique hardware in antique languages.

Speak for yourself. I program in the language that best fits the problem
(or is dictated by the clients requirements). Sometimes both. The
fastest way to develop really tricky algorithms is in a language where
human errors and typos are mostly caught at compile time. The final
version is then translated back into C (which is mostly what people seem
to want). ISTR NAGLIB used this approach a very long time ago (when
FORTRAN was the main language of choice for scientific computing).

I wish that a more robust language had won the language wars, but it is
too late now to cry over spilt milk.

So, a hundred years from now, everybody will still be programming in
C++? Writing billion-line programs with millions of bugs?

Something to look forward to.


John


.

Relevant Pages

  • Re: object system...
    ... for that you need machine language. ... isn't even as fast as other systems programming languages. ... Stroustrup's stated design goal was to enable ... all manner of elegance or abstraction can be sacrificed for speed, ...
    (comp.object)
  • Re: DirectX in HLA
    ... I guess that you have a great knowledge of DirectX ... > understanding by looking at them in assembly language... ... > actually represents, really, is a means to "undo" the OOP so ... > is NOT an "OOPL" (object-orientated programming language), ...
    (comp.lang.asm.x86)
  • Re: DirectX in HLA
    ... I guess that you have a great knowledge of DirectX ... > understanding by looking at them in assembly language... ... > actually represents, really, is a means to "undo" the OOP so ... > is NOT an "OOPL" (object-orientated programming language), ...
    (alt.lang.asm)
  • Re: LSP and subtype
    ... What is the class of problems solvable using UML? ... the language of physics cannot describe. ... whatever paradigm equivalent to 2GL/3GL ... there is still a great need for reuse and generic programming. ...
    (comp.object)
  • Re: Why C Is Not My Favourite Programming Language
    ... If you decide afterall that C programming is just not your thing you ... > C has no string type. ... > compiler take care of the rest. ... Why does any normal language ...
    (comp.lang.c)