chipdart

> cannot agree. It's just "feel-good thinking."

Not really. There's nothing inherently special about people who dedicated enough time to learn a subject.

> "Everybody can do everything." Well, that's simply not true. I'm fairly sure you (yes, you in particular) can't run the 100m in less than 10s, no matter how hard you trained.

What a bad comparison. So far in human history there were less than 200 people who ran 100m in less than 10s.

I think you're just reflecting an inflated sense of self worth.

> I think the ML people want to get (a narrow band) of stuff done and ivory towered people want to understand a prove things. ML is applied mathematic. Both are needed.

I don't agree. First of all, ladder-pulling in math is observed at all levels, not only cutting-edge stuff. Secondly, it's in applied mathematics where pure math takes a queue onto where to focus effort. See how physics drives research into pure math.

> I agree with the sentiment of this. I think our obsession with innate mathematical skill and genius is so detrimental to the growth mindset that you need to have in order to learn things.

I would argue something different. The "skill" angle is just thinly veiled ladder-pulling.

Sure, math is hard work, and there's a degree of prerequisites that need to be met to have things click, but to the mindset embodied by the cliche "X is left as an exercise for the reader" is just people rejoicing on the idea they can needlessly make life hard for the reader for no reason at all.

Everyone is familiar with the "Ivory tower" cliche, but what is not immediately obvious is how the tower aspect originates as a self-promotion and self-defense mechanism to sell the idea their particular role is critical and everyone who wishes to know something is obligated to go through them to reach their goals. This mindset trickles down from the top towards lower levels. And that's what ultimately makes math hard.

Case in point: linear algebra. The bulk of the material on the topic has been around for many decades, and the bulk of the course material,l used to teach that stuff, from beginner to advanced levels, is extraordinarily cryptic and mostly indecipherable. But then machine learning field started to take off and suddenly we started to see content addressing even advanced topics like dimensionality reduction using all kinds of subspace decomposition methods as someting clear and trivial. What changed? Only the type of people covering the topic.

> In my experience, the mess created using OOP is harder to untangle than the mess created using a functional approach.

OP complained about accidental complexity, not subjective takes on how hard it is to refactor code.

Even so, anyone who has any cursory experience with TypeScript projects that follow a functional style can tell you without any doubt whatsoever that functional style is incomparably harder to refactor than any "enterprise-grade" OOP.

> A. OOP as practically implemented for the last 25 years is glueing functions to state

I see you opt to go with a huge amount of handwaving over the question.

> Functions and structs.

That's what a class is, and thus OOP, except it supports information hiding and interfaces. So your alternative to OOP is... OOP?

> OOP is an industry of its own which generates a ton of incidental complexity.

I think you're confusing "OOP is used in projects and I've seen accidental complexity in projects" with "OOP generates accidental complexity".

The truth of the matter is that developers create complexity. It just so happens that the vast majority use OOP.

I challenge you to a) start by stating what you think OOP is, b) present any approach that does not use OOP and does not end up with the same problems, if not worse.

> What helped me was to track Sprint Volatility in addition to Sprint Velocity.

I dread to imagine the number of bike shedding meetings and planning poker it takes to change a 5 to a 3 or 7.

> I agree, this is a problem, but there should be a trivial solution: Users of the browser should pay a small amount of "money" for the product they use all day every day.

What a brain-dead idea. Having to pay for something does not affect the openness of a platform. You just create a de-facto tax that benefits no one at all.

> 1) does it though? It seems like the Google-specific parts of it are pretty ancillary to the whole experience

You're unwittingly describing the textbook definition of anticompetitive practices only made possible by abusing a dominant position.

> 2) how is it different to Apples integration with Safari?

Safari does not represent >65% of all web traffic. Also, there's the major liability of having a single ad company controlling the browser that the average internet user uses to browse the web.

> I think inexperienced developers write complex code because it's difficult to write simple code and they don't know how yet, not because they're trying to make it complex.

From what I've been seeing, inexperienced developers write complex code because they are trained with a bias towards accidentally complex code (i.e., how else would you show off design patterns), they have no experience in dealing with the tradeoffs of writing accidentally complex code, and they do not understand the problems they create for themselves and others by adding complexity where they do not need it.

I'd frame accidental complexity in the same class as dead code: inexperienced developers might be oblivious to the risk presented by codd that serves no purpose, but experienced developers know very well the ticking time bomb nature of it.

> I think it's especially bad advice with the "copy paste once is okay". You absolutely do not want multiple (even just two) copies of what's meant to be exactly the same functionality, since now they can accidentally evolve separately.

Hard disagree. Your type of misconception is the root cause of most broken and unmaintainable projects, and the root of most technical debt and accidental complexity.

People who follow that simplistic logic of "code can accidentally evolve separately" are completely oblivious to the fact that there is seemingly duplicate code which is only incidentally duplicate, but at its core should clearly be and remain completely decoupled.

More to the point, refactoring two member functions that are mostly the same is far simpler than refactoring N classes and interfaces registered in dependency injection systems required to DRY up code.

I lost count I had to stop shortsighted junior developers who completely lost track of what they were doing and with a straight face were citing DRY to justify adding three classes and a interface to implement a strategy pattern because by that they would avoid adding a duplicate method. Absurd.

People would far better if instead of mindlessly parrot DRY they looked at what they are doing and understood that premature abstractions cause far more problems than the ones they solve (if any).

Newbie, inexperienced developers write complex code. Experienced, seasoned developers write simple code. Knowing the importance of having duplicate code is a key factor.

From the article:

> Copy-paste is OK once. The second time you're introducing duplication (i.e., three copies), don't. You should have enough data points to create a good enough abstraction.

There's already a principle that synthesizes this: Write Everything Twice (WET).

It's a play on words to counter the infamous Don't Repeat Yourself (DRY) principle, which clueless but opinionated developers everywhere have used time and again to justify introducing all kinds of problems involving a combination of tight-coupling unrelated code, abstraction hell, adding three classes and an interface to avoid writing two classes, etc. This nonsense is avoided by tolerating duplicate but uncoupled code until the real abstraction and coupling needs emerge.

I still cringe at a PR that a former clueless junior developer posted, where in the name of DRY added a OnFailure handler which, instead of doing any error-handling and recovery logic, simply invoked OnSuccess, because "it's mostly duplicate code and this keeps the code DRY". Utter nonsense.

> They're a good idea, but not a substitute for knowing the rules.

It's a good thing no one made that claim, then.

The whole point is that were seeing people in this thread making all sort of wild claims on how it's virtually impossible to catch these errors in C++ even though back in reality there are a myriad of static analysis and memory checker tools that do just that.

Your average developer also knows how to type in a space character but still it's a good idea to onboard linters and automatic code formatters.

> So you're suggesting that people should just wrap everything in Arc (...)

You're the only one who managed to come up with this nonsense. No one else did, and clearly you did not pick that from what I wrote because I definitely did no wrote that.

Please refrain from slippery slope fallacies.

> No one really claimed it was easy to learn.

It's a great example of unintended comedy the fact that the comment right below yours is literally "Rust is easy to learn and user friendly."

https://news.ycombinator.com/item?id=42162676

> Well there's your problem. Rust does look like a semi-colon language, that's intentional, but if that's all you understand you're probably going to struggle.

This is a silly point to make. What makes a C++ programmer a C++ programmer is not an uncanny ability to find a semicolon on the keyboard. It's stuff like using low-level constructs, having a working mental model of how to manage resources at a low level down and how to pass and track ownership of resources across boundaries. This is not a syntax issue.

It's absurd. You have people claiming that Rust is the natural progression for C++ programmers because their skillsets, mental models, and application domain overlap, but here are you negating all that and try to portray it as a semicolon issue?

> Those tools can't reliably identify undefined behaviour.

I'm sorry, can you explain what leads you to believe your hypothetical scenario is an argument rejecting the use of static code analysis tools?

I mean, I'm stating the fact that there are many many tools out there that can pick up these problems. This is a known fact. You're saying that hypothetically perhaps they might not catch each and every single hypothetical case. So what?

> Anyone who has managed to become proficient in C++ is smart enough to be proficient in Rust.

I'm not sure you're paying attention. The people who are saying Rust is too hard are the Rust community itself. They said so in Rusty's annual survey. The ones who participate in it are Rust users who feel strongly about the topic to participate in their governance.

It's Rust users who say Rust is too hard. There is no way around this fact.

> I was responding to "I'd love to hear exactly how a monolith application is guaranteed to perform better, with details."

I asked nothing about Netflix. My question was directed at your remark regarding monoliths vs microservices.

Now, can you answer the question?

> Which is the point TFA is making.

Again, the point is wrong in more than one way.

You don't simply add undefined behavior. It's wrong, and buggy code. Onboard a static code analysis tool like cppcheck to tell you when you messed up.

It takes far less work to onboard any of these tools than it takes to write a sentence in a blog post.

> Rust is easy to learn and user friendly. But if you are stuck in your ways (...)

It's high time that people in the Rust community such as you just stop with this act.

The Rust community itself already answered that they find "Rust too difficult to learn or learning will take too much time" as a concern to not use Rust. The community also flagged Rust being too difficult as one of the main reasons they stopped using Rust.

https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...

> This just seems to be the standard excuse I read any time someone has a critique of Rust.

The guys who parrot this blend of comments don't seem to be aware that cognitive load is a major problem, not a badge of honor.

> I think it's telling that whenever someone raises concerns about any element of Rust, no matter how constructively (...)

I'm far from a Rust expert, but to me if someone is whining about how it is hard to track lifecycle rules of an object because they are passing it through long chains of function calls across all sorts of boundaries, what this tells me is that you're creating your own problems that you could avoid if you simply passed the object by value instead of by reference. I mean, if tracking life cycles is a problem then why not prevent it from being a problem? Not all code lives in the hot path. I'm sure your performance benchmarks can spare a copy somewhere.

> I have memorised the UB rules for C.

Why? What's wrong with using one of the many static code analysis tool to tell you about them if/when they appear?

From the article:

> This is painful because I am an experienced C++ programmer, and C++ has this exact problem except worse: undefined behavior. In the worst case, C++ simply doesn’t check anything, compiles your code wrong, and then does inexplicable and impossible things at runtime for no discernable reason (or it just deletes your entire function).

This is completely wrong, even in the "not even wrong" territory. It reads like an attempt to parrot a cliche without having any idea what it means. "Undefined behavior" just means the standard does not define what is the expected behavior, and purposely leaves implementations free to implement it how they see fit. This means crashing the app or sending an email to the pope.

In practical terms this means developers should not write code that triggers undefined behavior, and treat the code that does as errors requiring a fix. Advanced users can lean on implementation-defined behavior from compilers to add some expectation to the behavior, but that's discouraged.

It's so strange how someone calling themselves a seasoned C++ developer fails to understand such a basic aspect of the language.

The important tidbit is that a) it's completely wrong to parrot "undefined behavior" on "C++ doesn't check anything", and b) if you code triggers undefined behavior without your knowledge then you just broke the code and wrote a bug out of your own ignorance.

To make matters worse, there are a myriad of code checkers for C++ that catch undefined behavior and even some classes of safety errors. Take for instance cppcheck. Why is the blogger whining about undefined behavior and "c++ not checking" when adding cppcheck to any project is enough to detect most if not all cases?

> It's not guaranteed, but much fewer points of failure.

Can you explain where this is relevant to buffering issues?

Also, you are very wrong regarding failure modes. The larger the service, the more failure modes it has. Moreover, in monoliths if a failure mode can take down/degrade the whole service, all other features are taken down/degraded. Is having a single failure mode that brings down the whole service what you call fewer points of failure?

> It's sad that tech employees won't collaborate to push back on management.

Some employees are like the Boxer character from Animal Farm[1]. I vividly recall Amazon employees complaining about Amazon's new leadership principle "strive to be Earth's best employer", and once the job cuts started to hit home there were employees attacking fellow employees with jabs such as "being the Earth's best employer means those who do not like it should just leave", and "you're whining here but 10 would eagerly take your place".

One of the biggest scams is making you believe that your fellow employees are looking out for your best interests, as there were no backstabbers around.

[1] https://en.wikipedia.org/wiki/Boxer_(Animal_Farm)

> There's almost zero chance they backtrack on this. Amazon is looking to reduce costs, this is fairly cheap since people will quit. Anyone who is irreplaceable will be exempted.

This was very clear from the start, even the timing of mandating RTO while announcing mass layoffs. I don't know what compells anyone within Amazon to focus on the red herring.

Don't post rage bait from the Telegraph. This isn't Twitter.

> The only service performing well is a closed source one that could simply use a real chess engine for questions that look like chess, for marketing purposes.

That conspiracy theory holds no traction in reality. This blog post is so far the only reference to using LLMs to play chess. The "closed-source" model (whatever that is) is an older version that does worse than the newer version. If your conspiracy theory had any bearing in reality how come this fictional "real chess engine" was only used in a single release? Unbelievable.

Back in reality, it is well known that newer models that are made available to the public are adapted to business needs by constraining their capabilities and limit liability.