I think I can get on board with this view. In the earlier LLM days, I was working on a project that had me building models of different CSV's we'd receive from clients. I needed to build classes that represented all the fields. I asked AI to do it for me and I was very pleased with the results. It saved me an hour-long slog of copying the header rows, pasting into a class, ensuring that everything was camel-cased, etc. But the key thing here is that that work was never going to be the "hard part". That was the slog. The real dopamine hit was from solving the actual problem at hand - parsing many different variants of a file, and unifying the output in a homogenous way.
Now, if I had just said, "Dear Claude, make it so I can read files from any client and figure out how to represent the results in the same way, no matter what the input is". I can agree, I _might_ be stepping into "you're not gonna understand the software"-land. That's where responsibility comes into play. Reading the code that's produced is vital. I however, am still not at the point where I'm giivng feature work to LLMs. I make a plan for what I want to do, and give the mundane stuff to the AI.
Yup, agents LOVE Tailwind+ShadCN. Even when I've explicitly told them not to use it, it still creeps in. There's a lot of prior art out on GitHub and LLMs can't help themselves. FWIW, the result does tend to look nice enough. For a POC I can't complain. If I'm really going to roll up my sleeves and get into the code though? I don't think I'd enjoy all of it.
They hype-train on all of this stuff is unreal. React+NextJS+Tailwind+ShadCN is just a mess. It's complexity piled on deeper complexity - for little gain! But suggest any of that in many circles and you'll get the standard, "skill issu bro" comebacks. Say what you want about Remix/ReactRouter 7 (there are plenty of issues to talk about there) but at least those guys _tried_ to stay closer to existing web standards. I could go on and on about the disaster of NextJS caching. I could point out RSCs being one way to solve a problem that could already be solved by loaders in other frameworks....
Tailwind was my moment of saying, "Nope, I'm gonna sit this one out". I have a few trusted friends that assure me I'm missing out. I've told them to come back to me after they've done their first major refactor. If they tell me it was a pleasant experience, I'll have another look.
AirBnB doesn't use this config and you probably shouldn't either. Much of this was based on Jordan Harband's opinions in 2016. He's likely changed his mind since then. Perhaps not. But I bet he'd tell you to do your own profiling and consider your own targets before blindly accepting a one-size-fits-all configuration for your linter.
> do your own profiling and consider your own targets before blindly accepting a one-size-fits-all configuration for your linter
Too bad ESLint has been recommending airbnb as the style until 2024. You can't expect everyone to start with nothing and hand pick every rule themselves. Doable for a large organization, not possible for a personal project.
This was added to the language 10 years ago. So while it's "newer" than a plain old for-loop, it's definitely not "new". It was designed to work with Symbol.iterator. This is the mechanism whereby one can iterate anything that implements the Symbol.iterator interface.
As far as why folks won't just do simple for-loops, it's the same reasining every language tends to implement a "foreach", because there are annoying off-by-one errors lurking in the < vs <=. Of course one could argue that developers should be smart enough to handle this. But that's an argument even older than for-loops.
These barely if ever happen for simple iterations, it's an idee fixe. Off-by-one sneak in when trying to do something special, and then a for-on loop is useless anyway.
> Symbol.iterator interface
I get it, but it's unnecessary abstraction to overgeneralize a vanilla array to an iterable.
anyway, for..of is not an issue, it's alright. I think if there's one main point i'm trying to make, is that devs will write objectively worse code base on gut wants (in this case, obsession to use higer level abstractions to iterate over an array).
I can give an anecdote if that's helpful. Imagine you're wanting to download an object from S3. You start to type out the command in your CLI. You hit enter, only to realize, see that the object is not found. You have a typo somewhere... but where? The bucket is huge so, you resort to listing the contents and passing the results through grep. Then you copy the object to the clipboard so that you can edit your original command.
I see one of the other comments mentions K9s. The exact same use cases manifest with that tool. YES, if it's just a one-shot, nothing beats the CLI. Many things where you need to investigate the resources a bit more, lend themselves to a TUI (or GUI if that's your thing).
I come from an era where folks could fly through tasks on dumb terminals. (AS/400 apps). The moment we gave them "better" gui tools, they slowed way down. No matter how many times we told them, "you can still use your TAB and ENTER keys!" TUIs were just a sweet spot.
I don't want to pile on you as I see you've already taken a hit - so I'll leave the voting out of this. But consider how many people you knew in the 80s/90s with a Laser Disc player. It was very niche. You likely had one techy nerd friend, or you had a friend that had a dad that was always buying "the next big thing". I think I knew ONE GUY that bought a laser disc player. Contrast that with just Tesla (not even EVs). You likely know 4 or 5 friends or family that own one. The model Y was the best selling vehicle last year. Whether that trend lasts into the 2050s, none of us can know. But calling it a failure? I just don't see it.
Electric cars were a failure, their market share tanked back in the 1910s. So a vague "electric cars failed in the market" is technically true. However, that past failure is quite distinct from the current electric car thing.
And of those things we've been told, a high percentage of them have had to do with battery technology. Science is full of discoveries, science at scale doesn't always work out like we've hoped.
Everything I remember about the Jobs RDF was entirely about things like MacWorld Expo presentations. Selling lesser-performing products for more by claiming they did more with things like Photoshop bakeoffs, or with (claimed) style over substance. (I was a big long-term Mac user so I felt like Mac OS was enough of an advantage over Windows for a long time that it wasn't just style over substance.)
Musk just took it way further. When Jobs missed with the RDF it was on stuff like the G4 Cube being "cool" enough to make up for its issues. He wasn't promising miracles.
In our org, an RFC precedes a tech spec. The RFC literally is the "let's formally talk about this before we nail down a specification". For smaller specs, annotated comments can serve this purpose. Before this process, what we had found was no one was paying attention to tech discussions in our eng slack channels. Having an RFC gave us an inflection point where we could point back and say, "an official discussion happened, we decided to move forward with a spec".
Perhaps. Watching my GenZ kids react to AI commercials during the Macy's Thanksgiving Day parade, there was general revulsion. It seems many of them are seeking authenticity not uncanny. I know this would be an anathema in a board room where the cost of producing an amazing commercial via AI would make a C-suite sparkle with delight. No paid actors? No sound stage? No reshoots?
And yet, my kids reject it. It's odd. This is coming from a guy who loved watching frogs belch out the name of a beer company in the 90s....
Now, if I had just said, "Dear Claude, make it so I can read files from any client and figure out how to represent the results in the same way, no matter what the input is". I can agree, I _might_ be stepping into "you're not gonna understand the software"-land. That's where responsibility comes into play. Reading the code that's produced is vital. I however, am still not at the point where I'm giivng feature work to LLMs. I make a plan for what I want to do, and give the mundane stuff to the AI.
reply