Archive

Archive for September, 2010

Something I just learned about Emacs part 1: deleting whitespace

September 29th, 2010 No comments

I’m very much a trainee Emacs user at the moment. I’ve been using it for about a year, and I’m much faster in it than in any other editor, but I’ve still got so much more to learn.

I’m planning to document these new things as I learn them in the hope that (a) writing it down will help me remember, (b) if (a) fails then at least I’ve got this as a references, and (c) maybe someone else is at a similar level of Emacs mastery to me, and they’ll learn something new with me.

delete-indentation

Let’s say you’ve got the following code:

function myAwesomeFunction(argumentOne,
                           argumentTwo,
                           argumentThree)

and you decide that it’s really not necessary having all those arguments on their own line – you want them all on the same line. My old technique would be to set the mark at the end of the first line with C-<SPC>, move down a line with C-n, back a word with M-b, kill the region with C-w, and insert the space with <SPC>.

The new technique uses delete-indentation, mapped to M-^. Just go anywhere in the last of the three lines, and press M-^ to remove all space between argumentTwo, and argumentThree) except for one space. Then press M-^ again to bring the line argumentTwo, argumentThree) up to the end of the previous line. Awesome!

The old technique takes 11 commands to process those three lines (assuming point is at the end of the first line). The new technique takes just 2 commands (assuming point is somewhere in the third line). That’s a 5.5x increase in productivity! Hell yeah.

just-one-space

Just one Cornetto,
give it to me,
delicious ice-cream, of Italy,
vanilla and choco dream,
Give me Cornetto,
from Wall’s ice cream.

Sorry about that. So, you’ve got the following annoying string:

"My string has a long      string of spaces in the middle"

If only there was some way of deleting all those spaces in the middle… My old technique was this: starting with point on the first space, C-<SPC> to set the mark, M-f to the end of string, M-b to the beginning of string, C-w to delete the spaces and then <SPC> to insert the missing space.

Here’s the new-and-improved-with-added-awesome technique: with point anywhere in the spaces, press M-<SPC> (just-one-space). That’s it. 5 commands down to 1. A 5x productivity increase. OOooh yeah.

delete-horizontal-space

just-one-space has a brother called delete-horizontal-space, mapped to M-\, which does exactly the same thing but removes all the spaces, leaving nothing but a trail of destruction in its path.

delete-blank-lines

One last one – it’s not as exciting as the others, but it could easily be the most useful. Imagine the following brilliant JavaScript code:

function awesome() {
    //do stuff
}






function great() {
    //do other stuff
}

The author of this code probably heard that whitespace was beneficial for readability, but they went too far. delete-blank-lines to the rescue! With point on any of those blank lines, press C-x C-o and all the blank lines go except for one. It’s flexible too. With point anywhere on the last line of awesome() (the }), press C-x C-o to delete all the blank lines.

There’s a cloud to every silver lining though: with this technique, I don’t get to go C-k C-k C-k C-k and shout “Kill Kill Kill Kill!” I think it’s worth the sacrifice though.

Further reading

GNU Emacs Manual – Deletion

Why McConnell was wrong: Idiomatic programming

September 14th, 2010 4 comments

This is a topic that’s been on my mind since I read Code Complete, Second Edition. I think in general, Steve McConnell is right on the mark in Code Complete, but there’s one point which I really disagree with him on: Programming into your language. It first comes up in section 4.3, and is reprised in section 34.4. He repeats the point throughout the book (if it had just been one instance I would have forgotten about it, but he hammers away at every opportunity).

So, what does McConnell mean by “programming into your language”? Referencing David Gries, he says:

Programmers who program “in” a language limit their thoughts to constructs that the language directly supports. … Programmers who program “into” a language first decide what thoughts they want to express, and then determine how to express those thoughts using the tools provided by their specific language.

He later says that you should not

limit your programming thinking only to the concepts that are supported automatically by your language.

I think this is dangerous thinking. To me, it’s very similar to the concept that you can write FORTRAN in any language. Just because you can write code in one language like you would in another language doesn’t mean that you should. I think it leads to the narrow-minded view of programming that there is one “right” way to do everything.

The example he gives is cleaning up Visual Basic code by enforcing a separation between presentation and business logic which the environment actively discourages. In this case, I think it’s great to try to enforce some order, if you know that your language is encouraging poor practices. But most languages (worth using) don’t generally encourage poor practices. There’s a difference between correcting your language where it has done something wrong, and shaping it because it does things differently. To illustrate this distinction, here’s a JavaScript example:

  • Something JavaScript got wrong: implied globals. If you assign to a variable without declaring it with var, it gets global scope. The fix: always declare variables with var before use. Use JSLint to enforce this.

  • Something JavaScript did differently to most other languages: prototypal inheritance. The fix: don’t fix it; it ain’t broke. Learn how to think prototypally and do it the JavaScript way.

Both of the above solutions are examples of idiomatic programming in JavaScript. There’s no need to work out in every language what it got right and what it got wrong – just follow the idioms.

Idiomatic programming

So, what is an idiom? This concise definition is from Christian Lescuyer on Stack Overflow:

A programming idiom is the usual way to code a task in a specific language.

Here is another perspective:

In English you say “I am hungry”. You can say the equivalent in French (je suis affamé), but people just don’t. It is a grammatically correct statement that is never used. It is not a French idiom. Instead in French you say “j’ai faim”, which means “I have hunger”, which in English is a grammatically correct phrase that nobody uses. “I have hunger” is not an English idiom. Writing English or French is not only a question of producing grammatically correct phrases, but also to apply correct usage and to use the correct idioms.

This is used to illustrate the point that although there are many ways to write “grammatically correct” C code, only some of them are idiomatic. Writing un-idiomatic C code is the equivalent of saying “I have hunger” in English.

Why use idioms?

Idioms are like the distilled wisdom that has accumulated in the community around every language. Different languages have varying degrees of accepted idiomatic usage. For example, it is generally considered poor form in C++ coding to use every available language feature, but which features to use are not agreed upon. In Python, there is a strong emphasis on writing “Pythonic” code. The Ruby community seems to believe strongly in “Best Practices“.

There is a reason why these idioms exist, and are so widespread – they make it easier to code in the language, and they make it easier for others to read your code. After all, as Martin Fowler wisely said, “any fool can write code that a computer can understand”. The one thing that readers of your code will have in common is knowledge of the idioms in the language it is written in (hopefully). Using the language’s idioms makes it easier for the readers to read it. Being familiar with the idioms makes it easier for you to read code written by others.

JavaScript is currently maturing as a “serious” language, and so is currently lacking in widely accepted idioms. Douglas Crockford makes a strong case for using prototypal inheritance in JavaScript; after all, this is the built-in inheritance mechanism. Others have tried to make JavaScript follow a class-based inheritance pattern. To me, this is an example of “programming into” the language, by making it work in the way one might expect, but not in the way it was designed. I hope the prototypal pattern will win out, but that remains to be seen.

Go with the flow

The important thing is to go with the flow. If a language and its community push you towards a particular practice, go with that. If the language pushes towards something but the community pushes towards something else, it’s likely that the community has spotted a deficiency in the language and is compensating for it.

Learn the idioms, and apply them. Don’t be afraid to try out idioms from other languages, but also accept that there’s likely a reason why they’re not idioms in your current language. Sometimes the only reason is because “that’s just not how it’s done round here”, but that’s a valid reason. Older versions of Rails used for post in @posts in generated views to iterate over lists of model objects. The newer versions use the more idiomatic @posts.each do |post|. Rubyists like blocks, and that’s enough of a reason to use the latter version.

So was McConnell wrong?

I think McConnell was wrong to make the blanket statement “program into your language, not in it”. I think what he really meant was to protect yourself from your language when it forces you to do bad things, but it doesn’t come across like this.

Further reading

Steve McConnell: Code Complete, Second Edition: Despite being wrong on two pages, the rest of this book is an excellent distillation of decades of computer science research and industry best practices.

Jon Skeet: Programming “in” a language vs programming “into” a language: Jon Skeet of Stack Overflow fame has already written on this subject – I came across his post while researching mine. I almost didn’t write this post after finding Jon’s, but I decided that although we agreed, we had very different perspectives.

Keyvan Nayyeri: Program into Your Language, Not in It: Nayyeri agrees with everything that McConnell says on the subject – I’ve included his post here for balance :)

Programming idioms: A good discussion on idioms, from a C perspective.

Categories: Programming Tags:

Finding your passion

September 9th, 2010 2 comments

Some time in the decade just gone I went to university to do Music and Sound Recording (Tonmeister). I chose this course because I loved to make music, and I loved technology. I also happened to be doing the right A levels (Maths, Physics and Music). The Tonmeister course was a great mix of music theory and practice, audio theory and recording practice. We recorded through a Neve V series desk onto 2 inch multi-track tape, as well as through a Sony OXF-R3 into ProTools. It was an audio geek’s dream.

But for the entire first year of the course, you weren’t allowed to play with the toys. The only way to get access was to assist a student in the second or final years (the third year was spent on placement). For the period of the recording session, you’d be their bitch. You’d set up mics, plug in cables, move amps about, go and get pizza – whatever was needed basically. Studio time was at a premium, so these sessions were often all-night affairs (with lectures at 9 the next morning).

I had a friend – let’s call him Chris – who did a lot of assisting in the first year. He’d hang out with the final years, and got first dibs on most of the assisting opportunities. He spent more time in the studios than most of the second or final years, and often knew more about the kit than the students he was assisting. If you needed help getting the lexicon reverb unit to output in stereo, you’d ask Chris. We were in the same halls of residence, so I’d often see him coming in early in the morning after an all-night session, or running back to his room to get his pop shield, or another SM57, or whatever.

When he wasn’t assisting, he was listening to music. He’d listen in great detail to recordings, electronic, rock and classical, and analyse the recording on his pro headphones. He’d listen to the compression, the EQ, the reverb. He listened for bad edits and nice mixes. Endlessly analysing, working out what he liked, and what he didn’t like. And when he wasn’t listening, he was reading. He’d read and read books and magazines about recording, mixing and mastering.

Then, when it came to the second year, suddenly he was able to record stuff himself. He didn’t have to put the mics in the wrong place where he was told to; he could put them in the perfect place where it would sound just right, where you’d get the perfect balance of snap and pow and bang. He spent as much time recording as he could. We only had a fixed amount of studio time per semester, so when he didn’t have his own session he’d assist other second years, or he’d just hang out in the studio.

For the placement year, only one place would do – Abbey Road. So he went there for the year, and worked all the hours they threw at him. Then came the final year, and again, he spent all his free time recording. He ended up getting a first-class degree, and then went back to Abbey Road. These days I open up Sigur Rós albums and see his name on the inside.

The passion

Chris had the passion for recording, and audio. I didn’t. I enjoyed the course, I loved recording, had great fun in the studios. But I wasn’t passionate. I didn’t spend my spare time reading about it and listening to music. I didn’t spend all my time in the studios. And I wasn’t great at recording. I wasn’t bad – I could hook up some mics, put them in the right place, get the levels right; but I couldn’t listen to a mix and hear that the top snare mic was two inches too close to the rim, and the drum overheads weren’t balanced properly.

The best bits for me were the digital signal processing modules, where we’d mess about with digital audio in Matlab, Csound and Max/MSP. I bought Matlab, and spent hours and hours of my free time making a random music generator. I wanted to make digital audio plugins to destroy music and put it back into an unrecognisable (but awesome) state. But if I was going to do that, I’d have to learn to program, and that would be too difficult. I’d heard about this programming language called C++, and to make audio plugins you had to know C++. I wanted to make audio plugins with Matlab, because C++ was a scary proper programming language, whereas Matlab was this nice fun environment that happened to input and output audio. Unfortunately it wasn’t very good for making high-performance audio plugins.

Anyway, skip forward a year or so, and I’ve left the world of audio behind and have found myself working in publishing. On a rainy holiday, where all we had to do was read newspapers, I read a story in the Technology Guardian about how the UK computer games industry was doing terribly. One line caught my eye:

It’s better for us to go to somewhere like Imperial College and employ someone who has just done a computer science degree and knows how to program in C++.

I hadn’t done a computer science degree, but I thought to myself – I can learn C++! Why not? I could be a game developer! The moment I got home, I downloaded a C++ IDE, found some tutorials, and started teaching myself C++. I just coded and coded, using the internet as my teacher. Then I bought a beginner C++ book, read it cover to cover in no time, and then re-read it, understanding it that little better. I bought the O’Reilly C++ Pocket Reference and took it on holiday, spending the whole time learning the difference between public, protected and private, and the syntax for operator overloading. I drove my girlfriend crazy by watching TV with her with my laptop on my lap, tapping away remaking tetris with Pixeltoaster. I wrestled with obscure syntax, but Stack Overflow came to the rescue (I was actually really lucky that Stack Overflow went public around the time that I started programming).

At one point I questioned whether I was doing the right thing by learning C++ as my first programming language. I got an answer that has stayed with me ever since (a quote from Randy Pausch’s Last Lecture):

Brick walls are there for a reason. The brick walls are not there to keep us out. The brick walls are there to show you how badly we want something. Because the brick walls are there to stop the people who don’t want something bad enough. They are there to keep out the other people.

So, it took time, but eventually I found my passion. Some are like Chris, and find it when they’re still a teenager, which is great. Others take longer. You just need to be receptive. Don’t assume that there’s anything you can’t do, just because you haven’t tried it. There’s something out there in the world that you’ll discover and you’ll find it hard to imagine your life without it. It’s like a soulmate you get paid to spend time with.

The point

So, what’s the point of all this? I guess what I’m saying is don’t waste your life doing something you’re not passionate about, but be on the lookout for what it is that really fires you up. Because it’s out there, and it’s waiting for you to find it. You may have already ignored some clues as to what it is. Like all good things worth searching for, you won’t find it when you’re looking. But at the same time, you won’t find it if you’re closed to the idea of ever finding it. Keep your eyes wide and your mind open.

Categories: Programming Tags:

Why JavaScript is AWESOME

September 3rd, 2010 34 comments

JavaScript is an awesome language. Now, a few years ago, you’d be marked out as a weirdo for saying something like that. I think there’d probably be some kind of witch-burning ceremony or something, because JavaScript was this stupid language which had stupid syntax and stupid scope and was used to do stupid things by stupid people and just led to awful spaghetti code and killed kittens.

These days people are more understanding, and more and more are coming out of the JavaScript closet. It’s starting to become cool. And I don’t mean cool as in “look at this cool bouncing text” (only works in Internet Explorer 4+ and Netscape 3+); I mean cool as in “hey, check out that cool guy over there writing JavaScript, look how cool he is!”. These days John Resig is a ninja and Douglas Crockford is Chuck Norris.

Douglas Crockford with guns

If Crockford builds JSON without quotes around the labels, it's still valid JSON. - TheReincarnator

Seriously though, what’s so great about JavaScript?

Functions or lambdas

A rose by any other name would smell as sweet, and JavaScript’s functions are sweet like chocolate. I tried to explain to a friend recently just what was so great about JavaScript. What I decided was that it was the functions. JavaScript’s functions can act like lambdas, functions and methods. They can be used to create modules, namespaces, classes and objects. A language like Ruby is a toolbox with some really neat little tools that do their job really nicely. JavaScript is a leather sheath with a really really sharp knife inside. That knife can cut anything, and with it you can do anything. You can kill a bear. You can catch fish. You can whittle a piece of wood into a pony. It’s even a toothpick.

So what makes JavaScript functions so great? It’s two things I think: first-class citizenship and closures.

Functions as first-class citizens

Functions are people too you know? Well, no they’re not actually, but they are objects. They can be passed around like any other object. They can be assigned to variables, passed as arguments, and even returned. And because you can write function literals in JavaScript, you can return a function without even naming it:

function outer() {
    return function () {
        alert("I'm in ur function, accessin' ur local variablez");
    };
}

This kind of thing is really powerful. I’m not going to try to give any clever examples because it’s the kind of thing you only truly get once you’ve done it yourself and suddenly the whole universe opens up in your mind.

Closures

A closure is a funny thing to get your head around. If you’re used to a static language, then it just won’t make sense. Really it’s another one of those things that you have to do until you transcend, but I’m going to have a go explaining it.

Closures are intimately related to first-class functions. One of the things you can do with a function in JavaScript is define it within another function. You can nest functions as deep as you like. Here’s an example of a nested function:

function outer() {
    var name = 'Bob';
    function inner() {
        alert(name);
    }
    inner();
}

So, in this example, when outer is called, it defines name and inner as a local variable and function, respectively (i.e. they are not visible outside of outer). Then inner is called, which alerts name (‘Bob’). That’s not very exciting though – all it shows is that a function can access variables defined in an enclosing scope. But look what happens here:

function outer() {
    var name = 'Dave';
    function inner() {
        alert(name);
    }
    return inner;
}
var something = outer();
something();

Now outer is called, and it defines name and inner like in the previous example. This time, however, inner is returned (alternatively, I could’ve just returned it as a function literal like earlier). When outer is called, its return value is assigned to something. something is now the same function as inner. But what happens when we call something? outer has returned, so when something tries to access it it’ll probably segfault or something. Well, no, it won’t. That’s where the magic happens. When inner was returned, it somehow magically “closed over” its containing scope, essentially keeping it all available even after outer returned. You can do this with arguments as well:

function outer(arg) {
    return function () {
        alert(arg);
    }
}
outer(5)();

This time the returned function has access to the argument of the outer function. That last crazy line there with all the parentheses isn’t Lisp, it’s JavaScript, believe it or not (Lisp parentheses are nested, in case you ever need to tell the difference). outer is getting called with an argument of 5, and then the return value of that call is called itself.

These two things, first-class functions and closures, are what make JavaScript functions so powerful and flexible. Again, this power needs to be felt to be believed, and the only way to feel it is to write it.

Douglas Crockford

Another thing that’s great about JavaScript is Douglas Crockford. He not only wrote the best book on JavaScript – he’s also given the best talks on the language.

Dynamic typing

I’m a big fan of dynamic typing. It adds so much flexibility, agility and speed to programming. It also makes programming much more fun. I’ve written a few posts on the subject so no need to go into more detail here.

Conceptual purity

If I went back ten years and told anyone (myself included) that one of the great things about JavaScript was its conceptual purity, I’d be laughed out of my time machine. But it’s true, there’s something really pure about the language. What can be achieved with such simple language constructs is amazing. There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.

Why JavaScript isn’t awesome

There are a few small things that I don’t like about JavaScript (and are generally considered a Bad ThingTM).

Implied globals

If you don’t declare a variable as local with var, you’re making it global. I don’t need to go into why global variables are a bad thing, because everyone else has.

Semicolon insertion

There was a programme on TV once and they showed all these x-rays with weird things in like toy cars and bottles and stuff, and … oh yeah, semicolon insertion. That’s where the JavaScript interpreter makes it easier for non-programmers to write JavaScript that works and makes it harder for programmers to write JavaScript that’s correct. Silly. Here’s what happens:

return {
    javascript : "fantastic"
}; //This will return an object with a single property

//the interpreter sees this as an empty return statement so inserts a semicolon:
return //this line is interpreted as "return;" - with a semicolon
{
    javascript : "fantastic"
}; //this is just an empty block now.

But I love it really

It’s easy to mitigate those two things with decent coding practices. Basically, always use var, always use semicolons where necessary, and always put the opening brace at the end of the previous line, not at the beginning of the next. Finally, put anything you write through JSLint. It’s like a compiler, without the necessity.

Further reading

JavaScript: The Good Parts: This is Douglas Crockford’s book on JavaScript, and it’s brilliant. It’s only 176 pages, but manages to pack a lot into those pages. By the end you’ll know how to write a recursive descent parser for parsing JSON in JavaScript (some really beautiful code).

Move over Java, I have fallen in love with JavaScript: Miško Hevery usually writes great things about testing – here he talks about JavaScript, from the perspective of a Java programmer.

Best resources to learn JavaScript: This is a useful list of resources for learning JavaScript (as suggested by its title).

Structure and Interpretation of Computer Programs: If you still don’t understand what all the fuss is with functional programming, read this book. I’m only half-way through, but it’s already taught me more about programming than any other book. It’s also probably the reason I love JavaScript so much, because deep down, JavaScript is just Scheme in C’s clothing.

Categories: Programming Tags: ,