choosing a language for your audience or macros vs syntax?

[Shriram Krishnamurthi <address@hidden>]

Aside: Continuations have a somewhat fearsome implementation
reputation, perhaps unfairly: it's a function of the layout of your
run-time system.  Adding continuations to the SML/NJ run-time took the
stereotypical "48 hours" -- or maybe even 48 minutes.  (The parser was
more work, and of course the type system took years to fix.)  The
continuation was on the heap, its deallocation was handled by the GC,
so reify the continuation reference and you're good to go.  (This same
insight was, over a decade later, exploited by Stackless Python, and
even earlier than SML by the many authors who wrote papers and theses
on implementation models for Scheme in the 80s.)

All this is complicated quite a bit by foreign-function interfaces,
the udesirability of copying C's stack, etc -- or by the need to run
efficiently on VMs for languages with pre-1965 models of control.

That said, macro systems are not much harder to implement.

Ken Anderson notes that the defmacro-style macro system in JScheme is
just about 40 lines.

What is difficult to understand is why JScheme doesn't go further.  A
pattern-matching, hygienic macro system like SYNTAX-RULES is *also*
just about a page of code (maybe a European page); furthermore,
implementations abound on the Web and in other implementations.  It
would have taken a day to port any of these into JScheme -- probably
much less, given the fearsome hackers who implemented JScheme!  And it
could have shown macro users how much more macros can do.

> I suspect macros would be a lot of work because of the syntax, but i
> suspect that culturally, macros were not important, for lack of
> experience.  After all, Ruby makes a lot of things easier to
> program, so maybe that's enough.

Paul Graham's Blub paradox
  (http://www.paulgraham.com/lib/paulgraham/sec.txt):

  Programmers get very attached to their favorite languages, and I
  don't want to hurt anyone's feelings, so to explain this point I'm
  going to use a hypothetical language called Blub.  Blub falls right
  in the middle of the abtractness continuum.  It is not the most
  powerful language, but it is more powerful than Cobol or machine
  language.

  And in fact, our hypothetical Blub programmer wouldn't use either of
  them.  Of course he wouldn't program in machine language.  That's
  what compilers are for.  And as for Cobol, he doesn't know how
  anyone can get anything done with it.  It doesn't even have x (Blub
  feature of your choice).

  As long as our hypothetical Blub programmer is looking down the
  power continuum, he knows he's looking down.  Languages less
  powerful than Blub are obviously less powerful, because they're
  missing some feature he's used to.  But when our hypothetical Blub
  programmer looks in the other direction, up the power continuum, he
  doesn't realize he's looking up.  What he sees are merely weird
  languages.  He probably considers them about equivalent in power to
  Blub, but with all this other hairy stuff thrown in as well.  Blub
  is good enough for him, because he thinks in Blub.

  When we switch to the point of view of a programmer using any of the
  languages higher up the power continuum, however, we find that he in
  turn looks down upon Blub.  How can you get anything done in Blub? 
  It doesn't even have y.

  By induction, the only programmers in a position to see all the
  differences in power between the various languages are those who
  understand the most powerful one.  (This is probably what Eric
  Raymond meant about Lisp making you a better programmer.) You can't
  trust the opinions of the others, because of the Blub paradox:
  they're satisfied with whatever language they happen to use, because
  it dictates the way they think about programs.

Shriram