Yes, I think so. The downside with Python comes when refactoring the code. There’s always this double checking if the code is correctly indented after the refactor. Sometimes small mistakes creep in.
It’s really hard to tell when Python code is incorrectly indented. It’s often still valid Python code, but you can’t tell if it’s wrong unless you know the intention of the code.
In order languages it’s always obvious when code is incorrectly indented. There’s no ambiguity.
I don’t like YAML because it’s overly complicated. The specification is like 80 pages long. How the hell did they think that was a good idea?
JSON on the other hand is super simple. It doesn’t do more than it needs to.
Just compare this: https://yaml.org/spec/1.2.2/
With this: https://www.json.org/json-en.html
The entire JSON specification is shorter than just the table of contents of the YAML specification!
Another thing I like about JSON is that you can format it however you want with the whitespace. Want everything on one line? Just write everything on one line!
If data can be represented as a JSON, then there’s generally only one way to represent it in JSON (apart from whitespace). In YAML the same data can be represented in 1000s of different ways. You pick one.
It was featured in a PlayStation showcase last year. The most notable part of the trailer was a burger. I’m not kidding.
There’s also the $100 million development cost
Joseph Anderson has made a similar trolley challenge. It’s a cinematic masterpiece: https://youtu.be/RgqRIFj4Zrk
I liked when they said “it’s concording time” and concorded all over the place.
Right now I’m mostly using the Xbox One controller (on PC). It’s a controller that feels really good to hold. No weird gimmicks like motion control either. I think it’s one of the all time greats.
Runner up is GameCube.
Shit in terms of having no players and being pulled back after just two weeks.
From what I understand, the game itself was alright. It had no major technical or gameplay problems. At least the team of programmers and game designers were competent.
The main issue is that the game was incredibly unappealing, and I believe this can only come from poor leadership.
It’s probably not even the artists fault it turned out this shit. My gut feeling is that the game is victim of incompetent leadership. Indecisiveness on important matters and micro management on stupid things.
It’s also the same incompetent leadership who will get bonuses and promotions after this.
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#.
That still counts as one
It doesn’t matter, why the present is garbage, it’s garbage and we should address that.
The problem is fixing it without inadvertently breaking for someone else. Changing the default behavior isn’t easy.
There’s probably some critical systems that relies on old outdated practices because that’s the way it worked when it was written 20 years ago. Why should they go back and fix their code when it has worked perfectly fine for the past two decades?
It makes you want to die on a hill