MantisShrimp90

Half of me agrees with you. As someone who used to tinker with neovim all day I've had to learn just because you can program the problem doesn't mean you should and stick to a relatively minimal config.

Still, its a valid design choice with different design decisions compared to sway. But that's the point you get to choose.

Hyprland is much more "build your workspace with legos" so having a full lang like lua makes sense to properly integrate the various pieces.

I believe perfection is a dirty word because it has a pernicious effect on the human mind.

Striving towards perfection too often leads to yes over-engineering but I think more importantly it also: leads to way too much bike shedding due to the need to be perfect and allot of even emotional baggage when we don't make that perfect things.

Even the author admits that their definition of perfect can only arise with stringent requirements and I'll take it a step further, maybe it was perfect for that problem at that time but guess what change happens all the time, and as architects we have to think about future problems as much as current ones. With that in mind I think that having something that is good in many scenarios is better than the thing that is perfect in the scenario you start in.

Yea by having claude code in a terminal window within neovim rather than tmux you can leverage neovim commands to traverse, copy, paste and otherwise interact with the terminal window like any other buffer.

There are also plugins with more specific workflows but I like really seeing how much vanilla neovim can get done

Knowing and leveraging the editor deeply is the best high level advice. Sessions for persistence, windows and buffers to manage screen real-estate (including terminals), and the terminal command itself to run the agentic workflow of your choice.

I will concede that this is the primary gap in the ecosystem right now is PERSISTENT terminal buffers but the act of doing terminal work in neovim is straight up nice if you use neovim motions to leverage that relationship.

Terminals resuming in a session is just a feature to be added not a complete functional rewrite.

(Neo)vim is setup wonderfully for this era. Im with Justin on the take that neovim can replace tmux soon literally all that is left is being able to restart terminal sessions on restart (which is even set as a goal for summer of code).

Neovim can already have all the agents running in different terminal buffers or there are plugins popping up every day to have deep integrations with your favorite or we even have some interesting harnesses that are unique to neovim like sidekick.

As always, the ability to compose small tools and edit any file allow neovim to stay relevant and more powerful than ever in my opinion while not forcing workflow changes like the others

I mean others are saying its divided and that's true.

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

I mean yea my take is that there's basically nothing that claude could benefit from that humans wont. So I see no reason to make claude-specific docs.

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

I think this writer kinda took the bait which is fine someone had to do this so we couldn't debate endlessly.

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

Cute interesting take but I feel like it misses the point. Specifically, this makes sense where performance is necessary. Many projects have been written in suboptimal languages because the writers didn't want to learn lower level languages.

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

I recently posted about how I refuse to buy apple products because of stuff like this. The lock in has made iPhone users dependent on a app ecosystem when we could have had most of our functionality through the open web.

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 refuse to buy macbooks/apple products and advise my people to do the same.

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.

I think this is a classic case of correlation does not imply causation. As someone that has known these people, and I does smoke as an adult, I would interpret that as people who are struggling with mental illness symptoms turn to weed as an outlet. Especially when we take it with the wider literature on drug abuse and mental illness any practitioner worth their salt knows mental illness makes drug abuse more likely and yes then the two affect one another which is why rehab is usually a big part of the hospitalization process. But what I don't want to see is more moral panic so we can renew the war on drugs which as always should really be the war on poverty and mental health issues.

The only real answer is something like web assembly and that would be a major breaking change for them.

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

As someone who has been running all the components of omarchy before they made it, I agree with you in spirit especially as an arch user.

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.

Remember, in other countries, especially eastern ones, the recommendation of even your local city means allot. There is a deeper trust of government bodies so this will likely have an impact.

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

This sparks a thought experiment I've been having. In this world where llms can be thought of as the new layer of compilers, things like pickle are likely going to be the main unit of work for humans.

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

Im in the same boat. In theory JavaScript holds more potential to make finely crafted visuals. But you're right, the ecosystem is so mature I still find other ecosystems lacking.

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

You get it

Im on the opposite extreme here in that I believe typing obsession is the root of much of our problems as an industry.

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 love casey and I love this talk. Always good to see people outside of academia doing deep research and this corroborates allot of how I have understood the subject.

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

I get that its funny to shit on philosophers with the "time is a social construct" quip but you then literally outline the arguments that make this statement true.

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.

Meh, you're making the same mistake most do on this one. You're treating the Linux desktop like it's compatible even though these two non-linux operating systems are made by some of the biggest companies ever with allot of engineering hours paid to lock people in.

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.

Its just not that simple. The best way I can dovetail with the author is that you are thinking in terms of the abstraction but you have mistaken the abstraction for reality.

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.

Thank you, most of these books are actively harmful, and the lack of intellectual rigor makes them exactly this, entertainment masquerading as education.

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.

Projects like this are great because open source versions need to figure out the right way to do things, rather than the hacky, closed, proprietary alternatives that pop up first and are just trying to consume as many users as possible to get a most quickly.

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

Unless you are someone that has chores to do like say... Most people? Yes we could technically leave our dirty dishes on the sink while we do art but that decision bites you next time you want to cook lol.

Obviously we mean we want to use that time of doing dish towards art instead, like how automation has always worked?

I mean I guess In this obtuse, maybe someone's joy In life is doing dishes and that is their art, then idk maybe but not even then.

First, this just misunderstands what is being said here. For most people, chores like the dishes is a menial task that we will be happy for any reduction in time/effort. In addition, dishes and laundry are considered necessary for modern life.

By contrast, art like music and visual mediums is often associated with joy and the creative act of building something out of making art rather than getting a task done.

To misunderstand this contrast is to misunderstand why we automate things in the first place, to minimize the unnecessary toil and maximize human flourishing. This does the opposite frankly.

It took a minute to setup, but using a combination of rsync and timers to backup system files has done wonders to decrease my anxiety around upgrades on arch

The only real answer here.