Diversity - existence, value, and pursuit.

[Mitchell N Charity <address@hidden>]

I've just caught up with ll1-discuss (job search avoidance),
so three related thoughts...

"In other computer news, at the MumblePLAN '07 conference in Boston,
 proponents of the DanceIt(tm) and ScribbleIt(tm) programming languages
 came to fisticuffs.  Some of the incensed, battered and bewildered
 participants were heard mumbling "DanceIt is where it's at!  Its
 spacial-kinetic notation is so easy, it lays out problems so naturally
 - anyone who hasn't moved to it has their head buried in the sand".
 Others cried "ScribbleIt solves the programming puzzle once and for
 all.  Its logical-symbolic notation is so straightforward, it allows
 programs to be reasoned about so cleanly - anyone who doesn't like it
 is just lazy or fidgety."

Perhaps we could cut back on our use of universal quantifiers over users?

Undisputed is (1) s-exps are a powerful representation, (2) non s-exp
representations can recapture some of that power, (3) but not all, (4)
but they can be more concise, (5) the true value of 1 and 4 are often
not fully appreciated, and (6) both have learning curves and human costs.

Often overlooked are education research's big 4 results of (1) people
have deeply varied internal representations and cognitive strategies,
(2) thus the effectiveness of particular information presentation
strategies varies greatly among users, with global optimums generally
non-existent, (3) teachers pervasively overrate the success of their
favorite strategies with their students, and (4) ignoring observations
1 thru 3 is very popular, and robustly so.

I ceased having to wade through the endless `GUI direct manipulation vs
command line programmatic interface' UI flame wars after folks realized
both that there were classes of problems better suited to each, and that
there were classes of people better suited to each.  The war was more one
of poorly communicating design communities, than of an actual engineering
incompatibility.  Both approaches were needed, with the optimum tradeoff
varying over people and tasks.

'Nuff said.

(Oops, or not.  This thrust, about mis-extrapolating from self-selected
 groups to the general population, has a corollary, that by targeting a
 language design to a small homogeneous group, one can perhaps engineer a
 better fit, and higher productivity.  Thus I was delighted to see folks
 pushing on the concept of "a language just for me, a wizzy programmer".
 As this gets easier to do with time, it will be fun to see just how high
 one can push programmer productivity in the best case.  But that's a
 topic for another post.)

Relatedly, (to multiple approaches and tradeoffs) regards

  [Bruce Lewis]

       -b + sqrt(b*b - 4*a*c)
       ----------------------
	       2*a

   ...and it would group in the expected way.  Now *there's* an infix
   notation one could get excited about!

I saw a related educational language go by, a decade ago, on the Mac.
Using their language-dedicated code editor, you simply found typeset
equations in the midst of your code.  Which could be edited with a
normal mac equation editor gui.  I don't recall the system's name.

In counterpoint, Gerry Sussman's "Structure and Interpretation of
Classical Mechanics" system wizzily uses s-exps as the core
representation for differential equations.  The development environment
derives latex and typesets math for auxiliary display.  But the twist
is that the standard mathematical notation in the area is painfully
ambiguous, so the inverse transform isn't possible, and a functional
notation is clearly necessary.
[ http://www-swiss.ai.mit.edu/~gjs/6946/index.html ]

Hmm, so would peoples' objections to
  (> (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a)) 0)
go away, if it could optionally appear as
       -b + sqrt(b*b - 4*a*c)
       ----------------------
	       2*a
in their favorite editor?

My meta hypothesis is that whenever one can rely on a language's
development environments to provide presentation transformation services,
a (large?) number of language design issues, those which stem from a need
for a single inflexible ascii representation, become rather less important.
Regrettably, there doesn't seem to be much movement towards obtaining
this property outside of a few narrow-domain, narrow-target systems.
Though the general migration towards unicode and embedded object
documents should make it easier with time.

(Oops, another thing I left out - mumble Microsoft's "Intentional
 Programming" project mumble - what the editor shows is but a transient
 representation of a backend database containg program semantics.)

(Oh, I suppose I should have a punchline...  LLs perhaps provide a
 nice opportunity to push development architecture issues like tight
 IDE integration, and ephemeral representations).

Good night,
Mitchell Charity