That was called an analogy. YMMV. | [reply] |
Apples and Oranges, maybe?
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
I see I need to be more explicit...
- Dealing with concurrency correctly is hard. Lifting it to the language level makes it easier to handle.
- Dealing with security correctly is hard. Lifting it to the language level makes it easier to handle.
I must be missing your point. I keep hearing the mantra "Security is a Process". Well coping with security in the language domain makes our "process" more explicit and enforces our policies so we can't violate them willy-nilly. I just don't understand the reluctance to even consider enhancing security through the language. Is it mostly because it is a new some-what foreign idea? When I see Theo de Raadt lamenting...
It was so subtle, that type of bug, that we realized that this was no longer an API-type of programmer mistake, but that people don’t actually understand the C programming language, or even basic arithmetic with restricted-size variables.
This integer overflow thing is really scary because as programmers, we really can’t spot them; we can read the code, and they’ll just go right over our heads. We can’t even spot them, even if we know what we’re doing.
I think to myself, "Ah, another way our languages help defeat security". Same goes for 99% of all security breaches. Could have been avoided or rendered harmless by using better languages. Its one thing to put up with crappy languages in the present. But why do we insist on punshing ourselves forever by not exploring greener pastures? Sigh.
| [reply] |