Earlier quoted context omitted.
> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. As someone who way long before the LLM age had small patches accepted in several dozens of projects I've been using, I can assure you that this is just a matter of mentality. All I needed to be able to do that was to stop thinking that "nobody has done it so far, so it must be hard" and just do it. S…
I expect it's a whole lot easier on Debian and Arch than it is on macOS.
Devtools must be open source
181–190 of 262 posts
Re: Devtools must be open source
#182Earlier quoted context omitted.
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/
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.
Re: Devtools must be open source
#183Re: Devtools must be open source
#184Earlier quoted context omitted.
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.
This means:
Every release, the only thing done is they edit a prompt and then ship the build that comes out of LLM -> CI/CD ?
Then they delete all the source that was generated, along with the context, and only the prompt is carried forward to the next release?
Re: Devtools must be open source
#185> 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…
> "Check that the software works as intended" is not going to cut it, as AI are very, very good at obeying the letter but not the spirit of the ask. Surely you don't think that he literally meant to use those seven words as a bullet proof prompt, right? I will never understand this way of responding literally and pedantically to verbal psudocode. He's leaving it as an exercise to the reader to specify "check that the…
Again, this is normal if you are interactively working on software and can fix any problems you see. It is only problematic if you do what OP says, and make it on cron, daily and unattended.
Re: Devtools must be open source
#186> Both the upfront fixed costs and the ongoing costs of personalizing software have disappeared.
Is just wishful thinking, at best. We can say your own quirky little personalised software that works on your computer might have become cheaper. Production grade software that people pay for is a different beast. That’s why people pay for software: support and ongoing maintenance. LLMs have not and are unlikely to change that part of the equation. As a business the pure liability of not having anyone to call about an issue is a BIG issue.
Re: Devtools must be open source
#187I've worked at a DevTools company and been the CEO of one too. Here's my thoughts: I agree that they need to be open source. But that makes it really hard to make a successful business. Sure, there are examples of success, but also many examples of successful open source tools never becoming successful companies. The most famous example is Sendmail (where I worked way back in the day). They took millions in funding a…
Re: Devtools must be open source
#188I've worked at a DevTools company and been the CEO of one too. Here's my thoughts: I agree that they need to be open source. But that makes it really hard to make a successful business. Sure, there are examples of success, but also many examples of successful open source tools never becoming successful companies. The most famous example is Sendmail (where I worked way back in the day). They took millions in funding a…
The answer is you don't sell the tool. You release the tool, others help you make it better, then you use the tool to build the actual thing.
Re: Devtools must be open source
#189Open-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.
AGPL software is in practice always gratis, because anyone who has a copy can post it on the internet where anyone can download it. The monetization benefit of AGPL is that it makes it significantly more annoying (but by no means impossible) for IaaS providers to sell managed hosting for the software without making a separate commercial agreement with the copyright holder. This usually isn't relevant to dev tools tha…