The Core Aesthetic Clash: Python's __init__
Let me preface this by saying I actually I like the ethos of Python. I think the Ruby and the Python community share a lot of similarities. They're both dynamic interpreted languages. They're both focused on immediacy and productivity and ease of use in a bunch of ways. But then they're also very different in many other ways. And one of the ways they're very different is aesthetically.
Python to me, I hope I don't offend people too much. I've said this before, it's just it's ugly. And it's ugly at its base because it's full of superfluous instructions that are necessary for legacy reasons of when Guido made Python back in '87 that are still here in 2025 and my brain can't cope with that. Let me give you a basic example.
When you make a class in Python, the initializer method, the starting method is def. Okay, fair enough. That's actually the same as Ruby, def definition of a method. Then it is underscore underscore, not one underscore, two, init, underscore underscore.
Yeah.
Parentheses start, self, and then the first argument.
Yeah, the whole self thing. Yeah. Mhm.
I look at that and go, I'm sorry. I'm out. I can't do it. It's just everything about it offends my sensibilities to the core. Here you have the most important method that all new objects or classes have to implement. And it is one of the most aesthetically offensive ways of typing initialize that I've ever seen anywhere. And you guys are okay with this?
Yeah. You're making me, you know, where you're like talking about my marriage or something like this and I'm now realizing I've been in a toxic relationship all along. Yeah. I just get used to it.
Ruby's Philosophy: Optimizing for Human Readability
That to me, by the way, was the magic of Ruby. It opened my eyes to how beautiful programs could be. I didn't know. I'd been working in ASP. I'd been working in PHP. I didn't even have the concept that aesthetics, beautiful code was something we could optimize for, that something we could pursue. And even more than that, that we could pursue it above other objectives.
That Ruby is as beautiful as it is is not an accident and it's not easy. Ruby itself is implemented in C. It's very difficult to parse Ruby code because Ruby is written for humans and humans are messy creatures. They like things in just the right way. I can't fully explain why the underscore underscore init make me repulse but it does and when I look at the Ruby alternative it's really instructive. So it's def, same part, def space initialize.
Parenthesis, not even parenthesis if you don't need to call it with arguments, there's not even a parenthesis. That in itself is actually also a major part. If the human doesn't need the additional characters, we're not just going to put them in because it'd be nicer to parse for the computer. We're going to get rid of the semicolons. We're going to get rid of the parenthesis. We're going to get rid of the underscores. We're going to get rid of all that ugliness, all the line noise and boil it down to its pure essentials.
And at the same time, we're not going to abbreviate. This is a key difference in the aesthetics between Ruby and Python as well. init is shorter type. It's only five characters. initialize is a lot longer, but it looks a lot better and you don't type it very often. So, you should look at something pretty. If you don't have to do it all the time, it's okay that it's long.
Expressive Conditionals: How Ruby Uses if, ?, and unless
Those kinds of aesthetic evaluations are rife all over the Ruby language. But let me give you an even better example. The if conditional, that's the bedrock of all programming languages. They have the if conditional. If you take most programming languages, they all have if. That's basically the same in almost every language. Space, start parenthesis. We all do that. And then you have, um, perhaps let's say you're calling an object called user.isAdmin() close parenthesis, start brackets and here's what we're going to do if the user is an admin. Right? That would be a normal programming language.
Ruby doesn't do it like that. Ruby boils almost all of it away. We start with the if. Okay, that's the same. No parenthesis necessary because there's no ambiguity for the human to distinguish that the next part is just a single statement. So you do if space user.admin?.
Yeah.
No open brackets, no parentheses, no nothing. Next open line, here's the unconditional. That question mark means nothing to the computer, but it means something to the human. Ruby put in the predicate method style purely as a communication tool between humans. It's actually more work for the interpreter to be able to see that this question mark is there. Why is this question mark in here? because it just reads so nicely. if user.admin? That's a very human phrase. But it gets better. You can turn this around.
You can have your statement you want to execute before the conditional. You can do user.upgrade, to say you're calling an upgrade method on a user, space if space user.admin?. We do the thing if the thing is true. Instead of saying if the thing is true, do the thing. But it gets even better. This is why I love this example with the conditional because you can keep diving into it. So let's flip it around.
user.downgrade if !user.admin. Right? That'd be a typical way of writing it. Ruby goes, that exclamation point is line noise. Why do we have if and then an exclamation point? That's ugly. We could do user.downgrade unless user.admin?. That to me is an encapsulation of the incredible beauty that Ruby affords the programmer through ambiguity that is only to serve the human reader and writer. All of these statements we've just discussed, they're the same for the computer. It'll compile down to the same C code. They'll compile down to the same assembly code. It makes no difference whatsoever. In fact, it just makes it harder to write an interpreter. But for the human who gets to choose whether the statement comes before the conditional or the predicate method has, it's just incredible. It reads like poetry at some point.
The Designer's Vision: The Pursuit of Programmer Happiness
It's it's also incredible that, you know, one language designer is creating that. You know, Guido Van Rossum also. It's like one person gets to make these extremely difficult decision because it's you have to think about how does that all get parsed and you have to think about the thousands if it's a popular language the millions of people that end up using this and what they feel what that question mark on the for the if statement what what does that feel like for...
That's what Matz thought about because he started his entire mission off a different premise than almost every programming language designer that I'd heard at least articulate their vision. That his number one goal was programmer happiness. That his number one goal was the affordances that would allow programmers to articulate code in ways that not just executed correctly, but were a joy to write and were a joy to read. And that vision is based on a fundamentally different view of humanity.
