3 ms·

The first quote is an over-simplification that often does not hold in practice: one usually needs both. The exceptions are mostly trivial programs.

by sidlls 4y ago

gilch 4y ago
It's the reason Excel is easier to learn than Java.
Karellen 4y ago
Most pithy aphorisms are over-simplifications. "Want cleaner code? Use the rule of six" probably is too. But they can still give you a useful way of thinking about a problem that you might have forgotten to consider, and can give you a Platonic ideal as a useful guiding star even if you know you'll never reach that sort of purity in the real world.
lelanthran 4y ago
> The first quote is an over-simplification that often does not hold in practice: one usually needs both. The exceptions are mostly trivial programs. Depends, but not on the complexity of the application. Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is supported by the set of applications. Given all the code for the same set of applications, and you'd find it difficult, if not impossible, to predict what the business logic is across all the applications.
- sidlls 4y ago
  > Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is supported by the set of applications. How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does. One can guess at bits and pieces of it, but not more. It’s like saying that given a table of numbers one can predict exactly what functions produced them.
  - lelanthran 4y ago
    > How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Only if they're randomly named. > Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does. Seeing a table named "invoices", which has a column named "user_id" that is a foreign key for table "user" doesn't give you at least a few clues about the business logic there? Seriously, I want to see an example (choose an open source project) of a project where the data structures don't give any clue to what the business logic is. Once you go looking for that example, you'll see why the data structures are more revealing than looking at the code.
    - sidlls 4y ago
      It gives clues, but it doesn't tell the whole story. It certainly isn't enough to do anything other than make a pure guess at what the application actually does and more importantly how it does it.
      - lelanthran 4y ago
        > It gives clues, but it doesn't tell the whole story. It certainly isn't enough to do anything other than make a pure guess at what the application actually does and more importantly how it does it. I'm not claiming that it will tell the whole story; I am claiming that it tells so much more of the story than the code, that you may as well just not look at the code if you have the data structures. OTOH, if you look at only the code and not the data structures, you'll have so little of the story that you cannot make any change without risk of breaking some other piece of logic. There's just no comparison between "The code tells us what the applications should do" and "The data tells us what the applications should do". If you can find any examples where it is faster to determine what business logic is supported by the application by examining code (as opposed to being faster to determine what business logic is supported by examining the data structures), I'd very much like to see that.

The first quote is an over-simplification that often does not hold in practice: one usually needs both. The exceptions are mostly trivial programs.

by sidlls 4y ago

The first quote is an over-simplification that often does not hold in practice: one usually needs both. The exceptions are mostly trivial programs.

gilch 4y ago

It's the reason Excel is easier to learn than Java.

Karellen 4y ago

Most pithy aphorisms are over-simplifications. "Want cleaner code? Use the rule of six" probably is too. But they can still give you a useful way of thinking about a problem that you might have forgotten to consider, and can give you a Platonic ideal as a useful guiding star even if you know you'll never reach that sort of purity in the real world.

lelanthran 4y ago

> The first quote is an over-simplification that often does not hold in practice: one usually needs both. The exceptions are mostly trivial programs. Depends, but not on the complexity of the application. Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is supported by the set of applications. Given all the code for the same set of applications, and you'd find it difficult, if not impossible, to predict what the business logic is across all the applications.

sidlls 4y ago
> Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is supported by the set of applications. How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does. One can guess at bits and pieces of it, but not more. It’s like saying that given a table of numbers one can predict exactly what functions produced them.
- lelanthran 4y ago
  > How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Only if they're randomly named. > Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does. Seeing a table named "invoices", which has a column named "user_id" that is a foreign key for table "user" doesn't give you at least a few clues about the business logic there? Seriously, I want to see an example (choose an open source project) of a project where the data structures don't give any clue to what the business logic is. Once you go looking for that example, you'll see why the data structures are more revealing than looking at the code.
  - sidlls 4y ago
    It gives clues, but it doesn't tell the whole story. It certainly isn't enough to do anything other than make a pure guess at what the application actually does and more importantly how it does it.
    - lelanthran 4y ago
      > It gives clues, but it doesn't tell the whole story. It certainly isn't enough to do anything other than make a pure guess at what the application actually does and more importantly how it does it. I'm not claiming that it will tell the whole story; I am claiming that it tells so much more of the story than the code, that you may as well just not look at the code if you have the data structures. OTOH, if you look at only the code and not the data structures, you'll have so little of the story that you cannot make any change without risk of breaking some other piece of logic. There's just no comparison between "The code tells us what the applications should do" and "The data tells us what the applications should do". If you can find any examples where it is faster to determine what business logic is supported by the application by examining code (as opposed to being faster to determine what business logic is supported by examining the data structures), I'd very much like to see that.