Programming Languages Should be Simple

Programming languages should be simple, based on a small and flexible core. Why is simplicity important? A simple language is easier to learn than a complex one, and a simple language lends itself to a simple implementation, which is easy to modify.

Simple How?

What does it mean for a language to be simple? The way I judge the complexity of a language is by the number of special cases the programmer has to be aware of while using it.

A language such as C++ is definitely not simple. The sheer number of rules you have to know in order to fluently write C++ is astounding, especially where templates come into play. A loose specification, where implementation behaviour is undefined in many error cases, means there are many traps you have to know to avoid, since they can be difficult to find your way out of after you fall into them (see some examples of problems you can run into when dealing with the linker). The slow but incessant growth of features over the years coupled with an obsession for backwards compatibility leads to a monster of a language.

A language like Scheme is comparatively simple. It has a very homogeneous syntax: almost everything is a function call. There are only a few built-in syntactic constructs (things like conditionals and definitions), no keywords at all, and no operators to worry about.

Simplicity Makes Languages Easy to Learn

The most immediate advantage of having a small core language is that it’s easier to learn. If you can learn all of the language constructs and exceptions in half an hour, then you can turn your attention to what’s most important: understanding how you can use the language to write programs. It’s not that a simple programming language makes programming easy, it just prevents it from being artificially difficult. Programming is hard enough without the programming language providing its own obstacles. Programming should not be about memorization, it should be about problem solving.

Simplicity Makes Languages Easy to Modify

If the language is based around a simple core, it’s likely to be easier to implement. Besides saving the initial implementor some amount of work, a small implementation is easier to change. This allows experimentation with new features. It encourages people to make modified versions of the language, which will foster innovation and research. In the long run, that’s good for the future of Computer Science as a whole. For example, though Lisp is a minority language now, its influence is felt all over computing. Wikipedia lists over 15 different Lisp variants, and some of them, such as Common Lisp and Scheme, have more than a dozen implementations.

It’s not likely we’re going to come up with the perfect language anytime soon. By making languages simple, we can at least compromise by making it easy for others to correct the imperfections.

Posted on 2009-01-01 at 23:35. 1 comment -->

Timeboxing to Avoid Procrastination

As a follow-up to my new year’s resolution, I’ve decided on January’s trial: timeboxing.

Getting things done is often a problem for me. Not because I can’t work effectively, but because I don’t work effectively. I sit around with a vague idea that I should be working on things, then don’t actually work on them. Instead, I lazily read e-mail or RSS feeds, feeling sort of guilty about not doing what I should. Because of that guilt, I don’t even enjoy being lazy! It’s not that I don’t want to work on things, since once I start something I really get into it and get a lot done. What’s difficult is putting together the energy I need to make myself start working.

What’s lacking is direction. In a work environment, it’s easy to find direction. Since you’re working as part of a team on a larger project, there are always tasks waiting for you. Having other people working around you also provides direction. In university, though, there’s no one around to tell you what to do. You have to provide your own direction, whether it leads to schoolwork or to personal projects.

Timeboxing is a simple concept. Instead of setting achievement-based goals, you set time-based ones. For example, instead of deciding to reach a certain milestone for a school project, you set aside three hours and devote that time entirely to the project.

Timeboxing helps in two ways. First, it forces you to make conscious decisions about how you spend your time. If I want to read RSS feeds, then that’s okay. I’ll just set aside a half-hour and focus on exactly that. Since I’m making that decision consciously, I won’t feel bad about it. The second way it helps is by providing immediate direction. Even an hour devoted to reading RSS feeds or playing video-games is better spent than an hour wasted without a clear sense of direction.

The way I see it, if I can get myself to start working like this, I’ll have no problem getting what I need to done. So, my trial for January will be to time-box a minimum of 3 hours each day, for whatever tasks I choose. It doesn’t have to be 3 hours at once, or all for the same purpose, but the total should be at least 3 hours. Not all of that time has to be school-related, but I’m confident that since I’ll be conciously deciding how to spend my time, work isn’t going to be neglected in favour of leisure.

Posted on 2009-01-01 at 22:54. 4 comments -->

New Year’s Resolution 2009

It’s a bit early to post a new year’s resolution (I think it has to be new years eve >_>), but this one takes a bit of preparation.

In every month of 2009, I’ll run a 30-day trial. Not the shareware kind, the personal development kind. Every month, I’ll make a commitment to do something differently, just for that month (this means that February will actually be a 28-day trial, but oh well).

Having a different goal each month gives the resolution flexibility. If I pick a goal which is too easy, then I can pick a more challenging one the next month. On the other hand, if I pick one which is too hard, well, after 30 days it’s done, and I can move on to something else. 30 days is long enough to form a new habit, but it’s short enough that I’m not stuck with the goal if it doesn’t really work out.

This resolution also has the advantage that I’ll get a variety of experiences from it. Twelve months means twelve experiments with forming habits. Even if only half of them turn out a success, it’ll make a huge difference.

So what’s the preparation? I still have to finish figuring out what do to with the first month XD. I’ll be back later with January’s trial.

Posted on 2008-12-31 at 00:11. Leave a comment -->

favicons

Favicons (the little icons that appear next to the address bar) are small, but when you put many together they become a formidable entity! This project takes search queries (which are actually delicious tags) and finds related favicons, displaying them on the grid. Clicking on an icon spreads a related icon to a surrounding cell.

What did I learn? Doing dozens of page fetches to arbitrary sites in response to a user query makes for a very sluggish UI. . .

Posted on 2008-11-29 at 14:42. Leave a comment -->

at.stream

at.stream sends fragments of twitter conversations at you, can you figure out what’s being said? This one’s a project done a few weeks ago by Jonathan Lebensold and me, he’s responsible for the front-end (JavaScript with JQuery), me the back-end (PHP with SQLite).

Posted on 2008-11-28 at 02:51. Leave a comment -->