Development Environments Matter

["Peter J. Wasilko" <address@hidden>]

Hi Chris,

> Could languages be more "lightweight" if presentation and editing were 
> more robust?

    I would definitely say YES. These comments perfectly capture the
direction of my thinking in terms of a support environment for Clear.
Indeed, such logic lies at the core of my decision to use verbose
natural language as the canonical representation for most language
elements rather than a terse notation.

    A lot of the look and feel of today's mainstream languages arises
from notational decisions aimed at reducing the amount of text
programmers need to type, but as a result each character becomes more
significant and often less likely to trigger a timely error message if
miss keyed. So we get short programs but at the price of the programmer
having to expend a lot of mental cycles to code what he or she is
thinking, to explicitly comment the intended meaning of the code lest it
become necessary to reconstruct this understanding at a later point in
the presence of coding errors (ie. if all that is written is terse
notation that is *wrong*, the original intention isn't captured anywhere
in the text), and to parse the dense notation of code written by others
to try and infer what they were thinking.

    All in all, this isn't much of a win to save a few bytes of file
space in the presence of multi-hundred meg main memories and gigahertz+
chips that could automate the typing of verbose identifiers whose
meaning wouldn't entail working through an extra level of mental
indirection.

    Of course such mental overhead isn't a *conscious* burden on skilled
programmers who just see meaning behind a screen of even the most
twisted source code, particularly if newer languages continue to mirror
the notation of older onces whose quirks have been safely internalized
for years.

    For those approaching such languages for the first time, it makes
the language very heavyweight.

    But if you use the language "a function" instead of a lambda glyph,
your End User - be he or she a programmer from another language
community or just a motivated accounting geek - can get past the surface
and start to build a good mental model of the code without an O'Reilly
Pocket Reference in hand. 

    Yes, the user will need to learn the important CS concepts inherent
in the code, but surely that is enough of a burden without having to
throw dense notation into the mix to save a few keystrokes that an
editor macro could eliminate in any case. Personally, if a string of
punctuation glyphs and concatenated consonants means "a pointer to an
array of handles to pixel maps" I would prefer to read and write that
verbose form and let the environment render it for you as pseudo-C if
that is what you would rather read.

    The key point is to think of our languages as just one part of a
system that also encompasses our development tools and the people using
them!

Warmest Regards,

Peter


_________________________________________________________________

Peter J. Wasilko, Esq.
     J.D., LL.M.               

Executive Director, The Institute for End User Computing, Inc.

Visit us on the web at: http://www.ieuc.org

_________________________________________________________________

It's time to abandon brittle architectures with poorly factored
interfaces, gratuitous complexity, and kludged designs dominated
by sacrifices on the altar of backwards compatibility.

Such artifacts are vulnerable to cyber-attack, weigh down the
economy costing trillions of dollars in lost productivity, and
suffer from an impoverished conceptual model that lacks the
integration and elegance needed to empower end users to
get the most from advanced applications in the future.

_________________________________________________________________
The Institute for End User Computing --- Pursuing Secure, Simple, 
   Supple, & Sophisticated Systems to Unlock Our Human Potential
_________________________________________________________________

* The Institute is incorporated under New York State's
   Not-For-Profit Corporation Law