Programming in the 21st Century 2015-11-12T00:00:00-06:00 What Can You Put in a Refrigerator? 2015-11-12T00:00:00-06:00 2015-11-12T00:00:00-06:00 James Hague

This may sound ridiculous, but I'm serious. The goal is to write a spec for what's allowed to be put into a refrigerator. I intentionally picked something that everyone has lots of experience with. Here's a first attempt:

Anything that (1) fits into a refrigerator and (2) is edible.

#1 is hard to argue with, and the broad stroke of #2 is sensible. Motorcycles and bags of cement are off the list. Hmmm...what about liquids? Can I pour a gallon of orange juice into the refrigerator? All right, time for version 2.0:

Anything that's edible and fits into a refrigerator. Liquids must be in containers.

Hey, what about salt? It fits, is edible, and isn't a liquid, so you're free to pour a container of salt into this fridge. You could say that salt is more of a seasoning than a food, in an attempt to disallow it, but I'll counter with uncooked rice. This could start a long discussion about what kinds of food actually need refrigeration--uncooked rice doesn't, but cooked rice does. Could we save energy in the long haul by blocking things that don't need to be kept cool? That word need complicates things, so let's drop this line of thinking for now.

Anything that's edible and fits into a refrigerator. Items normally stored in containers must be in containers.

How about a penguin? Probably need some kind of clause restricting living creatures. Maybe the edibility requirement covers this, except leopard seals and sea lions eat penguins. No living things across the board is safest way to plug this hole. Wait, do the bacteria in yogurt count as living? This entire edibility issue is troublesome. What about medicine that needs to be kept cool?

Oh no, we've only been thinking about residential uses! A laboratory refrigerator changes everything. Now we've got to consider organs and cultures and chemicals and is it okay to keep iced coffee in there with them. It also never occurred to me until right now that we can't even talk about any of this until we define exactly what the allowed temperature range of a refrigeration appliance is.

In the interest of time, I'll offer this for-experts-only spec for "What can you put in a refrigerator?":

Anything that fits into a refrigerator.

The Right Thing? 2015-10-20T00:00:00-06:00 2015-10-20T00:00:00-06:00 James Hague

A Perl program I was working on last year had fifteen lines of code for loading and saving files wholesale (as opposed to going line by line). It could have been shorter, but I was using some system routines that were supposedly the fastest option for block reads and writes.

The advice I had been seeing in forums for years was that I shouldn't be doing any of this, but instead use the nifty File::Slurp module. It seemed silly to replace fifteen lines of reliable code with a module, but eventually I thought I'd do the right thing and switch.

I never should have looked, but File::Slurp turned out to be 800+ lines of code, including comments, and not counting the documentation block at the bottom. One of those comments stood out, as is typical when prefaced with "DEEP DARK MAGIC":

DEEP DARK MAGIC. this checks the UNTAINT IO flag of a glob/handle. only the DATA handle is untainted (since it is from trusted data in the source file). this allows us to test if this is the DATA handle and then to do a sysseek to make sure it gets slurped correctly. on some systems, the buffered i/o pointer is not left at the same place as the fd pointer. this sysseek makes them the same so slurping with sysread will work.

Still, I kept using it--the right thing and all--until one day I read about a Unicode security flaw with File::Slurp. Now I was using an 800 line module containing deep dark magic and security issues. Oh, and also no one was maintaining it. This was no longer the recommended solution, and there were people actively pointing out why it should be avoided.

I dug up my original fifteen lines, took out the optimizations, and now I'm back to having no module dependencies. Also the code is faster, likely because it doesn't have to load another module at runtime. As a footnote, the new right thing is the Path::Tiny module, which in addition to providing a host of operations on file paths, also includes ways to read and write entire files at once. For the moment, anyway.

(If you liked this, you might enjoy Tricky When You Least Expect It.)

Computer Science Courses that Don't Exist, But Should 2015-09-10T00:00:00-06:00 2015-09-10T00:00:00-06:00 James Hague

CSCI 2100: Unlearning Object-Oriented Programming
Discover how to create and use variables that aren't inside of an object hierarchy. Learn about "functions," which are like methods but more generally useful. Prerequisite: Any course that used the term "abstract base class."

CSCI 3300: Classical Software Studies

CSCI 4020: Writing Fast Code in Slow Languages
Analyze performance at a high level, writing interpreted Python that matches or beats typical C++ code while being less fragile and more fun to work with.

CSCI 2170: User Experience of Command Line Tools
An introduction to UX principles as applied to command line programs designed as class projects. Core focus is on output relevance, readability, and minimization. UNIX "ls" tool is a case study in excessive command line switches.

PSYC 4410: Obsessions of the Programmer Mind
Identify and understand tangential topics that software developers frequently fixate on: code formatting, taxonomy, type systems, splitting projects into too many files. Includes detailed study of knee-jerk criticism when exposed to unfamiliar systems.