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

Changing how we develop Ladybird

ladybird.org

Post reply on HN
Print view View original

331–340 of 602 posts

Re: Changing how we develop Ladybird

#331

Post by ruszki »

mistersquid wrote: post #303
shinryuu wrote: post #286

Earlier quoted context omitted.

100x is achieving something in two days, what it took an entire year before. I strongly doubt that is happening for an individual.

> 100x is achieving something in two days, what it took an entire year before. Reduce your scale: "100x achieves in 1 hour what used to take 1 week." One year of work could require levels of complexity and human judgement that can't be accelerated past a certain point. 1 week of work can be reduced to an hour and some change.

That’s also not possible in “skilled” hands. My output is roughly the same. It does the scaffolding, but I need to rewrite almost every line, because it introduces footguns around that often. And before I had about 20000 LOC it failed even with scaffolding, ie architecture. And it wasn’t taste, just footguns all around, architecture ones. Nowadays for example still introduce mutability or completely unnecessary complexity where it shouldn’t, even when the example code which does almost the same is pristine. Many times it’s like StackOverflow, when a question doesn’t need 90% of the accepted answer, but people happily copy it brainlessly.

This is especially bad with new, or quickly improving frameworks, like Android Compose. LLMs use completely outdated, deprecated APIs all the time, when they are not completely supervised. Or at least, I hope so that the framework causes it. Because if that’s not the case, then your products are fucked.

Also even with the best prompts it could never produce more working code in an hour than what I can produce in a day. Regardless of quality, just “working somehow”. Not even with an uninterrupted session. If that’s the case for some, then there is definitely also a developer skill issue. And so would definitely not trust anything coming out of their “supervision” of an LLM.

Re: Changing how we develop Ladybird

#332

Post by jatora »

patates wrote: post #131

When AI first happened, I was afraid I was going to eventually lose my job. And while I've been lucky since, many did, and that hurt a lot. When people are losing something to automation, regardless of the economics of the situation, you cheer for the humans, or at least hope that society keeps being fair to those who are most affected. Now I see communities being affected. When you kill PRs, you not only kill the co…

> Also: I liked a song and it was sonos. I unliked it after discovering. I feel so stupid, so often.

This is asinine. Keep depriving yourself of things you enjoy I guess?

Re: Changing how we develop Ladybird

#333

Post by rurban »

losvedir wrote: post #321
rurban wrote: post #269

Earlier quoted context omitted.

There massive value in AI PR's. If a feature and ignored, it can forked to provide more value to the users. If unaccepted bugfixes, the maintainers are just silly. They need to be forked off.

It's interesting to see this perspective in the wild. In the age of AI I wonder what "massive value" your PR is bringing to the maintainer. $1 worth of tokens?

[flagged]

Re: Changing how we develop Ladybird

#334

Post by slipknotfan »

kristoff_it wrote: post #132

The problem statement is clear to everybody. > For decades, code contributions have been how open source projects learned who to trust. People would show up, do the work, take responsibility for their changes, and stick around. Over time, trust emerged from the work itself. The solution, IMO, is a strictly worse version than what we chose in the Zig project (banning LLM contributions). > AI tools have changed the eco…

>This is an obvious recipe for disaster (a rugpull), and I'm forced to wonder if this is just by mistake or if some of the Ladybird sponsors are playing a mean game of Secret Hitler. I guess only time will tell.

When I first read this I checked the license and saw that a rugpull would be permitted. However, if someone wants to continue the project after the rugpull they could do something thing like the redis rename to redict.[0]

[0] https://andrewkelley.me/post/redis-renamed-to-redict.html

Re: Changing how we develop Ladybird

#335

Post by rurban »

bpicolo wrote: post #289
rurban wrote: post #269

Earlier quoted context omitted.

There massive value in AI PR's. If a feature and ignored, it can forked to provide more value to the users. If unaccepted bugfixes, the maintainers are just silly. They need to be forked off.

I mean, aren't you kind of proving the poster's point? Fork away. If you want to put in the meaningful effort required to maintain and improve upon a project as significant as Godot, and feel that AI is a mechanism you want in order to do so, go for it. Clearly, the maintainers don't feel that that's the best approach to create the product they want to create, and they are not required to accede to the sense of entit…

Even before AI it was trivial to setup a continuous merge script. I did that several years for several projects which refused my PR's.

Nowadays it's even more trivial.

And a community is more of a burden than an advantage nowadays. Users are ok, but a community not so. See python, perl, ruby, node and countless others.

Re: Changing how we develop Ladybird

#336

Post by justin66 »

hypfer wrote: post #281
gbalduzzi wrote: post #198

Earlier quoted context omitted.

I still don't see solutions on how a normal person can become a mantainer though. If all relevant open source projects close up their contributions, you can't enter the project anymore from an external point of view. Almost all open-source public figures started by being interested in a project and submitting PR to it, until eventually either joining the project as core mantainer or creating a separate open source pr…

Just uh.. build your own thing? Boom. Maintainer. Easy. Why would normal people even want to become an unpaid janitor for someone else's stuff?

> Why would normal people even want to become an unpaid janitor for someone else's stuff?

Social validation. Or, to be slightly more generous, sort of a compulsory way to force someone more experienced to provide some mentorship, by compelling them to review your pull requests.

Re: Changing how we develop Ladybird

#337

Post by paddim8 »

gregoriol wrote: post #67
koteelok wrote: post #9

Stuff like this makes me wish AI had never happened. An open-source projects losing the ability to find and mentor new maintainers is so disappointing.

How is it really related to AI? there have been issues with open-source and maintainers for a long long time

Read the post

Re: Changing how we develop Ladybird

#338

Post by wussboy »

jatora wrote: post #332
patates wrote: post #131

When AI first happened, I was afraid I was going to eventually lose my job. And while I've been lucky since, many did, and that hurt a lot. When people are losing something to automation, regardless of the economics of the situation, you cheer for the humans, or at least hope that society keeps being fair to those who are most affected. Now I see communities being affected. When you kill PRs, you not only kill the co…

> Also: I liked a song and it was sonos. I unliked it after discovering. I feel so stupid, so often. This is asinine. Keep depriving yourself of things you enjoy I guess?

Perhaps knowing a human with talent worked on it, putting some small part of themselves and their lived experience into the music has value to them? If so, then their actions make complete sense.

Re: Changing how we develop Ladybird

#339

Post by troupo »

nh2 wrote: post #245
troupo wrote: post #79

Earlier quoted context omitted.

> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it. You can still submit a bug report and tell them exactly how you did it. > Reviewing code fixes is strictly easier than coming up with them yourself. Unless it's hundreds or thousands of AI slop PRs each pretending "here's a bug I fixed it"

> You can still submit a bug report and tell them exactly how you did it. Can you? The announcement says "There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks". So I, as a human, describe in prose which changes I made to e.g. 20 files? How is that in the spirit of fighting LLM slop? Also, if I can do…

> Can you? The announcement says

That you can still report bugs

> So I, as a human, describe in prose which changes I made to e.g. 20 files?

Rarely does a bug require a description of what needs to be done in 20 files

> Also, if I can do that, the LLM slop contributers can also ... do that.

Yes, they can. Yes, they will. And yes, it's a problem.

Re: Changing how we develop Ladybird

#340

Post by customguy »

Folcon wrote: post #309
torben-friis wrote: post #251

Earlier quoted context omitted.

>But all now seems like a transition phase. Transition to f-ing what though? It feels like being in the middle of a tornado. But I think it helps to turn off screens, sit in a desk, and calmly remember first principles and consider them slowly. Quoting obama, "reality has a way of catching up with you". I see a lot of talk, but iOS is not delivering a decade of features and fixes on each yearly release. Literally no…

I've been thinking a fair bit about what I'm seeing in terms of the output I experience It's quite hard to quantify, but I think it's one shot nature really makes it hard to gauge it's capability Friends have spoken of good days and bad coding days with me, and I find it odd nodding along, it's a strange new normal At times it feels like we're just coding with one-armed bandits, trying to carefully line them up for a…

I imagine this stuff is probably really good at iterative changes to improve objective benchmarks like CPU or RAM use. I'm thinking of little contained optimizations that you can understand in and of themselves, that you maybe have done yourself before in other places, found really quickly and applied uniformly. Stuff you can confirm to be what you expect it to be by mostly just scanning. Low hanging fruit for sure, but something where you can actually know what is a fruit and what is crap, and only keep the fruit, and develop some confidence in the process, if that makes sense?

Or trying to reduce complexity, increasing readability and coherence of variable names (the opposite of code golf if you will), while staying within a certain limit of performance regression (e.g. "make this code as nice as you can while making it at most 0.5% slower").

Making the stuff millions of people have been using for decades better, in a way that also makes it better for humans when they read the code. Surely that's possible, some people are probably doing it but it doesn't go viral as much, because it's too mundane.

And of course, making new stuff is more exciting. I mean, you could hit on something with a vibe coded thing, and then know it's now worth to make a non-sloppy version, but you won't get much fame for making ffmpeg twice as fast by prompting an LLM. Though on the other hand, it's like a safe investment (if not in "fame", then in "improving the stuff we all have to use daily"), because you know ffmpeg and many many other things will still be around, whereas a vibe coded thing that wasn't special will be 100% forgotten the next day, or have just the one user forever.

Post reply on HN