Ben Popper is the Worst Coder In The World: Quantum Edition

This is part 2 of an ongoing series detailing my journey from total noob to hobbyist coder. I share my thoughts as I learn the basics of programming. You can find the rest of the series here.

Welcome back to The Worst Coder in the World. Last time I talked about my experience learning HTML and CSS. Since then I moved on to the JavaScript portion of the FreeCodeCamp curriculum. 

Like my experience with the basic HTML lessons, going over grade school addition, subtraction, multiplication, and division made me feel silly. Does it feel less embarrassing if you’re learning to code when you’re still a kid, and this kind of work is part and parcel of regular school? 

But like Paul said on the podcast below, the nice thing about acquiring some new knowledge, even basic stuff, is that you start to see the world through a new lens. A few days after finishing the JavaScript lessons on basic mathematical operations, I was playing some Hearthstone, a collectible card game similar to Magic the Gathering. 

I started to think about how the code running the game might be set up in order to calculate the health points left after a certain attack does damage, or how the system might select a random card from your deck when confronted with an even or odd number of cards in the pool. The logic behind the scenes started to feel as interesting as the action happening on my screen.

Hearthstone runs on the Unity gaming engine, which makes it easy to develop for different software platform and hardware form factors. Unity seems to mostly run off of C# these days, and as it turns out, so does Stack Overflow! Small world. I love the idea that I could learn one language and suddenly be able to peek underneath the hood of the software at my job or my favorite video game and perhaps of some faint understanding of how it all worked.

Logo, Logos, Legos

It feels like programming would be a lot less intimidating if the vocabulary used to describe operators was closer to what the average person learned in school. Learning to concatenate a string sounds difficult. Putting a bunch of words together in a certain order, now that sounds approachable! 

To be fair, by the middle of the curriculum, the course started speaking my language. The following rather technical direction – “You will need to use the string concatenation operator + to build a new string, using the provided variables: myNoun, myAdjective, myVerb, and myAdverb.”

Was nicely translated to – 

“We provide you with a noun, a verb, an adjective and an adverb. You need to form a complete sentence using words of your choice, along with the words we provide.”

Making your writing, or your code, easy to understand, seems like a simple maxim. But I was a bit confused by some of the advice the lessons had to offer. For example, the lesson suggested that “there shouldn’t be any spaces between the array name and the square brackets, like array [0]. Although JavaScript is able to process this correctly, this may confuse other programmers reading your code.“

If it works for the machine, what’s the problem? As Cassidy Williams, the curator of The Overflow newsletter explained, “When you do array[0] it’s clear that it’s getting the first value of an array, but array [0], it’s confusing because it could be considered a variable named array and another instance of an anonymous array with length one and the value of that item 0.

TLDR: “JS does things that it probably shouldn’t and other languages don’t allow because it is confusing.”

So, these fancy and popular coding languages are flawed from the foundation! I want a refund! Ah right, the class is free.

Ghost in the Shell, Defect in the Dialect

On second thought, I realize I have run into this same problem in my own domain. I’ve been trying to teach my six-year-old to spell recently, and let me tell you, the English language some serious inconsistencies. There is a reason our fourth most popular Stack Exchange is devoted to the subject. He might write that his new pair of shoes are “Bloo” or “BL00” or “Blue” and most experienced readers would understand what color he’s trying to describe. They would certainly have an easier time with odd but obvious spelling than I would have trying to explain to my kid the complex history of why blue is spelled the way it is.

“Well son, thousands of years back, people in Central Asia used the word bhle to describe something that was light-colored. Light blue, light yellow, ya know, just kinda light. From there it evolved in a lot of directions. Ya got belyi, which is Russian for white, blawr in Welsh for gray, blavo in older Spanish for yellowish-gray. We speak English which comes from Old English, which used bleu, cause back in the dark ages people in what we now call England were also French.

Consider yourself lucky! Way back in the day, folks couldn’t even see blue, so they just described the ocean as looking like dark wine.”

Apparently I’ve got options for languages that were created with the overlap between spoken language and computational logic in mind.

A Pattern in Nature, Found Everywhere

All this linguistics got me thinking about what the parallels are between my old job and my new line of study. Back when I was a journalist, I used to spend months reporting, researching, writing, and editing a feature story. While it might not seem like it from the outside, I was of course, concerned with performance. If a piece of software is slow or buggy, users won’t stick around. The same is true of an essay or feature story. If the transitions between sentences and paragraphs aren’t strong, people will get confused, or worse yet, bored. 

So what does a bug look like in journalism? Just like coding, small, rather trivial errors can cripple a massive project. Get a date or location wrong and suddenly the accuracy of your entire piece comes under suspicion. Tech has pair programming and code review, journalism has editors, fact checkers, copy editors, and more. A single sentence in the New York Times may end up being touched by far more people than your average line of code, at least the first time it gets pushed to production.

The author and web app engineer Isaac Lyman shared this nugget of wisdom with me on Twitter. (note – as a reader pointed out, right after a paragraph about the importance of accuracy in writing, I spelled Mr. Lyman’s first name wrong in the sentence above. Now the entire article is ruined!)

As I was puzzling my way through the relationship between a written language and a programming language, Google was busy announcing Quantum Supremacy. I was chatting with Paul and Sara about this topic on the recent podcast, and they made the point that if this becomes a powerful new paradigm, computer science programs will need to start teaching advanced physics. We already see folks studying hard core math and statistics they can apply to machine learning that a decade ago would not have been taught to most computer science majors.

Our guest, Clive Thompson also hipped me to an old language, FLOW-MATIC, the first English-like programming language. It was created by Grace Hopper, who at the time was working for the RAND Corporation and trying to sell more computers to corporations and government agencies.

“I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. […] They said, ‘Throw those symbols out — I do not know what they mean, I have not time to learn symbols.’ I suggest a reply to those who would like data processing people to use mathematical symbols that they make them first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it.”

At the time, her colleagues declared that writing anything but binary and assembly level code was blasphemy. Compilers were certain to introduce more errors than they solved. Our Chairman, Joel Spolsky, recently said, “I just picked up Arduino a year ago and that was enormously fun because it was like going back to C, instead of all these fancy high-level languages where you don’t know what they are going to do. It offered a  really detailed level of control. If something doesn’t work, you can figure it out, because everything is tractable.”

He see a growing gap between those skills and what many folks learn to land jobs in junior developer roles doing web or mobile work. “In my time, it was the absolute control. Whatever code you wrote, that’s what executed. There was no translation. It wasn’t like, well the flour was kind of old, and I tried to make the souffle but it collapsed. Unlike so many things you will try to accomplish as a child or an adult, where you work on something but it doesn’t turn out as you expect it to, with code it will do exactly what you told it. Even if that’s not what you meant. You might suddenly realize you’re obeying me to the point of making me angry.  It’s sort of utopian. Things behave as they are supposed to. The reason I put a question mark on that, as programmers move higher and higher up the abstraction tree, that kinda goes away.”

The Arrival – new language, new ideas?

It seems like this may be one of the eternal debates of computer science. What are the advantages of keeping things rooted in math, logic, and a collection of domain specific commands versus the advantages of opening up your language to a wider audience by adapting it so that it connects back to the language we read, write, and speak everyday.

And if that’s the case, are there any popular programming languages, at a global level, that have gotten traction with developers, lasted for years, and been used to build popular products and services, that weren’t originally written in English? Is the grammar – textual or ontological – of German or Chinese perhaps better suited to generating the next great code?

Whew, things got heady there for a minute. I’ve got to get back to the grind of understanding how to access array data with indexes. If you have thoughts on these topics, we’re always looking for folks to submit ideas for the blog, so hit us up at pitches@stackoverflow.com.