There are times when static type-safety feels a lot like shopping with
an obsessive-compulsive friend.  Whenever you consider buying
something, he forces you to scribble it onto a list; whenever you
change your mind, you have to cross it off.  If you complain, he
starts to laboriously tell you the benefits of keeping the list: you
can easily check your shopping cart against it, it makes you seriously
consider each item you buy -- and, once you've discovered your
shopping patterns, you might be able to convince the storeowner to
rearrange the aisles for your convenience!  In the meantime, every few
seconds you're forced to edit the list when another item catches your
eye.

For a programmer, paying that sort of careful attention to detail has
many advantages, so it's almost always worthwhile.  Compilers and
other static analysis tools can catch thousands of mistakes that would
otherwise wreak unpredictable havoc, but they usually require
programmer input, like variable declarations and type annotations.
Most programs benefit from these abilities, particularly since they
often also enable the compiler to make certain powerful optimizations.
Even better, when code is stable, these features are easy to take
advantage of; it's usually just a matter of writing down what the
programmer already knows to be true.  Moreover, programmers often have
a good conception of how their programs will be used, so they can
carefully craft them from the beginning to exploit the expressiveness
of the language.

The trouble is that programs are rarely made entirely out of solid,
carefully-written code.  New code can be very volatile, written for
rapid prototyping or against shifting requirements.  Exploratory
programming is poorly served by having to conform to a disciplined
coding practice: the structure of the code is too unstable to be
usefully depended on, and, as a supplemental system, it usually
doesn't need to be efficient.  Most programmers would choose to use a
more flexible language in these situations if they could, but that's a
practical impossibility when the cost of integrating multiple
languages into a single program is very high (as is normal).

I believe that that particular tension can be eased substantially
using some already-established techniques -- namely, a disciplined
combination of dynamic typing and type inference -- but I also believe
that it's merely a part of a much larger deficiency.

A great deal of PL research has gone into the pursuit of greater and
greater efficiency and correctness.  This work is commendable; few
would wish it away in favor of a return to wilder, slower, and buggier
days.  However, I fear that something is lost in this: that
programmers are often overwhelmed by their languages, and that these
advanced abilities are often made without enough consideration for
usability.  Languages like Standard ML are hard to match in the
expressiveness of their module and typing systems -- and yet
beginning students are continually turned off by arbitrary fits of
syntax and unhelpful type-checkers.

I'm excited about the possibility of working on these problems with
Northeastern's Programming Research Laboratory.  More than many
departments, Northeastern has shown a consistent drive to not simply
advance the start of the art in computer science, but to do so in a
way accessible to students and unspecialized professional programmers.
Furthermore, the department's experience with novel programming
technologies like aspects and environmental acquisition leave it in a
strong position to lead research in my areas of interest.  I would
like to investigate using these techniques to lower the performance
cost of agile development, as well as to simplify the interactions
between tightly- and loosely-written components.

My interests are in helping programmers to write better programs more
efficiently and more effectively.  I've been doing that, in a small
way, since I first wrote libraries for a specialty text-adventure
language in high school.  I've done a great deal at Viz to improve the
company's product; I've written architectures, and I've written
applications against them.  Many of my proudest moments, however, have
been improvements to the company's SDK, letting other people do their
work more easily and more expressively.  That's the work I love to do,
and I hope to continue doing it at Northeastern.