Rationale

The fewer lines of code there are, the fewer bugs you’re likely to have. Generally, if you can say a lot with fewer words, without loss of precision or intelligibility, it’s a good idea. It’s also a good idea to push complexity down by using language features or standard libraries to do the heavy lifting for you.

What I find attractive about functional programming patterns like higher order functions is that it allows you to push some of the complexity downward, into the language or standard libraries, without losing expressiveness. You can say more with fewer words. If we want to accumulate a list of even numbers between 1 and 20 in Java, it ends up looking something like this:

List<Foo> fooList = getFooList();
List<Foo> fooBarList = new List<Foo>();
for (Foo f : fooList) {
  if (f.hasBar()) {
    fooBarList.add(f)
  }
}

This example is a bit contrived, but not terribly so. Filtering a list of items is relatively common, and despite that, this has a lot of lines for such a simple, common operation.

Lest it seem like I’m picking on Java, I’ll show you a rough equivalent in Go:

fooList := getFooList()
var fooBars []Foo
for _, f := range fooList {
  if (f.HasBar()) {
    fooBars = append(fooBars, f)
  }
}

We have less boilerplate in terms of declaring variable types, but it’s still a lot of lines for filtering a list on a simple boolean test.

I pick on Python a lot, but this is extremely simple in Python:

foos = GetFooList()
foo_bars = [f for f in foos if f.HasBar()]

This, I would say, is a nearly perfect ratio of lines-to-operations. You could even replace foo_list with GetFooList(), but let’s not get carried away. Ruby takes this even further and provides a number of similar patterns for the Array class.

I know this is crazy talk, but I think this is extremely powerful. You can express your intent very clearly in fewer lines. Your readers (yes, readers) are free to focus on what you are doing instead of how.

If you read about FP, you’ll also hear a lot about state. The notion is that if you’ve got methods attached to a class, the state of that class is implicit input to any given method. Coming from a testing perspective, I believe this makes a class harder to unit test. Sometimes you must store state, obviously, but in general a method which has explicit inputs and outputs is easier to test. (I suppose this is also applicable to trying to reason about what a method does mathematically.)

What was sort of revelatory to me is that, actually, a lack of mutable state isn’t so crazy (h/t Haskell Amuse-Bouche). If you’ve used *nix for getting work done, you’ve probably done something like this:

grep -o 'foo.*bar' ~/baz | awk '{print $1}' | sort | uniq -c

None of those are actually changing any state. You’re just filtering input. If you take the above — avoid state, give functions explicit input/output — to a reasonable conclusion, what you end up with is a glorified pipeline like what you see above. And this is one of the ideas behind Haskell.

A simple example and then done

In Haskell, you can compose a series of functions pretty easily, like this:

map (negate . abs) [5,-3,-6,7,-3,2,-19,24]

It’s a slightly goofy math example ripped off from Learn You a Haskell, but you get the idea. We chain together functions negate and abs as one function, and then map that onto the following list.

The concision here is impressive, although I find “real” Haskell considerably more difficult to read so far. Haskell programmers are very fond of one-letter variables and the syntax itself is so expressive in part because it is so concise. If you can decode it, it starts to become beautiful, but it’s that decoding part I still struggle with.

As I delve more into Haskell, I’ll probably blog about it. This is enough for now, though.

Still, this is as good as time as any to talk about the first one. Lately I’ve spent some time with the Go programming language.

Go

If I had to sum up Go in my own words, I’d call it the spiritual successor to C, with modern sensibilities. It has concise and lightweight syntax. It’s memory safe (read: garbage-collected) and strongly typed. It has powerful concurrency primitives at the language level. It has a unique approach to interfaces where they are actually orthogonal to data types, not unlike Haskell’s typeclasses. It has first class functions and lexical closures. And it has a rich standard library.

Although Go doesn’t ship with a REPL or interpreter, there are some projects out there. However, there’s also http://play.golang.org/. As far as I’m concerned, this is close enough to a REPL that I’ve found it extremely useful for prototyping, testing out a package from the Go standard library, and I’ve even written code I’ve ended up keeping later.

Go threads the needle between providing a strongly typed language which is more productive than C++ and orders of magnitude less verbose and clunky than Java. It’s more performant than your average scripting language, yet the standard library is just as rich and easy to use. I would probably not go back to Python except for ~100 line helpers, or glue code which is just above shell scripts in terms of complexity.

It’s tough to pick good examples for some rough comparison that aren’t already covered in the Go docs. But here’s one of my hobby-horses, something which is easy in some scripting languages.

Processing command output

This is trivially easy in shell scripts, and shell scripts were made for processing text. Perl makes it approximately as easy, and as Ruby borrows so much from Perl, it’s similarly easy.

In Python 2.x, it’s terrible. I’d rather not write this in C++ or Java.

Here’s how you run a simple command in Go and capture its output:

// exec lives under the os/exec package
out, err := exec.Command("foo", "--bar", "baz").Output()

out is the output, an array of bytes. You’ll want to split it in lines and iterate over it, treating it as (say) an id and a username along with it.

lines := bytes.Split(out, '\n')
for _, line := range lines {
  // Split by spaces.
  fields := bytes.Fields(line)
  fmt.Println("id is %v. username is %v.", fields[0], fields[1])
}

Notice the lack of type declarations. Most of the time you use := to declare and initialize at once, which ends up feeling a lot like Python or Ruby. The difference is that the Go compiler infers types based on return values and the like, granting the benefit of type checking.

Further reading

I could come up with more examples. I’m trying not to! That’s because you’re better off playing with something like the Go tour. Trust me: you might think it a bit silly at first, but there are exercises and the app will test your solution. It’s very good.

The Go site is rather good, as well. There’s [a Go tutorial] wherein you write a wiki which is worth your time. You should read Effective Go if you’ve decided you’re actually serious about it.

Advantages

• Vim keybindings for 70% – 90% of the commands I use (e.g. ci(, marks, :w)
• Find in files
• Cmd-R to jump to a symbol
• Command-T-style fuzzy completion of filenames via Cmd-P
• Projects (i.e. a list of files spread across disparate dirs accessible via Cmd-P)
• Menu commands executable through Cmd-Shift-P, complete with fuzzy matching
• A sensible configuration & plugin language
• Fast. Buttery smooth.
• Linux AND Mac compatibility
• One license, all of your machines

It’s not that Vim can’t do most of this stuff (modulo the sensible configuration language). It’s that all of the above works out of the box. There’s a litany of things that I’ve just never quite gotten to work right. For instance, CommandT worked for a while and then broke. I don’t mean to pick on anybody. But this was not uncommon.

That was perhaps the single biggest reason that I switched.

At another point, I was trying to fix bugs in a dozen or so Python scripts, themselves scattered across three or more different subdirectories at various depths. In ST2, I added all three dirs to my project, and I bounced between them with Cmd-P quickly and easily. It just worked. And it’s fast. It breaks my heart to say it but Vim felt positively medieval in comparison.

I also look forward to learning how to write plugins. I’ve never been able to convince myself to learn Vim’s scripting language.

There are some disadvantages worth mentioning.

Disadvantages

1. Split-pane isn’t as good as Vim
2. Inaccessible via the Terminal
3. Not libre or gratis
4. I may run into cognitive dissonance wrt Vim bindings

With ST2, you have to switch between a canned set of layouts rather than being able to ad-hoc split pane. With Vim, I have anywhere from 3 – 5 panes open, and with ^W and some handy \ew aliases (edit file in same working dir as this file), it’s mostly muscle memory.

I can’t use ST2 in the Terminal, which means I’ll have to fallback to Vim. That’s not the end of the world, but it is inconvenient.

I hesitated for weeks, having taken it for a test drive for some of the toying around I’ve done with Go. But it wasn’t about FOSS. It was about the price. Why pay for a text editor when there are N free ones available?

That said, I am willing to pay a little bit of money to get the job done. (Shit, if time is money, it’s already saved me a ton of time.) And I know that I’m supporting a small and independent developer. I want to live in a world where people can make money off of developing kick-ass software.

Vintage (the plugin for ST2 which adds Vim keybindings) does have some limitations. “, double grave, doesn’t work right. g; and g, don’t work. I’m sure I’ll run across more.

Conclusion

It’s been some weeks since I switched, and I haven’t really looked back. If you’ve got the dough and you’re looking for an editor that’ll help you step your game up, I recommend you check out Sublime Text 2. As I said, it’s a free trial.

When I was introduced to Python, suddenly programming was fun again. It was hard to imagine going back to anything like C++ when I could become so productive so quickly with Python.

I held to this view for a very, very long time. I appreciated how languages like C++ or Java would be useful for writing “serious” applications, but I didn’t write that stuff. That was for other people.

In the last year or so, I’ve gradually come to believe that a strong type-checking system AND a high-productivity language ought not and are not mutually exclusive. The corollary is that I will consider carefully before I use a scripting language for anything more than a thousand or so lines.

The first sign of trouble

The first time I ran into serious trouble with a scripting language was a few years ago (yikes). I wrote a script in Python which would monitor some servers for updated software and kick off a job when they were updated. It was less than 1000 lines, but despite knowing better, I did a poor job keeping it clean. And because it was such a mess, of course I had no tests.

Without unit tests, I had to test it manually. The cycle was something like: write a bunch of code, and run the whole dang script. This was time-consuming and error-prone. I’d miss things. Basic things. The script itself wasn’t mission critical but I found these bugs and the script itself personally embarrassing; I knew better, and I knew I knew better.

Still, I was otherwise quite productive in Python. Around the same time, using the Django framework, I wrote a server which slurped XML-formatted test results and allowed the user to view results grouped by various properties. It was very fast to write, and I could hardly imagine doing it in C++ or Java.

I had three experiences in the last year or two which rearranged my prejudices.

JavaScript and the Closure Compiler

The first was working in JavaScript land, with the Closure Compiler. JavaScript was far less restrictive and, in my opinion, more expressive than Java. The compiler caught some of my dumb mistakes and I grudgingly came to value it. However, it didn’t catch all of my mistakes and the ones that it did not catch were sometimes difficult to track down.

The lesson I learned was that even the slightest type-checking can really help save you from yourself. It also makes refactoring (and thus maintenance) easier; adding or removing a parameter, or passing in the wrong type can be difficult to debug in a language like JavaScript.

Java

The second was working in Java land. I wrote a framework which would test a remote API. I had to do a lot of fighting with the language, with a lot of boilerplate and book-keeping. I missed closures and first class functions dearly; contrary to what I thought at first, Java does have a very limited form of closures, in the form of anonymous inner classes. The lengths I had to go to get certain pieces working was comical; at one point, I wrote a FactoryFactory. I’m not kidding! And I’m not proud of it, but the language and API I was using drove me to it.

However, up to this point in my career, I don’t think I’d spent as much time with a decent IDE on an extended project. Several aspects were revelatory. I’ll mention two.

1) The type system gave me substantially more confidence that I was doing the right thing most of the time. I spent more time fixing incorrect assumptions about the API, adding error-recovery, or simply writing code than chasing down basic mistakes. I do that in any language, but the difference here was that the IDE and language eliminated an entire class of mistakes as I introduced them. By the time I ran my program, I had substantially more confidence about its correctness than I ever did in Python.

2) If you haven’t yet, read Martin Fowler’s Refactoring. The short version is that there are a set of highly mechanical techniques you can use to facilitate refactoring. Furthermore, many Java IDEs support many of these operations. Even something as basic as renaming method calls or variables within a specific context is massively more helpful than dumb S&R.

Lest I seem insane

Despite all that, I still wouldn’t program in Java again by choice. I want closures. I want first class functions. I want built-in higher order functions, for that matter. I want syntax and/or a syntactic paradigm (think variables or methods like fooByBarWithBazAsQuux) that’s substantially less verbose.

It’s the difference between

numbers = [1, 2, 3, 4, 5, 6]
evens = numbers.select {|x| x % 2 == 0}

and

// I'm sure this is still invalid for many reasons.
ArrayList<Integer> intList = new ArrayList<Integer>() {
  1, 2, 3, 4, 5, 6
};
ArrayList<Integer> evenIntsList = new ArrayList<Integer>();
for (Integer i : intList) {
  if (i % 2 == 0) {
    evenIntsList.add(i)
  }
}

That? That up there? It hurts me inside. The compiler makes it harder for you to screw it up, but you still have to do the whole song and dance every. Single. Time. You spend ~6 lines on an operation which, in the grand scheme of your program, ought to be small and trivial.

Python

Speaking of Python, I started relatively recently on refactoring a set of Python scripts responsible for kicking off tests. Nobody owned these scripts and consequently they languished as multiple people had patched or hacked on them to fix bugs or add features. The scripts were a mess.

Furthermore, there are few thousand lines of these scripts, plus thousands of lines more in the form of libraries which the scripts use. There were and are tests, but obviously nobody ran them because they were all broken.

After having spent so much time in the Land of Type-checking, reality came rushing back. It scary to make changes without having any confidence that they were correct. I wrote tests to find basic mistakes which would not manifest until runtime.

I would say that this was the biggest shock and what did the most to change my views. A scripting language is very good for getting something running quickly, but in terms of refactoring and maintenance, it took two or three times as long as I thought it ought to.

A word about tests

You could make a strong case that the scenario above— writing tests to the point of boredom— is Working As Intended. I am strongly sympathetic to this idea.

You ought to write unit tests with good coverage no matter the language. Tools like autonose allow you to get feedback from those tests rather quickly. This workflow arguably gives you faster, more comprehensive feedback than one with just a compiler and manually run unit tests.

One hitch is that getting a good error message from a unit test requires an amount of diligence multiplied by the number of unit tests. A compiler does only catch a small subset of the problems a unit test would, but any decent one ought to catch them more reliably and precisely.

Anyway, I haven’t delved too much into larger-scale projects which are based on scripting languages, but my guess is that their approach is similar to this. Write testable code. Use frameworks which make it easy to write tests (with a nice DSL, flexible mocking, or what have you). Use frameworks which make it easy to run tests (such as speed and parallelism). Minimize the inherent friction and you’ll get something richer than a compiler alone would offer you.

The answer?

I’m still writing tests in Java. I’m still refactoring Python scripts. For obvious reasons it would be silly to introduce a new technology into an existing stack chiefly or even partially for my own personal satisfaction. Rewriting is a dubious proposition anyway, one that must be considered very carefully. So for practical reasons, the situation won’t change.

Even so, I still want to have some go-to language. What could I use for a new project, personal or otherwise which would have good odds of making me happy?

C++ is not memory safe. C is simpler than C++ but is also memory unsafe and has more trade-offs. In both C and C++, it can be very difficult to write basic functionality.

Java is memory safe and has a rich set of libraries, but as I’ve mentioned, I’m not interested.

So what’s the answer? What language or technology do I feel is most promising, offering a combination of strong typing and high productivity? I have one prospect, or even two. But I’ll save those for the next post.

I guess Monte Cook has been back at Wizards for ~4 months? And he’s been writing a column? This makes sense, given that there’s now an announcement about this 5e playtest.

Looking back on 4e, I still think it was a really solid edition, but I’ve come around to agree with some of the criticism with regard to losing some of the old school flavor. It’s inevitable that a thick layer of mechanics, no matter how crisply designed, are going to focus people’s attentions on that.

One part of 3e and Pathfinder I strongly want to remain addressed or fixed in some fashion is character power level. 4e rather strongly pushes a philosophy where PCs get a sort of metaphorical +2, and if nothing else, I found that to be a revelation. If there’s anything I would preserve from 4e, this would be at the top of the list. (Second would probably be: fighters and their ilk should not be inherently less interesting to play than casters as they have been with previous editions.)

This is in contrast to 3e and even Pathfinder, wherein you get some kind of bonus or interesting ability but there’s a trade-off baked into the ability. The game is balanced for characters without that sort of advantage, so any advantage a PC receives has to be offset with some penalty or substantial drawback.

I recall this being true in particular of the sorcerer’s at-will attacks. You get an ability to make some kind of attack. Fantastic! So I don’t need a crossbow? Well, not quite. A crossbow requires a move action to reload but it does 1d8, which is too much. It would also be too powerful for a caster to do more damage than some spells, so it’s 1d4 or 1d6 + 1 for every N levels of sorcerer. Oh, and at-will is too powerful, so you’ve got a fixed number of uses per day. There’s a neat mechanic attached to some of them which makes it worthwhile but in our analogy of 4e handing out +2, this is more like +0.5.

As you go on and on, you see that there’s a limit to how awesome even Pathfinder can make you. They can bolt on additional abilities all they want, but they must be 3.5-esque in terms of versatility and power level and they must be in lockstep with what’s gone before.

Note that, at least from a balance perspective, I’m entirely sympathetic. The system has got to work. And people who like 3.x are presumably fine with this. I mean, I’m saying all that stuff up there like it’s a bad thing! There’s nothing wrong with people enjoying that flavor of mechanics. Hell, it’s far and away more interesting than many of the 3e classes, especially for fighters and whatnot. Nevertheless, this is something that has bugged me ever since 2e and Pathfinder is more of the same when it comes down to it.

Anyway, I don’t want to spend all my time knocking Paizo’s product. More power to them if they can make something of the contracting tabletop RPG industry. It seems like both they and WotC have their work cut out for them, though. I fear I’ve turned this blog into some kind of platform of doom and gloom but I can’t lie: I suspect our hobby will only become more and more niche.

I found a list here, from the Unofficial White Wolf Wiki:

• Russell Bailey
• John Bridges
• Chad Brown
• John Chambers
• Mike Chaney
• Ken Cliffe
• Shane DeFreest
• Brian Glass
• Craig S. Grant
• Sara Luebke
• Aileen E. Miles
• Ethan Skemp
• Michelle Webb

You can hit the list of layoffs to find links to each person’s White Wolf CV. There are a lot of names here that go way back before you even start talking about such as Ethan Skemp and Aileen Miles.

I reiterate, this time with emphasis: holy fucking shit. It breaks my heart.

Now, I don’t pretend that I would even recognize any of these people on the street, let alone that I have any sort of personal relationship with them. I only have a relationship with these people insofar as I’ve spent countless hours curled up with books they’ve written, typeset, and otherwise lovingly crafted. I couldn’t have bought and read a decade’s worth of White Wolf books without recognizing at least some of these names.

It’s tempting to opine about the whole White Wolf/CCP thing. Of course some part of me feels bitterness. But if the complaint is that CCP is killing White Wolf, I have to wonder whether White Wolf would’ve survived, alone, for this long.

No, I don’t really have any big pronouncements. Recessions suck. I’m sad about RPGs being on the decline. White Wolf was one of my favorites because I like creepy and/or modern shit.

Arguably this is what happens when times change; the old stuff, which has its own merits and trade-offs, falls by the wayside or is otherwise transformed. They are replaced by new things, which also have their own merits and trade-offs, and will themselves, at some subsequent time, be replaced or transformed. It’s not the end because it’s never the end; RPGs live in on multiple forms. Many of their concepts and mechanics are now more pervasive than they’ve ever been. And in a more concrete sense, White Wolf itself still lives, as does WotC and numerous indie developers.

That’s about all I’ve got.

When Lion came out, I decided to check out the state of the art in ostensibly user-friendly (read: GUI) email clients. I don’t pretend to know much about how Apple Mail It was purely curiosity. But a number of issues have cropped up in my mind.

• Gmail can get really bloated, memory-wise. I was surprised when Mail took up less than 200MB; I assumed all mail clients routinely took up at least twice as much. Gmail often takes up something north of 500MB. (I suppose Chrome doesn’t help, if only because its multiprocess model necessarily involves a RAM tax.) Part of this is that I keep it open all the time, or rather I used to; now I feel obligated to close it now and then to keep my RAM clear. On balance, I don’t want to care about RAM, but in practice I feel I have to. I share a laptop with my -girlfriend- wife, which means Gmail effectively occupies 1GB or more. Running a Minecraft server on my desktop machine means I’m consistently down by 1GB, at least until I move it off.

• The idea of having my mail on every machine is less of a concern now. Chiefly this is because I have a smartphone; if I don’t have a laptop with me, I always have my phone. IMAP means that changes on one client propagate elsewhere automatically, whether it’s on the phone, the iPad, or a full-fledged computer.

• I can use an email client offline. This doesn’t happen that often, admittedly, and when I am completely offline I’m typically on vacation. Still, there were a couple of occasions recently where my connectivity was poor enough to make Gmail sluggish. A mail client simply had to download my messages once and I could read and search all of them without hitting the server via my flaky connection.

• An email client is consistently faster when it comes to common UI operations. This is not to say that Gmail is slow, at last not most of the time. Most of the time, it’s fast enough. But when it’s not, it’s quite frustrating when a simple search takes longer than it really should! Contrariwise, once a client downloads my mail, I’m not subject to network delays. Yes, the client can be slow due to limitations of my machine, but those same constraints apply to the browser as well. Furthermore, the difference between searching my mail via Gmail and on my own machine continues to narrow, at least for me.

• With Gmail + IMAP, I have the best of both worlds. I can check mail via a browser should I need to, but should I have the need, I can use the client. This is the strongest point in favor of retaining Gmail, modulo other logistical issues: it does’t have to be either/or.

That said, there are some significant drawbacks, at least to Apple Mail in particular as well as Gmail/IMAP.

• Gmail/IMAP integration isn’t that great. Or maybe I should say that IMAP itself isn’t that great. It’s a folder-based paradigm, which treats emails like files. I think that’s ridiculous. IMHO, people only think about emails that way because it’s been thrust on them, and it’s not like most people understand the filesystem paradigm in the first place. Labeling/tagging a message is a “copy” operation, which is dumb. Archiving a message means “move to All Mail,” which is silly, too. Overall I’d say the mapping is somewhat leaky. I’m not sure it’s anyone’s fault in particular; I prefer Gmail’s model, but I wouldn’t expect Apple to sign on to that model wholesale.

• Your -filters- Rules don’t sync across multiple machines. It seems that previously you’d have to pay for MobileMe to get this, which is/was ridiculous. Perhaps iCloud will fix this? It would be surprising if it didn’t, esp. considering they’re offering a full-fledged email service as far as I can tell.

• The keyboard shortcuts aren’t nearly as good. Although there are hitches now and then, for the most part I can drive Gmail entirely through keyboard shortcuts. Mail’s keyboard shortcuts are merely OK.

All this really amounts to in terms of my behavior is that nowadays I often have Mail open on my personal machines. I don’t shy away from using Mail on iOS devices, either. Beyond that, I still use Gmail for chat and I use it for most email operations that aren’t simply reading or deleting. The thought remains that I could, if I really wanted to, make the switch. I’m just not sure what it would take for me to do it; certainly I have no reason to now or in the near future.

Sometimes, in the course of one’s life, one is left with a one-off task. In this case, I needed to call a binary a whole lot of times, and do something with the output each time. The details aren’t important; I just needed to write a wrapper script for this binary, do a modest amount of processing on it, and then output the result to a file. This is a pretty common task, one to which the command line in general and *nix in particular is well-suited.

Now, for various reasons, I prefer not to do this via shell scripts. I don’t have a hard and fast rule for when or why. Unless you routinely write shell scripts (I don’t), you’ll inevitably spend a bunch of time looking stuff up that you looked up, oh, six months ago. Or at least I do. I don’t enjoy it, so if I can’t do it with a few commands, maybe one loop or so, then I prefer to use a scripting language. I have the advantage of better/clearer failure modes and simpler syntax and I feel like I’m learning something more powerful and more widely applicable in the process.

One of my “favorite” things to forget and look up again is the difference between [[ ]] and [ ] in tests. Another one is how you loop over a file or output from a command (while read line; do bar --baz $line; done <foo and foo | while read line; do bar $line; done, respectively).

If you have no trouble remembering this stuff or you write scripts often enough, I suppose this is moot. There was a time when I was scripting enough that I didn’t have to look all this stuff up every time, but that time is past. YMMV and all that.

Anyway, the point is that I probably could’ve done this with something like this (which is simplified somewhat):

ARGS="--bar=baz"
CMD="~/bin/foo"
KEY="quux"
MIN=0
MAX=10000
 
for $(seq 0 1000) num do;
  $CMD $num $ARGS | while read line;
    if egrep -q $KEY <<<$line; then
      value=$(egrep -o '[1-9]+$')
        echo "$num,$value"
    fi
  done
done

I’m sure I have a bajillion bugs in there. For example, I am not at all confident about the outer for loop syntax. And while it was easy to write, I’m not doing anything with command line args, doing any error handling, or anything like that. (On the other other hand, I uh underestimated how easy this was. That’s partially why I’m convinced there are bugs in there.)

I still don’t know how to write idiomatic (typo: idiotmatic) Ruby, so this is going to be very rough. Still, it feels natural to me, minus one or two hitches:

ARGS = "--bar=baz"
CMD = "~/bin/foo"
KEY = /quux/
MIN = 0
MAX = 10000
 
def main
  (MIN..MAX).each do |i|
    out = %x[ #{CMD} #{i} #{ARGS} ]
    out.split('\n').each do |line|
      KEY.match(line) do |m|
        value = line.split(' ')[1]
        print "#{i},#{value}\n"
      end
    end
  end
end

I’m not confident about the outer loop once again, and I’m not sure the call to match() will do what I want, let alone whether it’s elegant. Still, I feel pretty good about it. I love Ruby’s pattern of passing in blocks.

Fortunately or unfortunately, I had to use Python. And don’t get me wrong: I love Python. It is through Python that I learned to love scripting languages. Processing a file line by line was, I think, the real epiphany. And list comprehensions are wonderfully expressive.

But man alive is it awful for this sort of thing. I’m not even going to bother writing it out in Python. I’ll just excerpt, from the 2.7 subprocess docs. Here’s what they say should replace backticks output = \mycmd myarg``:

output = Popen(["mycmd", "myarg"], stdout=PIPE).communicate()[0]

Mind you, this is if you did from subprocess import *. Generally I don’t, which means it ends up looking like this:

output = \
  subprocess.Popen(["mycmd", "myarg"], subprocess.stdout=PIPE).\
  communicate()[0]

Yes, once you have it written, sequestered in its own function that you never touch again, it’s not so bad. However, this is firmly in the category of something I will not be able to (and have not been able to) remember months later.

It is also not discoverable in the sense that it’s highly particular— stdout=PIPE? Really? Compare and contrast opening a file (for line in open('somefile'): print foo(line) or [foo(line) for line in open('somefile')) with this monster. Even my Ruby example could have used backticks if I hadn’t remembered the %x syntax. The best I can say about subprocess is that it’s a) better than Popen in Python 2.4 (or whatever), and b) it’s easier to search the web for than %x.

The kicker of course is that rest of the Python script was very easy to write! However, since calling the binary was changing some external state, though, I had to make sure it was doing the right thing. In the end building and testing the call to subprocess.Popen() took longer than the rest of the script. In an otherwise elegant, no-bullshit, batteries included language, the subprocess module is a terrible blemish. It doesn’t look any better in Python 3.0, either, unfortunately.

Even more unfortunately, this is ultimately why it would be my preference to use either Ruby or shell. Ruby seems to work well for a variety of tasks, from writing a full-fledged webapp to some grungy text manipulation. You don’t have to compromise because it’s quite easy to use it for Python-y things as well as Perl-y things. It’s just a shame that Python seems to treat this case with a bizarre kind of fussiness incongruent with the rest of the language and standard library.

One of them was unboxing my roleplaying books. They’d been boxed up as part of some home improvement and I never got around to unboxing them. This weekend, I did. It’s hard to describe how I felt. It was bittersweet, in that I felt nostalgic but also some sense that I might be done with roleplaying for good.

And then just now, I saw that White Wolf had put up their publishing schedule for 2011 – 2012. Huh.

I’ll admit I’m less than thrilled by the whole V20 thing. (I guess we’re all curmudgeons now?) (Uh, “now”?) There wasn’t much thrill in a game I wasn’t all that interested in, although on some level I have to feel happy for the people for whom this is a big deal. The guy who runs my FLGS certainly seems pleased. My visits aren’t often these days, and he brings it up each time. I don’t have the heart to tell him I thought Requiem was a superior game by nearly every measure.

On top of that, I presumed that the nWoD was all but dead. Perhaps that says more about me than anything else: from glancing at DriveThruRpg.com, it seems there’s been a trickle of releases. It’s difficult to see at what rate with DriveThruRPG’s interface, but it doesn’t seem like that many. Maybe that’s consistent with the rate before the move to digital publishing in any case.

I’m rambling.

So then I see the new publishing schedule, and it’s an interesting mix. Releases are one per month, as far as I can tell, and the list goes out to 2012. Remarkably, it seems they’re releasing new material for the old games (including finishing up some of the old Technocracy Convention books, ha!). But the majority is either nWoD or Exalted.

Another notable piece is that there’ll be another nWoD expansion game, a remake of Mummy.

Finally, it looks like some of the print on demand stuff came through. On top of the oWoD stuff, a bunch of nWoD stuff will be on here. So there’s that.

My own hiatus

My thoughts on roleplaying these days are few and far between, as I’m sure I’ve reiterated the few times I’ve posted lately. That’s persisted. I’ve spent more time reading, coding, working, or goofing off. A big chunk of it is that my core gaming group is heavily ensconced in their own game, for which I have little interest. Hearing about their game evokes the opposite of what I’d imagined; the more I hear about it, the less I’m interested in roleplaying overall.

I’d say it’s a phase, as these things do move in cycles. Two year cycles, though? That’s the last time I posted any really coherent thoughts on roleplaying. Oh, I’m sure I’ve played some one-shot D&D since then. But I never ran Changeling, nor Dark Sun, nor Geist, nor anything else.

What’s funny is that when I was shelving my books the other day, I was reminded about how I kept acquiring books even after I’d ostensibly lost interest. I’ve got a fair number of D&D books I haven’t read. In my defense, some (but not all) were gifts. Some of the later Vampire: the Requiem books are mostly unread. I probably finished The Mage Chronicler’s Guide.

There’s something alluring about the books, though, as always. The Requiem clanbooks in particular were among the most enjoyable role-playing books I’ve ever seen or read.

This is all just a long way of saying that I’m sure I could get interested again if I tried. But do I want to? I’m not sure! This I will say: as of this evening, and it sure is tempting to crack open a role-playing book or two in the meantime. I might have achieved the point (seven years?!) at which there’s enough nostalgia to get me reading, if nothing else.

autocorrect

I didn’t realize this was going to be as big a deal to me as I thought. Actually, I’d forgotten about it entirely until I started writing a couple of blog posts. Thus I was pleasantly surprised when I realized the built-in autocorrect is actually pretty handy. The vast majority of the time it does the right thing! Were I using Vim to do most of my writing, it might not matter so much; Vim has so many handy motions that it’s easy to jump between words, sentences, and lines in order to fix mistakes quickly. For a standard (read: less arcane) input method like this one, though, I’ve only got the standard ctrl-a, ctrl-e, alt-left, alt-right, and so on. Having the OS correct the litany of stupid typos I make regularly helps.

I had sort of wondered why this wasn’t an OS feature in the first place. Input fields are common as mud and autocorrect has been a feature in word processors for a long, long time. So why isn’t it in the OS? Who knows? It is now.

Irrationally, I worry that a feature like this will erode my typing accuracy.

fullscreen apps

To some extent, I’m being conspicuous when I use them. There’s no real reason that I need to use Safari fullscreen while blogging. After all, Chrome is my main browser. But it does have a nice way of focusing my attention. I’m also trying out Apple Mail, and segregating it to its own space means I’m less likely to fidget with checking it.

mission control

I was a litte worried about Mission Control doing away with Snow Leopard’s way of laying out windows via Exposé. Leopard laid out windows sort of haphazardly and without obvious consistency. Snow Leopard made it into a grid layout, which made it a little harder to figure out which window was which but looked a lot neater and cleaner overall. Mission Control looks to restore it back to a semi-haphazard layout, grouped by application, which seemed like a loss of functionality.

What rescues it is the presence of a gesture for application-level Exposé. With that, I don’t have to Cmd-` my way through two or more Chrome windows. I’m not sure how useful Mission Control’s facility for selecting one or more of an app’s windows is, though.

launchpad

It’s pretty! I’ll give it that. But I am not sure how useful it is.

It looks like it finds all of your apps, which is a good thing overall. It’d be dumb if it didn’t.

However, putting them into iOS-style folders and whatnot is odd. For example, I’ve got a bunch of git clients (Tower, GitY, GitX, GitHub) sitting in my Applications folder. There’s also a Development folder in Launchpad. Except it actually corresponds to /Developer. When I moved my various Git.* apps around in Launchpad, it created /Applications/Developer which had only the Git.* apps in it.

Call it a leaky abstraction, I guess. Or a corner case, given that the majority of apps go under /Applications in any case.

scrolling, gestures

I’m fine with the new scrolling. I guess I’ve lived with it for a week, like I said I would, and I don’t feel like turning it off.

The gestures are kind of messed up out of the box, though. Two finger swipe for fwd/back is fine in theory but it doesn’t work at all in Chrome (expected; I presume they’d have to make a code change) or even System Preferences (!). It’s easy to switch it back to three finger swipe, and I did that.

I like the new scrollbars, although once again they’re hideous in Chrome. Chrome still has the old scrollbar gutter, and the gray scrollbar is always present. The Chrome team is working on it, or so I hear.

TTFN

That’s all I’ve got for now.

I sort of want to write something about Resume and whatnot, but I’m out of steam at the moment. Perhaps another time. John Siracusa’s excellent review of Lion covers this in more detail, and he probably says it better than I would anyway.