On 2016-04-27 2:50 PM, Noel Chiappa wrote:
    > From: Liam Proven

    > There's the not-remotely-safe kinda-sorta C in a web browser,
    > Javascript.

Love the rant, which I mostly agree with (_especially_ that one). A couple of
comments:

    > So they still have C like holes and there are frequent patches and
    > updates to try to make them able to retain some water for a short time,
    > while the "cyber criminals" make hundreds of millions.

It's not clear to me that a 'better language' is going to get rid of that,

Modern languages can indeed wipe out large classes of bugs (including many of those that lead to vulnerabilities). But *every* advance in abstraction does.

I like Professor Benjamin Pierce's way of putting it: "Mechanical checks of simple properties enormously improve software quality."

This has been called for, with little traction, for a very long time; one of my favourite calls is by Professor Per Brinch Hansen, recipient of IEEE Computer Pioneer Medal, in 1972:

"I expect to see many protection rules in future operating systems...enforced by...type checking at compile time."
  -- he assuredly did not have C in mind.

because there will always be bugs ...

The virulence, level, and number, change. Just think of the change in the nature and frequency of mechanically missed bugs going between: assembler to C; C to Java; Java to Haskell; etc.

I'd rather be dealing with only the bugs that get through that sieve, than deal with malloc/free bullshit or buffer overflows in C.

Ultimately the goal is to deal with the highest value problems, such as incorrect specifications or assumptions, rather than accidentally getting a stack offset wrong in one obscure instruction.

Productivity, security, reliability, correctness all demand that we wipe out as many tiers of bug as we can, with better/more high level tools... imho of course...

--Toby



        Noel


Reply via email to