Code Budgets | Hacker News Reader

Code Budgets

danielbmarkham.com

I'll happily take on the challenge, in fact I've already done this on past projects. The "code golfing" complainers have no sense of how much a codebase can be a maintenance sink, and how you could easily attain 100-fold line reductions for some things if you just took the problem seriously and aimed towards defining languages that suit it. See VPRI's "STEPS" papers for examples.

The problem is he has defined maintenance liability as lines code. This isn't true. If your building 3d cad software it's not going to fit in 2000 lines of code no matter how hard you try. An attempt to do so will make it a maintenance nightmare.

Having an incorrect model however is a maintenance liability.

I happened to have read many of VPRI’s papers and some domain expertise in a few of their topics, or know close friends with such domain expertise. Btw, my collection of their links are at https://news.ycombinator.com/item?id=19844088

The goal is a noble one; though it's unclear to me if their research is the right way to go.

Alan Kay's gang's research's end result are often great, but their implementations are usually more geared toward prototyping rather than production. For example, the GUI innovation is great, whereas its implementation using Smalltalk is clearly geared toward faster iteration and not meant to be as competitive as a production language (let's not enter into this debate as this is another rabbit hole. Plenty of other HN threads on this). But I think so far these implementations have gotten a pass because the end result is futuristic enough for someone else to come along and implement e.g. the GUI in more production-oriented languages.

In the context of VPRI, however, the goal wasn't to create more futuristic end results, but to recreate existing result using hopefully drastically more concise paradigms and DSLs. In this case, the implementation itself is the thing we should examine, and imo they kinda fall short.

For example:

- Yes, it's very appealing that Nile can reduce the antialiasing logic by so much. Is it resilient to real world requirement changes though? Unclear (and the Nile paper still isn't out as the author seems busy with some startup).

- The OMeta parser tool is cool until you encounter more complex grammar and proper error messages (most non-hand-rolled parser tools' error messages and error recoveries are treated as secondary concerns).

- Reusing the same state machine from OMeta (afaik) for TCP is clever, theoretically sound, but likely also not shippable in production the moment you want to tweak some low-level details.

- The dynamic language used for the final product, they baked in some pretty hardcore first-class features but..., this is too long to explain, though experienced folks who read this probably know what'd happen to such language in production.

- The bulk of the final line count reduction wouldn't come from some language-related line count reduction, but from VPRI's rehash of OpenDoc, aka the end product is a Word/PowerPoint hybrid put together by massively (over)reused component. The moment such app hits the real world and a component needs to deviate from its use-case in other callsites, that amount of reuse is gonna decrease quickly. HN has plenty of comments regarding OpenDoc so we can check history here. The final use-case being an OpenDoc rehash is also slightly cheating imo. Demo a game. The line count there is a better stress test.

- Real-world perf requirements are gonna increase the line count by a lot. I understand they're employing he classic PARC strategy to "iterate as if you have the supercomputer of tomorrow, today", but plenty of languages today can already reduce their line count by a lot if perf wasn't considered.

All in all, I'm not sure VPRI's respectable goal can concretize through their method. I am however extremely on board with their goal (of shrinking the code size to be understandable by as few people as possible). Here's an alternative take on the same goal: https://www.youtube.com/watch?v=kZRE7HIO3vk and of course Casey's friend Jon Blow whose language Jai so far obsoleted a bunch of other DSLs he'd have usually needed in his workflow (https://www.youtube.com/watch?v=uZgbKrDEzAs). Now that's a more realistic way of shrinking code and simplify, imo. Between:

- a great language that can demonstrably do low to high level coding and with an in-language metaprogrammmming facility that removes the need for DSLs, and

- VPRI's opposite direction of proliferating many DSLs (which in real world are gonna cause nontrivial accidental complexities),

I'd take the former.

When you say 'defining languages', do you mean as DSLs or choosing appropriate existing languages? If DSLs, which language would you recommend for creating DSLs. Could you give a successful example?

So are we back to counting lines of code as measurement for productivity, success and cost? Does that mean someone who writes cleaner code using a bit more lines is less good than someone who writes less code but also less unreadable (assuming in many cases slightly more verbosity leads to more cleaner code).

Line budgets sounds like an awful idea. Code golf!

I'd rather have 20 lines of clear simple code then, 5 lines of dense complicated code.

Budgets will just make people write dense code.

Think there would be another metric that would be better?

E.g. a readability score for the code, one that could be composed of analyzing the cyclomatic complexity ( https://en.wikipedia.org/wiki/Cyclomatic_complexity ) and other factors that affect how easy/hard it is to read and understand it?

Or would most such attempts be deemed to fail because of how abstract code is and how hard to evaluate automatically it can be?

Lots of reasonable metrics become bad once you make them a target.

What we want could be a complexity metric corresponding to a set of lines.

I'd say that's something that could be ML-learnable with the right dataset.

Given an answer from stackoverflow, ask an average developer to identify what was the question from a set of say 5. The average time taken to provide a right answer would be the complexity score.

You could use a transformer trained on code, and make it transfer-learn a function approximating that score.

Budgets don't support anyone getting the job done. It's a business metric and serves as a halting line, early warning, decision taking line... whatsover. I dislike the KPI mindset. I prefer common sense, understanding what's really needed to deliver something reliable that behaves as expected from the customer's point of view.

Talking about the cost for a line of code is like talking about the cost for a line of blueprint design. Forcing cost evaluations for non trivial problems is like forcing a curved surface onto a plain map. It may be considered doable if admitting a high enough level of error, but it's just a pain to do it, every time.

tl;dr: The only way to limit the cost of solving a problem is to limit the LOC count allowed to the developers.

This ignores real world issues:

- It is utterly trivial to work around this one, since every popular language lets you write an abritrary amount of code in a single line. In fact, your entire application could be a single line of code, easy!

- When you enforce KPIs, the only people who will stay are the ones who agree with the KPI (code golfers) or know how to work around it (see above).

To extend this idea to its logical conclusion and work around both the issues above, why not limit the number of characters the developers can use? Because every single name in the application will be a single character, making maintenance a nightmare.

Let's continue the above list for fun:

- Automated tests are code, so they would limit the budget of production code even further.

- Infrastructure as code is out the window, for the same reason.

This is an awful idea.

This doesn’t account for the cost of dependencies (an import statement is only one line!), so this mindset would result in taking on big dependencies to limit “lines of code”.

You must be very careful about dependencies. I’d sooner take a rule to arbitrarily limit dependencies than lines of code.

I agree. I don’t think lines of code is necessarily the right thing to budget, especially if you limit it to “lines of code written by our team”.

But there is something interesting in this idea. Our software is growing immeasurably complex. We’re piling on more and more layers of abstraction. Ostensibly the goal is to make our lives easier. But in reality we’ve got companies throwing hundreds or thousands of developers at the problem of building a wiki or a social network, and they end up building these Rube Goldberg machines where 99% of the effort is spent on things other than the actual problem users want the software to solve.

Moore’s law has been totally offset by Wirth’s law[0], and as an industry I don’t see us doing anything about it. Even if lines of code is the wrong constraint, we could do with learning how to do more with less.

[0]: https://en.wikipedia.org/wiki/Wirth%27s_law

Reply on news.ycombinator.com