Programming languages vs. human languages, and learning thereof

[Sprachprofi]

As some of you may know, I straddle both worlds, since I've learned a lot of human languages but I've also learned 7 programming languages and I actually earn a living as a web developer, not as a polyglot.

If you've ever wondered how the two kinds of languages compare, I just wrote a lengthy article to satisfy your curiosity: https://languagecrush.com/forum/t/3440

I compare them under the following aspects:
- Vocabulary
- Grammar
- Usage
- Learning
- Conclusion / Recommendations

[Cainntear]

I don't do Ruby, but I really don't like any language that ends loops and branches with the END keyword. To me, it just implies something more terminal than the actual job or does. ENDIF, END LOOP, END <<LABEL >>... all fine. But END on its own messes with my head.

[Lisa]

I don't find learning computer languages and human languages very similar, except that when I was new to computers I did want to learn obscure languages like lisp. The problem with computer languages (I'm looking at you, C++) is some obscure grammatical constructions that create blocking problems and you can't easily sidestep/get close enough. While with human languages, it's the sheer volume, changeability and flexibility of words. While human languages have obscure grammatical constructions, you can usually avoid having to construct "If I'd known X I wouldn't have wanted to do Y" sorts of problems. The other problem with computer languages is that details (e.g. add-on libraries) change much faster than human language so if you come back a few years later you have to unlearn/relearn "words".

[rdearman]

I don't do Ruby, but I really don't like any language that ends loops and branches with the END keyword. To me, it just implies something more terminal than the actual job or does. ENDIF, END LOOP, END <<LABEL >>... all fine. But END on its own messes with my head.

Could be worse, could be a stupid whitespace delimited language.

[ryanheise]

Nice article and topic, Sprachprofi.

Programming languages do not conjugate verbs and most do not care about noun plurals either.

This got me thinking back to HyperTalk, an English-like programming language designed at Apple in 1985, and quite popular for some time for scripting HyperCards. The early Macintosh also allowed you to record the user's interactions with the computer and save that into an English-like script written in HyperTalk which could be re-played on demand like a macro. HyperTalk supports sentences like:

Code: Select all

put the value of card field "typehere" into theValue

In that sentence, theValue at the end is just a variable name, not a grammatical thing, but at the beginning "the value" is grammatical and the computer infers what you are referring to by "the". There is also an "it" keyword, the meaning of which is similarly inferred by the computer.

But does it have verb conjugations? Well, 99.9999% of all verbs in high level programming languages are not built into the language anyway, but rather are words invented by the programmers themselves, and are usually named after verbs in the programmer's own language, or more commonly, English. It is therefore common for example to see both "click" and "clicked" appear in programming language code. It is less common to see "willClick" because it is the nature of computation that the only way to determine the future is to wait for it to be computed, although many modern languages have a notion of "futures" representing computations that will produce results in the future.

But, if only built-in verbs qualify for verb conjugation, then yes, HyperTalk does indeed have built in verbs that conjugate in different tenses, although it is rare. One such example is "suspended" vs "suspend". But in my view, whether this is a built-in verb or a programmer-defined verb makes little difference as both cases look the same. In both cases, it is not that the programming language has some built-in notion of past and present, it is just that the words themselves have been defined to have particular tensed meanings. So conjugation here is more about conventions in the naming of vocabulary words rather than a strict grammatical feature.

However, if you want a language that actually has a built-in notion of tense, then one example is the Lucid programming language which includes its own tense logic allowing you to write conditions based on whether a variable "is" or "was" or is "always" a certain way. Predating that, there was also an article written on the topic called Multiple Tense Computer Programming.

Programming languages, like human languages, do not allow you to reference something before having defined it.

I assume your comment is specific to "imperative" programming languages, in which steps are defined to execute in a particular order. Not all programming languages are like that; declarative languages and functional languages typically have no notion of doing things in a specific order, and often allow some flexibility in this respect in order to define mutually recursive functions. And, most imperative programming languages today also now support some notion of forward reference in order to express mutual recursion, most commonly in mutually recursive data structures, but also in functions, so the comment is not necessarily true in general, but true for the steps within a procedure.

learning vocabulary does not take a lot of time in your education as a programmer. The syntax also isn't terribly difficult,

This is a very interesting topic. I agree with your general conclusions. Vocabulary is also not a problem in programming due to Auto Complete that is always at hand. And the grammar is simpler. But interestingly, the programming language with the simplest grammar (the lambda calculus) is also the hardest to program in, and so humans really like to have that extra grammatical sophistication in order to be able to express ourselves more naturally. That is why modern programming languages are adding more and more complexity to become more and more expressive. That increased expressiveness means we have to learn more grammar to master the language, but once mastered, it also means we are able to express ourselves more succinctly and more clearly. Some modern programming languages even go so far as to allow you to extend the language not only with your own custom vocabulary, but also with your own custom grammar (domain specific languages).

But while learning a programming language is very different from learning a natural language in many ways, I actually find some similarities in the way I personally approach them.

In both cases, I have a preference to pick up the grammar just through lots of examples, rather than by reading a formal grammar. Even though I have studied formal grammars for many years, and have a Ph.D. in the design of programming languages, I do not think of grammars as the best learning aids, at least for me. What I need are examples!

I may be an extreme case, though. I remember when I was a teen, deciding I should learn the C programming language, I never bought even a text book. What I did instead was print out pages and pages of source code of actual C programs and try to decypher them. I remember reading things like:

Code: Select all

*ptr = x; // end of string

and wondering, what does the star mean? and what in the world does // mean? Was it some kind of division? If you are a programmer, you can imagine my confusion for someone who had no familiarity at all with the strange syntax of C (if you don't think it's strange, then you are taking your familiarity for granted). But I eventually figured out several pages in that the text to the right of every // was not code but arbitrary English text that served as explanatory comments for what was going on in the actual code to the left. And through those comments, I could also eventually figure out that * was associated with variables allocated with malloc, and eventually understood that it dereferenced the pointer. So to understand the code, all I needed was the code, and a translation of the code into English, and I was able to figure out the rest. When learning more complex modern programming languages, I do sometimes get curious about a specific rule that wasn't evident from the examples, and so I will look it up in the grammar.

Of course I wouldn't say this is exactly the same as my experience with Japanese, since natural languages have far more rules and special cases to discover, but there is at least some similarity in my approach of preferring the examples over the grammar.

[Sprachprofi]

Thanks for the detailed and insightful comments, @ryanheise!

When developing the prototype of a machine translation system, I did create my own loops like each_word, each_letter and a grammar "calculator", but I haven't designed a programming language from scratch.

@Cainntear, Ruby actually allows you to use { } instead of do... end, to make it easier for people coming from other programming languages. In practice, you'll see that a lot for one-line stuff but not multi-line.

[Cainntear]

Was trying to keep away from this as I’m on holiday and don’t have a keyboard, and this is a big topic, but I can’t help but want to say my piece, even if it means writing a long screed on a phone…

The first thing that should be understood is that computer languages were invented during the height of Chomskyan linguistics — linguists we’re trying to treat languages as a combination of simple formal rules, which in principle is probably not that far wrong, but the other major component of Chomskyan thinning is the idea that grammar doesn’t convey meaning, and that probably explains why the rules weren’t all that useful.

Computer languages were born out of Chomskyan definitions of what language is, and that’s not actually what language actually is.

Computer languages are more like mathematical or musical notation. They are a means of expressing and sharing a certain tour of logic. The fact that we try to make them look like language doesn’t mean they are language, and the more sophisticated they get, the less like language they look.

One of my favourite programming features is Python’s list comprehension: [ x*x for x in myList if x > 3] gives me a list of the squares of all numbers greater than 3 in the original list. This is very very close to mathematical notation, so it’s maybe not the most immediately obvious thing first time you look at it, but once you can understand it, it becomes something you can tread almost instantly — render it more language-like and it would be harder to read.

I really think we should be beyond “languages” by now — typing in fixed keywords in arbitrary orders is an inefficient way of expressing ourselves to computers. Dragging and dropping like Scratch isn’t much use either.

The best thing I have ever seen is Stride — is most of what I think a modern “language” should be.

[golyplot]

Natural and computer languages are as alike as turtles and turtle doves. The conflation of terminology confuses more than it illuminates.

Computer languages are more like really elaborate control panels or sets of lego blocks and are deliberately designed to be easy to learn and to be similar to each other.

[ryanheise]

The fact that we try to make them look like language doesn’t mean they are language, and the more sophisticated they get, the less like language they look.

I would just point out that you're using a different definition of language than the one being adopted in the first post. Yes, language can (and did originally) mean human language, but scientific endeavours have resulted in further kinds of languages, and thus a more general definition of language has arisen over time, of which the others are sub-classifications. I have no issue with adopting a definition different from my own, although it can get confusing to switch mid conversation, since the message often gets obfuscated.

Looking past the different definition of language and to the point, I think you are saying that the more sophisticated computer languages get, the less like human language they look. But I don't think that's quite right. Like other kinds of languages, computer languages are adapted to be fit for their purpose. Current programming languages use single-character symbols like *, %, @, {, }, etc. precisely because we program code on keyboards and we read code on computer monitors. These symbols are both more efficient to type, and visually easier to delineate. But the moment we start programming through verbal dictation, our programming languages will adapt to that purpose. Languages with lots of symbols will be out, and languages with a more human language-like feel well be in.

I once had a blind student who was studying computer science. Languages with a high number of symbols presented the greatest challenge for him. To work at his computer, he basically had an earpiece that would read out to him all the code around the cursor's position, mind you at an impressive speech rate that was far too fast for me to personally comprehend. Hearing "List<Integer>" read out as "List less than Integer greater than" is not quite as easy to process as simply hearing "list of integers".

At that time, I remember almost embarking on a project to design a programming language that was more fit for this purpose. In addition to the "the" and "it" keywords that HyperTalk had, it was going to have an implicit, strong type system so that you wouldn't actually need to ever utter "List<Integer>" in the first place, and to support that, a built-in notion of singular vs plural words so that the type system could infer the plurality of a variable from its name. It was also going to treat function definitions as grammatical rules, so that rather than define functions such as "sqrt(x)", you would define the grammatical patterns such as "the squared root of x". Human-like programming languages can be simple or sophisticated, and symbolic-like programming languages can be simple or sophisticated. But the driver for an Human-like programming language is not about the level of sophistication, but rather to better adapt to the environment and purpose for which it is to be used.

The first thing that should be understood is that computer languages were invented during the height of Chomskyan linguistics — linguists we’re trying to treat languages as a combination of simple formal rules, which in principle is probably not that far wrong, but the other major component of Chomskyan thinning is the idea that grammar doesn’t convey meaning, and that probably explains why the rules weren’t all that useful.

Computer languages were born out of Chomskyan definitions of what language is, and that’s not actually what language actually is.

Putting aside the Chomsky religion, the science itself has progressed the way science should. The early models of physics were simple and elegant, but did not account for everything. Science made observations that did not fit the model, and so new, more advanced models were invented to account for those observations. Similarly, in the past, it had been observed that there exists language that could not be modelled in Chomsky's context free grammars, and so science came up with more advanced models to account for the observations. And it really does not matter that models are approximate. There are computer games based on simplistic physics models that still feel immersive, and still feel something like the thing they are modelling. There are also conlangs based on context free grammars that probably feel similar to conlangs that step outside that. It is close enough that this to me is not a differentiating factor.

The point is that I don't think the fundamental difference between human languages and computer languages has anything to do with what model a linguist came up with 70 years ago. Since languages adapt to their purpose, the fundamental difference between these two types of language is the purpose for which they were adapted. A language fit for communicating with other humans will go a certain way, and a language fit for communicating with computers will go another way. But the two types of language are not so different that we can't see at a meta level that they both have things in common such as vocabulary, grammar and semantics.