It sounds like at least some of the problems pointed at would be mitigated by using fzf. At least it has greatly improved my terminal ux.

Well Shadcn gives you more freedom to fix stuff like this and rewrite how you want the component to work and look, since everything lives in your own code base. In a regular component lib it would be less likely that you'd think about this complexity, since it would be "hidden" away in node_modules or even transpiled and minified.

> everything lives in your own code base

A common misconception.

In reality Shadcn is a thin wrapper around libraries such as Radix, recharts, etc. The article says as much.

Sure, but if you wanted to change it to just use a radio input you could. Shadcn gives you a baseline.

native radio buttons gives you a baseline.

You can only call Shadcn a "baseline" if it was a baseline of the last floor of the babel tower of abstractions.

Sure, that's true. I oversimplified.

I still don't understand why someone would choose to essentially clone some code vs import a library. Suddenly you increase your maintenance burden, lose updates, etc. I've had no problems at all with UI libraries like Mantine. If you follow this logic, why not just clone all your npm repos and build from source. Ultimate control, right? Please help me understand the benefits here, because I tried out shadcn and wasn't into it

It's for projects that are design-first, where you'll have to implement your own component library that matches the design.

> Then, I brought it to my local repair shop. The owner had to tell me that they cannot repair Fairphone's

I brought mine to my local repair shop as well and they were completely unwilling to even try to repair it. Then I went home and tried myself and managed by just bending back some pins. The display cable had gotten loose. Have worked fine since then.

But is that because the phone is difficult to repair or because repair shop personnel has clear instructions to not try anything on devices they haven't been trained on? Likely "trained" as in their parts supplier does not have a QR code to the YouTube instruction in the ring binder.

Chances are they refused because it's not only a niche phone but a niche phone that's particularly repairable without shop logistics.

Yeah, I tinker with hardware embarrassingly seldom and my impression was that it was very easy to work with. The screen, which was the issue, is designed to be replaced and I realized it was fixable when I was trying to figure out if I could replace it.

My impression was that they had never seen the model before and for some reason they weren't interested in trying. I think I talked to the shop owner and it wasn't at a chain store.

The actual screen had dislodged from its detachable frame so I glued it back to that. And the screen connector pins were a bit bent so I bent them back. Then it worked. Figuring out how the broken parts were supposed to fit together were a little bit finicky I suppose. If I hadn't launched it into a concrete wall it would've been easier to figure out.

Honestly, with a phone as easy to repair as Fairphone I don't really care that repair shops won't repair them. All I need to to be able to order a part.

> I think everyone that's ever used GitHub actions has come to this conclusion.

I agree that that should be reasonable but unfortunately I can tell you that not all developers (including seniors) naturally arrive at such conclusion no.

I'm not claiming this works for everyone but what sometimes work for me to form a routine is to do the thing but without committing effort to it. I.e. go to the gym but you only promise yourself to go there, not actually spend effort there. Any actual exercise you then do is a bonus, not a "payment on your promise".

I think it can be generalized as:

Find the thing to do that doesn't require much effort but puts you in the context of doing the effortful thing. Do that thing. See if you "want" to do the effortful thing. Otherwise go home.

Cleaning? Put the vacuum in your hands and see if something happens.

At least I think that's how it works for me.

The points when it's hardest to make it work is when there's lots of distractions. Like when you try to get into a routine of doing work at a computer.

Yeah but I wonder if there's a structure that can be used to make it useful for larger side projects.

That’s where VS Code has helped me the most, it provides a lot more model guidance than people realize.

> your competitors will be able to replicate in few months.

Will they really be able to replicate the quality while spending significantly less in compute investment? If not then the moat is still how much capital you can acquire for burning on training?

There are multiple tech companies with quadrillion-deep pockets.

What does moat even mean anymore

Would it limit a person getting your instructions in Chinese? Tokenisation pretty much means that the LLM is reading symbols instead of phonemes.

This makes me wonder if LLMs works better in Chinese.

That's a problem that is at least possible for the LLM to perceive and learn through training, while counting letters is much more like asking a colour blind person to count flowers by colour.

Why is it not possible? Do you think it's impossible to count? Do you think it's imposing to learn the letters in each token? Do you think combining the two is not possible.

How often can the hardness be exchanged with tediousness though? Can at least some of those problems be solved by letting the AI try until it succeeds?

To simplify for a moment, consider asking an LLM to come up with tests for a function. The tests pass. But did it come up with exhaustive tests? Did it understand the full intent of the function? How would it know? How would the operator know? (Even if it's wrangling simpler iterative prop/fuzz/etc testing systems underneath...)

Verification is substantially more challenging.

Currently, even for an expert in the domains of the software to be verified and the process of verification, defining a specification (even partial) is both difficult and tedious. Try reading/comparing the specifications of e.g. a pure crypto function, then a storage or clustering algorithm, then seL4.

(It's possible that brute force specification generation, iteration, and simplification by an LLM might help. It's possible an LLM could help eat away complexity from the other direction, unifying methods and languages, optimising provers, etc.)