Java Concurrency in Practice is a book by the Java folks who designed ConcurrentHashMap and all those other tasty Java ConcurrentThingies. I didn't finish reading it, though I liked the part that I read. You know how the scary aspect of programming Design Pattern books is when tyro programmers want to use all the design patterns they learned right away? Java Concurrency in Practice made me want to
spawn threa start Executors all over the place, when... I'm not really writing that kind of code right now. At work and at home, I work on code where some geniuses have already figured out the multi-threaded web server framework, have already designed the ConcurrentThingies data structures for me to build on top of. All the changes I found myself thinking about were just complecting; I should use the code the geniuses wrote. I put the book down; I know where to find it again if I need it.
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.