Saying that everything should be public is certainly an idea that takes getting used to. It’s like saying that you should publish the details of your drunken escapades on your blog. It’s unsettling, but then again, the pictures are probably already on Facebook anyway. I think there are two issues here — one is for fields, and the other is for methods.

Though Steve seems to say that fields should be public (or have getters and setters on them), I personally tend to go the other way: fields should be private by default and only accessible through getters and setters. I like the way Ruby does it — everything is private by default but the accessors are generated by metaprogramming, so you don’t have the junk lines of getWhatever and setWhatever that you do with Java. Direct field accesses like Java and C++ allow are just bad ideas.

For methods things are the other way around. Firstly, I don’t like the idea of invoking methods on an object. I far prefer the Smalltalk notion of sending messages to objects and having them respond. I think it’s a far better conceptual model than methods and the private/public debate goes away in that model. If your object responds to methods, then being able to use private and public means that the object knows of and cares about where about the message is coming from. However, this breaks encapsulation. Ideally an object should respond to a particular message the same way irrespective of where the message comes from.

But, you say, what of the real world where ideals don’t necessarily hold? Hmm… let’s see what happens to software development under the assumption that all your methods and functions are callable from outside. To start off, you have to be careful about what parameters your methods take. You can’t assume that they’ve been pre-sanitized which means that either you’ll have to check them yourself or fail cleanly (and maybe send a stern warning up the chain). This may be a bit annoying, but I’d say it’s on the same level as dynamic typing — you’re never 100% sure of what type the arguments are so you take appropriate measures.

Now let’s talk about safety. One of the arguments in favor of private is that you don’t want methods to be abused and put the object in an unusable state. Again, I don’t think this is as big of a problem as it’s made up to be. It just involves rearranging where checking occurs. Presumably, if you have a private method that makes delicate changes to your object, you have a public method somewhere else that approves the changes and then calls said private method. Why not put the approval inside the private method and dispense with the public method entirely? If you want to make a change to an object, call a method to do it. If it works, fine. If not you get an error back.

I should make it clear at this point, that I don’t have any real world example to back up my claim (at least no examples that aren’t hopelessly contrived). What I’m talking is refactoring to meet a design constraint — that of total publicness. People will kick and scream and say that it breaks their careful separation of functionality into methods, but I think it’s just a design pattern, like dependency injection for example. And the trade-off to that is probably more flexible, more powerful software systems.

If everything is public (and designed from the ground up to be public) you start writing code that’s meant to be used by other code. Which in turn makes it easier to use and extend your code. I think you’ll eventually end up with something like Emacs — lots of public functions that do useful things to an object (the text in the editor) and an awesome array of functionality made possible by using these public functions. There is a fundamental change in programming and building ideology that needs to take place. With full publicness you can’t have a nicely bureaucratic language like Java. You’re going to end up with something that’s far more open and flexible like Ruby, Python or *shudder* Lisp.

I think that a lot of the heightened discussion surrounding Steve’s suggestion stems from the nature of the Java language. It’s certainly meant to be used by large corporate teams and is designed to stop programmers from hurting themselves (or stepping onto someone else’s turf). “Bureaucratic” is perhaps the best way to describe the language. If you take out private from a language like that, you lose most of its raison d’etre. So is private a good thing? Probably not. Does it need to stay in Java? Probably.

I’d like to reiterate that I think that message-passing is a superior way to think about object-orientation and it makes the public/private debate unnecessary. That’s why the language I’m building for my thesis will have message-passing. I’m also stealing Ruby’s private-by-default and metaprogramming for accessors.

Powerful Python was a series of posts about the Python programming languages and how its features make it easier for programmers to write code. As it stands now there are four posts in this series:

• A guide to Python namespaces
• Switch-case statement in Python
• Python properties vs Java Access Specifiers
• Switch-case statement in Python revisited

Python is the language that I’m most familiar with and have written the most code in. Over the last month or so I’ve been writing Python day in day out and really exercising my Python chops (as well as getting acquainted with features like generators and decorators).  Over the next few weeks I’m going to be writing more posts exploring Python and adding them to the Powerful Python series. If you regularly write code in Python or just have a passing interest, this is something you’re going to like.

The second series that I had was Sunday Selections. I try to post two to three times a week, but I didn’t want to leave the weekends completely bare. I also wanted to spend my weekends doing other things (preferably away from the computer). So I started a series where every Sunday I would post links (with brief intros) to interesting things that I had found the week before. I’ll admit that I haven’t been very stable with the post schedule, partly because I kept forgetting or losing what I had found and really didn’t want to go hunting around the intertubes for whatever it is that I liked.

Over the past few months I’ve become much better at holding onto things I find online. Using Diigo for bookmarks and Tumblr for “scrapbooking” the web I’ve been managing to keep a good record of all the wonderful stuff I’ve found (and there is a lot of it). So I’m bringing back Sunday Selections as well (starting this Sunday) so stay tuned for a steady flow of Internet-y goodness.

I’m really looking forward to writing series posts again. I feel like my writing can sometimes get either monotonous or spread all over the place without any focus. I’m hoping that the series (especially the Powerful Python series) will provide a good path for me to write articles that are coherent and progress along a definite line. Stay tuned.

Without dropping any spoilers here’s what you need to know about the movie for the rest of the article: it’s about people who go into other people’s dreams in order to steal their secrets. Pretty simple, right? The kicker is that it’s possible to dream inside another dream leading to all sorts of interesting situations and plot twists. Ok, so that’s not quite recursion since that would mean that the subject would be dreaming the same dream inside the dream (confused yet?). Come to think of it the dreams of Inception are more like closures.

So what are closures? Wikipedia tells us that:

In computer science, a closure is a first-class function with free variables that are bound in the lexical environment.

Perfectly understandable, right? No? Ok let’s translate. First and foremost, a closure is a function. But it’s not just any old run-of-the-mill function. A closure generally contains variables that are neither local variables nor arguments to that function. So what do those variables refer to? Their values come from outside the function, specifically the code block that surrounds the function. The wikipedia page on closures gives examples in a number of languages. Though closures aren’t necessarily a part of a standard curriculum they are extremely powerful constructs that can be used to implement a host of other programming language features (including control flow structures and object systems). Coming back to Inception, once you are inside a dream you can recall the world outside (though the real world seems like a dream so everything’s a bit fuzzy).

Closures in computer science (and dreams in Inception) are important because they are a prime example of abstraction. Functions are a powerful concept because they essentially let you create little worlds in which you can do stuff. You put something in a function and get something out. You don’t need to know or care about what’s going on inside the function (unless something goes wrong, but that’s a different matter entirely). Functions let you abstract away processes. Closures improve upon functions and let you abstract state. If you’re using a function that’s a closure, you don’t need to know about what it’s variables are bound to (except the ones you pass in) and you can’t see what data the closure can manipulate either.

By tucking away state, closures give us less to hold in our minds and make it easier to write code that’s clean and follows the Single Responsibility Principle (essentially, do one thing and do it well). Suppose you have a bunch of closures inside one larger function. Now magically you have sections of executable code that all operates on the same data and yet can do completely different things. They can also do all this without having to passing in a host of arguments every time (which reduces the chance for making mistakes). Whenever the closures need something, they just refer to their outer environment. Sound familiar? It should because I just described objects and methods. And that is the hallmark of a good abstraction — it lets you build up other abstractions on top.

Abstractions are in general a good thing. But unless you think through your abstractions, they can be bad. A leaky abstraction is one that doesn’t quite get it right. The underlying layers somehow “leak through” what should be the abstraction’s water tight boundaries. Joel Spolsky has a very good article on leaky abstraction that’s a must read if you want to learn more. And while we’re on the topic of abstraction — too much can be a bad thing. I wrote a Python program two summers ago to experiment with L-systems. Last summer I tried rewriting it such that everything in the system was the instance of some class. Everything was supposed to go through methods and abstraction boundaries. I never finished. This summer I toned it down a little and got a working version in about a week. Yes, this is classic second system effect, but it also shows that sometimes abstractions will just get in the way and force you to jump through hoops.

In conclusion: abstractions are good if used wisely. Closures are one such powerful abstraction. Dream safe.

The question is, what? My suitemate has a projector and we have 3 couches in our lounge (don’t ask) so yesterday evening we had an impromptu movie party, watching Hangover and eating homemade popcorn. Said suitemate also has a bunch of lights hooked up to a dimmer switch and 5.1 surround sound. So while we were waiting for the projector to warm up a friend of ours decided to play the DJ and plugged his Macbook into the sound system. And while the music was playing yet another tried running switch to the tune of the music. Of course he was much too slow to keep pace but it gave me the idea of trying to set up some electronics so that the dimmer switch (and hence the lights in the room) would modulate along with the music.

The next question is: how? And that’s not something that I’ve quite figured out yet. I’d like to use the Arduino, since I’ve heard good things about it and I know people on campus who have some experience with it. And since I want to some audio sampling and processing I’d like something with a decent amount of processsing power. I have no experience with the Arduino at all but one of the people that I’m working with over summer does (he’s the one who started playing wiht the dimmer in the first place). I’m starting my trawling around the Arduino website and looking over the specs and getting used to the programming environment for it. I technically have all summer to play around with it, but I would like to have a working prototype ready in two weeks (in time for my birthday). I’m open to suggestions, tips and tricks so if there any Arduino wizards reading this, feel free to drop me a line.

The problem with being a undergraduate researcher is that I don’t have enough experience to know how big of a project is a good size. Again, I don’t want to think too much about this and end up limiting myself from what I can achieve. So how should I choose my project? First, I want to get my priorities straight. I’d rather do something that’s ambitious and end up with something that’s a litte incomplete than do something I can neatly finish, but is mundane and unexciting. That being said, I don’t want to do something that I have no chance of finishing. I’m not looking to prove or disprove P = NP (and I’m not a theory guy anyway) but I don’t want to write yet another Python/Ruby/Java clone.

I remember reading Paul Graham’s essay on procrastination a while ago. What stuck out to me most was his summary of Richard Hamming’s essay on research. One of the core themes on that essay is asking yourself three basic questions:

1. What are the important problems in your field?
2. Are you working on one of them?
3. Why not?

Hamming was talking to professional scientists and researchers and I’m just a wee young undergraduate working on an honors thesis, but it’s never too early to get started. So, in keeping with Hamming’s excellent advice, what are the important problems in computer science? Now that’s a tricky one. Of course, there are the classic ones. Prove or disprove P = NP, build true AI, build a working quantum computer etc. etc. Then there are the ones with been-there done-that written all over them. For example, the current software stack is a bit of a mess so let’s build a unified top-to-bottom hardware-software solution all in Lisp (along with a YouTube viewer).

But seriously, what’s a real, current problem that I can take a chunk of and have a hope of solving? For starters, there’s parallel computation. Engineers are piling the core on with no sign of stopping and we have absolutely no idea what to do with all of them. Most of our software is still inherently single threaded and keeping up with concurrency with all the ills of shared memory are a pain to keep up with. New programming languages and innovations like software transactional memory are doing a valiant effort, but they still aren’t tools that you can ship off to everday programmers and have them cranking out parallel code. I’ve been studying parallel code (mostly in terms of GPUs) for last semester and it’s definitely something I can get into. However parallel computing is still a wide area and I’d need to find something more specific. I’m working on a different sort of parallelization over the summer (MapReduce with Hadoop) so that’ll give me something more to think about.

I posted to the Arch Linux forum about just this issue and one of the replies that came up multiple times was network security. The internet is everywhere and a computer without a network computer in this age is pretty much useless. And when you connect your computer to dozens of other ones spread out all acrosss the world, there’s a good chance that one or more of them don’t want to play nice. With botnets, viruses, trojans, worms and the like being a daily reality security is important and no seems to have a solution that’s even remotely bulletproof. Unfortunately for me, security just doesn’t interest me that much. I’d rather be building interesting stuff than holding down the fort. So on to the next one.

I’m interested in the way that people interact with their machines, not really in the up-front, HCI sense, but in a more general sense. One problem that I find interesting is how we can manage all the data we have on our machines without having to explicitly name (and then remember the name of) each and every single piece. The filesystem metaphor does not scale to thousands of songs and images or to the many tiny bits of text and video that we’re continually sharing with each other. Unfortunately, none of the popular operating systems seem to be meeting this challenge head on (iLife is going in the right direction, but the ideas need to spread to the rest of the system). I’d love to come up with an implementation of a file-less, data centric user model, probably along the lines to what the Etoile project is trying to accomplish. This is certainly something that I’ll be thinking about more (and I need to come up with a more theoretical basis for an honors project).

There are probably a bunch of other things that could qualify for being among the most important problems in computer science and I could add another few thousand words to this post. But sufficeth to say that this is still something that I need to give a lot more thought to. I still have no idea what my thesis topic could be, but I know what I’ll be doing over summer. I’m not going to be solving the multicore crisis or building a completely new operating system from scratch, but I’m definitely going to be taking my best crack at it.

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.

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.

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.