robjsoftware.org

Because I can

2009-09-11T00:24:00.000-07:00

This is a list of worthy programmers. It makes me happy.

Daniel Lehenbauer

Pavel Curtis

Jonathan Shapiro

Ravi Pandya

Dean Tribble

Chris Brumme

Bjarne Steensgard

David Tarditi

Tanj Bennett

Joe Duffy

Leif Kornstaedt

Unfortunately that is all I can say about this list at this time. Hopefully someday my disclosure may be fuller.

Sex and the Clueless Coders

2009-07-07T00:24:00.001-07:00

I am very late to the "party" here, but I can't help chiming in on the recent spate of programming conference presenters dropping bits of porn into their presentations. First it was the Golden Gate Ruby Conference in April, where a presentation on CouchDB (hmm, now I know what couch they meant!) included some racy pictures of mostly nekkid women. What's more astonishing yet is that David Hennemeier Hanson, the Big Dog of the Ruby community, apparently thought this was all quite appropriate. I guess he wants the Ruby community to be all anti-corporate and rock-star. Or something.

And now as I was doing my remedial surfing to catch up on the story from April, I find that something similar went down (ahem) at a Minneapolis Flash conference, where the presenter did a big ol' animation of all kinds of X-rated activities.

It's funny, in a sad way, to see so many clueless male geeks sticking up for the L33t Rebels Busting Out The Pr0n. I mean, my God, guys, the entire Internet is filled with images of hotties of all genders, ages, species, and descriptions. Why do you feel the need to shove it in peoples' faces at a geek conference?

I work for Microsoft now, which I suppose is an arch-corpocracy by the definitions of these running-wild-and-free, swinging-low coder cowboys (operative word being boys). Here at Microsoft we have this little thing called an HR policy. What it means is that if I wallpapered my desktop or office with pictures like the ones these zany idiots are slathering all over the place, I WOULD GET FIRED. And deservedly so. Because while sex is great, mixing it with work is guaranteed trouble for everyone.

It's especially appalling how absolutely butt-ignorant many of these testosterone-poisoned hackers seem to be. I lived in San Francisco for a good twenty years, and I got to know a raft of feminist sex workers and general sex-positive people. And the one abiding principle that everyone thrived on was respect. Listening to what other people want and how other people feel -- what a concept!!! And that's exactly what all these indignant self-important immature coderboys are apparently utterly unable to do, when confronted with the thoroughly understandable discomfort of the women and the more enlightened men who were present at these code talks that turned into bad peep shows.

I love programming. I love computer science. The world of software has unlimited potential. And the lack of women in this field is beyond tragic. This summer I'm actually managing a female intern in our group; she is rocking the code in a serious way and I'm honored to get to be her manager. Looking at this unbelievable travesty of civilized behavior at these conferences, I'm just really, really glad we're not on any Ruby or Flash projects, and I'm also glad we're in a Big Boring Corporation, because not only are we working on things that are astonishingly cool despite our corporate overlords, we are protected from the kind of juvenile bullshit that seems to have infected the Ruby world.

We want MORE women in this field, not less -- but if the numbskull, sexist Rubyists and their ilk have their way, all we'll have is stupid guys with more balls than brains. And that's bad for everyone. KEEP IT IN YOUR DAMN PANTS, IDIOTS! And do your pr0n surfing in private!

Edit: Here's the big thread on the Ruby debacle, with the presenter in question chiming in. Now you know which side I'm on....

More editing: Here's Martin Fowler's excellent summary of the debacle. And here's DHH himself -- scroll down to April 27. Kind of funny how he seems to think that enjoying the movie Pulp Fiction and putting porn into a technical conference are somehow related. Dude, don't be so proud of being R-rated -- I'm sometimes very X-rated myself, but you won't find out about it here, because I know better than to get my boundaries mixed up! Good fences make good neighbors.

Bob vs. Gavin, no holds barred

2009-05-08T11:04:00.001-07:00

As this blog chronicles, I was in the Java world from 1996 to 2008. Near the end of the road, I got involved in the Seam and GWT communities, and I met Gavin King and Bob Lee. Gavin developed Hibernate and Seam (both wonderful), and Bob created Guice at Google (which I hear is wonderful, but haven't looked at it much). (Sorry, can't be arsed to link all these terms; search = your friend!)

Then we had to sell our house (housing bubble near-miss) and we decided to move to Seattle, and now I work for Microsoft and am very happy, and I lost touch with what was going on in the Java world. The last I heard, Gavin was working on the Web Beans JSR (JSR-299), collaborating closely with Bob, and Web Beans was going to be the best of Seam and the best of Guice standardized and pushing Java EE forwards. Ah, how lovely a picture!

However, I just opened my RSS feed on Gavin's blog, and was shocked -- SHOCKED -- to see serious trouble in paradise. For example, quoth Gavin:

Bob, if you're honestly trying to argue that Guice - which relies upon procedural Java code to specify dependency-related metadata - is as inherently toolable as a system that allows all dependency-related metadata to be specified using annotations (or XML for that matter), I'm just going to leave this discussion now, because that's absurd.

And quoth Bob (replying to a different post, I'm cherry-picking not summarizing):

This is a little disingenuous. As you know, the lead of a JSR has absolute power. Most leads don't abuse this power. They listen to their (highly representative) EG, achieve consensus, and very rarely make executive decisions. I think you'll agree that you are more of a dictator. Yes, you took what you thought were the best ideas from Guice, but I found working with you as a lead and changing your mind on anything to be an exercise in frustration. I can't count how many hours I wasted convincing you that Seam-style injection was fundamentally flawed only to have you switch to using proxies which have their own set of problems. I even brought Josh Bloch in one time to help settle a debate, but you cursed at and insulted him. I sincerely wish I had that part of my life back. By joining your JSR, Spring would not only validate it, but they'd have to give you absolute power over themselves. Based on my experience, I wouldn't recommend they do that.

Zow! What's also strange is that this comment shows up in my RSS feed for Gavin's page, but I'm not seeing it on the comments web page itself. So if you want to see the fur fly, go straight to the feed.

This is the kind of thing I miss the least about the Java world. I theoretically admire the openness of the JCP/JSR process, and in theory it should lead to better results than a more closed process. But in practice, normal human perversity just gets in the way -- the kinds of personalities that drive specs forwards tend to be very focused, and prone to conflict. So now it looks like there are going to be multiple JSRs describing dependency annotations, and the two people who could best work it out seem to be at each others' throats (as far as their respective specs are concerned). Disappointing.

Neal Gafter recently left Google -- and the entire Java world -- and came to Microsoft, for similar reasons... he put man-years of work into the Java closures spec, and then it was killed due to backroom political pressure. The Microsoft model is more like, we own everything, and we will do what we think is best. Coming from the Java world, I used to think that made Microsoft the Evil Borg. But now, on the inside, I see there are a lot of benefits to having a single decision point. (Well, God knows there are huge political issues even inside Microsoft, but it's still an order of magnitude less than the Java world!)

Intentional shipped!!!

2009-04-25T19:59:00.000-07:00

Intentional Software was founded in 2002 by Charles Simonyi, one of Microsoft's first billionaires. They've been pretty vague ever since then, which led to the usual vaporware skepticism.

I've been following them for some time, because I had extremely positive results using domain-driven design at Nimblefish (my first serious enterprise software job). I've also blogged extensively here before about the appeal of extensible languages.

Well, last week they finally gave a real demo, and it turns out they've been very busy for these last seven years. The Intentional team has made some real leaps forward in the whole concept of language construction, multi-language projection, and bidirectional editing. Basically, their system lets you use any number of different languages to describe a problem domain; you can create your own languages, project them as Ruby/Java/C# code, tables, or diagrams, edit them in any format and have it translated directly to the others (to the extent possible), run the model directly while editing it, and just generally take metaprogramming to completely the next level.

Yes, I'm excited; it's not every year (or even every decade) that you see a demo like this.

Here's a breakdown of the contents, if you need to optimize your optical cycles:

0:00 - 9:00: basic Powerpoint conceptual overview
9:00 - 13:00: more technical Powerpoint about the structure of their system
13:00 - 21:00: illustrating the "metamodel" for a state machine domain-specific language
21:00 - 31:00: bidirectionally projecting and editing a state machine via Ruby, UML, etc.
31:00 - 36:00: demonstrating an electronics DSL, including a live evaluation of electrical flow while editing the circuit graphically
36:00 - 43:00: the Cap Gemini beta test product, implementing a pension system with live Intellisense on the actuarial math equations, and a temporal rule language for pension rules
43:00 - 46:00: the multi-user versioning support that operates at the level of their fundamental tree-based data structure
46:00 - end: various Q&A

If you only have 15 minutes, watch 31:00 - 46:00.

There are various systems that have done various subsets of all this before, but I've never seen it packaged in a unified way. Ever. It's time to start watching Intentional very closely. It may also be time to check out the open-source JetBrains Meta Programming System. Software is all about raising levels of abstraction, and we might just have some new cranes coming online.

Edit: I just checked out the Meta Programming System's tutorial, and yay! Looks like it's a free version of many of these concepts that we can play with now! Time to tinker....

Miracles can happen: CACM

2009-03-26T20:46:00.000-07:00

So I've been a member of the ACM for many years. For a long time it was the only way to get at their Digital Library, which was the motherlode for research paper junkies like me. That made it worth putting up with their magazine, Communications of the ACM (CACM for short), which was really remarkable for how it never had anything worth reading. Pretty much all the lead articles it published were turgid studies about the sociological makeup of MIS departments, or the nature of collaboration in enterprises, or other strange bureaucratic stuff that only had a tenuous connection to programming as I knew it.

Last spring I got my current (unbelievably excellent) job at Microsoft, which has free corporate access to the Digital Library. Hmm, I thought, maybe I should drop my ACM membership.

They must have been snooping on me, because almost exactly then, they announced a complete editorial revamp of CACM. Refereed articles! Hardcore software / hardware research papers! Suddenly they were talking my language. And even better, they actually did it.

The new CACM is frankly the best computing magazine I've ever seen. Wide ranges of articles, high technical bar, many diverse subjects of great interest... it's really a winner. Puts the old Byte / Dr. Dobbs / etc. to shame. Of course, all those mags are dead, too... but the itch they used to scratch is scratched much better by CACM! Who would have thought?

And the new CACM web site is no slouch, either.

I guess sometimes miracles do happen. Thank you, ACM, for doing such a good job on this reboot!

(And yes, it's been a while... I've been sick, the whole family had the flu, the dog ate my homework, it's been awful dark outside, gimme a break here! At least I'm back! :-)

The Five Stages of Programming

2008-12-29T21:03:00.000-08:00

Programming is an interesting job, because it goes in continual cycles. Each part of the cycle has its own emotion that goes with it, too.

When starting off a new project, there's a learning curve that goes with it. You're spinning up, reading code, reading technical papers, trying to figure out what the hell you're going to do. The main emotion here is puzzlement -- how is this thing going to work? What's the interface? What's the feature set? What the heck is going ON?

After that comes early implementation. In this phase, the main emotion is nervousness. You think you know how it's going to work, but there's nothing really there yet. So you're hacking madly away, trying to get enough of a skeleton in place that you can start to make it dance. Forget about getting flesh on the bones, you're just trying to come up with something that can stand up! Since you don't really know what you're doing yet, it could all still fall apart on you.

Once you're out of those woods, you're into late implementation. Here, the main emotion is adrenalin. You're charging on all cylinders, driving at full throttle. The bones are rapidly becoming enfleshinated, and you're in the zone. This is in some ways the most satisfying part of the whole cycle, because now you start to see some real results from what you've been working on.

The last phase is debugging. Here, the emotion swings wildly between frustration and relief. You're almost done... except you're not! There's a bug! Fix it, fast! OK... and on to the next test... and WHAMO, another weird bug! Grrrr. OK, got that one done... YES! IT WORKS!!! Ship it!

And then the whole cycle starts over again.

So that's my job: puzzlement, nervousness, adrenalin, frustration, and relief. Of course sometimes you take a few steps back. For example, right now I made it all the way to relief, but I'm about to backslide into nervousness. The best-case scenario, though, is when you make it to relief and then you can keep building on the code you just finished... then you have a kind of secure happy foundation under you, reassuring you that even if your current layer falls to bits in a welter of recrimination, at least you know the relief -- that fantastic sense of accomplishment that comes with writing a software machine from thin air, that has real value and usefulness -- is still out there, in the future, waiting for you.

That's what software is, to me: the promise of progress, of building on what's come before, making it better. And this emotional cycle is what it takes to make that happen. So I'll close with a word that sums it all up for me:

Onwards!

Yow! MGrammar ahoy

2008-11-24T20:05:00.001-08:00

I've ranted about grammarware here in the past, but now I'm actually using some, and it's rocking. I'm talking about MGrammar, part of the impending Oslo.

MGrammar is a toolset for writing grammars and working with them. The MGrammar grammar description language lets you write what is basically an LALR(1) grammar, which means it's about as powerful as YACC. Or it would be, if it wasn't also a GLR parser, which means that when your language is ambiguous you get all the possible alternatives. This is a nice way of avoiding the NP-completeness issues around ambiguity detection.

MGrammar also separates syntax (LALR(1)) from tokenizing (regular). This is a win, since sometimes tokenizing is all you need.

The coolest thing about MGrammar is the grammar development tool. It's a three-paned window, with sample text on the left, the grammar in the middle, and the parse tree on the right. You can change the sample or the grammar at will, and it reparses with every keystroke. When your grammar finds a parse error or ambiguity in the sample text, the sample text gets a red underline with Intellisense. When your grammar itself has an error in it, you also get a red underline with Intellisense, which is reasonable because there is in fact an MGrammar description of MGrammar itself, which drives the Intellisense.

It works very well in practice and makes grammar writing so much more productive it's not even funny. Using a lot of negation can make it go nonlinear, but it's manageable.

On a sad note, Gilad and his merry band have lost their funding. This really sucks, as Newspeak is one of the most interesting language efforts around. I very much hope a community takes root around it and drives it. (If it can happen to Factor, of all things, it can happen to Newspeak.)

And finally, yes, http://robjsoftware.org was broken for the last month or two. I had one email filtering rule for all of GoDaddy, and when we moved to Seattle this spring, the address change broke GoDaddy's monthly charging, but I didn't see the warning because it was in the same bucket with all of GoDaddy's spam^H^H^H^Hinformative emails. Which I never read. Sigh. I clearly need a fully redundant alerting and monitoring system for my blog.

Life, it is the greatest

2008-10-08T21:49:00.000-07:00

Well, except for Blogger eating my profile picture, and GoDaddy eating my redirect from robjsoftware.org to blog.robjsoftware.org -- why can't things just Keep On Working? Entropy, I hates it.

Shortly after I griped last month about a lack of working FLINQ samples in the latest F# CTP, Don Syme himself came through nicely with just what I asked for. So yay Don! And yay F#! And boo me, because I have not done thing one on the personal-hacking front in the last month. In fact, that aspect of this blog is going to go quite dark, if current evidence is anything to go by.

Not to say I'm not still deeply digging geeky things -- I'm currently reading my way through the extremely excellent Parsing Techniques, The Second Edition. My upcoming task at work is to do a whole lot of parsing stuff, and this is exactly the book I need. It's amazing. I've been reading scads of parsing papers (one-stop shop for me: Bryan Ford's Parsing Expression Grammars page), but I lacked the basic background -- what exactly is LALR? How do shift-reduce parsers work? How do you convert a left-recursive grammar to a non-left-recursive grammar, and what does it do to your attributes? Well, the Parsing Techniques book is absolutely the best imaginable text for me. It's the second edition, just published this year; the first edition was from 1990. How beautifully synchronistic that it should come out just when I absolutely vitally need it! I LOVE it when that happens.

And honestly, there are two other reasons I'm not getting much solo hacking done. One is that I'm climbing about 20 learning curves at once in my day job, and it's saturating my technical novelty bandwidth. There's not a lot of extra juice right now for doing yet further explorations in the evening. The other reason, and this is something I have yet to blog about here, is that it's the fall season, and that means GAMES.

Yes, the truth is out: I'm a fairly inveterate computer/video gamer. It's been a hobby of mine ever since I first laid eyes on a computer -- literally; the first computer I ever saw was a PLATO timesharing system at my best friend's doctor father's medical school in Connecticut. And what was it running? Spacewar. I still remember it vividly.

Ever since then I've been happily gaming away, and in many ways it's the perfect hobby for a compulsive hacker -- video games push technology in a lot of ways, and modern games use cutting-edge 3D graphics, physics simulation, distributed virtual space technology, and generally a whole lot of hardcore computer science in doing what they do. So not only do the games themselves get more immersive as games, but they also get more technically interesting and intriguing to learn about. Right now I'm playing Crysis, one of the most hardware-intensive games ever made (though people debate whether that's because it's not well optimized or just super ambitious). I finally got my self-built PC to run two graphics cards (through NVidia SLI), and man, this game is freaking stunning on my 1920x1200 26" monitor. (Which cost only $600! Damn, wasn't it just two years ago that this sort of thing was $2000+?)

So I'm giving myself permission to slack off, personal-hacking-wise, for the rest of the year. Unfortunately it looks like it will still be a good long time before I can post in depth about what I'm actually working on at Microsoft, but suffice to say that I really do look forward to that, and it will happen sooner or later, and the longer it takes the more I'll have to say when the veil finally drops. But rest assured, it's freaking cool and you will love it when you see it :-)

Best laid plans, mice, men, etc.

2008-09-03T21:33:00.000-07:00

Well, not a lot of F# hacking got done last month. I did download the then-current F# build, and tried out some of the FLinq samples, and they didn't work. I posted about it on the F# mailing list (Microsoft, your mailing list server needs some serious kicks in the pants region), and there was no helpfulness forthcoming. So, onto the (cold, dark) back burner it went.

Which was fine, because ordinary life (summer vacation for the kids, my birthday, etc.) was plenty busy. And my work has exploded into a drinking-from-the-firehose geek frenzy -- I wrote a monadic push parser the other day, and got paid for it. Not clear whether it'll ever ship, but it was definitely relevant, which rocks. I can now say that I have lost my monadic virginity. Whether I should say it is another question. (My wife says not....)

However, on the bright side, the F# team did ship their CTP (Community Tech Preview, or something like that, for those outside the MAZ (Microsoft Acronym Zone)). So I'll take another run at it later this month. One cool thing is they have support for dimensional quantities now, a la Fortress. Only F# is basically here now, and usable for production software, whereas Fortress is still N years away from having any kind of realistic compiler. So IN YOUR FACE, Guy Steele! (Seriously, Fortress looks great. It's just that F# is here now, and is pretty great itself.)

OK, time to get back to watching a truly monster build crunch away. Work is creeping out of normal working hours -- getting assigned a fairly major team-wide task tends to have that effect. It's also cutting into my discretionary hacking and gaming time considerably. We'll see what the next month holds....

Not Dark, Just Busy

2008-08-03T14:04:00.000-07:00

It's amazing what a difference not commuting can make. Up until our move to Seattle in April, I'd been commuting an hour each way every day into San Francisco. That time on BART -- without net access -- was where all my blogging got done. Well, now I'm driving 15 minutes each way to work (modulo time to take my daughter to her school), and still coming down off the stress of moving, so I've been putting my energy elsewhere in the evenings. In any case, consider this a summer vacation for your RSS feed :-)

Not that I've personally been vacationing -- not at all! I'm finally getting up to some kind of reasonable cruising speed at work. It's been a colossal re-education in .NET, C#, low-level Windows debugging, SQL data stack design, and about 50 different interesting research projects which I can't really discuss -- at least not yet. It's very educational being on the list for all the different talks that happen inside Microsoft Research; there are a lot of different pies that those folks have their fingers in. The internal Windows developer talks are also very intriguing.

Now, this isn't to say that everything is on the hush-hush. Some of the better publicly visible tidbits I've run across lately involve LINQ, the techniques for basically doing data-oriented metaprogramming in the .NET framework. I mentioned LINQ in my last post, but suffice to say that it's a combination of a set of data-oriented query operators (that form a composable, monadic algebra), some syntactic extensions to allow more idiomatic SQL-like query expressions, and an internal syntax-tree representation that can be transformed into native query languages (including but not limited to SQL) and partially evaluated into high-performance serializers. Overall it's a very well-thought-out structure with a lot of room for growth. To wit:

DryadLINQ extends the LINQ operators to support MapReduce-like distributed cluster computation at scale.

PLINQ and the ParallelFX framework are building up the .NET infrastructure for fine-grained parallelism and efficient use of multi-core for data-parallel problems.

Matt Warren's series on implementing a LINQ query provider is a great example of metaprogramming in practice -- taking a C# abstract syntax tree describing a query, and transforming it into efficient SQL. This is the technique that is at the heart of LINQ. I've heard tell of F# projects that are using LINQ-like expressions to describe linear programming constraints declaratively -- same metaprogramming paradigm, completely different domain.

All of this is exciting because you noble long-term readers (e.g. since December 2007) will know how interesting metaprogramming is to me. Microsoft really gets it on multiple levels, and has put it into production with LINQ. There's a lot more on the horizon, too, and I'm eagerly waiting for each bit of it to reach RTM in some form so I can happily blog away about it!

Not only that, but I have a personal hacking project again. Matt Warren's blogs (mentioned above) are a great example of how to implement metaprogramming with an imperative C# visitor-style API. But I find the code hard to read -- it's taking this lovely declarative representation and then transforming it with all of this intensely imperative, explicitly scheduled transformation code. It reminds me of the JastAdd project, which has evidently now reached public release. JastAdd creates a declarative framework for implementing language analyses and transformations. I want to hack on an F# implementation of the JastAdd paradigm, applied to LINQ to SQL transformations. It would be very interesting to see if it could lead to something significantly easier to maintain and reason about.

This is something that arguably is potentially relevant to work. So I am going to blog about it internally first, and then repost publicly a week or so later (on a per-post basis). If it gets to where it is interesting enough for Microsoft to want to privatize it, I'll just have to find something else to blog publicly about! In any case, it'll be fun to post about here for as long as it lasts :-)

There's Nothing Micro about Microsoft

2008-06-23T21:26:00.000-07:00

Hello everyone. Ah me. We live in Washington now! (State, that is.) We're happily ensconced in a nice rental home in Kirkland, and so far just about everything we hoped for from the move has happened -- we have less commute, cooler weather, a better school for our daughter, and my wife no longer has to work. And my new job at Microsoft is going very well so far, though I've actually been there less than a month -- I took May off to help our family settle in, and THANK GOODNESS, because moving is a LOT OF WORK even once you actually arrive!

But so far so good up here... I'm sitting in our living room looking out at the evening sky and the pine trees across the street, through the full-length windows and French door that front our house. It's beautiful up here.

I can't say too much in detail about what I'm working on, because Microsoft (like Google) is mighty touchy about confidential projects. But I can make some general observations after being back on the inside of the Borg for a few weeks. (I was amused to discover that they remembered me! I interned at Microsoft in 1988 and 1989, and I guess they gave me employee number 40775, because when I signed back up they gave me the same number back again. People were like, why are you 40775 rather than 263484? Microsoft's gotten BIG over the years....)

It's very curious how deep the not-invented-here goes at Microsoft. It seems to be partly historical -- Microsoft was such a winner-take-all company for all of the eighties and nineties, it sank deep into the marrow of the company. And it is partly reactionary -- the rest of the industry reacted so negatively to that aggressive attitude (antitrust suits, pitched legal battles with Apple and Sun, etc.) that it drove Microsoft even further into its own corner. I've got kids now, and I think a fair bit about sibling rivalry, and how kids (and adults, and nations) tend to define themselves in opposition to one another... sometimes your identity emerges through your interactions with your peers. That's definitely happened to Microsoft, and as a more than thirty-year-old company, it's going to change only slowly if at all.

Regardless, Microsoft really is its own technological world now. And this has its good points and bad points. Coming from the Java world, and from California where lots of my friends are vehemently anti-Microsoft, it's a bit bemusing to see it all with an outsider's eyes... plenty of my new colleagues have been here for decades, which is almost unimaginable to me. It's certainly part of my value here, that I've got recent experience with how things are on the Outside.

I can't be too specific, but there are quite a few areas where I feel like Microsoft's internal technical isolation is hindering them... particular tools that seem like a step backwards, or particular design problems where it seems like there just aren't quite enough people providing fresh ideas. The relative isolation of the Microsoft software stack can seem a bit... I don't know... lonely? The "us vs. them" thinking is hard to escape in the blogosphere, and it's such a polar choice -- either you're on Windows / .NET, or you're not. And if you are, you've got to pay to play -- at my last startup, we were a Linux and Java shop, partly because it got the job done and partly because it was free. (Though as one of my new cronies says, the people who won't pay aren't customers anyway, because how can you make a business out of non-paying customers? That's a very deep-seated belief in Microsoft-land, and you know, there's some truth to it.)

But on the flip side, there are some real advantages to owning all the code you could possibly need to run an entire industry of PCs. I've spent the last two months spinning up on LINQ, one of the coolest new features in C# 3.0. It stands for Language Integrated Query, and on the face of it it seems like syntactic sugar to let you write SQL-like code in C#. But it turns out that under the hood there's a lot more to it -- it's implemented via compiling language statements into expression data structures, that can then be rewritten, reparsed, and used to generate entirely different kinds of language output. It is very cool technology, very useful for creating domain-specific languages -- in fact, it's rather along the lines of my extensible language rant from a few months ago.

And it would not have been possible if Microsoft didn't completely own the C# and Visual Basic languages, and have the resources to come out with a new iteration of the language spec, and all the compilers and tools to support it, simply because they thought it was a good idea. Compared to the slowness of Java's evolution (how long has the closure spec been rattling around?), Microsoft's ownership is yielding real benefits to .NET programmers. (OK, so the closure spec is deeper and wider-reaching than C#'s lambda expressions, but nonetheless there are several intersecting features in C# 3.0 that are all needed to make LINQ work, and I don't see Java catching up very quickly.)

It's also pretty amazing to see the breadth of the expertise here -- my team happens to be pretty closely connected to Microsoft Research, which is teeming with world-class experts. If you look at the roster (Simon Peyton Jones, Don Syme, Erik Meijer, Galen Hunt, Nick Benton, Martin Abadi, Luca Cardelli... heck, search 'em yourself!), you'll see a whole lot of people who've driven the world of software forwards. Microsoft has a deep commitment to that goal, even if their not-invented-here, no-open-source mentality gets in the way sometimes. So it's exhilarating to be part of that mission.

Microsoft is a colossal company, and I'm fortunate that I've landed in a very ambitious and solidly supported team -- in fact, I can't think of any job I'd rather have in the industry. I'm feeling very lucky indeed, and I'm doing my best to get productive quickly -- this opportunity isn't going to come along again anytime soon!

And, that said, I'm obviously not doing very well on keeping to my blog schedule. Realistically this blog is going to slow down a bit, probably to more like once per month. Eventually -- once our team's incubation project goes public (knock on wood!) -- I'll hopefully have another blog on msdn.com where I'll blog semi-officially about our technology. But this blog will be my personal property into the indefinite future. Stay tuned!

Only 20,000 Lines

2008-04-14T21:37:00.000-07:00

A while back I posted a big ol' post titled A Growable Languge Manifesto which argued strongly for extensible languages.

Well, I just ran across the one-year progress report from Alan Kay's current research group, and it's some extremely exciting work that is all about extensible languages!

The group is the Viewpoints Research Institute, and the progress report lays out their plan to implement a complete software stack -- everything from the graphics driver, to the language interpreter / compiler, to the TCP/IP stack, to the windowing and rendering system, to the IDE and programming environment -- in 20,000 lines of code. Total.

As they point out, a TCP/IP stack alone in many conventional languages is more than 20,000 lines. So how can they possibly pull it off?

The answer, it turns out, is extensible languages. Specifically, they have an extensible parsing system -- OMeta, cited heavily in my manifesto -- which allows them to easily and quickly extend their languages. They also have a "meta-meta-language runtime and parametric compiler" named IS, which is how they actually get their languages and metalanguages into executable form.

One especially cool example is their TCP/IP stack. The TCP/IP specification has text diagrams of packet formats. So they wrote a grammar to parse those specifications directly as ASCII. And lo and behold, they could use the TCP/IP RFCs themselves to generate their source code. They also can use their parsing framework to analyze the structure of TCP/IP messages -- they basically define a grammar for parsing TCP/IP messages, and action rules for handling the various cases. (OMeta lets executable code be attached to matching productions in a grammar.)

They also wrote domain-specific languages for just about every area. One example is low-level pixel compositing, basically giving them the functionality, and most of the efficiency, of a generative 2D pixel processing library such as Adobe's Generic Image Library, cited in Bourdev and Jaaki's LCSD 2006 paper. Another example is polygon rendering (450 lines of code that implements anti-aliased rasterization, alpha compositing, line and Bezier curve rendering, coordinate transformations, culling, and clipping). Though evidently they have yet to fully define a custom language for polygon rendering, and they hope to cut those 450 lines by "an order of magnitude".

Basically, they take almost all parsing and optimization problems and express them directly in their extensible language, which gives them almost optimal flexibility for building every part of the system in the most "language-centric" way possible.

They have no static typing at all, which doesn't work for me (though their line counts make a compelling argument), but there's no reason in principle that these techniques couldn't also apply to static type system construction.

In fact, there is work right now on intuitive language environments for creating written formal definitions of programming languages. A system like Ott lets you write semantics declarations that look like they came straight out of a POPL paper, and convert them into TeX (for printing) or Coq/Isabelle/HOL (for automated verification). I don't know how far the implementation of Ott or Coq/Isabelle/HOL would change if Viewpoint's techniques were aggressively applied, but I look forward to finding out!

I think this kind of programming is the wave of the future. Reducing lines of code has always been an excellent way to improve your software, and the expressiveness of a language has always shaped how succinctly you can write your code. From that perspective, it seems obvious that an extensible language would provide maximum potential increase in expressiveness, since you can tune your language to the details of your specific problem. It's a force multiplier, or possibly a force exponentiator.

Object-oriented class hierarchies, query languages, XML schemas, document structures, network protocols, display lists, parse trees... they all share a common meta-structure that the "extensible languages" concept subsumes, and the Viewpoint project is the clearest evidence I've seen of that yet. It's going to be a dizzyingly exciting next few years in the programming language world, and programming might just get a lot more interesting soon -- for everybody.

There's more to say on that topic, but I'll save it for another post!

My New Job

2008-03-23T20:50:00.000-07:00

Well, this post has been a long time in coming. Finally all the stars have aligned, and I can announce to the world (i.e. you!) that I have accepted a job at Microsoft. My family and I are moving up there in just a few more weeks -- we sold our house (in one week flat! amazing what price reductions can do), and are in escrow. Which also explains the loooong delay since last post.

What exactly will I be doing? I'll be working for a technical strategy incubation team, which kind of sits in between research and line development. We're working on a new operating system stack from boot loader all the way to applications. I can't really say much more, except that what we're doing is not entirely unrelated to the Singularity operating system.

Having spent the last twenty years in the bay area, hotbed of anti-Microsoft sentiment, I am pretty sure that I have quite a few readers (and friends!) who will be wondering why exactly I'm joining the Evil Empire. Especially when I interviewed with quite a few other places, including Amazon and Google. What's up with that?

There are a few answers to that question:

I don't like how Microsoft has abused their monopoly power, but I also have been a Windows user for the last sixteen years, with quite reasonable satisfaction. So I personally have never quite swallowed the "Microsoft is Satan" kool-aid.

The more blogs I read by Microsofties (especially the anonymous ones), the more I see that Microsoft's internal self-assessment is by no means all rosy. Microsoft engineers seem quite aware of when their stuff sucks. The existence of the team I'm joining is arguably proof of that exact fact.

It's possible that working for Microsoft will circumscribe what I can blog about without making lawyers mad. However, that's just as true of Google, which is also notoriously secretive. Google also has had quite a few criticisms directed at its business practices. Basically, size, confidentiality, and ethical qualms seem unavoidably linked. (It's true that Google does more open source stuff than Microsoft, but that may be changing as well.)

If our stuff is great and makes it into Microsoft products, it could potentially make life better for a whole lot of people. Operating system work at Microsoft can have a broad impact in a short time, if it's successful.

I'll also be working with some old friends from my Xanadu days, along with some relatively well-known other folks, including Pavel Curtis and Chris Brumme. I got to meet a good cross-section of the team and I'm very jazzed. My research paper addiction paid off handsomely, it turns out!

I spent the entire last week of February interviewing. I did get offers from other places, each of which I greatly appreciated.

I got a great offer from the Prime team at Amazon, also, which seems like an extremely sharp group; I will definitely be keeping a close eye on Amazon as they grow their distributed infrastructure business.

I also interviewed with a startup, which I expect to do very well (keep an eye on Apptio -- though they'll be rebranding themselves soon!). If I hadn't spent the last ten years in startups, none of which has (yet) had life-changing success, I would have probably jumped on them just for the raw upside potential; as it is, though, I'm ready to try a megacorp.

(To my Google friends: Google was very interested but ultimately turned me down. Might have partly been timing issues on my end. So, looks like it'll be a while (at least) before I'm working with you all. I'll also need to pull back from the GWT project. It's been a great few years in Java-land but it's time for a change, and I'm looking forward to C# generics :-)

All in all it was a very difficult choice across the board!

In general the whole week was the most fun I've ever had interviewing, despite the fact that I had a big bandage on my head for most of the week (beware of low pine branches after dark!!!). I sincerely thank everyone who took time to meet with me in person or by phone over the last few months.

Now to start walking the fine line between saying too little and too much. I don't plan to go dark on this blog, though I also won't (yet) be able to say much about my day job here. But that won't stop me from the general research paper talk to which you're already accustomed!

Simple Pieces, Dying Quickly

2008-02-18T21:11:00.001-08:00

Late. Again. I assure you there are perfectly good reasons for this that, I further assure you, you do not want to know. Good news is things have radically improved in the last few days and the future is extremely bright. I'm squinting right now, in fact.

There are some architectural patterns that just Feel Right. That feeling of rightness isn't always reliable -- it can lead you pretty badly astray -- but still, it's there. And sometimes, what do you know, it even is right.

For years now I've been following research into microkernels, starting back in the early nineties when I was reading about Amoeba, an old-school distributed system structured as a set of small components. The idea of structuring an operating system as a set of isolated pieces, protected from each other and passing data only by well-defined messages, seems conceptually clean. It's started to gain traction lately with projects such as the L4 kernel, the Coyotos project, and Microsoft's Singularity, and IBM's K32.

Interestingly, one of the biggest obstacles to the wider use of microkernels is Linus Torvalds. In late 2006 he had an online spat with Alex Tanenbaum, developer of Amoeba (back in the day) and Minix3 (new hotness). Linus has been saying for years that microkernels are a crock, and that operating systems are best built with extensive use of shared memory, because -- in his view -- what operating systems do is provide coherent views of shared state to multiple processes, and without a single shared state available to the whole kernel, providing a coherent view becomes much, much harder. Linus draws a parallel between microkernels and distributed systems, pointing out that distributed protocols are really hard to implement, precisely because you don't have common state.

Personally, I agree strongly with Tanenbaum's (and Shapiro's) rebuttals. Tanenbaum points out that distributed protocols also have to deal with partial failure and reordering, which are not problems that microkernels have. Inter-component communication within a single machine's operating system can be radically simpler than communication over a network (even though multicore machines do start introducing some timing variability). Also, of course, shared state in a monolithic kernel still requires concurrency management, and the complexity of managing concurrent access to shared kernel state is by far the biggest single source of Linux kernel bugs. Just look at all the work on massaging the locking patterns in the Linux kernel (getting rid of the Big Kernel Lock, etc., etc.). For Linus to claim that micro-component kernel development is more complex than monolithic concurrent state management is... well... not as obvious as he seems to think.

Shapiro points out that all robust engineering practice has shown that high reliability requires high isolation between small, robust components. He claims, and I agree, that there are no large-scale highly reliable systems that are not built from small, modular, isolated pieces. Certainly Erlang provides another data point that high reliability comes from many small interacting components, rather than from large-scale shared state.

Small, modular components get you other benefits, such as upgradeability (if your microkernel tracks references between components and manages inter-component message passing, you can upgrade individual pieces of your system without shutting things down -- Erlang applications also work this way). Security is also enhanced if the compromise of a single component doesn't expose the entire state of your kernel.

There are also interesting parallels between building single-machine operating systems as sets of modular services, and building large-scale Internet systems as sets of modular services. In both cases, you want to build something big and reliable from individual pieces that communicate over explicit interfaces, and that can be individually quickly restarted when they fail. In an operating system, your drivers are the flakiest piece, and when they die you want to be able to reload them without the rest of the system batting an eye. In an Internet service, your individual servers are the flakiest piece, and when they die you want to be able to fail over to other (mostly identical) servers without batting an eye. Isolation between components is critical in both cases, and you want to build your whole system in a layered way with redundancy and restartability at all levels.

Linus is correct that distributed transactions (for example) are hard to build out of individual components. But it's also true that as you scale, distributed transactions are one of the biggest architectural system-breakers. Amazon, for instance, doesn't use them (see also here), instead relying on careful ordering of service updates to preserve consistency in the face of intermediate failures. And many microkernel operating systems are also structured to avoid multi-component consistency interactions wherever possible.

So I think this is a rare example of where Linus is squarely on the wrong side of history, and where Linux will likely fall behind other systems that push towards greater modularity and greater internal componentization. It's an interesting question whether large-scale Internet services will, over time, make individual-server operating systems less important -- in other words, whether most applications will migrate to a highly-managed cloud, in which case most computers will wind up being more like thin clients, with all the action happening on a virtualized pool of services. But even in that case, the companies building those services will still want to leverage multi-core technology to the max, which essentially means building their individual service instances using highly isolated component architectures. Having such an architecture at the base of the operating system can only help achieve that goal, and it's sad to think that Linus (on current evidence) will get in the way of that for Linux.

Inside Stories and Posted Mortems

2008-01-22T21:55:00.001-08:00

Yikes, just missed my two-week window. Too much happening, too busy... get used to it, folks, it's here for the duration, e.g. until this summer, after we've sold our house. Enough of that! Onwards!

Research papers are one of my biggest Internet weaknesses. Another one is post-mortems. If we learn from others' mistakes, then post-mortems are solid education... they're experience reports in their most tangible form.

For some reason, it seems there have been a whole slew of interesting ones on the net recently. Here they are:

Lambda the Ultimate cited this analysis of why Symbolics failed, as footnoted by Daniel Weinreb. Short story: too much technology, too little business focus. Still, interesting to get the inside view.

Even better are Daniel Weinreb's posts about the history and impact of Object Design and Objectstore. Orthogonal persistence once seemed like a Really Good Idea to me, until we tried it at Electric Communities in the mid-nineties and couldn't make it work. Even so, it looks like there are some valid use cases that Objectstore exploited about as well as possible. Did you know Amazon evidently relies on Objectstore caching for their entire inventory database?

Switching gears almost completely, from civilized discussion to rabid flaming, Zed's infamous rant on leaving the Ruby community deserves mention. (WARNING: SOME NOT-SAFE-FOR-STRAITLACED-WORKPLACES CONTENT!) I have to admit I have a weakness for, shall we say, colorful language. The BileBlog (WARNING: DITTO!) was entertaining for a long time, though recently it's gone dark... maybe Hani decided the career impact wasn't worth the flameful fun. I've been tempted to go balls out and get explicit here, but the more I consider it, the less necessary it seems. Wait, that was all a huge digression away from the facts, which are that Zed's rant is entertaining but I have no idea how accurate it is, and his comic self-promotion makes it hard to tell when he's being serious and when he's not, which hinders his message. He kind of wants to have his cake ("I'm so awesome, truly") and eat it too ("Can't you tell I'm mostly joking?"), which doesn't do him any favors.

Meanwhile, the poor beleaguered Open Source Applications Foundation recently announced that Mitch Kapor is washing his hands of it all. No more funding on his nickel, almost two-thirds of staff laid off, and Katie Parlante left to try to turn it all into real revenue somehow. After six and a half years of Python hacking, they still barely have a usable application. Scott Rosenberg already told the whole epic story, but this seems like almost the last gasp. Open source projects can perish without clear architectural and requirements leadership, and OSAF will forever be the paradigmatic example. (I largely agree with, again, Dan Weinreb's take on it all. I wonder if a good dose of RPython would help out Chandler at all?)

Finally, this isn't new news (totally the opposite!), but I've got my own personal post-mortem skeleton in the closet, namely my involvement with the legendary Xanadu project. I'm quoted in the Wired post-mortem article. Some of what I said there was classic "this kid is young and bitter" uncensored vitriol. I'm glad that the brilliant people I worked with there understood that, because I want to work with some of them again some day! But overall, there is a lot of truth in that article, and it's just a great read regardless. (Warning: that link is to the printer-friendly version, and Wired, under their new Conde Nast overlords, has lost their web-fu and has broken image links everywhere. Doesn't matter; the text is all that counts in this instance.)

I've made some whopper mistakes in my career -- some quite recently -- and it's too bad it will be a long time, if ever, before I get to tell the tales. (The downsides of modern tight-lipped corpocracy....) Still, we (hopefully) live and we (hopefully) learn. The more post-mortems, the better!

GWT2007 Video, Brain Teasers, and Semantic Metatheory

2008-01-04T20:47:00.000-08:00

It's almost terrifying how busy things are right now in robjsoftwareland. Moving with two young kids is just not the best idea from any kind of sane logistical perspective. Trust me on this. PLEASE. My life is a continual rolling boil of domestic packing and repacking and remodeling and general chaos, and it will continue for months to come.

But I cannot and will not go dark on this blog. So, a quick update:

1) The video from GWT2007 got posted! If my previous posts about my RPC talk made you curious, you can now see for yourself. I'm amused at the Sartre reference that snuck into the video :-) I think it came out quite well overall (with the caveat, as before, that an unexpectedly large portion of the audience were newbies who didn't get the most out of it). The other talks are also online -- now I'll get to see the ones I missed! I'd also recommend Billy Hoffman's talk on security (warning: one short NSFW item in there!).

2) I'm currently putting all research papers and language-y thinking on hold for a few months. Instead I'm getting back to basics. All my side reading/hacking time is going into plowing through these two books: Introduction to Algorithms and Artificial Intelligence: A Modern Approach. I've generally in the past spent most of my time reading current research, because books get out of date so quickly. Well, not these two! They come pretty darn close to being timeless.

One quick brain teaser from the algorithms book: Everyone knows how to write a recursive algorithm to print an inorder traversal of a binary tree. Almost everyone knows how to convert it to an iterative algorithm using an explicit stack, too. But the book mentions that -- if your binary tree contains parent links as well as child links, and if you can test pointers for equality -- you can actually write an iterative algorithm to do an inorder traversal without keeping an explicit stack... in other words, an iterative algorithm that uses constant space (rather than space proportional to the depth of the tree). It took me about twenty minutes to figure it out. How about you?

3) One of the more interesting posts recently on good old Lambda the Ultimate was this post by Paul Snively asking whether syntactic or semantic theory is the way of the future. Most approaches to programming language theory historically have been largely syntactic, but there are a number of recent papers that take a purely semantic view.

While I'm still learning this field myself (and haven't spent nearly enough time on the basics -- Pierce's syntactically-oriented Types and Programming Languages is on my reading list, but so far I've only dabbled), it seems to me that semantic approaches have an intentional stance that might make them fundamentally more general. For example, this paper on semantic verification of a simple compiler makes the point that a typed assembly language program can only go wrong if it tries to treat a given memory location as being of an unsafe type, but that there might be possible values in that memory location which can be safely interpreted as other types without inconsistency.

This approach reminds me of the Logic of File Systems paper, in which file systems are modeled in terms of their beliefs about the contents of memory versus disk. It's a fascinating philosophical view, to think of programs as enacted, operational beliefs and to consistency check them on that basis. A program only goes wrong if its beliefs are inconsistent with the contents of the machine, as opposed to being inconsistent with its own source text (represented as base terms of the program). It's going to be fascinating to see how far the semantic approach can be pushed.

That's it for early January -- see you in about two weeks!

Me, Manifesto, GWT2007

2007-12-20T12:08:00.000-08:00

Sigh, another two weeks gone by without a post. Still, that last post was a doozy, so cut me some slack, willya? Incidentally, my readership has increased by 50% in the last two weeks according to Feedburner. I am honored to have all of you paying attention to me, and I will try to be worthy of your eyeballs and neurons.

This post is going to be a bit of a catch-all: some about me, some about my last big-ass posting, and some about the GWT conference.

First, sorry I missed last week -- I got another cold (endemic in the wintertime with two young kids in the house), and my wife kicked into moving high gear. Yes, we're selling our house, for a wide variety of reasons I will discuss in personal email if you're interested enough to send me some. (Not in the comments, sorry!) We're shooting for having it on the market March 1, which means there is no time at all to waste. I'll be doing no hacking for the next two and a half months, that's an absolute given. I'll keep up the blogging, but weekly may be tough; bimonthly WILL happen if it kills me!

Which is all too bad, in a way, because there's plenty to do in hackland. My manifesto was rather well received. The comments on the post itself have a number of intriguing links. I also posted about it on Lambda the Ultimate, where it got a number of other fascinating responses. Thanks to all who engaged with it in either location. I am sorry I won't be able to touch it until March first at the earliest, but that's the nice thing about research -- interesting ideas don't go away!

I also wanted to give an update on the GWT conference. My talk was quite well received if the consensus speaker's feedback was anything to go by. I appreciate the appreciation, to say the least. I did hear that there was a significant fraction (over 50%?) of the audience that felt it was too technical. Evidently a substantial quorum of GWT2007 attendees were relatively unfamiliar with GWT at any level. I apologize to anyone who wasn't experienced enough to get the most out of my talk; I hope that you can find helpful material on the GWT site and/or any of the various GWT books. I've put my slides online for anyone interested. Evidently it'll be Youtubed sooner or later, but I've yet to get a date on that.

The last morning of the conference, we had a participatory breakfast session where Joel Webber and I led a discussion of declarative UI and declarative data binding in GWT. One thing that was clear from my talk is that there are a lot of people doing form-like web applications, and GWT underserves that population right now. Joel spent some time going over the declarative UI work he's doing; he specifically mentioned that various internal Google customers want him to ensure that you can write a GWT-XML document that lays out a GWT widget tree with HTML fragments mixed in almost arbitrarily. This seems like a win insofar as Joel's talk on performance specifically mentioned that innerHTML is your friend; the DOM is faster at inserting HTML fragments than it is at handling individual DOM element insertions. So everyone keep an eye on Joel's stuff as it hits the incubator.

I asked the table what kinds of form-data-binding approaches would be most useful to implement. The consensus seemed to be split. A number of people were familiar with the JSF-like structure of binding to backing beans and using expression language to specify the coupling from bean fields to the UI. I mentioned JSR 295 and various people expressed interst in that. There is a recent thread on the GWT contributors forum about some community work in this very area, which I look forward to investigating in depth (in early March! :-P ). Check that thread out if you want GWT to do this. I talk at more length there about a potential GWT EL parser.

There was one gentleman (whose card I got, and subsequently lost; please contact me again, sir!) who was a forceful advocate of an XForms-like approach; evidently XForms lets you declaratively specify data dependencies within your model, and allows you to lay out interactions witihn your UI purely in your interface specification. This was pretty much news to everyone at the table. I will definitely have to look into XForms now. However, it seems to me that a JSF-like, JSR-295-like bean-binding approach covers many of the basic use cases people want, and should certainly be a near-term project.

OK, that's it for this week. Happy, happy holidays to you all!

A Growable Language Manifesto

2007-12-04T11:11:00.000-08:00

Warning: this is by far the largest and most action-packed post I've ever made. Grab a cup of [insert favored beverage here], sit back, and enjoy. If you get headcramp from reading this in narrow-column blog format, there's another full-screen version here -- but please return to this post to leave your comments!

I've posted recently about the dynamic versus static flamewar and about recent research in extensible languages. The more I think about these ideas, the more compelling they get. It seems clear to me that these ideas are synergistic and point in the direction of a new kind of programming environment -- one which could potentially offer the ease of dynamic languages, the safety of static languages, and an altogether new level of extensibility (both for enhancing the type system and for allowing safe metaprogramming.)

So I want to lay out a manifesto here for a growable programming language. Or perhaps it's more like a toolbox for language construction. Or perhaps it's a framework for experimenting with extensible syntax and extensible analysis. In any case, here is the vision. At the end, I include extensive references to the research that's inspired these ideas.

A growable language should be opt-in. It must support a graceful spectrum of usage styles. A growable language will necessarily be multi-paradigmatic, since it will be extensible with features from various fields of programming. The language should implement a dynamically-typed core on which all static analysis is built, to allow programmers a straightforward and lightweight syntax for prototyping.

A growable language should be increasingly powerful. It should support a rich and expanding variety of static analyses and dynamic checking, to give maximal benefit to the programmer who wishes to leverage these features. over time, as more program analyses become possible, a growable language should gracefully integrate them. A growable language must continually increase the expressive power of the programmer, both in terms of what the programmer can say and in terms of what the environment can help the programmer prove about their program. A growable language should have a powerful analysis framework as a foundational component, such that other analyses can share that basic capability; wherever possible, additional analyses should require only incremental effort by leveraging infrastructure already created.

A growable language needs a declarative metalanguage. Current languages do not define inherent mechanisms for syntax extension and for type extension. The syntax and the type system are both baked into the language's compiler. A growable language needs to lift the specification level of the language itself to be both declarative and modularly defined, so that syntax and type analytics can both be expressed and implemented as layered extensions.

A growable language needs partial typing. Certain analyses are necessarily incomplete or even undecidable. A growable language should permit such type systems, and should be able to fall back on dynamic typing whenever analysis is inconclusive. This lets programmers work freely without having to continually meet the demands of the type system, yet supports graceful type annotation to enhance static safety at the programmer's discretion. (Without partial typing, the opt-in goal cannot be met.) The language should ideally provide clear feedback as to when its analyses are conclusive or inconclusive, and ideally should identify the sources of inconclusiveness so the programmer can either annotate them appropriately or deliberately ignore them.

A growable language needs layered types. A growable language should be able to extend itself with primitive types, dependent types (e.g. data-dependent subrange types), traits or other parametric or abstraction-based genericity mechanisms, and multiple flavors of type qualifiers. Integers should be as much of a language extension as non-null types, tainted types, or range types. A growable language requires an extensible subtype lattice.

A growable language needs inferrable types. To avoid drowning in explicit type declarations, the language should be able to infer types wherever possible, and the programming environment should support controllable visibility for the inferred type information. Without inferred types and environmental support for controlling analysis visibility, a growable language cannot scale for users; being able to selectively ignore some or all of the (many) analyses is critical.

A growable language needs explicit, optional type annotations. An extensible analysis framework will be able to infer or deduce a great deal about the actual behavior of the program. But the actual behavior of the program may or may not correspond to the programmer's intent. The programmer's explicit annotations express the programmer's expectations. A programmer might look at the analyzed annotations and make some of them explicit -- perhaps they reflect properties of the code that the programmer considers important after the fact, and that the programmer now wants to enforce. Or a programmer might add explicit annotations during development, such that the system can confirm they are valid and warn when they are violated. Explicit annotations at module boundaries -- whether programmer-generated or system-generated -- are likely to aid in separate compilation and in module documentation.

A growable language must be efficiently implementable. As more language features are added -- more qualifiers, more types, more syntax -- the language must still be efficient and usable. This applies both to programs written in the language (which should have performance competitive at least with Java or the CLR) and to programming environments for the language. The latter requires aggressive attention to analytical optimizations and to multi-threaded analysis frameworks. As the language's analysis structure grows, the language's programming environments must be able to leverage multicore architectures to ensure consistent responsiveness for users. Moreover, the language should be continuously analyzing in the background; incremental feedback as the user edits should be available for all language features and extensions.

A growable language must have a unified internal representation. Concrete syntax, abstract syntax, type and name bindings, type qualifier propagation, type parameterization, dependent range type constraints, and logical queries over the program's alias structure should all leverage a single internal representation of the program. This maximizes the reusability of internal language implementation code and ensures consistency in analytical derivations. Where multiple representations are necessary, the derivation rules must be clear and consistent.

A growable language must promote static metaprogramming. Fully dynamic metaprogramming -- runtime extension of classes and objects with arbitrary code, or even unrestricted dynamic reflective access to arbitrary methods -- is almost impossible to analyze effectively. To give a growable language's extended type systems maximum exposure to the actual behavior of the code, static metaprogramming techniques must be definable, extensible, and compatible with the rest of the language's structure. One would hope that the very extensibility techniques that implement the language itself would be usable for static metaprogramming.

A growable language must support diverse analyses. Some analyses are most naturally expressed as systems of recursive equations over an abstract syntax tree. Others can best be expressed as logical queries over a program's alias graph. Ideally these could both be expressed naturally in the metalanguage.

A growable language must be analytically composable. This is likely the single most technically ambitious goal. Traditional compiler development involves subtle and explicit scheduling tradeoffs, layering multiple analyses through manual interleavings that can be fragile or non-optimal. A growable language with a declarative metalanguage needs an analysis engine that can automatically schedule multiple, potentially interleaved analyses, leveraging parallelism where possible to optimize non-dependent analyses. Achieving this goal will be immensely difficult, but proportionately valuable. Interestingly, here is where the metalanguage itself will require many of the same extensibility properties as the language it describes; meta-level closure -- implementing the metalanguage using the language itself -- will be a holy grail for this language design.

Is the above language even possible? Is it too much of a stretch -- particularly the "unified internal representation" and "analytically composable" goals? Maybe so. I'm definitely not an expert at programming language implementation; the only compiler I ever wrote was back in high school. So this may be ridiculously unrealistic in whole or in part. I welcome feedback on which areas of this manifesto are more or less plausible.

Overall, consider this my stab at answering Paul Graham's challenge to ponder the hundred-year language. Given current trends in programming language development, it seems that languages of the future will transcend being "languages" as we know them and will become more like unified environments for language creation and extension. Arguably, this vision has a lot in common with intentional programming, which doesn't bode well, since the intentional guys have been in stealth mode for almost fifteen years and nothing has publicly come of it. But that doesn't mean the general direction isn't interesting, any more than the slow progress of Chandler means that a unified and flexible personal information manager isn't worth pursuing.

I promised references. Here they are:

opt-in -- Gilad Bracha's pluggable type systems paper is the origin of this goal. Bracha forcefully posits that static type systems are all necessarily incomplete and that dynamically typed languages have necessary flexibility. Meijer makes a similar point in his static where possible, dynamic where necessary paper. I'm not clear that Bracha's extreme view -- that all static analysis must be kept out of the language kernel -- is the correct one, given the potential performance cost, but I suppose RPython provides an encouraging counterpoint.

increasingly powerful -- There are increasingly many varieties of static analysis being developed primarily for Java. One recent paper on http://www.cs.umd.edu/~jfoster/papers/oopsla07-uno.pdf points out that its framework could straightforwardly be implemented on top of other analyses with similar intraprocedural resolution. The BDDBDDB framework has already been used for implementing taint analysis, and the JastAdd system for non-null Java type inference. In general it seems there is a lot of opportunity for shared infrastructure here. Also note that support for excellent error messages and great visibility into analysis results (and analysis failures) will be critical for usability. See Grimm's paper titled Systems Need Languages Need Systems for some forceful advocacy here.

a defining metalanguage -- Some good examples of metalanguages for syntactic language description are the OMeta pattern-matching language for executable grammars, Gilad's executable grammars in NewSpeak, and the Rats! extensible parsing system. A good example of an extensible language for static analysis is the JastAdd extensible Java compiler with its support for defining rewritable circular reference-attributed grammars... they implemented Java 1.5 generics as a modular declarative compiler extension, which proves their point to me, anyway!

partial typing -- The two best examples of this that I know of are the gradual typing work of Siek and Taha, and the hybrid typing for undecidable type systems work of Flanagan, Freund, et al. In both cases, a static type system is enhanced with a generalized type (named Dynamic or "?"), which is inferred to be a more specific static type where possible, and otherwise cast at runtime to preserve dynamic type safety.

layered types -- The already-mentioned JastAdd system is perhaps the best example of a structure which permits layering additional analyses. The extensible Java compiler Polyglot is another.

inferrable types -- My original thinking about this entire line of research originated in a blog post from a couple of months ago where I realized that some implementations of type qualifiers -- for example, a "tainted" type qualifier in C++ -- would ripple through the whole program due to mandatory explicit static typing everywhere. It's noteworthy that many type qualifier analyses for Java are not based on explicit syntax. For example, the taint analysis based on the BDDBDDB framework does not require explicit propagation of tainted or untainted declarations, yet it derives such information throughout the program's structure. An environment which made the results of that analysis visible -- and traceable -- at every program point would let the programmer see the flow of tainted values without having to explicitly declare them.

explicit, optional type annotations -- Programmers must also be able to add explicit qualifiers, since the programmer's intent may or may not match the analysis; the analysis may be incomplete and the programmer needs to provide more information, or the analysis may be consistent and the programmer wants to declare that they confirm it and want it to be enforced at that location (e.g. if the program changes such that the property is no longer true there, the language would signal an error). The programmer's explicit intent and the analyser's implicit understanding should be able to be flexibly cross-checked. I'm not aware of any inference systems that support this fully; they seem to be either purely inference-based (e.g. JQual) or purely annotation-based (e.g. a C++-based type qualifier system discussed in the "Extending Type Systems in a Library" paper from LCSD '06).

efficiently implementable -- This is obviously enormously difficult, insofar as analyses can in general be interdependent. There is a great tension between layering analyses (for separability) and weaving them (for mutual dependence and synergy). See the "analytically composable" goal below. In general, I wouldn't be surprised if aggressive parallelization of a language analysis / compilation framework required software transactions to support optimistic and incremental analysis by multiple threads.

a unified internal representation -- I mean something along the lines of Grimm's declarative extensible syntax trees, a concept proven by his weaving of Java and C typechecking into a single system. The JastAdd framework is another example; there is no separate symbol table in JastAdd, since name bindings become reference links in the abstract syntax tree (which is really more of an abstract syntax graph). Note that JastAdd's own declarative language for extending the syntax tree is fundamentally similar to open classes, in that subsequent extensions can directly modify the structure of already-defined syntax node classes. This seems to inhibit modular development of language extensions, but modular language extension development is really hard anyway.

promote static metaprogramming -- This goal is about ensuring the entire program text remains analyzable, and about permitting domain-specific languages to be implemented in the same structure used for extending the base language. See OMeta's SQL extensions or C# 2.0's language-integrated queries which reify some expressions as syntax trees visible to the runtime system. The Google Web Toolkit's support for extensible code generation is another example, as is the RapidMind system for creating parallel compute kernels from C++ code. Finally, there's the RPython system which creates a "metaprogramming startup phase" for Python programs, followed by a static compilation phase yielding 100x speedups. Interestingly, this whole goal contradicts Paul Graham's 2001-era view that "true macro systems aren't compatible with static type systems."

support diverse analyses -- The best two already-cited examples here are the JastADD grammars formalism and the BDDBDDB Datalog-based analysis specification. These are radically different but potentially very synergistic. I'd be fascinated to see whether there's some deeper commonality between them....

analytically composable -- The JastADD framework seems the best example of a declarative structure that supports automatic weaving of multiple analyses. For evidence to this effect, consider that the JastADD folks claim that the Polyglot team is reimplementing their framework in JastADD to avoid the difficulties of scheduling dozens of analysis passes.

I plan to start experimenting with some prototypes of an Eclipse plugin for an extensible language framework along these lines, likely starting with something much like OMeta and extending it with a JastADD-like rewritable grammar formalism. This will be open source all the way. I would enthusiastically welcome all pointers to similar projects, all interest in helping with such a framework, and all critical comments on all or part of this manifesto!

(Disclaimer: our family will also be moving out of our house in the next three months, so progress may well be slow :-)

GWT presentation tomorrow!

2007-12-03T21:33:00.000-08:00

I've been working on a truly monster blog post, nothing short of a manifesto for a growable programming language. It's about four pages long now and roughly 90% complete. All I have to do is Google up the two dozen reference links.

But I can't quite get to it tonight, because tomorrow is my presentation at the GWT conference and I've been tweaking my slides semi-compulsively.

So, hopefully I'll see several of you tomorrow at the conference, and stay tuned later this week for my Big Fat Language Rant! Your patience is very deeply appreciated.

Gaming, Turkey, and Burnout

2007-11-26T21:45:00.000-08:00

(Warning: relatively low technical content ahead!)

Rats, missed another blog-posting week here. A week ago I finally got my GWT conference presentation done. I was rather nervous about whether I was hitting the right technical level, so I mailed it to a few GWT team members, and Bruce Johnson (the team lead) wrote back and said, basically, "It's perfect." Thanks, Bruce! Eased my mind tremendously. The conference is coming up next week.

Then on Tuesday, Mass Effect shipped, and I was instantly lost in space. I've gone back and forth on whether to talk about gaming here, but this title pushed me over the edge. I've been a computer gamer ever since I've been a computer user -- my very first experience with a computer was playing Spacewar on a PLATO timesharing terminal at my friend's father's college. And gaming has become a true lifelong hobby. Mass Effect is a great example of why that is.

Programmers inherently love systems. A truly intrinsically motivated programmer will spend hours thinking about how something fits together, and more hours tinkering with it and seeing what happens. A great game also has a systemic internal structure that rewards tinkering and exploration. So it's natural that so many programmers are gamers.

Moreover, many programmers are thrilled by advances in technology. The more powerful our computers become, the more we can do with them. And computer games are definitely the most widely visible hardware-pushing applications. Just take a look at some of these screenshots. A $280 XBox 360 can now do real-time facial animation that looks a lot better than ANYTHING being done five years ago (real-time or pre-rendered). And it qualitatively changes the nature of the game, when your character and the zany aliens they're talking to both have facial emotions and lip-syncing that are so much closer to realistic that you can almost lose yourself in the illusion. I'm not claiming that Bioware's crossed the uncanny valley just yet, but they've definitely taken huge strides in that direction, and they've hooked me but good.

I expect to be a gamer for the rest of my life, since games just keep getting cooler and cooler as hardware gets more and more powerful and we learn more about what to do with it. It's a perfect hobby for a systems-oriented, game-addicted technophile.

So Mass Effect took over my after-the-family's-asleep life, and stole my blogging cycles last week. Thanksgiving was also pretty hectic -- we cooked an 18-pound turkey for our church get-together, which took me all day while my wife juggled our three-month-old and our (almost-)three-year-old. That left us pretty wrecked and we laid low the rest of the weekend.

Meanwhile, on the hacking front, I have continued to feel blocked by the whole Seam 2 broke my code issue. Actually, technically, it's that Seam 2 broke the G4JSF code. That code was originally written by the Ajax4JSF team, but they have abandoned it. So the question for me is, how motivated am I to fix it? (And, potentially, to continue fixing it as Seam, JSF, and GWT continue to evolve?)

I originally started on this whole Seam / GWT / JSF project because I had ambitions to create a peer-to-peer distributed blogging system. I made a lot of progress on that system (at least as far as creating a Seam-based model for representing version trees with Java persistence, a la Mercurial). Then I wanted to start on the UI. Which led me to GWT, and the realization that the existing G4JSF library didn't couple gracefully with GWT RPC. So I patched GWT, and then G4JSF, and that led me to presenting to the GWT team at JavaOne last year, which then got me the opportunity to speak at the GWT conference next week. All of that was quite unexpected and quite appreciated -- particularly the speaking opportunity!

BUT, going back to my original project, the peer-to-peer distributed object system lost its mojo somewhere over the last year. It led me down the GWT / Seam / JSF path, which was really interesting and connected me to the open source world like never before... but somehow the journey became the destination, and the original goal no longer feels as interesting. Frankly, I'm not feeling very enthusiastic about being the sole owner of the G4JSF code base, given the evident cost of keeping it current and given the lack of other support from the JSF community. Maybe having a second baby also cut my energy level.

In order to avoid burnout I need to work on the projects that are most interesting to me, which right now is looking like prototyping some extensible programming language ideas that have been burning a hole in my brain for the last two months.

So, I'm going to set aside the G4JSF work and I'm going to leave the Seam/GWT/JSF integration project in its current state. I am more than willing to work with anyone (at Red Hat or elsewhere) who wants to pick it up again and fix it up to work with Seam 2 (and JSF 2 when it comes along), but I can't drive it further on my own. Anyone who was using that integration library and who is interested in fixing it, feel free to email me (rjellinghaus at gmail dot com).

This blog will shift focus away from Seam/JSF and towards programming language research and the experiments I'm doing. Hopefully that'll still be interesting to my loyal readers -- I'll do my damnedest to make it so! Because I'll tell you one thing, it's pretty fascinating to me :-)

Android hits the fan

2007-11-13T17:14:00.000-08:00

Unless you've been buried under a boulder, you've heard about Android. It's nice to know what my secretive Google mobile JVM guru friend has been working on all this time :-)

The Android forum is awash in C / C++ developers ranting about how lame Android is because it doesn't support raw access to the hardware. It's too bad, really. I feel for them, and I agree: Android apps are going to be slow and clunky compared to native apps.

But Google's making a play to build a whole new kind of mobile ecosystem here. Google's betting on increasing mobile CPU power (certainly an excellent bet), and Google knows that if Android develops a personal-computer-like reputation for flakiness, it will fail and fail bigtime. I would argue that a big reason no mobile platform has really taken off yet (besides crazy licensing costs) is that native apps are simply flaky, and the more of them you run, the flakier your hardware gets. Since Android is trying to greatly increase the hardware diversity of Android devices, allowing raw native access combined with open developer access would rapidly drive the stability of the system to zero.

Native developers hate to hear this, because they spend their lives tuning for performance and chasing crash bugs. I'm sure many of them do write good solid apps. But I'm also sure that making native code crash-proof, especially across a wide spectrum of hardware, is very, very hard to do. And if you want to throw your platform open to anyone who wants to ship an app for it, you're guaranteed that many if not most of those people will lack the uber native skillz to achieve that kind of cross-platform stability.

So HOORAY GOOGLE! for making Android a fully managed platform! Note also that Microsoft sees the writing on the wall; they're working on a fully managed operating system, for crying out loud.

End rant. The most interesting thing I've yet learned about Android is that it is fundamentally trying to end-run around Sun's IP restrictions on Java ME. Stefano Mazzocchi breaks it down in exemplary fashion. Super cool! It's going to be really strange to see Sun and Google at each other's throats, but given how close the two companies are, and given how heavily Android leverages Java-the-language while totally subverting Java-the-runtime, AND given how anti-patent-war Sun is trying to be, I hope for some kind of peaceful reconciliation there. Microsoft, on the other hand, will go apeshit. Let the fireworks begin!

GWTJSF broken with Seam 2, sorry folks!

2007-11-07T22:08:00.000-08:00

So I've gotten past a number of the issues I blogged about previously, and I now have a Tomcat-only no-EJB3 version of the Seam blogging example. I've tried rolling the GWTJSF code from my original example back into it, and it looks like Seam 2 has thrown another wrench in the works.

As Chris Alfonso at JBoss warned me, Seam 2 installs the SeamPhaseListener by default. The Seam/GWTJSF integration as it previously existed needed its own phase listener, as explained in my article on the topic. This delegating-PhaseListener technique seems to be impossible in Seam 2. (Unless I'm missing something.)

With the GWT conference breathing down my neck, I may need to sideline this for a while until I get a fallback presentation together -- I was hoping to be able to demo GWT 1.5 (if it gets done in time!) with JSF 1.2 and Seam 2, but I can't count on that at this point, there are only four weeks to go and I don't have the hacking time I'd need. So it's Plan B time. I'll take a week or so and get the presentation together with the previous version of the code, and then I can pound on Seam 2 some more.

Also, it looks like the GWTJSF code has officially been left behind in the Ajax4JSF 1.1.1 code tree, which has been rolled into the RichFaces project -- except for GWTJSF, which is nowhere to be found in the RichFaces code tree. GWT can definitely be considered a competitor to RichFaces, so I guess I see why JBoss isn't supporting GWTJSF, but still it's a shame. It'd be great to see some more synergy there, but I'm not sure how to bring it about. (other than blog about it and rock the boat a little ;-)

Anyway, sorry to those who've been wanting to use GWTJSF with Seam 2 -- it's going to be a longish road. All help very much appreciated if anyone else has cycles to hack on this with me!!!

Friendship and fraternal aid

2007-11-05T20:19:00.000-08:00

Last week I griped about some hassles I was having with Seam 2, Java 6, Tomcat, and JBoss Embedded. I grumpily grouched about the grim gloom of an open source world where things break and people don't get along very well, and how non-fun it is.

And hey presto, what should happen but two Red Hatters read my kvetching and chimed in with some downright helpfulness. First, Jason Greene mentioned this workaround for the bizarre Java 6 ClassNotFoundException I mentioned. Seems there is a magic JVM flag you can provide to revert to the Java 5 classloading behavior if it causes you too much trouble. That's good to know, and I appreciated the clue.

Second, Chris Alfonso -- who's been asking me when I'm going to get around to fixing my GWT/JSF/Seam demo to work with Seam 2 -- said that he's got a Maven 2 version of the GWTJSF demo building as an EAR that runs under JBoss with EJB3. Which is cool, because I now have a plain old Hibernate version of the Seam 2 blogging demo that deploys under vanilla Tomcat, so it's nice to have both flavors. (Chris, can you send me your version? I'd like to poke at it some -- I won't post it without your say-so.)

So that's the great thing about the open source community -- it is a community, and people offer each other helping hands. Thanks for brightening my week, guys! You put the fun back in :-)

GWT RPC presentation, by popular demand

2007-11-05T20:13:00.000-08:00

A couple of months ago, I was honored to learn that I'll be doing a presentation at the upcoming Pearson GWT conference in San Francisco in early December. I'm quite grateful for this opportunity.

What's more, I just learned that they're giving me a discount code! Head to the site and enter code GW-JELL for $100 off the registration fee. Woo!

Originally I contacted Pearson with the suggestion that I might do a GWT/JSF talk, but there wasn't enough room on the agenda for that. Instead they'd planned to have Miguel Mendez (the author of the GWT RPC code) do a presentation about RPC in GWT. It turns out that he can't make it. So I'll be presenting on it instead. It'll be impossible for me to do as good a job as Miguel would do, but I'll give it my best shot. (Thankfully it's the area of GWT that I understand better than any other!)

So the next question is, what exactly should I discuss? I'd like to throw this open to the community to some extent. If you were going to a presentation on GWT's RPC, what would you want to learn about?

I'll start by listing the things I personally want to know more about (from most to least):

how to use GWT RPC with Hibernate or other Java persistence frameworks (particularly interaction with lazy loading)
best practices for scoping the object graphs you send in RPC (to manage problems of updating server state in a large object graph)
Java 5 support in GWT RPC: how generics are handled in GWT 1.5
organizing your RPC code for best readability and easy sequencing
integrating with JSF, Spring, and other server frameworks

Obviously this is way too much already for a mere hour-long presentation, but that's my problem, not yours :-)

I'd appreciate it if people could post their favorite topics. If you can list them in order from most urgently interesting to least, that would help me.

I'll be working with Miguel to refine the presentation over the next couple of months (thanks, Miguel!). There'll also be some blog posts coming out of it. And I'll see you in San Francisco in December!

Finger-pointing and frustration

2007-11-01T22:37:00.000-07:00

One of the tough things about open source is that the world never stands still. Actually, it's not just open source, it's software in general, but open source exacerbates it. See, one of the main motivations for open source developers is fun and the enjoyment of sharing something cool you did. So you'd like to be able to do something cool and then have it stay cool.

But the problem is, once you get something cool working, it's almost guaranteed that it's going to stop working soon. Why? Because everyone else is doing other cool things. Including all the developers whose projects yours depends on. So the odds approach 100% that before long your cool thing is going to break with the latest version of FooBarLib. And broken things are no longer cool.

And fixing your cool thing, that broke for no fault of your own and for reasons you don't agree with, is the absolute opposite of fun.

Even large developers are vulnerable to this. Right now I'm banging my head against trying to get my Seam + GWT example working with the latest 2.0 release of Seam. But Seam made a number of changes that are frustrating me rather deeply right now. For one thing, they changed the packaging for their embeddable EJB support such that you have to install the JBoss embedded EJB container directly onto your Tomcat. No more delivering a nice simple WAR file that uses Seam and EJB3, now it's a multi-step process that leaves your Tomcat fairly JBossified.

The nominal rationale for doing this is that it lets the EJB3 services be shared by all the apps inside that Tomcat instance. So you might think, great, now my Seam+EJB3 WAR file is 6MB instead of 20MB. (Which is indeed a problem with the demo version on my page -- it's stinkin' HUGE.) But, BUT, it turns out you can't actually run multiple Seam apps under the Embedded EJB3 container!

Why not? Well, because Bill Burke and Gavin King, both of whom work at JBoss and both of whom are fairly bullheaded, can't agree on whose problem it is that multiple Seam apps collide in the Embedded EJB3 component registry. Not only that, but the Embedded EJB container's development has stalled. So, Tomcat is a seriously second-class citizen as far as Seam is concerned now. Of course from a JBoss perspective this is arguably good, because JBoss doesn't get support revenue from Tomcat installations. For me, though, it sucks, because I don't want my Seam / GWT example to require JBoss.

And the icing on the cake is that the Embedded JBoss container doesn't run under Java 6. I like to run on the latest Java. It's just a funny preference I have, I don't know why. But JBoss does classloader tricks that Sun apparently considers invalid loopholes, which Sun closed in Java 6. This results in charming errors like:

ERROR 01-11 21:56:07,921 (AbstractController.java:incrementState:456) -Error installing to Instantiated: name=DeploymentFilter state=Described java.lang.IllegalStateException: Class not found: [Ljava.lang.String;

And JBoss and Sun are finger-pointing about who broke who. So Seam isn't at all guaranteed to run under Java 6 in any way, and JBoss and the Seam team consider it Sun's problem, not theirs.

So what am I going to do? I've got a conference presentation coming up and I wanted to use this demo with the latest Seam and latest GWT. But it's starting to look like I'm going to have to sink way too much time into mucking about with Seam for reasons I'd rather not have anything to do with. I'll probably follow the path of least resistance, which is just to roll back to Java 5 and grin and bear it. It's definitely demotivating, though. Definitely. Demotivating.