Re: language issues
- From: Chris Gray <cg@xxxxxxxxxxxx>
- Date: 05 Oct 2008 12:16:57 -0600
nadia <nospam@xxxxxxxxxxx> writes:
If security is any issue at all the language must be simple.
Simple in the stuff that could enable security holes. But, adding stuff that
cannot affect that should not be an issue. For example, I've added some stuff
that I hope is a considerable improvement on C's bitfields, and I hope to
define it in such a way that it can actually be used portably. This adds to
the complexity of the language, but should not be a security hole.
I don't expect the *language* to block denial of service attacks on a system,
for example - I simply wish the language to prevent type insecurity issues.
An example of interest (although I know almost no details) is the old
Burroughs systems, in which most of the OS was programmed in an Algol
variant, and so was less vulnerable to type-security issues.
The sole reason Java was created was to produce a secure and safe language
for online use.
That was completely broken by allowing native code, of course. But, does the
rest of the language meet that goal? (Of course, this is not strictly
on-topic for what I'm trying to do.)
I don't mean this in any way to denigrate your skills but it seems that if a
team of well paid workers with the resources they had available can't produce
anything vaguely secure - following their lead may not be the best idea.
(Its just an opinion)
Can you provide explicit examples where Java *the language* is not secure?
I have no intention of copying Java libraries - my somewhat limited exposure
to them leads me to believe that they are most of the problem with Java's
bloat, for example.
Before implementing polymorphism or "classes" or any other popular features I'd
be very wary of the pitfalls.
Most people consider OOP to be the way to develop software - in the real world
the practice is more often in not to just "get the job done" and that often
means resorting to good old fashioned procedural methods hidden away under a
mask of modernistic gloss to please the bosses and marketing people.
To be honest, I'm really not a fan of OOP. But, I have limited experience
in it. What I want is the polymorphism, not the OO aspects.
Ask yourself exactly what it is you achieve with polymorphism in the real world.
A better more efficient program ? Doubtful. Ease of programming. Nope. Efficient
use of memory and processor time? Absolutely the reverse.
What I'm after is type safety. As my other requirements stated, I want to get
it without any significant cost. My system itself had already grown 4 uses of
internal polymorphism. The two main ones needed in the language system would
require far too much background to explain, but a simple one in a library is
used for the usual "magic cookie" technique. In C, these are often "void *"
values. In Java I imagine they are Object. In both cases, the client code
must cast to their particular cookie type. Using polymorphism, this can be
done with no casts, and still be type safe.
Todays complex methodologies relying on the hidden assumption that computers are
fast and getting faster in order to disguise all manner of inneficient academic
behaviour is all wrong (IMHO of course)
I don't disagree with what you are saying. My early experience goes all the
way back to CP/M systems where you could expect 32K of RAM for the entire
system, and were lucky if you had 56K. My first home compiler was the Draco
compiler (there is a wikipedia entry, but I've never editted it), which was
a one-pass compiler (from source to object file) for those systems. It even
managed to have some simple optimizations in it. It was written in itself.
Thanks for your response.
Experience should guide us, not rule us.
Chris Gray cg@xxxxxxxxxxxx
- language issues
- From: Chris Gray
- language issues