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