Live data from Hacker News

Slop is not necessarily the future

greptile.com

361–370 of 512 posts

Re: Slop is not necessarily the future

#361

Earlier quoted context omitted.

We have modern architecture crumbling already less than 100 years after it has been built. I know engineering is about tradeoffs but we should also acknowledge that, as a society, we are so much used to put direct economic cost as the main and sometimes only metric.

You would be very unhappy if you had to live in a house as built 100 years ago. Back then electric lights were rare. even if you had them the wiring wasn't up to running modern life. my house is only 50 years old and it shows signs of the major remodel 30 years ago, and there are still a lot of things that a newer house would all do different that I sometimes miss.

I've lived in a 100 year old house and and in a brand new house, they both had issues. That also both had advantages too. Oddly the older house had a better designed kitchen. Our lives change over time and our housing has to adjust to that too.

Re: Slop is not necessarily the future

#362
post #51

Earlier quoted context omitted.

I respect your opinion and especially your honesty. And at the same time I hope that you will some day be forced to maintain a project written by someone else with that mindset. Cruel, yes. But unfortunately schadenfreude is a real thing - I must be honest too. I have gotten to old for ship now, ask questions later projects.

I'm in camp 1 too. I've maintained projects developed with that mindset. It's fine! Your job is to make the thing work, not take on its quality as part of your personal identity. If it's harder to work with, it's harder to work with, it's not the end of the world. At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies. I think camp 2 would rather see one beautiful thing than ten use…

> I think camp 2 would rather see one beautiful thing than ten useful things.

Unashamedly, I would, but this is a false dilemma. We can have ten beautiful and useful things.

The thing that drives the camp 2 folk crazy is that often it would have taken no extra effort (or perhaps even less effort overall) to make a good version of the thing but the people who made thing simply couldn't be bothered.

The attitude you're describing here has led directly to our world being full of profoundly disappointing objects that proliferate because they meet a minimum bar of usefulness.

People don't like the minimum bar. They'll take it if it's the only thing on offer, but they like better things.

Re: Slop is not necessarily the future

#363
post #162

People are not emotionally ready to accept that certain layers of abstraction don’t need as much care and effort if they can be automated. We are at the point where a single class can be dirty but the API of the classes should be clean. There’s no point reviewing the internals of a class anymore. I’m more or less sure that they would work as intended. Next step is that of a micro service itself. The api of that micro…

"The only reason people disagree with me is because they are emotionally deficient."

It goes from "llms can do everything as well or better to a human" to "quality doesn't really matter" really fast.

Re: Slop is not necessarily the future

#364

Earlier quoted context omitted.

The general public does not know how to identify or care about the pipes in the walls. They do care when they bust and cause tens of thousands of dollars of damage. Thats why they hire someone with a keen eye to it to act on their behalf.

The general public does not know how to identify or care about good code. They do care when their data gets leaked or their computer gets hacked or their phone gets ransomware. That’s why they hire software engineers, who are supposed to care about the quality of the code they ship.

Agreed. No one need care about obsessively neat and orderly code, but there becomes a point where very real world issues surface that users actually care about. Contrary to some of the opinions here. Rushing out vibeslop at rapid pace will eventually have consequences.

Re: Slop is not necessarily the future

#365
post #275

Earlier quoted context omitted.

Regulation can cause freedom to be balanced differently between parties. For example, regulating smartphone manufacturers can result in more freedom for users. It’s not true that regulation necessarily reduces freedom overall (to the extent that that can even be graded). Just like rights, freedoms aren’t absolute, and one’s freedom often impinges on someone else’s freedom.

The increase of freedom of the users is an indirect side effect, intentional or not, which, as you put it, can happen, or not. But a direct effect, which is guaranteed to happen, is the loss of freedom of the manufacturer. Whether that's a good thing, that's another topic.

The increase of freedom of the slaves is an indirect side effect. But a direct effect, which is guaranteed to happen is the loss of freedom of the slaveholder.

Re: Slop is not necessarily the future

#366
post #118

Earlier quoted context omitted.

"I have an opinion and everyone on the planet agrees with me, if you disagree, you don't matter" is not a useful insight, and is, in fact, far more emotional and dismissive than any of the replies to it.

That's a horribly broken misrepresentation of what was said in the original post. If that's what you took away from it, you're not reading carefully or critically.

No, that's exactly what the original post said.

> No one has ever made a purchasing decision based on how good your code is.

This has since been edited (I suspect OP later realized how ridiculous of a claim it was) but it's an objectively false statement that blindly projects OP's stance on software quality onto the entire population.

People have, in fact, stopped using software because it was too slow or buggy. I've done it, many others have done it. To give you a real example, I'm a fan of JetBrains IDEs functionality-wise, but I've been seriously considering moving away from them due to how bloated and unoptimized they've become in recent years - when your IDE feels more sluggish than one built on top of Electron, something has gone seriously wrong. I don't have to actually read the code itself to know it's bad code, I can feel it by simply using the software.

Just because you don't care doesn't mean others don't. Modern society was not built by people who didn't care about their craft, nor was it built by designing everything with the lowest common denominator in mind.

Re: Slop is not necessarily the future

#367

Earlier quoted context omitted.

You might be missing the point of the quote. He's not talking about whether it is commonly done. He's talking about the mentality that justifies sacrificing the aesthetic and artistry, in favor of things like "dimensional stability". He is giving a reason why it shouldn't be done, and people can disagree about whether the reason is a good one.

He's saying that carpenters who make nice things wouldn't use a material like that, but they objectively do and this doesn't sacrifice the aesthetic or artistry. He specifically calls out the use of the material in a place it wouldn't be seen as something that the carpenter making beautiful cabinets wouldn't do, but that's actually something they absolutely do. He's trying to argue some other point by way of this ana…

> He's saying that carpenters who make nice things wouldn't use a material like that

If they do, then they aren't making truly great things. It's as simple as that really.

If you cut corners, even if you think nobody will notice, some people will, and your product will never be truly great. Steve understood that.

Re: Slop is not necessarily the future

#368

I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…

Code quality is directly related to how easy it is to modify without creating bugs which customers absolutely DO care about. I've read about an EMR product that was such spaghetti code every bug fix was likely to create 2 new bugs. I suspect this is a major reason Siri has not had any major new features in forever.

Re: Slop is not necessarily the future

#369

Earlier quoted context omitted.

You might be missing the point of the quote. He's not talking about whether it is commonly done. He's talking about the mentality that justifies sacrificing the aesthetic and artistry, in favor of things like "dimensional stability". He is giving a reason why it shouldn't be done, and people can disagree about whether the reason is a good one.

He's saying that carpenters who make nice things wouldn't use a material like that, but they objectively do and this doesn't sacrifice the aesthetic or artistry. He specifically calls out the use of the material in a place it wouldn't be seen as something that the carpenter making beautiful cabinets wouldn't do, but that's actually something they absolutely do. He's trying to argue some other point by way of this ana…

He's saying "carpenters who don't do X are craftsmen". And you're saying "But other carpenters do X." That's true, but those other carpenters are not craftsmen.

Re: Slop is not necessarily the future

#370

Earlier quoted context omitted.

> Treat code design and architecture as the thing that lets your slop canons (90% of engineers even pre-ai) move fast without breaking things I'm currently of the opinion that humans should be laser focused on the data model. If you've got the right data model, the code is simpler. If you've got the relevant logical objects and events in the database with the right expressivity, you have a lot of optionality for pivo…

How do you even converge on the right data model without refining code? Elegant code and elegant data model are the exact same thing!

"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."

Lots of people try to make their code better by revising their procedures and don't even think about changing their data model, and generally fail. You might not be able to change your data model without changing your code, but they're different activities.

Post reply on HN