How much do environments matter?

The last week and a half has been really productive. I’ve written a lot of code, made progress on my research project and learned a lot of stuff in the process. Unfortunately it’s all been in one area, but that’s a matter for another post. But given how productive I’ve been one thing that I’ve been wondering is how important an environment really is to productive.

I’m usually of the opinion that environment (both physical and in terms of setup) is really important for any sort of creative or intellectual work. However I’m not quite so certain anymore. My current working setup is less than perfect. Though I have a nice DIY standing desk and a brightly lit office I also share the office with six other people and at times it can get pretty busy and crowded. I have a very powerful work machine but most of my recent work has been in a basic Ubuntu virtual machine with no customization other than my Bash and Emacs setups.

Despite the fact that my environment is not perfect the last week has probably been the most productive I’ve had all year. This begs the question: are environments really as important as I had thought they were? Or is it sufficient (and necessary) to have a project you’re really interested in? Of course, I understand that this is a personal question, so I’m just going to try it for myself.

What I’m starting to think is that the environment doesn’t need to be perfect, it just has to be “not painful”. There are some things that I just can’t stand: I can’t stand bad chairs, environments that are too noisy or too high of a room temperature. But once I have air conditioning, a standing desk and decent set of headphones I can quite easily tune out everything else. Similarly, once I have a command-line UNIX environment and a decent enough keyboard I care much less about what window manager I’m using, what size my monitor is or even what my language or toolchain is. Once I’m in the zone there’s very little that I care about.

I would say that environments matter, but only to some extent. After a point an interesting and exciting project can easily make up for any deficiencies in the environment. However, the opposite – a great environment but an uninspiring project – hardly makes you want to jump out of bed in the morning and get to work.

In addition to my Macbook and my work machine I have a small Eee PC lying around with a bare bones Arch Linux install on it. As a small experiment I want to see if I can be as productive on that machine as I am on my work machine. In addition to my research project I’m taking a programming languages class and TAing a functional programming class, so I regularly find myself in the mood for some OCaml hacking. Admittedly it won’t be a scientifically controlled and rigorous experiment, but it will be interesting to see how far an interesting project can compensate for a less then ideal environment.

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

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.

Graduate School Semester 2

I’m about a month into my second semester of graduate school at Cornell’s excellent Computer Science department. (Shameless plug: If you applied and got admitted you should definitely come visit, we’re awesome. If you’re thinking of applying contact me with questions.) The first semester involved a fair amount of getting used to grad school life. It’s pretty different from undergrad and I covered my initial impressions before. There’s a lot of autonomy (even in the first few semesters) but that means it’s all that much easier to screw up. The most important lessons I’ve learned are to start early, make plans and schedules and set up routines and environments that make getting the work done the default (this applies to both school work and research). I’m definitely not perfect at it, but I try to suck a little less each day.

While last semester was a good learning experience I got a lot less done than I could have. While I don’t want to cry over spilt milk I certainly don’t want to make the same mistakes again. My class load and TA work are about the same as last semester. However I have a better idea of how much time each takes so I can schedule blocks of time more effectively to get large chunks of work done at a time (and not worry about it otherwise). That in turn means that I can have more time for research (which is something I definitely want to do more of this time around).

I’m really happy about the choice of classes I have for this semester. I’m taking Advanced Programming Languages and Datacenter Networks – both are areas in which I have an interest but I know less than I would like to. I have great professors in both and so far the material has been very interesting (and useful). I’m the TA for a class on functional programming which is turning out to be a good learning experience as well. I’ve done some amount of functional programming but not a lot and not in a structured way. I’m working through the exercises and homeworks myself so that I can better help out the students and learning a lot in the process. Since I’m going to be doing a lot of functional programming in the future (Haskell programming in particular) this a good way to level up as well as get my TA duties done.

Last semester I had a small research project which was more of way to get familiar with the concepts and tools I’ll be using later. I am a little disappointed in that my final deliverables weren’t as complete as I would have liked but the experience will come in handy. This semester I have a more concrete (and more ambitious) project. I’m also starting sooner and thanks to last semester I have a far better idea of the challenges I’ll face and how much work it will take to get around them. My main interest in programming languages and right now the project isn’t very language-oriented. But there is a lot of cool systems-hackery involved and once the foundations are laid I can move on to the more higher-level language-oriented parts of it. I’m still taking baby steps (figure out build systems, building testbenches and having rather intense discussions with my compiler) but within a week or two I want to progress to the real meat of the project.

Aside: In case you’re wondering, it involves networks and trusted computing, but more on that in a future post.

Apart from school and research work I’m hoping to do some more exploring. Cornell has a really nice campus but I only saw a small fraction of it last semester (and probably spent a bit too much time in my apartment). I’d like to be able to get out more and take advantage of everything that Cornell has to offer. That’s a bit easier said then done in winter, but that’ll change as things get warmer.

I’m still trying to work out the best “work life balance”. While things like Cal Newport’s fixed schedule productivity seem appealing it might be unworkable for me right now. More importantly, I’m still not sure how separate my work and my life should be, or even what constitutes “work”. I haven’t decided if I consider my writing or my on-the-side hacking (which I’ve been doing far too little of recently) to be work, play or something else. Part of me would like to think that the work-life distinction is only applicable to a more Industrial Age setting where you don’t like your job and want to spend as little time doing it as possible. Ideally you should do work you love (which I’m gradually approaching) and have no need to draw a distinction. While that seems appealing I’m afraid it might lead to sitting (or standing) in front of my machine all day which is not what I want to do. Luckily these aren’t questions I have to answer definitely right now, but I can keep refining my answers over time.

I’m hoping that the rest of the semester will have lots of great learning, cool hacks and maintaining some semblance of a life away from my machines. I know that graduate school can easily become a drag and very stressful and I’m determined to not let myself end up in such a position. Luckily I’m in a good department with great support from friends, family and professors. I’d like to see this semester be more productive and a step on the way to deciding exactly how I want my grad school experience to turn out.

Sunday Selection 2012-02-12

Around the Web

The Information Diet : A Case for Conscious Consumption You could consider this a counter-argument to my previous post on how we can use consume and use information. I think we’re still pretty early into the Information Age and we’re still coming to grips with the fact that we have the world’s knowledge just a few clicks away. I haven’t read the book yet, but it’s definitely on my reading list.

10 Rules of a Zen Programmer I’m not entirely sure why there seems to be a strong interest in Eastern meditation and mysticism in the hacker culture, but tit does lead to some interesting analogies. In that light, this article is both pragmatic and idealist. While I don’t agree with all of it (no. 5 for example) it’s a worthwhile read and might help change your perspectives.

How to be Relentlessly Resourceful This isn’t about technology or Zen (at least not directly). It’s more about how to get the job done. And we all want to get the job done.


Spotify To be honest, I still have my doubts about streaming music. I do prefer to have my own collection that I’ve paid for and (mostly) have physical copies of. That being said, I do think Spotify is a really neat service and a good way to try out artists and albums before I decide to buy.