Untitled attachment

Notices where this attachment appears

1. Embed this notice
   𒀭𒂗𒆠 ENKI ][e (enkiv2@eldritch.cafe)'s status on Friday, 14-Jul-2023 19:05:27 JST 𒀭𒂗𒆠 ENKI ][e

   in reply to

   @mnl @clacke

   Code-monkey ecosystems are extremely complex, but they are complex in a trivial way that could be solved by better tooling. Better tooling would necessarily obviate the existing code in the organization, but such organizations IMO should not exist.

   So, I think we're talking about different scales.

   Like, working for a company, we're all trapped writing bad code. There's no choice. And a company would not be able to adopt humane tooling, because capitalization is inherently inhumane. If you're not willing to blur the boundary between non-technical end user and expert developer, then tooling improvements are always going to be incremental. Somebody who's working for a paycheck is justified in not caring about more than management's metrics. It drives me nuts for aesthetic reasons, but in a case like mine (writing code that shouldn't exist, for a task that should never be performed, to support an industry that should be abolished) it's probably better for the world if the code I write is broken.

   My main concern is that, if using LLMs to code becomes widespread, it's going make it even harder for new, convivial tools to gain traction. Already, the most interesting work in tooling is being done by individuals and very small groups, mostly in isolation, and the people who would benefit most from them are unable to use them because they never get the opportunity to hear about them, are discouraged from learning about them, and would be forbidden from using them for most of their waking hours. LLMs promise to multiply how often the most common ways of doing the most common tasks are performed with the most common third party libraries.

   Generating code is very tempting, when you're stuck with a language and a set of libraries that is tedious to work with. But the generated code still takes up bytes, and still needs to be maintained; on top of that, you've burned a bunch of cycles in generating code that wouldn't have been burned writing it. It is better to structure the tools in such a way that your tasks are not tedious, or use tools that are a better fit for the task. But it's easier to ignore the severity of these problems when code generators are used. This is not a problem specific to LLMs: IDEs that generate boilerplate for you, the layers of languages and template generators in autotools, and now even a lot of web development technology, all follow the general pattern of standardizing on a language that is unnecessarily bloated and awkward and then using code generators to hide the bloat rather than eliminating it. And it's much faster to write a code generator than to do the design & architectural work necessary to figure out how to make a tool that is a joy to use. Generating code also solves the compatibility problem: for social (rather than technical) reasons, you're stuck doing certain things in certain ways, and code generators can hide that too (until it breaks). So, it's extremely tempting!