Abstraction levels and tool evolution, versus bugs - Re: strangest systems I've sent email from
Toby Thain
toby at telegraphics.com.au
Wed Apr 27 17:14:47 CDT 2016
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
>
More information about the cctalk
mailing list