I'd Say 1-Liners Are Crucial

August 15th 18:13
by why

When Hackety Hack came out, I’d see some folks in Internet Town say that the six-line blog example on the home page was contrived, simply because it was too short. I mean you can reduce any thing to one-line of code, ultimately, right? And what’s the point of coding if it’s all dumbed down for you?

So, getting back to Bonnie Nardi’s book. One of the things she studied in the book was how quickly people grasp spreadsheet programming.

It is very important from a motivational standpoint that users attain early success with the system they are using. It is not enough to say that users need systems that are “easy to use”; end user programming systems should allow users to solve simple problems within their domain of interest within a few hours of use. (p. 45)

Yeah, definitely, Bonnie. Definitely. And I might add that it would be nice if they could see something satisfying happen within the first fifteen minutes. Anyway, there’s a very short clock ticking in the beginning hours of learning.

And the size of the code is really important! Nardi has a few pages on conditionals. How hard they are for beginners to pick up. And yet she found that Excel users really grasped on to them and often used them quite early since the IF() construct in Excel is small enough to fit in a single cell.

A conditional in a spreadsheet formula is easy to understand because it does not transfer control from one part of the spreadsheet to another. Its effects are local to the individual cell; the user can keep track of its effects because they do not ramify throughout the program. (p. 47)

A few pages later she mentions that most spreadsheet users only touch fewer than about ten functions in their frequent work. Perhaps a six-line blog may just be too long!

I’m not suggesting that one-liners are the heart of all programming. But they can be the hook to get someone exploring. A single line of code simply shows that a language can be focused. And it lets a beginner get comfortable with the basic atoms.


George Bunyan

said on August 16th 02:28

I think the ability to do something satisfying within 15 minutes should be a requirement of all librarys. Have you ever tried to use a GTK TreeView? It isn’t pretty.

Chris Pine

said on August 16th 02:56

And I might add that it would be nice if they could see something satisfying happen within the first fifteen minutes.

Absolutely! Because if it’s not satisfying by then, it’s not fun. And it’s a physiological fact of the brain-stuffs that fun increases learning and retention.

One-liners say a lot about a language, about closing that space between we soft beings and the computers. Until we start getting computers in our brains like D.A.R.Y.L., one-liners are the next best thing. Because they open up a whole realm of problems to actually be solved. Not big problems, but lots of little problems.

I’m not suggesting that one-liners are the heart of all programming.

No, not the heart of programming. But also not just the beginning. 10 years later and you’ll still be coming up with one-liners, maybe more often than ever.

I’ve been getting really into Erlang recently, and do most of my programming in that. But I find myself reaching for Ruby quite a bit, because it is just better for little things, for tiny algorithmic experiments, for just thinking.

It’s kind of sad seeing (otherwise very smart) programmers who don’t have a one-liner-compliant language to think in. A question will come up, and they just go kind of blank, like if you asked them for the wavelength of red light without wikipedia access nearby. But they’re sitting at a computer…

Just sad.

The other huge virtue to one-liners (and Ruby in general) is that because you have taken out all of the public static final const unsigned struct incantations, the new programmer can actually understand every aspect of a one-line program! None of this “well, just ignore the first line… you just need it.” I cannot stress how important this is to a feeling of ownership of the program! Italics! Having a 5-line helloworld.java program is criminal. Might as well call it goodbyprogrammer.java, for all the fuzzy goodness you decided the unfortunate student was unworthy of.


said on August 16th 03:36

I’m so glad you’re reading and now citing Bonnie Nardi’s work! We talk about SMOP quite often ’round these parts.

I’m going to have to read some of her otherstuffs too some day too.


Mike Woodhouse

said on August 16th 04:47

re Excel: ’s true

Of the built-ins, IF, SUM, AVERAGE, VLOOKUP, OFFSET (I’m a advanced user, after all) probably constitute more than 90% of my usage.

And what about COBOL, where I spent (frittered?) my career in the 80s? MOVE, COMPUTE, IF and PERFORM, with a smattering of file IO commands were pretty much all the verbs you needed.


said on August 16th 07:03

Hi Chris Pine,

Your tutorial made me enroll in Computer Science!

Now it has been 2 years and I soon have a bachelor’s degree.


said on August 16th 10:04

George Bunyan: The Ruby-GNOME library is totally sprawling. Too much unnecessary work!

A. Whitehead: By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems.

Chris Pine: I’ve wondered if the reason many people adore babies and small pets is because they fit entirely into view. You can be close to them and yet their shape doesn’t go into your periphery.

lwu: SMOP is a true classic!! With any luck, programmers will pull their heads out of their frothy goblets of business trends and start seeing the other dimensions to the arena.


said on August 16th 11:06

I like one-liners. But since Hackety Hack is aimed at kids, I’d say one liners are something to be introduced after you’ve shown them the longer version. At least that’s been my experience (admittedly in teaching only one kid). I find it useful to first teach my child the fuller construct which often makes it easier to grasp (more written out as if in plain English), and then teach her the one-liner (“and now, look how it’s cool that you can do all of that with just this one line”). But teaching her the one liner first can be a bit hard for her to really grasp what’s going on.

Probably not the best example, but here’s one we recently went over:

var1 ||= nil
if var1 != nil then
var2 = var1

reduced to:

var2 ||= var1 ||= nil

Once she understood the longer version, the one-liner was easier to grasp.


said on August 16th 11:39


Ah yes, frothy goblets of business trends. Thar be green dragons…

If you’re in the mood for more reading re: notation, check out Green’s Cognitive Dimensions of Notation (CDN):


You seem particularly interested in the task of concise yet expressive notation, and I’m curious if you could put the vocabulary and dimensions of CDN to work!

Sometimes when I think of your work, _why, I have thought of it as a form of hacking crossed with bricolage, but after reading and thinking about Donald Schön’s work on reflective practice, I started to see your code-y efforts with a distinctly Schön-ish lens.

That is, you often employ exploratory experimentation, and I think you do (reflective) conversation with materials better than most anyone I’ve known!

At least, that is my lit (prog) crit of your recent works :)



said on August 16th 13:16

Interesting stuff… I don’t really get the point Bonnie Nardi is trying to make though. Yes, I see the points about text being concise, about things being task specific, but then what? I’m not entirely in agreement about visual languages not adding much: Star Logo and Alice and Storytelling Alice have the advantage of removing tedious typos from the keywords and code layout that one gets in purely textual programming without getting your wrist slapped :-) by the syntax highlighter.

Having said that, as the Pragmatic Programmers say, keeping knowledge in plain text is important. I think the Alices and Star Logo should have pure text outputs easily accessible so that the programs may be manipulated by other programs and read back in.

However, since the extracted parts of Bonnie’s book are very clipped, I can’t see the thrust of the argument without buying the book; and I’m less inclined to buy the book if I’m not seeing what is argued.

@lwu: that conversation with materials link was great. I didn’t know about the origin of Scotch tape, and the name. Interesting to see stuff from Terry Winograd as recent as that book—I’ve always wondered what happened to his natural language work as SHRDLU is still cited to this day, and I’ve not seen much that is better. The chatbots of today are not as bright, alas. This supports Bonnie’s point about natural language input.

And the point about concise notation is interesting. FORTH is concise because the data passing is implicit (the stack) and it has many features which make it elegant, ideas of encapsulation built in well before Pascal became popular. But I can’t get my head round it. I just haven’t been able to do anything useful with it, after hours of reading, and even playing with Gnu Forth. I’m hoping for something to fall into place one day (to which end I bought Thinking Forth recently).


said on August 16th 14:13

hgs: I dunno, I can’t really summary this book. The beauty of it is that it covers so much ground. Ultimately it’s about how to get everyone to program. Part of it involves looking at hacking as a common skill like basic math rather than being strictly a vocational gig.

Anyway, she’s not advocating visual languages really. On the topic of syntax:

Syntax is often suggested as a problem area in textual languages, but in our study users reported that syntax errors were few once they were familiar… Textual languages are compact, efficient, and can be developed in less time than graphical languages.

If you don’t believe most people will end up learning how to hack or if you think our programming environments of today are the end, then I wouldn’t spend the money. It’s an expensive book!!

Also, she’s not advocating natural language input, but we’ll get to that on another day, I’m sure.

August Lilleaas

said on August 16th 15:20

I totally agree. One-liners makes beautiful code, that’s easy to read. I enjoy reading code with stuff like “get_options_from_args” and “start_file_upload”. And I love the rails initializer with a ton of one liners like:

  • require_frameworks
  • load_environment
  • load_plugins
  • load_observers



said on August 17th 05:08

@Why: Thanks. Yes, I realized she wasn’t advocating natural language, or visual languages, the critique was valid for those. Indeed, natural language is only used in everyday conversation. Any domain where you want more precision, which you’d need for computational tasks, you end up with something else: {maths, legalese, technical drawings, …}, and special vocabulary, which even cooking has.
But I find myself wondering about mixed modes, ability to chat to the machine about your program, like SHRDLU: “Why did you give me a segmentation fault just then?” “Because I was trying to access 0x36a9436f.” “OK, what data structure were you trying to look in at the time?” in a more natural way than fitting yourself to a debugger… And that visual languages may allow quick composition of syntactically correct snippets of textual code, which you then treat as text.

Actually, with less punctuation peculiarities, Ruby and similar reduce the need for this, compared to the semicolon obsessed :-) languages, though one can still have long, bloody wars about indentation, how wide tabs are, etc!

I may try to get it from a library for now. Thank you.

Comments are closed for this entry.