[Edu-sig] Design patterns

[Kirby Urner]

> In his mind, (and I think in yours as well) computer languages are more
> like mathematical notation than a form of technology.  And as such, 
> evolution is slower - not at the pace of the changes in the underlying 
> technology.

However I'm sometimes in the mood to not draw this line between notation and
technology, looking at language as technology, as tools.  And yes, different
technologies evolve at different rates.  Bucky kept saying the lead time
from prototype to mainstream was a key variable, and in electronics might be
about 3 years, whereas in housing it might be at least 10 if not more.  So
he figured housing prototypes in the 1940s might pan out in the 1960s, and
to some extent they did (and didn't).  Plus he kept making prototypes, as
did his students (J. Baldwin and Joe Clinton come to mind).

> 
> Though certainly not uninfluenced by those developments.  The most
> important technological development he seems to point to is the 
> increasing raw power and speed of processors, which allow languages 
> to design away from a preoccupation with performance issues.

However it's also important that, given this opportunity for faster physical
cycling, per the silicon chip computer, software engineers were able to rise
to the occasion and give us VHLLs like Python, i.e. were able to take
advantage of those extra fast cycles and yet still make the language
parsable and machine friendly enough for a CPU (which is ultimately nothing
more than a fast arithmetical/logical unit, no matter how fast it goes).

> He thinks - though without great confidence in his intuition here - that
> Java is an example of a language headed down a dead-end evolutionary path.
> Than so must too be C#.
> 

A language has a half life.  Big expensive systems that aren't broken don't
need to be replaced, only tinkered with, so you have this long aftermarket
for language skills, even when the language itself is "officially" dead.
FORTRAN is a good example.  At the OSCON/Stonehenge party this year, Jeff
Zucker (a Perl saint) and I met up with a FORTRAN guy who to this day works
on optimizing FORTRAN compilers, to run more effectively against today's
chips.  Because lots of big fancy computer models still perform useful
service and make heavy use of FORTRAN.

> Despite having some understanding that it must be annoying to hear
> high-fallutin theory from someone at my level in this domain, I persist.
> 
> And it seems to me that the evolutionary successful language will include
> in its approach clear and concise constraints on its ambitions.
> 

So far you haven't said anything I disagree with.  Just adding emphasis:
software had to meet the integrated chip designers at least half way, and
computer languages aim for a layer in a long term archeology that could
include working bits for centuries, if not millennia -- just as centuries
old math notation still expresses algorithms in useful form today (your
original point).

> If I am understanding "properties" mostly correctly, and in fact their
> reason for being is to allow for a fundamental midstream redesign of a
> program without alteration of that program's API, I am thinking something
> to the effect that it is only possible to do the impossible in half-
> measures, and half-measures are only half-measures and who wants to work 
> in an environment of half-measures.

In Java, you should probably work out ahead of time if you want to use
private variables cloaked in protective getters/setters, so that you might
continue fiddling with the guts indefinitely, even as your users experience
and enjoy a simple attributes-based API that hardly ever changes (like the
front panel on a TV:  channel and volume, yet no tubes inside (not even a
picture tube these days)).

In Python, you have more liberty to wrap what used to be a simple attribute
in a property, and so maybe don't have to hard code so many design decisions
up front.  Java coders may be more likely to practice "defensive
programming" than Python coders and make everything private and
method-protected up front.  This philosophy is manifest throughout the
language (with its private, protected, and public attributes -- whereas in
C++ you also have friends [1]).  Some say Python is a "consenting adults"
language, with permissions by convention vs. enforced by a nanny compiler
(I'm not saying the latter can't be a nice experience also).

> I don't think mathematical notation, for example, includes the concept of
> the half-measure.
> 
> Whatever.
> 
> Art

For me, non-executing math notation needn't be enshrined as the ideal.  So
much about math involves insulating one's self from having to deal with real
world complexity (only to discover it later, one hopes in some manageable
form).  Computer languages ventured off into the wild west and took on
whatever features we needed to do real time accommodation of client wishes.
So I'm not nostalgic for the good old days, before we had computer science.
I don't pine for a "math rules" world, wherein more machine oriented
languages are second class and pitiable.  There's nothing pitiable about a
Perl, Ruby or Python.  They're just tools that do what they're supposed to.
They're not here to whine about not being mere "math notations" as if that
would be an improvement.

Kirby

[1] http://www.faqts.com/knowledge_base/view.phtml/aid/24762/fid/163