A cogent case for polyglotism in programming

When a dog owner wants to train his dog, the procedure is well-known and quite simple. The owner runs two loops: one of positive feedback and one of negative ditto. Whenever the dog does something right, the positive feedback loop is invoked and the dog is treated with a snack. Whenever the dog does something wrong, the dog is scolded and the negative feedback loop is used.

The result is positive and negative reinforcement of the dogs behavior. The dog will over time automatically behave as the owner wants and never even think of misbehaving

When a programming language trains its leashed programmer, it likewise uses positive and negative feedback. Whenever a problem is easily solvable in the constructs and features of said language, it reinforces the use of those features and constructs. And also in the same vein, if something is hard to do in the language, the programmer will shy away from thinking the idea, since it may be too hard to do in the language. Another negative feedback loop is when resource usage of a program is bad. Either it will use too much memory of too many CPU resources to carry out its work. This discourages the programmer from using that solution again.

The important point is that while all practical general purpose languages are Turing complete, the way they train programmers to behave as they want is quite different. In an Object Oriented language for instance, the programmer is trained to reframe most – if not all – questions as objects of bundled fields and methods. A functional programmer is trained to envision programs as transformations of data from the form X into the form Y through the application of a function. And so on.

(excerpt from One major difference – ZeroMQ and Erlang by Jesper Louis Andersen)

While I wouldn’t readily admit to the pertinence of  comparing a programming language to a canine owner in the way they interact with their primary subjects, the principle of positive and negative feedback loops extend beyond programming languages to the IDE‘s and platforms that we develop on. Beyond the industry, it is embedded in every tool and device we come in contact with, chipping away at every facet of daily life as we know it.

This is why I’ve spent significant pockets of my two week holiday wrapping my mind around the LISP-y Clojure and forcing myself to do it in Emacs (non-trivial, coming from many years of vimming). From the point of view of the final product, I’m hard pressed to point out any significant differences, i.e. It doesn’t matter what editor you use, or what language you code in; but from a educational and developmental angle, the benefits are rife and immense.

 

Dead tree libraries and exploratory learning

Wifey and I were driving in the car yesterday morning when the thought hit me: will I ever get to take my kids to a real library with dead-tree books? Somewhere in the background, this question was made starker by the recent introduction of one Kindle DX device into the household.

But back to the question about kids and library trips, mom used to take my brother and I to the library when we were young.

My most distinct memory of the whole experience was how sick I’d feel right before we made a trip to the library because I’d misplaced the soon overdue books we’re needing to return. It was then in my early years, I learned that being stressed out is a luxury one cannot afford when the the car engine’s started and the whole family is waiting in the driveway. I also learned that if you’re planning on hoarding lots of stuff, they should ideally be digital and indexable.

But I digress. My second distinct memory is that of the state library we would frequent. Upon entrance, it had two clearly defined section: a section for children, and a section for grown-ups. You could tell which was which by the way spaces were furnished, and how high the bookshelves stood, but you could also tell because the kids’ section smelled like children. I’d always try to steal a whiff from the grown-up section: the smell of grown-up knowledge and wisdom.

The only times I got to enter the grown-up section were when we were about to leave. Mom would send me to get dad who was busy looking up some motorcycle manual, or something about stock markets, or something about computers. Oh, what joy for me – shelves taller than the eye could see, amber coloured monochromatic computer screens to look up books, and… THEY HAD AN UPSTAIRS: double delight!

I would take my time to browse through the shelves as though I were looking for something, while hoping for the day I could understand what lay behind the incredibly serious looking covers with photo realistic pictures and titles I couldn’t pronounce.

Those trips to the library gave me something to look forward to. The whiff “knowledgeable” adulthood ever so gently nudged me to grow up a little quicker, if for nothing other than to be able to reach for the higher shelves.

I fear my kids may not have this experience. Their earliest recollections of knowledge repositories may very well begin a 4-coloured logotype, a blinking text cursor, and a button that says “Search”. What’s a seven-year-old to type in the box? How’s a child going to search for something that he/she doesn’t even know exist? And how’s a child to defend him/herself from the every increasing ubiquity of attention grabbing advertisements that seek to colour his/her mind for their commercial purposes.

I sure hope we don’t screw it up too badly for them.

A call for rigorous evidence-based software engineering

Here’s a video recording of a keynote presented by Greg Wilson at CUSEC 2010 entitled “Bits of Evidence: What we actually know about software development and why we believe it’s true”.

My favourites are a few of his closing thoughts.

On the point of research:

The point of research is to find a really good question that is going to move human knowledge forward. There are lots of bad questions out there that are either pointless or too hard to tackle. Finding something that is worth answering and within reach is an art form, and the only way to teach it to you is to have you do it for a few years.

On the purpose of university:

We are trying to teach you how to take over the world because you’re going to have to whether you want it or not, sooner than you think.

On inheriting the world:

I want [my daughter] to inherit a better world from you than you’re going to inherit from us. And the only way to get there is to have you think a little more clearly… [Before you know it,] You’ll be running the world, and the world you’ll be running will be scarier place than the one you’ve got now. You’ll be dealing with all the mess that my generation is leaving behind because we’re to fat and happy to fix it.

For a more comprehensive transcript, check out Joey deVilla’s notes on the Canadian Developer Connection MSDN blog.

Why I’m learning Emacs

In my high school years, I was one of those kids who spent every spare moment geeking out at the school computer lab. The teacher in charge there had a background in software development and was a bit of a nerd himself (thankfully).

Once in a while, a new copy of Microsoft Internet Developer (MIND) magazine would appear in the lab (he’d purchased it). I would eagerly flip through it and attempt to digest its contents.

If you’ve ever have had the privilege of reading one of these magazines, you’ll recall that every feature article had a little callout box at the start that said something to the effect of:

To get the most out of this article, you’ll need to understand Microsoft IIS, MSMQ and ASP

These articles were very technical, and my teenage grey-matter struggled to grasp the concepts presented. Which is why the callout box proved invaluable to me because at very least I knew what those labels were, which meant my journey didn’t need to come to an abrupt end; rather, there were detours that I could take en route to enlightenment.

So I would put down the magazine, seek out some 4-inch thick QUE tome, and wander merrily down wherever the path led for as long as my teenage attention span could last.

Needless to say, I usually didn’t last long enough for the chapter numbers to turn double digits, much less get back to the magazine article that I so wanted to decipher. A month would go by, a new magazine would appear, along with new set of keys for me to acquire in order to unlock the wisdom of the “grown-up professionals”.

How little things have changed.

Just this week, I stumbled upon Steve Yegge’s Tour de Babel. Lo’ and behold, a new carrot was presented to me:

All of the greatest engineers in the world use Emacs. The world-changer types. […] the greatest software developers of our profession, the ones who changed the face of the industry.

And that is why, sucker that I am, and despite having spent the last 5-6 years barely getting comfortable in Vim, I am learning Emacs.

My head hurts like hell because of my vim inclinations, but here’s hoping over a decade in, I would get a little further than my teenage self.

Have you got a story about how or why you pick things up? Share below, or join the discussion at Hacker News

Expert Conversations

Time and time again, I find myself amidst highly qualified individuals. Take the previous weekend for example. We were hanging out at a cafe after lunch. Present there were a panel highly trained individuals whose combine knowledge would span the disciplines of psychology, dietetics, mechanics, geoscience, econometrics, and multimedia (and that’s just counting the formal paper certificate stuff).

What puzzles me is how little we get to converse about the very things that we invest most of our waking hours working on.

After asking around for a bit, it came down to an infinite number of variations circling around two main themes:

  1. I don’t think it’s interesting.
  2. I don’t think anyone else is interested.

Responding to 1, I’d suggest that one would seriously need to reconsider the career that one has chosen. It’s one thing to attempt to objectively gauge the interesting-ness of a particular line of work; it is a completely different matter for one to give five seventh’s of ones adult life to something that bears no interest even to its beholder.

As for theme number 2, very few of us have cultivated the skills required to engaging domains of knowledge beyond what we are accustomed to, myself included. In other words, it is not your fault, but you could try cultivating an interest in what others are working on.

I don’t know how such a skill would be cultivated, I sure wasn’t taught any of this in all my years in the education system, but I’m going to learn to be interested, and I’m going to try and seize every chance to celebrate the abundance of expertise around me.