One reason I am writing about learning to code Cocoa apps for OS X and iOS is that I view programming languages as specialized human languages. After all, humans do create the languages. We create computer languages with our notions of what a language should be, from its grammar to its level of abstraction.
In my post on the generations of programming languages, I mentioned that languages are interpreted, compiled, or translated, with some variations and complexity within those processes.
Let's consider how these compare to the human language process.
Or brains might be called "just-in-time" (JIT) compilers. They are fast, but there is still a lag between thought and action — or action and thought!
The interpreter has to know both languages well. That requires a fair amount of memory. The interpreter also has to know the oddities, the quirks, of the two languages. Most interpreters cannot match the power of a compiled language — but they are more than sufficient for many tasks.
When you translate a program from BASIC or Fortran to C, a common task with "Business BASIC" and free Fortran compilers, the resulting C code is not as efficient as programs written directly in C. Translating software simply applies rules and patterns to the process. When we speak, we don't always communicate the same idea with the same words. The words change, based on context. But, a translator does not appreciate nuances within a language. Words and phrases are translated with a rigid formalness.
If you speak more than one language, you might recognize that people also learn second languages in a formalized manner. I know a bit of Spanish. When I speak Spanish, I still include the pronouns that a native speaker omits over time. My Spanish is more "wordy" than a native speaker's Spanish. Yes, it is correct, but it is also inefficient.
As I'll write in future posts, learning to program is learning additional human languages. At first, you translate ideas. The code you write works, but it lacks "native" elegance. In time, you master a language and adopt the common idioms. You learn what to omit and why.
Hopefully, others find this comparison useful and come to appreciate why I value teaching programming to more students.
In my post on the generations of programming languages, I mentioned that languages are interpreted, compiled, or translated, with some variations and complexity within those processes.
Let's consider how these compare to the human language process.
Compiled Languages
About as close to the "natural" machine code as many programmers get on a regular basis, compiled languages remind me of our "native" spoken and written languages. After a while, we think our silent thoughts in a human language. We are entirely unaware of how our brain converts (or compiles) the language into neurological pulses. For me, English seems to be the language of my brain — even though it isn't.Or brains might be called "just-in-time" (JIT) compilers. They are fast, but there is still a lag between thought and action — or action and thought!
Interpreted Languages
Interpreters work in "real-time" with some overhead. The interpreter, a specialized program, translates each line of human-readable programming code into machine code. This is similar to having a sign-language interpreter standing beside a public speaker. A good interpreter is fast — keeping up with the speaker, with only a slight lag. But, there are some challenges.The interpreter has to know both languages well. That requires a fair amount of memory. The interpreter also has to know the oddities, the quirks, of the two languages. Most interpreters cannot match the power of a compiled language — but they are more than sufficient for many tasks.
Translators
When you translate one computer language into another, and then compile the results, you end up with acceptable machine code. I compare this to translating literature. Imagine wanting to share Dante's Devine Comedy with a literature class. Instead of reading the Italian with an interpreter repeating the lines in English, it makes more sense to translate the original. But, the translation is never perfect.When you translate a program from BASIC or Fortran to C, a common task with "Business BASIC" and free Fortran compilers, the resulting C code is not as efficient as programs written directly in C. Translating software simply applies rules and patterns to the process. When we speak, we don't always communicate the same idea with the same words. The words change, based on context. But, a translator does not appreciate nuances within a language. Words and phrases are translated with a rigid formalness.
If you speak more than one language, you might recognize that people also learn second languages in a formalized manner. I know a bit of Spanish. When I speak Spanish, I still include the pronouns that a native speaker omits over time. My Spanish is more "wordy" than a native speaker's Spanish. Yes, it is correct, but it is also inefficient.
As I'll write in future posts, learning to program is learning additional human languages. At first, you translate ideas. The code you write works, but it lacks "native" elegance. In time, you master a language and adopt the common idioms. You learn what to omit and why.
Hopefully, others find this comparison useful and come to appreciate why I value teaching programming to more students.
Comments
Post a Comment