Fluent in 3 Months: A new bilingualism
Week 3&4/12
Among the myriad differences, computers are less forgiving than humans. Say you’re building a simple to-do list. A single typo would suffice to break your application. Whereas a grammatical mistake on your part might not hinder the flow of the conversation as your partner nevertheless grasps your meaning, a computer will stop you at the sign of a misplaced letter. You might take 30 minutes to find that typo with the result of a now seamlessly working application. I’m sure every developer has been there. I thought I might be less susceptible to typos due to my copy-editing experience but to no avail. Instead of politely correcting you, they give you lengthy and frightening error messages in their own language, most of which remain incomprehensible to you, and the rest often vague. Computers are very literal and very demanding. There’s no hand-holding. Despite the seemingly light-speed progress of AI and computer languages, computers still have a hard time deciphering what we can express in words so effortlessly. I wonder how close computer languages can get to speech — I immediately thought of Ruby, which I mentioned in my last article, versus C, the grandparent of modern computer languages. Let’s look again at a Ruby function vs C. The goal of each program is to print “Hello World.”
int main()
{
printf("Hello World");
return 0;
}puts "Hello World"
About twenty years after the invention of C language, the evolution of programming language syntax exemplified by the Ruby example is impressive. It goes without saying that the latter more closely resembles English than the former. What kind of style choices will creators of programming languages take in the future? Which words will they include, and which will they forgo? Naturally, a programming language complete with synonyms and prepositions would be a nightmare for the programmer, but the former would provide room for style, not unlike in code tests. Imagine code copywriters, whose sole job is to make code more readable and elegant! Actually, that’s not a bad idea. “Refactoring” is already a thing — basically editing your code so that it’s more concise/readable/efficient. As with drafting a paper, when you start coding, you just want to hash out your ideas and convert them into something workable. It’s a rough draft and not totally presentable, but you’ve just done enough work to give yourself a pat on your back. Then comes the editing, or refactoring stage: you revisit your work, put in some fancy methods, and hopefully come out with clean code that you’d be proud to show and tell. Of course, there are applications that automate this process. They carry names like “Prettier” and “Beautify” that entice you to no end and automatically align your code or insert tabs to make even the sloppiest code look aesthetically pleasing and consequently produce lazy coders. As their names suggest, their help is merely superficial and doesn’t help make your code workable, or more efficient. If programming languages took more liberties with their syntax and style, I wonder how far programs like “Prettier” could go to correct your code. Would they always prefer the newest and latest syntax? Would they reprimand you for being repetitive?
Since I’m bad at making decisions, I for one am happy that there’s not too much room for style in programming language syntax. I’m also sure that anyone who has to work on someone else’s code would agree.
