RE: Continuations

["Anton van Straaten" <address@hidden>]

Dan Sugalski wrote:
> At 5:13 PM -0400 8/9/03, Anton van Straaten wrote:
> >I think it can reasonably be argued that the "average"
> >programmer does, in fact, have little reason to want
> >write an interpreter.  But the same isn't true for an
> >"above average" programmer.  I'd argue that too few
> >above-average programmers write interpreters, because
> >of the above factors, but also because of this one:
>
> I'll add a #7:
>
> Most programmers (above average or not) don't write interpreters
> because they neither need nor want to write them. Occasionally it's
> useful to embed some sort of scripting engine into a large app (been
> there, done that, quite useful) but for most things the average, or
> even above average, programmer does there's just no need to write an
> interpreter.

I consider this point covered by my point #1: that it's not that they don't
need or want to write them, it's that they don't know why they should want
to write them.

My underlying premise was that I think many above-average programmers could
improve their understanding and skills by writing interpreters, and learning
about some of the things which go along with that.  IOW, they should want to
write them.

I don't think it's for nothing that books like SICP cover the writing of
interpreters.  I also don't think it's rocket science, especially not in
highly dynamic languages with eval and related capabilities.  Part of what I
was saying is that I think it's a pity there don't seem to be many more
accessible resources on the topic, geared towards doing it in commonly used
languages.

There's also the whole issue of DSLs, which can be a powerful
problem-solving tool.  This goes beyond "embedding some sort of scripting
engine into a large app".  Depending on the application, the large app might
be a much smaller app if it's implemented using a DSL.  There was a nice DSL
example given back in February:
http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02421.html

That example had an unhappy ending because of issues over a "proprietary
language" and so on.  But if language development was more common and
well-understood, it would be a more acceptable solution.  There's a chicken
and egg problem there, of course, compounded by the lack of knowledge and
lack of tool support.

But even if we ignore DSLs, a specific way in which writing interpreters can
improve skills is by helping to think about problems from a language
perspective.  At the risk of using another overly broad definition, a lot of
mainstream programming is about building "languages", often in the form of
domain-specific object models, which are then manipulated using a
general-purpose programming language.

A well-designed object model may in fact end up with objects that can be
used very much like an expression language, so you can write code that looks
like an expression in some higher-level DSL, that's been converted into an
object-based syntax.  If you design objects like that, then all that may be
needed for a simple DSL is a syntax translation, which can be easy to do
with a parser library.  But even if you never take this extra step, a design
that works this way can be a big improvement over the alternatives.

More often than not, solutions are not explicitly conceptualized like this,
in language terms, so you end up with something much less consistent and
more primitive - for example, operations being performed at a much more
granular level, in big nested loops.  I've seen plenty of cases where this
kind of code is just churned out, page after page, with little awareness
that the whole thing could be done at a much higher level, with much less
code, and with a big improvement in comprehensibility and maintainability.
Thinking about things from a language perspective can improve object designs
in cases like this.

BTW, there is a connection here to config files and other kinds of
data-driven applications.  The more sophisticated examples of these qualify
as real DSLs - they abstract some of the program's behavior to a higher
level, and they eliminate code that would otherwise have to be hand-written.
So the point about config file "interpreters" is really just a question of
degree, i.e. how sophisticated the config file "language" is.  (Sendmail's
notoriously Turing-complete config files being a canonical example.)

I'll summarize my point like this: many kinds of programs involve
hand-writing the code that could otherwise be generated by a DSL.  If that's
realized, then designs can benefit from it, whether or not an explicit
language in the sense of an interpreter or compiler is ever implemented.  So
learning about language development is a good idea, and writing interpreters
is a good way to do that.

Anton