magic_lobster_party

Do you know why?

The type is dynamic. It can be whatever you wish.

Pac Man was younger when Halo was released than Master Chief is today.

It’s not like it’s going to consume electricity like Bitcoin.

PoW was first conceptualized as an anti spam method. It’s just a little overhead to make it expensive to make DOS attacks. This makes perfect sense.

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

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

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

I think comments are good as a last resort when it’s difficult to communicate the intention of the code with other means.

If I find code that’s hard to understand, I’ll first try to find better variable or function names. Often this is enough.

If it’s still too difficult to understand, I try to restructure the code to better communicate the flow of the code.

If that doesn’t help (or is too difficult), then I might add a comment explaining key information that’s difficult to understand from the code.

There’s also the $100 million development cost

I liked when they said “it’s concording time” and concorded all over the place.

Turn on a lamp

The only problem is to ensure the entire team agrees to only use it like an interface and nothing else. But I guess that’s the only proper way to do it in C++, for now.

In your example, the declaration of ArrayList look like:

public class ArrayList extends AbstractList implements List {
}

The dependence on AbstractList is public. Any public method in AbstractList is also accessible from the outside. It opens up for tricky dependencies that can be difficult to unravel.

Compare it with my solution:

public class ArrayList implements List {
    private AbstractList = new AbstractList();
}

Nothing about the internals of ArrayList is exposed. You’re free to change the internals however you want. There’s no chance any outside code will depend on this implementation detail.

If the lists have shared components then that can be solved with composition. It’s semantically the same as using abstract classes, but with the difference that this code dependency doesn’t need to be exposed to the outside. This makes the dependency more loosely coupled.

I usually break it out using composition if that’s ever needed. Either by wrapping around all the implementations, or as a separate component that is injected into each implementation.

Ask Bjarne to add interfaces enough many times until he gives in.

On a more serious note, I’m not exactly sure what the best C++ practice is. I guess you just have to live with abstract classes if you really want interfaces.