5 ms·
You can fix your interface bugs early in the development process with the aid of a compiler, or you can fix them later manually at much greater expense. When t
by pklausler 9y ago
You can fix your interface bugs early in the development process with the aid of a compiler, or you can fix them later manually at much greater expense. When the "tax" is so much cheaper than the consequences, not paying the tax is crazy.
- wellpast 9y agoBut "interface bugs" are the least of our problems. As evidenced by most bug queues that I've peeked at.
- willtim 9y agoNo true. I have to try and reverse engineer types whenever I use JSON APIs. The documentation provides only "samples". I literally have to experiment to find out what works with no guarantee it will keep working.
- always_good 9y agoI don't know about that. How about the simple interface of "shouldn't be null".
- deleted 9y ago[deleted]
- wellpast 9y agoIf null pointer exceptions are the most of your problems then I think you're doing pretty well. In my experience NPEs are the easiest bugs to root out and fix.
- willtim 9y agoThe point is that NPEs are a solved problem, just not in Java and Clojure. I am better able to stay focused on the real problems, as I never have to root out and fix bugs like this.
- wtetzner 9y agoNot to mention that the ease of fixing the bug has little to do with the cost of the bug showing up in production.
- wellpast 9y agoI can do all kinds of things to prevent bugs showing up in production. I once worked on a mission-critical piece of software in which the entire team was brought in to do a page-by-page code review for all newly written code. Of course, the cost outweighs the benefit in this case for most industry software that can afford a few bugs at the extreme expense of (this kind of) code review. Now the question is: are the static verification methods you're using (null-checking, type-checking, range-checking, what-have-you) worth the effort it takes to apply them over time? And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Most static programming languages force you (or make it hard for you not) to do this verification across the board.
- wtetzner 9y ago> And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Most static programming languages force you (or make it hard for you not) to do this verification across the board. Yes, actually, I don't find these things to be a particularly high burden, and the benefit, in my experience, easily outweighs it. When you're writing code, you have to think about what kinds of things will be passed to a given function, whether the compiler checks it or not. So I find having the compiler check mundane things like this lowers my cognitive load, because I don't have to worry so much about what to do if I get a null (fail, handle it in some way, etc.). I will agree, though, that the style of programming with maps so prevalent in Clojure makes a lot of sense in some programs. However, even then, there is a typing discipline that fits (row types).
- pklausler 9y agoHonest question: have you ever written a large computer program in a programming language descended from ML (SML, OCaml, Haskell, &c.)?