Today's Question:  What does your personal desk look like?        GIVE A SHOUT

In praise of impractical programming

  Jacob Harris        2011-12-05 12:28:58       2,733        0    

Although it’s become a cultural mainstay now, I still remember when I first saw that thick book — the one with the wizard on the cover — about a school for magic where wonders are easily conjured by those who know the proper spells. Of course, I’m talking about the Structure and Interpretation of Computer Programs. There was that other book with the spells, but the “Wizard Book” sincerely claimed to teach magic.

For the past few years, I’ve been working as a software developer in the newsroom, where perceptions of my kind have changed from novelty to a necessity. Recognizing this, some journalism schools now even require programming courses to teach students practical skills with databases or web frameworks. It’s thrilling to contemplate a generation of web-hacking journalists — but I wish we could somehow squeeze a little magic into their course load.

Learning to program is an important skill; learning how to be a programmer requires a far different type of course. For that, I have to thank a truly impractical introduction — my first programming class at MIT, 6.001, taught in the very impractical language of Scheme.

Scheme is an academic dialect of Lisp (LISt Processing), an old-yet-advanced language designed for the theoretical work of artificial intelligence. To the beginner’s eye, Lisp looks like sentences turned inside out and nested in a truly maddening numbers of parentheses. Eventually, you learn to see it as the language of angels, because the language is not narrowly designed towards a specific purpose like matrix manipulations or building operating systems. Lisp is designed for representing symbols (and also included other important features lacking in other languages), which means it’s capable of representing anything. Because Scheme’s core syntax is remarkably impoverished, the student is constantly pulling herself up by her bootstraps, building more advanced structures off simpler constructs.

At the start of the semester, it was enough to learn how to learn about procedures; but the end, we were casually manipulating infinite streams of data and simulating the workings of a computer chip. The most radical lesson was in the middle of the term, where we learned the seemingly paradoxical exercise of writing the Scheme interpreter in Scheme itself. Appropriately, the metacircular evaluator introduction was not so much lecture as an dorkishly adorable induction into the MIT Scheme society, complete with costumes, flashpots, and each of us issued buttons emblazoned with the logo of Scheme to mark our initiation. By the end of the semester, I was entranced.

But I was no more skilled at the practical work of programming; learning theory was the point. Which is why such impractical introductions to programming is a hard sell at most universities. If students only take one programming course, professors want them to be able to build something when they’re done. Even MIT itself replaced the Lambda Mystery Cult in 2009 with a simplified course based on Python and robotics meant for students who might not be majoring in computer science. The reasoning was that programming itself had changed since the ’80s; developers no longer built whole systems from nothing; now they merely plugged together existing libraries to get something that worked. This is true for much of the programming work out there — but I am gloomily reminded of Prospero renouncing his magic.

And yet, I feel like 6.001 (and the rest of the gloriously impractical CS program at MIT) made me a better programmer. Its very impracticality forced me to understand the broader world of computer science instead of just focusing on a very narrow end-of-term goal, like building a website or learning SQL. This might be a mawkishly unconvincing argument, but at least I’m in good company; as usual, Paul Graham expresses this better than I ever could. I may not have used Scheme in years — in fact, I use the same practical tools as you. But I don’t just use a hammer: I know how its form was derived and how it could be adapted to new problems. I think this is what impractical computer science instruction gave me.

I won’t argue that journalism schools should squander those dearly-won computer-science credits on whimsical introductions to programming. But if you want to advance as a programmer, you need to take some impractical detours. If you don’t know how to program, it’s fine to pick something practical; there are fine introductions in languages like Python, Ruby, or Javascript. But then try learning a programming language that’s far different from the one you work in. Clojure is a pretty cool modern LISP. You could even take a Grand Tour through several languages at once. In the opposite direction, finally learn C, and read how your favorite language is implemented by reading its source. Read the source code of libraries and tools you admire and those you hate. Do some genealogy — learn about the languages your favorite programming language was derived from (e.g., Ruby borrowed from Smalltalk, Eiffel, Lisp, Perl, and a really key feature in CLU). Learn how to write a parser. Learn about algorithms. Learn how operating systems work. Start random projects; fork random repos. Always be coding. Ignore my suggestions and make your own. And have a blast doing it.

All that matters is that you strike out on journeys without clear destinations in lands you hardly know. Be impractical. Cast spells.

Source : http://www.niemanlab.org/2011/11/in-praise-of-impractical-programming/

IMPRACTICAL PROGRAMMING  STRUCTURE  SCHEME  PRACTICAL 

Share on Facebook  Share on Twitter  Share on Weibo  Share on Reddit 

  RELATED


  0 COMMENT


No comment for this article.