8 ms·

This is all about the tooling most companies choose when building software: Things with more than enough boilerplate most code is trivial. We can build tools th

This is all about the tooling most companies choose when building software: Things with more than enough boilerplate most code is trivial. We can build tools that have far less triviality and more density, where the distance between the code we write and business logic is very narrow.. but then every line of code we write is hard, because it's meaningful, and that feels bad enough to many developers, so we end up with tools where we might not be more productive, but we might feel productive, even though most of that apparent productivity is trivially generated. We also have the ceremonial layers of certain forms of corporate architecture, where nothing actually happens, but the steps must exist to match the holy box, box cylinder architecture. Ceremonial input massaging here, ceremonial data transformation over there, duplicated error checking... if it's easy for the LLM to do, maybe we shouldn't be doing it everywhere in the first place.

thfuran 2y ago
>but then every line of code we write is hard, because it's meaningful, and that feels bad enough to many developers, I don't know that I've ever even met a developer who wants to be writing endless pools of trivial boilerplate instead of meaningful code. Even the people at work who are willing to say they don't want to deal with the ambiguity and high level design stuff and just want to be told what to do pretty clearly don't want endless drudgery.
- Aeolun 2y ago
  That, but boilerplate stuff is also incredibly easy to understand. As compared to high density, high meaning code anyway. I prefer more low density low meaning code as it makes it much easier to reason about any part of the system.
  - wruza 2y ago
    So basically it’s a presentation problem. We want to control code at the call site, boilerplate helps with that by being locally modifiable. We also want to systematize chunks of code so that they don’t flicker around and mess with a reader. We wanted this since forever and no one does anything because anything above simple text completion is traditionally seen as an overkill, not the true way, not unix, etc. All sorts of stubborn arguments. This can be solved by simply allowing code trees instead of lines of code (tree vs table). You drop a boilerplate into code marked as “boilerplate ‘foo’ {…}” and edit it as you see fit, which creates a boilerplate-local patch. Then you can instantly see diffs, find, update boilerplates, convert them to and from regular functions, merge best practices from boilerplate libraries, etc. Problem solved. It feels like the development itself got collectively stuck in some stupid principles that no one dares to question. Everything that we invent stumbles upon the simple fact that we don’t have any sensible devtime structure, apart from this “file” and “import file” dullness.
  - thfuran 2y ago
    In and of itself, it's usually easy to understand. But the more fluff you stuff between the nontrivial bits, the harder it is to take in all at once. I think large quantities of simple boilerplate make the overall project harder to understand and debug. Though that is in comparison to an imagined alternative that's somehow exactly the same but with all the glue removed, so maybe that's not entirely fair.
codr7 2y ago
I think you just nailed the paradox of Go's popularity among developers, managers are obvious.

thfuran 2y ago

>but then every line of code we write is hard, because it's meaningful, and that feels bad enough to many developers, I don't know that I've ever even met a developer who wants to be writing endless pools of trivial boilerplate instead of meaningful code. Even the people at work who are willing to say they don't want to deal with the ambiguity and high level design stuff and just want to be told what to do pretty clearly don't want endless drudgery.

Aeolun 2y ago
That, but boilerplate stuff is also incredibly easy to understand. As compared to high density, high meaning code anyway. I prefer more low density low meaning code as it makes it much easier to reason about any part of the system.
- wruza 2y ago
  So basically it’s a presentation problem. We want to control code at the call site, boilerplate helps with that by being locally modifiable. We also want to systematize chunks of code so that they don’t flicker around and mess with a reader. We wanted this since forever and no one does anything because anything above simple text completion is traditionally seen as an overkill, not the true way, not unix, etc. All sorts of stubborn arguments. This can be solved by simply allowing code trees instead of lines of code (tree vs table). You drop a boilerplate into code marked as “boilerplate ‘foo’ {…}” and edit it as you see fit, which creates a boilerplate-local patch. Then you can instantly see diffs, find, update boilerplates, convert them to and from regular functions, merge best practices from boilerplate libraries, etc. Problem solved. It feels like the development itself got collectively stuck in some stupid principles that no one dares to question. Everything that we invent stumbles upon the simple fact that we don’t have any sensible devtime structure, apart from this “file” and “import file” dullness.
- thfuran 2y ago
  In and of itself, it's usually easy to understand. But the more fluff you stuff between the nontrivial bits, the harder it is to take in all at once. I think large quantities of simple boilerplate make the overall project harder to understand and debug. Though that is in comparison to an imagined alternative that's somehow exactly the same but with all the glue removed, so maybe that's not entirely fair.

codr7 2y ago

I think you just nailed the paradox of Go's popularity among developers, managers are obvious.