5 ms·
No, it wouldn’t have, for the simple reason that no one is willing to go to the extra effort to use a capability-safe language, for the same reason we don’t all
by alasdair_ 5y ago
No, it wouldn’t have, for the simple reason that no one is willing to go to the extra effort to use a capability-safe language, for the same reason we don’t all code in formally-verified languages - it’s just too much work.
The claim in the article could be “The log4j vulnerability could have been prevented by hiring someone to punch any developer who tries to use JNDI in a logging library in the face” and would be equally valid.
- kragen 5y agoIt sounds like you haven't tried it, so you're just guessing that it would be hard without any knowledge, because you're used to writing code in such a way that security is inconvenient. Writing code in E is nothing like writing formally verified code. It's a lot less work than writing code in Java or C++.
- PedroBatista 5y agoIs it? I’m referring to real world coding to solve real world problems in order to get real world paychecks.
- kragen 5y agoYou're going to have a hard time getting a job writing E, or for that matter finding E libraries, because nobody uses E. Same story with Lobster, Clean, RScheme, Cobra, or a zillion other languages that don't have much adoption. But that is an entirely separate question from it being a cumbersome programming language, which is what the grandparent comment was alleging of all ocap languages—based on, apparently, total ignorance. There's nothing wrong with total ignorance; it's where we all start. But there is a great deal wrong with pretending that your total ignorance is expertise that justifies dismissing what you're ignorant of. Believe me, I have a lot of experience being that guy. It sucks.
- pdimitar 5y agoI don't disagree but we have to start somewhere. For example: formally specify [the clear parts of] HTTP 1.1 with declarative programming (which will generate proper code) and that would already be a huge jump. My point is: at one point somebody has to contribute.
- kragen 5y agoYou may have intended to comment on a different article, since not only does your comment not relate to anything in my comment it was related to, it doesn't relate to the security approach being discussed in the article the entire thread is about.
- alasdair_ 5y ago> Writing code in E is nothing like writing formally verified code. It's a lot less work than writing code in Java or C++. I bet it’s not, for the very simple reason that most software today isn’t written in E. This sounds like I’m being flippant but I’m not. The total “cost” of writing code in a specific language includes things like “can I find the answer on Stack Overflow?” and “can I hire enough engineers to code in this language?” And the total cost of coding in E is almost certainly higher than in Java because if it wasn’t, people would already be doing it.
- kragen 5y agoI explained why your comment is not to the point 15 hours before you wrote it at https://news.ycombinator.com/item?id=29700919 https://news.ycombinator.com/item?id=29700919, because someone else already wrote the same thing.
- clusterfish 5y agoI don't think a well designed capability system would be so onerous as to be unworkable, people use other complex features in Rust and C++ and Haskell just fine. It's just that being capability-safe by itself is not enough to carry a niche language. Eventually these ideas will find their way into more mainstream languages, one way or another.
- kragen 5y agoI disagree with your premise that a well-designed capability system is a complex feature. It's better described as an absence of certain complex features.