I just do my job to the best of my ability. I have to change jobs every couple years anyway to get proper pay bumps, so I don't really care what the higher ups think of me. The people near me are who I'll use as references and they generally know I'm great at what I do.
My experience working with other peoples code is that they often use too many wrappers. I don't mind using some wrappers, often they're just necessary. But I'll often see components with like 4+ nested divs where half of them or more can just be removed with no visual change. Not to mention spans, some people just use spans for everything, it's all divs and spans.
Personally I like to try to use semantic HTML where possible, as it helps with a11y and is nicer to read and work with. But I don't mind using some container/wrapper divs to make things look right.
Across a large enough area it's always sunny somewhere. And clouds don't interfere as much as you'd think. Add in wind, hydro, nuclear and some gas and you can handle pretty much anything just fine.
That has nothing to do with where factories, mines, farms etc are already located. You have to buy land to connect the power plant to the load and some guy in the middle wont sell. Handle congestion/maintenance of those lines etc. Lots of issues beyond just generation that the grid already is dealung with even though massive solar plants have been built. But main thing is weather forecasting has to get better because even with existing huge plants constant surprises happen.
There's this thing called the power grid, it transports electricity across great distances.
And everything you're talking about is an issue with any kind of production, I don't know why you're bringing it up as if it's unique to solar. If you're building a factory that needs high amounts of stable power then you plan accordingly. Doesn't change the fact that solar is a useful way to generate electricity. I don't think anyone is saying we have to use it exclusively. We can use different solutions for different problems.
Lots of probs with existing grid . Certain routes are already overloaded/congested, building new ones is not as easy because of land acquisition costs compared to the past. Repairing, upgrading and maintaining old routes to handle new loads raises costs of moving electrons to your factory etc. One hurricane or blizzard can shut a route down so redundant routes have to be built. People just under estimate how complex things have become.
Also that's impossible. It is impossible to simulate reality exactly using digital computers. The best we can do is approximate. Doesn't matter how powerful it gets, it'll always just be an approximation.
What does "simulate exactly" mean? To me, exact simulation is not so much an impossibility as a nonsensical concept. What subset of reality are we simulating, and to what degree of precision, and with what certainty? An "exact" precision as it relates to real world objects is not a well understood or defined concept. For integers, I can say there is exactly one Earth orbiting exactly one Sun, but I think that statement is riddled with assumption, inaccuracy and imprecision. For example, it is assumed that I am referring to the present Earth, but is the statement of when the statement is made or when it is heard? Even the word "is" is inexact.
I agree, exact simulation is nonsensical which is my whole point. Did you read the comment I replied to?
It is nonsensical to claim that anything other than my brain could produce the same consciousness that my brain is producing. It's obviously far beyond anything any conceivable digital computer could ever reasonably simulate, and even if you did create a "good" simulation it obviously wouldn't have the same properties that my brain does because it's an entirely different thing than my brain is.
Assuming you don't believe humans have any metaphysical component, then the only remaining question is whether there's some essential component to being human that depends on impossible-to-precisely-simulate portions of reality. Nothing we currently know of biology suggests that that would be true, as much as it continues being pursued by people who need there to be something mysterious about consciousness or brains.
In any case, a closely-but-not-perfectly-accurate simulation of a real human brain is still going to be human, unless you believe that someone becomes less human when they're experiencing some kind of cognitive decline, or a stroke, or other biological malfunctions. The point is, there is nothing essential to the having of a physical brain that creates the concept of consciousness or sense-of-self.
How can a simulation be human when it isn't human? It's a simulation. A human is a human, a simulation is not. Anything that is not a human, is not a human and can never be a human.
And there absolutely is something essential to the concept of being human that we are entirely incapable of replicating artificially. In fact as far as I know we are incapable of synthesizing any kind of life whatsoever. We can't even create the simplest type of living cell imaginable.
So to claim that we could just create consciousness, a fundamental property of this "life" thing that we don't properly understand, within a piece of rock is beyond naive. We don't even know what it is or how it is.
It seems to be important to you that consciousness is mysterious.
We understand quite well where in the brain the sensation of self-awareness / self-experience / sense-of-self comes from. We have evidence that disruption of that part of the brain breaks those sensations.
I don't know why people always need to assign agendas to me in discussions like this. It's not "important to me" it's literally just reality. Consciousness is mysterious, we don't know much about it. The fact that you can mess with it by poking the brain does not mean you understand it.
Okay now tell me where in the LLM its alleged consciousness comes from.
Its a computer program. It is literally just a lot of zeroes and ones, sitting there doing nothing.
Then a request comes in, and the system does a bunch of calculations using those bits, and spits out a result. The bits are unchanged.
When your brain receives input, it is changed. It is constantly active. If it ever stops being active it's dead.
So, what exactly is the claim? Are the bits constantly conscious? Do they snap into consciousness when the computer does math with them? Or is it maybe the computer that's conscious while it's processing these bits? How about when it stops doing that and goes back to doing other stuff? Why are these particular bits special? Was the computer always conscious?
I feel like the only way anyone could believe LLMs are conscious is if they don't understand how computers work. Of course it isn't conscious, how could it possibly be conscious? Its literally just bits. It's like saying the text in a book is conscious.
So, what exactly is the claim? Are the bits constantly conscious? Do they snap into consciousness when the computer does math with them? Or is it maybe the computer that's conscious while it's processing these bits? How about when it stops doing that and goes back to doing other stuff? Why are these particular bits special? Was the computer always conscious?
These are all fine questions, and they don't become any easier to answer if you replace "computers" with "brains" and "bits" with "neurons".
Of course it isn't conscious, how could it possibly be conscious? Its literally just bits.
"That's ridiculous. How can meat make a machine? You're asking me to believe in sentient meat."
What is even being argued here - neuroscience is hard, so programming your PC thus makes it conscious?
We don't understand how combining a bunch of obviously(?) non-conscious biological components can produce a larger system that is conscious, so it's unwarranted to be certain that that can't happen with software.
Cells are living entities, can't they be conscious? I think they are. Is not that human consciousness comes out of raw materials. They are alive, not as bits or circuits. That can't be discussed.
A lot of the time if you're copying code from one place to another what you actually want to do is abstract it so you can reuse it in both places.
The LLM can easily do this type of stuff, just tell it and it'll happily do it. This is exactly what I mean when I tell people they need to work closer with the AI, tell it how to do things. Don't just tell it what to do and get frustrated when it does it differently than you would.
A good way to achieve this without writing huge prompts is tell it to plan the change first. Just give it some vague low-effort directions. It'll usually get most things right, you tell it what you want different and once you're happy you tell it to go ahead.
Nah the codebase is legacy fucked and I cant be bothered to try and optimize business flows without the fear of other stuff breaking.
Claude 100% of the time even thinks we use laravel despite the project being some old lumen codebase, so most of laravels features are not available. It also gets the PHP version we are using wrong 100% of the time.
Are you some kind of entitled corporate dev that barely has any influence on the codebase? If I fuck up a whole business goes down as I am the only dev there currently. We cant afford that happening.
Also why would I mess with anything claude.md related? I just use the CLI tool. LLM enthusiasts always claim how smart these things are so they should figure it out on their own, you know?
I have full control of my codebase. I'm not afraid to make changes to it because I know what I'm doing.
You would edit Claude.md to say things like what tech the project is using, because that's the entire point of claude.md. It's literally the solution to the exact problem you're complaining about. Any information you want it to know, you put in there and then it knows it. And you can tell Claude to make or update the file for you.
I'm not one of the people telling you how smart LLMs are. I'm telling you how to use it efficiently, by not expecting it to know everything but rather provide the information that it needs in order to be a more useful tool.
This is a spicy take, unless the business is willing to face some down time, and I am hired to do exactly what you said, I’d never touch any line of code unless I absolutely have to. Different environments don’t help as much.
We tend to obsess over software quality when it’s the least important thing for a business. It’s just a means to an end.
This is what its about, we have multiple ecom shops running 24/7 and cant simply afford downtime or a change of business flow that maybe doesnt affect shop A and B but definitely affects shop C and D...
- Takes weeks or months to get simple features out the door, and when they're out they're buggy as hell and the bugs never get fixed. Sound familiar?
> I’d never touch any line of code unless I absolutely have to
And this is how legacy code is made. Years of everyone "never touching anything they don't have to" leads to a giant steaming pile of shit.
> unless the business is willing to face some down time
How does a simple refactor cause downtime? I do this kind of stuff all the time and pretty much never cause any downtime. In the very rare cases that prod downtime does occur it's generally not because of some simple code refactor, and we have it back up in no time by just rolling it back. Unless it's not related to the code at all, in which case it also wasn't a refactor that caused it.
That feels like a market failure though. For a tool to be a useful extension of the user, it should work in the way a user expects it, without a huge amount of having to realign and repackage your normal process.
Maybe that's something we can hope for in a next-generation of LLM product. Right now, the race seems to be all about performance and capability, but maybe when we get to a plateau of performance, vendors can start differentiating by building tools with clearer voices and expectations-- focused system prompts and training, maybe. If you know DeepSeek will follow your requests fairly literally, while Qwen will start adding best-effort tweaks, you can decide which one is the right choice for a given task.
I asked Claude to read two logs and assemble them in a single table for easy reading the other day. It takes me like 30 seconds to pull and toggle between the logs normally, but I figured it would be nice to have a skill to let the machine crunch it all onto a single page. After 5 minutes, it spat up a ball of Markdown with half the content truncated and summarized it in a way I didn't ask for and had no interest in.
If I had asked a human to do it, there's no way it would come to that conclusion because doing the wrong thing is literally more effort. Maybe the model did those things because "typical" requests want summarization so it's the implicit default, but IT SHOULDN'T BE MY RESPONSIBILITY TO GUESS THIS.
You're just expecting too much. If a task takes you 30 seconds to do you're almost certainly better off doing it yourself than getting an LLM to do it. If it's a recurring task it might make sense to create a skill for it, and this is exactly the use case for skills. Give precise instructions so it does the task correctly, and save them for later so you can do it again easily.
I don't really get how you guys can be so demanding - this technology is magic. It's doing things that 5 years ago we could only dream of. It still blows my mind every time I paste a screenshot of some vague issue along with a quick and dirty prompt and it just gets it and gives me the right answer immediately.
In the hands of a competent user these things are absolutely incredible, I can develop solutions faster, with higher quality and less effort. So honestly man all you guys complaining that they aren't good enough? I can't help but think you guys must really not be very competent. Complaining about problems while the solution is staring you in the face.
> I don't really get how you guys can be so demanding - this technology is magic
That could be the problem. I suspect a lot of developers have spent years developing workflows and understandings based on the idea the machine is precise, repeatable, and does exactly as it's told. "Magic" is a very poor match for that strategy.
> Complaining about problems while the solution is staring you in the face.
Not quite sure what the "solution" is here. Am I supposed to try to restyle the prompt to be "quick and dirty" to give Claude more room to stretch and hopefully hit my desired goal? Or am I supposed to iterate repeatedly on the skill to add a harness of "don't truncate that, don't add a summary, etc" until it behaves how I want?
I'm not saying you're wrong. I think it's almost more like the difference between programming languages. If you come into writing FORTRAN with a TCL/Tk mindset, you're going to have a hard time getting what you want, but the industry understood that and made environments for both. I suspect right now, since the big market is outside the hardcore programmer market, they're going to focus on the "it does magic with vague prompts" version before the "it's reliable and precise with specific prompts" one.
There are a lot of instances where you don't want to create an abstraction that will tie two disparate areas of the code together even if they happen to be using a similar pattern you want to copy. For example, when you expect their implementations to diverge in the future.
I have experienced enterprise codebases that have been DRY'd to the point they become ossified.
That's why I said "a lot of the time". Not always. And it's not really a problem to de-DRY things, literally just copy/paste and make the change you want.
The bigger problem in my eyes is when the requirements start to diverge people just add an if branch and soon you have a function/component that does 7 different things depending on how it's used and it's a big buggy mess.
It's also possible in many of these cases to identify sub-patterns you could abstract, to create a set of tools you can compose in different ways in order to satisfy the different use cases. Instead of one function/component you make multiple, and use them together.
All this stuff is just basic programming but I've mostly given up trying to preach about it. Most people don't care, and even if they did care they just don't have the talent to write really good code. It's rare to find a dev who does really solid work. In my experience you either do it because that's who you are, or nothing I say will make any difference.
It seems you didn't read the article. It's not whining about how people use or write custom attributes. It's whining about how they're implemented in the language.
And I wouldn't really describe it as whining, I thought it was an interesting article that rases valid points and suggests a solution.
The 2nd half of the article is an explanation of the problem of reading enums referenced in attributes, specifically about how it impedes performance, which I am directly discussing, both in this thread and https://news.ycombinator.com/item?id=48373294
The author is saying the .NET devs did a bad job implementing that, they are not saying you shouldn't use it. So you talking about using attributes is irrelevant to the article, it has nothing to do with developers using attributes nor how they do so.
reply