Code bloat

“Back when I was starting out in computer science I thought by today we’d be writing a few lines of code to accomplish much. Instead, we write hundreds of thousands of lines of code to accomplish little.” — Lispian

14 thoughts on “Code bloat

  1. Such blasphemy! The referenced article seems to disparage object oriented programming.

    I develop an application on top of an object oriented framework with lots of poorly documented classes – Dijkstra’s complaint about “goto” programming is nothing compared to this “where from?” programming. When it breaks somewhere in the framework there is no clue as to why it is where it is.

  2. Part of the problem with frameworks is that they try to be all things to all people. As I argue here, when a framework tries to go from a 90% solution to a 99% solution, the cost may go up 10x and the bug count 100x.

    A focused, modest framework can be great. But such modest frameworks are usually called “libraries” rather than frameworks.

  3. I think ‘lines’ should be replaced by ‘statements’, but that’s probably obvious.

    The problem with thinking you could write a few statements to accomplish much is what you mean by ‘accomplish’. A one-liner script can invoke a mighty app, accomplishing much, but I think few programmers would see it as much of an accomplishment. On the other hand, imagine a program in accomplitopia like this:


    Sure, it is one line, but what could you possibly expect for the output?

    To quote the Devil’s DP Dictionary regarding defaults, which quotes King Lear, “Nothing will come of nothing: speak again.”

    Back in the day, decomposing a monster matrix was a big accomplishment; these days we can do it in one line, but I doubt many would see it as accomplishing much.

  4. Randy A MacDonald

    I would prefer to write it as

    anArticle←WriteJournalArticleFromAnalysis Analyze MyData ”

    Most platforms might crush under the “weight” of MyData being anything more than a single value, not to mention “anArticle”.

    The logic the poster gives might also be used to downplay the significance of MapReduce, which I would downplay as well but for reasons that APL gave me.

    r ← (⌈MapReduce foo) sources ⍝ show the largest ‘foo’ value of all the data sources.

  5. Randy A MacDonald

    So it’s bloat(cycle)… meaning multiplication and division, and most floating point ops are bloat. Hmmm.

  6. Some of the bloat arises, I believe, from the “efficient business” habit of building new systems by slapping together existing and ill-suited libraries and packages to achieve something new. Sure, that’s the model of the Unix and Powershell, but their primitives combine well. Often, units in this slapping together do things which need to be undone later, and are not terribly well tested individually.

    There are exceptions. I have found R packages to be, on the whole, really well done, and I generally trust them, even if anybody doing the quantitative needs to keep a skeptical eye. There are exceptions to this in R but they are vastly outnumbered by awesome packages, like Professor Frank Harrell’s Hmisc and Design.

  7. Mathematica allows you to achieve astonishing feats with little code. That, however, only when you look at it as a programming language and get to learn it. Most kids just use it as a very expensive calculator, to do things they could do in excel.

  8. Alex: I’m very impressed with Mathematica. I think one reason it lets you do so much with little code is that things compose easily. Nearly everything you expect to be able to do works.

  9. Indeed, once you get in tune with it, it is quite natural. Sometimes I get the feeling that only imagination sets the limits of Mathematica. Usually if it cannot do something it is because you don’t expect it to.

  10. human mathematics

    R allows me to do much with few lines of code.

    I guess lispian is talking about Web apps. Well it’s not the language’s fault if what people try to do with it is of low value, or if the language is not tuned to the purpose. It may not be the language’s fault if what people write is unclear.

    John, I agree with what you said in comment #4. That’s worth a higher place on the page.

    Lastly, surely readability is a goal besides length.

  11. @human mathematics,

    I have found that, just as in an engineering context or commercial context where most of your colleagues don’t understand some of the subtleties of statistics, there is also a need to adjust a coding style to match theirs. Thus, my default way of writing R is to use things like sapply, lapply, and pmin heavily. But, if I need to sketch an algorithm for someone to use to, say, calculate a robust mean and standard deviation, I’ll leave the loops in.

    That adjusting for my environment is something I’ve had to struggle with over the past couple of years. I can explain, or try to, but people’s interests, attention spans, and time are not unlimited, and it’s challenging to try to express why variability in a large sample needs to be considered, why small sample sizes can make proportions nonsensical, or why the bootstrap works — but there are exceptions where it doesn’t.

Comments are closed.