[dead]
Devtools must be open source
241–250 of 262 posts
Re: Devtools must be open source
#242One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I think LLMs have changed…
I have vibe-modified quite some software I use daily.
- Podcast app (removed nags, ads, added some stats and filters I wanted).
- notepad. After windows added copilot to notepad I deleted it. Then i took some simple notepad app from github and added the few features I care about.
- android voice keyboard
And the biggest win was taking Wezterm and having claude build Lua scripts for the features I'm missing
Re: Devtools must be open source
#243One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I think LLMs have changed…
> The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often.
That's not quite right. It's always developers who make the changes, just those who care strongly enough to dedicate their time. Open source (or in a limited sense an extension framework), allows these developers to share their updates with a wider audience. If the tool evokes strong emotions, the pool can be quite large.
While it may seem like I'm nitpicking, my point is this: There is no external benevolent entity as your statement implies. Rather it's just a fellow developer who cares enough to evolve the tool long beyond it's lifecycle.
Re: Devtools must be open source
#244Everything is now open-source by default. All features are replicable. I don’t really care that much any more that tools need to be OSS because I can make my copies when I want. And I do when I so desire. Your feature page is your source code.
Your idea is my source code.
Absolutely. It’s all an execution and distribution problem now.
Re: Devtools must be open source
#245One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I think LLMs have changed…
> the freedom is more about being able to lean on other people to do that Alternately: The collective capability is what makes important lasting changes, but individual capability is still a required building-block to get there. Much like freedom of speech, come to think of it.
Very well put.
Re: Devtools must be open source
#246Earlier quoted context omitted.
> Then you’re maintaining a stack of patches on top of the upstream until the end of time The linked article has an ambitious solution for that, in the form of this prompt to a coding agent harness: Set up a nightly cron job that executes the prompt: fetch upstream changes to the and rebase all local changes on top of upstream. Check that the software works as intended and replace the current version.
That's not a solution, just the necessary work. You still have a stack of patches you continuously have to (have) rebase(d) on upstream.
There are software tools like quilt, who do exactly that.
Re: Devtools must be open source
#247Earlier quoted context omitted.
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 a…
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 lan…
> 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.
Re: Devtools must be open source
#248I 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…
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, an…
Vim and neovim are highly configurable. Indeed, they have scripting and plugins too. Same for Kakoune, which uses KakouneScript instead of vimscript. Vis uses Lua. Micro is sort of Vim-ish, and it is scriptable with Lua.
Cream and SpaceVim are not separate editors, but sets of configs and plugins to provide a much different experience from stock Vim or neovim.
Re: Devtools must be open source
#249I 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…
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 a…
> if the build is fast.
...and the build doesn't require any tools that aren't already on your machine, and there are no dependencies to download
Many of the best tools I use are written in languages I don't program in and thus I don't want the build tools and package caches for those languages taking up space on my drive. I'll take the config file any day.
Re: Devtools must be open source
#250One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I think LLMs have changed…
The language I use at work has one formatter with zero configurability. This is a good thing. It has had a long open issue on github: allow users to put an import statement anywhere in the source code (not in the middle of a function, but between functions) and have it move up to the import section at the top of the file. This is syntactically invalid if left unformatted; you can't have imports after the first definition. I'd talked to the program's creator and he said it was going to be a high effort change because the formatter is a fork of the compiler, and the compiler first considers imports before switching to considering function declarations.
I gave problem to Claude and went and did yard work. It handled it in one shot, including writing tests that I could understand and be satisfied that it works. The PR implementing this remains open and that's fine; it's a lot to ask a maintainers to take responsibility for code I don't fully understand. I don't want to lean on them! But now I use my modified version of the formatter, and I think some people at work do too. It's an amazing era for "give me this feature why not?"