• Posts
  • RSS
  • ◂◂RSS
  • Contact

  • Programming: Repurposeability

    February 23rd, 2009
    programming, repurposeability  [html]
    How much needs to be changed when you find out the problem you thought you were solving differs substantially from the actual problem? Programmers complain about this all the time, generally when it's not their fault. A manager comes in telling you that some cost you thought was negligible isn't. A client finally sees a prototype and tells you you've conflated two similar but crucially distinct categories. It's easy to say "stupid non technical people -- can't they tell me what they really want from the start?", but its not always someone else's fault, and this fixes nothing.

    Given that we are always constructing models of problems and nearly always must begin before our understanding is total, times when we must repurpose our code are unavoidable. Then this presents a metric for evaluating a programming style or language: repurposeability. That is, when one writes code in this fashion and finds out that one was solving the wrong problem, how much work is needed to repurpose it to solve the problem one should have been solving all along?

    Repurposability is the driving force behind many aspects of good coding style. The avoidance of duplicate code, for example. Say you need to send some debugging output to a file instead of standard output. In java you might have a gui program with hundreds of calls to "System.out.writeln()" that really should be calls to some debug function. So this is a programming style issue. It is also a programming language issue, though. In common lisp one might deal with this problem with a statement equivalent to "in the code called from here, substitute this object for System.out". Similarly in java, you might have hundreds of reads and writes to the object attribute "Foo.bar". The standard arguments for java tell you to make them be to "Foo.setBar()" and "Foo.getBar()" instead, so if you later change your mind you don't have to change all those references to "Foo.bar". The advice is so to maximize repurposeability. But in python one would solve the same problem by using Foo.bar all along and taking advantage of the ability to wrap it in getters and seters later if needed.

    I need to think more about what is needed for repurposeability, but it certainly sounds like a useful metric.

    Comment via: facebook

    Recent posts on blogs I like:

    Randal O’Toole Gets High-Speed Rail Wrong

    Now that there’s decent chance of US investment in rail, Randal O’Toole is resurrecting his takes from the early Obama era, warning that high-speed rail is a multi-trillion dollar money sink. It’s not a good analysis, and in particular it gets the reality…

    via Pedestrian Observations May 12, 2021

    Collections: Teaching Paradox, Europa Universalis IV, Part II: Red Queens

    This is the second part in a series (I) that examines the historical assumptions behind Paradox Interactive’s grand strategy computer game set in the early modern period, Europa Universalis IV (EU4). Last time, we took a look at how EU4 was a game fundame…

    via A Collection of Unmitigated Pedantry May 7, 2021

    Books and websites on babies

    Several people I know are expecting a first baby soon, and I wrote up notes for one of them. Might as well share here too: Medical:Scott Alexander’s Biodeterminist’s Guide to Parenting is an interesting read, and some parts are actionable.  If you live in…

    via The whole sky April 14, 2021

    more     (via openring)


  • Posts
  • RSS
  • ◂◂RSS
  • Contact