Technology which includes software is a powerful enabling force. We have the ability to do amazingly things on a global scale using software.
Thanks to software, we are able to take pictures of a black hole that is 55 million light years away. We can treat and cure diseases that would have been thought chronic or even fatal just a few decades ago. We might not think of this as achievements of software specifically but software is the underlying force that is powering and enabling all of these. But software can be used for terrible things as well, using it to inflict violence or commit genocide.
If we think software is a powerful and enable enabling force, who does it enable and what does it allow them to do? I have really lives who don't speak English. If one came to me and said they want to learn to write software and asked me for advice, the first thing I would say is you have to learn English because if you don't speak English, you're not really going to be able to do much in the software world, certainly not in open-source software development. Especially if you don't even read the Latin script because your native language uses a different script altogether. That itself is a barrier.
The idea of eliminating natural language barriers to programming isn't new at all. In fact, it's very old. Grace Hopper is one of the first computer scientists and she wrote THE very first compiler for a high-level language. You should check out her portrait there. The language that she invented was called Cobal, and the goal was to have English-like national language syntax so that business executives could write code.
She got a lot of pushback about this because engineers thought if non-engineers can write code, this can put us out of a job but Hopper took this vision further. Why restrict it to English-like syntax? What if engineers who speak other languages want to be able to write code as well, and she wanted Cobal to be a language you can talk to people around the world. The response she got to that was more vitriolic. How can we teach American computers to run German programmes? That wasn't an accident.
This wasn't a question of how it can be done technically, it was a political question. This was the 1950s, and in the US military, the fear of a threat from Germany or Russia was still a huge fear in people's minds.
But even if Hopper's idea was put on the back burner in the 1950s due to xenophobia and Cold War politics, we can look at what that means today, and apply that approach to modern languages. So this is Hopper speaking about Cobal many years later, "I would have thought it would be useful to NATO because they had the common verbs for the things they're going to do, and the nouns, they have to have a dictionary for the things they were referring to for inventory control. They would have common announce throughout NATO and a diction of common verbs and translate the programme. You can write one in English and you could translate it and it goes to the other language.
No problem. You have communication. It would be a limited vocabulary." One thing is that she chose the imperative mood specifically because she thought it would be universal to languages, because not all languages distinguish between tenses in the same way but they generally have a commanding way to do something. Cobol popularised the programming style, and that stuck with us today.
You will see why I chose it for this example. But as for Bengali, I chose that because Bengali it's the language my family speaks, and we're Bengali, and, if you talk to Bengali about our language and culture, you'll see very quickly that we're pretty proud of it. The Bengalis like to say is the language that is so beautiful, people literally fought a revolution, an entire war, to defend the right to speak it. The United Nations more recently actually issued a declaration stating that Bengali was the sweetest-sounding language in the entire world. But on a more practical note, Bengali is a pretty common language.
After Hindi, it's the most common language spoken in India, and also the national language of Bangladesh. Combined, that means it's the seventh most widely spoken language in the entire world. There are more native speakers of Bengali than there are of German and French combined. It also uses a non-Latin script, so it gives us an opportunity to test the boundaries of what we can do with Unicode and how characters get treated and rendered in languages outside the ASCII code range.
Again, nothing that I'm doing here is unique to Bengali or to Go. If you speak another language, which it seems the majority of this room does, I encourage you to go home and try to do this with your own language as well.
This right here is a simple "hello, world" in standard Go. If you've never written a line of code, you can guess what it is doing here. This is that equivalent programme written in koro. We've left the identifier names intact, and I did not forget "true", true is not a key word in Go.
Based on the previous slide, you can take a guess at what this programme is doing. If you don't speak Bengali, you might not be able to figure it out from scratch, if you do, this is a whole lot more readable than what we just saw on the previous slide. The first challenge we need to do here is we need to get this programme to run because the Go compiler isn't going to know what to do with the key words. Here we can take advantage of a nice trick.
This is why we chose Go for this example. Go's source code is all UTF8.
Having made those changes, this is what that "Hello, World" looks like in practice. You can see the programme, and we are going to run it. There we go. Thank you. [Applause].
Remember, our goal is to defragment open-source development, not to fragment it further. We need to make sure that our code that we are writing in koro is still interoperable with English-speaking Go developers are use as well. We don't want to have to translate every programme manually because that would be unfeasible, but the computers are doing the heavy-lifting for us. Conveniently, for translation, Go has a handy utility for format ing - and mostly we you have the use Go format to argue over bike shedding, semicolons, things like that.
Instead of arguing which is the proper way to indent your code, you set up the editor whichever way you want and render tabs how you want them to be, and, when you save your code, it's committed in the standard form. If I want to use four spaces for indentation and you want to use two, Go format means we can work together. I set up my editor to render it to the width I want and we don't need to know that we have different indentation preferences because the code committed is on the standard form. Go format is syntax aware, so it can do things like remove unnecessarily parentheses and ensure it will never change your code semantics.
That's a simpler way of saying it is a great way of performing fully isomorphic translations of source code which is exactly what we could wouldn't here. All we have to do is extend Go format and repurpose it for translating English Go code into Bengali or vice versa, and that is what koro format does. So let's translate that same programme written in koro back into English-speaking Go and run it.
Here is the koro programme. And now we can format it, and we get the English programme again, but if you don't believe me, we can run it and prove it does the exact same thing. There we go. We just translated from one language to another, and back again. There we go.
So the same way that you didn't know that I was using four spaces for tabs and I don't know that you were using two, having bidirectional translation layers means you don't need to know that I'm writing my code in English and I don't need to know that you're writing your code in whatever language you happy to speak. We can still work together and we localise our source code as a commit hook and the editor will display it for us in the language that we want. As a developer, koro means we only need to look at source code in our own language, and as far as the code is concerned, the language barriers are no more of a barrier to you and me writing code and working together than our indentation preferences are. That's the way it should be.
Translated the key words but you will notice that we left the - we didn't touch everything, so like the package names and identifiers, those we kept in English. Is there a way that we can translate those as well in there are a lot of ways to choose variable names but the one thing that everyone agrees on is they should be descriptive and concise.
If you don't speak English, then it's not descriptive to have English codenames. In reality, many functional names are highly structured. We don't need to, as Hopper mentioned, we already have the verbs that we use when talking about our programme. There is the common vocabulary.
It's some sort of access or method. By being more conscious about these conventions we're already using, we can make our code that much more accessible to non-English speakers.
You have to pass in error values and operate on the values. Go does the exact same thing but for all code where synchronous or asynchronous.
Translating error messages is a good starting point. Not only are they fine night in full - finite in number - and they are the easiest to solve technically because we can rely on existing localisation strategies.
I don't have time to talk about the aspects like documentation. How do you translate documentation and how do you make sure that that documentation stays in sync between across languages? How do you make things like mailing lists or even meet-ups and conferences like this, make those accessible to people who speak any language, not just people who happen to speak English? I don't have time to go into the details today, but I've spoken about some of the challenges in the past, so, if you're interested, you can check that out, or come and find me afterwards.