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!