Live data from Hacker News

Devtools must be open source

blog.exe.dev

121–130 of 262 posts

Re: Devtools must be open source

#122
post #108

Earlier quoted context omitted.

I suspect the people advocating for this don't actually do this, its one of those things that you say because it sounds modern and up to date, and makes for a good sounding blogpost. The actual reality of any of what they're talking about is absolutely terrible Even just the cost of this would be a disaster, especially once everything goes to token based pricing

Some people even claim that they don't commit the code into source control, only the prompts. The best part about the internet is that you can publish any random shower thought.

Around 2020 I started getting downvoted for predicting that while the most popular programming languages at the time were Python, Java, and JavaScript, or whatever they were, the most popular programming languages in 2035 would be English and Mandarin.

Looks more like 2030, after all. So the downvoters had a point.

Re: Devtools must be open source

#123
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…

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/

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

Re: Devtools must be open source

#124
post #111

Earlier quoted context omitted.

What a boringly reductive take. It's not like hackernews is some amazing bastion of like, optimism and culture and interesting conversation, but surely we can do better than this?

HackerNews, the site when someone posts about their business for developer tooling, there is always a bunch of folks posting links about half implemented alternatives, because who wants to pay for tooling like any other professionals?

This is also completely self inflicted. This is one of the only professions that does not want to pay for their tools and will do anything to get it for free, including building it themselves.

So this is quite unsurprising that open source developers have become this decade's new starving artists asking for donations for their "free software" only for a coding agent to do it for close to $0.

Re: Devtools must be open source

#126
post #108

Earlier quoted context omitted.

I suspect the people advocating for this don't actually do this, its one of those things that you say because it sounds modern and up to date, and makes for a good sounding blogpost. The actual reality of any of what they're talking about is absolutely terrible Even just the cost of this would be a disaster, especially once everything goes to token based pricing

Some people even claim that they don't commit the code into source control, only the prompts. The best part about the internet is that you can publish any random shower thought.

I don't even commit the prompts. I just commit the one prompt which says "do what the customer wants. ask when more information is required."

Re: Devtools must be open source

#127
post #79
post #15

> 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. This sounds like hell. You have unreliable actor redoing the software every night, and every day there is a chance you wake up and find your workflow broken. And no, "Check that the software works as intended" is…

I don’t auto-rebase but I definitely vendor in and choose to update on my own cadence.

yeah, vendor in is the only way to stay sane over time, if you understand the cost of dependencies (and have a reasonable security model). And forking some Python or Go dep on Github and using that instead of the canonical one is pretty ergonomic. I don't know how Rust folks manage with so many dependencies via Cargo - my friend who loves Rust says they are smaller and more "one thing done well" but the complexity of hundreds or thousands of deps just scares me.

Re: Devtools must be open source

#128
post #108

Earlier quoted context omitted.

I suspect the people advocating for this don't actually do this, its one of those things that you say because it sounds modern and up to date, and makes for a good sounding blogpost. The actual reality of any of what they're talking about is absolutely terrible Even just the cost of this would be a disaster, especially once everything goes to token based pricing

Been doing it for the past several weeks. It is no longer correct to say that LLMs can't/don't/won't exercise reasonable aesthetic judgement on the finished product. Immense progress in this area has been made recently. If you want the model to maintain a certain look and feel, or to preserve the UX in other ways, tell it . Even if it doesn't get it 100% right today, the direction of progress is pretty clear, so you…

This doesn't appear to relate to the conversation at all, because we aren't talking about generating entire products. Is this just generic AI advertising?

Re: Devtools must be open source

#129
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…

Yeah I think this is changing, fast. 100% agree on "clone X and tell me how it works". I'd also add: "clone X and see how it does Y; use that as design reference for building feature Z" if licenses permit. On modifying software... I forked codex in ~Dec and had my own lightweight "plan mode" and a few other things. It was fun and satisfying, but it ended up being a bit of a pain to keep updated. The models were less…

How are you handling the actual provisioning of the agent boxes/VMs? Are you using a specific provider/cloud, or multi-provider? Are there any providers/clouds you've found are better/worse for your use cases?

Asking because I am working on an open/standard protocol/layer for provisioning cloud resources across different providers. One of the ideas is to provide a marketplace of providers/resources via one unified/standard API, which I would allow automatic selection and provisioning of VMs (and other resources) based on price/value/feature/reputation requirements/priorities.

Re: Devtools must be open source

#130
post #56

Earlier quoted context omitted.

Actually, the harsh reality is that for a large majority it has been an easier way to pirate, nothing else, while feeling entitled to scream at the poor maintainers for not implementing whatever features they needed for yesterday.

What a boringly reductive take. It's not like hackernews is some amazing bastion of like, optimism and culture and interesting conversation, but surely we can do better than this?

[deleted]
Post reply on HN