magic_lobster_party

Do you know why?

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

Even when computers did improve and became able to handle Vista people weren’t willing to change their minds about it. Windows 7 had a 1GB memory requirement. Why didn’t more people use Vista right before the Windows 7 launch?

Vista shows how important the initial reputation is. Everybody had made up their mind to hate it, even if the hate wasn’t fully justified. There wasn’t much Microsoft could do about it, other than releasing Windows 7.

Windows 8 on the other hand was genuinely bad.

Windows 7 recovered from the disaster of Vista. Windows XP recovered from Me. It has been a bumpy ride for a long time.

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

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

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.

In 99% of the cases, inheritance can easily be replaced with composition and/or interfaces. Abstract classes tend to cause hard dependencies that are tough to work with.

I’m not sure why you would use abstract classes without data. Just use interfaces.

So things like abstract classes are mostly absent from my codebase.

I believe the consensus nowadays is that abstract classes should be avoided like the plague even in languages like Java and C#.

In my team we use both Linux and Mac (I don’t want to disclose my company, but it’s in Sweden). IT isn’t entirely happy about some of us using Linux because it’s more difficult for them to administer the computers (i.e. install spyware), but so far they’ve been unsuccessful in making us switch.

I’ll revise my opinion when Valve changes to a more overtly predatory model of capitalism

I believe as long they’re not publicly traded )and Gabe is in charge), that’s not a concern.

Being public (or owned by a publicly traded company) tend to bring out these nasty traits. It’s more about finding ways to bring value to shareholders than the customers.

For each steam power there are thousands of similar inventions that never see the light of practical use cases. We just remember those that had significant breakthroughs.