3 ms·

This is the response I was looking for. We keep making computers 2x faster, and then making software architecture 4x more wasteful (given, it's also 20x faster

• masklinn 13y ago
  > That sucks, but I can't even imagine what the processor ends up executing for the Ruby lambda callback. That's not a very good question, `if object == nil` will already be a pretty huge number of instructions in ruby. Now if the question is "could you have this pattern compile down to little more than a null check", the answer is why not? A bit of flattening/inlining should be able to handle it correctly. And in most fields, the gain in safety way outweighs the almost unnoticeable (against background noise) loss in efficiency.
  • Locke1689 13y ago
    could you have this pattern compile down to little more than a null check The answer for C# and Java, which this issue was directed at, is no. Email me if you want details.
    • masklinn 13y ago
      > The answer for C# and Java, which this issue was directed at, is no. I'm not sure what you're talking about, you focused on java and C# for odd and unknown reasons, TFA merely uses java as an example of syntactically heavy (or even missing) closures language to illustrate the pattern's gains and differences.
      • Locke1689 13y ago
        Did you read the article? This is the beginning of it: The other day, I saw this example on StackOverflow: Person person = dataSource.getPersonById(personId); if (person != null) { person.setPhoneNumber(phoneNumber); dataSource.updatePerson(person); } This looks like a typical case where we need a null check. If the canonical example under discussion is in Java, I think it is safe to assume the article is about Java.
        • masklinn 13y ago
          > I think it is safe to assume the article is about Java. No. The article is about a pattern of explicit null-check avoidance, java is an example of "a language without blocks or lambdas" but the article is no more about java than it is about ruby, you're not even missing the forest for the trees you're missing the forest for a fallen leaf.
• dragonwriter 13y ago
  > "if (ptr == NULL)" is usually one instruction and an instruction pipeline flush. That sucks, but I can't even imagine what the processor ends up executing for the Ruby lambda callback. Probably a lot more than the null-check, and yet still undetectable against the background of the db call.
  • mrmekon 13y ago
    It's not the extra 1000 instructions of this call that is concerning. It's the extra 1000 instructions per thing-that-would-have-just-been-a-null-check summed over every running process on your machine if this actually took off as a standard idiom. If we keep adopting readability tricks with orders-of-magnitude differences in speed compared to what we're replacing, we'll just keep getting slower and slower code.
    • dragonwriter 13y ago
      > It's not the extra 1000 instructions of this call that is concerning. It's the extra 1000 instructions per thing-that-would-have-just-been-a-null-check summed over every running process on your machine if this actually took off as a standard idiom. I think for most cases where what you want to do isn't throwing an error on null, most of the time null checks are addressing external interfaces (database or otherwise) where the IO is going to be enough bigger than the pattern overhead that if you are able to deal with the load from the basic functionality, the difference between null check and using this "teller" style implementation is going to be negligible. And, obviously, where you want to error-on-null (whether or not an external interface is involved), this isn't the pattern to apply. > If we keep adopting readability tricks Factoring out commonly used boilerplate into a library function isn't a "readability trick", though it does benefit readability and maintainability of code.
      • masklinn 13y ago
        > it does benefit readability and maintainability of code. And its safety and correctness.