We should embrace complexity: A Hello World Case

Every time I read someone suggesting that our code should be as simple as possible (there exists the acronym KISS - Keep It Simple, Stupid), I remember how the "printing Hello World" little program can be written in different languages.
Take, for example, a Ruby program:

puts 'Hello World'

Simple and straight-forward, right ? Just with one line and three words, you can print "Hello World". But print where ?

So, let's compare with C# program:

namespace HelloWorld
{
    class Hello {        
        static void Main(string[] args)
        {
            System.Console.WriteLine("Hello World");
        }
    }
}

It's still simple, but instead of one line and three words, we have to declare a namespace (why?), a class, a method with arguments, and then, inside the method, call another method from another class.

Comparing both languages, you may wonder: Why does C# require all that stuff and Ruby doesn't ? If code should be simple, why is C# not that simple ?

First and foremost, they're different because, obviously, they were built differently. But the main point here is that every program should have an entry/starting/main point. And, as we can see, the C# programming language just requires that it be explicit. Ruby doesn't because its creator just developed the language to do this entry/starting/main part automatically.

There are other things related to a programming language that differentiate one from another, like compiling, interpreting, parsing, but what I'm trying to show is that something may seem simple but, in the end, it's not.

When we talk about "Hello World" programs, generally, we talk about printing the string somewhere. When someone is learning programming for the first time, they usually have no idea about the destination of the string output. Usually, when we write "Hello World" programs, we print the string on the console. And it's explicit in the C# program (System.Console). So, in order for this simple program to work, it requires an operating system and this system needs to have console feature. It also requires, obviously, an I/O system to enable characters to be printed on the computer screen. So, again, the program seems simple, but it's not. For those who have this knowledge, it looks simple. But imagine beginners who have no idea about all that stuff. They become lost, as I became when I started studying programming.

In other words, words matter.

Let's take the concept of variable as an example. When you tell a beginner that they need to create a variable and then use this variable somewhere else. Beginners usually get confused because they wonder, "What does creating a variable mean ?" And "how does the program get this variable and use it somewhere else?" They get confused because they don't know the memory system. What actually does "create a variable" mean? It's just a value that's been allocated to computer memory. And then, when the program needs this value, it just accesses the memory location. So, as we can see, a lot of things need to happen in order for a "simple" program to be executed.

But that's the concept of complexity, that's the concept of system. The word "complex" comes from the Latin word "complexus" which means "a complicated whole made up of interconnected or related parts". Quite similar to the concept of system: "a set of things working together as parts of a mechanism or an interconnecting network". So, in order to understand a program, we need to know its parts and how they work together.

It seems obvious, but if we take this vision seriously, we should abandon the idea of "simple" code and face coding as it is: "complex". We should talk in terms of how complex a system would be, whether it's more or less complex but, indeed, complex. I know that there are contexts in which we use the word "simple" and, in fact, the KISS approach, meaning that we should avoid "over-engineering" when it could be more succinct and straight-forward. But even, when we use the meaning in these contexts, we should use the word "complex" because, even if a code should be more succinct and straight-forward, even when we should avoid over-engineering, the reason for that is based on the concept of system/complexity, e.g., the reason is that the parts of the system tell us that the way we should lead is the "apparently simpler"

So, my conclusion is this: let's embrace complexity and don't be afraid of it. People just get scared when they see this word, but we should not be. Life is complex, systems are complex. So, let's face it as it is.