Deus Ex is "Deus Ex translated to Canadian French and back again"

Video games are software. They're also art, but they're made out of software. I've complained about this before, after playing Fable 3.0, I think. For a game that I don't love, like Fable, I'd rather just play the last of the series, the best one. The Fable series, and a lot of others, consists of successive repetitions with improved software at each new version. The trend of trilogies, which I'm pretty sure started for monetary reasons, may prevent this gormless repetition--if nothing else, they are pumped out so fast that only the content designers get a chance to refine things--the tech guys don't get a chance to overhaul the engine. And even if the designers view episode 1,2,3 as successive chances to refine the game mechanics, at least the writers will feel an obligation to make a coherent story line, one that won't make you feel ripped off for playing the same thing 3 times in a row. (Disclaimer: I tricked a friend into playing Fable 1.0 for me while I watched. But I did play all the way through Fable 2.0 and 3.0)

So Fable exemplifies the Sequel Remake, when someone decides that they'd really just like to make a few tweaks and release the same thing as a 'sequel'. Games have been around long enough now to have another kind of remake: the Borges Remake, in which the creators of Fallout 3.0 are not at all the same people that made Fallout 1.0 and 2.0. They are instead people who liked it so much that they wanted to recreate it from scratch. Like Borges' French author Pierre Menard, they take a break from writing nonsense like Les problemes d'un probleme to write chapters 9 and 38 of Don Quixote. From scratch. In the original Spanish. To be exactly as good as when Cervantes wrote it; in fact, exactly the same as when Cervantes wrote it. You can easily tell when a game is a Borges Remakes because usually the title is the same as the original. No additional numbers, only maybe a tiny subtitle in small font.

This seems like the ultimate fanboyism, and in the world of literature, that's probably all it is. But in video games, there's real money. After the one-two punch of the Nintendo Wii and the Great Recession, Borges Remakes have become proven safe moneymakers. Not only can you find plenty of people who want to make Prince of Persia again from scratch, you can find plenty of people want to play it again. Or Mario. Or Wolfenstein. When you only play a game or two a year, it might as well be the 'same' game that you played when you were 12. Anyway it sounds a lot like the remastered editions of Star Wars, or maybe the Lion King. They probably won't even notice if you change a bunch of stuff! (That's actually good--games have improved over time, so even an average game today will have some usability improvements compared to the brilliant games of the past.)

Eidos Ubisoft Montreal's Deus Ex is a whole-hearted Borges Remake, one of the pure-hearted fanboy ones (probably) (maybe). They decided to make Deus Ex. And they did. Really well. It's almost an exact copy. But over a decade has passed, and the innovative things about Deus Ex are no longer innovative -- almost all games have incorporated the good things from Deus Ex. So Deus Ex (by Ubisoft Montreal) turns out to be a very competent sneaking/shooter with a lot of dialogue options, while Deus Ex (by Ion Storm) was a brilliant genre-bending hybrid of FPS, RPG, and tactical stealth espionage action mumble mumble whatever Kojima sticks on the end of Metal Gear titles.

Really, the only place where Deus Ex (by Ubisoft Montreal) is worse is the overarching conspiracy theory. The conspiracies in Deus Ex (by Ion Storm) turned out not be that gripping, but it was mostly because they were so tangled and the game went on for so log, adding layer upon layer. The writers must have been really into it. The conspiracy in Deus Ex (by Ubisoft Montreal) is actually kind of stupid, and I didn't pay much attention because the Real Villains were introduced in the first five minutes via dramatic camera zooms and big explosions.

On the other hand, the new Deus Ex is better in a few places, mostly places that were 'modernised' and 'consolised'. Those two words mean pretty much the same thing except for the connotations. Basically, we (as a race (of programmers, and maybe of humans)) have figured out simpler ways to convey the same feeling of progression that a complex orchestration of numbers does. I support this change, although people who really like numbers may not.

Finally, the single worst aspect of the game was the translation. I don't how much of the game was written in French Canadian originally, but many of the in-game item/power descriptions obviously were. Also, a nice multi-cultural culture (or whatever it is that Canadians do better than us) turns out not to automatically translate into cultural knowledge of the US. Surprise!

Even though setting the early parts of the game in Detroit was a nice dodge for all the Canadian voice actors they hired (linguistic research has now discovered that as many as 80% of Detroit natives are actually speaking Canadian without even realising it), they apparently don't know that skin colour is not a perfect predictor of accent in Detroit. The voices are doled out strictly along lines of skin colour, so a white gangster sounds like a college student from Toronto, while a black one sounds like a Harlemite practising a Chicago accent (badly). That's not how gangs work! Everybody tries to sound the same to show that they're members of the same group.

The same problem applies to yuppies, and there are a few even more obvious and embarrassing errors, like the Hispanic ex-Marine who barely knows English (how did he survive in the Marines then?), and the African-American Detroit bum who apparently just arrived from Alabama, but has lived there for years developing a network of bum contacts for the police to use (? ? ?).

Overall, the voice acting and motion capture suck pretty ferociously for a AAA game, even for the main characters. Again, this feels it may have been conscious imitation of Deus Ex (by Ion Storm), or perhaps just clever allocation of a limited budget. It didn't stop me from enjoying the game, but it did make me want to pace around, sarcastically imitating David Sarif's always-enthusiastic monotone. I so wanted him to turn out to be completely evil, but he never did. At least I think he didn't. My sense of the moral landscape was fuzzy by the end, mostly because I stopped paying attention.

Due to a Hilarious Library Mishap, I have a huge stack of tech books on my desk at work. (Don't ask, it's a really long story of libraries not understanding technology.) The most interesting-looking of the stack, Domain-Specific Languages, I took home to read. It is heavy. (Which is why I asked the library for digital versions, and ... let's not get into that just now.)

I read the background section, about 150 pages, and the first few patterns/recipes. I get two conflicting impressions. first, DSLs is "Compilers for Mice". The background is a simplified, no-theory overview of compiler technology. Fowler over-simplifies the concepts so that they are 80% correct and all have non-standard names. In some cases he doesn't appear to understand the underlying theory himself. You could get some use out of this section, but you're better off reading the Dragon Book even though it's Real Hard.

The second impression is that DSLs is the "Compiler Cookbook". It's a list of things you will end up writing into your compiler if you are writing a Serious Compiler. So you might as well learn about them and use them for your Compiler-Lite as well. A lot of them are special cases of things that are explicit in the functional world, like the Writer monad or the State monad, and they have Special OO/DSL names like Notification or Context. But whatever. Still useful for first-timers.

Fowler retains his annoyingly myopic view of the computer language world as "Java". Every time he makes a statement about how rare, common or useful a language feature is, append "in Java" to that sentence. The most egregious statement is about how rare closures are. Most of the languages in use today have closures except C and Java. That's pretty common!

He also explicitly mentions that he knows little about functional programming. Missing functional programming per se isn't a big loss for this book, but functional languages attract a lot of the people working on language, so he misses or misunderstands some of the language techniques and culture that emit from there. For example, he muses at the end of one chapter something like "if only there were a book that explores alternative models of programming" (where alternative means non-imperative).

In conclusion, I have worked with this stuff way too long to remember what a newbie needs to learn. I am biased. From an expert perspective, though, there's an awful lot of the baby-talk and beneficient lying that accompanies mediocre teaching.

I just got my first Ship-It award yesterday, for release codename Denver. They happen every six months at Bing, so they're not a big deal, except that I didn't get one for my first six months there. Apparently partial credit doesn't count, even though I was there for all but one day of the Boston release.

Those awards are going start looking a lot cooler once we switch to bands for our codenames.

Megaman Legends is "8-bit mysterious".

As you stray more and more toward narrative videogames, it becomes clear that games have real trouble competing with novels in telling a coherent, interesting story, often because you can short-circuit the whole thing just by getting a game over. And they have trouble conveying deep emotions as well as movies, because you can always ruin the mood by deciding to jump in place for 20 seconds. The strength of games is in conveying a sense of place. The best narrative games tend to drop you in a place and let things play out from there. Shadow Moses. Tallon IV. Hyrule. Even, and I want to emphasise that I do not speak from personal experience, Azeroth.

So what's the minimum you need to convey a sense of place? Often the best art is found where the constraints of technology are the tightest. The imagination is powerful, and if you can use that to populate your world, just the smallest hint of a thing will be enough to fully flesh it out. When I played the tiny Gameboy version of Zelda (Link's Awakening), my imagination was the one providing the dreary, leaf-swamped forests, the sun-drenched plains, and the cold, steely dungeons.  

There are a lot of parallels between the bleary four shades of grey-green that Link's Awakening builds on and the shaky, barely textured polygons that Megaman Legends uses. On both the Gameboy and the Playstation, games appear to struggle just to paint pixels on the screen. It doesn't leave a lot of room for atmosphere-building--only the good games manage it. The secret, I think, is to stylise aggressively. Also, strict control of scope. So, two secrets: make the world stylised, keep the scope small, and make sure that detail is concentrated where the player is looking. Among the three secrets of atmospheric games are ...

Seriously, these are all one thing really. Find a fit between the hardware and the player's brain. Easier to do today, harder to do back then. Megaman Legends does it. The tradeoffs are draconian, and they weren't appreciated at the time, but I think they're the right ones for 3-D games on the Playstation. The biggest technique: reducing detail with draw distance, which is standard procedure now, but was rare at the time. Truth be told, the tradeoff is a little extreme. Small rooms are full of detail and actual clutter (a novelty for the Playstation). Big rooms are full of detail...in the immediate vicinity of the camera. About 10 meters away, a black fog makes the rest of the world invisible (note: sometimes it is a white fog). Face-to-face, the characters are the most detailed and animated on the Playstation. 10 meters away, they're a few big blocks stacked up.

Even though still screenshots make it look bad, it works better than you'd expect. The eye expects closer things to have more detail, even if the drop is extreme. The eye prefers to see real clutter instead of bare spaces, even if the clutter is 8-bit mysterious in its simplicity. ("Is that a key...or a clock?"). With most other Playstation games, you can tell that the game struggles just to put polygons on the screen. Megaman Legends, on the same hardware, has atmosphere.

So what does its atmosphere convey? Well, large parts of it are probably down to my imagination. Maybe you'll read its atmosphere differently. What I got was a sense of mystery at first. The world seemed designed for exploring; the beginning of Megaman Legends felt like the beginning of a Zelda game. But where a Zelda game spirals into a steady progression of tools and accomplishments, of dungeons completed and bosses defeated, Megaman Legends fosters a slow dread. Unlike Zelda, the dungeons aren't well-defined puzzle spaces--most are simple journeys to the bottom, then back again. Monstrous robots will try to kill you, because they guard some secret that no intruder must learn. Your weapons are puny and hard to aim. They are unreasonably powerful. You can see less than 10 meters. They lumber at you from the dark, audible long before they are visible. Killing them is hard, and often the only reward is money. No secrets: they die defending them, or the secrets never existed in the first place.

You quickly learn to fear any new noise in the dark. You can respond by ruthlessly grinding for money to upgrade weapons, or you can do what I did: get really twitchy and run away at every noise. Inch into rooms and jump back out if anything moves. Constantly dither between turning around and going deeper. Beat bosses by the skin of your teeth.

It's not clear whether this atmosphere happened by accident. I'm really tempted to say that it did, but I think I may be unfairly judging the Japanese game industry of the late 90s by the nearly-dead Japanese game industry of a decade later. You know what makes me decide that it was no accident? Another instance of genius--the control scheme. Seriously, the control scheme. Here we have another case of the game precisely fitting its limits--when Sony added two analogue sticks to the controller, Megaman Legends sprouted the same third person shooter controls that are used today. In 2000, the game had a control scheme that would be common by 2006.

So what happened after 2000? I titled this "Megaman Legends series" for a reason (though one reason is that I wanted to cheat and consider the best of both games at once). Capcom, after publishing the seeds of the modern third-person-shooter, abdicated to the West, which proceeded to incorporate all those seeds into the standard by 2006. Then in 2009 (or so), Inafuna, the creator, got a chance to make Megaman Legends 3.0. At least, I assume that this would have been a progressive, software-like refinement. It's possible that we would have gotten Megaman Legends: The Reboot. Of course this is all moot because Inafune left Capcom and Capcom canned the game. Inti Creates has made a number of Megaman spinoffs, but I don't think they will get the IP to Megaman Legends, so this really is the end.

Monster Tale is "evocative in a good way".

As Gabe says, the difference between an homage and a rip-off is whether or not I like it. Monster Tale is an homage to Castlevania and Metroid, plus a little Pokemon and Monster World. I liked it. It reminded me most of Symphony of the Night and Metroid Fusion.

Castlevania's levels are meant to be explored. They want to be explored. They're filled with the beautiful tension of enemies that mean to stop you (in the most ridiculous or undead way possible). With every new screen, you get to see a little more of the craziness that Dracula decided to pack his castle with. With every new screen, you may run out of health before finding the next save point. Symphony of the Night finds the best level of difficulty: every time the path forked, I stopped. I tried to guess which path led to a save point. And I debated whether to go back and save my exploration up to that point. It's no mistake that there's a huge exploration percent displayed on the map screen.

Compared to Castlevania, Metroid Fusion seems bossy. It's always telling you where to go, because Nintendo (unlike Konami) must have written down a policy early in the life of the GBA that games must be playable in 5-minute increments. That means a game that is not quite as mysterious as Super Metroid or Metroid Prime, both of which have the Valve Property: wandering around lost will get you where need to go--but it may take more than five minutes, and you may have a chance to absorb your surroundings first.

Like Fusion, Monster Tale sacrifices this organic mystery to 5-minute playtime, with the additional handicap that its target audience appears to be 5-year-olds. Not that a well-crafted Metroidvania can't get by without a good story (see: Portrait of Ruin, or, to a lesser extent, every Castlevania <i>ever</i>). Actually, Monster Tale is a lot like Portrait of Ruin in that its overall structure is a disconnected Mario-3-esque Theme World design. At least they aren't the literal Mario 3 Themes--instead of Desert/Water/Air/Ice we get Halloween/Runaway Train/Seaside/Club(?). I guess these Theme Worlds are places the authors think kids would enjoy, but like Portrait of Ruin, the Themes are skin deep coverings over level design that is actually a bit bland. A lot bland, if I'm being honest.

What saves Monster Tale is the difficulty. Although the target audience appears to be kids, the difficulty is aimed at, um, slightly older kids. Really, we were playing (and beating (some of us (not me))) games this hard by age 10 at least--Mario 3 is easily twice as hard. By modern standards, though, this is a hard game. I had to play four of the five bosses multiple times, learning patterns, fiddling with my pet to get the right combination of skills, balancing offence and defence. That's above average difficulty in today's world, especially for kids.

So parts of the world are Genuinely Dangerous, and health drops don't happen that often; I knew they had re-captured the Symphony of the Night feeling when I stopped for an internal debate at every fork in the road--which path seemed more likely to lead to a save point? Which would wear me down, kill me and waste my hours (5 minutes) of exploration? I could ignore the bland levels and haphazard enemy placement because I was having fun beating enemies and getting beaten. The enemy-juggling mini-game contributed to that, but it was mostly good old-fashioned meaty Castlevania Action.

Last, and actually pretty close to least, there's that Extra RPG Spice, permeating the gameplay like MSG whenever the actual flavour gets too boring. Here, the Spice is Pokemon, or something like it. Sure, it's manipulative, but watching your pet level gives the mind something to do when the body is backtracking through the lower-level parts of the world. Anyway, it's not completely straightforward--after I finished the game I visited gamefaqs and found out why some forms of pet never became available; the reason is that they have specific conditions besides "level up like crazy". So that's nice. It wasn't a lazy copout; they actually cared. In fact, most of the "innovation" in the game revolves around the pet, but it turns out most of the "fun" comes from core game copied from Metroid and Castlevania. Take that for what it's worth.

 

If you visit learnyouahaskell.com, you'll see that Learn You a Haskell For Great Good originated as a Haskell tutorial when the author decided he wanted to make sure he really knew Haskell. Haskell tutorials are a dime a dozen, especially monad tutorials, but that's exactly what it is; an introductory Haskell tutorial followed by a monad tutorial. It has the distinction that it is very well explained and much more complete than the average tutorial, as well as now existing in dead tree form. But it is not like Real World Haskell, which explains concepts in the order a practising coder would need to get a useful program off the ground. Learn You A Haskell For Great Good assumes that you are a practising coder in an imperative language, but generally explains concepts in order from simplest to most complex.

 

That's cool if you want a summary of the language, and if you're approaching Haskell as an enthusiast rather than a practitioner then you will probably like it. The focus is on expanding your mind, not (for example) finding the right tradeoffs between safe and succinct. It's arguable that this is the right approach for Haskell, which was traditionally a research playground, and the that the people behind Real World Haskell are engaging in wishful thinking when they try to make Haskell a production language.

 

Personally I prefer the practical approach (I've even used Haskell for scripting (!) before), but the tutorial approach has its advantages; it's a lot more thorough, and it covers cool new stuff in favour of things like database libraries. Even after 2-3 years of Haskell use, I learned interesting new things about Haskell's kinds, applicative functors and zippers.

 

The book is divided into two tuturials: basic Haskell and monads. The basic Haskell section is not too surprising--it covers the syntax and semantics of the basic constructs of the language. I think it could have done with a bit more emphasis on solving problems recursively, because the primary difficulty of learning Haskell is not the syntax. Really, it assumes that you are an intelligent person who is willing to work through new concepts yourself. If you don't already know at least one of: Lisp*, Erlang or ML*, then for additional help, you might want look at the Little Schemer, which does a great job of teaching recursive thinking without much language overhead.

 

*Popular members of the Lisp family are Scheme, Common Lisp and Clojure. Popular members of the ML family are F#, Caml and SML.

 

The other half of the book is a monad tutorial. It's tied with Real World Haskell for the best tutorial I've read. Instead of starting with ugly code and cleaning it up, Learn You a Haskell starts with functors, then progresses through applicative functors, monoids and on to monads. Although I suspect that this order does not recapitulate the history of these libraries, it makes a lot of sense. You get to see how functors generalise `map` on lists, then how applicative functors allow arbitrary functions to be lifted and applied in a functor (as well as providing left-to-right evaluation, which is something I missed when I was learning monads), finally ending with the way that monads allow chaining of functions to produce an imperative style.

 

I don't know if this is how the web site presented it--it takes a lot of space, but I think that it's worth it. If you have bounced off monad tutorials in the past, this one may work for you. You'll do a lot of reading, but you'll also end up with a wide, solid base for understanding monad usage.

 

Besides, if you get bored, there's always the fact that Learn You a Haskell is Officially Funny. However, the humour quickly fades into the background. This is no _why's Poignant Guide--the humour is closer to the occasional cracks in my ancient Learn Visual J++ 1.1 book. Well, I guess the drawing are pretty cool. I can't believe Capcom let them include a cartoony sketch of Quickman, but it's AWESOME. (There's also a Wiggler from Mario used to demonstrate head/tail.) Unfortunately, the drawings too fade into the background as they become less topical, or at least start referring to pop culture that I haven't heard of. Overall, it reminds me a lot of O'Reilly-quality writing. That's good but (and here I'm biased) not too surprising coming from the extraordinarily literate Haskell community.

 

Although the writing is good, it's hard for me to estimate how good the book is at teaching, since I already know Haskell. Fortunately, there is a chapter on zippers tucked in at the end, so I can use that to estimate for the rest of the book. Here, I easily acquired an intuitive understanding of what zippers are and how they work--the examples and analogies were good. But I didn't feel like I got a concrete understanding of their implementations, or when I'd need to implement my own. I'll need to actually play with zippers myself to understand them properly.

 

Bottom line: I didn't think too much of the basic Haskell tutorial, but I liked the monad tutorial. It's worthwhile if you have the patience to read the whole thing. Compared to the other two Haskell books I own, Haskell: The Craft of Functional Programming  (Thompson) and Real World Haskell (O'Sullivan, Goerzen & Stewart), Learn You a Haskell For Great Good fills the niche for smart programmers who already know an imperative language and want to learn Haskell for its own sake, covering concepts thoroughly whether or not they will be practically useful. The result is a more focussed book that covers less.

 

 

Machinarium is "professional".

There is a certain class of games that just make other games look amateur. "You can play around with your guess at 'fun'," they say with lordly caliber to other games, "but when you are done, the big boys will be over here with the quality." These are the kind of games that define a genre and spawn imitators. These are the kind of games that people will still play after the imitators are gone.

That's not to say that these games are perfect, but they exude so much confidence that we ignore their failings. They rewrite the rules for what a game in their genre has to be. Mario. Half-Life. Final Fantasy. Uncharted. Metal Gear. And, amazingly, sequels as well: Mario 3 and FF4, for example. (Maybe because the team didn't change between games, and they were brilliant TWICE?)

Without these games, a genre stagnates and falls into repetition. Look at JRPGs. For at least a decade, the only innovation there has been the guts to not have a spiky-haired, conflicted protagonist once in a while. Breaking with the mold isn't as exciting when you immediately pick up the previous mold. 

Western adventure games lacked confident games for almost a decade too--probably the confidence got worn down during the period when FMV adventures were supposed to be pretended to be good, then later when 3-D graphics were supposed to be pretended to be good (at that time, neither were, but nobody was allowed to say so). In the meantime, the good adventure games were the kind of innovators that boldly went back to non-3-D graphics and proceeded to nail one part of the old formula. Like Longest Journey, which did dialogue really really well. (And really really long.)

Machinarium defines the new standard for western adventure games. All adventure games after this must have a built-in hint system. Little puzzles scattered throughout. Maybe even wordless interaction.

More importantly, the reason that Machinarium is great is that it builds a world skillfully, like a pencil sketch, from a few well-placed lines. Despite the spare characterisation, the world is internally consistent. The game is funny, but lets the humour arise naturally from its whimsical world, not by making constant wisecracks. Every puzzle, even when it is frustratingly hard, is a delight to watch in motion.

Like other great games, the small points of brilliance outweigh the memory of the whole in my mind. Watching a robot use a ball-bearing pop-gun for target practise. Flooding a smoke-filled poker room. Refueling a diesel elevator from the kitchen food dispenser. Returning stolen instruments to a robotic jam session. Bringing a robotic greenhouse back to life.

Machinarium. If you haven't played it, you should.

I'm testing a new blog engine, blogengine.net. I plan to migrate my old posts on b2evo to this database at some point, and at that point I'll figure out how this blog will be shared between sandersn.com and cackhanded.com. Since cackhanded will probably stay as projects-only, I think I'll point both sandersn.com and cackhanded.com/blog to this blog eventually.

Supposedly this blog has code highlighting:

foreach(var language in languagesThatStartWithP)
  it(has, highlighting);
else
  noHighlighting(); // wait, are comments even coloured?

But so far Python didn't work, whereas C# did.

(henceforth, New Mario)

New Mario is "Mario 3".

I'm not sure what to say about New Mario. It's not like Star Wars where the old is clearly better than the new, and only those unacquainted with the old say otherwise. New Mario is good. But the reason it's good is that it's the same as Mario 3 and Super Mario World (and to a lesser extent, Yoshi's Island).

New Mario is even more polished than those two old games, but otherwise there's nothing new. If you ever wished that Mario World just had a few more worlds, then New Mario is precisely for you. On the other hand, if you ever wished somebody would come up with the Next Thing after Mario World, you might be more interested in, say, Mario 64, Braid or Super Meat Boy. And if you wished you could just reclaim that feeling from childhood of spending hours with your cousin trying to beat world 3-2 in Mario 3...

Well, don't be an idiot, Nintendo SELLS Mario 3 on the Wii. Just buy that and play until you reach World 3-2! If you're the type that hasn't played games in twenty years, you'll probably start dying there just like you did as a kid.

This is the reason I dislike New Mario: it doesn't need to exist.The target audience is not the person who appreciates New Mario for what it is (more 2-D Mario levels), but the nostalgic who has forgotten that the Wii has a Virtual Console. Nintendo made New Mario solely because they would otherwise be selling Mario 3 for $5.

Disclaimer: The one new idea in New Mario, multiplayer, doesn't seem to work. I suffered through a five-minute griefing session on level 1 and a twenty minute attempt to two-player-coop through 1-1 to 1-4. That ended badly at the vertically scrolling section. If the top player gets too far ahead, the bottom dies unless he's quick enough to push A to bobble up and let the top player reach a stable platform. I learned about that trick after we burned through our 10 lives in 2 minutes. Tycho calls it marriage poison and I suspect he's right.

Disclaimer 2: Yes, I know there is a New Mario on the DS. It's a bit simpler than this New Mario. If you must you can pretend that the DS version is the moral equivalent of Mario 3 while the Wii version is the equivalent of Mario World. But that's kind of stupid.

It's been about six months since I blogged about Fing. I've only touched the code a couple of times since then, so I will restart the series by describing the module organisation as it stands today, in the process of developing version 0.2

Fortunately, I wrote all this down six months ago on the fing github wiki, so if you want the details, including module contents, look there. This is a module-level overview.

Util

Utilities. That usually means: utilities that ship with Haskell but not with F#.

Types

The basic types, plus basic operations on them: fold, map, string formatting.

---

Everything below this line depends on Util and Types (except for Opt).

ParsedTypes

string → internal type representation. For example, user entered types.

FSharpTypes

F# Powerpack Metadata → internal type representation.

CSharpTypes

C# Reflection representation → internal type representation. This is not implemented yet; maybe it should be called DotNetTypes instead.

Search

Search for functions matching a given type.

---

Everything below this line depends on everything above this line (mostly).

Fing

The public interface: string → list<result> and related operations.

Opt

Command line parsing. I can't believe this isn't part of the standard library.

---

Program depends on Fing and Opt

Program

Command line interface. To be augmented later by other kinds of interfaces, probably an ASP one next.

Most of my time so far has been refactoring and working on the woefully incomplete tests. Earlier I made a conscious decision to push out a number of features without testing so that I'd have something people could use. Now I'm coming back through and writing the missing tests.

My approach was to build a decent database of types for testing. Most of my tests then assert that a property holds about all the types. This is a lot like QuickCheck, but without the random generation. I personally think it serves me better, because I manually generated all the complex cases of the grammar without recursion on the obvious cases. I could be missing stupid-simple cases, of course. (Also I didn't want to mess with installing F#'s port of QuickCheck—without typeclasses, I assume that it's kind of klunky and painful.)

For example, my newest test asserts that, for all types, if you shuffle the order of type variables, then run Types.index, you will get the original type back. This holds because (1) Types.index overwrites type variables with ones in canonical order and (2) all my test cases were manually created with type variables in canonical order. Actually (2) is a bad idea; it's OK for parser testing but is overly simple when you start testing semantics.

The more I think about it, the more I think I may need something like QuickCheck, at least some hacky fuzzing of my existing, over-regular test cases. That should probably be the next major step in the testing of the code, even if F# Quickcheck is painful to install.