Programming languages are clearly linked to human languages: language designers use human languages to pick keywords, programmers use human languages to choose variable names, and so on.
How well does this work? We’ll explore this linkage in this multi-part assignment.
Programming languages need to produce output in a variety of languages, not only English. You might think using Unicode solves this problem. Not so fast! If you learned to program text-processing over English represented in ASCII, various assumptions you may have (implicitly) learned to make start to fail. See, for instance, this post which is relevant to the design of String datatypes. Other posts of interest might be this one and this one.
Try the three languages we’ve used this semester (Racket, Java, and Python), and two more of your choosing (but not other #langs, since those are just reusing Racket’s support), and report back on the level of support you are able to find for both variable names and in strings (these may not be the same!). You’re welcome to scour the Web for text in various languages.
Even if a language supports Unicode for variable names and strings, that still leaves the keywords. The keywords are especially important because (a) they signpost the program’s behavior and (b) they aren’t in the programmer’s control. For people not comfortable with English, learning programming becomes a double obstacle: in addition to the inherent difficulties of the medium, the learner has to also learn another foreign language.
For a while, it was popular to try to build variants of then-popular languages (such as Pascal) that had keywords in languages other than English. Do some research on the Web to see what such languages have been built. Provide the names and a little information about at least three of them. (Cite your sources!)
Sadly, these languages usually did not persist. Building and maintaining a separate language is hard, especially when it has a small user-base.
However, it isn’t clear why we should have to live with this compromise. The same could be said for software, but many systems support internationalization (“i18n”): e.g., instead of hard-coding text they choose it (with care) from a dictionary, and substituting different dictionaries usually results in fairly good i18n support. Why don’t programming languages do the same?
Let’s try to do this right now, for Spanish-only-speakers! (If you don’t know Spanish, consult a friend, or use a dictionary to look up suitable keywords.) Provide all the keywords and functions mentioned in the smol/fun documentation as a library, "smol-fun-es.rkt". Provide a client program that tests this code. That is, the library will provide all these bindings, while the client will be in #lang racket, but (require "smol-fun-es.rkt") (from the same directory) near the top. (In principle this allows bilingual programming. How to prevent the English bindings requires a little more knowledge of Racket that is uninteresting for this assignment.)
Experiment a little. Ignoring the DrRacket user interface (which anyway does support Spanish), and assuming you did not find any Unicode problems, what other difficulties do you encounter? What else might need to happen to create a more comprehensive non-English experience? Did you already notice and address any of them in your implementation? (It’s okay if you addressed it in English, signposting that the fix would need translation into each language.)
It turns out that knowing English isn’t all it’s cracked up to be, either. English words have many meanings, and sometimes quite specific ones, that keywords in programming languages don’t match. After programming for a while, these keywords may have gotten so ingrained in you that you forgot they have other meanings…but they do. This causes real difficulties for beginners:
Think of at least one keyword not described in the above paper, in any language you have programmed in, that can create similar confusion. Tell us what it is, which language it’s in, and why it might be problematic.
Not knowing English has become one kind of learning obstacle in computer science. Another important, and more intrinsic, one is visual impairment. If you are already significantly visually impaired, you can simply indicate you are in answering this question (and do not need to write any more unless you wish). Otherwise, at the two relevant points below, simulate this experience with a blindfold.
Write fresh code (say a factorial function).
Ask a friend to load an unknown program for you, and try to read it to explain what it does.
Recently, block-based languages (like Scratch) have become very popular in schools, especially for younger children, because they avoid most syntax errors. These will also become popular in contexts with people of any age who need to write small programs (e.g., scripts to control devices, to modify settings, etc.). If you aren’t familiar with them, please find some video tutorials for programming in Scratch.
However, block-based languages usually depend crucially on two abilities: (fine) motor control and visual acuity. If you lack one or both, you would have a very hard time using them.
Read this research paper, which describes a new library trying to address this problem. As so often happens with accessibility support, note how addressing these problems may also be able to help with native language issues.
Describe your experience trying to read and write code in Python.
Also, why do you think you were specifically asked to use Python?