I guess the other side of your argument is... Is it better though? One could easily argue much of software development is promising projects strangled by their own technical debt and short sighted designs. It still has yet to be seen if AI can make well architected systems unsupervised. And this really was one of the few places where technical people shared their labors of love and appreciated the technical skills of a community.

Also, all the externalities whether that be environmental, social, or even technical and hn is really bad at actually talking about these things directly so we have to couch it all as the tool being bad. That's the part you're missing for many its more like its not good enough to justify the costs

With that said, yes, the difference is I KNOW claude will read my docs, especially if I shove it into the context and therefore, I KNOW I'm getting ROI on that work.

As someone who has written docs for years I have spent too many hours writing docs that my colleagues proceed to just ignore and ask me to explain verbally. Its a culture thing if people don't have a natural instinct to read docs and a culture of documentation and asking others to read the docs INSTEAD of bothering the human.

Also, there may be something to the theory that people don't learn well from docs as tutorial. I find 10x faster return when I make a video for people or tutor them through something rather than sending them a link and asking them to read it. Often this is because good docs are disciplined and try to answer the one question they were asked. Which is great, untill you realize most are missing necessary background so now you're in a bind. Do you document foundations that are covered in other places? Or do you cover them in your own words making 10x more work for questionable value? Its not an easy question

But the reality is that if you were already set enough to call rsync slop because of a single post, you aren't going to be more down now. Even in these responses I see everyone nitpicking and moving goalposts as if one more commit being actually claude-aided will tip the scales from stable project to "vibe coded slop".

Software has always been fuzzy, we have never come up with an objective way to handle software quality, and this Uber hatred of llm contributions lets the humans who make egregious bugs and mistakes off the hook.

Taking a step back, we need to have more empathy and thoughtfulness of one another in this space. Its new and people are experimenting and there will be nothing good coming from personal insults and DDOsing a good project just because someone got ragebaited on threads, x, mastodon or whatever else.

How do we determine bugs and increase quality? Its almost like we have been grappling with this question for decades and I still hear people fight on the best way forward. Simple design, test driven development, user surveys, all of the above have been used as a proxy for software and they all failed to capture everything. Back in the day we used that ambiguity to give each other grace, now we use that ambiguity to tear down other creators. Whatever, if open source software really is dying its because of this toxic shit just as much as the llms

Still, not ALL projects benefit from such an approach and there are times when yes python is the right tool. Not just due to readability of humans but the other qualities that make it really good for small, iterative apps.

My take has never changed. Knowledge is cheaper than ever, but wisdom is as rare as ever. This is a great example of misunderstanding the former for the latter

People saying they don't want these features are missing the point. Its about control and if developers have the option to make something as a website that actually works that gives them less incentive to make an app that apple can take 30% of your profit from while you are forced to write in their proprietary language for the stuff that only works on their devices.

So much engineering duplication of effort and waste just to satisfy a bottom line.

I make it clear it's not about specs, it's not about UI, its about the fact that apple makes the world actively worse so they can sell you a better alternative.

You cant have iMessage anywhere else because they don't want you to, you are locked into apple stores because they refuse competition, you cant repair your own device because they get that money back in repair fees.

Its not about the operating system or the specs, I feel investing in Linux is the best way to create a more sustainable future for me and the ones I love and changing that take will require systemic changes, not these spec bumps and UI overhauls people fixate on.

This is why allot run dev containers but agreed this really should be top priority but instead is probably in the "maybe if we have a major security incident" bucket of concerns as these things often are

But other people need an ISO and yes all those things are kinda considered standard at this point.

People like you and I aren't the target audience, but for the people who are, this is what they have been asking for.

And starting small is probably good, lets the idea iterate before rolling it out wider and this often comes down to making a choice, this city just thought this would be best and I suspect unless this goes horribly wrong it will help

Only now instead of this developing brittle generated tests, it will instead be used by the llm as guidance to generate the actual code and tests.

Before people jump down my throat, I know we are nowhere near that today and I promise I'm not pitching this to my leadership because they would gobble it up too fast.

But for us engineers, I think there is an interesting space for thinking of llms as akin to garbage collection, a feature that allows us to abstract to a slightly higher level of thought. Yes we still need to know how to check under the hood, but this is looking like the right level of precision-flexibility ratio that llms thrive in

But if anything would change my opinion this has the right set of values

I think Rich Hickey was completely right, this is all information and we just need to get better at managing information like we are supposed to.

The downside of this approach is that these systems are tremendously brittle as changing requirements make you comfort your original data model to fit the new requirements.

Most OOP devs have seen atleast 1 library with over 1000 classes. Rust doesn't solve this problem no matter how much I love it. Its the same problem of now comparing two things that are the same but are just different types require a bunch of glue code which can itself lead to new bugs.

Data as code seems to be the right abstraction. Schemas give validation a-la cart while still allowing information to be passed, merged, and managed using generic tools rather than needing to build a whole api for every new type you define in your mega monolith.

I find it funny that even after he goes into explicit detail about describing oop back to the original sources people either didn't watch it or are just blowing past his research to move the goal post and claim thats not actually what OOP is because they don't want to admit the industry is obsessed with a mistake just like waterfall and are too stockholm syndromed to realize

The philosophers had their finger on the pulse decades ago, science only started listening after their models stopped being able to construct a clean deterministic view of the universe.

Plus, one could argue they've actually just established dominance through market lockin by ensuring the culture never had a chance and making operating system moves hard for the normal person.

But more importantly if we instead consider the context that this is largely a collection of small utilities made by volunteers vs huge companies with paid engineering teams, one should be amazed at how comparable they are at all.

Physics, biological sciences, these are tools the mind uses to try and make guesses about the future based on past events. But the abstraction isn't perfect, and its questionable on whether or not it could or should one day be.

The clear example is that large breakthroughs in science often comes from rethinking this fundamental abstraction to explain problems that the old implementation had trouble with. Case in point being quantum physics which has warped how we original understood newtonian physics. Einstein fucking hated quantum because he felt it undermined the idea of objective reality.

The reality (pun intended) is that it is much more complex than our abstractions like science and we would do well to remember they are pragmatic tools and are ultimately unconcerned with the practice of metaphysics which is the underlying nature of reality.

This all seems like philosophy ramblings until we get to little lines like this. Scientism, or the belief that science is the primary and only necessary lens to understand the world falls for the same trap as religion of thinking that you have the answer to reality so anything else outside is either unnecessary or even dangerous to one who holds these views.

What matters is humility, thoughtfulness, and a relentless focus on quality. These books sell to people that want all of the inspiration with none of the work.

In that case, a shitty, closed system is good actually because it's another thing your users will need to "give up" if they move to an alternative. By contrast, an open ide like void will hopefully make headway on an open interface between ides and the llm agents in such a way that it can be adapted by neovim people like me or anyone else for that matter