Solarized (everywhere!)

The black text on white background always seemed to cause me eye strain. On the other hand, the white-on-black or green-on-black seem too intense (too high-contrast) after a while, and made switching to a browser with its white background (yes, I’ve tried out the “high contrast” extension in chrome, it screws up colors too much for my taste) a jarring experience.

Then I came across Solarized (yes, late to the party, but that’s ok), and now I’ve enabled it across everything I use — which in my case happens to be a a couple of environments — OSX (terminal, emacs) and Linux (terminal(s), emacs). Here’s what I did for each:


Run M-x package-install (you might have to run M-x list-packages to refresh the list), and select solarized-theme. This assumes you have the MELPA package archive configured. If not, add this line:

(setq package-archive (("melpa" . "")))

Once the package is installed, add the following to your .emacs:

(load-theme 'solarized-dark t)

Gnome terminal

Run the following:

wget --no-check-certificate
mv dircolors.ansi-dark .dircolors
git clone
cd gnome-terminal-colors-solarized


Run the following:

git clone
cd guake-colors-solarized


Download this zip file, then from the iTerm Preferences, select “Profiles -> Color -> Load Preset”, and select the theme from the solarized directory in the unzipped contents, then select the imported theme.

That’s it! Have a happy solarized rest-of-your-life !

Free Software is a protest movement. Open Source is a weapon. I can see a significant constructive element to Free Software, but I can’t see any with Open Source. Linux is not a success to be repeated, just like Microsoft is the last of its kind.

In both cases, however, men in suits with their ties so tight blood supply to the brain is cut off believe they know what caused these successes and attempt to emulate them through some incidental quality that has nothing to do with the success.

… the programming environment model in Unix is an imitation of the Lisp machine, and the way it is implemented is through processes and inter-process communication instead of function calls.

Functions in the Lisp heap are programs on disk in the Unix model. the optimizations that made Unix able to survive this incredible inefficiency are bad for Lisp, which would have done it a lot better had it been in control …

Lisp Books

This is something I’ve always pieced together bit-by-bit, and I’m sure a lot of other people have done the same by combining occasional blog posts, reviews on Amazon, perhaps a few mailing lists, and so on.

Adam Tornhill has reviewed a bunch of these, and I’ve read them and agree with most of them, so here is an index to some of them:

(My own current path is slightly different, btw. I had read SICP many years ago and definitely need to re-read it, but I started with Conrad Barski’s “Land of Lisp” and am now slowly working through Graham’s “ANSI Common Lisp”, hoping to move on to PAIP once I’m done)

I’m not arguing against type theories, not arguing against the usefulness of various forms of type inference, not arguing against reasonable requests, not arguing against the desire to reason about code, not arguing against tools to ensure correctness and all that good stuff.

I am arguing against the belief that types belong in the compiler and not in the running system, and I am arguing that the specific idea of a “parameterized type” is moot in Common Lisp, both because we have typed objects and because we have a type hierarchy for all types with specialization on disjoint types.

I am arguing that parameterized types are necessary when you accept disjoint types and believe in the compiler as your only savior.