4 ms·
> When people say "it's hard to reason about", what they really mean is "it's got bugs and you can't tell by reading the code". This obviously isn't true unive
by JadeNB 9y ago
> When people say "it's hard to reason about", what they really mean is "it's got bugs and you can't tell by reading the code".
This obviously isn't true universally, and almost assuredly isn't meant to be; but, even interpreting it in the spirit in which it seems to be meant, surely the right translation is "you can't find bugs in a given code unit by reading only that code unit" or, more positively (?), "to find bugs in just one code unit, you have to read all the code."
- scarmig 9y agoMaybe for a sufficiently smart person, you can find all the bugs by reading all the code. But if you've got a concurrent program that modifies global state haphazardly, a sufficiently smart person doesn't exist.
- clusmore 9y ago>There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -Tony Hoare
- elihu 9y agoOr a concurrent development team that modifies the shared global code-base haphazardly...
- adrianratnapala 9y agoYes. But saying "code unit" makes it seem reasonable to read a module or package (or whatever it's called in your language). Ideally you want to just read a few lines of code and say yes-or-no. Any need to read more should be because of genuine big picture stuff. For example: Good: Yes, these five lines of code correctly parse the `fooTarget` flag, but I need to read more to understand if fooTarget is the right thing to parse. Bad: Ok, we are parsing the `fooTarget` flag, but these five lines will only work right if the current locale has certain properties, is the locale somehow guaranteed at this point?