Hello, world! My regular blog doesn’t really have a main topic, but in recent years it has kept going along the general theme of politics in Costa Rica, with occasional wanderings into information technology. That (and the fact that it’s written in Spanish) has kept me from writing about the more technical side of programming, which is what I really do on a day-to-day basis.

The elephant in the room: if I want to write about the more technical stuff, why do I think that it’s more appropriate to do so in English? For starters, English is the lingua franca of programming. All the major computer languages in use today are basically in English. When I write something like this:

for i := range elements {
	fmt.Println(elements[i])
}

that might not look like English to a person that doesn’t write computer programs, but at its core it’s English: “for”, “range”, “format”, “print line”. You can sort of read it left-to-right top-to-bottom in English: “for i in the range of elements, print the ith value”.

Compare to this:

for i := range elementos {
	fmt.Println(elementos[i])
}

I changed one little tiny thing, and it feels choppy already. To each its own, but if you hand me that in a code review, I’ll ask you to change the name of your variables. Mixing the quasi-English elements of the language and the standard library with quasi-Spanish variables and functions will make your program harder to understand, as you’ll be interrupting the flow of whatever it is that you are trying to express. At a fundamental level, writing a program is communicating and communicating clearly must be one of your goals.

Going from there, for me it’s only natural to communicate the other parts of the programming activity in English as well. If I’m going to write about programming, I’m going to write in English.

That said, you probably picked up on the fact that I’d like to write mostly about the Go programming language. I would also like to contribute to the growth of the Go community, not only the worldwide one but the Go community in Costa Rica.

Why?

I started almost 30 years ago by teaching myself Pascal when I was around 14, and I moved to C not that long after. By the time I entered college in the early nineties, I had already written a spreadsheet with graphing capabilities (which is what happens when you don’t have Internet access: you end up reimplementing Unix, poorly). A couple of years later I moved to Linux, and with it came the Unix programming environment, which allowed me to meet the shell, makefiles, Perl, automation and a whole bunch of other stuff. When I found C++ I was enchanted by the possibility of expressing programs more succinctly without sacrificing performance.

I’ve learned and used a number of programming languages and paradigms since. But over and over again, we end up in the same situation: portability is just a promise; apparent simplicity is actually hidden complexity; what’s a good idea on paper, is hard to use in practice.

Go is the first thing in a long time to come forward with a proposal as to how to actually make the programming practice more effective. Rob Pike presented the ideas that drove Go’s development and summarized them as less is exponentially more, perhaps channeling Antoine de Saint-Exupery. I do believe that Go is a better C than C and a better C++ than C++. I don’t expect to see on operating system kernel written in Go anytime soon, but there’s lots of “systems software” already written in Go. Go is not one of the important languages of the future. Go is an important programming language today.

In that sense, Costa Rica is weird. There are companies hiring PHP developers today. Very few people know how to work with C and even less know C++ (although lots claim to be proficient in it). Java is king around here, largely because we have companies pressuring people to use it, which has driven universities to teach it to freshmen, not as a practical example of one programming paradigm, but as an actual tool that must be used. Around here Computer Science students generally don’t learn how to solve problems, they learn how to apply tools. Very specific tools.

And yet here I am advocating a tool. Yes and no. Go is a tool, yes. But it’s a tool different enough to push you to try to figure out what your solution actually looks like and question it. Go is a simple language, and it encourages you to have strong preference for simple solutions.

I hope to be able to demonstrate that simplicity in future blog posts.