Hacker News Reader

Comment by Karellen | Hacker News Reader

> Show me your flowcharts (code) and conceal your tables (data structures), and I shall continue to be mystified. Show me your tables (data structures), and I won’t usually need your flowcharts (code); they’ll be obvious.

-- Fred Brooks, The Mythical Man-Month, 1975

> a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read and only incidentally for machines to execute.

-- Abelson & Sussman, The Structure and Interpretation of Computer Programs, 1984

View on HN

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

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.

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

> 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.

> 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.

> 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.

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.

> 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.

Well, dealing with graph algorithms, none of them are obvious from the representation. Which is usually a matrix.

In fact, Gauss Jordan is also not obvious, just seeing a matrix.

Reply on news.ycombinator.com