Ask HN: Bottom Up Programming Question

In code, a function to trim whitespace from a string is perfectly functional on its own. When you actually try to write code this way, a rather large number of things can be written, larger than you may think.

Rather than write a lengthy explanation, my suggestion is to write a non-trivial program in Haskell. After that you'll better understand how it is possible to have many functions that can stand on their own, and I think this will help clarify the situation in your mind.

You can do this in any other language, but most languages make it relatively easy to reach out and touch lots and lots of state. Real-world evolved systems tend to do the biological equivalent all over the place, to a level even the worst spaghetti code ever written doesn't even come close to aspiring to, and do not resemble human-engineered code in the slightest. The Haskell advantage here is that it won't let you. Achieving this in other languages right now is a chicken-and-egg problem; if you knew how to do that you wouldn't be using the metaphor you cited.

(BTW, just to state it explicitly: No, I didn't directly answer your question. As others point out, it's not a very informative question. I'm going for the root of the problem, how you are conceiving of functional units in a program.)

Maybe just 7% of your comments are about your business, but imagine you are talking to a mattress salesman, and every 10th sentences he says is about mattresses or about his business. Is that not a bit annoying?

I'm not saying what you are doing is wrong or that it does not fit the standards of the community. I'm just saying it annoys me personally. Nobody else maybe, just me. So I'm pointing it out to you, because it may also be annoying someone else, and if nobody mentions it, you won't be aware of this.

For example, you original comment on this thread was funny and insightful. The followup comment about bingo software was not, it just seemed like marketing.

I'd start with the "outside" of the program and work inwards. This forces you to categorize features as greatest to least important.

Refactoring can be significant -- much more than top-down. When used poorly, this can lead to the "design a 747 by building a wheel first" mentality, however. In other words, like everything else there's a place for it in the toolbelt.

You know, you can always model the problem domain first and still code bottom-up. The structure of the data is probably the most important factor anyhow, no matter how you code or what the qualities of the language are.