It’s occurred to me more than once that I really don’t know many great programmers. I go to a small school and most of my fellow students are about the same level as I am (or lower). Actually I don’t really know what level they are on because I don’t get to work with them as much as I would have to in order to find out. There is only one person whom I can say for certain is a better programmer than I am and I’m currently doing a project with him. My professors are good computer scientists, but I have no idea how good at programming they are.

But from what I’ve read (and what I can attest to from personal experience, to some extent) achieving excellence in any field (especially programming) requires a lot of dedication and hard work — about 10,000 hours of it. I’ve thought about whether or not it really is worth it to invest so much time in one activity, even if you really love it. I love spinning code, but I don’t want to be sitting in front of a bright screen all the time. Watching the dancers the other night, I got to see what dedicated practice can bring. They put on a great performance and everyone enjoyed it (including myself) and creating something beautiful and wondrous is a worthy cause. But I’m also interested in getting to know about what they dancers themselves think about their work. I’d love to know their feelings and emotions as they dance and have people cheer and whether they think it’s fair compensation for their commitment. And I don’t mean compensation in only the monetary sense, though that is important too.

Admittedly there is nothing in the programming world that is quite the same as a great dance performance. Our victories are more personal and what people see (and sometimes applaud us for) is often a small sliver of everything that we do. But that’s fine by me. When I solve a hard problem after a long time (my personal record is 3 hours hunting a pointer bug) or make something that I think is really cool (a recursive-descent parser for a little language), I think I feel some of the elation, satisfaction and relief that I think the dancers would have felt too. Yes, it does feel really good. As each year goes by I get better at doing what I love doing. But I rarely ever think about all the practice and experience that has gone into making me capable of whatever it is I am doing. Not too long ago, I would never have imagined myself capable of writing a UNIX shell or designing a programming language, but know I am doing both those things and it feels almost natural.

Ok, that last sentence was a lie. It doesn’t feel natural, but it feels like it’s just outside the range of being natural. When I’m doing things like that, I’m on the edge of incompetence. It was hard and it was painful, but now that I know I can do it, I feel much better. In some ways, I wish such chances came more often (I think the education system for computer-related studies needs to be revamped significantly, but that’s another matter) and I know that each such experience leaves me just a little bit better. Do flamenco dancers feel the same way? Maybe. It would be interesting to find out.

Excellence is a rather strange thing in that it’s hard to achieve and the return on investment on its pursuit can be very little until you get to a certain tipping point. And then there all the people who seem to be trying really hard without getting anywhere. I’m not surprised that many people choose not to put in the investments that it takes to be excellent. As a girl I liked once told me, there are a lot of people leading average lives who are very happy about it. I guess that’s true. I’m not clear about where I stand on excellence myself. I do want to be really good at what I want to do and I fully understand that it won’t be easy. But I also don’t want to give up everything on the quest for excellence. “No sacrifice, no victory” sounds very noble and all, but there’s a tinge of recklessness that I really don’t like.

At this point, the word “balance” might seem appropriate. But that’s bullshit too. I don’t think people who are great at something got there by seeking balance. The better option is breaking the rules, or at least fracturing them. The prime example is 37signals. They’re a small company, with little VC funding who don’t give away their products for free and still make millions of dollars. And they didn’t do it by working round the clock either. They broke “rules” like working 80 hours a week and making free products and other such things. But they also knew what rules to break. They didn’t break rules about being thrifty or having a solid business plan. They might not be the paragon of excellence and they’re certainly arrogant, but they’re doing well so far.

As someone seeking excellence myself, I’m trying to bend my own set of rules. I bend rules by taking courses out of sequence, doing independent studies where I can write lots of code and meet interesting people and actively trying to talk to people I admire. I need to put in 10,000 hours, so I build my life to provide opportunities to do just that. I really wish that there were a lot more people doing the same.

Happy hacking.

While I agree with the theory in general, I can’t bring myself to go the whole nine yards and completely disconnect everything. A related article by Alexis Madrigal argues that the unlinking doesn’t work with Twitter. Twitter has no memory and Twitter is most useful when you have other meatier services (like a blog, website or even just Facebook) that give people a better idea of who you are. The author argues that Twitter’s relative impermanence means that it’s worth piping your Twitter stream into something more permanent. For my part however, I see things the other: I want Twitter to be my catch-all because it is impermanent.

The New Old Deal

Here’s the deal: I accept that cross-linking feeds leads to some amount of pollution and that’s not something I should be subjecting my friends too. My friends on Last.fm don’t care about how many billions of floating point calculations I’m running at the moment and the readers of this blog probably don’t care about my thoughts on modern instrumental music. But as Madrigal puts it, Twitter is different. I feel uncomfortable calling Twitter a social network. To me it’s  more like a broadcast service. You send out little snippets and anyone connected can read it. Of course you could have a private feed and carefully control your followers, but I feel like that’s just a holdover from email (where spam is a clear and present danger). Also, Twitter is not email. It takes far less overhead to skip something that you don’t care about and personally at least, I don’t feel the same pressing urgency for my Twitter inbox as I do for my email.

When someone follows me on my Twitter account, I want people to understand that they’re getting the whole deal. They are getting my 140-character updates (which make up the bulk of my stream) but they are also getting my regular tech-related articles as well my discoveries online. Tim Maly notes that time is precious and accounts are cheap and it seems that he was talking primarily about other peoples time. While that is true, my time is also precious and so is my mental overhead. As an example, I take myself.

Account Overload?

I could, right now, split my Twitter stream into at least three separate accounts: one for updates only, one for my blog and tumblelog and one for my Last.fm feed. Thanks to Twitterfeed, I can set things up automatically to post to whichever account I want. That’s all fine and dandy and I’m really tempted to do it. But what happens when I have a thought about music that isn’t engendered by Last.fm? Does it go into statuses, music or both? Do I really want to tell my close friends that they now have to follow me on three different accounts to get everything (not to mention the overhead of @-reply conversations that could easily start crossing accounts)? Should I have a fourth account that pulls everything in for those who want it? I’ll be the first to admit that my example is somewhat contrived and probably a worst case scenario, but it deserves some thought. I would rather have Twitter collect everything with a disclaimer that people might be getting more than they bargained for.

As for pulling out of Twitter to somewhere else, I’ll agree that’s just a bad idea. Twitter has grown it’s own syntax with @replies and hashtags and the like which really make no sense elsewhere. The only place that you should even consider piping Twitter to is your Facebook status. As a friend of mine said when he dabbled in Twitter briefly: “It was like setting my Facebook status, except that’s all I could do”. Point taken. Even then, it’s a good idea to sanitize your stream to remove all the Twitter-speak. I use the Tweeter application which gives you some good filtering abilities.

In conclusion

• Cross-linking your social networks is a bad idea.
• Except for Twitter. It makes a certain amount of sense to pipe your feeds to Twitter.
• Exporting Twitter to elsewhere is also a bad idea, because of Twitter-speak, except maybe for your Facebook status, if properly sanitized.

As an addendum, if you do decide to use Twitter as your catch-all, I suggest you standardize on a solution. Many services give you the option of piping to Twitter from within the service yourself. That may be fine if you have one or two services and want your posts to appear immediately, but the overhead grows as the number of services grow (and each service has the options in a different place). I recommend using RSS as your glue and piping things through Twitterfeed. There will be a short delay, but I don’t think that will much of an issue for most people.

Ars Longa, Vita Brevis

As I’ve pondered before, life is short and it takes a fair amount of dedicated effort and time to come up with something beautiful and useful. With the rise of the Internet and instantaneous communications, we’re becoming a culture that is very much used to continuous streams of small information packets. The essay is becoming a holdover from the old days when having long periods of times to do nothing but sit and read was common. However, there are a number of really good essayists alive today, and a lot of them are on the Internet. There’s Paul Graham, whose essays are practically the stuff of legend for programmers. There is also Steve Yegge who seems to have retired, but left behind a fairly large collection of essay-length material (including an article on why you should write a blog). Outside the Internet there is Warren Buffet who has written long detailed letters to shareholders for the last 32 years each of which is an education in and of itself (and I can’t help but wonder how many shareholders actually read through them all).

I don’t think I’m making a mistake when I say that the essay is still alive and well today, albeit in somewhat modified forms. But the fact remains that putting out something of such length and depth takes up a lot of time and energy (not to mention the countless hours that go into accumulating the knowledge and organizing the thoughts that must flow into such a work). In many ways, writing an essay is similar to a software project. There is planning and preparation that must happen upfront, but nothing is really for certain until you sit down and start writing. Writing a good essay that other people will want to read and tell their friends about is no easier than writing good software that others will want to use.

Blog meet Essay

The blog and the essay are fundamentally different things. A blog is a magazine compared to an essay’s book. The blog as a format is great for some things: without easy blogging I probably wouldn’t be writing at all. But the rise of blogs (and accompanying software) has left the long form essay in the dark. You could simply write long articles and put them on your blog like Steve Yegge. But reverse chronological ordering really isn’t the best format for a collection of essays. For small numbers, a simple list of titles, maybe with a blurb is probably the best. Once you get to a larger number (Paul Graham for example), a simple list doesn’t cut it any more.

There is also the actual writing experience. Whenever you write a longer piece over the course of many days, you start to go back and visit the old parts. Part of it is for editing, but you also want to read what you’ve read before so that you know you’re keeping your essay coherent. Blog software doesn’t easily let you do this. I know WordPress stores revisions, but there doesn’t seem to be an easy, upfront way to see diffs of different versions against each other. I suppose a wiki could be better as an essay platform. Dokuwiki has excellent visual diff function and Writeboard also lets you compare versions.

Perhaps we do need some sort of specialized software for writing essays. Something that puts drafting editing at the center as opposed to at the edges. Personally I’ve been using Emacs with Git to get some of the same result, but I would really like to see a webapp that can do something like that. After all, there isn’t much use in writing an essay if no one is going to read it (and how better to get people to read it than to put it out on the Internet).

I, Essayist

Even though there may be no quick-and-easy publishing solution like WordPress for essays, writing an essay is far less dependent on tech tools than most other things today. Like I said before, Emacs and Git do a fairly good job together. I would like to be able to put all my drafts online with some sort of commenting system so that people can see the evolution of my essays, but I’ll settle for just being able to show a final product.

Separate from showing the essay is the mental exercise of actually sitting down and writing the essay (and then revising and editing). That’s something that I’ll have to get back into the habit of doing and will probably take time. Subject matter is also an issue, but a good starting point would be to simply expand on the themes that I cover in this blog, while making sure that people who read my blog can read my essays without getting bored (and vice versa). Expect my first essay to be on essays, sometime in the next few weeks.

Lindenmayer systems or L-systems are pretty awesome. You start with a string of symbols and a bunch of rules describing how those symbols transform into other symbols. And then you just keep reapplying those rules over and over. L-systems can easily generate a wide variety of interesting forms and patterns including many plant morphologies.

Two years ago I made a  implementation of L-systems in Python using the Python Image Manipulation library. But one of the goals of that project was to create a tool that non-programmers can use. It was an interesting experiment, but after a few months I was no longer sure if it was a good idea to create a “non-programming” interface to something that is so computationally powerful. This time around I’ve eschewed the whole “pretty interface” idea in favor of dealing with real code.

I chose to use Processing so that I could work a few steps removed from nitty-gritty image manipulation. Processing is based on Java, so I can use Java with all it’s libraries if I need to (and to some extent, I did). I would have preferred it if I could have Python underneath, but I’m not complaining too much. There is also a version of Processing running on Scala and there is a port in the works to JavaScript and Canvas which I’m interested in. It might be an interesting future project to port it to Jython.

How it works

L-systems in general work by generating a string of symbols that work as driving instruction to a LOGO-style turtle (think of it as a pen you can move with simple instructions like “forward”, “left”, “backward” etc.). The lowermost layer is a simple turtle implementation that takes a bunch of movement commands and draws them to a screen (or canvas).

On top of that is a class that represents Lindenmayer systems in general. A class stores the symbols, rules and the mappings from symbols to turtle instructions. It also implements the basic rewriting algorithm and allows to provide an external turtle object (in case you want to process the image outside of the actual L-system). It also takes the generating string of symbols and passes it to the turtle to draw.

The top of the stack is functional Processing code where you have a setup() function that sets up the image canvas and initializes the L-System object. The draw() function executes repeatedly and controls how many generations the L-system goes through. Each L-system is two functions: a setup function that creates the L-system object with symbols and rules and another function that gets called on every draw(). This allows you to do extra processing before or after the L-system’s actual generation.

Go Get It

I’m calling the resulting system Lisip: LIndenmayer Systems In Processing. It’s released under a GNU GPL and is available right now on Github. There are just three source files (the Turtle, the L-System class and the Processing code driver which includes a number of L-systems). I think the code is fairly self-explanatory (thanks to a large extent to how much Processing cleans up the usual Java syntax). I do plan to add some proper documentation within the week.

I’ll continue to add L-systems to it and probably add to the Turtle’s functionality in the weeks to come. Feel free to fork it and add your systems, but I’d appreciate it if you dropped me a line if you do fork it.

Happy Hacking.

Unlink Your Feeds – A Manifesto is a passionate appeal for not diverting all your social information to everywhere else. It makes a good case for keeping individual social networks separate. I suggest you follow the links at the end of the post too.

Media:

Unlearn Your MBA by David Heinemeier Hansson is something that you really need to listen to if you want to start your own company any time soon. DHH is quickly becoming one my heroes, both in terms of business and software and if I start a software business, I’m definitely going to taking a few pages out of his books.

Software:

FreeMind is a free, cross platform mind-mapping tool. Mind mapping is a great way to brainstorm new ideas. Though I love plain text as much as the next guy, the visual impact of mind mapping can be helpful. I’ve only just started using at the recommendation of a professor and will probably have an article on it sometime.

What led me to flesh out this idea was Martin Fowler’s observation that the three most popular version control systems: Subversion, Git and Mercurial are all completely open source. With just a little bit of thought, I realized that there’s a company that does exactly what I propose: Apple. Apple’s dev tools like XCode and the Objective-C compilers and libraries are open source are free for everyone to download and use. The core of OS X is the open source Darwin kernel. But layered on top of this is a closed and really high quality system of interfaces and applications that make for a very appealing user experience.

First let me say that what I’m about to say isn’t a commentary on the pay-for-support model that Red Hat and Canonical use. I think that’s a perfectly legitimate model that has it’s advantages for consumers, companies and open source hackers. But I want to propose an alternative that focuses on making money from selling the software itself.

Opening Doors

Why does this make sense? Leaving aside any moral imperatives, one of the biggest reasons for open source is that you can tinker and fix things that are broken. If you see something that is not right, you can easily pop open the hood and dig around in the internals. Now, the only way that you’ll know if something is broken is if you either use it yourself or have someone tell you that it’s broken. However, in my experience it’s much easier to fix something when you see it broken for yourself. It also gives you a better idea of what the fix should be like. It’s also more likely that you’ll change a program for the better if you’re using it day in and day out. Eating your own dog food has its advantages. If you’re a programmer, you’re most likely to find bugs and missing features in tools that you use every day. So it makes sense for you as a developer to use open source tools so that there’s an easy way for you to fix or change things that in turn will help your own developer experience.

If you’re a corporation (or organization) like Apple or Microsoft then it makes sense to open source your developer tools as well. For a corporation, the benefit to open sourcing a product is that you get feedback both in terms of ideas, comments and bug reports and also in terms of real working code. What you end up with is a positive feedback loop: you make tools and release them to developers for free who then help you make even better tools. I love the lesson that 37signals has taught the world in terms of tools and basic infrastructure: Ruby on Rails is part of their basic infrastructure, but they’ve decided to open source. As DHH claims, it’s hard to make money off of basic infrastructure (unless maybe if you’re Microsoft with a huge already installed base). Better to release it into the world and benefit from the improvements that other people make to it.

Making Money

So that’s all nice and dandy for developers, but what about the poor corporation that wants to make a decent buck? The basic idea is that the number of people who aren’t developers far outweighs the number of people who are. Also the number of people who just want something that works far outweighs the number of people who want something that they can tinker with ad infinitum. Even most of us hacker types occasionally break down and just want something that we can shut off our brains and use (for me it’s Excel in my engineering labs and Photoshop for image manipulation). People will pay for convenience, quality and polish. That should be the motivating factor behind businesses who want to sell software.

To make money from selling software you first need to hire good developers and give them good tools that they customize to their needs. Fortunately, you already have great free dev tools. Now pay these people well and give them a concrete goal so that they put real polish into the products, especially in the areas that open source hackers might tend to neglect. Since you’re going to be charging money, you can afford to put some money into hiring professional designers and UI experts and make sure that your app really looks good as well as works good (something that is still sorely lacking in a lot of open source software). Of course you need other people on team too: at least a fair number of testers who are the same people who will be using your for-pay product day in, day out. You end up with a product that has been crafted by motivated developers using great tools with feedback from your target user base. Admittedly you can still end up with a crappy product that no one wants to pay for, but that doesn’t mean the idea itself doesn’t work.

Though I have no real experience making products like that, the cases in front of us are pretty clear to see. Apple and Adobe both make lots of money selling high quality consumer software and I personally consider Microsoft Office to still be a better user experience that OpenOffice.org (especially with the ribbon interface).

One of the questions I haven’t fully resolved is whether your for-pay app should be open sourced. I am tempted to say no because I can’t think of a business model where you can open source your product (code and design elements) and still expect people to pay a decent price for it. If someone with more experience than me can come up with a working model, do let me know. However, one compromise that might be fair is to open up your app a few years later once your company has a newer product. Under this model, Apple would open source all their code prior to OS X. I’m less familiar with Adobe, but I think prior to the Creative Studio editions would be a good time point. Microsoft might consider releasing the pre-NT Windows code and maybe Office prior to 2000 or 2003. That way, your business still makes money today while making a community contribution in the future. It also helps users who can get their hands on a copy of a program if they need to open a file from 10 years ago that the current version no longer supports. It frees up the company to go ahead while worrying a little less about backward compatibility. It also keeps companies on their toes because they know that any market advantage they have will be effectively erased in a few years.

The Plan Isn’t Perfect

No plan survives contact with the enemy

– General Field Marshall Helmuth von Moltke

And this plan will definitely have to be modified if and when a company adopts it. One immediate problem I can see is that inevitably there will be calls to open source all the company’s product. I don’t have a suitable response to that apart from saying that would probably cause the business plan to collapse. Also if your product’s core algorithms don’t vary much from one generation to the next, open sourcing older versions might be equivalent to shooting yourself in the foot (though if you’re expecting a handful of algorithms to bankroll your company till the heat death of the Universe, you’re probably doing it wrong).

Again, I don’t have any real world business experience (though I would like to, someday). I also don’t know any company that has a policy like this at its core. If you’re interested in starting a company like this (or know of one already), do drop me a line. I’d really like to play a part in making a world where people can get paid for writing their code and then releasing it for other people to use and improve. A business that makes money but still open sources its code (even if its a few years late) would be a great step in that direction.

All I did last night was recreate an project I’d done a few semesters ago with Lindenmeyer Systems. In some respects, our previous work was a bit misdirected and we should have been building on top of Processing all along. Last night I was reminded firsthand of the importance of using good tools suited for the task at hand. I didn’t write much in terms of code, but I did manage to build up a fair bit of functionality (a much better measure of progress I think). But it’s still not done and I suspect at least an hour or two more of steady work before I get to something that I can show off. This morning as I was trawling in the interwebs I came across this essay written by my creative writing professor and her quotation of “Ars longa, vita brevis” rang out as so true. The art is long and life is so short.

I’m not really an artist, though I like pretty things. I’m a hacker at heart. More important than the actual beauty of the object is the joy I feel in actually creating it. As  a coder, I guess I’m half decent by now. I’d call myself a really really advanced beginner (close to intermediate). But in terms of art, I’m pretty much a greenhorn. What’s more, the art that I’m doing is in code. I thought that would be fun and easy. It’s not easy and it remains to be seen if it’s fun. Though I love writing code and can concentrate better on writing code than on anything else, when it comes to art, I’m a bit lost. It’s been a while since I’ve done any drawing or painting, I prefer using my words to create images in people’s heads. Also without the use of hands and real physical paints and paper, it’s a bit harder to play around. Admittedly, it’s easier to tinker, redo and recreate with computerized tools but there is more of an upfront investment and the learning curve is significantly steeper (at least in the beginning).

In some ways, you could say that I’m painting entirely with mind. It’s liberating: I don’t have to worry about drawing a perfect circle or making sure that the sides of my squares are all the same length, the machine does it for me and I can work at a higher level. At the same time, I can’t just splash some paint on campus and see what it looks like. I have to look up an API reference instead of stroking away extra paint with a brush and I sometimes I have to get my hands dirty debugging (including dealing with Java’s broken type systems). If real artists did this all the time, we’d never progress beyond stick figures. That’s not to denigrate Processing, the people behind it or computational art. The gains in productivity and expression we get from tools like them far away my pain. Don’t mind me. I’m just bitching.

The art is long and life is short. It takes some 10,000 hours to become an expert in anything and it takes continued practice to keep up that level of expertise. And life is short. Sometimes I wish that I could sever all human contact and just sit and write code (or stories or whatever) and the next moment I realize that it’s stupid because it’s meaningless to live completely in isolation. There’s no point in my writing code or making art if no one uses and appreciates what I create. It’s rather ironic that it takes antisocial devotion to a task to create something that others can appreciate. If only our brains could really multitask, things would be so much easier.

Well, that’s enough bitching and moaning for one day. I’m going to get back to my code/art.

What we wanted was a solution that was quick and easy to set up, was resource-light and could be hosted locally. We thought about larger wiki systems like MediaWiki but we settled on DokuWiki. First off, it’s flat files: no database or SQL required. It makes a point of being lightweight, so there’s no WYSIWYG. Instead there’s a simple wiki syntax instead that suits us hacker types just fine. Looking at the configuration page you can easily tell that it’s focused on functionality rather than looking pretty. But that doesn’t mean that it short on features or good design. It tracks revisions (with short commit messages as well) and has a really nice visual diff tool. Using Git for the better part of a year has made me really love good diff tools.

The wiki syntax is also well thought out. There’s little redundancy but strong features. And CamelCase is optional. Links are enclosed in double square brackets in the form of [[url|link text]] and you can make new pages just by putting in an empty link. It supports multiple level of headings and generates an automatic table of contents for any page with more than 3 headings. Though the design is simple and minimal, it does look pretty good. It’s clean and standardized so you won’t get lost and the edit controls are neatly tucked into bars at the top and bottom. It looks more polished than a default MediaWiki setup, for example. It’s easy to tell that DokuWiki is meant to be a clear documentation tool as opposed to another “build my website quickly” software and in our case, that’s a good thing.

And did I mention the sourcecode support? It uses the GeSHI syntax highlighter, meaning that it supports a wide variety of languages (including some fairly obscure ones like Lotus Formulas and LocoBasic). You can also turn snippets of code into downloadable files by just specifying a filename. You can tell that this was a tool made for hackers by hackers. And of course I just love it. Uploading images is easy, but if you want to add files with other extensions, you need to edit a config file which shouldn’t be a problem for most people who’ll be using this sort of software.

There are a number of other goodies in the bag that I haven’t had time or cause to investigate (including plugins). The fact that I’m not administrating the installation means that I won’t be playing around with it as much as I could, but I think I can turn it into a user point-of-view experience. I wish there was some easy theming support, but I can live without it. This is the first time that I’ve used a self-hosted wiki and though I’ve had experience with other wikis in the past (I like PBWorks) I think I’ll definitely turn to DokuWiki if I need a simple but strong wiki for a code-focused project in the future. I might consider hosting it on my personal server in the near future too and get some more chance to play with it. Right now I’m perfectly willing to keep it simple and focus on my real work (more on that later too).

I hopped on the C channel at Freenode and within minutes I had not only found out why program was misbehaving, but I also got two separate suggestions on how to fix it. I may have bent the rules a little bit, but I trust my professor will understand that I actually did learn something and not just steal code of the Internet. I still don’t really know how to implement one of the suggested fixes, but I implemented the other. The fix I didn’t understand is probably the cleaner of the too and I plan on asking my professor more about it.

I repeated the experience yesterday, but with JavaScript and the canvas element (while trying to use Processing.js). I did IRC in the past, but never really to solve problems. I went on channels (mostly #archlinux and #python on Freenode) mainly to interact with the community. Whenever I had problems, I generally googled my way to a solution. In some ways, asking on IRC could be considered the easier path: instead of searching for material, you simply go ask someone who knows. While that may be true to some extent, it’s certainly not what happens all the time. When asking the C question, the other channel members made it perfectly clear to me that I needed to go read more (which I totally agree with). They also helpfully pointed me to resources. IRC channels aren’t “cheatsheets” by any stretch of the imagination. I got the feeling, on both the C and Processing.js channels, that the people on them are very well-versed in what they do. They’re willing to help you, but only if you help yourself (some make this point more forcefully than others).

IRC is a good example of a way to learn Computer science (or at least programming) in a master-apprentice fashion. It’s different from learning from a tutorial or reading the man page. I hesitate to call it “teaching” because it’s more of a free form Q&A. Instead of having someone give you the information up front (a typical classroom setting) or going out and hunting it down yourself, you get to pick the brains of people who have already internalized the knowledge that you’re after. To get to it, you have to ask the right questions and that means knowing the problem well enough to figure out what questions are worth asking. And that requires some thought.

It’s not exactly master-apprentice because you aren’t learning under the tutelage of a single master. I think a more apt analogy would be spending some time at a monastery. You don’t have a very strong connection to the people there, but you share some things in common. You can go with a purpose or without one. But you will benefit more if you do have one. There are some basic rules, mostly concerning respect and etiquette. If you break them, you will be asked to leave and in extreme circumstances, removed. The experience you have is very much up to you and could leave with a profound sense of enlightenment and a strong desire to return and learn some more.

Ok, so I’m embellishing a bit and programmers aren’t really monks (except maybe if you’re Richard Stallman). IRC certainly isn’t solution to all questions and you could easily come away being more confused than when you started, but that could happen with a book or a normal class. IRC is another resource, but it’s a good one. No matter how good search technology may be or how well-written technical docs may be, sometimes it’s good to be able to be walked through problems by a human being. And yes, I do still have questions for my professor.

Anybody who tells me I can’t use a program because it’s not open source, go suck on rms. I’m not interested. 99% of that I run tends to be open source, but that’s my choice, dammit.

I got my shiny new iPod Touch yesterday and even though I really like it for a number of different reasons, I can’t help but feeling a little bit guilty. I like Apple in general, but the iPod is pretty much as closed as a system gets and I don’t feel too good about giving my hard money to something that is rather opposite to what I think computing should be like.

Though I can’t shake off the feelings of guilt (and am concerned by the direction in which popular computing is going), I let practicality take the upper hand in this case. The reason I bought the iPod Touch is that there is no other device on the market that lets me do just what I want to with the Touch. I needed a light, mobile internet connection device that could connect via Wi-fi and fit in my pocket. Also, I didn’t want to spend a small fortune (for a college student). I didn’t want a phone with a plan (I hate phones) and I didn’t want to shell out $500+ for an unlocked Nexus One.

What I needed was basically a web-ready PDA for the modern day and the iPod Touch pretty much fits the bill. The calendar and mail apps work wonderfully with Google services and there are some good to-do list apps available cheap. If there was an Android equivalent to it (say the Motorola Droid without the phone part) I would buy it instead in a heartbeat. But there isn’t and I need something that gets the job done today.

Though I am very much an open source advocate, I’m not fanatical about it. I use OS X on a regular basis because I think it looks good and the UNIX underneath lets me do most things I need it to do (except perhaps package management, but I haven’t really tried that). On the other hand, I went completely Microsoft-free last week. I stopped using proprietary formats long ago, preferring plain text, HTML and PDF. But I nuked my Windows partition simply because I didn’t use it any more. I was back up and running with a beautiful fresh, 64 bit Arch Linux install in about an hour.

Having a philosophy and values and ideals is awesome, but in the end I choose technology that serves me best. If that means I have to spend a few dollars lining a closed giant’s coffers, then so be it. The reason I grew to love Linux was because it was so easy to tinker with and because I could write programs very easily. I never quite figured out how to write serious code in Windows and I’ve never been a big IDE guy. If Windows had let me program and tinker as easily, I would have probably stuck to Windows. Some would argue that Windows will never be that way because of its closed nature. I’m not sure I agree, but then again, I can’t say I’ve tinkered enough with proprietary systems to tell what can and cannot be done.

And of course no conversation on openness today can be complete without some mention of the iPad. I think it’s an interesting piece of tech, but it’s not something I will buy because I don’t have a plausible use case for it. I either want something I can carry in my pocket (the iPod Touch or iPhone) or I want a full fledged computer. However, I also understand that I’m not the iPad’s target audience. The target audience is people who don’t do a lot of typing and are more digital consumers than they are proper computer users. And though the iPad may be unimpressive from a technical perspective, it will almost certainly sell like hot cakes (as my friend puts it). And no doubt Google will push out an Android-based competitor to it within the year.

Part of my misgivings about buying the Touch has to do with the fact that at heart, I am a tinkerer. I like cracking things open to see what the parts do and then putting the parts back in a slightly different just to see what will happen. Seeing a mass market popular device that is so tinkerer unfriendly does unsettle me. But there are also things that I have no interest in tinkering with. I don’t want to jailbreak my Touch or run my own “unauthorized” programs on it, because there are far better things for me to do with my time. Computer technology is at the point of maturity where you don’t have to tinker to get things to work the way you work and I think that in general is a good thing. I care more about users having a good experience and getting their job done than I do about running a completely free software stack. If that means I need to throw a little proprietary into the mix, so be it.

Linus Torvalds does sum it up really well for those open source users who aren’t primarily motivated by morals or ideals: most of what we run is open source because it works and gets the job done. And most importantly, it’s my choice.