Comment by codygman | Hacker News Reader

Comment by codygman | Hacker News Reader

You might have been bitten by this before:

    1. Make it work
    2. Make it right
    3. Make it fast (uh-oh your nice design prevents performance optimizations, time to scrap it)

The reaction to that is usually to think more about performance ahead of time so you don't get trapped by your theoretically perfect design when the real world comes crashing down.

With your hard-won experience you do away with those childish notions of being able to make a perfect elegant design where you don't have to worry about performance until the end.

The most valuable thing you'll find in Sandy's book is that you can actually ignore performance until the end and nearly always (always maybe?) be able to make it fast.

You can regain your optimism from your younger years before the bad experiences and resume this path:

    1. Make it work
    2. Make it right
    3. Make it fast

I think it goes without saying that I highly recommend Sandy's book and think it could be the way forward for quickly writing correct, elegant (composable/re-usable!), and FAST programs.

IMO

1. Make it correct and not insane asymptotically.

2. Tune constant factors, if you need to.

In school I was confused why they kept on talking about asymptotics and ignoring the different costs of the building blocks. Now I see that, while it is true that asymptotic analysis doesn't well explain performance when "things are good":

1. There are a lot of stupid things people do write that it does catch.

2. Since it is scale free, it makes sense as a way to evaluate programs throughout their entire development.

3. Constant factor optimizations will always tempt one to ruin abstraction boundaries, but asymptotic analysis shouldn't----or if it does, sorry your abstraction sucks and needs to go. (Hi ORMs.)

The latter points are really powerful. Never make me work without efficient tree map/set union and intersection ever again.

>theoretically perfect design

We have no metric to use to quantitatively score one design as something unequivocally better than another design.

This is the first thing you will need before you can prove one "design" is "better" than the other. Until than we are doomed to go in circles and have endless debates.

I believe even if we do find some quantitative measure on program "designs" it won't be rating something as "better" or "worse" it will likely be metrics on many dimensions measuring tradeoffs.

When you design software focusing only on the business logic and domain the end result will be better than if you have to do it while juggling implementation and performance concerns.

> We have no metric to use to quantitatively score one design as something unequivocally better than another design.

Given the current state of software development, it's not fair to place that burden of proof here when it's not used elsewhere.

>When you design software focusing only on the business logic and domain the end result will be better than if you have to do it while juggling implementation and performance concerns.

Do you have a foundational proof for this? What are your axioms and theorems? A qualitative description (that you have provided) is open for debate. I can say the opposite and supply you with an endless chain of examples while you come at me with couter-examples and we go nowhere.

>Given the current state of software development, it's not fair to place that burden of proof here when it's not used elsewhere.

The entire mathematical community has this burden placed on them. The entire scientific community has lesser statistical validations placed it. The programming community has endless design pattern debates online as the burden.

Reply on news.ycombinator.com