1. 19
  1. 5

    An interesting case in point is the textadept editor. Its author has self-imposed a limit like this.

    Reading the article immediately makes me think of possible ways to game this limit. In particular, I’m not quite sure how to distinguish library or compiler code lines from “main app” lines. How about test lines? Or does splitting a long string over many lines for readability count to this limit? Finally, does this try to suggest that using APL is inherently better than any other language? So, the idea and general thought is rather interesting, however it seems to me “not fully there yet”, still wanting some further exploration.

    1. 4

      Some thoughts:

      • Perhaps the budget could be expressed in other size-adjacent terms. It could be things like the size of the .gzipped source of the program and it’s dependencies. It could also be programming language specific, applying less cost to comments, and more to conditionals, for example. I think there’d need to be some research done here.
      • I think it might make sense to cost some languages more than others, I think CSS is “cheaper” than Javascript for example. Browser devs might actually have better intuitons here than mode.

      There is an upper limit to how much can be done in X lines of code. You won’t be able to, for example, make Super Metroid fit on the PICO-8. There’s just not enough memory available. So ultimately, a conversation about budgeting lines of code also becomes one about keep scope under control.

      1. 2

        Good point. Thanks.

        My strategy in limiting it to budgets was that the budget idea, if accepted, would drive-out other conversations such as scoping — otherwise they’d never occur. Assuming the budget is absolute, if you’re running over budget, why? To me that was really the more interesting discussion than budgets in the first place.

        There’s a scoping conversation/essay that I didn’t include here. I will eventually write an essay on that (because I feel it’s a separate topic) and make the cross-links. It didn’t occur to me that folks might game it. How could I forget Wally writing himself a new minivan?

      2. 3

        I like the idea of using a code budget as a form of startup capital. Giving an engineering team a few weeks to test something out but also giving them a code/service budget of 1000-100-10 or whatnot.

        1. 2

          Good sentiment. The way I always think about this is that (and the article says this):

          1. Users get value from features, not code.
          2. Code costs resources.
          3. Thus, to maximize a fixed feature set’s profit, minimize code.
          1. 2

            Writing truly reusable components is hard. Integrating libraries or frameworks is also typically hard–unless the library is truly simple or truly familiar (leftpad was the former, a regex library might be the latter).

            So I think this is an interesting thought experiment, but like writing a book without the letter ‘e’, it’s not a rule that you can follow to make your overall work better. Omit words, delete code, live minimally–sometimes. But also add words, write code and buy kitchen gadgets when they’ll serve an important purpose. There’s no substitute for case by case judgment about what you should do in each specific instance.

            1. 3

              Writing a book without a given plot, or without Deus Ex Machina, might make your overall work better.

              Expressing a complicated idea without any major domain specific vocabulary words and within a page can drastically improve the effect and reach of the work.