Tuesday, February 20, 2007

A Noogler's View of Google

I know I promised I'd blog once a week, but they killed Simone and now I'm just incredibly distraught. How could they? So I guess I'll recycle some stuff from my internal Google blog, from my first few weeks there, about 20 months ago. Blatant self-plagiarism. What's the blogosphere coming to?

I figured I'd publish it so you know what it was like for me as a newcomer at Google. In case you were planning on sending me a resume.

You know. Just in case.

If you want some real content, check out this funny rant about programming language names. It's a good read. Free karma to the first taker!

Anyway, here are my first few entries in my Google internal blog. Ah, to be a Noogler again...

Important Disclaimer (like, duh) - I don't speak for Google. These opinions are my own.

Remember, this was written for a Google audience, so I left a bunch of obvious stuff out. You'll just have to come see for yourself, I guess.

Hope you like it.

Noogler 101

Tuesday, June 14, 2005



Hiya.

This is my second day as a Noogler. I figured I'd keep a diary of the experience, so we can all look back and laugh. Not at me, of course. Towards me.

The first morning we got badged, and through a minor communications mishap, I wound up with an expression that looks exactly as if they'd said: "one... two... ack, there's a tarantula on your crotch! *click*" HR has assured me that I can go get another picture taken if I want. Unfortunately, today I am, for lack of a better word, fat. As in, obese from eating waaaaaay too much on my first day. Bloated. Stuffed. I almost yakked yesterday, actually. They didn't prepare me adequately for the experience of being surrounded by yummy free food. I had approximately the same reaction as the kids when they first got to Willy Wonka's. "Everything's edible, even the staircase!" is I think what Willy said. Roughly. And that's how it feels here at Google HQ.

I'm sitting in a temp office with a temp office mate. Both of us are heading up to Kirkland next week, aka the Land Where Everyone Appears to be from Microsoft. My office has a big window, and outside the window there's a printer with a red bull on it that says "Bull". It's a popular printer, and people come by all the time and peer at us while they rifle through their print jobs. We're a regular Noogler Zoo, me and my officemate. We have another officemate, a ghost, who evidently never arrived. His big yellow welcome balloons are mostly deflated, their smiles wrinkled into expressions of concern or balloony dismay. We hope he's OK, wherever he is.

So far things have gone pretty well. The only mishaps have been fairly minor. One is that my officemate and I, who appear in most respects to be identical new hires, got slightly different equipment. His desk had his name, some happy balloons, two 24-inch flatscreen monitors, a fully-configured linux box, a set of office supplies, and misc equipment. My desk had my name, some happy balloons, and a box of kleenex. Fortunately, Tech Stops are almost as easy to find as the bathrooms (meaning about 1/10th as easy to find as food and drink), and they were able to hook me up with a laptop that's worked quite well so far. It was supposed to be a Powerbook, according to my recruiter, and it's actually an IBM stinkpad, but I guess I can wrap it in tinfoil and pretend it's the x86 version. At least I got a nice bag with it. One large enough to hold the roughly 150 feet of cables and adapters that came with it, allowing the laptop to be powered by every conceivable power source, including hooking it up to your cat or dog, if I'm interpreting this one strangely-shaped adapter correctly. (Editor's Note: I now have a spiffy 15-inch Powerbook. It rocks.)

I did do better than my officemate (the real one, not the ghost) in one respect: I got put up in the "Joie de Vivre" Hotel Avante, which is air conditioned and filled with toys and serves free beer and wine every day from 6pm-7:30pm. He evidently got placed in a 2-bedroom apartment, one without air conditioning. Someone generously saw fit to equip it with a roommate, though, and didn't tell either of them they'd be sharing. So my officemate says he walked in to an apartment that was 20 degrees hotter than it was outside, to find his new roommate standing in the kitchen in his underwear, cooking dinner. Imagine their surprise.

Anyway, that's about it for days 1 and 2 of my Noogler experience. I hope to be able to take advantage of some of the perks before I head to Kirkland next week, including jumping in the large vat of brightly-colored plastic balls and hoping nobody's asleep under them. If anything else interesting happens, I'll be sure to post it.

Kidtastrophe

Wednesday, June 15, 2005



The end of my second day as a Noogler ended in a mini-tragedy, as I floundered around in a big vat of plastic balls like a deranged baby elephant seal.

See, my Google mentor was nice enough to give me a tour of the facility, and he made it a point to show me the big pool of colored plastic balls in the corner of the 2nd floor in bldg 42. He said you could just jump in there any time, although you never knew if someone was actually down there. You know, resting or something. After the imagery of someone taking a nap down there as I did a cannonball, I decided I'd hold off for a bit.

But oddly enough, just last week (the week before I started), I'd mentioned to a friend that I had never been in one of those big containers of plastic balls, the ones you find at fancy kids playgrounds, you know, like at McDonalds or something. I guess I never ran into one until I was over the height limit. I think they said height, although it sounded suspiciously like "weight" to my juvenile ears -- the cotton candy muffled what they were saying a bit. So I'd never gone in one. And here was this big, pretty, free one sitting right on my floor. Calling me, sort of. I just *had* to give it a try.

So towards the end of the day, after most (but by no means all) folks had cleared out, I decided to give it a go. I walked over trying to act casual, and just jumped in. Whee! It was every bit as gratifying as I'd imagined. You know how you always wonder whether you'll be buoyant without water, or whether it's easy to walk around, things like that? All my lifelong kiddie questions about vats of plastic balls were answered. It turns out it's really easy to sink like a stone, and kind of hard to get out. And you look like a total dork in the process. Kiddie quicksand. After about 2 minutes, I'd had my fill for a lifetime, and had finally made it back to the edge. I think I only fatally crushed one ball (um, from the vat) during the excursion.

However, not all of me actually left the vat. No, probably not what you're thinking. I wasn't in there that long. But I did discover I was short exactly one badge. You know, my Google badge. D'oh. I didn't realize this until I was back in my office. That's when the nightmarish elements of this real-life story began.

I walked back, trying to look nonchalant, and saw there were about eight guys playing pool at the large pool table that's located approximately 2 feet from the ball vat. Ahem. So, trying to stay casual, I walked around them and carefully got back into the vat. They all stopped playing and just stared at me, as if I'd decided to crawl in the refrigerator. I waved. They didn't wave back. They weren't antagonistic or anything; they were just sort of dumbfounded, and were all staring at me, this fully grown (overly grown, actually) adult standing up to his waist in a tub of plastic balls they'd probably never seen anyone in before.

I squatted down and started thrashing around, and it dawned on one of the sharper ones that I was looking for something. "Vat are you looking fer?" He had a nice accent, maybe Austrian or German. Now everyone was really curious. The pool game was pretty much dead. I wished fervently that I was somewhere far away, maybe Austria or Germany.

"I'll give you two guesses," I said, pretending like I was some sort of career ball-vat guy.

No guesses emerged from the crowd.

"OK. I'm looking for my badge, which fell in here. Happy?" They nodded, and half of them shook their heads sadly in the internationally recognized head gesture for "you poor dumb noogler". They went back to playing pool, a game which, if you'll recall, only requires one person to be paying attention at a time. The rest stood around just staring at me, wondering if I'd find it.

"It should be near the bottom by now, don't you think?" said another smart-looking one.

"Gasp urf unk" said I, thrashing around with my hands and feet. It turns out you can only brush the bottom of the vat (which is only about 3 feet deep) if you get yourself almost completely submerged. Otherwise the balls are too heavy to move very far, and all you can do is poke a fingertip-sized area. And the dude was right; the badge was probably near the bottom. Probably near an edge (the math just kinda works out that way), and the balls are much harder to move around near the edges.

I spent a *long* time in there, maybe 15 minutes, during which time I became more tired of plastic balls than I'd ever have thought possible. I eventually emerged, miserable and defeated. I'd recovered 2 unopened packs of gum, several coins, some rubber bands and some binder clips, but no badge. I was starting to think I'd find Jimmy Hoffa's badge before I ever found mine. I *really* didn't want to be stared at anymore, although on the plus side, they all knew my face well enough by then to spot my badge from 100 paces.

So I went home, and got a new badge in the morning, and even a new badge picture. The old one is deactivated, and will rest in peace, more secure than the Heart of the Ocean, lying at the bottom of that big plastic tub of balls. You're welcome to try to get it. In fact, I dare you. I'll even come and stare.

End of Week One

Friday, June 17, 2005



Today I went to a tech talk. It looked like it was going to be exciting, but evidently signing up to give a tech talk does not, as one might conjecture, automatically make one a good tech-talker. The problem was that most of us were Nooglers, and the presenters didn't give us much context. They jumped immediately down to the lowest implementation details of their project, and we didn't know what the hell it was for, let alone the other projects they constantly cited. It was rough going. After about 15 minutes, several people in the audience were visibly asleep. Since nobody had started to snore audibly yet (which would have livened things up), I "snuck" out.

I do have to quote "snuck", though, because the act involved tripping over at least two people in the 3rd row back, so my exit couldn't really have gone unnoticed to the presenters. I tried the clever gimmick of glancing at my watch, as if I just happened to need to be somewhere else at exactly 12:47pm. Unfortunately I wasn't wearing a watch, so it didn't go over exactly as planned. Oh well.

I walked outside, and into a different world. There was live music playing, with Googlers everywhere on the lawn, and it was a beautiful, sunny, breezy day. There was a huge barbeque going, with juicy bratwursts and other delicious-smelling food. The band appeared to be playing on some sort of period-instruments, and the music was great. Well, I'm a sucker for that kind of music. It sure was nice to be outside, away from the slides and snores.

I ran into a guy I knew a little. I'd interviewed him a few months ago, for my old company, and he'd turned us down to go to Google. We were bummed, since he'd seemed to be the brightest person in his graduating class. I remembered he'd passed my interview in about 12 minutes, so I'd spent the rest of the time chatting with him about how college hires are making their decisions these days. His insights were really the beginning of the mini-investigation I did that wound up with me applying to Google.

That "investigation" started by chatting with college hires about why they were turning us down. Then I looked a little further, and a little further, and discovered that Google has a sort of event horizon, beyond which you're inevitably sucked in. Anyone at another company who looks hard enough into why people choose Google will ultimately apply to Google, if they have the courage. And it's a scary thing, too -- Google's recruiting-marketing has reached the point where a lot of smart, experienced people wonder whether they'd be able to get an offer.

Anyway, I said 'hi' to the guy, who remembered me, and we laughed a little about the whole situation. Then I headed back to my office.

Unfortunately, I have a remarkable propensity for getting lost on the campus, or at least disoriented. I realized I'd gone in the wrong direction (towards the food, as if that outcome were anything but preordained), and to get to my office, I'd have to walk back past the tech talk that I'd "snuck" out of. Oops. So with as little chalance as I could muster, I walked quickly by the room. As I went by, I glanced in, and as far as I could tell, they were on the same slide as when I left. I bolted.

Right now I'm sitting in a massage chair, looking out over what seems to be a big park or golf course. Sun's shining. Campus is beautiful. I'm sad to be leaving. Why can't Mountain View be in Seattle?

Tune in next time for my exploration of the wonderful world of the Kirkland Design Center, which you should check out on Google Earth! (The office looks taller in real life.)

Incidentally, a bit of good news: someone found my badge, the one I thought was lost forever in the tub of plastic balls in Building 42. I happened to be walking by the pool table nearby when some guy pointed it out to me. The badge was sitting on a little table between the ball vat and the pool table. I'm not terribly surprised, in retrospect, since I've noticed people evidently spend a lot of time in that tub -- talking on cell phones, or solving complex mathematical problems in their heads, or rooting around like starving boars in a full dumpster looking for lost wallets and wedding rings and so on. I guess it was only a matter of time.

Settling In

Sunday, July 17, 2005



Well, I've spent a few food-filled weeks in the Land Where Everyone's From Microsoft, so I figured it was time to blog again.

They really are, you know. From Microsoft. You can walk up to anyone in the Kirkland Office, even a potted plant, and say: "So! I'll bet you a million dollars you're not from Microsoft." And 80% of the time, they get all dejected and say: "Yeah, I was there." They're not even happy they won the bet.

So then I say: "Wow. Microsoft. That must have been cool." I get this evil gleam in my eye when I say it, but they don't notice since they're all dejected and looking at their shoes. (They're $1000 shoes, but they're still dejected. I guess if you're dejected, looking at your $1000 shoes can cheer you up a little.)

And they say: "Well, it was cool! Except we never launched our project. And we hated all the other teams. And they hated us. And each other. And our customers kind of hated our project too. And we couldn't make any forward progress, because we were crushed under the weight of blah blah blah..." They tell me their whole, sad, shaggy-dog story, and it's always the same. Project was cool, never launched it, everyone hates each other. (Editor's Note: actual percentages and experiences may vary. Some shoe prices inflated for dramatic effect.)

It's really cheery around here, I tell ya.

Actually it is really cheery, because everyone knows they're not at their old company anymore. If you ask anyone: "are you glad you came to Google?" They always brighten up instantly and say: "oh, hell yeah! I'm actually writing code!"

I'm actually editing these conversations down a bit, because what they really sound like is this:

Me: "Armph omph mmfph *gulp* So! *chomp* *chew* *chew* *mrmph* You from Microsoft?"
Them: "... mmmm *chew* *chew* mmmm *chew* *chew* .... mmmm *chew* mmm..."
Me: "Caught you with your mouth full, eh? Sorry. *CHOMP* *chew* *chew* *chew* ..."
Them: "... *gulp* yeah. sucked there. *CHWOMPH* omph mmfph *chew* *chew* ..."

And so on. I assume Google's master plan is pretty much the same as the witch's from Hansel and Gretel:


Hansel, who liked the taste of the roof, tore down a great piece of it, and Gretel pushed out the whole of one round window-pane, sat down, and enjoyed herself with it. Suddenly the door opened, and a woman as old as the hills, who supported herself on crutches, came creeping out. Hansel and Gretel were so terribly frightened that they let fall what they had in their hands.

The old woman, however, nodded her head, and said, "Oh, you dear children, who has brought you here. Do come in, and stay with me. No harm shall happen to you." She took them both by the hand, and led them into her little house. Then good food was set before them, milk and pancakes, with sugar, apples, and nuts. Afterwards two pretty little beds were covered with clean white linen, and Hansel and Gretel lay down in them, and thought they were in heaven.

The old woman had only pretended to be so kind. She was in reality a wicked witch, who lay in wait for children, and had only built the little house of bread in order to entice them there. When a child fell into her power, she killed it, cooked and ate it, and that was a feast day with her.


I mean, come on, it's pretty obvious they're going to eat us. Geez, we've all read fairy tales before. Nobody just gives you a bunch of free food for as long as you want without killing you and eating you. Like, duh. But I can vouch for Kirkland: when the Feasting Day OKR comes around, we'll be ready. I myself would probably go well with cranberry sauce.

Anyway, until then, the main pastime, other than researching how the Romans managed to eat several meals at one sitting, is Foosball. This is a game I've been introduced to since I came to Kirkland. I've seen it before, and always thought it looked kind of lame, but that just shows you what I know. Foosball is a way of life around here. Which makes it... not lame, see?

I can't quite figure out whether it's popular because it's the only thing to do other than stuff your face (except on Mondays when you can poll the massage calendar hoping someone will cancel) or if it's actually fun in its own right. You could do a scientific experiment, and bring some other game in and put it near the foosball table. But if we ever had the space and the budget for another game, we'd get another foosball table. (Editor's Note, Feb 19 2007 - we now have two tornado tables, air hockey, a pool table, darts, and other stuff. But foosball is still by far the most popular.)

I think Google would probably approve another table, even though various academic studies have shown that on the Grand Scale of Calorie-Burning Activities, playing foosball falls somewhere between "comatose" and "deceased". Most of the calories burned playing foosball are spent contracting your stomach muscles, which happens when you're laughing really really hard, because I just scored on myself again. Believe me, it's not possible to be worse at foosball than I am. I think I'm the only person who's necessitated consulting the rules to see whether it counts if you serve, then score on yourself without the ball touching the other player's men.

Other than eating and foosball, punctuated by the occasional multi-hour bout of intense programming, the major fun activities in Kirkland include:

* having construction workers watch you go to the bathroom. They sometimes offer helpful advice. ("You missed a spot." "Thanks.") They're putting in showers, and the workers use the toilet stalls as storage lockers.

* sitting in one of the $5000 massage chairs and punching buttons randomly, since the instructions are all in Japanese.

* uh, and other stuff that's way too fun to tell you about.

Oh, who am I kidding. All we do for fun is play foosball. I don't think the showers are going to add too many new fun new activities -- at least I seriously hope they don't -- so it looks like foosball is the pastime of choice for now.

In the meantime, I think I'll go see what's in the fridge. MMMMmmmmm, looks like milk and pancakes, with sugar, apples, and nuts. They're so nice to us!

Saturday, February 10, 2007

The Next Big Language




There seems to be a long period of initial obscurity for any new language. Then after that comes a long period of semi-obscurity, followed by total obscurity.
—Paul Bissex

Note: after I wrote this entry, one or two commenters speculated that I might be talking about something Google is doing. They're barking up the wrong tree: I may not be the smartest feller ever to fall off the cabbage truck, but I'm not -that- stupid. The speculation in this blog is all based on stuff I've read on the net. It's purely my own ideas and opinions, and I don't speak for Google (nor in today's entry, even -about- Google). You'll have to look beyond Google for clues about NBL. Enjoy!

People are always asking me to comment on their new programming language they're designing. I don't know about you, but I find that pretty funny, given the general trend of my comments on existing languages. I mean, if you saw someone walking around kicking people directly in the metaphorical groin, would you go up and beg them to do it to you too?

And I feel bad about giving them my feedback, because I don't want to discourage them. It's just that nobody will ever, ever use their language. The odds are impossibly stacked against it. Not to be discouraging, of course.

But people are still always trying to make new languages, because we have yet to see a language that is (a) popular and (b) doesn't suck. Do you disagree? If so, I don't mind. It just means your standards aren't as high as mine. Nothing wrong with that.

Back when I was in the Navy, just out of boot camp, an otherwise entirely forgettable petty officer first class instructor of ours offered us, unasked and free of charge, his sage advice on how to pick up women at a bar: "Go ugly early." With this declaration, he had made it clear that he and I thought rather differently about certain things in life. But I had to hand it to him: here was a man of conviction. He didn't care what other people thought of him, or for that matter, what he thought of himself. He had defined his philosophy and he was sticking with it.

And in a sense, he taught me a valuable lesson, although it's not the one he probably thought he was teaching me. I'll pass it on to you, unasked and free of charge. If you want to spare yourself a lot of angst in deciding which programming language to use, then I recommend this simple rule: Go ugly early. C++ will go out with you in a heartbeat.

For my part, I want to encourage people to make their own languages, because doing it makes you a world-class programmer. Seriously. Not just a better programmer, but a best programmer. I've said it before, and I'm sticking with it: having a deep understanding of compilers is what separates the wheat from the chaff. I say that without having the slightest frigging clue what "chaff" is, but let's assume it's some sort of inferior wheat substitute, possibly made from tofu.

But I really need to stop spending time telling people individually why their languages are doomed to fail. Instead, I'll summarize it in today's blog entry.

Summary: your language is doomed to fail, with probability 1 minus epsilon. If you fell off a thirty-story building, you might survive (anyone else watch the last episode of Heroes? wasn't that an awesome scene?) but for all practical purposes the odds are nil.

Before I go into slightly more detail, I'll let you in on a secret. Just between you and me. Nobody else will know but us. The secret is that last week I got an insider's tip: I know what the Next Big Language is going to be.

You probably imagine some sort of Old Boys Network that's responsible for deciding what we unwashed masses are going to use next. You know, a bunch of corporate executive cigar-chomping porcine thugs sitting on each others' boards, conspiring and maneuvering to wheel and deal with mergers and consolidations, and suddenly language XYZ is endorsed by all the big companies at once, so you have to learn it or you'll get fired and deported and have to go live on the streets in some fly-specked third world country where, ironically, you don't speak the language there either. Well, that's exactly how it works; how the hell do you think we all wound up programming in Java?

Seriously, though. I know I have a very slight tendency to exaggerate a wee bit now and again, for dramatic effect. And I don't always stop at stretching my metaphors; sometimes I drag them out to the back alley and beat the living crap out of them. But it should be clear that there's a grain of truth to my cigar-chomping executives: most successful languages have had some pretty serious corporate backing. C++ had AT&T and Microsoft. Java had Sun and IBM. C# and Visual Basic had Microsoft. Perl basically had O'Reilly. JavaScript had Netscape, Sun, and Microsoft (among others). And so on.

And I found a tip — a rather detail-packed one at that — as to which way the wind is blowing. Let's face it: I've been digging into this story for years, so it should be no surprise that I got the scoop. (Hint: the "tip" was synthesized from reading a bunch of public web pages, so you've got all the clues you need.)

Unfortunately I can't tell you what language it is. For one thing, you probably wouldn't believe me. For another, it wouldn't be fair; there are plenty of contenders out there, and it seems like they should all have a fighting chance. Instead, I'm going to outline the characteristics that a language needs in order to be a megahit. You won't like some of them, and I sure as hell don't like some of them, but we're talking stark reality here. It's not a matter of opinion.

I'm really killing two birds here: by telling you where languages are headed, I'm giving you enough hints to figure out what the Next Big Language is without committing to anything, thereby evading the inevitable jihad against me if I were to say its name. Second, I'm giving language designers valuable information that should help them get their language adopted, if that's their goal.

But first, some preliminaries and caveats are in order.

You won't be deported to Columbia

Just because the Next Big Language (NBL from now on) is going to arrive very soon (timeline: 18-24 months, as far as I can tell, which in language terms means "imminent") doesn't mean your language is going away. You won't lose your job, so don't freak out on me.

What it does mean is that there's going to be a massive momentum shift, so if you start preparing now, it's not going to hit you as hard when it happens. You'll be ready.

Heck, if you're lucky, you already know the language — at least the subset of it that exists today. If so, you've got a big head start.

NBL does not replace C++

NBL is garbage collected. There will always be a bunch of engineers who think that's evil, and they'll continue to use C++.

C++ does need to get replaced someday. It's just horrid, and everyone knows it. However, there aren't very many people trying to replace it, either. The only contenders I'm aware of are Objective C and the D Programming Language.

D's a really beautiful language. By rights it should be the next C++. However, C++ programmers won't have it because it's garbage collected (even though it can be disabled, and even though Stroustroup himself is now advocating adding garbage collection to C++). Walter Bright is one hell of a lot smarter than the C++ programmers who won't look at his language, and he has demonstrated that D is as fast as or faster than C++ and nearly as expressive as Ruby or Python. It's a secret weapon just waiting to be seized by some smart company or open-source project.

But nobody ever accuses programmers of being wise.

I don't know much about Objective C, to be honest; I've read one or two books about it, and it looks decent-ish, but not inspiring in the way that D is (for instance.) So I can't say much about it. Seems kinda ho-hum to me.

Anyway, most of the language research and effort and creativity out there, both in academia and industry, is focused on higher-level languages, so it looks like C++ will continue to struggle happily in its tar pit for some years to come.

NBL isn't about winning beauty contests

When I refer to NBL, the Next Big Language, I specifically mean the next popular language. I.e., a language that you yourself will wind up learning and actually using. You can point to all sorts of languages, both existing and in the works, that are prettier than NBL. Doesn't matter, though. Heck, as you'll see (Rule #1), beauty is one of the obstacles to adoption.

If your goal as a language designer is to design a language that meets your own personal sense of aesthetics, then you're an artist, and I salute you. For my part, I'm looking for the middle ground between hard-nosed I-don't-care pragmatism (in which case you go ugly early, use Java or C++, and be done with it) and idealistic better-world optimism. And I think a lot of other people are too.

In any case, I'm not claiming that NBL is a great language; I'm just saying it doesn't suck. In practice it's actually quite good, and it will be very, very popular. NBL isn't the 100-year language, but it will definitely be the 10- to 20-year language.

And now, on to the features. Get ready to get mad.

The Language Arena

Here's how you compete in the programming language arena today. Follow these rules and you stand a chance. Ignore them and your language will be Lion Chow.

Rule #1: C-like syntax

C(++)-like syntax is the standard. Your language's popularity will fall off as a direct function of how far you deviate from it.

There's plenty of wiggle room in the way you define classes and other OOP constructs, but you'll need to stick fairly closely to the basic control-flow constructs, arithmetic expressions and operators, and the use of curly-braces for delimiting blocks and function bodies.

This is because programmers are lame, but hey, it's your target audience. Give the people what they want.

People sometimes ask me why I think C's syntax is bad. The reason is pretty simple: it's too complicated. Well, C's wasn't so bad, but when you throw OOP into the mix (whether it's Java's, or C++'s, or D's, or anyone's), the grammar becomes enormously complex, with hundreds of productions.

It might feel, as a programmer using a C-like syntax, that the syntax is helping you out. Unfortunately, as soon as you try to write code that deals with the language itself, you hit a wall.

Case in point: Java folks always wish they had a better Java code formatter. The best one ever written was Jalopy, but it never took off, in part because it wasn't open source, but also in part because its manual was astoundingly long and complicated. Why? Because it provided rules for customizing every last one of the hundreds of edge cases in Java's syntax. And this was before Java 5 came along and made it even more complicated with generics and so on.

So people settle for the one built into Eclipse, but nobody ever goes in and messes with its actual internal mechanisms themselves, because even if they're unhappy with the way it handles certain syntactic cases, it's too damned complicated to bother with.

Most programmers don't realize how often they need to deal with code that processes code. It's an important case that comes up in many, many everyday situations, but we don't have particularly good tools for dealing with it, because the syntax itself prevents it from being easy.

That's why it's bad.

Unfortunately, even Ruby and Python (which "feel" simpler, syntactically) both also have very complicated grammars, making it nontrivial to write code that processes them, even with parsers that hand you the AST directly.

Whatever. Now you know why I think C's syntax is bad. It's because it is bad.

But bad or not, NBL will have approximately C-like syntax because if it doesn't, most programmers won't give it a second glance.

Sigh.

Rule #2: Dynamic typing with optional static types.

There are two ways to make a language. The old way is to make it super static, to protect programmers from hurting themselves. The classic example is SML, which is so fanatically typed that you're guaranteed never to get a runtime exception, because you will never get your goddamn program to compile. There's nothing more fun than having your compiler tell you: "Error: expected type (int, int, int) but got type (int, int, int)". Sheesh.

When you make a static language, you will be forced to add dynamism to it, because otherwise it's like programming in a straitjacket. If you don't add dynamic features to your static language, then assuming everyone hasn't ditched it entirely, they will start building in the dynamic features themselves, no matter how hard it is, and how awkward they are to use.

The other way to design a language is to make it dynamic, and then you'll be forced to add static checks in later. If you don't, then programmers will start simulating static checks using assertions and preprocessors and all manner of other hacks, in an effort to help lock things down once they've stabilized past the prototyping phase.

Adding in optional static types is the ideal solution. It helps with performance, it helps with code reliability and (possibly) readability, it helps IDEs navigate your code, and most importantly, it helps combat the incredible FUD that dynamic languages inspire in people who come from static backgrounds.

It should be pretty obvious that dynamic + optional static types is a better approach than static + optional dynamic features. The latter is premature optimization, plain and simple: the root of all evil.

So NBL will be a dynamic language with optional static types.

As a special sneak preview, its static type system will include a "standard" class system (i.e. the kind you're used to if you do any conventional OOP using C++ or Java or Python or whatever, as opposed to Common Lisp's object system or some other unconventional one.) Not that the standard system is any better, but it's what people want.

Rule #3: Performance

NBL will perform about as well as Java. That means if it's one of the big existing dynamic languages out there, something major is going to have to happen with performance.

It turns out that eval() is one of the key things that gets in the way of performance optimizations. It can easily invalidate all sorts of otherwise reasonable assumptions about variable bindings, stack addresses and so on. It's also pretty important, so you can't just get rid of it.

So NBL will have to do something clever about eval.

Generally speaking, NBL will have to have a much greater focus on performance than so-called "scripting languages" have had in the past. I mean, if it's really the Next Big Thing, it'll have to run on mobile devices, game platforms, and all sorts of other hardware-constrained devices.

It sounds impossible, I know. But it's not. Those compiler writers are a tricky bunch, and they have decades of experience. A bunch of them got together and did a lot of head-scratching over NBL, and the result is going to perform quite nicely.

Rule #4: Tools

Let's face it: one of the biggest reasons people haven't adopted Ruby or Python is the lack of IDE support. IDEs like Visual Studio and Eclipse have set the bar and the expectations for most programmers out there.

I can't tell you how many times I've heard people say they wouldn't use Ruby because it lacks automated refactoring tools. Ruby doesn't actually need them in the way Java does; it's like refusing to switch to an electric car because there's no place to put the gasoline. But programmers are a stubborn bunch, and to win them over you have to give them what they think they want.

So NBL will have great tools. They might not be Java-great on Day One of NBL's reign, but they'll be a lot better than the options available for Perl/Python/Ruby/Tcl and the rest of the popular dynamic languages out there today.

Rule #5: Kitchen Sink

Word on the street is that all languages are evolving towards each other. It's another way of saying they all have feature envy. So NBL is going to have to play along.

Here's a short list of programming-language features that have become ad-hoc standards that everyone expects:
  1. Object-literal syntax for arrays and hashes
  2. Array slicing and other intelligent collection operators
  3. Perl 5 compatible regular expression literals
  4. Destructuring bind (e.g. x, y = returnTwoValues())
  5. Function literals and first-class, non-broken closures
  6. Standard OOP with classes, instances, interfaces, polymorphism, etc.
  7. Visibility quantifiers (public/private/protected)
  8. Iterators and generators
  9. List comprehensions
  10. Namespaces and packages
  11. Cross-platform GUI
  12. Operator overloading
  13. Keyword and rest parameters
  14. First-class parser and AST support
  15. Static typing and duck typing
  16. Type expressions and statically checkable semantics
  17. Solid string and collection libraries
  18. Strings and streams act like collections

Additionally, NBL will have first-class continuations and call/cc. I hear it may even (eventually) have a hygienic macro system, although not in any near-term release.

Not sure about threads. I tend to think you need them, although of course they can be simulated with call/cc. I've also noticed that languages with poor threading support tend to use multiprocessing, which makes them more scalable across machines, since by the time you've set up IPC, distributing across machines isn't much of an architectural change. But I think threads (or equivalent) are still useful. Hopefully NBL has a story here.

Rule 6: Multi-Platform

NBL will run, at a minimum, both standalone and on the JVM. I'm not sure about plans for .NET, but it seems like that will have to happen as well.

And there are two other platforms that NBL will run on which, more than anything else, are responsible for its upcoming dominance, but I'd be giving away too much if I told you what they were.

It's all about not sucking

The features I've outlined don't make NBL a great language. I think a truly great language would support Erlang-style concurrency, would have a simpler syntax and a powerful macro system, and would probably have much better support for high-level declarative constructs, e.g. path expressions, structural dispatch (e.g. OCaml's match ... with statement) and query minilanguages. Among other things.

The features I've outlined are basically the minimal set of requirements for not sucking. At least off the top of my head; I've probably overlooked a few.

Well... OK, I think C-style syntax kinda sucks, for reasons I've outlined, but it's a price I'm willing to pay, because I think there's no choice. Rule #1 is in there strictly to support popularity.

Looking at the list, it's amazing that you have to work so hard just to meet the minimum standard for not sucking. The bar has really gone up for programming languages.

Not to discourage you or anything.

Is NBL (the one whose name I won't tell you) guaranteed to be the Next Big Language? I think it's got about a 90+% chance, but there's still hope for the other runner-ups.

For instance, it might be possible to get away with non-C syntax, provided you offer everything else I've listed here, but you'll have to bear in mind that you're competing against NBL, which has all the features of your language plus C-like syntax. So your language would have to offer something not in this list that gives it a huge leg up on NBL. (And I'm afraid simpler syntax alone won't do it; you're going to have to offer something that compensates for your lack of C syntax, because that's just how programmers are.)

So it's possible. But my bet is on NBL.

And now, if you'd like to see some excellent variations on the old game of Shoot The Messenger, enjoy the comments!

Wednesday, February 07, 2007

My save-excursion

A friend of mine on a neighboring team at Google presented me with an interesting math problem the other day. It went like this:

Friend: Hey Stevey!

Me: Uh, you know people don't actually call me that to my face, right? Only behind my back.

Friend: (cheerily) But you're Stevey! Look at your badge!

Me: Sigh. OK, fine already. What's this math problem?

Friend: Let's say there's this hypothetical blogger who writes for 4 hours a month, and he desperately needs an editor who will never materialize, and in those 4 hours he produces very... large... ummm...

Me: And what exactly are you trying to say there, ex-friend?

Ex-friend: Oh, nothing! It's purely hypothetical! I'm just saying that I, er, well, I've been reading for hours and I'm only half done with your last blog entry, and I accidentally fell asleep and had a wonderful dream that I was finished reading it, and then I woke up and my keyboard was gone. Plus I'm still not done yet.

Me: That was a pretty long story.

Ex-friend: (reading what I wrote) That's not what I said! What do you mean the keyboard was gone?

Me: Uh, never mind. I'll fix it in the real blog.

Ex-friend: Fine. Whatever. Anyway, we were all thinking...

Me: Oh! So it's "we" now, is it? And who are my other ex-friends in this particular hypothetical situation?

Ex-friend: Jared and Todd and Jeremy.

Me: B-b-but — you can't say their names in my blog!

Ex-friend: Oopsie.

Me: There are people listening!

Ex-friend: No, Stevey, I think your readers all died of starvation on account of trying to finish your blogs in one sitting.

Me: D'oh! OK. Yeah. I think I get it. You're saying — and correct me if I'm wrong here — that if I write for an hour a week, I'll produce blogs that are only like 600 times too long, rather than the usual, ah...

Really-ex-friend-now: 2400.

Me: Ouch! That's just... low. (frowning vaguely, looking at my fingers) I know how to multiply, you know. I was just thinking about something else, that's all.

Really-ex-friend-now: Well, we think maybe you should give it a try! Just one hour a week. You could be, like, a columnist.

Me: Yeah! I won't get paid, and nobody will read any of it, but otherwise it's pretty much exactly the same as a columnist in all respects. I can be like... like Paul Graham, and sit around in my underwear writing articles about how I get to sit around in my underwear writing articles about stuff, on account of having written everything in Lisp. Except I'll still have to wear pants.

Friend: Um. (edging nervously towards the door) So does this mean I don't have to finish that last blog about Cinderella?

Me: *sigh* Pinocchio. And no, you don't have to finish it. He dies at the end, anyway.

Friend: (sympathetic frowny-face) Sad. (runs out)

Stevey's Blog... Column... Thing.

So! I'm going to try writing for an hour a week, and also try limiting my blog to a certain number of words that columnists apparently never actually discuss but which appears to be around 800, and we'll see if it nets me fewer complaints. And I'm going to start... last Friday! This blog is officially 3 days late, but I figured apologizing could get me a couple of extra words.

As of that last paragraph, I was at 2338 chars, or 437 five-letter words, at least in the first draft. I'll spend the rest of today's entry explaining how I knew that.

Since I'm writing this in Emacs (where else?) I need an Emacs command that will count the non-whitespace characters in the current buffer and tell me how many there are so far, plus divide by five to show how many "words" I've written, since as we all know from fifth-grade English class, words are always five letters.

First I type C-x 2 and switch to my *scratch* buffer. You can write lisp code there. When it's tested, you can copy it into a file somewhere that's loaded by your .emacs.

I start with the basic interactive function skeleton:

(defun blog-column-length ()
"Print stats on current blog column, or blogollum, or whatever"
(interactive)
(message "hi there"))

That's pretty much the minimal command you can invoke with M-x. After typing it out, I put the cursor anywhere inside the function definition and type M-C-x (i.e., Ctrl-Alt-x) to evaluate it. Note that we don't have to restart Emacs to do this. *Ahem*. At least Eclipse comes with free bullets.

Now we can type M-x blog-column-length to see the "hi there" message printed to the minibuffer. If I were doing lots of output, I could use with-output-to-temp-buffer, but I figure this can just be a one-liner. The (message) function takes arguments similar to C's printf.

Note: by evaluating my function, I've fully integrated it into Emacs. I can tab-complete the command name, do M-x describe-function to read the help string, do M-x apropos blog to find it in the list of commands that have 'blog' in the name, and so on. Emacs is cool. Why aren't all editors like this?

I mean, if you were trying to follow along with our little exercise in Eclipse, at this point you might have it out of the box, maybe, but there would be parts all over the floor, styrofoam everywhere, and you'd be staring at the 10-page Hello, World demo trying to figure out where main() goes. Good ole Eclipse. And I hear the Visual Studio team was jealous of Eclipse's "lightweight" plugin system. (Is it any wonder that developers never customize their tools? Jeez.)

Anyway, all that's left is to count the characters. It helps to know one wacky thing about Emacs: most functions are written as scripted versions of exactly what you would have done by hand. That's how it got to be called "Emacs" — Editor Macros. As you learn the editor commands, you're also learning how to program Emacs, because you can use all those commands in your elisp code. Sweet!

There are lots of ways to count the non-whitespace characters in the buffer, but the first one that came to mind is to go to the beginning of the buffer and start looking at each character, incrementing some counter if it's not whitespace, and keep going until we get to the end of the buffer.

So that's what we'll do. First, go to the beginning of the buffer:
(goto-char (point-min))

You could also use
(beginning-of-buffer)
if you prefer. No biggie.

Then we need a loop. How about "while"? Sounds good to me. Let's loop while we're not at the end of the buffer:
(while (not (eobp))
)
It's good to know all the little functions for testing if you're at the beginning of the line (bolp), end of line (eolp), beginning of buffer (bobp), end of buffer (eobp), etc. 'p' means predicate; i.e. a function that returns true/false. It's just a lispy naming convention.

Oh, let's wrap the whole thing in a save-excursion. That's an emacs macro that saves/restores the point and mark around any editing operations. If you want to be able to run your command without affecting the user's actual cursor position, use save-excursion. You see it all over. There's even a haiku about it:
The friends chat gaily,
I stand up to join their talk.
My save-excursion.

Really. It's a real Emacs haiku. Look it up! The only Eclipse haiku I know goes like this:
startApplication()
thenWaitFriggingForever()
thenItGoesRealSlow()

That's what they used to say about Emacs, but then hardware got faster so they needed a new elephant.

Anyway, here's what we've got so far:
(defun blog-column-length ()
"Print stats on current blog column, or blogollum, or whatever"
(interactive)
(save-excursion
(goto-char (point-min))
(while (not (eobp))
;; we're going to increment a counter in here
)
(message "count will be displayed here")))

First, we need to declare a variable. I'm tellin' ya: declaring your variables is all the rage these days.
(let ((char-count 0))

This declares a variable char-count, initialized to zero, within the scope of the let-block, which is sort of like a curly-brace block in C or Java. The extra parens date back to 1955, and they get real grumpy if you mention them, so let's not.

Next we need to say "unless we're looking at a whitespace char, increment char-count". Here's how:
(unless (looking-at "[ \t\r\n]")
(incf char-count))

Gosh. And everyone always says they despise Lisp. It's not that hard, is it? The only trick is knowing where to put the parentheses, and that's easy. It's just (function arg arg arg). If arg is a call to a function, then you parenthesize it, and it all nests nicely, sorta like XML but without all the yelling.

Plus those extra ones around the let-declaration, but we don't talk about them, remember? That's how you remember them.

Then we move the cursor forward:
(forward-char 1)

Putting it all together:
(defun blog-column-length ()
"Print stats on current blog column, or blogollum, or whatever"
(interactive)
(save-excursion
(goto-char (point-min))
(let ((char-count 0))
(while (not (eobp))
(unless (looking-at "[ \t\r\n]")
(incf char-count))
(forward-char 1))
(message "%d chars, %d words" char-count (/ char-count 5)))))

Et voila. Almost exactly 1 hour. Well, 90 minutes, but who's counting.

6936 chars, 1387 words. OK, it's a little longer than my target, but what's a few words in the pursuit of Emacs education between friends? Plus I got a couple of jabs in at Eclipse, so it's not a total loss.

See you all next week!