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

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.

I tend to find that top-down designs usually end up clunky. In my experience, bottom up designs (starting with specific things and creating new abstractions as they're needed) tends to create simpler and more obvious designs. You also don't waste time on hypotheticals, since every line you write has a purpose. This blog post really nails it: https://caseymuratori.com/blog_0015

In that context, I don't think this is superficial at all. If your code is hard to read, I suspect your design is hard to read too.

Sure, for super important architecture decisions you have to make a few top-down (spatial partitioning structures, database decisions, network architecture, etc.), but I think it's generally better to late-bind on those decisions if you can.

It is superficial. No amount of trying to pretty up the code can fix underlying design deficiencies. That's what I said, so we're not even disagreeing here :)

I know the semantic compression post, and I don't think it makes a point for bottom-up design. I find top-down and bottom-up to be quite misleading anyway. Someone told me, they don't like to think of things at the "top" and the "bottom". It's data transformations, maybe more like "left to right".

If you design bottom-up, you end up with lots of artifacts you never needed (and likely still missing the ones you can make use of). If you design top-down, you end up with lots of code you don't need. (this is where semantic compression comes in, in my understanding).

I suspect that if you like to think bottom-up, maybe that's because you like it more at the bottom (you are a low-level type of guy, or like to make libraries). If you like to think top-down, maybe you like it more at the top.

I like the semantic compression term because it reduces the act of design to the essentials, without introducing fluff terms or opinions. I find myself doing this compression no matter what kind of code I'm writing.

Well, you might know of that blog post, but might want to reread it, I don't think it says what you think it says. The example he steps through is very clearly bottom up. He even outright says it:

> This is a very bottom-up programming methodology, a pseudo-variant of which has recently gained the monicker “refactoring”, even though that is a ridiculous term for a number of reasons that are not worth belaboring at the moment. ...

> Like a good compressor, I don’t reuse anything until I have at least two instances of it occurring. Many programmers don’t understand how important this is, and try to write “reusable” code right off the bat, but that is probably one of the biggest mistakes you can make. My mantra is, “make your code usable before you try to make it reusable”.

> I always begin by just typing out exactly what I want to happen in each specific case, without any regard to “correctness” or “abstraction” or any other buzzword, and I get that working. Then, when I find myself doing the same thing a second time somewhere else, that is when I pull out the reusable portion and share it, effectively “compressing” the code. I like “compress” better as an analogy, because it means something useful, as opposed to the often-used “abstracting”, which doesn’t really imply anything useful. Who cares if code is abstract?

And I don't understand how you'd end up with artifacts you don't need with that approach. Do you mean intermediate steps you refactor? In that case I suppose so, but that's an important part of the process, not a waste. You're never going to get the initial design exactly perfect so you need to iterate on it.

What he means there by saying "bottom-up", as far as I can tell, is that you "compress as you go", i.e. it is bottom-up compression, in a similar way to how you can also write bottom-up parsers.

It's not stating that you should start by creating lots of little artifacts before you have a great plan (bottom-up design) nor that you should start implementing the "non-functional requirements" (another confusing term) on a high level before you know the platform and other functional requirements, which is top-down design.

So that's perhaps a justification why I said earlier that these terms are misleading :-)

As to the other thing that I said, that bottom-up tends to create things you don't actually need, it's almost immediately following the definition of bottom-up. You can even find this on the Wikipedia page, which states that in practice, software-development typically uses a combination of bottom-up and top-down for that reason.

(In other words, always strive to know as much as possible about requirements both at the "top" as well as at the "bottom", as early as possible. Or the risk is that the design won't fit some part of the requirements and large parts need to be redone).

I still don't see the connection with what I originally wrote, in any case.

> It's not stating that you should start by creating lots of little artifacts before you have a great plan (bottom-up design)

Look, you can disagree with his conclusion, but that is exactly what he's saying. The post is long but it's very clear and methodical about how he's suggesting code should be designed and written. I happen to agree with him.

From the post: "if the reusable code is already suitable, you just use it, but if it’s not, you decide whether or not you should modify how it works, or whether you should introduce a new layer on top of or underneath it."

I'm having a really hard time interpreting this as "you should design / program bottom-up".

If you go to Wikipedia, bottom-up design is roughly defined as taking the existing stuff and building new things on top. I still fail to see where the compression part comes in here.

Neither of the two directions will look back at the mess they've made and compress it. They're just ways to develop the system by adding to it incrementally.

But then, these terms are generally poorly understood (as evident from various discussions I've had) and I don't want to claim to have the perfect understanding either. Nor do I want to be "Look"'ed any more. So, whatever.

Honestly mate, I just don't really understand the point you're trying to make. Originally it was that it doesn't matter if the line-by-line code is understandable because the high level design is what's important. I think the line by line clarity is important, because if that's confusing in my experience the design tends to be muddled also. But then you have these definitions of bottom up and top down that are very confusing and seem to exist mostly to you. I'll simplify what my definition is: bottom up programming means you write the code without any abstractions first, and then you generate the abstractions as you find commonalities and repeated patterns. I find this to be superior to the other approach, of generating abstractions first and then filling in the code. That is my opinion, I know other's believe differently. And "look" is not an insult.

What is easier to read:

a) 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1

b) 20

If all the code in your project was written like a), how would you feel? Does it make your job easier or harder?

I'll tell you how most people feel when they read code that looks like a):

- The author didn't care about other maintainers.

- The author is selfish and does not have empathy for others.

- The author ruined my fucking day.

- Team members are competing by sabotaging each other's productivity.

- If I clean this, by the time I am done, the author would have pushed 10 more commits that look exactly like this and eventually become my boss.

- The author is wasting everyone's time.

- The author is forcing others to volunteer to clean up after them.

- Why does management tolerate code following the a) style? A simple intervention would make it go away and my job would be so much better.

- It's sad that everyone is too busy looking at Jira and nobody cares about the actual fucking product.

- This is slowing everyone down and I have stuff to do.

- The code is error prone, one day I'll break it.

- Why should I contribute quality code if low quality is acceptable?

As you can see, it objectively fucking sucks. It's draining, demoralizing to read, it's frustrating, it wastes people's time, it gives people the perception that nobody fucking cares and the code is everyone's toilet with no trip lever.

And while it's "superficial", it's the surface that all engineers interact with. If I spread superglue over the surface of your kitchen counter and every dish and utensil in your kitchen every day around lunch time, that problem will also be "superficial", but it will ruin your life.

So, the conclusion is: Just fucking write clean code. Shitty code ruins the morale of people who care, who are the people that want to build great things not the ones cashing a paycheck and resting and vesting.

You are not a full-time architect, you are not in business development/marketing/finance or whatever, you are in the fucking engineering department. Your contribution to the business are your deliverables. The "superficial" stuff you talk about is your job. Do it.

"Ah ah ah, you didn't say the magic word!! ah ah ah!" Don't be the fucking Dennis Nedry of the team. Format your code, make it readable by your team and your future self.

Do you want everyone to love you? Write code like this:

https://norvig.com/spell-correct.html

What the f* is wrong with you?

If your comment were code, I think it's an example of a)

Fair enough, but a strong point had to be made.

Your example is artificially designed to make your point, but imagine a case like this:

  # Add the left & right margins
  width = calculatedWidth + 1 + 1

The "+1+1" might indeed be more readable than "+2".

Yes, I sometimes do that as well to signal a part that's non-obvious or easy to overlook. Ideally with a little comment for the reason.

Same with my (admittedly rather dirty) openSCAD designs, where I like to explicitly add tolerances to the measurements while keeping them separate, e.g. `width = 34 + 0.25;`. Especially because tolerances often have to be tweaked a couple times.

You miss the point. The problem are not arithmetic operations.

Sorry if I've misunderstood your post.

The parent article was about replacing dense code with more lines of simpler syntax. I assumed you were in the shorter-is-better camp and willing to prove it with your example, where shorter undoubtedly is better. I found your example far stretched, and designed another case using your material (arithmetic operations) but applying only 2 repetitions, much in line with the spirit of the fine article.

I hope I managed to show that, although we can agree that "very very longer is worse", this not always implies "shorter is better".