| ▲ | kelnos 6 hours 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 6 hours ago | parent | next [-] | |||||||||||||||||||
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. | ||||||||||||||||||||
| ▲ | wilsonnb3 4 hours ago | parent | prev | next [-] | |||||||||||||||||||
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. | ||||||||||||||||||||
| ||||||||||||||||||||
| ▲ | skybrian 5 hours ago | parent | prev | next [-] | |||||||||||||||||||
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. | ||||||||||||||||||||
| ▲ | benoau 4 hours ago | parent | prev | next [-] | |||||||||||||||||||
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. | ||||||||||||||||||||
| ▲ | herrkanin 6 hours ago | parent | prev | next [-] | |||||||||||||||||||
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?". | ||||||||||||||||||||
| ||||||||||||||||||||
| ▲ | bluGill 5 hours ago | parent | prev [-] | |||||||||||||||||||
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) | ||||||||||||||||||||
| ||||||||||||||||||||