language fluency

I have heard it said that learning a second language is pretty hard, but learning subsequent languages gets progressively easier. Already an ESL (English as a Second Language) student in high school, I was forced to attempt a 3rd language, Spanish courses that were mandated for graduation. I merely muddled through it.

"That galaxy is signaling in binary. I should signal back, but I only know enough binary to ask where the bathroom is." - Bender ( Futurama - S4E8 - Godfellas )

My excuse for my limited Spanish acquisition is that perhaps I'd been diverting my learning toward computer programing languages instead.

"I dedicate this performance to the lovin' memory of Microsoft QBasic. Keepin' it real." - Futuristic Sex Robotz

But the excuse is only an afterthought. I only started thinking about the correlation between spoken languages and programing languages after stumbling onto the topic of literate programming.

Literate programming is an approach to programming, introduced by Donald Knuth, in which a program is given as an explanation of the program logic in a natural language, such as English, interspersed with snippets of macros and traditional source code, from which a compilable source code can be generated.

...

According to Knuth, literate programming provides higher-quality programs, since it forces programmers to explicitly state the thoughts behind the program, making poorly thought-out design decisions more obvious.

Google dictionary defines literacy as "the ability to read and write." Well, ideally all developers can read and write code in their chosen language(s). Wouldn't all programing be literate? Depends on where you set the bar. A first grader is technically literate because he can cobble together some words by sounding out the syllables. But this isn't a rant about MS Bob, this is a rant about learning languages. So a bit about my experience as an ESL.

In 1993 my family and I moved to America, and it was pretty obvious to those around me that I was an immigrant. Thinking back, here is the basic list of the tells:

Sentence Structure

  • Description: Coming from Russian, a language with no forced sentence order, one hurdle to learning English was sentence structure. As a result, my sentences would sometimes become overly complicated and difficult to understand.
  • Solution: Translation at first, seeing the languages side by side and trying to understand the differences and similarities. Oh, and reading the language.
  • Years Later: I learned to organize my thoughts in the paradigms of the English language.

Lack of Vocabulary

  • Description: Without an extensive vocabulary it is almost impossible to communicate complicated ideas. The "big floating hotel boat" or "cruse ship" convey the same idea, but the correct terminology makes the communication efficient.
  • Solution: Watching television. No, really! What a great way to learn a language. The pictures and words sync up for a better inferred meaning. Thank you, "Family Matters" and "Married with Children." Also, reading helped alot. A pattern emerges.
  • Years Later: My vocabulary expanded, allowing me to more precisely craft my thoughts with elegant variation.

Getting Lost in the Process of Translating

  • Description: I would often know what I wanted to express, but would get bogged down in the details of "how" to phrase my idea.
  • Solution: Can't really stress enough the importance of reading.
  • Years Later: Most appropriately the point of fluency in a language.

Accent

  • Description: The Hunt for Red October's Sean Connery.
  • Solution: Just practicing speaking the language
  • Years Later: Can't even fake a bad Russian accent now.

Well as a PSL (programing as a second language), we each have to take a very similar path when learning new programing languages. Lets take a look at the same tells in the field of programing:

Sentence Structure

  • Description: When a language learner translates a sentence into a new language, the complexity of both languages cloud the meaning of the sentence. The new programmer often brings much of the complexity of spoken language into the code they are writing.
  • Solution: Read Code! Read books about code and code structure. Oh, the same pattern works here! Read code in open source projects. Programing languages are best learned by watching variations of language expression.
  • Years Later: You learn to think in the constructs of the language and general computer logic.

Lack of Vocabulary

  • Description: This is a real damper on the effectiveness of a green developer. This often leads to duplication of effort, the proverbial reinventing of the wheel. It also frequently diminishes the view of possible solutions, leading developers to work harder and not smarter.
  • Solution: Read quality code. I feel like a broken record. But it was reading and listening to spoken English that helped me learn English, and it is reading quality code that helped me "learn" programing languages.
  • Years Later: Obviously, I re-invent fewer wheels. But the benefits don't stop there. DSLs (domain specific languages), for example, open a whole new can of worms with syntax (vocabulary)

Getting Lost in the Process of Translating

  • Description: Instead of thinking about the business logic surrounding some iteration of a list, a green developer thinks about the for loop and the variables involved to handle it.
  • Solution: Read Code. Definitely a broken record. But read more code!
  • Years Later: The logical abstractions come quicker, as many of the same abstractions are noticeable in many open source projects.

Here are a couple of books that have helped get me here over the years:

So the moral of that story is to read code. And by "reading code" I am talking about the "Common Core" style reading for comprehension. Introspect on the code and really try to understand the meaning and intent.

So, crazy special IDE's/tools aside, litarate programing simply asks you to translate your code into English. It is almost like double checking your long devision with multiplication. I am not really suggesting that you write a novel alongside your application code, or go full Knuth with a special IDE's; it's a cool idea, but just try getting everyone on your team on that same page. :)

What I am suggesting is that thinking about the intent of our code should be a habit in the same way that unit testing should be a habit. The unit tests verify the integrity of you code, while the comments verify the sanity of those same lines. This is going to be a big goal in my personal improvement plan. Better fluency and code "sentence" structure will be the rewards, along with an assurance that the code solves the right problem.