Inclusive and Exclusive OR in informal speech

As good computer scientists, we know that there are two kinds of OR.

An inclusive OR, which is what we nearly always need in programming, is true if either of its branches is true: “exit this loop if we’ve processed 50 items OR there are none left to process.”

An exclusive OR is true if exactly one if its branches is true, but not if both are. “If player 1 is attacking player 2 OR player 2 is attacking player 1 (but not both) then inflict damage.” [This is a contrived example: that's because it's hard to think of non-contrived examples -- they hardly ever come up in real programs.]

When we use “or” in informal speech, we nearly always mean exclusive or. If I tell you I’m going to the cinema to see Skyfall on Wednesday or Thursday, you understand that I will go on one day or the other, but not both. If I ask you what you want to drink and you say Abbot Ale or Ruddles County, you’d be surprised (but maybe not disappointed) if I brought you two pints.

“You can do anything if you believe in yourself”

Trust your heart.  Believe in yourself.  Follow your dream and you can do whatever you want to.  Ubiquitous morals in Hollywood movies and many TV series.  But potentially poisonous.  As Andrew Rilstone has pointed out, “this is a deeply re-assuring message for the high-achievers who make movies. It says in affect ‘We are rich and famous because we deserve it’. It is a very depressing message for the people who make their coffee.”

Plus it’s, you know …  Not true.

(This image is from a T-shirt that I am very tempted to buy.)

On trying to read Dune

Matt Wedel is constantly telling me I need to read Frank Herbert’s classic sci-fi epic Dune.  I’ve never been keen because of the vast number of sequels, but I finally gave in to his repeated requests and started on it last night, on my Kindle.

I got as far as page 4.  Since the Kindle shows small pages, I guess that’s part way down page 2 of a printed copy.  Here’s why:

Yes, Paul.  What is a gom jabbar?

Tagore Smith on functional programming

My travails with functional programming have been a bit of a recurring theme on this blog, and I have to admit that my attempt to learn Scheme has stalled, more than anything due to all the other things I’ve been doing.  I’m sufficiently aware of it to feel guilty, but not sufficiently to actually invest the time I ought to into actually learning it.

But today, Togore Smith wrote a brilliantly insightful comment on one of my oldest posts (Closures, finally explained!), and it’s got me thinking about this subject all over again.

Five and a half months late

If only the XKCD guy had published this comic five and half months earlier, I could have used it to illustrate my functional-vs.-imperative-programming article.

C’est la vie.

Unrelated addendum

Am I the only person in the whole world who finds this joke funny?  ”A man walked into a pub.  He said ‘Ouch!’.  It was an iron pub.”  It makes me laugh even to type it here, but so far not one single person I’ve told it to has laughed.

Also: “1st man: My wife’s gone to Jakarta.  //  2nd man: Of her own accord?”

Perl’s *DBM_File packages: what the heck are you people thinking?

Among many other things, my day-job involves working on a web-based system, written in Perl, for administrating our MasterKey metasearching system.  We call the admin system MKAdmin.  It was developed on Debian GNU/Linux, since that’s our usual production platform, but I also work on it from my Mac laptop.

Excuse me if I rant for a moment.

MKAdmin, until recently, used the NDBM_File module to implement a simple persistent session store — just an on-disk hashtable that maps cookie values to session structures.  NDBM_File is part of the core Perl distribution.

But when one of our partners wanted to run it on Fedora Linux, it became apparent that in their infinite wisdom the Fedora packagers have removed the NDBM_File module from their Perl package, so MKAdmin wouldn’t run. Understand: it isn’t that they didn’t provide an RPM package for the NDBM_File module, it’s that they removed that module from the Perl package, even though it’s part of the Perl core distribution.

How correct is correct enough?

First of all, welcome back to programming! It was a bit of a shock for me to see that, since the last programming article, I’ve written a sequence of four posts about Doctor Who and Buffy, which is an imbalance I never intended.  Well, Doctor Who will end after two more episodes, so hang in there, programmers!

Now, then.

The response to We can’t afford to write safe software was very interesting.  As usual (I am pleased and proud to say) the comments here on The Reinvigorated Programmer article itself were, almost without exception, insightful and informative.  But over on Reddit things were not so good.

We can’t afford to write safe software

Let’s start by thinking about a very simple example.  I’ve recently switched to using Ruby as my language of choice, after a decade as a Perl hacker.  Ruby does a lot of things more nicely than Perl, including having proper object syntax, simple everything-is-an-object semantics, a sweet module/mixin scheme and very easy-to-use closures, so I’ve mostly been very happy with the switch.  In so far as Ruby is a better Perl, I don’t see myself ever writing a new program in Perl again, except where commercial considerations demand it.

A hard-to-find bug, and equivalent APIs in low- and high-level languages

I just wrote an entry about a hard-to-find bug on the blog of my employer, Index Data.  It turned out to hinge on the different API expectations of programmers in low- and high-level languages — specifically C and Ruby — and I think it’ll be of interest to most Reinvigorated Programmer readers.  Enjoy!

How slow are functional implementations of quicksort?

I’ve been talking with my colleague Jakub Skoczen.  He’s insisting that functional implementations of quicksort, which make and return new arrays at each level of recursion, must surely be much slower than imperative implementations that modify an array in place.

And I can see his point.