Re: Public disclosure of discovered vulnerabilities

Andrew Reilly wrote:
> However that programming generally still involves constraints like
> absolute minimization of memory footprints, RAM/ROM/on and off-chip space
> management and real-time response that rules out (or severely curtails)
> dynamic memory management, let alone the garbage collection systems that
> come along with most of the high profile, modern, safe languages.

That's a lot like the case for Assembly.

> Fortran, Pascal, Ada and Modula-2/3 could probably still find some uses,
> but they suffer from the availability problem. C++ is a readily
available
> "modern" language, but it doesn't do anything for the safety problem.
> Java/C#/Lisp/functional all suffer from a reliance on dynamic heap data
> structures that simply don't offer the necessary level of control and
> placement, have un-bounded and unknowable run-time and space overheads,
> and which impose significant extra space and time overheads by having
(for
> example) no (packed, contiguous) arrays of compound user-defined types
> (structs). Eiffel comes pretty close, now that it has a reasonable
> compliment of basic numeric types, but has the "niche language"
problem in
> spades, as well as the dynamic memory problem. Got any suggestions?

You ask if I, Bryan Olson, have any suggestions? You must be new
here.

I suggest 0.2% of code in Assembly; 2% in a low-level language
such as C or Ada; 20% in a flexible scripting language such as
Python; and most code (77.8%), should be in a language with an
advanced static type system, such as languages in the ML family.
Those are kind of global, over-all, long-term goals, and not
what I'm suggesting to my current customer for our current
project.

The availability issue, or niche language problem, is real, but
it's largely an unfortunate matter of inertia. C is so popular
because C is so popular, as one post put it. Some respect for
inertia is wise; we want to take advantage of implementation
effort already invested. The unfortunate part is the mental
inertia. We programmers like to think of ourselves as moving the
world forward, but really we tend to be as set in our ways as
anyone since the Luddites.

-- 
--Bryan