A "Pareto front represents the set of solutions where no solution outperforms any other solution in the set at every objective, and every solution not in the set is outperformed by at least one solution in the Pareto front in every objective"

I appreciate your work to make this topic accessible in an interactive format. Somehow, in this case, it's too much for me.

I think the ratio of information to interactivity is too low. It's like I have to push around a tiny keyhole to slowly access information. The graphs look fun, but their fancifulness is distracting me.

I don't usually mind interactivity, but I think usually it is embedded in the text, instead of gating it, if that makes sense.

I get that this form of presentation may be great for many people, but for my brain, it makes it extremely hard to engage with the content.

LLMs love this pattern. Whether one put it into this text, or the author soaked it up and now used it himself, who knows. But it is one of the few things in the post that gives me the ick.

And then, there's the verbosity.

If I had to guess, an LLM was involved, but the author did a good job with manual writing and editing, too.

I'm taking issue with the combination "load-bearing seam". It's a bad metaphor, because seams are usually structural weak points in the physical world, and not load-bearing in the sense that this modifier is usually used. (Seams need to bear loads and stresses to do their job, but so do walls; yet, we do not call all walls load-bearing. We mean something extra when we say that, something that seams don't do.) Even if we were talking about seams in the well-defined software sense, as opposed to the metaphorical one, you still get a mixed metaphor as a result that I find extremely awkward and grating. It doesn't have to be. There are so many ways to highlight the importance of something without calling it "load-bearing".

I understand that you don't see it that way or don't care, but to me, the result is thoughtless, careless and vapid. Bad metaphors put little holes into a text, they leave eddies of confusion where meaning should be, they look load-bearing while actually being weakening, they're like a fart in the elevator that should lift the reader's understanding.

Note that I'm not calling into question that seams may be well-defined in some software contexts, or that "seam" and "load-bearing" can be valid metaphors on their own, as you describe. I think you might have misunderstood me that way. I'm only calling out, and fed up with, the bad style that permeates LLM-generated prose like the whiff of something not quite digested.

It's not this particular case that irks me, but what it exemplifies. I wouldn't mind so much if similar things to this weren't there everywhere, every single day.

If it doesn't bother you, I'm happy for you.

It communicates an absence of thought and awareness, blind groping at building blocks without understanding. It's borderline vapid, and quite annoying.

The combination of both I usually find in text generated for me by LLM, and so far, it serves as a good signal for density of information and, inversely, not-quite-right ideas and their connections. (That's not to say it's pervasive, but below the surface, the quality of LLM text as a medium is often not great.)

There may be well-written text of non-trivial length generated by LLMs, but so far I haven't knowingly encountered any, with or without em-dashes. Human editing remains very necessary.

That's what this thread is about, I thought.

Point being: your comment made me sad and I needed to lighten myself up a bit.

There is a difference between saying "I worry that these rules are too open for interpretation" and "these rules only pretend to be sensible and fair, they are clearly intended as weapons made in bad faith, the jury is rigged and I will not even consider any other interpretation". The first point is open and constructive, the other rejects other perspectives outright and dismisses the possibility of understanding and compromise. You're making the first point; the comments I replied to above seem essentially to be doing the latter, and that's what I'm arguing against.

I don't really see a difference between applying maximalist intepretations of rules to treat people unfairly on the one hand, or on the other, using maximalist interpretations of rules to dismiss good-faith rules _a priori_, that is, to use a certain reading of rules to accuse people of conspiring to use them in a certain way. How on earth are you going to make any rule that is immune to either?

In fact, I think both are the exact indentical failure to not be a dick, by the same method, just approached from opposing sides. They're born of the same inflexibility, the same uwillingness to extend other people some credit, and I do not envy anyone who has to deal with either of them as a result of trying to bring people together for some common good.

I do think you're simply reading their rule in a way that's not intended by them. Could the rule be written to convey the intent more clearly? Yes, I think so. Is it only their own responsibility how the rule is interpreted? No, I don't think so.

The hacker news guidelines ask us to:

> respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

This is good advice in general. It is your choice to pick an the interpretation that you disagree with the strongest, and subsequently use it to condemn them: "puts me off entirely", "no room for nuance", and (paraphrasing:) it's on them to prevent me from interpreting the rule in the most severe way.

No. The spirit of the rule is clear. The nuance is there. What you do with it, that is all you.

I don't think that's too much to ask, just like it's generally considered preferable to not chew with your mouth open when in company, or talk to people with food in your mouth.

They even acknowledge that they expect these rules to not be followed all the time.

I'm surprised that you read it as a general prohibition of being surprised. ;)

Edit: Sorry, wrote my reply before I saw your substantial edits where you clarify your position and distinguish between "positive" and "negative" surprise. I agree there's a better way express surprise. The rule clearly wants people to avoid putting other people down by creating a feeling of "wow, how can you not know this". That's the spirit of the rule, and I guess it could be expressed better. I don't think they'd have a problem if someone managed to turn the surprise into a positive, but to do that, it's good to be mindful that it's often perceived negatively.

That would be the"strongest interpretation" of OPs comment, which the local guidelines prefer us to respond to.

Of course there should probably be a way to limit waste, but putting all financial cost onto a single person is a way to effectively limit freedom of information to the point where it contradicts and undermines the whole idea behind it. That's one of the reasons why this change is being proposed, and it is not a stretch to call this nefarious.

> (Hipp) How do I pronounce the name of the product? I say S-Q-L-ite, like a mineral.

> But I also hear a lot people say, "Sequel lite and SQL lite." You know, I don't care. Whatever comes off of your tongue easily is fine with me.

> (Q) But the official correct way is S-Q-L-ite?

> (Hipp) Yes, like a mineral.

https://www.listennotes.com/podcasts/the-changelog/why-sqlit...

So, he means SQL-ite, but doesn't want to proscribe this as the only way people should say it. I like all of that.

Maybe we should follow his example.

Common pronunciations allow you to stay perfectly ambiguous about where the L goes, which aligns quite well with the name as spelled. If you do it right, nobody can tell if you're saying sequel-ite or sequel-lite or seque-lite on the one hand, or S-Q-L-ite or S-Q-L-lite or S-Q-lite on the other.

AFAIK there is no official word on how the name is intended to be read or said.