Biggest annoyance in Ruby: nil is an object, nil's class is NilClass, NilClass's class is Class, Class's superclass's superclass is Object, and Object's superclass's superclass is basically BasicObject

Him: "dont put your constants in a standalone class, it defeats the purpose of OOP. A class is for methods and such."
Me (in thoughts): THIS IS PYTHON YOU OEDIPUS, WHAT ELSE SHOULD I DO IF I DONT WANT MY CONSTANTS TO CLUTTER THE FILE??1?

But using the enum-class as superclass maakes it ok for him...

I can't stand Swift's initializers. No other languages have the problem with constructors/initializers that Swift does. It's a complete failure of a feature and to hell with safety if it comes with this cost.

Just to illustrate how ridiculous it gets, I want to have a class where my initialization logic can be split among reusable parts. That is, the logic that initializes the class with no parameters has logic that I want to reuse in my other initializers. Simple DRY stuff. Well, the only way I can do that in Swift is if I use a convenience initializer that calls another one. But convenience initializers have completely different rules from designated initializers (again, something only Swift does).

For example, you can't access "self" until you call a designated initializer. You can't chain designated initializers, and if you want to chain anything in the same class you have to handcuff yourself by using a "convenience" initializer (there's nothing convenient about them, I might add).

So now I want to subclass my class and initialize myself using one of my superclass initializers. Oh but the one I want to call is a *convenience* initializer so I can't, unless I turn my new initializer into a convenience initializer. Except wait, a convenience initializer must delegate with self.init(), so it can't even call a superclass initializer!

And it just goes round and round and round. I don't know if I should try to convert all of my initializers to convenience initializers or the other way around.

Why all this nonsensical madness? Get rid of the distinction and go back to nice clean powerful initializers like Objective-C. I mean what does it have to take? This is a complete nightmare.

- The golden rule of CoffeeScript is: "It's just JavaScript".
- Nice!
- And provides a basic class structure that allows you to name your class, set the superclass, assign prototypal properties, and define the constructor, in a single assignable expression.
- No nO NO NO!

The Rise and Fall of Helper Classes

New method doesn't seem to fit into one of the existing classes so a developer creates a new class and innocently called it "helper".

Another dev had a similar conundrum and adds a couple more methods to the "helper" class.

And a few more methods added...

A couple more methods surely wouldn't be too bad. It has unit tests anyway.

After a year, the helper class has now grown to about 10,000 lines that no one is brave enough to refactor.

CTO now says, "Ok let's park this project and build a new one in Go." Fun times!

OOP is all about code reusability until you really want exactly the code Foo with non-pure functions in all your classes. You end up almost rewriting all subclasses' properties into the superclass to silence typecheckers. Is there no "I know what i'm doing, please just transpile/compile this piece of logic into these 20 places I need?" You end up doing it the functional way, dumping refs and params into some shared util function and have it do the job. I know, might as well have that one inherited also, but what's the point of adding more mess just for that ?