Filed under Technology

Crystallized Archetypes

Manuel Simoni writes a very interesting (and brilliantly named) blog on programming languages entitled The Axis of Eval. For almost two years now he’s been delving deep and wide across the field of programming languages. He was interviewed by the State of Code blog a few months ago. I read something in that interview that has been lurking on and off in the back of my mind:

I think Lisp is the archetype, the crystallized form of all dynamically-typed scripting languages, and for that reason I like it. I also like C and Haskell, because they’re similarly crystallized languages in their respective areas.

As I study more about languages, and use a growing number of them on a regular basis, I can’t help but think: what are some of the other crystallized archetypes of languages out there?

Let’s start with Manuel’s list. Lisp stands out as the archetype for dynamically typed scripting languages. Other similar languages (Perl, Python, Ruby and the like) all emulate bits and pieces of Lisp (with varying success). Each new scripting language that becomes popular seems to be just a little more Lisp-y. Haskell is then the archetype for statically typed, functional programming languages. One could argue that this title belongs to OCaml or the various other MLs. From my experience working with them both occupy very strong points in the space of statically-typed functional languages. Which one you choose depends very much on what your particular needs are.

On another level entirely resides C. While both Lisp and Haskell strive to help you create elegant towers of abstraction, C will happily lay open the bare hardware for you. C is your archetype for a low-level systems programming language for a von Neumann machine. There’s certainly a new generation of systems programming languages waiting in the wings: D, Go and Rust to name a few. Though I have limited experience with any of them, from what I can tell they are all a few layers above the machine. While that’s certainly great for programmers (and I hope it picks up speed) if you want to get down into the guts of your computer you’d better reach for your C compiler. If you have more experience on this front, feel free to enlighten me.

While Java and C++ might have introduced much of the world to object-oriented programming, the title of archetype almost certainly goes to Smalltalk. While Lisp can play host to a powerful object system and OCaml goes far towards combining OO and functional programming, Smalltalk stands out as being object-oriented from the bottom up, so to speak. Of the modern popular languages, Ruby is probably closest to the Smalltalk way while still being a scripting language for Unix-like systems. I’ve only done a tiny bit of Smalltalk programming myself (and certainly haven’t made a large system) but it’s definitely a very interesting experience. I don’t know if there’s an ‘aha moment’ like there is with Lisp, but I highly recommend it if you write OO code regularly.

While those four cover most of the ground for popular programming paradigms, there are a handful of other interesting archetypes out there. For concatenative programming I’d recommend Factor. Similarly, Prolog stand for declarative, logic programming. I’m hesitant to name archetypes for web or distributed programming. Personally I think of JavaScript as more of a prototype-based OO language that happens to be in the browser than as the archetype for a web programming language. Somehow I feel like we can do better than the HTML, CSS and JS trifecta we have now.

As I keep learning about languages, I’m looking forward to exploring these archetypes in greater depth (and their particular instantiations). I might even try implementing a few of them. So much to learn, so much code to write, so little time.

Sunday Selection 2012-02-19

Around the Web

UNIX as IDE I have a love-hate relationship with IDEs. While I understand that IDEs are useful (if not essential) for languages like Java and C++, I personally can stay away from those languages and hence I use Emacs + command line tools as my IDE. Working primarily in Linux (and sometimes OS X) makes this very easy. This series (it’s a long read) is chock full of useful tips to better use Unix as your IDE.

Don’t Fall in Love with Your Technology Our job is not to use the best technology or write code. Our job is to solve problems.

Letter to a Young PL enthusiast This pretty topic-specific, but I’m a PL enthusiast so it’s relevant. If you’re interested in PL research (or just like exposing yourself to new ideas) this is a worthwhile. I don’t know half the things mentioned, but I try to learn a little more everyday. Additionally there seems to be a new PL-oriented mailing list called LL.next.

Fromt the Bookshelf

How to Steal like an Artist Ok, I’m jumping the gun on this one. It just came out and I pre-ordered on Amazon so I’m going to get it in a few days. But judging from the talk and blog post that started it all, it’s going to be awesome. Amazon has it for the cost of a venti something-or-the-other from Starbucks.

Software Tailors

I came upon an article a few days ago relating software developers to tailors. The author (Patrick Rhone) wishes to have software tailors: people who will customize (or custom-make) software for you, for a price. It’s an interesting idea and not without its practical merits. In particular, given how most software today is “mass-produced” and customization options are in general, limited at best, a cottage industry of software-tailors might not be a bad idea. But for all its merits I think the idea is somewhat short-sighted. Software is sufficiently different from physical goods (including clothes) that applying the same concepts and processes to software and clothes is fundamentally flawed.

Operationally, software is much easier to change than physical matter. There’s no physical matter to change and if you make a mistake you can revert and go back to what you had. Undo is your friend. That means that even new programmers can create things of values, make mistakes and learn quickly by doing. However, conceptually, making software is as hard, if not harder than manipulating physical objects. I’m not a tailor, but I would wager that hacking on a complex piece of software requires as much skill as making alteration to a jacket. In fact, understanding million-line codebases might well be harder than tailoring a suit to custom dimensions.

The second flaw in the software tailor argument is that our software needs are far more varied than our clothing needs. Humans all have the same general body plans, you only need a handful of numbers to make a shirt fit. But our software requirements are far more varied. The text editing requirements for a novelist are different than that of a blogger which in turn are different from that of a programmer. To really understand what each person needs the programmer needs to have a pretty thorough understanding of what the problem domain is. This in turn means that the programmer either needs to be using that specalized software on a regular basis or the customer needs to able to communicate very clearly what they want. As anyone who’s written software for clients knows, getting proper requirements is often the hardest part of the project. This is why the best software is often “dogfooded” – the developers have been using what they’ve been developing. Furthermore making changes to any part of a codebase often requires understanding more than just the component you’re changing. What might be “just a few changes” to Mr. Rhone would probably end up be hours of diving into foreign source code (or at least learning an API). Writing good software is hard, writing good custom software is harder still. I don’t want to dismiss the idea of software tailors out of hand, but I want to make it clear that the job would not be like the analogy that Mr. Rhone provides.

If we can’t have neighbourhood software tailors, then what can we have? Customized software is good, because as I’ve said, people have very varied software needs that standardized software often falls short of accomodating. What I think we need is twofold: a technological shift where developers write extensible software by default and a cultural shift by which users are no longer afraid to modify their own software. Programmers (especially open source developers) are used to modifying and extending their own tools, I want to see common software users modifying their word processors and email filters.

But, but, but, does this mean we should make our own clothes and do the servicing on our cars ourselves? No, of course not. Like I said, the tailor (and the mechanic) analogy is not the right one. A better analogy is cooking. You can eat your meals at restaurants and fast food places (use standard consumer software) or you can cook your own. If you can spend an hour or two a day putting together ingredients in exact proportions and heating them at specific temperatures for specific times, you can spend half an hour a day typing some some code to make your software work the way you want it to.

Now this cultural shift is only possible if the software supports it and right now most of our software doesn’t. But that can change. Text editors like Emacs and shells like Bash and Zsh are meant to be customized and its not hard to do so once someone shows you how. Browsers are also customizable, though not quite as easily. Luckily software is malleable and with more and more people being software literate I think this is a feasible change in the not-too-distant future. Mr. Rhone wants a shift to developers making it easier for software to be extended, but those some changes could just as easily make it easier for users to adapt their software.

So with all due respect to Mr. Rhone, I don’t want a culture of software tailors. That’s not any different from the programmer-priesthood we have today. Unlike our clothes, our computers are incredibly powerful machines and we’re increasingly dependent on them in both general and very specific ways. I want a culture of citizen hackers: a generation of people who can mix and match their software just as we can develop our own dressing or cooking styles.

As programmers, our job isn’t to write code or be better craftsmen. It’s to solve problems, everything else is tangential. I believe the best way to do that is by empowering users to better solve their own problems. We fight for the users so that they can fight for themselves.

My Brain on Information

I’ve read two things recently that have made me think about and reconsider the role of information in our lives and particularly the way in which I consume and process it. We live in an information-dense era of human history. In the western world (and increasingly, the world in general) the tools to access, consume, produce and distribute vasts amounts of information are available to almost everyone at just a moments’ notice. In many ways, we are living in a Golden Age of Information. The problem is, this Golden Age first crept up on us stealthily and then rammed into us headlong at full speed. As a result I think most of us, even those considered “digital natives” (myself included), seem to be perpetually ill-equipped to deal with both the challenges and opportunities of an increasingly information-rich existence.

Last week I read Accelerando, a set of short stories by British science fiction author Charlie Stross. The stories start from the near future (almost the present) and extend to a distant post-Singularity future where humanity lives among the stars, but in the shadows of godlike intellects. Though the entire collection is worth reading (and available for free), the first few stories about a world not too different from our own were particularly interesting. At one point one of the main characters, a very intelligent serial entrepreneur (and “venture altruist”) name Manfred Macx claims to consume a megabyte of text and several gigabytes of multimedia a day just to keep current.

That’s a lot of information for any person to consume in a day – a megabyte is roughly half a million English words. Though this is science fiction, I think we’re quickly getting to the point where people who want to stay current with the pace of science and technology will be required to consume enormous amounts of information regularly. Half a million words a day may be too much for an unaugmented human (Macx has an array of cybernetic implants and software agents forming a “exocortex” for information processing) but I think tens of thousands of words a day will soon become par for the course. And that’s just text. I’m not including understanding diagrams, source code, operations manuals or even video or audio. If we’re supposed to be assimilating such huge quantities of information on a regular basis how are we supposed to make sense of it all?

That brings me to a piece on The Atlantic website dramatically titled “Is Google Making Us Stupid?“. It’s about how the use of search engines and similar fast information retrieval systems is supposedly rewiring our brains. While some parts of the piece are overly sentimental and melodramatic, the core point is sound: the tools we have access to and the way we use them plays a role in shaping the functionality of our brains. I also sympathize that a habit of continually sampling little bites of information can be deeply unsatisfying. It’s easy to get hooked on to a Facebook or Twitter stream but as you stay hooked you can feel your brainpower wither as you lose the ability to concentrate longer than 140 characters. When I get stuck on Hacker News or Reddit for hours I feel terrible by the end of the day. Though I love good stories and movies it’s easy to get hooked on Netflix, passively consuming information but not really doing anything. But I’d like to believe that we can train our brains to be not quite so helpless in the face of endless streams of juicy tidbits.

A growing body of research is showing that the human brain is an incredibly flexible organ. Neuroplasticity is the norm, not the exception. As the amount of information we need to process increases (and our tools to do so get better) our brains change to accomodate it all. That of course begs the question: how far can we push ourselves? Can we train our brains to not just flit from hyperlink to hyperlink but actually digest and understand large amounts of interconnected material with greater efficiency and accuracy? Can we ensure that Google makes us smarter and wiser, not stupider?

Though our reading habits (and by extension our general thought patterns) might be changing, the change is not accidental nor is it inevitable. Instead of bemoaning the loss of the slow reading habits of yesteryear I think we should be trying to embrace the information-dense world around us. In particular, we need to stop thinking of deep reading and skimming as antagonistic to each other. Perhaps what we need to do is not to read slower, but rather separate the physical act of reading from the mental act of comprehending what we have read. I would love to be able to read text fast, look up links and references and then let the mass of information “ferment” in my brain. I’d like to be able to train my brain to think of what I’ve read after I’m done looking at the text forming connection betweens concepts and ideas while I’m walking down the street or taking a shower.

Perhaps this is an exceedingly computer-science centric way of thinking about the brain and thought processes. To be honest, I’ve been writing code and processing data algorithmically far longer than I’ve been learning about how the brain works. I do tend to think of the brain primarily as an information processor. Unlike the author of The Atlantic article I’m not nearly as attached to the so-called “human” aspect of my intelligence (but that’s a matter for another blog post). I like settling down with a cup of coffee and a good book in a nice armchair as much as the next guy, but only on the weekends. During the week I’d like to come up with six impossible things before breakfast and figure out how to make them possible through the course of the day. To do that I need to keep the information machine fed, creativity doesn’t happen in a vacuum. I’d love to know how to do that better.

Looking ahead

It is now just about a third of the way through the first month of the year. I’m not really one for resolutions so I didn’t make any. In fact, I didn’t do anything by way of preparing for the start of a new year. However there is one thing that I’ve been wanting to do for years that I hope to finally get around to doing: concentrate more on my writing, in particular, paying more attention to this blog.

I’ve never really wanted to be a full-time blogger, not even a technology blogger. I’ve always preferred to be someone who wrote code (or at least studied writing code) and wrote about those experiences on the side. By and large, that’s been true. However the thing is that I really like writing. It’s a good break from coding and thinking about computer science research and I enjoy communicating directly with people instead of machines for a change (which is why I refuse to pander to search engines and write SEO-directed stuff). Anyways, despite my not being a very regular writer this blog has been moving along nicely. I get around 400 hits on an average weekday and that number has been going up steadily. I’ve been on Hacker News more than once and that’s always generated a good burst of traffic.

I’ve also been discovering technologists and scientist writing interesting and very useful blogs. These are people like danah boyd (Senior Researcher at Microsoft), Matt Might (CS Professor at the University of Utah) and Andrea Kuszewski (a researcher at the George Greenstein Institute). I admire their blogs and their writing but I also admire them for being dedicated scientists and researchers. These blogs reaffirm my belief that writing on a regular basis is important (and healthy) for everyone especially if you’re involved in research and development of new technologies.

All that is a way of saying that I would like to blog more. Looking over my archives for last year I’ve only made about one post a week. Ideally I would like to increase that to two or three a week, not including the Sunday Selection link posts (I doubt I could keep up quality for anything more than that). I also want to start tackling more technical subjects. I’ve been talking a lot about the intersection of technology and productivity for a while now, but I’m starting to get a tired of the productivity aspect. Long story short, I’ve found the small set of everyday tools and environments that I need to get work done. For the foreseeable future it’s more a question of being able to stick to habits and schedules than of using the right tools. When I do speak of tools I want to give concrete examples (like my post on showing Git information in your Bash prompt) rather than handwavey suggestions.

On a related note I’ve been considering moving off WordPress.com. WordPress is great if you’re using their web-based interface but is harder to use if you live in Emacs. I’m starting to itch for a writing system that integrates well with Emacs. I’d like to be able to include my own HTML, CSS and JavaScript in my posts and be able to customize things a bit more than WordPress.com allows. I haven’t given much thought to this matter, but I’m looking at alternate systems such as Jekyll and Octopress. Whatever I decide to do I’ll probably test it out at my personal website before doing anything over here.

While this blog is definitely my most serious writing project, it’s not the only one. I took a few creative writing classes in college and enjoyed them immensely. I would like to be able to continue writing fiction (and maybe even get in shape for NaNoWriMo 2012). But for I’ll be content with just regular blogging output. Glad to have you all along for the ride.

Follow

Get every new post delivered to your Inbox.

Join 301 other followers