Say you have a curve that you’re looking at under a microscope. You do your best to measure the length of the line given that your scope doesn’t have perfect resolution, so any tiny details get washed out and replaced by you going “well, it looks like a line”.

For a straight line, —-, as you increase the resolution of your scope, the length you measure doesn’t change. The same is true of a half circle, or most other such smooth things. Now, that when you double your resolution, what looked like a little bit of line turns out to be a squiggle, rather longer than the line it was blurred to, though with the same starting and ending points. And then for each part of the squiggle, when you double the resolution, each bit of line on it turns out to be a squiggle itself. And so on and so on.

If the length you measure grows in a regular fashion as you increase your resolution, so the length at one resolution is equal to the length at half that resolution to some power alpha, then we say that alpha is the Hausdorff (or fractal) dimension. For a straight line, the length is always the same, and alpha=1. It’s a one dimensional object. There are ones like the Hilbert curve where alpha=2 (that is, if you take the infinitely fine version, it fills the whole of two dimensional space), and things like the Koch curve which is about alpha=1.262. Wikipedia has a nice list, ordered by Hausdorff dimension.

Yet all of these things are lines. You could grab them and straighten them out into a straight line with Hausdorff dimension 1. The notion of dimension we’re used to is defined by what you can straight something out into, not by the resolution game above. If I can straighten it out into a line, it’s one dimensional. If I can flatten it into a surface, it’s two dimensional. This notion of dimension we call topological dimension.

Any time the dimension from how length grows with resolution exceeds the dimension of what you can straighten it out into, you have something weird and spiky with infinitely small noise.

That’s all there is. They’re cute. But why does anyone care? Because they showed up as a the shape of a bunch of weird things in dynamical systems that people didn’t realize existed until well into the 20th century.

So, a brief digression on dynamical systems: Say I have a recipe that takes each point in a space and maps it to another point. If I repeat the recipe again and again, the points start moving along paths, point -> recipe applied to point -> recipe applied to recipe applied to point.

One question to ask about the behavior is where the points go. Do all the points in some region stay in that region, that is, are there basins of attraction? Up until the mid 20th century, everyone thought that the only basins that weren’t really fragile mathematical artifacts were simple things with smooth boundaries with equal Hausdorff and topological dimension. Anything that wasn’t would just go away if you distorted the recipe slightly, so wasn’t important for modeling anything real.

Turns out that that’s not true. There’s a whole class of basins which behave in all kinds of new and strange ways that basically required a full rewrite of dynamical systems theory. Some of these systems and basins have boundaries which are fractals.

So the fractals aren’t the interesting part. The interesting part is the behavior and classification of dynamical systems. The fractals are just an easy part to see that everyone’s latched onto.

Laws and government are technology. Our ancestors roaming the African savannah did not know how to organize and run a state of three hundred people, much less one of three hundred million. That technology has developed over the past few thousand years. Law is similar. How many names from early history are associated with a code of law, from Hammurabi to Justinian?

And even in the supposed specialty of Silicon Valley, computing, it’s soft headed. Computing is only incidentally about the digital computing machines we use today. The first computers were rooms full of women with adding machines, passing their results around in fixed patterns in order to perform complicated calculations. This is different only in scale from a government.

The clamor for no government by those enamored with software as a cure for all ills can’t be taken seriously. To a man, they’re all either sociopaths or incapable of systematic thought.

A sociopath wants everything going his way, and objects to anyone stopping him for any reason. There’s not much to be done with sociopaths besides kill them. But for those who aren’t, this obsession with avoiding compulsion isn’t reasoned. It seems more like a holdover from being beaten up and having their lunch money stolen on the playground.

If they really wanted to minimize the compulsion on people, they wouldn’t be asking for no government. Most will quickly backtrack and accept some government. After all, you have to have enough force available to compel those who aren’t playing nicely to behave. If Mark Zukerberg decides that he wants me dead with no retaliation on himself, there has to be someone with even more teeth than he can hire. And that is the point of a government: we give it a monopoly on legitimate force in our society. After Mark Zukerberg sends his death squads after me, there needs to be a government powerful enough to go pry him out of his mercenary guarded compound in Montana.

But why is that compulsion worse than the compulsions imposed on those suffering from obsessive compulsive disorder or schizophrenia by their disorders? These are severe compulsions, ones that don’t go away after someone has taken your lunch money. We are today capable of at least partially lifting these compulsions. Anyone who has allowed as how enough government to protect them from playground bullies is good that won’t also accept this isn’t reasoning, they’ve just never gotten over having someone give them a wedgie on the playground.

And if such suffering caused by such continuous compulsions is to be prevented, what about forcing people to come to an environment which is both physically and socially unpleasant to do mindnumbing work, day in and day out, or face the threat of starvation, ruined lives, or possibly being allowed to die of a major medical condition? That seems like compulsion worth preventing to me.

So someone really interested in the freedom from compulsion, the liberty, of his fellow man, would agitate for honest and fair law enforcement, health care for all, and strong labor laws. That should sound familiar: it’s socialism.

That’s right, a libertarian capable of systematic thought is a socialist. Or a sociopath.

We’ll come back to the peculiar thing that is “data science” later. Let’s look at these programs first. They’re teaching basic probability and descriptive statistics, how to design a study and analyze it, how to make decent plots, linear regression in its various forms, and enough understanding of programming to get some work done. Some add on some domain knowledge on business.

That’s excellent material, and the undergraduate students at University of Washington or Northwestern or Columbia or the various schools offering these programs should be screaming bloody murder, or at least demanding their tuition back. Those aren’t graduate topics! Those are the basics you should expect from anyone with a technical degree! Okay, if you hired someone who studied a basic science like physics or chemistry you might now expect the business knowledge, but an engineer had better have it. This isn’t a subject. It’s part of numeracy.

They are very much teachable to the undergraduates. A good hunk of the data science certificate gets taught to physics majors in one semester of their second or third year at University of Virginia as “Fundamentals of scientific computing”. I single out University of Virginia’s class as an example because I happened to be there when it started in 2005, and remember talking about what should be in it with Bob Hirosky, its creator. My friends were the teaching assistants.

And the topics in these certificates are the basics, not the advanced material. Not that there aren’t legions of professional analysts out there with less statistical skill and no knowledge of programming, but no one would dream of giving them a title other than “Excel grunt”—sure, gussied up somehow to stroke their ego, but that’s what it comes down to.

So, we have a failure of the academy. Nothing new there. The rise of data science itself is a peculiar one, though. It was reified into existence by a couple of guys doing the dismal work of mathematically stalking people at Facebook and LinkedIn, though Google got in on the name game pretty quickly. Who can blame them? If your job is doing something as puerile as getting people to click on ads, I don’t begrudge you any vestige of self respect you may try to grasp. Yes, your life would be better spent getting your plumber’s certificate and doing something constructive, but I recognize that it’s hard to make big changes. But let’s not pretend that anyone would let you anywhere near the census or running a clinical trial.

Once data science was reified, the fight was on for who got to decide what it was. I know a few of the conceptions:

• The adsmen of Silicon Valley
• People trying to repackage Taylor’s scientific management
• Programmers with some machine learning training who found themselves analyzing data, but without knowing what had been done in statistics proper
• Academics trying to teach something useful, who hope to use the label to make an end run around the lethargy and uselessness of the statistics department
• Journalists looking for the next big thing to report on
• Companies trying to sell tools for data analysis who had found you can’t make money selling data analysis tools to statisticians unless you’re SAS or IBM

There are more. The full study of the factions and their interplay would make a very interesting sociology or history thesis.

But the fact that we’re arguing over this at all is a symptom of the failure of technical education today. That’s right: if you’re a professor in a technical department, it is your fault that these certificates exist. You have failed your students, and the world is paying a price in buzzwords.

This is a criticism of the Ruby language and its community. Some of the criticisms point out fundamental errors in the language design, or poor choices in what historical examples to follow. Others are about errors in the process of developing the language that have reduced its usability.

I have intentionally avoided all criticisms based on my own familiarity with some particular language. This means I have had to lay out a clear statement of the criteria a given language construct is supposed to address in practice, with examples of how various languages have handled it, and then turn to how Ruby has failed in this area.

There are things about Ruby that I think are poor choices—usings symbols like @ and $ instead of spelling out names, or Perlisms such as $/ for newline separator. I can make cases for my tastes here, but I acknowledge these as questions of taste. I am concerned here with substantive errors in Ruby’s language design, often cases where an infelicitous combination of small choices led to a cascade of complexities.

This document is necessarily negative about Ruby. Every section culminates with a criticism of Ruby. I have used what I found frustrating about Ruby as a lens for examining issues of language design. If I had used C++ or PL/I as a lens, then this document would be a sequence of negative statements about those languages instead. I must admit that the choice of Ruby was no accident, and I felt a certain gleeful sadism in the dissection, perhaps in revenge for my own frustrations in programming in the language.

Documentation

The degree and form of documentation is nearly uniform within a programming language community. Look at the language, its standard library, and those libraries and tools in common use, and the organization, the amount of detail, the structure of the reference material, and the form in which the documentation is presented and distributed is nearly uniform. For those who work in a single community this may seem unremarkable, but for those of us who wander (more or less uncomfortably) among many communities, it is a cause for astonishment.

The appendix goes into detail about the documentation cultures of several programming communities, but there are some defining questions:

• How is expository and reference information organized? Is API documentation completely separate from tutorials, as in Java, or does every API reference begin with a short introduction and some examples of use, as in Python?
• How closely intertwined are code and documentation? They may be completely separate, as in C, or one and the same, as in Knuth’s literate programming.
• How is the documentation accessed? Is it from static manuals, even hard copy books, is it found by quering a running instance of the language runtime, or both?
• How much detail is typical in the expository and reference information for the language? This can range from scanty vignettes as in BioConductor to Common Lisp’s closely defined standard.

Each of these decisions has tradeoffs. If I use docstrings extracted by a running image, then a piece of code that defines a large number of functions on the fly, none of which have an explicit representation in the source code, can easily give them documentation accessible like any other function. On the other hand, it is easy to lose the docstring on an object when transforming it in the instance (as with Python’s decorators)—a problem that static comments a la Java do not have. Other criteria have some choices that are clearly superior. The lack of both complete exposition and complete reference documentation in BioConductor’s vignettes, for example, is inferior to Common Lisp’s standard by all criteria except saving the implementor the time and effort to write documentation.

What are Ruby’s characteristics in this area?

• Expository information is separate from reference information. Reference information is provided in HTML format. Expository information is scattered among books, blog posts, and tutorials.
• The reference documentation is extracted from the source code, though there are at least three separate tools—RDoc, Tomdoc, and Yard, each with separate formatting conventions—for doing so.
• The documentation is accessed via static manuals. Ruby does not use docstrings or provide documentation in the runtime.
• The reference documentation is sketchy. It is typical for a Ruby programmer to refer to the source code to figure out the semantics of a function.

Interfaces, protocols, and abstractions

What are the methods on a socket object? Most programmers will immediately respond: read, write, and close. There may be more—whether the socket has data ready to read, is it closed already, and various others depending on the exact semantics a programmer learned for sockets—but those three will be universal. What methods will a stream have? Read and close at least. Such fixed sets of methods on a group of types we refer to as an interface.

All languages have interfaces. In Java, they are explicitly called interfaces and are distinct entities in the language:

public interface Stream { public String read(int n); public void close(); } 

Clojure and Haskell give them their own existance under the names “protocol” and “typeclass”, respectively. Common Lisp, Python, and (weirdly) C don’t give interfaces a language entity, but make heavy use of them in practice. Any object in Python with a read method and a close method, obeying some basic semantics, is usable as a stream, whether it is a file or a network socket.

In C, we can write a generic function over streams by passing, in addition to the stream to work with, a function to read from that stream and a function to close that stream. Such interfaces are essentially untyped, but common practice among good practitioners of the language, and are found even in the C standard library. For example, qsort (a quicksort function) has the signature

void qsort(void *base, size_t nel, size_t width, int (*compar)(const void *, const void *)); 

The first three arguments give a pointer to an array of memory, the number of elements in the array, and the number of bytes per element. The last argument is a function to compare two elements. The actual types and widths of the elements, and the types and widths the function expects to operate on, are completely unavailable to the compiler.

Interfaces extend beyond simple things like streams. Something as complicated as a SAX parser has an interface. There may be multiple SAX parsers in a language, with different tradeoffs of speed, memory use, ease of installation, etc., but there is no reason that they should not all share an API for SAX parsing. Python has codified this. Many elements of its standard library will have a version written in Python (for portability) and one written in C (for speed). The C version has its library name prefixed with a lowercase ‘c’, but the API within the libraries is identical. So whether you use ElementTree or cElementTree, your code should produce identical results, but it will run much faster with the latter.

The most obvious argument for strict interfaces is reducing how much a programmer must memorize. You avoid having distinct blocks of code to handle this kind of socket versus that kind of socket. But the real argument for interfaces is not what they save you from having to do, but what they make possible. For example, you can define a function that takes two streams, and returns a stream which concatenates them, or that returns a stream with all XML doctype definitions removed, or returns a stream that allows you to peek an arbitrary number of characters ahead into the stream it is transforming. These are all still streams. The glory of interfaces is not that they save you work, but that they make disparate types with common behavior into something that can be combined and transformed. Any one of these transformed streams can be used as an argument to any other of them. They have become an algebra. In the absence of an interface, none of these transformed streams are usable by existing code.

This is one of Ruby’s weaknesses, possibly because the documentation is sparse and it is impossible to satisfy an undocumented interface. A few (by no means comprehensive) examples:

• TcpSocket and SslSocket do not name their read and write methods the same thing.
• The SAX parsers in Rexml (which is pure Ruby) and Nokogiri (which is a binding to the C library libxml2) differ only cosmetically. Their constructors are slightly different, and the name of the event handling functions they expect are different, though they do precisely the same thing. There is no reason they could not have identical APIs.
• The XML libraries, and everything else that uses a stream, don’t use any well defined interface, so writing stream transformers is an exercise in frustration: run, see what method the library tried to use that was missing, implement it, repeat.

Namespaces, compilation units, and modules

I know of three concepts in computer science for organizing large amounts of code. The three are orthogonal. That is, if we write out the algebraic properties satisfied by the operations on them, there are no properties relating operations of one to operations of another (though there are optimizations in compilation that can be made that interact among them).

The three concepts are:

• Compilation units to control how much work a compiler must do to recompile a program when parts of it have changed.
• Namespaces to make the bindings of symbols predictable.
• Modules to define interfaces among components of the system.

All languages in general use today provide at least a partial implementation of all three, at least by social convention if not by actual language support.

Many language provide a notion of library, package, or assembly, but these can be seen as recursion in these three notions: a library as a namespace containing namespaces, versioning of packages as a compilation unit containing compilation units.

Compilation units

When recompiling a program, the simplest way is to compile all of the code from scratch, as if this were the first time it had been compiled.

In practice, this is often impractical. Some systems require hours or even days to build. In systems where the build time is long, the code going into the present build usually differs only slightly from the code that went into previous builds. To take advantage of this, we can divide a program into pieces and draw a directed, acyclic graph between the pieces, with one piece linked to another if its code, in the course of its life, will transfer control to a piece of code in the other. When we change code in one piece, we only need to recompile it and any pieces with a path to it in the graph. For systems with thousands or tens of thousands of pieces, this can be a remarkable speedup. These pieces are what we refer to as compilation units.

In most languages today, compilation units are some combination of files. In Python, the compilation unit is a single file. In C and C++, it is a source file and one more headers.

For a compilation unit we expect to be able to compile it, to be able to measure if it has changed since the last compilation, and, for any pair of compilation units, whether changes to one will also require the other to be recompiled.

Namespaces

Say you decide to use a third party library when writing your program. You don’t want to worry about what every binding in that library is, and whether you are going to collide with it when making your own bindings. Further, you want to be able to write your code to be interpreted in the context of a known set of bindings. Yet you also want to be able to override existing bindings, or attach bindings from other libraries to your current context. Handling these cases has leads us to namespaces.

A namespace encapsulates a set of bindings—functions, classes, constants, macros, or whatever other constructs the language allows a name to be assigned to—so they are not impacted by bindings in other namespaces. To make namespaces useful they must have what I call the “relocatability property”: if I move some code from one namespace to another, then attach that namespace, there should be no change in the behavior of the program.

In languages without explicit namespace support, such as C, Smalltalk, and Emacs Lisp, developers usually prefix their bindings with a library name. Every binding in GLib in C is prefixed with g_. All of org-mode‘s bindings are prefixed with org-. If everyone adheres to this convention, leaving unprefixed symbols to the default language and its standard library, then there need be no namespace collisions.

Continuously prefixing everything gets awkward quickly, so languages with more explicit namespace support, such as C++ and Python, allow you to attach part or all of a namespace, possibly qualified or renamed in some systematic way, to another namespace. In Python, where namespaces are files (which are also compilation units and modules as well) you can write

import something something.f() import something as new_name new_name.f() from something import f f() from something import * f() 

In C++, where namespaces are separate from compilation units, you can do the same thing:

namespace something { void f() { … } } something::f(); namespace new_name = something; new_name::f(); using namespace something::f; f() using namespace something; f(); 

There is another notion of namespace which is similar enough to be justifiably called a namespace, but different enough to be confusing: different syntactic usages of a symbol may refer to different bindings. That’s obscure, but a bit of obfuscated Java will make all clear:

public class Main { public static class T<T> { public T T; public T(T value) { this.T = value; } } public static String T() { return "Hello, World!"; } public static void main(String[] argv) { String value = T(); T<String> T = new T<String>(value); System.out.println(T.T); } } 

Everything in sight is called T, but almost every T refers to something different. In Java, the same symbol can refer, based on its syntactic position, to

• a local variable
• a function or method
• a type or package
• a generic type parameter

The extreme cases of this kind of namespace are Common Lisp, where you can add your own namespaces of this kind to the language (and Common Lisp already has five or six of its own built in), and, at the other end of the spectrum, Scheme, which has one namespace for everything.

These are also namespaces, but the operations on namespaces that we define next make no sense on them.

Returning to our namespaces for encapsulating bindings in code, there are a clear set of operations to support. We must be able to import the bindings from one namespace into to another, we must be able map a namespace into another with all its bindings qualified, typically by a prefix, and we must be able to extract a subset of a namespace.

These operations don’t always map directly to a language’s primitive constructs. I have chosen them because they are easy to write as functions with clear algebraic laws relating them. In Python they correspond to:

# Attach all bindings in X to the current namespace. from X import * # Attach a subset {a, b, c} of the bindings in X # to the current namespace. from X import a, b, c # Qualify namespace X with prefix 'X.' and attach it # to the current namespace. import X # Qualify namespace X with prefix 'Y.' and attach it # to the current namespace. import X as Y 

In C++, any namespace in scope is attached to the current namespace, qualified by the name under which it is in scope. The other operations correspond to:

// Attach an in scope namespace X qualified by the prefix Y. namespace Y = X; // Attach namespace X to the current namespace. using namespace X; // Extract a subset {a, b, c} from the namespace X and attach // its elements to the current namespace. using namespace X::a; using namespace X::b; using namespace X::c; 

Modules

Modules, strictly speaking, are aspects of program design, not programming language design. A modular program is one made of distinct parts that can be reasoned about, manipulated, tested, and replaced without touching the rest of the program. It’s a fascinating problem, and the best advice I have yet seen on it is from David Parnas’s 1972 paper “On the Criteria To Be Used in Decomposing Systems into Modules”: “…one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we the assumption that a module is one routines, and instead allow subroutines to be assembled collections of code modules.”

That being said, a programming language and its community can have tools to declare and enforce modules once they have been designed. Since we are talking about tools to support design, there isn’t a clean, mathematical formulation here as there is for namespaces or compilation units. There are certain properties that have showed up in tooling to support modular design in various languages, and I cannot offer much more than an enumeration of those I have recognized:

Visibility

One of the simplest ways to enforce a module’s boundaries is to make its internals unreferencable from outside. For example, the method getInput in the Java class

class ReaderModule { ... public Stream getInput() { ... } ... } 

could be reading from a file, a network stream, or generating random data without reference to the outside world. If there is no other information available than that its return type is a Stream, any other code using this class cannot depend on the module’s internals simply because there is no way to refer to them. Similarly, the internal functions to manipulate or examine data structures may be hidden. If the right bindings are hidden, it makes the values and behavior of a module inscrutable from the outside.

Most languages in use today have some constructs to control visibility, such as scoping of local variables, namespaces, and private/public declarations on class fields and methods. In C, top level bindings in a compilation unit that are declared static are visible only in that compilation unit. C++ inherits this ability, though in some circles it is eschewed in favor of anonymous namespaces, the contents of which are visible outside of the namespace in the same compilation unit, but not in other compilation units. In Python, any binding prefixed with an underscore is (by unenforced convention) private. Common Lisp also lets any binding be declared private, though it uses a distinct syntax to override the private declaration and access the binding instead of a naming convention.

Parameterization

It is a common pattern for one module to be parameterized over another. A stream transformer may be parameterized over a stream type. A queue may be parameterized over the type of its contents. So we might have functions on a stack in Haskell with the types

push :: Stack a -> a -> Stack a pop :: Stack a -> a empty :: Stack a -> Bool 

Looking at these functions, it is clear that the stack is parameterized over the type of its contents. A few languages allow that parameterization to be declared once and for all, as in SML, where the module declaration for the stack might be written

signature STACK = sig type 'a stack val push : 'a queue -> a -> 'a queue val pop : 'a queue -> a val empty : 'a queue -> bool end 

Other parts of the program refer to a parameterization of the module. Most of the common uses of parameterized modules and the manipulations of them available in SML are handled more simply with constructs like Haskell’s typeclasses, but the notion of declaring parameterizations at this level is worth knowing about.

Contracts

The simplest case of a contract is compile time type checking, as in the C function

double square(double x) { ... } 

This function always takes a double and returns a double. The compiler can check that this is true in most cases (though not when pointers are involved, or the signature of qsort,

void qsort(void *base, size_t nel, size_t width, int (*compar)(const void *, const void *)); 

would be useless). Modern type systems have pushed this much further, until in recent languages like Agda, the compiler can assert the type of every expression in the program at compile time, without the gaps that C has around pointers, and the types can express details such as the lengths of lists or the dimensions of matrices. Actually, Agda’s type declarations are themselves a Turing complete language.

Compile time isn’t the only time to check assertions. For decades, the mathematics wasn’t in place to do very sophisticated contracts in the type system, so some languages, beginning with Eiffel, added run-time contracts. Here is an example of a contract in PLT Racket for an absolute value function:

(-> number? ; Constraint on the input (and/c number? (or/c positive? zero?))) ; Constraint on the output 

How Ruby does it

Ruby’s compilation unit is a single file. The language’s support for modular programming is restricted to providing the keywords public, private, and protected to control visibility of methods defined on modules and classes. We saw in the section on interfaces that the libraries in the language make using visibility and parameterization to enforce module boundaries unnecessarily difficult.

The Ruby community uses a language construct called module for namespaces, as well as for mixins. Like C++, any Ruby module in scope is attached to the current namespace qualified by the module’s name. Ruby modules can be attached to other modules, and qualified by assigning them to a different variable, but they cannot be subsetted, nor do they have the relocatability property, since

def f() puts "Hello" end def g() f() end g() 

must be changed to

module Something def self.f() puts "Hello" end def self.g() f() end g() end 

and

def f() puts "Hello" end class A def g() f() end end def g() f() end A.new().g() g() 

cannot be put in a Ruby module at all.

Multiplication of like things

The phrase “orthogonal” is often bandied about in praise of programming languages, but what does it mean and why is it desirable? Consider pointers and references in C++. They are similar in that both are a way of passing parameters by reference, so

void increment(int *n) { *n += 1; } 

and

void increment(int &n) { n += 1; } 

do exactly the same thing. They differ in that pointers may be assigned to point to new memory locations, may be incremented and decremented to shift the memory they refer to, and they must be dereferenced in order to access the values they refer to. References are used like local variables, and the memory they refer to is fixed at their creation. The semantics of pointers and references overlap, though they have their differences, so we say that they are not orthogonal.

Another example is the distinction between superclass and interface in Java. Both are used to provide polymorphism (any subclass of A can be used in a function that takes an argument of type A, and the same is true of interfaces). But superclasses may provide implementations of methods that their subclasses will inherit, while interfaces may only declare that implementing class must define a given method with a given signature. Though the two concepts are not orthogonal, they let Java retain the simplicity of single inheritance (since inherited methods can only be inherited from the superclass), but interfaces also give it the polymorphism of multiple inheritance while avoiding its complexities (which are principally how to order calls to superclass methods).

Similarly, having both pointers and references in C++ is a tradeoff. C++ inherited pointers from C. The language was originally conceived of as a superset of C, so pointers had to stay. Yet pointers are a source of a disproportionate number of the errors in C programs. References fill one of the most common uses for pointers while avoiding all the errors that were possible with pointers, and so they were incorporated.

Now that we have established what it is, what makes orthogonality desirable? Simply that humans are good at memorizing how very distinct things work, but bad at keeping the details of similar things straight. No one confuses for loops and variable assignment, though both create a binding of a certain value to a name. They are as hard to confuse in your memory as a small Chinese woman with a giant black man.

Beyond that, nonorthogonal concepts are not intrinsically bad. C++ references and Java interfaces are both clever, useful solutions. Nonorthogonal concepts become a problem when they become a significant mental task for a programmer to disentangle. Beyond that, they can be a symptom of problems that arose in the course of in language design. Language designers don’t set out to incorporate nonorthogonal constructs in their language. Once the outline of the language is established, problems will rear their head in the details. It is resolving these details that leads to the addition of nonorthogonal concepts.

Ruby has accumulated a number of nonorthogonal concepts which significantly burden the programmer.

There are two methods to attach a module to the current context. extend adds the methods in a module to the current object; include adds them to whatever will be created by object’s new method. So in a class, include adds a mixin’s methods as class methods. extend adds a mixin’s methods as instance methods to the objects a class creates. For a non class object, include adds methods to it, and extend shouldn’t do anything at all.

Ruby has four notions that resemble a function: methods, blocks, procs, and lambdas. Methods are hunks of code that can be executed by sending messages to objects, and that terminate their execution and return to the message sender when the return statement is called. A block is a hunk of code, derived in analogy with Smalltalk, but unlike Smalltalk, where a block is a function and is the only form of function in the language, a block in Ruby is not usable directly. It has to be wrapped in a proc or a lambda, which differ in how they handle omitted arguments and how return behaves in them. Procs fill in default values of nil for omitted positional arguments (so if I call a three argument proc with two arguments, the third will be bound to nil in the body of the proc). Lambdas do not. The return statement of a proc returns from the next enclosing method. The return statement of a lambda returns from the lambda itself. And methods turn out to be a different type equivalent to lambdas plus names.

Ruby also provides two exception handling systems, identical except for their intended purpose. raise/rescue is meant for normal exception handling, but it has become a proverb not to use exception handling for control flow, since it is hard to understand and reason about code that does so. In Ruby this reason was apparently forgotten, but the letter of the proverb was obeyed: a separate system of throw/catch was created for control flow.

None of these justifies the mental burden they place on the programmer.

MN vs. M+N and what it did to the language

Smalltalk was the first object oriented language. It was built around the notion of objects which received messages and executed blocks of code in response. That is the underpinning of most object oriented languages to this day. However, there is a basic problem with it in practice: how do you write a polymorphic max function? That is, a function that takes two arguments of the same type and returns the larger of the two, ordered according to whatever ordering the type defines. In Smalltalk, you must define it on every class that you want it to have, which leads to an enormous amount of repeated code. This is true of any other algorithm you want to work on a given type, so for M algorithms and N types, you end up writing MN methods.

This has been solved in various ways. Common Lisp’s CLOS, and its descendents such as Dylan removed messages and instead defined generic functions. Each generic function could have multiple implementations, and which implementation was used was chosen at runtime based on the types of the arguments passed to it. This led in turn to the key insight of Stepanov’s Standard Template Library: you can separate iteration strategies from algorithms. For each of the N types you implement its iteration strategy, and you implement each of the M algorithms in terms of that strategy. Result: you write M+N methods.

The other major solution was to keep message passing and add multiple inheritance. This let programmers inherit from both the natural superclass of a class and also from a class carrying implementations of the various methods, though it adds its own complexities over how to order calls to superclass methods.

Ruby took the multiple inheritance route, but not openly. Instead it retained single inheritance from a superclass, introduced a new inheritance hierarchy of Ruby modules, and provided two separate mechanisms, include and extend, to have a class inherit from them. Now you must memorize how inheritance and Ruby’s two mixin expessions, include and extend, interact as well as how they order calls to superclass methods.

Tooling and reasoning

Most programming communities have their expectations about what tools are necessary and what are frivolous, and there is no core that every community would agree on as necessary. Turbo Pascal programmers assumed that an integrated debugger was a basic tool of a programmer, but the term unit testing did not exist yet. Python programmers today regard integrated debuggers as a luxury, but a unit testing library as a necessity.

There are a number of language agnostic tools—version control systems, build systems, literate programming tools—but beyond that the tooling which can be straightforwardly built in a language depends on two things: how easy the language is to parse, and how easy code in the language is to reason about.

Parsing is an old and largely solved problem. We know how to define unambiguous grammars that are easy and fast to parse. ALGOL 60 already had a mature, precise specification of its grammar, and most of the imperative languages that followed it were at least straightforward to parse. C, for example, is harder to parse than Lisp, but not terribly onerous. C++, unfortunately, is a nightmare to parse.

For many languages, such as Lisp and recent versions of Python, the live instance will parse code for you and return an abstract syntax tree, further reducing this burden.

How easy a language is to reason about is roughly equivalent to how rich a set of program transformations it supports. Some of these transformations are program preserving, ranging from from renaming a variable in the source code, to converting programs to continuation passing style and all the other tricks of writing optimizing compilers.

Others transform the program to other useful forms. Transform the code into a list of all the entities defined in the program and what regions of code they correspond to and you have the underpinnings of a code browser. Transform it to a simplified, decidable execution model where common errors can be detected without running the program and you have a static analysis tool. Alter the code to track what parts are run and what are not when exercised by a test suite and you have a code coverage tools. Mutate the code randomly when it is exercised by a test suite and you have a measure of how incisive the tests really are.

These transformations are also what a programmer does in his head when he reasons about code, so how easy code in a language is to reason about is equivalent to how easy it is to write tools in the language.

Ruby has no well defined grammar. All the Ruby implementations today reuse Matz’s original parsing code. There are various BNF grammars people have written for the language, but they may or may not match the actual implementation. Nor does Ruby provide a mechanism to turn code into an abstract syntax tree for you as Python and Lisp do. Anyone writing tools beyond a unit testing library must solve this problem first, before ever doing any real work.

Reasoning about Ruby is not much better, and the tools reflect this. There are a plethora of unit test libraries ()all incompatible). Beyond that there is a single code coverage tool providing line coverage, but not branch or instruction coverage, and which will ignore large hunks of code if not configured perfectly, including having the order of require statements in a file be just right. There are a handful of static analysis tools which have the insight you would expect from the first prototype of lint written over a weekend in the 1970′s. There is a debugger that may or may not skip the body of a loop when single stepping through, depending on how the loop is written, and may or may not crash, and usually fills the console of any frontend its is hooked to with garbage so that any console output of the program itself is obscured. And that’s it. The Ruby tool ecosystem.

Summary

The criticisms above are not matters of taste. They are errors in language design. Unrelocatable namespaces are an error. Introducing three separate methods for inheritance and a separate inheritance hierarchy when multiple inheritance was well understood before Ruby’s initial creation is an error. Documentation so sparse that its reader must turn to reading the source code instead is an error.

If Ruby were the only language in its niche, these errors might be tolerable, but it is not. So let me make my position on the language clear: Ruby is deprecated. Let it follow Perl into the dustbin of language history.

Appendix: Documentation conventions

C programmers on Unix-like systems

There are many communities of C programmers—C programmers in Microsoft’s ecosystem, in the Macintosh ecosystem, those who worked in Borland’s Turbo C, those who write for Unix-like systems—and these communities are distinct and have their own conventions for documentation. For those who work in the only community around their language of choice, such as PHP, or in the presence of slightly fragmented subcommunities, such as the scientific community centered around NumPy and SciPy in Python, this will seem strange, but a Windows C programmer would be quite lost on a Unix-like system and in the surrounding community, and vice versa. This section is concerned with the community of C programmers writing for Unix-like systems.

The community writing for Unix-like systems in C has memorized their core language, which is quite small, and almost never refer to a language reference, though such programmers usually have a copy of some C textbook, and one or more books on Unix-like systems (Stevens and Rago’s Advanced Programming in the Unix Environment or its ilk).

The community’s reference material is divided into man pages, which are read on text mode terminals. Each man page describes a small set of related functions, such as all the variants of printf or fork, and the pages are organized in a fixed way. The man page of fork is typical:

FORK(2) BSD System Calls Manual FORK(2) NAME fork -- create a new process SYNOPSIS #include <unistd.h> pid_t fork(void); DESCRIPTION Fork() causes creation of a new process. The new process (child process) is an exact copy of the calling process (parent process) except for the following: o The child process has a unique process ID. o The child process has a different parent process ID (i.e., the process ID of the parent process). o The child process has its own copy of the parent's descriptors. These descriptors reference the same underlying objects, so that, for instance, file pointers in file objects are shared between the child and the parent, so that an lseek(2) on a descriptor in the child process can affect a subsequent read or write by the parent. This descriptor copying is also used by the shell to establish standard input and output for newly cre- ated processes as well as to set up pipes. o The child processes resource utilizations are set to 0; see setrlimit(2). RETURN VALUES Upon successful completion, fork() returns a value of 0 to the child process and returns the process ID of the child process to the parent process. Otherwise, a value of -1 is returned to the parent process, no child process is created, and the global variable errno is set to indi- cate the error. ERRORS Fork() will fail and no child process will be created if: [EAGAIN] The system-imposed limit on the total number of pro- cesses under execution would be exceeded. This limit is configuration-dependent. [EAGAIN] The system-imposed limit MAXUPRC (<sys/param.h>) on the total number of processes under execution by a single user would be exceeded. [ENOMEM] There is insufficient swap space for the new process. LEGACY SYNOPSIS #include <sys/types.h> #include <unistd.h> The include file <sys/types.h is necessary. SEE ALSO execve(2), sigaction(2), wait(2), compat(5) HISTORY A fork() function call appeared in Version 6 AT&T UNIX. CAVEATS There are limits to what you can do in the child process. To be totally safe you should restrict yourself to only executing async-signal safe operations until such time as one of the exec functions is called. All APIs, including global data symbols, in any framework or library should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe. If you need to use these frameworks in the child process, you must exec. In this situation it is reasonable to exec yourself. 4th Berkeley Distribution June 4, 1993 4th Berkeley Distribution 

A skilled C programmer in this community can find what he needs in these strictly formatted pages with great speed, and documents his own libraries in the same way. The Perl community—Perl began life as a normalization of the diverging scripting languages associated with shells across various Unix-like systems—inherited this tradition.

The exception to this pattern is the GNU project. Richard Stallman came from a Lisp background, which had a very different tradition, and brought that tradition with him. Thus GNU software in this community tends to have both man pages and the long form manuals more typical of Lisp.

Both the man pages and the GNU manuals are independent documents. They are usually kept in a separate directory from the code, and compiled for viewing with entirely separate tools. The correspondence between the man pages and the source code is maintained by hand. Comments in the code are to understand its workings. Its purpose and intended behavior are recorded in the (separate) documentation.

Common Lisp

Common Lisp is a language with a single community. Indeed, the language was a political compromise meant to unify a number of divergent Lisp communities with shared interests. The compromise defined the language in great detail, from the branch cuts of the numerical functions over complex values, to the interface to the debugger, to standard ways of controlling whether code was to be compiled or interpreted, and the Common Lisp community is nearly unique in that their standard is their primary reference documentation while they work. If their particular implementation does not match the standard, it is expected that the vendor will fix the implementation rather than the programmer work around it.

Third party libraries in Common Lisp have similar manuals. Vendors provide such manuals for their extensions. The culture thinks in terms of coherent, book-like documentation, in contrast to the man pages of the C community on Unix-like systems described above. Indeed, a few still use a hard copy of Common Lisp, the Language, 2nd ed. as their reference, though most of the community uses the HTML based Common Lisp Hyperspec.

The manuals in Common Lisp are entirely separate from the code, but the language defines “docstrings”: the first expression in a Common Lisp definition, if it is a string, will be taken by Common Lisp systems to be documentation for the definition. A docstring is accessible by asking a running Common Lisp system for the docstring of a definition loaded into it:

(defun square (x) "Return the square of x" (* x x)) (documentation #'square 'function) ; Evaluates to "Return the square of x" 

Docstrings in the Common Lisp community don’t have as fixed a structure as man pages, and often have a much narrower scope, since there tend to be separate manuals describing how to use the system.

Python

Python occupies a middle ground between the Common Lisp community and the C programmers described above. The core language and standard library are documented in a series of HTML pages similar to the Common Lisp Hyperspec. The documentation usually begins with enough exposition to understand the topic at hand, followed by reference documentation for the public functions and classes provided. Unlike Common Lisp, the documentation is specific to each version of Python.

Also like between Common Lisp, Python has docstrings, which are again a string as the first expression of a definition, as in

def square(x): "Return the square of x." return x*x print square.__doc__ # Prints "Return the quare of x." 

Unlike in Common Lisp, the docstrings are not only accessible in the running Python instance, but are are extracted into the HTML manuals, so there are conventions governing their form and how they will be formatted for extraction. The most basic is that the docstring should begin with a quick, one line description, followed by a more comprehensive one (this convention was inherited from the Lisp community via Emacs Lisp).

Java

Like Python, Java puts its documentation into its source and uses tools to extract it into manuals. Unlike Python, it uses comments prefacing definitions to document them, as in

/** * Return the square of x. */ public static double square(double x) { return x*x; } 

This documentation is lost in compilation, so the extracted manual is the only reference. There is nothing equivalent to looking up a docstring in a running Python or Common Lisp instance. Like Python, there are strict conventions for organization and formatting the documentation.

Unlike Python, the manuals tend to be only API documentation, with very little exposition. Java libraries tend to have separately written tutorials to teach a programmer enough about the library that he can hopefully figure out whatever else he needs from the API reference.

R

R is an interactive language with a lineage going back to Bell Labs, the home of Unix, so it is no surprise that the documentation of its functions is nearly identical to man pages (though typeset in Rd, a language resembling LaTeX, instead of in groff), but accessed from within R itself. R itself also has a number of long form manuals introducing the language, specifying its grammar, and covering certain major areas such as importing data or writing extensions.

The general statistical community around R documents its libraries in the same way—man pages plus, sometimes, longform manuals covering particular areas—but there is a second, increasingly separate subcommunity centered in bioinformatics around the BioConductor libraries, which has a completely different documentation tradition. BioConductor eschews R’s online references and instead produces “vignettes” for its various packages. A vignette is PDF file with a few paragraphs explaining the library, some annotated code examples to quickly get started, and some terse reference documentation of the most commonly used functions in package.

TeX

Donald Knuth’s TeX language is meant for typesetting documents, so it is no surprise that it has an interesting documentation tradition. Indeed, I mention it to describe the logical conclusion of automatically extracting documentation from programs: literate programming. Knuth, who is concerned with producing code to be used and read for decades to come rather than years to come, proposed writing a document that happened to contain a program in it that a tool could extract to a compilable form, and this is exactly what he did with TeX.

The code need not be organized linearly in the document, nor kept together in any particular way. Blocks of it may be defined anyway and glued together elsewhere. Here is an example taken from the port of the wc command to the noweb literate programming system:

Here, then, is an overview of the file <tt>wc.c</tt that is defined by the <tt>noweb</tt> program <tt>wc.nw</tt>: <<*>>= <<Header files to include>> <<Definitions>> <<Global variables>> <<Functions>> <<The main program>> @ We must include the standard I/O definitions, since we want to send formatted output to [[stdout]] and [[stderr]]. <<Header files to include>>= #include <stdio.h> @ 

Then, Friday morning, one of my pals from Switzerland messaged me, saying that someone had posted it to reddit’s bioinformatics subgroup, asking what people think about it. It was the first item for a couple days.

From there it went to Hacker News and sat at the top of the front page for hours. Other fora picked it up. I got emails from their moderators asking me to come take part in the discussion, and I lots of email from people who just wanted to talk to me directly.

If you look at the fora, you will see lots of negative comments. I didn’t get a single negative email. This struck me as strange, so I went back and counted up all the positive, negative, and neutral comments and emails.

The three neutral email were two people inviting me to take part in discussions (which is how I found the discussions on Biostars and Hubski), and one which contained only the line “sent from my iPad”. The neutral comments on forums were largely side discussion. Interestingly, the mixed or primarily programming fora (Hacker News and Hubski) had about equal numbers of positive and negative comments. The bioinformatics specific fora (BioStars and the reddit subgroup) were very negative.

The negatives all followed certain themes. Many were ad hominems: “From looking into this guy a bit (who I’ve never heard of before today in my 10+ years in the field)…it does not appear that he completed his PhD after several years of work”; “Sounds like a fed up academic with a stick up his backside.” There were lots of implications that I didn’t know biology, didn’t know the state of programming in the non-academic world, didn’t know bioinformatics, etc.

A number were strawmen. One did try to claim I was wrong based on my own words (“There are only two computationally difficult problems in bioinformatics, sequence alignment and phylogenetic tree construction.”), but when asked for another, all he could offer was genome assembly, which is a special case of sequence alignment. One amusing strawman took umbrage with my use of the word “ept”, claiming it didn’t exist. Someone did eventually post the reference to the OED entry.

Others took issue with my tone, saying that it was unacceptable to address people this way, but there was no substantive criticism in public, and no criticism at all in private. That means these people weren’t concerned that I was wrong, or at least had no stomach to send me a criticism without some kind of public setting where they would be part of a group. Indeed, the original poster on reddit, who was worried as he was about to start a PhD in bioinformatics, didn’t receive an actual answer.¹

There’s a name for this in circles that study human behavior: group monkey dance. You should follow that link and read Rory’s article on it, and probably Rory’s books, too, but here’s a quick summary: human violence follows patterns. Most fist fights occur in the same way. Married couples will have the same arguments year after year. And social groups will turn on an outsider or perceived betrayer with a brutality that most of the group members would never display individually.

In this setting, a group monkey dance would have emotional outbursts against the transgressor (me), with repeated themes and short on rational argument, which is exactly what we find. Most of these people are folks I could sit down with an have a sensible conversation about bioinformatics. However, I attacked the group which they have made a part of their identity and triggered a group monkey dance.

So what has this whole debacle taught me is that public comment fora encourage group monkey dances, and thus reduce the quality of the discourse on the Internet. For the moment I am setting a policy for myself: I am not participating in public, unmoderated fora. I encourage everyone else to do likewise.

¹ I tried to send him something useful by private message, which I’ll reproduce here for anyone else who may be similarly disturbed:

Hi, I’m the author of the piece. A colleague of mine still in the
field pointed out that someone had posted it to reddit. I have no
intention of engaging with the comment thread, but I thought I’d drop
you a private message.

If you notice, no one provided any substantive criticism of what I
said, no refutation of my points. There were a few strawmen, a few ad
hominems, but no one addressed my actual words. If they’re words that
would make you want to not do a PhD, then you need to address that.
Figure out what the parts are that unsettle you (aside from the tone,
which was intentionally strident), and go independently find an
answer for yourself. The exercise will, at the very least, give you a
useful overview of some of biology. (As a similar exercise, try
writing a history of the future of the field over the next 50 years.)

Whether you decide to do your PhD or not, this is useful. If it leads
you to do something else–and you should plan on what you’re going to
do when you leave academia, since the data says you will, like almost
everyone else–fine. If it leads you to do your PhD, you’ll have a
perspective that you can use to choose what you’ll specialize in, as
opposed to randomly fall into it.

If you do the PhD, though, I warn you: use the perspective to cut
areas out that don’t interest you, but choose based on the professor.
Your advisor, whether you trust his scientific taste, his
personality, and his skill as a mentor, should be almost the only
criterion in your selection of your research in a PhD. Look at his
students. Are they happy, healthy, making progress? Do they respect
him? What about his former students?

Good luck to you either way.

You’re asking the wrong question. This is understandable, since the skill level of the bioinformatics community is so low that most of them ask the same wrong question. I’ll even answer it: PLT Racket is the best source to learn to program today. But it’s still the wrong question.

Here’s the right question: “What do I need to learn to be able to effectively use the computer as a tool to do biology?”

Part of the answer will depend on what you’re kind of science you’re trying to do, but some topics will be absolutely universal.

You need to learn a general purpose programming language. Here, I’ll teach you Scheme: (function argument argument argument …), and that form can go anywhere in each of those slots. For example, (+ 2 2), (+ (* 3 3) 1), ((if (> 2 3) + -) 1 1), (define (square x) (* x x)), (square 4). Congratulations. You can learn other languages when you need them. Languages come and languages go (well, except Common Lisp and FORTRAN), and you use what you want.

You need a basic knowledge of data structures and algorithms: big-O notation, singly and doubly linked lists, arrays, binary and n-ary trees, and hash tables. You need to know what a hash function is and why they work. You need to know the general operations for manipulating these data structures, and what they’re called in your language. You need to know how sorting works (though you needn’t implement it yourself) and searching on the various data structures. You need to know about the vagaries of floating point, and how to do basic root finding and minimization (Acton’s ‘Real Computing Made Real’ is the best source I know of for this), and how to design and write these algorithms by hand. You must know how pseudorandom number generation works, and have a good generator on hand. The Mersenne Twister is the day-to-day state of the art at this point. You need to know how Monte Carlo methods work, and how to generate random data (a.k.a., simulation).

You need to know how data is represented in the computer. What are bytes and words? How are characters represented? What are the different kinds of integer representations and floating point representations? How are enumerations and symbols represented? How are more complicated data structures like structs laid out in memory? How are the representations laid out in binary file formats? (Hint: binary files are not black magic, they’re just more data as represented in memory). You need to know the difference between machine code and byte code, compilers and interpreters, and what the relative benefits of each are (note that compilers can be interactive and interpreters batch only — ignore any assertions to the contrary).

You need to understand recursion and the design of loops via preconditions, postconditions, and loop invariants.

You need to understand relational algebra and be able to manipulate relational databases (SQLite is a good place to start). You need to know what memoization is, and how to implement various forms of it. You need to know how to produce 2D graphics in a clean, composable way, such as recognizing that the data area of a chart represents a new set of coordinates that you’re transforming to. You need to be able to send and receive HTTP requests, that is, opening a port and sending and receiving messages according to a fixed protocol. You need to be able to write a parser for a file format that isn’t a bunch of hacked-together regular expressions (go look at Haskell’s Parsec — write one for your language). You should understand what Prolog is, how to write in it, and how to [implement](http://okmij.org/ftp/Scheme/sokuza-kanren.scm) a simple one yourself.

You need to be able to produce correct programs. This means knowing what each part of your program is supposed to produce for some cases, being able to easily check that easily (best is stating invariants that another program checks by generating increasingly huge random cases — see QuickCheck), and being able to reason your way to where the error is in your program rather than trying things at random.

Oh, and learn a modern version control system: git or mercurial. If someone around you already uses one of those two, use what they’re using. Otherwise, flip a coin.

Those are the universals that will make the computer into a tool for you. Seem like a daunting list? It’s actually not nearly as bad as it looks, trust me. But what about your science? That’s the goal, remember: use the computer as a tool to do science. Not as a tool to move data from one file format to another (after you learn about representing data in the machine, you’ll understand that all file formats are arbitrary). Not as a tool for connecting to NCBI or EMBL or anywhere else. A tool to do science. Don’t lose sight of that fact. Most bioinformaticists spend between 90% and 100% of their time just messing with file formats. It’s not science.

Now, to recommend where you go next, you’ll need to talk about what kind of science you want to do.

I’ve talked with more people than I usually do in a month. It’s run me thin.

II.

The most visible lack among attendees is historical ignorance of our not-very-old field: rumblings among the NoSQL adherents during Stonebraker’s talk on VoltDB, not realizing that he has experience implementing databases comparable to the whole NoSQL community combined; Orenstein and Hernstadt reinventing the tree database with a relational adaption layer, not realizing that they were recapitulating something abandoned in the 1980’s, and looking surprised when part of the audience told them openly that ORMs are a terrible idea; the Bandicoot team during the emerging languages camp, reimplementing capabilities already in PostgreSQL, apparently driven by no more than a need for a C-like syntax.

Codd’s relational model was an upstart in a market of graph, object, tree, and various hybrids and other exotic databases. I do not claim that it the relational model is superior because it survived. Most entrenched artifacts of computing are fixed by social factors, not technical ones. The relational model is superior because it described the semantics a data store needed to specify for most real world use; made the translation of declarative queries into operations a finite, approachable problem; and unified all the expressive power of the other kinds of database in a single mathematical model. SQL, the language, was the result of a natural language project at IBM. It is not intrinsic. The underlying model, as Codd defined it, is intrinsic.

Puzzlingly, while we regard a programmer ignorant of the difference between an array and a linked list as incompetent, one ignorant of the relational model can bluster his way into respect from his colleagues.

III.

When I was a teenager, I suffered from an overabundance of generalizations. Years of experience have beaten them out of me. I still looked back on them with some chagrin. I’m not unusual. So why do the young spout generalizations? They imitate what they perceive their elders doing.

The problem is the perception. Their elders have either become snake oil salesmen or are chagrined at their own youth and focused on technical material. However, a mind with ten additional years of training and ten additional years of experience can make much more general statements while remaining, in its own conception, precise, technical, and on firm ground. Ten years, twenty years, thirty years, and at some point the generalizations start to seem like magic to those starting out. They are perceived as generalizations, though they are precise statements.

My advice to the young: present hard, technical material that you understand intimately. My advice to the old is the same.

IV.

Rich Hickey is engaged in the semantic terraforming of the JVM. The language has fallen beneath his juggernaut, and he has rolled on to the database. Go Rich!

V.

Spend half an hour with Elm for the sheer pleasure of seeing a functional reactive programming environment in the wild. Spend half an hour with Julia and mourn for the pain of physicists and engineers who have suffered MATLAB and its kin down through the years.

VI.

What do you mean you don’t know about unification? Go learn to write a Prolog!

VII.

Please stop recommending anything besides PLT Racket and ‘How to Design Programs’ for new programmers. Just because you wasted time when you were learning doesn’t mean everyone else has to. And if you prototype new languages in anything else, you’re a fool.

Oddly, it’s also the easiest environment to create stand alone, cross platform GUI applications in that’s available today.

VIII.

The 800lb gorilla in the room: JavaScript. We all know that it has to die. It speaks to our ignorance of the social processes governing our field that we have no idea how to go about killing it.

Of course, the model is wrong. To paraphrase Box, “all models are wrong; some are useful”. This one is useful in a limited way: it makes explicit the vast gaps between how different programmers think about programming. The observations that led him to this model are extremely valuable.

But given those observations, I think we can have a much more useful model, one that has both better descriptive power and eschews the loaded terms “conservative” and “liberal”.

Digression: Don’t build models in analogy to political spectra. The notion of a political spectrum is actually quite recent, dating from the French Revolution. In the meeting of the estates general, the third estate sat to the left of the entrance; the first and second estates sat to the right. Thus we have the political left and the political right. Prior to that, the closest thing to a spectrum we had was the Guelphs versus the Ghibbelines in Renaissance Italy. The political spectrum in France led to one side killing everyone in the other side. No use of it or analogy to it since then has been noticeably more productive. Using it is a good heuristic that your model could be profitably reformulated. End Digression.

I’m going to shamelessly steal Scott McCloud’s Big Triangle model. You should go read his presentation. It’s a brilliant piece of work and will forever change how you think about graphic arts. Then go buy his book Understanding Comics. Trust me. It’s worth every penny.

The model space is, appropriately, a big triangle:

The programmers who fall along the left side of the triangle think in terms of specification. They are writing instructions in a language with semantics. Those instructions result in actions when executed by something that obeys those semantics.

Programmers along the right side think in terms of behavior. There is some real system with which they interact to cause certain behaviors. They have a mental model of the system which guides them, but in the end the units of their thought and action are behavioral actions.

Languages are designed to support certain areas of the triangle. Haskell lies not too far from the specificational side, and theorem provers like Coq and the dependently typed languages like Cayenne approach it. Assembly is on the behavioral side by definition (unless you’re an electrical engineer, in which case it’s pretty far towards specification).

However there are very different levels within this. Lambda calculus is an assembly language for a very certain kind of a machine, but placing it near the machine instructions for an Intel processor is somewhat ludicrous. This leads to our vertical axis: the farther towards the upper point someone lies, the more abstractly mathematical their thought about computing.

This may be better phrased as how much they regard entities in the machine as immutable artifacts. A non-programmer, on the bottom side of the triangle, must accept the specified interaction modes of his machine as artifacts which he cannot change. Systems administrators live a few steps up, still primarily in the world of artifacts. Most programmers live in a world where something things are artifacts and some aren’t. For many, languages are artifacts they regard as immutable, but go talk to a compiler specialist or a smug Lisp weeny, and languages become mutable thoughtstuff. Go farther up and the machine, and even what logic you work in, become mutable things at the mercy of the programmer’s mind.

And now we come to why it’s a triangle. The gap between a specificational systems administrator and a behavioral one is vast. A specificational one will work entirely through Chef and Puppet, Fabric to bring up machines, a whole layer of programs meant to provide a semantics in which he can specify his systems. A behavioral one logs into each machine and runs shell commands on it, possibly collecting his commands into scripts. At the top of the triangle, a computational theorist working on higher order logic has no difference between specification and behavior. The question makes no sense for him.

So to summarize,

$startPage = [ (currentPage - \lceil window/2 \rceil + 1) \ \downarrow \ Npages - window ] \downarrow 0$
$endPage = [ (currentPage + \lfloor window/2 \rfloor + 1) \ \uparrow \ window] \downarrow Npages$

where

• currentPage is the currently displayed page.
• window is the number of page numbers to display in the widget.
• Npages is the total number of pages.
• $\lceil \cdot \rceil$ is the ceiling function.
• $\lfloor \cdot \rfloor$ is the floor function.
• $a \uparrow b$ is the maximum of $a$ and $b$.
• $a \downarrow b$ is the minimum of $a$ and $b$.

That’s the short version. Now how do we derive that?

First, a warning. Don’t use page numbers as primitive objects unless you’ll only have one item per page. If you’re going to list multiple items per page, tracking page numbers instead of the first item to display on a page will make your code unbelievably complicated when you have to change the number of items displayed per page, or when you want to show a list of items beginning with a specific index, rather than a particular page.

So label your items from 0 to $N$, and let $currentItem$ be the index of the first item to be displayed on the current page. If each page is to show at most $pageSize$ entries (“at most” because there may not be enough items to fill the last page to exactly $pageSize$), then $currentPage = \lfloor currentItem / pageSize \rfloor$, and the $i$th page will start at $i \cdot pageSize$. There will be $Npages = \lceil N / pageSize \rceil$ pages in all.

Now let’s move on to deriving the expressions for the actual pagination range. What, precisely, is the problem? For a particular integer between $0$ and $Npages$, we want to find a range of numbers of a fixed size which also fall in $[0, Npages]$ and are as centered as possible around $currentPage$. As usual, we’ll describe the range as a half open interval by the first page in the range $startPage$ and one after the last page in the range $endPage$. For example, in “« 4 5 6 7 »”, $startPage = 4$ and $endPage = 8$. Let the size of the desired range be $window$.

$endPage – startPage = window$, but we need a second constraint to center $currentPage$ as much as possible in this range. If $window$ is odd, then we want the same number of entries on both sides of the current page number. For example, if we are on page 3 and $window = 5$, We should display “« 1 2 3 4 5 »”. If $window$ is even, we must make a choice: do we want to display more page numbers after the current one, or more before? I chose to show more numbers after on the theory that a user is more interested in stuff he has not yet reached. This constraint translates to $currentPage – startPage = endPage – currentPage – 1 – (1 – window \mathbf{mod} 2)$

So, centering the current page in the control, $currentPage – startPage$ should be one less than $endPage – currentPage$ since $startPage$ is the first element and $endPage$ is one after the last element. So if $window$ is odd, $currentPage – startPage = endPage – currentPage – 1$. If $window$ is odd, since I chose to show more following pages, it is $currentPage – startPage = endPage – currentPage – 2$. We can combine all these expressions to get

$currentPage – startPage = endPage – currentPage – 1 – (1 – window \mathbf{mod} 2)$
$window = endPage – startPage$

which we’ll solve for $startPage$ and $endPage$. We’ll be using three properties of the floor and ceiling functions in the calculations below, which I’ll summarize here:

$x = \lfloor x/2 \rfloor + \lceil x/2 \rceil$
$\lfloor x/2 \rfloor = x/2 – (x\ \mathbf{mod}\ 2)/2$
$\lceil x/2 \rceil = x/2 + (x\ \mathbf{mod}\ 2)/2$

We calculate thus:

$currentPage – startPage = endPage – currentPage – 1 – (1 – window \mathbf{mod} 2)$
$\ \wedge\ window = endPage – startPage$

$\equiv$ { solve first equation for $startPage$ and second equation for $endPage$ }

$startPage = -endPage – 2 \cdot currentPage + 2 – window\ \mathbf{mod}\ 2$
$\ \wedge\ endPage = startPage + window$

$\equiv$ { substitute $endPage$ for $startPage$ in first equation }

$startPage = -startPage – window – 2 \cdot currentPage + 2 – window\ \mathbf{mod}\ 2$
$\ \wedge\ endPage = startPage + window$

$\equiv$ { group $startPage$ and simplify first equation }

$startPage = currentPage – (window/2 + (window\ \mathbf{mod}\ 2)/2) + 1$
$\ \wedge\ endPage = startPage + window$

$\equiv$ { $x/2 + (x\ \mathbf{mod}\ 2)/2 = \lceil x/2 \rceil$ }

$startPage = currentPage – \lceil window/2 \rceil + 1$
$\ \wedge\ endPage = startPage + window$

$\equiv$ { substitute for $startPage$ in second equation }

$startPage = currentPage – \lceil window/2 \rceil + 1$
$\ \wedge\ endPage = currentPage – \lceil window/2 \rceil + 1 + window$

$\equiv$ { $x = \lfloor x/2 \rfloor + \lceil x/2 \rceil$ }

$startPage = currentPage – \lceil window/2 \rceil + 1$
$\ \wedge\ endPage = currentPage + \lfloor window/2 \rfloor + 1$

This works in the middle of the range. At the edges, we have to calculate a different window. The first page is 0 and can never be less. The last page $Npages-1$ and can never be more. At the left end, $startPage=0$ and $endPage=window$. At the right end, $startPage = Npages – window$ and $endPage = Npages$. We augment the expressions for $startPage$ and $endPage$ to handle these cases (note that the order of operations is important):

$startPage = [ (currentPage - \lceil window/2 \rceil + 1) \ \downarrow \ Npages - window ] \downarrow 0$
$endPage = [ (currentPage + \lfloor window/2 \rfloor + 1) \ \uparrow \ window] \downarrow Npages$

No. Absolutely not. Empirical evidence comes from doing the experiment yourself, or as close as you can get to it. If I take the average of the guesses of the peasantry as to the length of the emperor of China’s nose, why should I expect it to be at all related to the actual length? I should go and measure it myself. Or at least get his valet drunk and ask him if I can’t actually abduct the emperor, cut off his nose, and lay it next to a ruler myself.

The only empirical evidence that you can get from asking a peasant how long the emperor of China’s nose is, is what that peasant is willing to publicly state as his guess as to the length when asked by some random person he doesn’t know who’s bothering him out of the blue…and even that’s biased to peasants that will answer you as opposed to chasing you out of their field with a hoe.

As for the links you sent, unless you’ve actually read and evaluated the original papers, you can’t have a prayer of knowing what the truth of the situation is. Even if you read the original papers you may not, since they may all be unusable and broken. Actually, the majority of the published literature is. It’s all too easy to cherry-pick a few papers to support your position, just like you can round up all the folks who’ve actually measured the length of the emperor’s nose into a stockade and demand under a hot light that they tell you the result of their measurement, but it’s so easy to assume that those guys with the overly long measurements were just trying to tell you what you wanted to hear since you were applying the light pretty close to their pasty, white faces.

Want to have an informed opinion? Go cut off the nose yourself. Or go actually run your own experiment.

Obesity rates? Set up a survey sample. Hint: the proper way to do this is to intern the population of your test area, assign them numbers, pick at random from them (and make sure you weigh any who were shot trying to escape before disposing of the bodies, in case their numbers are picked), and then strip, hogtie, and weigh those selected. Unfortunately, this is illegal in the USA unless you’re only interested in numbers from those who are Japanese or black.

Autism-vaccine link? Go vaccinate a bunch of kids, and inject the others with water. Stick ‘em in isolation bubbles so they don’t die of anything, or you’re confounded by kids killed by stuff they weren’t vaccinated with. Be sure to have a lime pit on hand to dispose of the bodies of parents trying to rescue their kids. Warning: this kind of longitudinal study takes a great deal of time. A decade or so. Again, there are legal problems with this.

That is what I know about empirical evidence.

Let me begin with a series of exhibits of small scale prose style, taken from documents that I have read over the years and that I recalled as clear and informative. Each exhibit is a paragraph or two long, chosen more for its ability to stand alone than for any stylistic distinction.

Edsger W. Dijkstra, EWD1213: Introducing a course on calculi:

“The functions I grew up with, such as the sine, the cosine, the square root, and the logarithm were almost exclusively real functions of a real argument. Sometimes, but not very explicitly, the argument could be allowed to be a little bit more complicated, such as the maximum of two values, a real function defined on a pair of real values, or on two values: whether the maximum was a function of one argument (which had to be a pair) or was a function of two arguments (each of which was a real number) was a question that was avoided. We didn’t talk about the types of the function arguments, we did not talk about the types of the function values either: we did not need to, for to all intents and purposes, all our functions were of type real. (Later this was extended to the type complex, but that was about it.) The net effect was that I was extremely ill-equipped to appreciate functional programming when I encountered it: I was, for instance, totally baffled by the shocking suggestion that the value of a function could be another function.”

Richard Feynman, Cargo Cult Science:

“I think the educational and psychological studies I mentioned are examples of what I would like to call cargo cult science. In the South Seas there is a cargo cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they’ve arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas–he’s the controller–and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential, because the planes don’t land.”

Rob Pike, Notes on Programming in C:

“I argue that clear use of function pointers is the heart of object-oriented programming. Given a set of operations you want to perform on data, and a set of data types you want to respond to those operations, the easiest way to put the program together is with a group of function pointers for each type. This, in a nutshell, defines class and method. The OO languages give you more of course—prettier syntax, derived types and so on—but conceptually they provide little extra.

Combining data-driven programs with function pointers leads to an astonishingly expressive way of working, a way that, in my experience, has often led to pleasant surprises. Even without a special OO language, you can get 90% of the benefit for no extra work and be more in control of the result. I cannot recommend an implementation style more highly. All the programs I have organized this way have survived comfortably after much development—far better than with less disciplined approaches. Maybe that’s it: the discipline it forces pays off handsomely in the long run.”

OpenBSD man page for ln:

“The ln utility creates a new directory entry (linked file) which has the same modes as the original file. It is useful for maintaining multiple copies of a file in many places at once without using up storage for the copies; instead, a link “points” to the original copy. There are two types of links: hard links and symbolic links. How a link points to a file is one of the differences between a hard and symbolic link.”

The four passages are obviously written by different people, but examine them again. The similarity of the OpenBSD man page to Rob Pike’s style is unsurprising, since Pike was deeply involved in the early days of Unix. Feynman, though is as much of an outlier as I can think of. His passage is a transcription of a speech, with ‘So’s’ starting sentences are connectors, but examine the feel of it crossing your mind. It is technical prose uttered in a New York accent, but still English technical prose in technical prose’s singular style.

I encourage you to read the full texts from which my four excerpts are taken. They aren’t long. I believe one characteristic imposes this prose style more than any other: throughout each text, its author knew exactly what pattern he wished to conjure in his reader’s mind. Each eschewed jargon except well buttressed by a couple well chosen examples, since free floating jargon abdicates all idea of what the reader shall make of your text. The thought has been arranged into a set of sentences that take the reader nearly as directly as possible through it. The sentences are direct. At the end we are in no doubt what each passage says, though any paraphrase we make is likely to be less direct.

This uniformity in style applies to the larger structure of a piece as well. I mentioned in the first paragraph Landau and Lifshitz’s course of theoretical physics and the OpenBSD man pages. The ten volumes of Landau and Lifshitz are organized into sections of a few pages in length, each covering a particular topic or calculation. Each section represents about forty five minutes of study. They are organized into a handful of chapters for convenience, but there are no further levels of subdivision. OpenBSD’s man pages have one page per command, and in each page a uniform succession of sections describing its use. Feynman’s lectures on physics, are divided into chapters and sections, though of slightly different proportions than Landau and Lifshitz.

Why two levels, again and again? Readers loathe deeply nested organizations. If you don’t believe me, examine your reaction to “Paragraph 3(c) of section 12, volume 324.” Compare it to “section 325, about two thirds of the way through.” Yet we avoid the other extreme. Novels, for example, still use chapters, which are a holdover from the days when books were written on a series of scrolls (chapter derives from the Latin “capitulum”, the word for a single such scroll). Longer novels even add a larger division into “books” or “volumes”, again largely vestigial since most novels are published in one volume today. Chapters, and books for larger masses of material, are guideposts in the books that have escaped extinction by being useful. We may take the degree of organization in novels as an evolved optimum for human use. The breaks serve only as guideposts. There is no reason to expect them to behave differently in technical prose, particularly given the ubiquity of find commands on today’s computers.

The OpenBSD man page shows another important distinction: instruction is separated from reference. The paragraph quoted is followed by a formatted list specifying in detail the arguments the command will take. This occurs again and again: the precise grammar of Algol 60 in section 2 of the Algol 60 report is separated from an purely instructive introduction in section 1; the Particle Data Group’s handbooks are vital references, but make no attempt to explain what the numbers they contain are, merely capture all the details necessary to use them. Attempting to instruct while providing reference material either swamps the neophyte with detail he cannot yet absorb, while denying the expert the details he doubtless needs if he has turned to a text at all.

All this can be summarized thus:

• Know precisely the effect you wish to engender in the reader, and keep to it.
• Make all jargon that you cannot eschew appear linked to a set of examples.
• Clearly separate instruction from reference.
• Organize your material in the shallowest structure which allows readers to easily recover some remembered place in the text.

I think I haven’t explained what you’re trying to accomplish well. You’ve been reading the books and watching the videos, and no one has told you what all this machinery is for. It’s a way for your future self to promise something to your current self.

Whenever something occurs to you, you can do one of three things:

1. You can do something about it immediately.
2. You can let it sit in your head and worry about it.
3. You can receive a promise that you believe from your future self that it will get taken care of.

All this machinery, all this work, is purely so you can replace (2) with (3) for everything in your life. That’s it.

What makes you believe a promise someone as made you? Here’s another list of three things:

1. It’s in their interest to keep the promise.
2. If they can’t keep their promise, they will talk to you about it so you can make other arrangements.
3. In the past they have kept their promises.

This is what you need from your future self. (1) should be easy. It’s you on both ends. I’ll talk about (2) for the rest of this text, but I need to get (3) out of the way. (3) is what most often goes wrong. You can only arrive at (3) from experience. It’s the basic problem of any organizational system. It doesn’t matter what tools it’s in, or what fancy name it has, or even if it works or not. You cannot trust it until you have worked in it long enough for the ancient, subconscious part of your brain to believe that it will work. Before that, all you can hope for is a theoretical understanding of why it will work and enough immediate value to get through the trust building period. That is a period of months or years, not days or weeks.

Now back to (2). How do you make promises to yourself so that they will get done or you will be notified? A written record somewhere is a start. Put a note on your refrigerator, or whatever other surface you look at on a regular basis. It will catch your attention later and you will deal with it later.

Now try that with a hundred promises. You start running out of space, and any individual promise won’t attract your attention, just the wall of promises. You won’t believe those promises anymore unless you regularly go through each one individually, look at it, and do it or remake the promise that it will get done later.

That’s it: reviewing your big list of promises on a regular basis. Everything else is details.

However, the details are important. A promise to keep a dentist appointment must be handled on a specific day, so you would have to review the whole mass of promises every day to reliably keep that promise to yourself. If you have a bunch of meetings, you would have to review it many times a day. It will eat all your time.

Worse, you probably won’t have your refrigerator with you when you’re at the grocery store, so you can’t review any promises about buying dog food or milk. You need a more articulated system to hold the promises.

Corral the promises that have specific times associated with them off to the side and sort them. There’s a calendar. Put the promises about buying dog food or milk at the store on a piece of paper and put it in your wallet. There’s a grocery list. Some of the promises you can immediately do (“Throw that plant off balcony”) and others aren’t so straightforward (“See the Pont-de-Gard and die”). Separate the two kinds, and then when you’re figuring out what to do next you can review just the doable ones. The others, well, you may as well make some small promise to yourself that will get your closer to those big promise, and you might as well make those small promises immediately doable and put it in the other category.

It goes on like this. It’s all detail, there to make the sheer bulk of it all manageable. It’s important detail, but it’s detail. If you’re a monk with an utterly fixed schedule and only a few responsibilities, you would probably do just fine with notes on a refrigerator.

It’s easy to get lost in the details, to try to get it perfect. It doesn’t have to be perfect. The goal isn’t to be organized. It’s to be able to keep promises to yourself over the long term. Start, and make a promise to yourself: “Improve my system.” Scribble any annoyances of your system there. They’re promises, too. Fix it all a little bit at a time.

I recommend implementing on a combination of plain paper or plain text files at first. The goal is to keep promises to yourself long enough to have some trust in your system. Until you keep promises, you won’t get anywhere. You don’t need pretty tools, or expensive tools, or just the right pen. You just need to be able to get all your promises to yourself in one place and review them. Are your stacks of paper getting unmanageable? Get some file folders and binders and paperclips and solve the worst annoyances. Is there something annoying about your text files? Try organizing them a little differently or switch to a more powerful text editor. They’re just text files. Switching is trivial. Sharing text files is easy. Put them in a shared folder in Dropbox or Sparkleshare and you’re done.

Choose a basic convention for how you format your text files. Tweak it over time as you find annoyances. Maybe you start with todo items listed as

- Do this
- And do this

and you delete a line when you do the item. Perhaps you want to review them later, or you need to see what you already accomplished on a list. Try

- [ ] Do this
- [ ] And do this

and when you finish something, put an X between the brackets. A lot of text editors will let you set up coloring so that any line starting with “- [X]” will be light and those beginning with “- [ ]” will be black. Maybe you have too many files to comfortably navigate in your current text editor. Mess with your tools until it’s comfortable. Don’t try to make it perfect, just try to fix any nuisances that are slowing you down. A long line of little changes leads to a system so smooth that you won’t remember it’s there.

Sometimes you can’t use text files. Your job uses a Microsoft Outlook calendar, and you want to share your calendar with me. The constraints have just forced something more complicated than a text file, so take that one piece and make it work. Leave the rest as simple as possible, in a format that depends on no special piece of software, no particular operating system or computer.

My attitude towards the subject after all my work in it can probably be best summarized thus: “Fuck you, bioinformatics. Eat shit and die.”

Bioinformatics is an attempt to make molecular biology relevant to reality. All the molecular biologists, devoid of skills beyond those of a laboratory technician, cried out for the mathematicians and programmers to magically extract science from their mountain of shitty results.

And so the programmers descended and built giant databases where huge numbers of shitty results could be searched quickly. They wrote algorithms to organize shitty results into trees and make pretty graphs of them, and the molecular biologists carefully avoided telling the programmers the actual quality of the results. When it became obvious to everyone involved that a class of results was worthless, such as microarray data, there was a rush of handwaving about “not really quantitative, but we can draw qualitative conclusions” followed by a hasty switch to a new technique that had not yet been proved worthless.

And the databases grew, and everyone annotated their data by searching the databases, then submitted in turn. No one seems to have pointed out that this makes your database a reflection of your database, not a reflection of reality. Pull out an annotation in GenBank today and it’s not very long odds that it’s completely wrong.

Compare this with the most important result obtained by sequencing to date: Woese et al’s discovery of the archaea. (Did you think I was going to say the human genome? Fuck off. That was a monument to the vanity of that god-bobbering asshole Francis Collins, not a science project.) They didn’t sequence whole genomes, or even whole genes. They sequenced a small region of the 16S rRNA, and it was chosen after pilot experiments and careful thought. The conclusions didn’t require giant computers, and they didn’t require precise counting of the number of templates. They knew the limitations of their tools.

Then came clinical identification, done in combination with other assays, where a judicious bit of sequencing could resolve many ambiguities. Similarly, small scale sequencing has been an incredible boon to epidemiology. Indeed, its primary scientific use is in ecology. But how many molecular biologists do you know who know anything about ecology? I can count the ones I know on one hand.

And sequencing outside of ecology? Irene Pepperberg’s work with Alex the parrot dwarfs the scientific contributions of all other sequencing to date put together.

This all seems an inauspicious beginning for a field. Anything so worthless should quickly shrivel up and die, right? Well, intentionally or not, bioinformatics found a way to survive: obfuscation. By making the tools unusable, by inventing file format after file format, by seeking out the most brittle techniques and the slowest languages, by not publishing their algorithms and making their results impossible to replicate, the field managed to reduce its productivity by at least 90%, probably closer to 99%. Thus the thread of failures can be stretched out from years to decades, hidden by the cloak of incompetence.

And the rhetoric! The call for computational capacity, most of which is wasted! There are only two computationally difficult problems in bioinformatics, sequence alignment and phylogenetic tree construction. Most people would spend a few minutes thinking about what was really important before feeding data to an NP complete algorithm. I ran a full set of alignments last night using the exact algorithms, not heuristic approximations, in a virtual machine on my underpowered laptop yesterday afternoon, so we’re not talking about truly hard problems. But no, the software is written to be inefficient, to use memory poorly, and the cry goes up for bigger, faster machines! When the machines are procured, even larger hunks of data are indiscriminately shoved through black box implementations of algorithms in hopes that meaning will emerge on the far side. It never does, but maybe with a bigger machine…

Fortunately for you, no one takes me seriously. The funding of molecular biology and bioinformatics is safe, protected by a wall of inbreeding, pointless jargon, and lies. So you all can rot in your computational shit heap. I’m gone.

Since you’re still reading, I imagine you’d like to know why. It’s not because of what’s in it. Actually there’s a fair amount of interesting information in it. There’s an attempt to explain why our public discourse is so miserable, and a clear statement of why it’s not really anyone’s fault. There’s a potshot at the little hits of dopamine your cellphone and email client give you. There’s the true statement that the information most folks pass through their heads is far from messy reality.

But then he tries to make a diet from these, coining the term ‘infovegan’. His diet’s what you would expect from someone who would choose such a term: from a limited scope, limit yourself even further. It’s all based on an idea of trophic hierarchy, which works fine in ecology, and if all you’re talking about is the successive filtering of news. But where in the tropic hierarchy are Henry James’s collected prefaces? Sure, they’re commentary on his novels, but they’re the word from the horse’s mouth on actually crafting novels. Or how about Carrol’s Jabberwock or the works of Rabelais? They’re pure fantasy, but both men clung close to the wellspring of language.

All I can think is that Johnson’s been in politics too long, and it’s blinkered him. I don’t need an information diet, I need an information cuisine. Robert Atkins had a diet. Julia Child had a cuisine. The funny thing is, them as have cuisines tend to get along just fine, while those with diets are in constant need of a new one.

So the major reason not to read ‘The Information Diet’ is lack of vision. Johnson doesn’t have it, because he ain’t got a cuisine. I’m sure we’ll see infodiet crazes once the metaphor’s firmly cemented, but I don’t want to be an ‘infovegan’. I don’t want to deny myself McDonalds hamburgers in favor of overcooked tofu. I made a stew of salmon, lentils, and beets tonight better than either. And I’ve got a pile of books at my elbow that make up a cuisine, and after this dud cake recipe, I’m off to stew up something proper.

I’ll leave you with a book about the same size as Johnson’s but chock full of cuisine: Ray Bradbury’s ‘Zen in the Art of Writing’. When you finish that, you can go try Ezra Pound’s ‘ABCs of Reading’, Kenneth Clarke’s ‘Civilization’, Garrison Keillor’s ‘Good Poems’, and Christopher Alexander’s ‘The Nature of Order’.

Shocking, yes? But consider: all a peer reviewer has to go on is what the author wants him to have. They both know the same background material, and both know that unknown factors can make seemingly identical experiments done by different people contradict. All a reviewer can do is ascertain that, if there was fraud committed, it was skillfully done. Our potential fraudsters are scientists, highly trained and intelligent. I believe them capable of producing a skillful fraud if they wish. Peer review spreads the responsibility editorial decisions for journals around on the theory that, with enough heads, someone will be able to decide well. It does no more.

How can we have credibility, then? Remove the social forces that reward fraud, and then punish the act of fraud with shame and ostracism. If there is no benefit and only risk, only a few pathological minds will bother. What are the social forces? Essentially, temporal rewards: promotion, tenure, prizes, funding, minions, and not being fired.

I want to digress on the firing of academic scientists. At this point in time, all the funding comes from the scientist. Universities provide at best partial salary support and some money to get set up, and thereafter demand rent from the scientist, in exchange for teaching and committee duties in perpetuity. The university has only prestige and facilities to offer in return. Facilities are cheap, so why does the university hold power in this relationship? It has to be the prestige, which is a fine inducement to fraud. The power universities hold beyond what any other landlord renting facilities would needs to end. As for the rest of it, promotion and prizes and minions, get rid of it all. Tenure, in the civilized world, should go. Civilized countries today have freedom of speech built into their legal foundations. The rights tenure originally guaranteed are now guaranteed to all citizens.

What does the resulting scientific establishment look like? It should be relatively easy to get enough funding for a single person to run a frugal lab for four or five years at a stretch, and horribly difficult to get more. There is no official recognition. There are no prizes to compete for, no plum positions or sinecures unless you convince private citizens to endow you luxuriously. There are no armies of graduate students being driven through programs to support the prestige of their professors.

Inevitably someone will protest that without these incentives, why try to do important science? I feel slightly ridiculous even addressing the point, but it must be done: I have trouble imagining the mind that gets up every morning and says to itself, “I think I’ll do something humdrum and unimportant today.” Perhaps they exist, and for those minds we can install basic checks. At the end of your funding period your work has to be reviewed for renewal. If you haven’t produced anything at all, not even interesting, intermediate results, then you’re on probation. If you don’t produce anything twice around, you’re not funded. The standards need not be that high. We’re not talking about a large amount of money, no more than $80,000 to $100,000 a year to pay for salary and all research expenses. There’s plenty of room at the bottom.

Scientists positioned like this, with no hope of official recognition, prestige, or promotion, have no reason to commit fraud. Add to that a strong discouragement—being barred for life from any government research funding if convicted of fraud—and you have a system where the literature will probably be credible. There will be crackpots, but that’s a whole different problem, and one that can be handled gracefully with minimal measures at the level of publishing.

I have spoken here only of individual scientists, not of large projects. What of major initiatives like CERN or USGS surveys? Projects of sufficient size have their own means of avoiding fraud. Papers coming from the experiments on CERN’s LHC are not peer reviewed by the journals. They have already been checked and rechecked internally, along with the data and the analyses themselves. I’m not worried about projects on this scale. They function just fine. The worry about credibility of the scientific literature is purely directed at the independent researcher working on a small project, and for that I can see no other solution than a reengineering of the scientific community to remove the inducements to fraud.

But why don’t I publish in these journals?

I do science because I really enjoy the cycle of reexamining what we know for holes, trying to interpolate into them, and then testing the interpolations, and because I value the scientific legacy left to me and I wish to pass it on enriched. Only the second has anything to do with publishing, and it puts the onus on me to communicate my work in the clearest, most generally accessible form possible.

Peer reviewed journals are not a generally accessible form. The papers in them are read only by a few specialists. The writing of such papers is an act of verbal contortion: editors demand extensive results before they will allot one of their competitive slots to a paper, but the slot is sufficiently short that there is no space to describe that work comprehensively, much less clearly. Most papers today don’t include a description of their methods adequate to reproduce the results. Once published, the paper becomes the property of a company with no interest in its general distribution, or even in its preservation, and is thereafter inaccessible to all but a few privileged individuals. This ignores the amount of work, frustration, and political wrangling that goes into forcing a paper through the peer review process.

Given this, why does anyone publish in these journals? It’s part of the game: if you want to advance in academia, you have to publish peer reviewed papers that your peers think highly of. That’s irrelevant to me. I decided before I finished my bachelors degree that I didn’t want to be an academic. Graduate school for me was an offer by a university to pay me while I amused myself with the fun parts of science for a few more years. Unfortunately, the professors where I went didn’t understand this and insisted on treating my presence there as somehow a privilege bestowed on me, but this is beside the point. We’re talking about publishing.

The academics can spend their time fighting to change the peer review system, to curb its excesses and make it function better. They have to. It’s a game they’re forced to play. I don’t have to, and I have no reason to want to. Yes, we need a system of evaluating research to prevent utter crackpottery, to “preserve standards”, but I’m not bringing them down. I required higher standards of myself than most of my colleagues were willing to meet.

I’ll make a promise that’s better than limiting my work to peer reviewed journals: I will train and work as rigorously as possible, and ask scientists I respect to tell me honestly where I have failed and need to improve. I will write my results up as clearly as I can, and make them publicly available as widely as possible.

If you’re required to play the peer review game by your career ambitions, go ahead. I understand. I ask you to understand that my career ambitions require me not to.

I did it on a little pocket notebook part of the time, and in a text file the rest of the time. I started in the early afternoon the day I thought it up, missed a couple hours on one day, and then ended the experiment after four days since the results were so clear. I could have run it a few days more, but more data wouldn’t have enabled me to make better decisions.

I encourage you to repeat my experiment with yourself. I’ll explain what I did with the data below to give you an idea of what you might try. If you want to send your results to me, I’d love to see them.

To start with, here is the raw data. The columns begin when I woke up in the morning, and end when I went to bed at night, except for Wednesday afternoon when I began the experiment.

The first thing to note is how regular it is. My energy levels have a regular pattern that varies by at most an hour or so per day. What does that tell me about how I should organize my time?

It would be a shame to ignore the structure and improvise my day as I go, as I would have to if the variation were two or three hours, as long or longer than the periods of high or low energy themselves. However, a rigidly defined schedule won’t work for me, since there is still variation by up to an hour. It would be wonderful for someone with variation of less than half an hour.

What I can do is make a rough flow of events, and their rough length. Society suggests just such a flow to us: have breakfast when you get up, work until midday, have lunch, work until five, go home and do what must be done to keep your life imploding until dinner, then be with your family until it’s time to sleep. Dinner varies with your background. For many Americans it falls at 17h00 or 18h00. For me it has always been around 20h00. For a Spaniard, it would be closer to 22h00.

Compare this with my energy levels:

If I did this, I would be starting work before my energy really rose for the day. I would stop working in the middle of my highest energy period of the day and have lunch. Then I work through my medium and low energy period, and have to take care of everything else in my life when my energy is at its lowest in the day. Then, when my energy is finally coming back, I sit down to dinner and relax for the night. This is almost the worst possible arrangement of events for me.

Instead, I’m going to make a few observations and build my own sequence of events. First, those two periods of high energy are sacrosanct. Any sequence of events must put my work into those slots. Fortunately, as long as I make an appearance somewhere in the work day at my day job, no one much cares exactly what hours I work.

I want to take half an hour before to start work and get my mind in the right place before my energy peaks so as not to waste any of it. I also want half an hour to an hour after the peak to the results in order and plan the work for the next period of high energy. So in the morning 9h30–10h00 is a warmup, 10h00–13h00 is work, and 13h00–13h30 or 14h00 is cleaning up and planning the next session. Looking over this, I also know that I’m going to need a light meal, something with plenty of protein and fruit and vegetables—tuna salad and carrots and an apple, perhaps—about 11h30, to be eaten while I work. Similarly, at night 20h00-20h30 is warmup, 20h30–22h30 is work, with a light meal about 22h00, and 22h30–23h00 or 23h30 is putting my work in order for the next session.

Those low hours from 16h00 to 18h00 are the bane of my existence. I hate them, and I’m going to deal with them before I do anything else. I’m going to sleep through them. 16h00–18h00 is hereby my siesta.

Those are the points that I feel really strongly about. Now for the essentials: sleep, food, and exercise. I like to eat my breakfast calmly, but I don’t feel like doing much in the morning before that first big peak of energy, so waking up at 8h00 will work fine for me. I need time to wind down before I can go to sleep at night, so after my last work period I’m going to get ready for bed and go to sleep. It may look like I’ve schedule ten hours of sleep a day, but I’m something of an insomniac. If I find I’m getting more sleep than my body wants, I’ll just get up earlier and do a little reading in the morning.

I’ve already scheduled two light meals during my peak energy times, to be eaten as I work. Knowing my metabolism, I need another light meal, and two full meals. The light meal is to get me through until dinner. I’ll have it at the start of my siesta. The two full meals are breakfast and dinner. Breakfast is before 9h30, probably whenever I get up, and it needs to be rather more than a bowl of cereal. Dinner needs to be done before my evening energy peak, so I’ll say that it happens between 18h30 and 19h30.

Finally, exercise. I need to have at least a medium energy level, and I must not have eaten heavily in the last hour or so. The obvious time is about 14h00, and I don’t need hours. I can have myself to collapse in about twenty minutes if I want. That still leaves nice hunks of time in the mid to late afternoon for dealing with the miscellanea of my life and spending time with people.

In summary, here is my proposed rough order of events for my day:

There, a sequence of events that is utterly abnormal in our society, but which is calculated to fit me.

The distance from earth to sun is roughly 1 AU. From the Earth to the moon is about 2.5 × 10^-3 AU. How often do you deal with an aspect ratio of three orders of magnitude in your life?

The tallest building in the world, the Burj Khalifa in Dubai, is 828m. What is the smallest object you can see if you have the entirety of the tower in view? The vertical field of view of the human eye is about 0.75π radians. 10^-4π radians. If we had the entire Burj Khalifa in view, the smallest object we could see next to it is theoretically 10cm, but to get any effect we would have to perceive it as an object, not a speck, so it would actually have to be several meters in size. That’s at most two orders of magnitude.

The great cathedrals, the Grand Canyon, the pyramids, don’t offer anything like two orders of magnitude of visible difference. You cannot draw a triangle with an aspect ratio of 1000 on a piece of normal paper with a pencil that you don’t perceive as a sloppy line. A4 paper is 210 x 297 mm, standard pencil leads are 0.7mm in diameter. The width of the a triangle 297mm long with the same aspect ratio as the sun, moon, earth triangle I saw would be 0.7mm.

We live in a world of very limited aspect ratio. What happens when we are suddenly faced with something as far beyond our experience as the Burj Khalifa is beyond a house in the suburb?

Satori.

“One limitation of this modeling approach is that for some genes, there is a low degree of similarity between the observed expression profile and the one predicted by the most appropriate model. …It is possible that other curve-fitting methods…might also be applicable to this kind of data. However these methods do not provide the statistical machinery that comes with the regression modeling approach that we have taken. The main advantage of our method is being able to easily apply valid statistical tests to determine which one of two models is more likely in light of the data. We are also able to explicitly define statistical significance in a meaningful way that protects against a specified false discovery rate.”

It’s from the paper Decomposition of Gene Expression State Space Trajectories. Summarized, it says, “We don’t know how to use any appropriate tools, so we’ll use inappropriate ones we found in our introductory statistics book. Everyone else calculates p-values for lots of things with it, so it must be okay here, too.”

Let us review what you must have if you are not to drive a statistically inclined mad scientist to sic his ants upon you:

1. Your procedure must measure something which is demonstrably relevant to what you are investigating.
2. You must know the assumptions under which a procedure is valid.
3. You must have tested your data and apparatus against the assumptions and found that they hold.

That’s it. Really. But if my giant mechanical ants were to truly rend those who fail to accomplish these three simple goals, the majority of inhabitants of the groves of academe would be ant food.

> I mentioned this article in the retreat

I seem to remember reading something very similar a while back.

Unfortunately, he doesn’t understand monads, as far as I can tell. They were a solution to syntactic problem, not a semantic program.

Almost every language out there attaches a continuation to each statement, that is, a “next in time will be this” pointer. Some languages, like Scheme, give you access to the continuation. Most don’t. They all have it, though. Even Prolog and ML have them.

The pure functional languages can be regarded as an experiment in cutting off the continuations. All you are guaranteed is that any value you use was evaluated before you used it. So how do you do sequential computation? Use a value which was produced by the thing you want to have happened before you in time. If you look at Mercury, which is a really fast, pure, strongly typed Prolog, you find a lot of statements are rather different from traditional Prolog. print, for instance, takes a value of type IO () as well as the string to print, and returns a new value of type IO (). The IO () value you pass it is what was supposed to come before it in time. The IO () it returns is a value that lets another function inject itself into print’s continuation.

Remember how your thinking inverted when you learned Lisp, and suddenly you pulled values through functions instead of pushed them into variables? Same thing here. You construct the continuation as a sequence of nested statements instead of constructing statements as a sequence of nested continuations.

The thing is, passing that extra state variable around is bloody annoying. It makes code ugly. And if there’s anything a programming language researcher hates more than ugly code, I don’t want to see it.

Then Phil Wadler figured out that what he really wanted to do was to reprogram the boundaries between statements, and then found that a category theoretical construct called a monad nicely described the IO case. And a bunch of others. Though it turned out not to be right for a bunch more, which lead to the propagation in the community of applicative functors (aka, idioms) and arrows.

He mentions actors as a better idea than monads. Actors have their own problems, though. Yes, they are more intuitive initially, but reasoning behaviorally about concurrent systems doesn’t actually pan out. For instance, see Lamport’s commentary on a paper he ended up on the author list of with Dijkstra.

The reason monads took off is not because they were the undeniably best way of handling state threading. Clean, for instance, uses a completely different mechanism that works just fine. Monads took off because they compose. You can construct domains specialized for what you want to do.

The tools for doing this composition work well enough for production use, but are anything but elegant. As soon as anyone has a good idea on how to do it right, it will sweep through the Haskell community like wildfire.

The chapter is organized into a list of core concepts to be taught from biology, physics, chemistry, engineering, and math and computer science, then a set of suggested curricula. I’ve broken my gripes down by section:

Biology: Some of the concepts listed are important (“Biological systems obey the laws of chemistry and physics.” and “Lipids assemble with proteins to form membranes, which surround cells to separate them from their environment. Membranes also form distinct compartments within eukaryotic cells.”) and I dearly hope they are being taught already. Others are sloppy, tautological, or espouse absurdities such as “holistic” science.

Chemistry: I know almost no chemistry and am not willing to comment on this section except for the fact that “computational methods and modeling” is a bullet point right alongside Lewis structures.

Physics: The physics recommendations largely consist of a standard intro physics course for hard science majors with a few topics moved here or there. This isn’t a bad thing. I think that the best approach would be to take an 1960′s edition of Halliday and Resnick and go through that in a year (for those who don’t know it, the early editions of Halliday and Resnick were clear, comprehensive, and had a doable number of extremely well selected problems).

The report also wants the students to do learn by interacting with simulations. I can tell you from being on the receiving end of such an attempt and from anecdotal evidence in the community that such approaches are dismal failures. Let the course be analytical and experimental. Leave the computer out of it.

Engineering: Aside from the incredibly broad heading, this has about the only interesting, concrete recommendation in the report. The introduction was written by the biologists who are convinced that systems engineering is all that they might really want. Then someone wrote a curriculum outline for the first third of a really solid neurobiology course. Whoever wrote that, bravo!

Mathematics and Computer Science: Some of the topics confuse me (computability theory? why?). The gist of this section is to give the biology students special math classes where the computer can do all the work for them. Hamming said, “The computer is an extension of the body, not the mind.” (I found this quote in the preface to McNeil’s Interactive Data Analysis) I agree that biologists should be able to program, and should really understand what BLAST does. This would be better taught as a one or two semester course on numerical analysis and relevant search methods, plus data structures such as ropes to handle long sequences. And it should be taught in Scheme (or this for the ambitious), not in “higher-level languages such as Matlab, Perl, or C” as the report recommends. Everyone who knows something about programming languages just stopped taking the computing recommendations of the report seriously with that list.

Apparently students should be taught data analysis. I completely agree. Astonishingly, John Tukey wrote some great books for this back in the ’70′s because he was teaching people data analysis. And it’s not just biologists who need this. Every scientist would benefit. Call up your local statistics department and get them to institute an “interdisciplinary” course based on John Tukey’s two classics Exploratory Data Analysis and Data Analysis and Regression, or whatever modernized version they want to teach.

The recommended math comes down to the following classes in the math department: single and multivariable calculus, linear algebra, differential equations (more like Arnol’d's book than what the engineers are taught), and probability and stochastic processes (this would be a great place to use Nelson’s Radically Elementary Probability Theory). There, three years of math, a semester of computer science, and a semester of data analysis. That’s not so bad, is it?

The report also mentions that medical school admissions requirements govern a lot of what biology departments cover. My approach: ignore them. Physics departments do. If the biologists ignore the MCATs completely, then they will change to follow the biology.

The recommended solutions for dealing with not having the expertise to teach a course are frightening: “…taught…by a collaborating team of faculty from multiple departments” or “A mathematician or computer scientist might also be invited to give a guest lecture or two.” Two lectures isn’t long enough to have any real effect on students’ mental processes, and team teaching makes the course scattered and disorderly. I speak from experience. Biology courses are often taught this way, and it’s absolutely useless.

There is an obsession throughout with having a course on modeling and simulation. I believe the rationale is that all the ugly mathematics stuff can be put into this, taught by one of those egg-headed math people, and the biology professors can go on doing exactly as they have been.

At one point it says, “Opportunities to learn mathematical skills in a rich content context will enhance conceptual understanding and procedural fluency.” No it won’t. Math professors should (and usually do not) ask students, “Why is this theorem interesting?” If a student has not reached a level of mental abstraction sufficient to answer such a question in the context of pure mathematics, the mathematics education has failed. Later it even recommends remedial math courses before calculus! What are you doing in college if you need that?

In an earlier post I gave my quibbles with the language of the BIO2010 report. I promised to lay out an alternative curriculum proposal, but first I’m going to set forth my underlying philosophy. First a few principles:

Repeat a canon several times.

Choose a core set of techniques and ideas which will properly shape the students’ minds. The shape of their mind when they come out is far more important than any particular collection of facts.

My sister once noted in surprise, the night before a calculus exam, “I can’t study for this class! I can only practice.” There is no body of things that a science student should know, only a body of things he should be able to do. Skills and mindsets take much longer to teach than facts, so it is important to be stingy with what gets space in the curriculum. For example, given familiarity with the simple SIR epidemiology model and with partial differential equations from mechanics, there is no conceptual difficulty with adding spatial effects to the SIR model. Unless it is a step to some other compelling mental skill, ditch it.

If math is your language, don’t work in translation.

You would not expect students of Italian literature to have everything taught in English translation except for one course where they played with Italian translation. Just so, if mathematics isn’t the language in which you teach your classes, adding a random course will not fix the situation. Having students take carefully designed courses in math, computer science, and physics is not the right approach. They should only take those courses which impart tools they will use in every biology class from there on out. If no biology class in your department uses complex analysis, then don’t require the class of your students. If almost every class needs stochastic processes, then abstract that out and require a course in it. If no biology class in your department uses math, then if you find this state of affairs unacceptable, it falls upon you to correct it, not to delegate the task to a mathematician who spends his days worrying about category theory.

Prerequisite courses are for the universal, not the potentially useful.

Physicists have separate calculus courses not because it’s a good idea for students to know calculus, but because the tools are used in every physics course the students take, so it is more efficient to deal with the tools once, uniformly, and assume them from there on out. Topics like Laguerre polynomials which show up in only some of the following physics classes are simply taught alongside the physics, not abstracted out.

Does every course require the students to know what a calcium ion is, what it does in solution, and how it combines with things? Then general chemistry seems like a compelling prerequisite.

A course is the minimal mental pattern of a practitioner.

Students taking a course shouldn’t have to memorize facts. They are there to pick up a core of tools and structures which shapes their mind for research in a field. I propose a rule of thumb: if a practitioner uses something weekly, it should be in the introductory course; monthly, in the advanced undergraduate course; annually, in the graduate course.

Finally, the report wants physics and chemistry departments to modify their introductory courses for the needs of the biology department, or to offer special introductory courses. No. Many students are undecided as to their major in their first year, and take the introductory courses in all the sciences. I think each of these courses should be taught as if to a class full of majors in the department teaching the course. For instance, why should physics departments throw out relativity? And if an ostensible biology student seeing relativity decides that they like that more, shouldn’t they become a physics major?

I’ll post the curriculum proposal next.

(Update: Talking to my adviser, his comment was that the single most important thing that could be done would be to cut the administrative burden (not including teaching) of principal investigators from half to two thirds of their time to something much, much smaller. I think perhaps five to ten percent should be the upper limit.)

Having given some principles to guide curriculum design, I’ll propose some content. Remember, the goal is a mature and sophisticated mind, not a knowledge of any particular subfield. I’m not qualified to select the content for such a curriculum, so please suggest changes. We’ll begin with a survey of the advanced undergraduate courses.

Neurobiology: I give neurobiology its own place because certain aspects of it are very mature and therefore a prime field for training minds. For similar reasons, immunology makes no appearance in this list, as the field is too contorted, at least as represented in the textbooks, to usefully train anyone.

The first milestone of the course is a physical understanding of the Hodgkin-Huxley model, and how it came to be. This will probably take half a semester.

After Hodgkin-Huxley, I am out of my depth. The two obvious directions are the essential features of the synapse, and the basics of neural architecture, probably using vision and hearing as the models. This brief discussion (warning: PDF) has some interesting references, but I have not had time to follow them up.

Molecular biology has two aspects. The first is structural understanding of the three major biopolymers (DNA, RNA, and protein); the second is designing protocols to manipulate them. Students should not only understand the structural differences between GC rich vs. AT rich helices (at the level of something like Calladine’s Understanding DNA), but also why each step in a miniprep is there, and how to calculate what it should be in the absence of a protocol. This means they need quantitative descriptions of sedimentation and separation by centrifugation, chromatography, and amplification by various kinds of PCR. Then move on to models of transcription and translation, and mechanics of molecular motors. This course will probably take about a year.

Evolution and ecology begins with population genetics (Gillespie’s Population Genetics seems about right), epidemiology (some selection from Diekmann and Heesterbeek’s Mathematical Epidemiology of Infectious Diseases), something about species interactions and evolution of behavior (a couple bits and pieces of Gintis’s Game Theory Evolving), bioenergetics and flows of energy carrying molecules both in organisms, which gives a chance to discuss metabolism, and in ecosystems. These selected topics constitute a semester.

The next semester is genetic mapping and screening (design of screens and selections, RFLP and other techniques) and phylogeny (constructing the universal phylogenetic tree, with visits to representative areas such as evolution of horses, gene transfer in bacteria, and parallel evolution of fluorescent proteins in corals).

Biomechanics is the successor to anatomy, merged with mechanical engineering and developmental biology. It begins with a couple weeks of statics such as Galileo’s argument on the scaling of bones, pressures on bacterial membranes and cell walls, DNA pressure and packing in viral capsids.

Then it moves to dynamics: swimming of microscopic and macroscopic creatures, motility of cells by actin, circulation in the body, and basic models of cell migration and patterning in development.

What about supporting courses?

Single and multivariable calculus are necessary in all the courses, as are ordinary differential equations, with an emphasis on phase space analysis and qualitative features, but definitely including the Fourier transform. Partial differential equations are used only in biomechanics and evolution and ecology, and in neither place in really intricate ways, so they can be handled in those classes. Probability and stochastic processes appear in all of the courses except biomechanics, and possibly there as well depending on the exact selection of topics. It is also necessary to statistics.

Chemistry of ions in solutions is necessary for neurobiology, chemical thermodynamics for evolution and ecology and molecular biology. Organic chemistry is necessary to make sense of the pieces in molecular biology. A general chemistry course with a really physical bent is probably enough as a starting point.

Physics of point particles and rigid bodies, thermodynamics, and basic electromagnetism are all that need to be covered outside of the courses. I expect most science students to take introductory physics, chemistry, and biology as part of choosing their field of study, so these courses cannot be altered too much.

All of the classes can provide opportunities for students to dig into real data, so a separate data analysis and statistics course makes sense. I think a selection from Tukey’s Exploratory Data Analysis and Data Analysis and Regression and Kiefer’s Introduction to Statistical Inference would form a good basis for such a course. All science students should have such a course, so there is no reason to specialize it for biology.

The data analysis course and the evolution and ecology course both involve an understanding of programming and computational cost of algorithms. A computer science course on basic numerical analysis and search, sorting, and alignment algorithms would be a useful companion to both. Students should write all their own code for the assignments in this class, and use almost no libraries and certainly no algorithmic black boxes. About the only way to actually do this is in a semester is to teach the course in Scheme or a similar language.

What goes in the introductory course? My inclination is the first two lectures of material from each major section of the four courses, rearranged into a more unified year-long presentation.

What laboratory classes should students take? I would propose a separate introductory laboratory class of experiments that can be done in one or two sessions, separate from the introductory biology course, but covering what of that material is checkable in the lab in reasonable time.

Molecular biology is an obvious for a candidate for lab, learning how to prepare DNA, digest and religate it, run western blots, and do genetic engineering in E. coli.

Almost everyone uses a microscope, so a one semester laboratory on optical microscopy covering material something like Shinya Inoué’s Video Microscopy would be a good time investment. Then an intermediate lab where students carry out three or four longer experiments in small groups throughout the semester.

The Bio2010 report recommends a research seminar, which I think is a good idea. The Rockefeller University requires such a course of its graduate students. The class reads two of the classic papers in biology each week and meets with two faculty members over lunch to go over them.

In the end we have a schedule that looks like this:

First year:

• Introductory biology (all year)
• Introductory chemistry (all year)
• Introductory physics (all year)
• Single and multivariable calculus (all year)

Second year:

• Introductory biology laboratory (all year)
• Differential equations (fall) / Probability and stochastic processes (spring)
• Neurobiology (fall) / Biomechanics (spring)
• Numerical analysis (fall) / Data analysis and statistics (spring)

Third year:

• Evolution and Ecology (all year)
• Molecular biology (all year)
• Microscopy lab (fall) / Intermediate lab (spring)
• Research seminar (all year)

Fourth year:

• Molecular biology laboratory (fall)

This leaves plenty of space for electives and general requirements. Now everyone have at and rip this to shreds.

Reliable and complex from simple, brittle pieces

TCP guarantees the arrival of intact data, short of the entire network fragmenting. Some telecom systems claim nine nine’s of up time. Large data centers expect disk failure (PDF).

No single person understands the whole of one of Intel’s chips, or those from AMD, or any other desktop microprocessor today. This is Conway’s law at work: “…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” Turn it around: a system beyond the grasp of an individual human can be built by organizing them along its lines, and designing the organization can be done by one human.

In groups we can build things beyond the grasp of the individual, that are more robust than any part we have available to put into it. If that doesn’t give you hope for our species, what does?

Abstractions

The simplest mini-Prolog is almost trivial. It’s a few functions, none more than a few lines of code. Seen in the host language, the functions are inscrutable, as opaque as looking up at the surface of the water.

On the far side, unification over Horn clauses (i.e., Prolog) is a consistent and self contained view of computing. You can peer down at the surface where Prolog begins and lambda calculus ends, but everything on the far side is hazy and distorted.

I always feel a sense of vertigo when I cross such a boundary, and even more when I erect one.

The infinite horizon of homoiconic languages

In Lisp, all is Lisp. In Smalltalk, all is Smalltalk. In Prolog, all is Prolog. These languages are easily defined in themselves. Their interpreters and compilers live as automata in the world which they define.

This imparts a feeling of space. In Haskell or C you can see the boundary clearly. Your semantics, your type system, the hard wall of the compiler, sit in plain view. In the homoiconic languages, the compiler is just another function, another object, another rule. The boundary that defines the edge of your semantics recedes into the distance and vanishes.

Practically, such languages are incredibly easy to bootstrap. If you can just breath life into some kind of interpreter, you open a door to wonderland, and may step through and forget whence you came.

Intrinsically hard problems

The implicit trust of mathematicians for millenia was that if we were only smart enough, if our reason were just powerful enough, we could calculate anything in the universe.

Complexity theory ended that. There are problems in our universe on which reason may break itself in vain, and they are named NP-complete. In a universe of subatomic particles colliding and appearing and disappearing, the seeming abstraction of how hard a problem is to solve is bound by universal laws.

Artificial intelligence isn’t human intelligence

Computers bear no resemblance to human cognition bears. We did not make these machines in our image. Indeed, one of the successes of the machines was to make us realize that we are not computers. Our thought processes do not work like that.

We are things capable of taking decisions based on the world around us. We created other things likewise capable, but they do so in a manner entirely removed from our own. After living with our creations, I can only wonder at the naivete of those who could think a being that created us would do so in his own image.

Updating technical consensus is very, very hard

JavaScript is broken. Everyone knows and acknowledges this. Books are written about how to avoid its jagged edges.

The Internet was not designed for web applications or streaming media or commerce or identification of its users.

Unicode is one of the most remarkable consenses of mankind.

Technical consensus is necessary for complicated artifacts, but no one knows how to change them. There are many obvious things that could be fixed in JavaScript, things that no one would dispute, but socially we don’t know how.

Public/private key cryptography and webs of trust

I can encrypt a message, send you a key to decrypt it, and be sure that no one else can eavesdrop. Public/private key cryptography, like building reliable systems from unreliable components, seems too good to be true. Of course, there’s a catch. How do you know someone didn’t replace the message and the key?

This is where webs of trust come in. I may not trust the key I got from you, but I may trust that a mutual friend says it’s the right key. That may not scale very well – why should I trust the friend of a friend of a friend? – but it needn’t scale very far. The small world theorem says that if the web is sufficiently comprehensive, I am unlikely to need very long chains of trust.

In practice, such cryptography hasn’t become ubiquitous enough for the small world effect to really kick in, which is a shame.

Self destruction of communities

In any sufficiently large and general online community, cliques arise that try to destroy the community, along with lots of other odd behavior.

If the interactions are limited enough, then this kind of abuse tends not to arise because the technical limitations make it too much work. It is hard to imagine how to go on a rampage in Twitter. In a small community, the social pressure to behave is high, and the probability of someone resistant or hostile to such pressure being a part of the community is small.

When the interactions are general enough and the community large enough, groups arise who view the community around them as their intellectual prey.

And then a system of controls and enforcers is put in place if there wasn’t already one. The history of IRC is one of networks splitting off and adding controls and enforcer powers. Usenet continually suffered from flamewars. Spam appeared in email, not to mention mail bombs.

We have built communities again and again from scratch on the Internet. It appears that a certain fraction of the human race is naturally destructive and must be held in check, and that some part of every community’s resources must be devoted to that.

It’s a strange thing to learn from a collection of wires and transistors.

Cryptographic hash functions

Imagine a function that has an inverse. The function is easy to compute, the inverse almost impossible. This is another of those pieces of magic that makes modern computing possible.

Add to that two more properties: small changes in input cause large changes in output, and no two inputs yield the same output. Now you have a tool to reduce anything to an identifying integer. At some level, computer security is controlling who has the data and who only has the identifying integer.

Accept liberally, produce conservatively, and go mad

RFC 791 says “Be liberal in what you accept, and conservative in what you send.” Since RFC 791 defines IP, the foundation of the Internet, this is, for all practical purposes, the Intenet’s motto. And the Internet grew insanely fast.

The World Wide Web did the same thing, resulting in broken HTML, distorted HTTP requests, and growth more usually associated with bacteria.

You must accept that many people will have to spent a lot of time cleaning the mess to the best of their ability at some point in the future. On the World Wide Web, at least 40% of HTML was malformed in 1996, and probably much, much more (it’s hard to tell from the way the data are presented). In 2001, there were at least 140 invalid HTML documents on the web for every valid one (source).

And a lot of people have spent the last fifteen years trying to fix this. The situation has actually improved, but think how much time and acrimony has been spent.

On the other hand, without this path, the web would have had only a brief history as a medium for pictures of women as opposed to its multidecade run as the largest source of images of the female of the species ever created by man.

It’s apparently better to let everyone in, let it go to hell, and try to clean up later. To the mathematical mind, this is a boggling principle.

Concurrent is different

Concurrency, or multiprogramming as it used to be called, has long been the bugbear waiting to snatch the unsuspecting programmer. Most programmers developed an implicit view of their craft based on some variation of a Turing machine. They work by setting up and running that machine in their head. This has crippled more programmers than I care to think about. (Dijkstra had many unkind things to say about such issues).

The human brain can keep track of one machine going back and forth on the tape. At each stage, there is only one possibility. The programmer develops an intuition based on how he would move chess pieces around on a board. But as soon as there is more than one machine on the tape, this fails, completely and utterly. There are now two chess players, and even when we only allow them to move their own pieces, that game has absorbed more of man’s intellectual energies over the course of history than programming has.

Concurrent programming is more difficult than single threaded programming, but more importantly, it’s just different. Once you have trashed the little Turing machine in your head, there is a lot known about multiprogramming. But what is astonishing in this? It’s not concurrency, though there are gems to be found there. It’s that we spend endless work trying to pander to programmers crippled by a curable mental afflication.

The creation of a network

The Internet went from 213 hosts in 1981 to 29 million in 1998 to 681 million last year (source). I remember when the only contact information on business cards were telephone numbers and mailing addresses, before FAX numbers were added. Today the telephone number is secondary to the email address or web site.

My mother was 17 when the first ARPAnet link was established. TCP/IP became the sole accepted protocol on the Internet in 1983, the year I was born.

The Internet is something new and different, though it has become passe to say so. Pundits and bloggers and talking heads pontificate about the transformative powers of this or that trend. They have no more idea of what’s happening than the neurons in our brains understand our thoughts. (I should add that the Internet is not a brain, and that analogies between the Internet and brains are roughly as useful as analogies between the Internet and cottage cheese; see my astonishment, above, that we created machines not in the image of ourselves).

How outlandish does the phrase, “The Internet thinks your cute?” sound? We’re not far from it seeming almost normal. Now go read A Miracle of Science, where Mars is a group mind and at some point says to someone, “Mars likes you.”

Epilogue

Now that the list is made, why did I choose things from informatics? There are things in math and physics and music that astonish me more over the years, but they tend to feel eternal. They are truths the world may reach towards, but they will not meet it half way.

The things I listed in informatics are visceral, low-brow, as though we were playing in a mud puddle from which the Loch Ness monster emerged. And they are, in so many case, about people, about how people interact and how people fail and how people end up in horrible messes.

A character has been slippery. Very well, who is this person? I’ll digress and figure her out, tell her story to myself, so she can walk into my novel a breathing creature.

This implies significant yak shaving even writing on Earth unless you’re writing about the town you live in, but as soon as you create a fictional world, you must digress from the character to construct the society that produced her, her family and upbringing. They, in turn, require a setting to live in. This is how worlds grow vastly beyond the small number of settings a novel actually traverses.

On a planet’s surface, the construction of areas, the effects of geography and history, are fairly familiar to most reasonably read and traveled people, but this book isn’t on a planet. Suddenly I find myself reading about orbital velocities and composition of trans-Neptunian objects.

The trick is minimizing it. The physicist in me wants to calculate transfer orbits and slingshots and velocity matching and the transfer orbits to send material insystem and the probable system of volatile materials futures used to hedge materials being sent in this way. Thas way lies madness and no character. I’m writing a novel, not a mathematics text (though there is that idea I have for a series of love letters involving Bessel functions). To quote Henry James, “Up to what point is such and such a development indispensable to the interest [of the subject]?”[preface to Roderick Hudson] and he was talking about the book itself, not the yak shaving of character predevelopment.

I chose to shave just enough yak fur off the astrophysics to give the character a setting, and I’ll adjust my narrative to eschew any details. After all, what reader wants to hear about the numerical calculation of chaotic transfer orbits from a position leaving a trans-Neptunian dwarf planet’s transfer orbit to to a cometary core in the inner Oort cloud?

Well, given my friends, probably quite a few, but they will have to be disappointed.

It was all worth it, though, when I traced the chain back out to the character herself, and as I told myself her story there came a moment when she sat up and drew breath in my mind, no longer a role in a narrative but a conception of a fellow human being.

This is not only wrong, it is dangerously wrong. I’ll explain why it’s wrong, then come back to the dangerous part afterwards.

Everyone has learned some variation of the idealized von Neumann computing machine: a processor that executes one instruction at a time and some contiguous bank of memory which it is connected to. Instructions in the processor can take a memory address in a register and read the data found at that address in memory into another register, or write the contents of that other register to that address in memory. Perhaps the registers are replaced by a stack. The memory might be layered, with some parts being faster to access and smaller and size, and others increasingly large and slow.

A program specifies the behavior of this machine. Typically they start with data at one place in memory and produce other data in another place in memory. This should all sound very familiar. A way of specifying programs is an interface to the computer.

So does a shell script constitute a program for this machine?

Many of my readers doubtless said yes. After all, it begins with data at one address (which happens to be a file in the filesystem, but that’s a memory address) and generally leaves data at another address (again in the file system, or perhaps stdout). It specifies the behavior of the machine. How could it not be a program for this machine?

It specifies the behavior of a machine, but not of this machine. When you run “ls | tail -n 7“, you do not have a coherent piece of memory. The operating system establishes the appearance of a contiguous chunk of memory for “ls“, and it establishes a second, completely disjoint chunk of memory for “tail“. In effect, there are two machines. The operating system goes through contortions to hand off a starting pattern of data to “tail“ and to do something with the final pattern of data from “ls“. The shell script describes a machine more like a prototyping board in electrical engineering. The Unix shell is a more convenient way of starting programs than keying them in by hand with switches on the front of the machine.

Why is this error dangerous?

If you regard the Unix shell as the interface to the machine, then writing a program consists of linking up pieces in the shell. The programmer may have to venture into some other world in order to create pieces, but those pieces are thought of as the atomic units. Among such programmers, all projects will end up producing shell commands. Each command will have its own file format, or ape the format of another command. There will be no publication of algorithms, only publication of shell commands. After a certain point the programmers realize that they are running out of descriptive names that are short enough to type comfortably. They begin creating namespaces by having a single command accept subcommands: foobar create, foobar delete, foobar check, etc.

Among such programmers much of the “work” of the field will consist of dealing with file formats, resolving naming conflicts, and trying to find bigger, better ways to connect pieces, never realizing that all of these are irrelevant.

A program consists of algorithms that run on data structures. Anything that interferes with running the algorithms on the data structures is part of the problem set, not the solution set. File formats to get data from one program to another are a problem. Leave the result of an algorithm in memory for the next algorithm to operate on. Naming every possible operation and adding subcommands to avoid conflicts and reuse names is a problem. Use a language with namespace support, like anything designed since the 1970s. Bigger and better ways to connect shell commands — these go under the moniker of “workflow managers” — are a problem. Calling conventions ceased to be a topic of controversey in programming languages in the 1970s, and instrumenting programs to monitor and log their execution has spawned that exotic tool, the “debugger”.

The shell mindset results in two dangers. First, as the cruft wedged between algorithms increases, more and more of the field spends more and more of its time fighting through with it instead of real problems. Estimating from my own experience and observation of my colleagues, most bioinformaticists today spend between 90% and 100% of their time stuck in cruft. Methods are chosen because the file formats are compatible, not because of any underlying suitability. Second, algorithms vanish from the field. They are not published. They are not analyzed. They are not seen. I am not worried about a lack of understanding of the heuristics for solving NP-complete problems like sequence matching, though I would love to be. I’m worried about the number of bioinformaticists who don’t understand the difference between an O(n) and an O(n2) algorithm, and don’t realize that it matters.

I don’t know what to halt this process. It may be too late. Biologists are pouring into the field and being taught that the irrelevancies and trivialities of file formats and workflow managers are legitimate work. They go back and tell their colleagues that it’s all very complicated and difficult without ever seeing the really difficult parts of programming. We may be doomed.

What’s a scientist anyway? Someone who pipettes all day, or stares through a telescope? That could just as well be a technician, and often is, even if hidden behind a title of "postdoc" or "professor". Let’s take some folks who are scientists by any estimation: Newton, Linnaeus, Mendele’ev, Darwin, Boyle, Einstein. We could easily add an astoudingly diverse range of names. On the flip side we can name many who were appalling scientists, such as Watson and Crick, Thomas Aquinas, Lysenko, or any of the proponents of "intelligent design" that plague us today.

What separates these two groups? It’s not that one worked on a particular thing or in a particular way. The day to day methods of Darwin were much closer to Lysenko than to Newton. It’s not intelligence. Newton was indubitably a genius, but so was Thomas Aquinas.

It’s a question of virtue.¹ We utter "Lysenko contaminated his science with ideology" and "Watson and Crick stole data" and "Intelligent design beggars the question" in tones of moral outrage. These men are epistemically evil, just as Boyle and Darwin are epistemically virtuous. The virtues vary — objectivity was not one of Mendel’s great virtues, nor generosity with ideas one of Newton’s — but all acted in a manner which embodied some range of epistemic virtues.

So: a scientist is an epistemically virtuous individual.

Now look at the graduates of science departments around the world. They aren’t particularly epistemically evil, nor very epistemically virtuous either. Virtue is a question of habit. Decisions make ruts in our minds and repeated action, virtuous or evil, digs ruts a man can’t easily escape from. There are no such ruts impressed into the minds of most of the children emerging from university with their degrees. They have memorized some facts, perhaps learned some technical skills, but we cannot call them scientists.

Some of them go on to graduate school, where they may be shaped by an advisor, but it is just as likely that they will be ignored, and who knows what ruts will develop? In some fields, such a molecular biology, this has gone on for generations, and it is only by chance that you may happen upon a professor who is a scientist.

This is all very depressing. If lecturing the children and making them do laboratory experiments does not produce scientists, how can it be managed? We must drive some ruts through their minds in desirable directions, which can only be accomplished my making them do some science, and do it in such a way that they are not merely technicians but actively make and take responsibility for decisions with epistemic consequences.

They still need technical skills, or they won’t be in a position to act at all, virtuously or not. Some degree of the following are needed for a scientist:

• Mastery of both her native language and English to the point where she doesn’t create impressions in her audience by accident. Her palette of intentionally created impressions may be limited, but she will not inadvertantly lead her audience astray.

• Technical fluency in some means of experimenting, whether carpentry and metalwork, manipulating liquids, mathematics, or programming. Whatever the medium, the scientist must turn to her tools without mental hesitation.

• Explicit thought. Anyone who has taught programming knows most humans have never had anything but vague thoughts. Faced with the computer, they struggle. Much epistemic vice is due to an inability to recognize vagueness. Programming is the best way to learn this explicitness.

• Organizing definitions and categories. Careful choice of definitions and their arrangement vastly changes the effectiveness of a scientist’s thoughts². The best way to learn this is to solve problems in a dependently typed programming language like Agda in such a way that errors are semantically impossible.

• Expressing ideas directly in mathematics, without passing through English or any other spoken language. Spoken languages are poor vehicles for new thoughts. There have been great scientists who couldn’t express their ideas directly in mathematics, and they have, one and all, lamented their inability to do so. There is no such thing as a non-mathematical science, just fields which awkwardly embed their mathematics in English. It is also impossible to understand statistics in any useful way without this fluency.

• Break the human habit of thinking in terms of "A acts on B". A mind that has not replaced this with basic notions of relations and mappings is crippled. Essentially, every scientist must internalize the essentials of category theory.

Once we have a student with these prerequisites, how do we drive ruts through her mind? We must give her role models and guidance, and then put her in situations where she must apply epistemic virtues.

The role models needn’t all be present, or even alive. A scientist who hasn’t read the founders and great investigators of her field, and understood how and why they approached the problems as they did, is at best a dilettante. A physicist who has not read Newton and a neuroscientist who has not studied Cajal are both pitiful creatures.

Someone does have to guide the student, though. Someone has to choose problems big enough to challenge her but not so large as to swamp her or make it too difficult to act virtuously (remember, we must be sure we lay ruts in the right places). Someone has to be a colleague to the student as she tackles the problem, and critic when she has finished. The written works of dead men don’t suffice.

And what kind of problems should the student get? I’ll offer some ideas which cover epistemic issues I think all scientists should address:

• Measure something out in the wild that cannot be found via controlled experiment in the laboratory. It could be the population of fish in local waterways, or the incidence of a disease in the area, or anything in astronomy. Observational studies offer scope for epistemic problems which the laboratory scientist can blissfully ignore.

• Plan an experiment limited by available resources. It could be a small clinical trial or an industrial project, but the outcome must matter and the resources to run the experiment must be sufficiently hard to come by that the student must do the experimental design and analysis correctly. All scientists today must come to terms with the foundations and practice of statistics.

• Measure a parameter with a precise, fixed value, such as the speed of light or the fracturing stress of a material. The student needs to know the worry of hunting for systematic errors in an apparatus while trying to produce a correct value.

• Choose the objects of study in an area without an established theory. Scientists who have always had clearly delineated definitions — the mass of an object is important, its color is irrelevant, etc. — are often at a loss when faced with nature in her raw form. The student should be faced with raw nature with no guiding theory and forced to impose mental order on some corner of the world.

• Explore a solid theory, such as classical mechanics or chemical thermodynamics. This is a chance to know what the outcome of successful science looks like: a solid, predictive theory on which you can base a discipline of engineering. The student also learns how much there is yet to be done in even the best established fields.

• Engineer a tool. The student must learn the difference between hacking something together for herself and producing a tool for others. There is only one way: she designs the tool, then is forced to watch silently while someone else tries to use it. Then she redesigns it, watches again, and on and on.

This list is by no means comprehensive, but it provides the student with a chance to exercise many epistemic virtues, and to find those which suit her best.

Unfortunately, this kind of education would require restructing the universities and firing a large number of professors. Since that is unlikely to happen, however desirable it might be, I’m afraid it’s just going to be a studiously ignored ideal.