dandi8

Kinda disappointing. I was hoping for a single-player-focused title.

That’s not creepy or weird, that’s horrifying.

Except “mass” is not useful by itself. It’s not a chair factory where more people equals faster delivery, just like 9 women won’t deliver a baby in a month. I wish companies understood this.

Isn’t the format literally just Twitter?

Are you complaining that older versions of Java don’t have the features of newer versions of Java…?

For me, as primarily a backend dev, the argument was that it’s a framework, unlike React, so you get an everything-in-one solution which is quite easy to setup and use.

Given that Google still hasn’t killed this one yet, it’s also a mature platform with plenty of articles online on how to use it.

IIRC the license was also better than React’s, at least last time I checked.

Not sure on what the landscape looks like today, but when I was making the choice, the internet didn’t seem to consider other solutions to be competitive with either React or Angular.

Over my dead body.

Not sure the son would see it the same way…

FYI there’s a fully playable unofficial port for Jak 1 and 2, and they’re working on the 3rd one: https://opengoal.dev/

deleted by creator

Pegasus?

I feel like I’d believe it if the headline was about John McAfee.

In my experience LLMs do absolutely terribly with writing unit tests.

IMO this perspective that we’re all just “reimplementing basic CRUD” applications is the reason why so many software projects fail.

Good abstractions are important for the code to be readable. An AbstractEventHandlerManager is probably not a good abstraction.

The original commenter said that their code was “generic with lot of interfaces and polymorphism” - it sounds like they chose abstractions which hindered maintainability and readability.

Is it possible that you just chose the wrong abstractions?

I never claimed it’s not important, I’m just saying it’s not relevant here, as there is no context to where this method was put in the code.

As I said, it might be top-level. You have to mutate state somewhere, because that’s what applications ultimately do. You just don’t want state mutations everywhere, because that makes bad code.

Clean code does not prevent writing bad code, it just makes it a bit easier to write good code.

OF COURSE you can follow the principles and still write bad code, because so much more goes into it, including skill.

A giant method with everything laid out, potentially mixing abstractions sounds like a nightmare to me. It leads to cognitive overload.

You’re nitpicking.

As it happens, it’s just an example to illustrate specifically the “extract to method” issues the author had.

Of course, in a real world scenario we want to limit mutating state, so it’s likely this method would return a Commission list, which would then be used by a Use Case class which persists it.

I’m fairly sure the advice about limiting mutating state is also in the book, though.

At the same time, you’re likely going to have a void somewhere, because some use cases are only about mutatimg something (e.g. changing something in the database).

And yet, outdated comments are far, far more common than outdated function names.

Also, if you’re changing a comment which explains the “what”, you should likely change the method name, as well.

It’s important for the client to know what the method does by looking at the name, so why would you duplicate your effort?