I’ve recently come across the Crystal programming language. Crystal is a statically typed programming language with a Ruby like syntax. I thought it might be useful to share my experiences so far. Here goes:

  • The thing that attracted me to Crystal in the first place is something I haven’t seen discussed much elsewhere: You can crystal build your way to a compact and completely stand alone executable, an executable that doesn’t rely on something else — specifically a Ruby installation. One of the things that I do with Ruby is write little utilities (see, for example expletive and md_inc). The ability to produce an executable that just works is great for my purposes.

  • It’s also not bad that the executable is likely to be much faster in Crystal. As I say, I’m just getting my feet wet, but I have ported expletive over to Crystal. When built with the –release flag the Crystal version runs nearly an order of magnitude faster than the original. Yes, that’s 10X. Speed ain’t everything, but it’s something.

  • Crystal has an interesting take on static typing and in particular type inferencing. To be honest I’m still trying to build a model in my head of how it all works. I do think that Ruby programs built with classic OO tech like classes and subclasses and included modules will be the least problematic to port. For example, I ported expletive, which is pretty traditional object oriented techniques to Crystal very quickly.

  • I’ve spent some time trying to understand how the Crystal typing system works when you are using lambdas, and I think porting Ruby code with lots of lambda use is going to be more of a challenge, but not terrible. We Rubyists (well this one anyway) are just not used to thinking about the types of things returned from lambda calls.

  • Most challenging are Ruby programs (and Rubyists!) that use a lot of metaprogramming. So for example, my md_inc utility is just full of instance_eval calls and is going to need some major rethinking to bring to Crystal. Which brings me to macros. Crystal’s macro system is interesting, and to be honest, fun to play with. I do agree with others who have said that macros can soak up most of the work that you might otherwise do by resorting to meta-programming. I’ve seen this in the Clojure world where there are lots of meta-programming facilities available but most of the time it is cleaner to do it with a macro. But I’m still thinking about macros in Crystal.

  • Biggest annoyance so far – and this is a silly one – is not being able to use ‘single quotes for strings’. It’s not a bad language decision, it’s just not compatible with the software loaded into my fingers.

Overall I think Crystal is well worth a look, especially if you are a Rubyist without much experience with a ”compiles to a real executable” lower level language (like C) or with static typing. It’s an easy way to see how the other half lives.

Personally I’m looking forward to learning more.


To the Moon Talk (again)

Posted on Nov 4th, 2014 In talks, space

You can find a second version of my To the Moon talk on YouTube:

This rendition is from the GOTO conference in Aarhus Denmark.


Regular Expressions in Ten Steps

Posted on Mar 21st, 2014 In programming, lists

Knowing how to use regular expressions is a lot like knowing how to cook: even though it is an incredibly useful skill, many people avoid learning. I‘ve been teaching people about regular expressions for years now, and since my voice is starting to give out I thought that I would write it down.

What Are Regular Expressions?

Regular expressions are simply strings that we use to match other strings. If you give me a regular expression, perhaps ‘Ols[eo]n‘ and a string, perhaps ‘Olsen‘ or ‘Olson‘, I can tell you if the strings match the regular expression (they both do). Most computer users deal with this kind of pattern matching all the time — Windows users frequently look for Word documents by specifying ‘.doc‘. While the ‘.doc‘ type patterns are great for what they do, when you are doing complex pattern matching, you need a serious tool. Regular expressions are that tool.

Like all good tools, regular expressions make it easy to do simple things. For example, it is very easy to write a regular expression to:

  • Match any string that ends in .doc
  • Match any string that is all uppercase
  • Or all lowercase
  • Or Russ followed by anything followed by Olsen

You can also write regular expressions that match some pretty wild things. It is harder, but not really all that hard to write a regular expression that matches:

  • A string starting with a letter or ‘_‘ or ‘$‘ followed by any number of letters, numbers or underscores or dollar signs
  • An alpha numeric string, followed by an @, followed by one or more alpha numeric strings separated by ‘.‘ ending with the string ‘.com‘
  • A series of words separated by white space, each word consisting of a vowel followed by the string way or ending with a consonant followed by the string ay

The good news is that there are just ten steps between you and these regular expression things. My hope is that by the end of the ten steps you will be able to write the simple regular expression easily, and be able to puzzle out the more complex ones.

Step 1: If It Looks Like a Duck…

The good news is that with regular expression, ordinary numbers and letters just match themselves:

  • The regular expression aaa matches only aaa
  • The regular expression 1234 matches only 1234
  • Usually, the match is case sensitive, so the pattern Russ would not match russ

While letters and numbers match themselves, most of the special characters (the ones like + and *) have special meanings in regular expressions.

Step 2: There is No Question About the Dot

OK, if letter and numbers match themselves, what do the other characters match? Let‘s start with the dot, the period, the full stop, that thing at the end of this sentence. The dot matches any single character. So,

  • A single period, ., matches a and b and c, among other things.
  • Two periods, .., match aa and bb but not a, or b or c
  • Rus. matches Russ and Rust, but not Rusty
  • Foo. Matches Foot but not Foo

If you are familiar with the *.doc pattern matching that you do when you are trying to find a file, you may have been expecting to use the question mark ? for this. Get over it. The question mark does indeed have a special meaning in regular expressions, but it ain‘t what you think. Remember, in regular expressions, the dot matches any single character. Well almost any character: a dot will not match a line terminating character like a newline or a carriage return, but that for now just think of the dot as matching anything.

Step 3: Quiet on the Set!

The dot is great if I want to match any single character, but what if I want to match something less than any? For example, how would I write an expression that would match only the vowels, or only the numbers? Enter the set. Sets in regular expressions let you match any one of a given set of characters. What you do is just wrap the characters in square brackets: the regular expression [aeiou] will match any one of the vowels while the set [0123456789] will match any single digit. So,

  • [abc] will match a and b and c but not d
  • [xyz] will match x or y or z but not xyz since [xyz] only matches one character.
  • [bcdfgjklmnpqrstvwxyz] will match any single consonant
  • [Rr]uss [Oo]lsen will match my name with or without capitals.
  • [1234567890][1234567890] will match any two digit number
  • [abcdefghijklmnopqrstuvwxyz] will match any single lowercase letter.

To the Moon Talk

Posted on Feb 13th, 2014 In talks, space

The video for my ClojureConj 2013 To the Moon has shown up on youtube. It’s all about the Apollo Moon landings, how they came to be and what it all means to those of us building computer systems in the twenty first century.

The folks who were there seemed to like it, but I was probably having the best time of anyone in that room.


Books of Twenty Thirteen

Posted on Jan 12th, 2014 In books, stuff, lists

Well another year has come and gone, which means that it is time to take stock of the books opened and read. I managed to get through 58 books in 2013, not quite as high as my record 64 the year before, but hey, who’s counting?

Anyway, here’s my list, as maintained by goodreads, organized by category. Oh and these are all affiliate links: If you object to that, don’t hold it against the books.


I spent a lot of time reading about Lispy programming languages this past year and one book really stands out: The Joy of Clojure by Michael Fogus and Chris Houser. Joy really lives up to its name: It’s a fun romp through all of the things you could, should and shouldn’t do with the very Lispy programming language Clojure. Of course I might be biased here, for two reasons: First, I have a soft spot in my head for how-to-use-this-programming-language type books. The other reason I’m biased is that I know and admire the good Mr. Fogus. If you want to know why, well then crack open this book.

The other Clojure book I read this year was Chas Emerick’s Clojure Programming. This book isn’t as much fun as Joy, but Mr Emerick has a much harder job: To explain the whole language from top to bottom. In that he does a good job and Clojure Programming is probably the best all round explanation of the language that we have.

Lisp Hackers by Vsevolod Dyomkin is an interesting series of interviews with, as the title says, Lisp hackers. I like Lisp quite a bit, but I do think this book sometimes falls into the It’s Lisp! Of course it’s great! trap. Show me, don’t tell me. Also Lispy is the Revised Report on the Algorithmic Language Scheme by Hal Abelson. This is, quite simply, one of the founding documents of modern Lisp programming. If you are at all interested in Lisp, read this.

If you haven’t come across it before, Forth is a wonderful, quirky programming language. Like many quirky things, you will either love Forth or hate it. As it happens, I love Forth and Programming Forth by Stephen Pelc is a great way to get going with that language.

I’m happy that technical publishers have mostly stopped asking authors to shoe horn every idea into design patterns. Aside from the unfortunate patterns box that Terence Parr used as a container for his ideas, Language Implementation Patterns: Techniques for Implementing Domain-Specific Languages is a well written, useful book, all about how to use ANTLR to build little languages. If you need to build a DSL in Java, I would grab this book.

There wasn’t a lot in Paul E. Ceruzzi’s Computing: A Concise History that I didn’t already know, but I do like this sort of thin, to-the-point volume. If you want to know something about the history of computers and software and don’t want to read a boring 500 page book to find out, give Mr. Ceruzzi a try.

Science And Technology

I’m an ex-mechanical engineer who has been in the programming biz for a very long time. I think that programmers without my eclectic background tend to have a very distorted idea of what “real” engineering is all about. I’ve heard coders say that our business is different from those other technical professions because we don’t just run equations all day; no, we have to deal with fuzzy requirements and people and their silly organizations. To that I say, read Henry Petroski’s An Engineer’s Alphabet: Gleanings from the Softer Side of a Profession and then tell me how different we really are.

Books of Twenty Twelve

Posted on Dec 30th, 2012 In books, stuff, lists

People who like my writing sometimes ask me how I learned to do what I do. Or they want to know how they can learn to do it too. My answer is simple and in two parts: Write more and read more. I suppose the write more part is pretty obvious, but I’m always surprised by how many people are taken aback by the read more part. Can you make good wine or even good Kool-Aid without knowing what it is supposed to taste like? So I read a lot, both because it improves my writing and because reading is one of life’s great joys.

This past year I’ve taken to keeping track of the books that I’ve read on Goodreads and below is the complete list. A couple of things about the list:

  • You will notice that I liked, or at least tolerated all of the books on the list. So didn’t I pick up any books this year that I didn’t like? Sure. Did I finish them? Heck no! Life is too short to finish a bad – or perhaps simply misdirected book – out of some bizarre sense of duty.

  • The links below are all affiliate links. If this bothers you then google is your friend.

I do recommend keeping track of what you read (and thanks to my buddy Michael Fogus for suggesting just that). Keeping a list means that you can spot patterns - for example I realized that I've always had a bias against short books and classic fiction - and this year I've tried to remedy that.

Anyway, here's my list, organized by topic.

Programming and Computers

Given what I do for a living, you would think that I read a lot of computer books. In most years that would be true, but not this one: In 2012 I went for quality over quantity. Perhaps the book that I proudest of actually finishing is Structure and Interpretation of Computer Programs (MIT Electrical Engineering and Computer Science) by Abelson, Sussman and Sussman. SIOCP is one of those much admired, frequently discussed, oft purchased but rarely read classics. Well having finally finished it, I'm here to tell you that it is well worth the effort. SIOCP takes what I think of as the 50 year view of programming; by the time you are done you will have looked at imperative programming, functional programming, meta programming, lazy data structures and everything in between. Like a lot of programmers, I've started this book any number of times, only to peter out somewhere in chapter three. Two things came together this year to get me on to the end: By the opening of 2012 I had gathered enough Lisp programming mileage to be comfortable with the code in the book right out of the gate. The other thing is that this time I bought a paper copy of the book - somehow having the physical thing there in my hand propelled me forward.

Another programming book that I read this year that I think quite a lot of is Let Over Lambda by Doug Hoyte. Where Abelson et. el. try to be even handed in that dry academic way about the controversies in our little world of programmers, Hoyte marches into battle with his keyboard drawn. Mostly it works and the book is full of all sorts of interesting Lisp ideas. My beef with LOL is that Hoyte violates the "show, don't tell" rule: If I were editing this book I would have cut most of the "Lisp is indescribably wonderful" statements and leave the examples that tend to make the reader draw her own conclusion. Oh and one more thing: If LOL is only for the top 1% of the top 1% of programmers - as the book so helpfully explains - and there are something like 800,000 professional programmers in the U.S. then the target audience for this book is about 80 people. Did the publishers know?

A wonderful contrast to the somewhat preachy tone of LOL is another LOL book: Conrad Barski's Land of Lisp: Learn to Program in Lisp, One Game at a Time!. Land of Lisp is one of those 'full of cartoons and silly jokes' programming books that don't usually work for me. The thing is that Conrad is actually funny and he mixes the jokes with one of the best beginning explanations of Lisp programming that I have ever read. If you are just starting out in the Lisp world, this is definitely a book to check out.

I've also been delving into the history of programming languages this year, which explains why I read Smalltalk 80: Bits Of History, Words Of Advice by Glen Krasner as well as SmallTalk 80: The Language by Adele Goldberg. A fascinating look at a era where having an entire megabyte of RAM was something to brag about.

Science And Math

I spent much of my youth reading all of the science books that I could get my hands on, especially anything spewing out of the typewriter of Isaac Asimov. Asimov used to periodically publish collections of science oriented essays which I would consume just after the ink was dry. I thought I had read them all (Asimov died in 1992) until I happened onto Far As Human Eye Could See. If you care at all about the art of explaining, you should read Asimov. He was a brilliant explainer - and his essays are a great place to start.

The talk that I’ve had the most fun doing lately is finally online. Here’s the official description:

Have you ever thought about how much of software engineering involves explaining things? We stick comments in our program to explain why we added X to Y, we type up README files to explain the program, we write proposals to explain why the program should be funded and we spend the afternoon explaining the whole thing to the new guy so that we can move on to something new. A decent explanation can be the difference between success and obscurity: Would there be any Ruby conferences if not for that original 15 minute build-a-blog screencast for Rails?

In this talk Russ Olsen will run through the things that you can do to craft explanations that are clear, engaging and perhaps even a bit funny. Russ will do his best to be clear, engaging and perhaps a bit funny.

This version is from last Summer at the Rocky Mountain Ruby conference in Boulder.



Another InformIT article!

Posted on Aug 13th, 2012 In ruby

I haven’t been blogging lately, but I have been writing. I recently did an interview with Michael Hart, the author of  Ruby on Rails Tutorial, 2nd edition. Here’s how it starts:

Russ: One thing that surprised me as I was preparing for this interview is that you have a Ph.D. in theoretical physics. How did you start in physics and end up in Ruby?

All articles…