In particular, I’m referring to the level of confidence a language can impart that when you call some method (or evaluate some function) in a particular language, your code will work the same afterward. This is directly related to side effects, and how much you have to “know” about the function’s implementation in order to use it. I’ll colloquially refer to this as “trustworthiness”.

At one extreme, a language might not especially concern itself with ensuring trustworthiness. If whoever wrote the method you’re calling Did The Right Thing, the method is trustworthy. Ruby is an example of a language like this: fully dynamic (”duck typing”) and extensible at runtime (”monkey patching”). I can do normal mutable stuff and touch storage locations that other code might care about in Ruby, but I can also write a method which affects the semantics of other methods; for example, when you’re inside Rails, the String class is enhanced with a bunch of utility functions. Here is an extremely contrived example:

def foo(a)
  a.respond_to?(:bar) ? a.bar : nil
end

def baz(a)
  a.class.instance_eval do
    define_method(:bar) { "barbarbar" }
  end
  nil
end

foo calls its argument’s bar method, if such a method exists; baz takes an object and extends its class with a bar method. Then, this series of calls evaluates like:

foo("abc") # => nil
baz("abc") # => nil
foo("abc") # => "barbarbar"

As you can see, the method foo isn’t idempotent. It’s not possible to write a Ruby method that you can guarantee to be idempotent unless it evaluates to a literal, because everything else is a method call on an object, and the behavior of existing classes and object instances can be modified at runtime. So, for example, even:

1 + 2

Isn’t guaranteed to be 3, because + is a method call, equivalent to 1.+(2). Of course, no one ever worries about this in real life, because you would be evil if your Ruby library changed the definition of the + method on Fixnum. But there is nothing to prevent it. So, Ruby is very versatile in its flexibility; as a trade-off, it is difficult or impossible to guarantee that your code will exhibit some set of particular semantics at runtime.

At the other extreme is something like Haskell, which is purely functional and strongly typed. I’m new at Haskell (though have some experience with other pure FP, typed languages like standard ML), so this next section might have some syntax errors. Anyway. Values are immutable, so you cannot change state, only write code that produces new values. Every expression has a type. Side effects are hidden in monads, which can be made one-way by the type system. In Haskell, producing a side effect like writing output goes to the IO monad, which “sucks” code into a world where the possibility of side effects happening is made clear by the type system. For example, putStrLn looks like this:

putStrLn :: String -> IO ()

It takes a String and returns an IO (), which you can think of like a queued IO action. When the action is eventually performed, it prints the given string out followed by a newline.
You don’t get information about types inside the IO (), so you can’t pull information out of it. The only way to “evaluate” the effect and have something actually print is to use the monadic binding function, whose type looks like this for the IO () values putStrLn produces:

String -> (() -> IO b) -> IO b

So you provide the string to write, but then you must provide a function whose type is () -> IO b. In other words, to perform the side effect, you have to produce code that returns a value wrapped “inside” the IO monad type. For example, check out this function, times2, which takes one argument (an Integer for this example, although without the type signature Haskell will derive this to a typeclass function on anything under Num a), and produces a new integer, the argument times 2.

times2 :: Integer -> Integer
times2 i = let x = (putStrLn "a line")
               y = (putStrLn "another line")
               z = 2 in
           i * z

Does calling this function cause those strings to be printed? Nope. Haskell’s evaluation is lazy, and the things we are binding x and y to in the let block are expressions. That means they will only be evaluated if they are actually needed. We return i * z, and so x and y don’t make it out of the function. Nothing can ever get to them, so they can never be evaluated and no side effects will happen. In fact, because Haskell is strongly typed, any values that could get out would have to be a part of the function’s type signature, so without even looking at the implementation, you could guarantee that no side effect would happen:

times2 :: Integer -> Integer

See? There are no IO’s in there. So no values that could possibly produce IO side effects can come out of this function. Additionally, there is no function in the type system that lets you “get out” of the IO monad; in other words, any function that takes a value of type IO must ultimately produce another value of type IO. It’s like a roach motel for side effecting execution: code goes in, but it doesn’t get out. So, if there were any deep, hidden code in our times2 function that made the IO happen, IO would have to percolate out into the type signature of times2.

That means that I can use any arbitrary Haskell function, and if IO isn’t somewhere in the type signature, I am guaranteed no IO effect can happen. There is no well-typed statement that would allow it. Code that doesn’t involve the IO type must willingly pass a “side effects ahoy” line to a domain that allows side effects, by “getting into” the IO monad and picking up the type. So code that doesn’t involve it can have guaranteed semantics, no side effects allowed, no changing of state. The tradeoff is that you have to adhere to strict rules.

Clojure is somewhere closer to the middle, at least in spirit, if not in strictness. The core Clojure data structures are immutable (as in their values are in Java final variables), so if you stick within the domain of those data structures and the functions that operate on them, you can have code that’s idempotent. Evaluation is eager, but much of the standard library supports lazy evaluation by producing sequences, which are like cons cells whose cars are thunked. There is no strict type system to force you to be visible about side effects or warn callers about things you might do. So most Clojure code is written in such a way that the side effecting parts are hidden in private namespace functions, and the public interface is functional. There are well-defined ways to have statefulness in Clojure, so you can write code that must be explicit about its side effect-ness:

(let [a (atom 0)]
  (defn post-inc! [n]
    (let [curr @a]
      (do
         (swap! a #(+ % n))
         curr))))

(post-inc! 1) ;; => 0
(post-inc! 1) ;; => 1
(post-inc! 1) ;; => 2

Here, post-inc! is obviously not idempotent, but we had to explicitly create a reference type and use a subset of functions in our code restricted to that type. So, if we stick within Clojure’s core types and semantics, we can have areas of guarantee. For Clojure code operating with other classes on the JVM, say a Java API, though, all bets are off, since we can’t guarantee anything about the side-effecting nature of external JVM code.

As far as laziness, you can opt-in to it, and code generally shouldn’t have to care if it operates at the sequence level of abstraction.

(defn int-range [a b]
   (when (< a b) (cons a (int-range (inc a) b))))

(defn lazy-int-range [a b]
   (when (< a b) (lazy-seq (cons a (lazy-int-range (inc a) b)))))

(int-range 0 5) ;; => (0 1 2 3 4), realized in memory
(lazy-int-range 0 5) ;; => a lazy sequence of  (0 1 2 3 4), realized when consumed

Which allows you to write expressions like (lazy-int-range 0 100000) with causing a stack overflow, but doesn’t require sequence consuming code to know whether the sequence is lazy or not to do what it needs to logically. So you are able to opt-in to many interesting language features like laziness when solving a problem; the tradeoffs are that there are more rules than Ruby in the optional parts, and that because the strict parts are optional, you don’t get the semantic guarantees of Haskell.

In a future post, I hope to get into the “related behavior” bit, discussing the ways that the 3 languages approach it: Ruby with its object-orientation, where data and behavior are packed up in classes and instances; Haskell’s typeclasses and instance derivation, where behavior is specified in a named unit, a typeclass, and concrete implementations give types membership in that typeclass), and Clojure’s new protocols/deftype feature (behavior is specified in a named unit, the protocol, and concrete “types” that implement it are made through deftype‘d factories), which seems spiritually very similar to Haskell’s typeclasses. As always, thanks for reading!

I was also very glad to avail myself of the opportunity to dive into some books. I used to read voraciously. To my chagrin, these days I spend a lot of time skimming or reading articles instead of reading books. But, I read a few on the trip, and the one that’s fresh in my mind is Stephen Fry’s Moab is my Washpot, an autobiographical account of his years as a child in the British preparatory and public school system, up to his acceptance at Cambridge.

If you don’t know Stephen Fry, well, I probably can’t do better justice for a biographical sketch than the wikipedia page. Primarily an actor and writer, I’ve long been a fan of his work, first becoming hooked by his performance of Jeeves alongside Hugh Laurie’s Bertie Wooster in the 1990 BBC run of Jeeves and Wooster, itself adapted from the brilliant Jeeves stories by P.G. Wodehouse.

Moab is a wonderfully witty piece of work, describing his early years and self-discovery as a writer, life in a British preparatory school, love - and complete lack of ability in - music, coming to terms with his sexuality, falling in love for the first time, and embarking on an early life of crime ending with a felony conviction for theft at the tender age of eighteen. The best autobiographies are both poignant in their description of formative experiences and piercing, connecting you to the author in shared experience. Each human life is a perfectly unique, ramshackle collection of experiences resulting in you, but we are all transformed in the same ways throughout life, emerging from the crucible of adolescence as proto-adults, with most of our basic foundations intact. Successful autobiographers reveal things in their books that people otherwise vigorously hide away; deep corners of their psyche, hopes and fears that they share with no-one else. The same hopes, fears and secrets that we all have. The trick of the gifted autobiographer is to share these things and connect them to the same hidden pockets inside you; to make you - a nameless, faceless reader Out There in the world - a close friend and confidante. If they’re really good, they’ll do so with an envious ease that all great writers seem to summon without a thought.

I quite recommend this book if you like autobiographies, Stephen Fry, clever writing, the nostalgia of British country life in the 1950’s and 60’s, or any combination thereof.

Java is not my favorite language to write. I find it to be verbose to the point of lowering productivity; I feel as if I write more metainformation to the compiler about what I am doing (specific types, access and visibility modifiers everywhere, checked exception declarations) than actually implementing the logic to solve a problem. I understand the point of view that Java’s explicitness and compile-time type checking produce better code, I just think it is wrong. There are many legitimate reasons to dislike the Java language’s design choices. I won’t detail them here; you’ve either heard them all before, or you can find many examples with a simple Google search.

I am, however, very impressed with the JVM as a platform. It’s stable, well supported, and well understood; whoever is in charge of deploying your software is probably comfortable with deploying and administering a JVM instance. Optimization techniques in the JVM continue to get better and better, particularly with some vendor implementations (such as HotSpot with Sun). You can get heavily optimized code that is very fast without a large amount of effort. As a digression, watching recent developments in optimizing bytecode is very cool (see clang/llvm, the jvm/hotspot, the .net clr, etc) and I’m excited to see how things progress in the future with those projects.

The takeaway here is that the JVM is a great platform. And now that there are several languages written to run on the JVM that are not Java, you have some great choices as a developer who maybe doesn’t so much enjoy writing Java. You can choose a JVM bytecode-compiled language that best fits your problem space (Groovy, Scala, Clojure, etc.), and immediately be able to leverage the huge number of libraries out there written for the JVM, including the Java standard library. And get nice, fast code while you’re at it. Great! All we need now is a specific bytecode instruction for dynamic method dispatch on the JVM, and life is sweet - so it’s a good thing that such an instruction is planned for the Java 7 specification.

1. Clojure is a LISP…
   It displays homoiconicity, which means (roughly) that code and data are represented in the same way in Clojure (as s-expressions). This has deeper implications that I can cover in a blog post, but, for example, if you have written code to do a particular kind of list manipulation, it can act equally on actual lists of data, or a list that represents an s-expr to be evaluated. Clojure fully supports macros, which allow you to modify the s-expr tree as it passes through the reader. It has a minimal syntax that elegantly models computation, especially if you view computation through the lens of the lambda calculus. In other words, it’s a LISP!
2. …minus some historical baggage
   
   Clojure sports a selection of core data structures that offer particular semantics and performance guarantees; the core structures are implemented efficiently and their design is well-considered. When applicable, functions exist to act on various abstractions as a structure (for example, there are functions that operate on anything that looks “sequential”, and most of the core data structures provide a way they can be viewed sequentially). From my perspective, Clojure very much wants you to “use the right tool for the job”, and provides several high quality tools in its toolbox to enable you to do so.
3. It’s functional, with immutable data types.
   
   What a pleasure it is to be able to view problems through a few different lenses, and how tiring it is to always view a problem through the OO lens. There are many arguments for (and against) functional programming; if, like me, you are a fan, you will be happy to learn that Clojure data structures are immutable (let’s omit discussion of the new “transients” feature for now). You do not (and in fact, if you are using one of the built-in Clojure datatypes, cannot) modify an existing value. “Changing a value” means “creating a new value with my changes”, implemented efficiently through structural sharing. This means a lot of good things, one of which is that…
4. Clojure does concurrency the right way.
   
   Writing concurrent software is hard, especially if you model your concurrency around controlling access to a central mutable storage location. Unfortunately a lot of concurrent software is modelled this way. Most of the difficulty in this method comes in controlling access to the central mutable storage. Code written in this style is usually about acquiring locks, doing stuff, and releasing locks, and constantly balancing lock acquisition with its tradeoffs (acquiring a lock is usually an expensive operation, so you can’t spray lock acquisition everywhere; if you hold a lock, you are solely responsible for preventing deadlocks and making sure you release it at the proper time, etc). By contrast, having immutable data types remove a lot of this complexity: threads can’t modify the same value, because modifying values is verboten. I’ll just give you a value I want you to do some work with, and I never have to worry about you modifying some state that might affect my execution, because you can’t modify any values in my thread: they are immutable! See Erlang’s message-passing concurrency model for an example of this type of approach. Like datatypes, concurrency in Clojure is exposed by a handful of discrete concurrency operators offering particular semantics and performance, each is well-supported, and each is well thought out. Check out the ref documentation on the Clojure page for one example.
5. It does many other things right.
   
   Lazy evaluation, robust interaction with the host platform, and a comprehensive core library are just some examples of this point. You may not like some of Clojure’s design choices, but if you watch some of Rich Hickey’s screencasts, you can’t argue that the design isn’t a carefully considered one.

Enough talking; let’s write some code. Euler problem #24’s problem statement basically says:

Given the digits 0 through N, and all permutations of those digits, arrange the permutations lexicographically, and return the nth permutation, for N=9 and n=1000000.

Like many Euler problems, there are many ways to solve this one, but I’m feeling lazy - literally. My solution will be to construct a lazy data structure that enumerates all the permutations lexicographically, and then write code that realizes the nth permutation. Easy, right?

So let’s write a method that produces this lazy data structure. Let’s suppose we’re given a set of numbers that are ordered lexicographically (0, 1, 2… N). Here’s an inductive method we could use to enumerate every permutation of those elements in lexicographic order:

1. Take the first element of the set; call it H. The remaining elements of the set (still in order) are T.
2. Recursively generate all permutations (in lexicographic order) of T.
3. Take each permutation of T and prepend H to it: the resultant list is the ordered permutations of the input set that begin with H.
4. Repeat with the second element of the set as the next H and T to be the set with the second element removed, then with H as the third element, and so on until the set is exhausted.
5. The sequence of lists produced in this way represent every permutation of the original set in lexicographic order.
6. As a base case, the empty list has only one permutation: itself (the identity permutation).

That’s a lot of pseudocode, but easy to express in a couple lines of Clojure:

(defn permute [coll]
   (when-let [s (seq coll)]
         (map (fn [x] (cons x (permute (remove #(= x %) s)))) s)))

This works for my solution because map and remove produce lazy sequences in Clojure. Laziness is pervasive in most Clojure sequence operators; operators that realize sequences generally tell you explicitly that they will do so. In other words, the result of applying permute to a collection will be a bunch of queued function application, and the evaluation will only happen when you actually reference a particular item (and then only as much as needed to realize that item).

The method above will return a sequence of two-element (cons) cells; the head (car) of each cell is an item in the permutation, and the tail (cdr) of each cell is another (ordered) sequence of all the permutations that start with the head element. It’s essentially a tree modeled as cons cells. Finally, the when-let handles our base case: when the sequence is empty, when-let will evaluate to nil.

Let’s assume there’s a factorial method in clojure. It’s trivial to write one of your own. We’ll use this to count how many permutations are in a particular subsequence, since the number of permutations of N elements is N!. Since each cell in the sequence that permute returns is the head of all subsequences that start with that element, as we move through the sequence and skip over a cell, we’ll want to know how many permutations we passed over. This will let us navigate to a particular permutation, like permutation number 1000000.

Next we’ll write the method to seek to the particular permutation we want in this data structure; let’s call it seek. This is a helper function, so we’ll declare it with defn-, so it doesn’t pollute our namespace (if we compiled this code to a class, it would become a private method). Here it is:

(defn- seek
  ([s parts i acc]
   (if (empty? s) acc
     (let [partsize (factorial (dec parts))
           permutation (nth s (quot i partsize))
           data (first permutation)
           remainder (rest permutation)]
       (recur remainder (dec parts) (mod i partsize) (conj acc data)))))
  ([s parts i] (seek s parts i [])))

Most of the logic of the problem is here. There are a few things to note. One is using arity overloading to make the default for acc the empty vector ([]), if one isn’t passed in; this seems to be idiomatic Clojure, as far as I can tell. You may also notice that the seek function is written in fake tail-recursive style (passing an accumulator and using recur), since the JVM doesn’t natively support tail-call optimization, this is syntactic sugar Clojure gives you to simulate it, by making iteration look less iterate-y.

So, this function takes a sequence of permutations in the format returned by permute, the number of elements the permutations represent (called parts), the element you want to seek to (i), and an accumulator; the permutation found at position i will be appended to the accumulator.

If the sequence is exhausted, we can’t iterate any further, so we return the accumulator. If not, the method finds which element of the top-level sequence the ith permutation lives under, remembering that every element we skip over really skips over parts! permutations that lie underneath it. So, we identify how many top-level elements of the sequence we want to skip over and do so: (nth s (quot i partsize)). We identify, within this subsequence, the index of the permutation we want to find, which is (mod i partsize), in other words, if you have 100 elements divided into 5 buckets of 20 items each, and you want element 43, you want element 3 (43 mod 20) of bucket 2 (43 quot 20). Then we recur with the subsequence to find that element.

Finally, we tie it all together to answer the problem:

(defn ith-permutation [n i]
  (let [coll (range (inc n))]
    (seek (permute coll) (count coll) (dec i))))

We generate the numbers from 0 to 9, inclusive, create all of the permutations of those numbers with permute, then seek to the ith element with seek. It’s not even that slow for the parameters of the euler problem (microbenchmarking caveats ahoy).

user=> (time (ith-permutation 9 1000000))
"Elapsed time: 4.103 msecs"
-answer omitted-

Not bad, especially since this method was our first pass and we haven’t done anything to make it more optimal. This blog post became a lot of text, but think about what we did once we started coding:

• We expressed the problem in a simple way: finding the right element in a structure of all possible elements.
• We then naively generated that data structure in code. We didn’t eat a bunch of CPU and memory because the data structure was generated lazily.
• We expressed searching through this data structure inductively, in terms of finding the right sub-structure to look in, then recursively looking in it.
• Our code solves the problem and is reasonably fast.

There are certainly more succinct ways to solve this problem, and like many Euler problems, doing a little math on paper can help you discover methods that are faster; we essentially brute-forced it, but we didn’t have to incur too much pain to do the brute-forcing, thanks to Clojure’s lazy sequences.

Whew! That was a long blog post! If you’re still here, thanks for reading! You can find the code for this post at a gist here. In addition, if you were intrigued by Clojure, you’ll find good links and excellent documentation at the home page. I also really enjoyed watching some of the slide presentations at the blip.tv clojure site; in particular I recommend “Clojure for LISP programmers” (or “Clojure for Java Programmers” if that’s your thing).

I hope to blog more about Clojure soon.

Here’s my latest:

How’s the crumb, you ask? Behold my works, ye mighty, and despair:

I bought a peel on Amazon, and decided to try it out by making some pizza. I hoped the peel would help dough to stick less, but it was still thoroughly sticky. Either I’m not using enough cornmeal or I have to grease it or something, or it sticks, and that sucks, especially when you go to slide a pizza into a hot oven and the toppings slide off instead. So I read about a trick with parchment paper that should hopefully work for all sorts of stone-cooked things. You place the dough on a piece of parchment paper on top of the peel, and it slides straight off onto the stone. The stone’s hot enough to bake the bottom of the crust through the paper; parchment paper can withstand the high heat for a few minutes. After waiting a couple minutes for a crust to form, pick up the pizza a bit with the peel and slide the paper out, so the crust is right against the stone, and then just finish as usual. Very handy!

After making some dough and letting it rise, this ball (B-A said it was “adoughable”):

Plus basil, chopped garlic, olive oil, and shredded mozzarella, became this:

And after a short failed peel experiment, came out like this:

You can see the streaks on the crust where some of the cheese slid off due to the sticky peel. It tasted really good, although it was a little high of an edge-to-topping ratio. It’s a nice meal and a good way to use up those mushrooms or peppers that are about to go bad in the fridge.

I also went to the Savory Spice shop, which was pretty incredible. Nice smells and a huge selection.

For dessert, I made an apple-pear tart. There were some really nice apples at Whole Foods, so I just went for it. Everyone really enjoyed the meal. I got a request for beef or poultry next time.

First, if you’re local and know of a good place to buy fresh whole fish, I’m all ears. The best option I’ve found is to call Whole Foods. I’ve talked to a few people at their seafood counter, and inferred that they buy from one of a few sources locally that cater to restaurants and food markets. Seattle Fish Market in Denver is one of these places. You can’t, as an individual, purchase small quantities direct from these wholesale suppliers, but you can get it on buys through your local Whole Foods. Some caveats I’ve found are that you have to give them good lead time (at least a week) if you want something really specific, but they can often find something that will work for you on shorter notice. For example, this week I decided somewhat late in the game to make fish (for 4), and while I couldn’t get a whole 4 pound fish on short notice, I can get two 2-pounders. This isn’t really the same amount of meat (extra heads, bone, etc.), but it’s close enough for my plans since I was a little heavy on the serving side with a single 4 pounder (3/4 to 1lb per person is a good rule of thumb for whole fish unless it’s a weird variety that is extra bone-y or extra meat-y). Plus, I can always make dessert or another small course to make up for it, which adds work for me, the cook, but if you find cooking joyful, that’s not really a problem.

A couple short words about French food: it’s easy. If your mental imagery of French cooking is tiny portions artfully served for very high prices, well, that’s a bit sad. It’s true that that particular style of presentation-heavy, palate-targeted cooking is a lovely and enjoyable art form, but it doesn’t detract from the bulk of provincial French food enjoyed by all the social classes in that country for centuries. So anyway, here’s a meal I’m planing for this weekend. Future posts will get straight to the cookery, but hey, it’s my blog and I can pretentiously describe French cuisine if I like before getting to the meat of the post. Get it? The mea… yeah. Anyway.

I’ll be poaching fish (snapper) with a julienne vegetable medley and sauce parisienne, which like most French sauces is just a variation on one of the basic sauces, in this case a velouté made with fish stock and having cream and egg yolks added. If I wanted to be super pretentious I could call this Filets de poisson a la parisienne. The vegetable medley will be potatoes, carrots, and probably shallots or maybe a leek, something fairly classic that pairs with sauced fish. Here’s roughly what I plan to do.

Acquire, scale, and gut the fish, then remove the fillets and de-bone. I’ll also be getting some extra fish trim from Whole Foods (bones, heads - probably halibut). All the trim goes to making fish stock in white wine vinegar. The fish stock also becomes the poaching liquid and the base for the velouté and ultimately the sauce. All the prep and stock work comes earlier in the day. When cooking time approaches, I’ll go ahead and julienne the vegetables, then season and cook them. Next, put the fillets in a baking dish, add the vegetables and season the dish overall. In goes the fish stock, which then goes into the oven for poaching. After it’s done, the poaching liquid comes out into a saucepan and turned into velouté, then sauce parisienne. Plate, add sauce, some nice crusty bread, and pair with a good white wine. I could also brown the sauced fish slightly, maybe adding bread crumbs, and then I could tell people they’re eating the very impressive sounding Filets de poisson gratin a la parisienne.

If I’m feeling ambitious for dessert, I don’t think you can ever really go wrong with creme brulee, and it’s an easy addition if you don’t mind making caramel. It also gives me an excuse to check out a new spice shop I learned about courtesy Tara, the Savory Spice Shop in Boulder.

Almost 3 years have passed since the farmhouse incident, and while the investigators have found tantalizing clues and references buried deep in library archives to the sarcophagus and Marion Allen’s method of death, the trail has gone cold and no definitive answers have been found. However, the investigators’ efforts have not been in vain; characters who played through the farmhouse incident have gained skills over the past few years during their studies and made important contacts among other scholars, researchers, and mystics, some of whom may become allies - or liabilities - in future investigations.

With a particular interest in Egyptology and the occult, all the members of the team remember the ill-fated Carlyle Expedition. Even laypersons can recall details of playboy Roger Carlyle’s well-publicized journey into inner Egypt in 1919, subsequent safari into Africa, and the eventual massacre of the expedition by death-cults in the remote interior of that country.

It’s not until now - 1925 - that one of Thurber Upton’s close correspondents begins to draw a tenuous link between the Carlyle expedition and Upton’s strange tale, but the link may lead our investigators to knowledge both forbidden, dangerous, and of a scale they could not have imagined.

Note: Players have received a private link to handouts with background material on the Carlyle Expedition in preparation for our next session. Players playing investigators who survived the farmhouse horror will receive a skill point bonus, to distribute as they choose, for skills they may have gained during the (2+ year) intermission between that and this scenario. Dates from the last scenario have been retconned to a few years earlier to prevent me from having to update dates on supplements for the next adventure.

A small skill point bonus will be awarded to players who can spot the video game reference in this post without using Google.

At the deathbed of respected Misaktonic University literature professor Rupert Merriweather, 4 of the professor’s acquaintances met and learned the professor’s secret: years earlier, he and a group of 5 other naive students, under the guidance of an older mentor, Marion Allen, formed a group dedicated to the study of spirits and the occult, called the Dark Brotherhood. After several failures, a new artifact (and associated ritual) provided by Allen gave the group its first and last success: they were able to summon an otherwordly Thing in a farmhouse outside Allen’s Corners, Massachusetts, which promptly beheaded one member of the group and drove the other insane.

Fleeing in terror, the group concocted a plausible story for the death of one member (and the catatonic insanity of the other) and vowed never to speak of the night’s events again. Nearly 40 years later, as Dr. Merriweather reached the final stages of terminal lung cancer, he summoned the 4 investigators to his hospital room, knowing that after his death any binding magic on the Thing would fade and it would be free to roam the countryside, unchecked. Giving them Marion Allen’s artifact and journal notes from the Dark Brotherhood, he urged them to help dispel the Thing he had so recklessly summoned years before.

The 4 investigators were drawn from various backgrounds, linked only by their mutual acquaintance to Dr. Merriweather. They included:

• Thurber Upton, a veteran and former battlefield medic, handy in a pinch with a revolver and schooled in the treatment of the serious physical trauma likely to be encountered in a war zone. Equally at home shooting a hobo through the femoral artery or treating the wound to prevent him from dying.
• Stanley Clark, snake-oil salesman extraordinaire, skilled in the art of misdirection, persuasion, and outright lying. Claims to have sucessfully sold an icebox to an Eskimo acquaintance. Valuable when you need a diversion, to convince someone to take a cheap bribe, or a shot of an “all-natural, fantastic, homeopathic elixir to cure hair loss, vapors, the gout, and rickets”.
• Cale Graves, a businessman who operates a successful bookstore dealing in rare volumes, while drawing the bulk of his finances from a private (and equally successful) bootlegging operation. Having both legitimate and illegitimate business, Graves possesses a wide variety of skills, including a working knowledge of chemistry from his bootlegging business as well as unparalled library research skills gathered while establishing a successful rare book emporium.
• Dr. Thelonius Doom, academic and respected professor of Psychology at Miskatonic University, skilled with ancient languages and gifted with a working knowledge of the fledgling skill of Clinical Psychiatry.

The investigators accepted Dr. Merriweather’s request and handily succeeded in dispatching the Thing lurking in the farmhouse attic. Along the way, the investigators explained the disappearance of Maggie McPhirter, local farmer’s wife, ensuring her soul could rest at peace when Cale Graves destroyed her reanimated body with a shotgun blast at close range. An unlucky hobo, Red Jake, had a more frantic meeting with the investigators, and ultimately sealed his own fate after bolting from the protection of the farmhouse to be subsequently killed and reanimated by the Thing and then killed again by a second blast from Graves’ trusty boomstick.

Over the course of the investigation, the group discovered several odd pieces of information that continue to defy explanation. While most of the original Dark Brotherhood died after the farmhouse incident due to natural causes, Marion Allen’s case was not so simple. During the investigation, the group discovered that the existence of the mysterious artifact Allen provided to the group, a small Egyptian sarcophagus originally containing an insect trapped in amber, was not a secret known only to the Brotherhood:

1. Before Allen’s death, he complained to police that he was being pursued by a group bent on recovering the artifact.
2. Soon after, his body was found near the docks, his clothing showing signs of being in or near a fire, and his tongue cut out with a sharp-bladed knife.
3. Strangely, neither the fire nor a bladed weapon were the cause of his death; the coroner was unable to find a definitive cause, citing foul play via coronary arrest, induced by unknown means.

The artifact itself is now safely locked in Cale Graves’ safe, although since the creature once contained in it has been dispelled, it possesses no occult properties. However, it is still a curious and valuable piece of antiquity, being made of solid gold. In the course of their investigation, the group learned the following facts about the artifact:

1. The inscription on the artifact’s case is Middle Egyptian, cryptically referring to a “Seeker of Wisdom”; after translation, the text is best represented in English as:
   

   "Seeker of Wisdom, Servant of Yoag Setheth,
   Deliverer of the people of the water,
   Bearer of the spirits of Nyar-loth-hotep,
   child of Thoth, Seeker of Wisdom."
   

2. Another inscription on the inside of the artifact’s lid is not Egyptian at all, nor is it a language any of the investigators can identify, despite thorough attempts with the aid of local libraries and academics. As best as they can identify, the language is similar to script found on artifacts that are claimed by less-reputable scholars to be from the ancient continent of Mu, said to be the location of fictional lost cultures such as Atlantis.

Returning to Boston after dispatching the Thing (and respectfully disposing of the rather messy remains of Maggie and Red Jake), the members of the group struggle to understand and explain what they saw in the farmhouse.

Unable to let the mystery rest, some begin to search for clues to the history of the artifact and how a mere dilettante in the occult like Marion Allen came to possess it…

But lately, we’ve been distant. To be honest, you’ve become a little shrill. I spend a lot of time now just trying to filter all of the stuff you spew at me every day. You’ve always been a little slangy and cliquish, but I have to admit that I’m beginning to honestly despise what you’re doing to the English language. Because I hang out with you all the time, I have to put up with it, but honestly, can you try to control yourself a little bit?

You’re caught up in fads. I don’t want to gossip all the time, and I don’t need to know the minutiae of all your friends’ lives. How do you even have that many friends? Why are you telling me what some girl you went to kindergarten with is going to see at the movies tonight? You talk an awful lot, but say little. I think you’re giving me ADD, if such a thing is possible. It’s always little soundbites with you. You can’t talk about a single topic for more than 30 seconds.

So I think we need to go on a break for a little while. I’ve… I’ve decided to read some books and stay away from you for a while. Look, I know we have to see each other at work, and I know I can read books on you too, it’s just… I need some space. Let’s just try to be adults about this. It’s only a few novels, and maybe, a little nonfiction. Just give me some time. We can work this out. Wait, why are you laughing? What do you mean, ironic?