dandi8

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.

How do abstractions help with that? Can you tell, from the symptoms, which “level of abstraction” contains the bug? Or do you need to read through all six (or however many) “levels”, across multiple modules and functions, to find the error?

I usually start from the lowest abstraction, where the stack trace points me and don’t need to look at the rest, because my code is written well.

It’s only as incomprehensible as you make it.

If there are 6 subfunctions, that means there’s 6 levels of abstraction (assuming the method extraction was not done blindly), which further suggests that maybe they should actually be part of a different class (or classes). Why would you be interested in 6 levels of abstraction at once?

But we’re arguing hypotheticals here. Of course you can make the method implementations a complete mess, the book cannot guarantee that the person applying the principles used their brain, as well.

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).

It makes me sad to see people upvote this.

Robert Martin’s “Clean Code” is an incredibly useful book which helps write code that Fits In Your Head, and, so far, is the closest to making your code look like instructions for an AI instead of random incantations directed at an elder being.

The principle that the author of this article argues against seems to be the very principle which helps abstract away the logic which is not necessary to understand the method.

public void calculateCommissions() {
  calculateDefaultCommissions();
  if(hasExtraCommissions()) {
    calculateExtraCommissions();
  } 
} 

Tells me all I need to know about what the method does - it calculates default commissions, and, if there are extra commissions, it calculates those, too. It doesn’t matter if there’s 30 private methods inside the class because I don’t read the whole class top to bottom.

Instead, I may be interested in how exactly the extra commissions are calculated, in which case I will go one level down, to the calculateExtraCommissions() method.

From a decade of experience I can say that applying clean code principles results in code which is easier to work with and more robust.

Edit:

To be clear, I am not condoning the use of global state that is present in some examples in the book, or even speaking of the objective quality of some of the examples. However, the author of the article is throwing a very valuable baby with the bathwater, as the actual advice given in the book is great.

I suppose that is par for the course, though, as the aforementioned author seems to disagree with the usefulness of TDD, claiming it’s not always possible…

I meant this:

The biggest one for me is that most of the games come out on PC eventually anyway, and will generally run at higher resolutions and frame rates.

Did you edit the comment? I could have sworn there was the word “issue” in there, originally.

Is it an issue, though?

Edit: The whole comment was just a misunderstanding.

Joplin itself is AGPL. Unfortunately, Joplin Server is under “JOPLIN SERVER PERSONAL USE LICENSE”.

While I really like Joplin, I’m thinking of making the switch to something fully open source.

Hopefully this will enrage the users enough to go and actually vote against Trump.

While that sucks, it’s only some games, and AFAIK they only rely on Gog Galaxy for the multiplayer features sometimes, and maybe achievements.

I’m also still holding out hope they’ll come out with a Linux version of GOG Galaxy. For now, for my single player gaming purposes, running the games using Lutris (or Heroic, which I’ve heard is even better for this) is good enough for my Linux gaming needs.

I think GOG gets better and better as a place to buy games.

I’m a die-hard fan just for the DRM-free offline installers they provide, but the game selection has been consistently getting wider, to the point where many AAA games release on GOG on day one.

The deals are also generally nice.

Can’t easily download offline installers, though.

They refused to pull out of Russia when it invaded Ukraine, though, so they’re shitty in other ways.

About 30 PLN for a standard seat in Poland, but that’s not really going to tell the whole story without looking at things like the median income, average prices of other goods etc.

For some reference, that’s the price for a month of standard Netflix over here.

American cinema prices are not the only cinema prices.

Does this really make it any less worthy of criticism, though…?

Interesting! Out of curiosity, what is the source? Is there a breakdown per role?

It’s no more a risk than throwing more developers at it when they’re not needed.

“Too many devs“ can, and often is, a significant bottleneck in and of itself. The codebase may simply not be big enough to fit more.

Besides, I still don’t see what all those additional engineers would actually be doing. “Responding to incidents” presupposes a large number of incidents. In other words, the assumption is that the application will be buggy, or insecure enough, that 30 engineers will not be enough to apply the duct tape. I stand by the claim that an application adhering to modern standards and practices will not have as many bugs or security breaches, and therefore 30 engineers sounds like a completely reasonable amount.