3 ms·

I agree that devtools should be open source, but... I very much disagree with the premise that no tools should have config files, options, or plugin systems, a

by kelnos 2mo ago

I agree that devtools should be open source, but... I very much disagree with the premise that no tools should have config files, options, or plugin systems, and instead when you want to change something like your text editor's font size, you should have an LLM download the code, change the hard-coded value, and rebuild it. That's just so inefficient and wasteful. Assuming a world in which LLMs do most of the coding work, do we want to burn electricity having the LLM build an options dialog or config file parser once, or do we want to burn electricity millions of times as users want to change any little thing about the software they use? I really hope what you should expect is my answer to that question isn't controversial. Having an LLM do bespoke customizations that are unlikely to be interesting to other people? Great, sure. But adding a generally-useful feature to a piece of software, but not caring to try to upstream it? Lame. Lame, lame, lame.

tajd 2mo ago
I completely agree - we've seen that tools with plugins are really scalable and then allow the better plugins to be folded back into the main tool where they become popular. I've taken that approach with my own dev tools that I've created.
- theshrike79 2mo ago
  And I've seen applications where the plugins are so damn complicated to make that it was easier to just make a separate tool to do that.
herrkanin 2mo ago
Without any evidence to back it up, my hope is that your criticism in a decade will be the equivalent to "Everybody having a mainframe at home? Do we want to waste a whole room in each and every house just for that?".
- arandomhuman 2mo ago
  Having an embedded scripting engine for large programs is nice for simplicity and keeping configuration modular - it would be messy to need to modify source constantly. It’s not an issue of it being difficult to compile something so much as it being pointlessly difficult to maintain.
- andersonpico 2mo ago
  do you want browser extensions to be able to modify browser code on the fly with regex? that's how you get browser extensions being able to modify browser code on the fly with regex [1] https://www.zdnet.com/home-and-office/networking/mozilla-changes-firefox-apis-developers-unhappy/?hl=en-US https://www.zdnet.com/home-and-office/networking/mozilla-cha...
bluGill 2mo ago
There are some things that should be configurable and some things that you should not be allowed to configure. Remember you are not working alone. Different people/companies work differently, but nearly every job has - at least once in a while - a time when someone will be ask your computer reading something on your screen with you. vi vs emacs is bad enough, but at least I know how to do minimal navigation, save, and exit from each (I expect that advanced users of those tools can do much more): there are only so many different systems I can learn though, and it is unfair to make everyone have to learn another. Thus emacs should not allow your to customize your environment with local scripts, either it is in base (as IT installed it), or it isn't allowed! (to my knowledge vi/vim doesn't allow this). Similar for other tools, if it isn't easy for someone who isn't an expert: either your company shouldn't allow it at all, or they need to ensure everyone is encouraged to get training (not forced in case you wouldn't do that anyway - but it should be automatic if you want it and you should know you can get it) Font size - I've worked with nearly blind people who need huge fonts just to see/read. However this is a compromise and they are worse developers for lack of ability to see as much text as a smaller font enables. Don't get me wrong, they are still great developers, but their eyes are a limit to how good they can be. It is thus reasonable to have a configurable accommodation for that. There are a number of other examples where things can be configurable, but the configurations should be controlled and easy to find. (I'm color blind, if you allow color coding that is fine so long as I can find a color that works for me)
- thewebguyd 2mo ago
  The idea that IT should lock down editor configs treats software development like a factory line where workers should be interchangeable parts. Maybe it is, but I disagree. Software is a craft, and a developer's environment is an extension o fhow they think. If pairing is hard because of someone's custom setup, the answer is to use tools designed for collaboration, not mandating a specific editor config. Check out the code locally. Personalized tools is how you eliminate friction, it'd be a misallocation of priorities to take that away. As an side, vim definitely allows user scripts.
- CamperBob2 2mo ago
  LLMs fix all of these things, in the (rare) instances where existing tooling does not.
skybrian 2mo ago
Updating a constant versus a config parameter isn’t all that different if the build is fast. I do think modularity will remain important because it makes merge conflicts less likely, and a system with good modularity could look a lot like a plugin system, except that AI can likely deal with minor compatibility breaks if it’s clear what to do. It’s a similar argument to why Linux device drivers are in-tree. If there are API changes then the AI fixes the callers. Compile-time checks are good because it’s direct feedback to the AI.
- hahahaa 2mo ago
  But you now have a fork. Main branch gets refactored you have a merge conflict.
- danbruc 2mo ago
  Updating a constant versus a config parameter isn’t all that different if the build is fast. Not even remotely true except that in both cases you change a number in some text file. If you do it in source code, you have to get the source code, you have to identify the correct line[s], you need a build environment, you might have to reinstall the new version after the build. And on top of this you want to involve a language model in this. The difference in complexity, effort, and resource consumption is orders of magnitude. And we are not even considering that you will have to go through this for each future version to keep your modification included. This is an insane way to change a font size.
  - 1718627440 2mo ago
    > you need a build environment If you have a self-sufficient OS, the build environment is already part of it. > you have to identify the correct line[s] Just run a full-text search on the old value.
    - danbruc 2mo ago
      Just run a full-text search on the old value. How often does 10 appear in the code base? And is the value you are looking for even 10 or does only the UI show 10 points but in code it is defined as 200 twip?
wilsonnb3 2mo ago
Even pre-LLM this is how suckless tools work, I actually don’t much mind having to edit a variable in a header and recompile when you make a config change. https://dwm.suckless.org/customisation/ https://dwm.suckless.org/customisation/
- nananana9 2mo ago
  Only for trivial programs - I don't mind running make on a 2500 line C program, I would mind having to recompile LLVM or Firefox.
  - ajsnigrutin 2mo ago
    Firefox is a nice example of a human-managable set of preferences in the 'settings', and "about:config" for everythig else 'those few users' might need (without the need to reompile)
- pjmlp 2mo ago
  Which is why many of us happily ignore their existence.
- ironhaven 2mo ago
  Suckless software does have config files they just have a “.h” extension Having your config file be a c header and needing a recompile is different than not having any user accessible configuration
benoau 2mo ago
The real waste is that tweaking a config setting is a one-and-done deal, I don't want my tools to be side projects that require maintaining their build chains and frequent customization even if an LLM is doing the heavy-lifting.
deleted 2mo ago
[deleted]
deleted 2mo ago
[deleted]

by kelnos 2mo ago

tajd 2mo ago

I completely agree - we've seen that tools with plugins are really scalable and then allow the better plugins to be folded back into the main tool where they become popular. I've taken that approach with my own dev tools that I've created.

theshrike79 2mo ago
And I've seen applications where the plugins are so damn complicated to make that it was easier to just make a separate tool to do that.

herrkanin 2mo ago

Without any evidence to back it up, my hope is that your criticism in a decade will be the equivalent to "Everybody having a mainframe at home? Do we want to waste a whole room in each and every house just for that?".

arandomhuman 2mo ago
Having an embedded scripting engine for large programs is nice for simplicity and keeping configuration modular - it would be messy to need to modify source constantly. It’s not an issue of it being difficult to compile something so much as it being pointlessly difficult to maintain.
andersonpico 2mo ago
do you want browser extensions to be able to modify browser code on the fly with regex? that's how you get browser extensions being able to modify browser code on the fly with regex [1] https://www.zdnet.com/home-and-office/networking/mozilla-changes-firefox-apis-developers-unhappy/?hl=en-US https://www.zdnet.com/home-and-office/networking/mozilla-cha...

bluGill 2mo ago

There are some things that should be configurable and some things that you should not be allowed to configure. Remember you are not working alone. Different people/companies work differently, but nearly every job has - at least once in a while - a time when someone will be ask your computer reading something on your screen with you. vi vs emacs is bad enough, but at least I know how to do minimal navigation, save, and exit from each (I expect that advanced users of those tools can do much more): there are only so many different systems I can learn though, and it is unfair to make everyone have to learn another. Thus emacs should not allow your to customize your environment with local scripts, either it is in base (as IT installed it), or it isn't allowed! (to my knowledge vi/vim doesn't allow this). Similar for other tools, if it isn't easy for someone who isn't an expert: either your company shouldn't allow it at all, or they need to ensure everyone is encouraged to get training (not forced in case you wouldn't do that anyway - but it should be automatic if you want it and you should know you can get it) Font size - I've worked with nearly blind people who need huge fonts just to see/read. However this is a compromise and they are worse developers for lack of ability to see as much text as a smaller font enables. Don't get me wrong, they are still great developers, but their eyes are a limit to how good they can be. It is thus reasonable to have a configurable accommodation for that. There are a number of other examples where things can be configurable, but the configurations should be controlled and easy to find. (I'm color blind, if you allow color coding that is fine so long as I can find a color that works for me)

thewebguyd 2mo ago
The idea that IT should lock down editor configs treats software development like a factory line where workers should be interchangeable parts. Maybe it is, but I disagree. Software is a craft, and a developer's environment is an extension o fhow they think. If pairing is hard because of someone's custom setup, the answer is to use tools designed for collaboration, not mandating a specific editor config. Check out the code locally. Personalized tools is how you eliminate friction, it'd be a misallocation of priorities to take that away. As an side, vim definitely allows user scripts.
CamperBob2 2mo ago
LLMs fix all of these things, in the (rare) instances where existing tooling does not.

skybrian 2mo ago

Updating a constant versus a config parameter isn’t all that different if the build is fast. I do think modularity will remain important because it makes merge conflicts less likely, and a system with good modularity could look a lot like a plugin system, except that AI can likely deal with minor compatibility breaks if it’s clear what to do. It’s a similar argument to why Linux device drivers are in-tree. If there are API changes then the AI fixes the callers. Compile-time checks are good because it’s direct feedback to the AI.

hahahaa 2mo ago
But you now have a fork. Main branch gets refactored you have a merge conflict.
danbruc 2mo ago
Updating a constant versus a config parameter isn’t all that different if the build is fast. Not even remotely true except that in both cases you change a number in some text file. If you do it in source code, you have to get the source code, you have to identify the correct line[s], you need a build environment, you might have to reinstall the new version after the build. And on top of this you want to involve a language model in this. The difference in complexity, effort, and resource consumption is orders of magnitude. And we are not even considering that you will have to go through this for each future version to keep your modification included. This is an insane way to change a font size.
- 1718627440 2mo ago
  > you need a build environment If you have a self-sufficient OS, the build environment is already part of it. > you have to identify the correct line[s] Just run a full-text search on the old value.
  - danbruc 2mo ago
    Just run a full-text search on the old value. How often does 10 appear in the code base? And is the value you are looking for even 10 or does only the UI show 10 points but in code it is defined as 200 twip?

wilsonnb3 2mo ago

Even pre-LLM this is how suckless tools work, I actually don’t much mind having to edit a variable in a header and recompile when you make a config change. https://dwm.suckless.org/customisation/ https://dwm.suckless.org/customisation/

nananana9 2mo ago
Only for trivial programs - I don't mind running make on a 2500 line C program, I would mind having to recompile LLVM or Firefox.
- ajsnigrutin 2mo ago
  Firefox is a nice example of a human-managable set of preferences in the 'settings', and "about:config" for everythig else 'those few users' might need (without the need to reompile)
pjmlp 2mo ago
Which is why many of us happily ignore their existence.
ironhaven 2mo ago
Suckless software does have config files they just have a “.h” extension Having your config file be a c header and needing a recompile is different than not having any user accessible configuration

benoau 2mo ago

The real waste is that tweaking a config setting is a one-and-done deal, I don't want my tools to be side projects that require maintaining their build chains and frequent customization even if an LLM is doing the heavy-lifting.

deleted 2mo ago

[deleted]

deleted 2mo ago

[deleted]