The Apple II Source Code for the LOGO Language Found

Could this be a trick to use the top of stack like another register and use all of the one byte stack instructions on it? If it is using the top of stack as a register, where then would be the real stack?

The only time anyone would notice slight errors in turtle position was trying to do animation by drawing over a previous drawing with an XOR or ERASE or background color pen. It might be necessary to explicitly reset the turtle position to the original start. I do remember having to be careful with the anti-aliasing so that when pointing in any random direction FD 100 RT 180 FD 100 would draw the same pixels in either direction.

There is a gray area there. But we are talking about translating an existing model program and algorithms, not looking at the program as a black box and recreating its behavior.

As the person who translated the Pascal Logo model to TI9900 assembler it was definitely the case that at the beginning of the project I translated every line of Pascal to a few instructions of assembler. By the end I was just looking at the gist of what a routine would do (its “contract” as they say) and writing it in assembler as you would new code.

It’s much like translating a literary work. There’s a famous quotation (which I’m not comfortable relating in full) about translations being either faithful or beautiful but not both.

Essentially maybe I became a fluent native speaker of 9900 assembler.

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.

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.