Hacker News new | comments | show | ask | jobs | submit login

The problem is that the simple and quick solution has to be hacked around when the problem set changes and that's how we get all these hacks.



A thousand times no. It's what we do when the problem set changes that causes trouble. We only ever respond one way: by agglutinating more code with the old. Compound this a few times and you have irreversible complexity. It's what would happen in a neighborhood if you called garbage "construction material" and only ever piled it up all around you.

The solution is to delete nearly as much code as we write. Put differently, the solution is small programs, ruthlessly pursued. The reason we don't do this is that it's totally absent from (nearly all) software culture -- absent as in blank stares and why-you-talk-crazy-talk if you bring it up -- and by far the number one determinant of what people do is what other people do.

There are a few points of light. Chuck Moore and Arthur Whitney come to mind. From everything I've heard, their programs are small enough not to have these problems. And in case anyone is wondering "If this is so much better how come we don't all work that way?" - the answer to that conundrum hit me the other day: sample size. Statistically speaking, it's never been tried.


Thanks for the Arthur Whitney reference, I had not previously been aware of his work although I fiddled about with APL to teach maths years ago and have always liked the 'executable notation' idea.

http://queue.acm.org/detail.cfm?id=1531242

    BC Is that advice you would give to practitioners: to throw out more?
    AW Yes, but in business it's hard to do that.
    BC Especially when it's working!
    AW But I love throwing it all out. 
It strikes me (as a non-programmer) that Moore and Whitney are working in well defined problem spaces. 'The art of the soluable' by Peter Medawar springs to mind (about scientific method).


I'm glad you looked that up. More people need to know about Whitney. I wish he would open-source his work so we could learn from it.

But why do you say they are working in well-defined problem spaces? No more well-defined than most, I would have thought. Certainly Moore was a pioneer of iterative development and evolving a program (and notation) in the direction of the problem. That's why he invented Forth in the first place.

Edit: Oh, having looked up the Medawar reference I realize you probably mean "well-defined problem space" in the way a mathematician would: a problem space narrow enough to be effectively studied but rich enough to produce meaningful results. Certainly most software projects do not start out in such a space. On the other hand, we don't try to learn enough about our problems to find such spaces. We merely add code. One might almost say we excrete it.


Sorry, yes, I'm not a coder. Whitney is dealing with financial data sets of impressively huge sizes but he (to my limited knowledge) clearly understands the structure of the data and a range of queries at a deep level. Moore looks as if he his devising the hardware to run the code!


Too true. It sometimes feels like programming is about trying to glue a bunch of hacks together creating yet another hack. Then someone standardises said conglomeration of hacks. Repeat.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: