magic_lobster_party

For me it’s the opposite. No money no deal.

deleted by creator

Let me guess, the coins can only be bought in bundles. The bundles are deliberately made so that no matter how you spend the coins, you’ll always have 1 or 2 coins left. Which makes you encouraged to buy another bundle to make all your moneys worth.

In case you’re wondering about the down votes, many think Clean Code is not a good book. It got a few good advice, but it also got bad advice disguised as good advice.

I don’t think switch statements should always be avoided. There are cases where polymorphism makes things more difficult to maintain. Saying polymorphism should be used over switch statements is not a good advice.

Here’s an article going into more detail why we should stop recommending Clean Code: https://qntm.org/clean

For me I have the habit of doing findFirst because determinism is important where I work. But I agree with you if determinism is not of importance.

Looks like it’s JavaScript, but in Java I would prefer to use the Stream API, something like this:

return availableDrivers.stream()
    .filter(driver -> calculateDistance(rider, driver) < 5)
    .filter(driver -> isPreferredVehicle(rider, driver))
    .filter(driver -> meetsRiderPreferences(rider, driver))
    .findFirst()
    .orElse(null);

Then we have:

private boolean meetsRiderPreferences(Rider rider, Driver driver) {
    if (driver.rating >= 4.5) {
        if (rider.preferences.includes('Premium Driver')) {
              return driver.isPremiumDriver;
        } else {
              return true;
        }
    } else if (driver.rating >= 4.0) {
        return true;
    } else {
        return false;
    }
}

This increases the separation of concern in a neat way, and it becomes more clear what the for loop does at a glance (get the first driver satisfying a set of conditions). The more complicated logic is isolated in meetsRiderPreferences, which now only returns true or false. Reading the method is more about making a mental map of a truth table.

It’s also easy to expand the logic (add more filter conditions, sort the drivers based on rating and distance, break out meetsRiderPreferences into smaller methods, etc.).

Not sure how the equivalent in JavaScript would look like, but this is what I would do in Java.

There’s C++/CLI if you want to combine garbage collection with the pain of C++

My body is Water Temple:

• Pain
• Pain
• Pain

Link to the original artist because her art is amazing: https://www.lilyseikajones.com/

I relate. Technical debt is by far the most common source of frustration in my career. It’s that code someone inexperienced wrote years ago that no one longer understands, but it still needs to be maintained. Often the code is also unnecessarily convoluted, so there’s a high risk of introducing new bugs when working with it.

I’ve recently managed to refactor such code recently. No one could work with it with confidence, it was slow and it was buggy. A lot of the code was also completely unnecessary (like 100 line convoluted mess that could be done with 1 line of code).

Now someone else in my team who has never worked with this code wrote a major addition to it without much assistance, so I take it as a sign that my refactor is a great improvement.

What’s happening is that support from VC money is drying up. Tech companies have for a long time survived on the promise that they will eventually be much more profitable in the future. It doesn’t matter if it’s not profitable today. They will be in the future.

Now we’re in a period where there’s more pressure on tech companies to be profitable today. That’s why they’re going for such anti consumer behaviors. They want to make more with less.

I’m not sure if there’s a bubble bursting. It could just be a plateau.

Isn’t problem solving mostly put things together of what you’ve learned before?

I didn’t read everything, but I mostly agree with the author, especially on this point:

While you can definitely abuse exceptions, functional-style error values are not a one-size-fits-all solution.

There are time and place for both. I think exceptions are good for bigger errors. Like database connection errors. Things that shouldn’t happen without any easy backup plan. Those errors might need to be escalated as high as possible where proper action can be made (like resetting the database connection and everything relying on it).

Functional style is great for smaller stuff. Like key not found in hash maps. In many cases there might be good defaults that can be used instead.

It’s a concept of a plan

Haven’t read through this, but this sounds like what C++ is to C. I’m not sure adding more complexity and features to an already complex language is the right way forward. What is needed is a language that cuts down all the burden that has accumulated in C++ over 3 decades.

Something like Zig sounds like the better path forward to me. A completely new language from scratch with cross interoperability to C++. I’m surprised it’s not mentioned even once in the page.

The great thing about Slack is how easy it is to make automations. I guess this one just reads RSS feeds.

At my work we have automations notifying us about production errors for example.

I like to mix between OOP and FP for different levels. OOP is great for higher architectural problems. FP is great for everything under it.

And yes, inheritance was a huge mistake. Just use composition and interfaces instead.

I agree, and I count that as “key information that’s difficult to understand from the code”.

IMO, comments should be used to provide value to the code. If they’re used too much, then readers of the code will more likely stop reading them altogether. They already got what they need from the code itself and the comments usually don’t add much value.

If they’re sparse, then that’s a good indication they’re important and shouldn’t be missed.

I think JSON is more robust than XML by now. Mostly due to its simplicity. There are few reasons why anyone would pick XML over JSON these days.

It makes you want to die on a hill