Hacker News Reader

Comment by jake-low | Hacker News Reader

If you don't mind me asking, did the book do any explaining of why the magic computer words were in a foreign language (English)? Had you been exposed to much English already when you picked up the book?

As a native English speaker I feel fairly ignorant of how programming is taught in other (human) languages. I recall a quote [1] by Eric S. Raymond commenting (or perhaps speculating?) that Linus commented his kernel code in English because it never occurred to him to do otherwise. But I'm curious for your perspective as I imagine the experience of a child learning from a book is quite different from that of an adult who is immersed in the English-dominated "hacker culture" on the internet.

[1]: http://www.catb.org/~esr/faqs/hacker-howto.html#skills4

View on HN

I'm not the GP, but here's my perspective learning programming in a 3-year technical high school program in Brazil (I had a little bit of exposure before, with Windows batch files and shell scripts).

We started with a language called Portugol or "structured Portuguese" which is something like a formalized pseudo-code language and was used to teach the basic concepts of structured programming: variables, control flow, subroutines.

We spent about three months working with Portugol exclusively, never actually running it on a computer, but just for understanding programming logic. After that we moved to C and eventually "C with classes" C++. Comments were still written in Portuguese.

The transition to C was fairly easy in my experience, because the actual English vocabulary you need to understand to program in C is very small, and because the concepts themselves were taught in Portuguese with Portugol, so you only had to do dictionary translation, really.

Seems a shame that there wasn't a Portugol interpreter/compiler handy to at least see things running on a machine before moving to C. Probably would have been a good class assignment to more advanced students to build something like that.

How awesome would it have been to be a high performing student, writing programs that a lower performing student would have to execute manually on your simulated computer system. So much good stuff here. Do you want to layout the nand gate or BE the nand gate? Or be the one that decides which problems the nand gate solves?

That's intriguing to the point I tried to find the relevant web site. Thanks for conveying your experience with it: http://web.archive.org/web/20080212005133/http://gpt.berlios...

"Portugol" is a great pun on "Algol"! Are there also programming languages called "Portutran" for scientific computing and "Portubol" for business data processing?

Yes it is :)

We never compiled or ran Portugol (IIRC, it was so vaguely defined that you'd be hard pressed to implement it), so practical matters like how applicable it was to scientific computing or data processing was never a concern.

I always wondered how non-english speaking developers from other countries who were first adopters of HTTP (or any new tech) reacted to words like "GET" and "Content-Type" and other things that were clearly invented by westerners. What would we think if we had to implement something new and use words we didn't understand?

I can tell you a similar anectode. My family used to live in a eastern Europe communist-at-the-time country. Computers were hard to come by and the only place you could get good hardware was in Germany.

My dad went to Germany and bought an Atari (I forget which one exactly), and realized it was all in German. Seeing that he didn't know any German, he learned it enough to navigate the UI.

In other words, the time cost of learning German was less than the cost of the computer + the trip to Germany. Basically necessity.

I wonder how often it is an advantage to not know English. Then you might have less baggage from outside the computer and you might map the token to what it actually does in the system (rather than what the token was aspiring to be). Assuming you can get to that point, of course.

The way I learned programming as a kid, while also simultaneously learning English, involved looking at the new weird term, grabbing a dictionary, and trying to figure out why it's named the way it is. Sometimes it was obvious, sometimes it wasn't, but generally it wasn't difficult - after all, this is just vocabulary. Single words. Pretty much the easiest part of learning a language.

> other things that were clearly invented by westerners

There are plenty of non-English speaking Westerners, you know? :D

In France, in the 80s, schools had Thomson MO5 machines that came with a french version of logo, with commands in french.

  repete 4 [ avance 100 tournedroite 90 ]

or with abbreviated commands:

  repete 4 [ av 100 td 90 ]

The Thomson version of Logo was developed by ACT Informatique in Paris by Sylvain Angéli.

I think you underestimate the number of people who can speak English. My family is Afrikaans, and it is our first language. My father taught himself to program with op codes on rudimentary computers back in the 70s. Then he learned assembly and later C. The English words never bothered him or his brother when they learned to code, because they could already speak English.

It was the same for me. I started learning in VB.net and then Java/Python. The English syntax never bothered me because I started learning English when I was 7 years old.

Trying to code in another language would just be a nightmare. So it makes sense to keep the syntax in one language (English in this case) for consistency.

I think I had the same book as the GP -- or follow up book at least: "Superlogo voor kinderen" (Superlogo for kids) from A.W. Bruna publishing. All commands were translated to Dutch. At the time, I had no idea I was using a LISP like language, but I recall being incredibly excited when the diskette arrived in the mail. I drew so many spirals with that little turtle. It had built-in sprite and sound support as well making it a truly early kids oriented and quite feature-complete language.

My native language is Dutch (Flemish, technically). As a Belgian, it is not that weird to me. We don't dub things on tv, so we grow up being fairly familiar with English.

So when learning programming it did not strike me as 'weird' that the language was English.

Nowadays, because of online gaming, it is probably even less of a problem for kids.

When I played with logo in the eighties, all the commands where translated to Spanish, so it would be something like (and I'm going by memory) :

  repite 4:
    avanza 50
    giraderecha 90

IIRC there was a dutch-language version of logo. That said I personally learned english by trying to parse the manual for game maker and asking my parents lots of questions. Of course I found out many many years later that a dutch-language version of the documentation was available from a third party.

It never occurred to Eric Raymond to do otherwise than to speculate and pontificate about what Linus Torvalds thinks (or how intelligent black people are, for that matter), instead of actually asking. (See "Linus's Law", which is should actually be called "Raymond's Wishful but Invalid Speculative Fallacy". But he cleverly named it after Linus, so he wouldn't get blamed when it turned out to be wrong. Heartbleed!)

https://en.wikipedia.org/wiki/Linus%27s_Law

I'd hazard a guess that Linus deserves credit for thoughtfully writing Linux in English on purpose, instead of just assuming that "it never occurring to him to do otherwise".

On the other hand, Yuri Takhteyev wrote a book called "Coding Places: Software Practice in a South American City" (MIT Press, 2012), about the social side of software and the culture surrounding the Lua programming language, developed at the Pontifical Catholic University of Rio de Janeiro in Brazil. And he actually spent three years interviewing the developers to find out the what the facts were, instead of speculating.

The name of the language Lua is Portuguese for "Moon", and the developers' native language is Portuguese, but the Lua language, code, documentation, mailing lists, and papers themselves are all in English.

http://www.takhteyev.org/

http://codingplaces.net/

He interviewed the developers and members of the global community, and examined why it had become so successful (modulo [or in spite of] the fact that it was extremely well designed and implemented, of course). His conclusion was that the developers made a conscious decision to write the code, comments and and documentation in English instead of Portuguese, because it was the de-facto language to use if you intended to foster an international global community around the language, which they did.

http://blog.castac.org/2014/04/coding-places-interview-with-...

Coding Places: An Interview with Yuri Takhteyev

Luis Felipe R. Murillo, April 15, 2014

In “Coding Places: Software Practice in a South American City” Yuri Takhteyev depicts a group of developers from Rio de Janeiro working on software projects with global aspirations. His ethnography, conducted in the span of three years, provides rich detail and insight into the practice of creating a programming language, Lua, and struggling to form local and global communities. In his narrative, Takhteyev sets off with a task that is particularly akin to anthropological studies of globalization: to specify socioeconomic and political forces shaping localities and creating instances of production and circulation of transnational scope. We asked him a few questions related to the book and his research on the topics of globalization, computing expertise, and politics of information technology. Enjoy!

https://mitpress.mit.edu/books/coding-places

Coding Places. Software Practice in a South American City. By Yuri Takhteyev

An examination of software practice in Brazil that reveals both the globalization and the localization of software development.

Software development would seem to be a quintessential example of today's Internet-enabled “knowledge work”—a global profession not bound by the constraints of geography. In Coding Places, Yuri Takhteyev looks at the work of software developers who inhabit two contexts: a geographical area—in this case, greater Rio de Janeiro—and a “world of practice,” a global system of activities linked by shared meanings and joint practice. The work of the Brazilian developers, Takhteyev discovers, reveals a paradox of the world of software: it is both diffuse and sharply centralized. The world of software revolves around a handful of places—in particular, the San Francisco Bay area—that exercise substantial control over both the material and cultural elements of software production. Takhteyev shows how in this context Brazilian software developers work to find their place in the world of software and to bring its benefits to their city.

Takhteyev's study closely examines Lua, an open source programming language developed in Rio but used in such internationally popular products as World of Warcraft and Angry Birds. He shows that Lua had to be separated from its local origins on the periphery in order to achieve success abroad. The developers, Portuguese speakers, used English in much of their work on Lua. By bringing to light the work that peripheral practitioners must do to give software its seeming universality, Takhteyev offers a revealing perspective on the not-so-flat world of globalization.

Reply on news.ycombinator.com