twobithistory.org

3 notes link to this site.

Codeacademy vs. The BBC Micro

An interesting look at how the UK government tried to educate their citizens about computers in the 70’s, and how their approach back then compares to the way we “teach computers” now-a-days.

I really liked the author’s points. Especially the idea of teaching general computing principles, not what code to write to make a computer do something, but how and why the computer requires you to write code to run programs (emphasis mine):

“Learn to code” is Codecademy’s tagline. I don’t think I’m the first person to point this out—in fact, I probably read this somewhere and I’m now ripping it off—but there’s something revealing about using the word “code” instead of “program.” It suggests that the important thing you are learning is how to decode the code, how to look at a screen’s worth of Python and not have your eyes glaze over. I can understand why to the average person this seems like the main hurdle to becoming a professional programmer. Professional programmers spend all day looking at computer monitors covered in gobbledygook, so, if I want to become a professional programmer, I better make sure I can decipher the gobbledygook. But dealing with syntax is not the most challenging part of being a programmer, and it quickly becomes almost irrelevant in the face of much bigger obstacles. Also, armed only with knowledge of a programming language’s syntax, you may be able to read code but you won’t be able to write code to solve a novel problem.

As I’ve written before, I suspect learning about computing at a time when computers were relatively simple was a huge advantage. But perhaps another advantage these people had is shows like The Computer Programme, which strove to teach not just programming but also how and why computers can run programs at all. After watching The Computer Programme, you may not understand all the gobbledygook on a computer screen, but you don’t really need to because you know that, whatever the “code” looks like, the computer is always doing the same basic thing. After a course or two on Codecademy, you understand some flavors of gobbledygook, but to you a computer is just a magical machine that somehow turns gobbledygook into running software. That isn’t computer literacy.

I’m banging the drum for “general principles” loudly now, so let me just explain what I think they are and why they are important. There’s a book by J. Clark Scott about computers called “But How Do It Know?” The title comes from the anecdote that opens the book. A salesman is explaining to a group of people that a thermos can keep hot food hot and cold food cold. A member of the audience, astounded by this new invention, asks, “But how do it know?” The joke of course is that the thermos is not perceiving the temperature of the food and then making a decision—the thermos is just constructed so that cold food inevitably stays cold and hot food inevitably stays hot. People anthropomorphize computers in the same way, believing that computers are digital brains that somehow “choose” to do one thing or another based on the code they are fed. But learning a few things about how computers work, even at a rudimentary level, takes the homunculus out of the machine.

The Rise and Demise of RSS

An interesting look at what happened to RSS. What I found interesting was the author’s “moral of the story” about how hard building consensus is (whether it’s in open source software, or even just in a business):

But the more mundane reason [why RSS failed] is that centralized silos are just easier to design than common standards. Consensus is difficult to achieve and it takes time, but without consensus spurned developers will go off and create competing standards. The lesson here may be that if we want to see a better, more open web, we have to get better at not screwing each other over.

The Rise and Rise of JSON

An interesting little story about how JSON rose to its prominence today. It’s probably an illustration of the rule of least power (“choose the least powerful language suitable for a given purpose”). In fact, the article’s author states as much:

my own hunch is that people disliked XML because it was confusing, and it was confusing because it seemed to come in so many different flavors.

The author goes on to say:

XML was designed to be a system that could be used by everyone for almost anything imaginable. To that end, XML is actually a meta-language that allows you to define domain-specific languages for individual applications...And yet here was JSON, a format offering no benefits over XML except those enabled by throwing out the cruft that made XML so flexible.

The simplicity of JSON, which I’m sure is often ridiculed, is quite fascinating in comparison to XML:

The first lines of a typical XML document establish the XML version and then the particular sub-language the XML document should conform to. That is a lot of variation to account for already, especially when compared to JSON, which is so straightforward that no new version of the JSON specification is ever expected to be written.

There were a few little historical tidbits I found interesting in this story. For example, when Douglas Crockford first implemented what would become “JavaScript object notation” by embedding a <script> tag in HTML, he ran into a problem where dynamically written keys could conflict with reserved words in JavaScript, so he just required all key names to be quoted. JSON requires quoted key names to this day.

There’s also the story about the name and the spec:

Crockford and Morningstar...wanted to name their format “JSML”, for JavaScript Markup Language, but found that the acronym was already being used for something called Java Speech Markup Language. So they decided to go with “JavaScript Object Notation”, or JSON. They began pitching it to clients but soon found that clients were unwilling to take a chance on an unknown technology that lacked an official specification. So Crockford decided he would write one.

On, and there was so linked reading in the article, some of which I followed. I liked this comment on XML, which put into words my feelings based on experience with XML:

I spend a disproportionate amount of my time wading through an endless sea of angle brackets and verbose tags desperately searching for the vaguest hint of actual information