3 ms·
> Programs today get very fat; the enhancements tend to slow the program down because people put in special checks. When they want to add some feature, they’ll
by brianpgordon 13y ago
> Programs today get very fat; the enhancements tend to slow the program down because people put in special checks. When they want to add some feature, they’ll just stick in these checks without thinking about how they might slow the thing down. You have to have a programmer who knows the program inside out to guard against that.
This one struck me. Today the public methods of a class would check to make sure the inputs are valid. Back then the programmer would just know the location of every single caller and make sure the calls are always valid in the first place.
It's clear that the modern approach is a winner, especially with enterprise-size codebases, and really especially when developers churn every few years and nobody is around from when the code was originally written.
And of course Amazon is the ultimate success story of taking this idea to the extreme with a completely service-oriented architecture. Coding super defensively to minimal interfaces has been proven to work.
- pjump 13y agoFor them special cases, you've got CTR+ALT+DELETE. :-D
- ANTSANTS 13y agoKeep in mind that Bill was talking about programming in assembly language for extremely resource-constrained systems there. Even today, if you're trying to write an extremely small/fast program/inner loop in assembly, you had better be relying on "dangerous assumptions" like that, or else the result is going to be worse than what a compiler could do.
- Symmetry 13y agoIdeally you want your type system to enforce as many of these assumptions as possible since when it can you both speed and safety.
- sirmarksalot 13y ago> This one struck me. Today the public methods of a class would check to make sure the inputs are valid. Back then the programmer would just know the location of every single caller and make sure the calls are always valid in the first place. Personally, I would use the second option even today, with the caveat that there should be few, if any invalid inputs, what with type systems and OOP. If your method takes a string as a parameter, and can't handle every string that ever existed, then you really should be deserializing it into a data object of some kind, so that the compiler does the validation for you. If I'm developing some kind of API for public consumption, then I'll do input validation at the service boundary so that the consumer knows why it didn't work, but otherwise I'm a big proponent of the "just don't pass null" approach. Input validation on every function call bloats the code base, and is annoying to read through.