8 ms·
Exactly, if a language makes a mistake virtually impossible to make, why would you not want to take advantage of that? If there's even a small chance you can ma
by seanwilson 12y ago
Exactly, if a language makes a mistake virtually impossible to make, why would you not want to take advantage of that? If there's even a small chance you can make a mistake, it's inevitably going to happen given a large enough project. For issues like security it's not scalable to just "be careful".
Also, as a programmer, I like to automate tedious problems away. I don't understand why a programmer wouldn't want to automate away such a enormously important issue.
- xamuel 12y agoIt's a real dilemma. Sure, the safeguards make your code 5% less performant; who cares, right? Now suppose your code has a dependency, which has a dependency, which has a dependency, which has a dependency. And each level introduces a 5% performance hit. Suddenly your product is 28% less performant. This is why you end up with such nonsensical things as, e.g., the OWL API needing 2 gigabytes of RAM to hold an ontology that should take 200 megabytes max.
- seanwilson 12y agoDo you have links to any benchmarks about this? I can't imagine bounds checking in practical programs has that much impact. For what impact it does have you have to weigh that against the impact of security exploits. Most languages with bounds checking have ways to eliminate bounds checks in certain scenarios as well.