Specifically, many ~1-year-old services have bird names. Some of them aren't so bad. Our big-graph database service is flockdb, which sounds like something that might hold a big social graph. (It might even be easier to remember than "pregel," the name of a similar database, which only makes sense if you know some obscure urban-riparian geography.) Some names make less sense: Why is that called Ostrich? Why is that called cassovary? If there were just one or two bird-y services, it might be easier to keep them straight. But there are dozens of them. I'm not an ornithologist. My brain doesn't have that many separate, uhm, pigeonholes for bird-names; I get them mixed up. I'm not the only one; new engineers grumble about it. Not-so-new engineers grumble too.
More recently, services have cropped up with "boring names". We say "boring names" but there's a note of relief in our voices when we say it. I forget exactly what the name of Twitter's ad service is but that's because I don't have to remember it: It makes sense. I guess it's something like "the ads service."
But there's always the temptation to backslide. Even for me, and simplicity-of-explanation is my stock in trade. I blame Steve Yegge, as one does.
Steve Yegge works on a project called Grok. (Works? worked-and-now-champions? I dunno, I'm out of touch. Furthermore, a bunch of folks besides Steve work on it. Anyhow.) It's a pretty neat project, by which I mean it could change software engineering. The gist of the idea: right now, every programming editor program wants a parser for every computer language. That is, if your fancy IDE is supposed to know how to format a C function, it needs a simple C parser; and another parser for Java; and on and on. If you want to try out Erlang but your IDE doesn't have an Erlang parser, you probably give up. Obscure languages stay obscure: they don't have good tool support. If someone wrote an Erlang parser for some other IDE, your IDE can't use it; you have to start over from scratch. Since only chumps start from scratch, you probably give up on Erlang.
The Grok project is basically a parser-for-tools standard: if you design a language, you write a grok-parser for it, and that will output an parse tree in a standard format; if you design an IDE, you design it to read that format. A new language doesn't have to write 20 parsers to support 20 IDEs. An IDE doesn't need 20 parsers to support 20 languages. Nice
At Twitter, we write a lot of Scala. There's some nice tooling for writing Scala, but I think about the future when Twitter has more Scala to wrangle and I dunno if our nice little tools will keep up. Maybe Grok will save us! (More likely, at least in the near-term, excellent hardware will save us. But maybe Grok!)
I was thinking about these things, when the wordplayish part of my brain had a clever-stupid brainstorm: It will fall to Twitter to write the Grok-parser for Scala. And "Squawk" would be a perfect birdy-name for such a project: a birdy Sca-ok sound. I felt insufferably proud of myself. Probably I felt as proud as whoever named "Ostrich." But then I thought: if you already knew it was a Scala-Grok parser, then "Squawk" would make sense. But if you just heard "Squawk," you might not think Scala-Grok. You might think... when do birds squawk? When they're alarmed? If I hear the name "Squawk," I assume it's a service that monitors machines and sends out pager alerts when those machines look crash-y.
I had to tell you about that bit of wordplay so that you can marvel at my cleverness. But I hope that if we ever do have opportunity to write a Grok-Scala parser that we call it something like Grok-Scala.
