In your tech journey, you hear a lot of takes. Some of them are bad takes, while others are misguided. About Ruby, I once heard “There are lots of good ideas in that language, but everything is implemented in the slowest way possible.” This is a quote from a C++ developer. If you have strong feelings about certain programming concepts being “natural”, your lizard brain is going to reject an idea that doesn’t fit. This is what happens to people who have C++ in their brain and they look at Ruby or Objective-C. They want to remove message passing so badly, but message passing is what makes it good, actually. If your mind is full of Ruby problem solving, you think things like “Computer time is cheaper than developer time”, which is horrible and gross from the C++ engineer’s standpoint. We need a way of accepting both statements as true, but in different contexts.

What I propose is that there are different places you can be in the programming universe. If you’re on C++ island, your truth is probably that lots of dynamic dispatch is bad and that types are good, but you can only take the type system so far before there are diminishing returns. The C++ community is full of people who all believe they’re in the same world, but they’re actually not. The community is fractured across a few core concepts being either good or bad. The truth is that most things contain both good and bad, but that’s another post. The divisive concepts are RAII, OOP, dynamic dispatch, exceptions, and more. There are probably thousands of distinct items you can argue about. One of my pet peeves is that C++ header files usually contain implementation details. Yuck. My preferred “C++” is using as little of these things as possible. A decade ago, Mike Acton gave my favorite talk ever at CppCon. He proposes that you mostly use C in C++ files. This is exactly what I do when I write C++. There are people lined up after the talk to explain how wrong he is. Building efficient system code goes beyond one intergalactic system language. You can’t describe all good system code in C++, so C++ can’t be the center of it all. I’ll come back to this in a bit.

There’s another island. The Alan Kay style OOP island (or maybe Adele Goldberg island) using late binding and message passing to build reusable software components which can snap together at runtime like Lego bricks. The reason I call out Alan Kay specifically is that his Smalltalk language used message passing instead of function calls and vtables. When you solve problems in this style, you use class clusters to break down a problem into its sub-problems. You think of the solution to a problem the same way you think of how you’d coordinate team members. Each person has a role and they communicate back and forth about their tasks. The great thing about this style of programming is that it maps to your own problem solving intuition. You can divide up the work and break it up among separate classes which coordinate to produce an output. This style of programming is distinct from others, which is why it lives on its own island. You will benefit from this style if you have a lot of business logic rules which map to human behavior. An example of a bad fit, which is my opinion BTW, is Apple’s CoreData. It was designed to be Alan Kay OOP, but is actually not a great fit because the problem itself is to get values from a database. You can trivially outperform CoreData with C functions which get the data. You don’t actually need class clusters to solve this problem.

Objective-C and C++ developers don’t really get along because the high-level code in Objective-C is actually from Alan Kay OOP island. It zero-cost bridges to C, which lives on C++ island. The fact that you have to be good at both programming methodologies to build certain types of apps is why Objective-C-based apps could be so good, but it’s also why it’s difficult to find people who can do that type of work.

There are more than just the two islands. Functional Programming is its own dinstinct island. You’ve probably seen people from this island showing up in your community. They’re known to be polyglots and are quite friendly, in my experience. There are truths from that island which are beneficial, so make sure to add some of these ideas to your brain if you want to.

Back to C++. An important thing to note here is that C++ island has never been just C++. It’s really a system code island. With Rust gaining popularity and getting to be a capable replacement for C and C++, it’s important that we change the name of the island in our hearts and minds. The real goal of this island all along is best described by Abner Coimbre in this talk. In the video, he says that good software is about transforming inputs into outputs in the most efficient way. I think this is completely true for games and operating systems, but not for all software. Note that Abner only really believes that C++ island exists and that everyone else is misguided.

A goal of mine is to always be kind to people who are entering your community and try to share space and power with them. Try to make some room for others. Be kind to Rust people who want to share this intellectual space with you. The best of the D programming language has been folded into C++ over the last decade or so. The same thing will happen with Rust. C++ can get optional lifetime tracking in the future and will be better for it.