Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Devtools must be open source

blog.exe.dev

Post reply on HN
Print view View original

21–30 of 262 posts

Re: Devtools must be open source

#21

Post by bluGill »

kelnos wrote: post #4

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…

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)

Re: Devtools must be open source

#22

Post by toplinesoftsys »

Like everything else, modifying code of open-source tools has its cons and pros. The biggest advantage is of course an ability to customize the tool exactly to your needs. The problem is that it makes patching and upgrading impossible. This is the reason plugins exist - they do not break ability to patch the host product. So, if customization cannot be avoided even at the cost of losing ability to patch/upgrade - that would definitely work. Otherwise, plugins is probably the best approach.

Re: Devtools must be open source

#23

Post by zdragnar »

simonw wrote: post #3

One 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…

> One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works.

The canonical example was RMS needing to fix a printer driver bug back before software updates were really a thing. That meant that there was a greater motivation for users to maintain their changes.

Today, with software being an evergreen stack of turtles from the BIOS all the way up the OS to the remote APIs the qpp interacts with, expecting a user to indefinitely maintain their private fork of any software is a really big stretch.

Unless it is a local-only, unmaintained project that doesn't get deployed through a software repository or an app store, I think that original vision of open source software is very much the exception and not the rule.

Re: Devtools must be open source

#24

Post by andersonpico »

herrkanin wrote: post #8
kelnos wrote: post #4

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…

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?".

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-cha...

Re: Devtools must be open source

#25

Post by skybrian »

kelnos wrote: post #4

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…

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.

Re: Devtools must be open source

#26

Post by indigodaddy »

2190asfg wrote: post #11

Company that resells openclaw and closed providers preaches about open source. The new personalization talking point appears to be coordinated. It is all over the Internet since last week. Problem is, 99.99% of people (including developers) do not need "personalized" software, unless you mean Emacs style.

Resells OpenClaw? What are you on about? and exe has no markup through their LLM gateway. Maybe educate yourself before talking smack about an awesome little company and platform like exe.dev.

Re: Devtools must be open source

#27

Post by firasd »

I think there is an argument to be made for how this benefits projects too, like if you want distribution then be as unencumbered as possible.

I've been making a couple little utils like a Clock for AI with an open public endpoint [https://github.com/firasd/mcpclock], a text file sampler [https://github.com/firasd/vblinds] and I was noticing the MIT license seems too encumbered with the requirement to keep crediting authors downstream so I used the 'Unlicense' public domain license

(CC-0 seems to be side-eyed by open source orgs cause it preserves patent rights)

Re: Devtools must be open source

#28

Post by nextblock »

Open-sourced doesnt have to be free either. There's always the very good GNU Affero General Public License 3 (AGPL-3) and others. I think most developers want open-source for transparency. We want to know what we are downloading.

Re: Devtools must be open source

#29

Post by thewebguyd »

bluGill wrote: post #21
kelnos wrote: post #4

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…

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…

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.

Re: Devtools must be open source

#30

Post by davidw »

It's a bit ironic to talk about key parts of the toolchain being open source while making black-box, closed source LLM's, controlled by external companies an integral part of all of it.
Post reply on HN