General talk about software patterns

["Mike Beedle" <beedlem AT e-architects.com>]

Pascal Costanza wrote:
> Sure. In machine language you can have one part of the code 
> that writes a sequence of machine words to some location, and 
> then directly jump there. In the first phase we are dealing 
> with data, and in the second  phase we treat them as a program.

Pascal:

I bet there are some interesting patterns lurking for doing that.

Pascal Costanza wrote:
> I have also been involved in a load-time transformation tool for Java 
> called JMangler (and there exist quite a few others) that treats 
> bytecode as data at loat-time, and then feeds that bytecode into the 
> JVM to execute it. The Java source code doesn't look like 
> bytecode, but from a bytecode perspective, Java source code 
> is just a collection of fancy macros. Within the bytecode, 
> one can easily regard bytecode both as programs and as data.

Interesting.  I have not played with that side of Java so far.

Sounds like a latent JSR can emerge to make Java "homoiconic".


> What I am trying to get across is that it's not so much important 
> whether a language has a certain feature - that's trivial, 
> because due to Turing equivalence every language has all 
> features by definition - but that it is much more important 
> how convenient a feature is to use. (I think "convenience" 
> is a good term here, because it implies both 
> "not too strong" and "not too weak".)


This makes a lot of "Alexanderian" sense... As Abelson and Sussman
once wrote:

"Programs must be written for people to read, and only 
incidentally for machines to execute."

  - Abelson & Sussman, SICP, preface to the first edition


Pascal Costanza wrote:
> Mike Beedle wrote:
> > This is the very quality that enables:
> >
> >     genetic algorithms
> >     true mobile agents
> >     most of the artificial life research
> >     dynamic-rule systems
> >     true behavior-learning and behavior-exploring systems
> >     spontaneous model creation
> >     true interactive programming systems (ala Kay)
> >     etc.
> >
> > Imo, it is a somewhat special quality.  But yes, it depends on what 
> > you want to do and what you consider "cool".
> 
> Totally agreed. I would even go as far as stating that the various 
> aspect-oriented approaches, application servers, refactoring 
> tools, code  inspection plugins for IDEs, etc. pp., are clear 
> indications that people _actually_ want reflective, "homoiconic" 
> languages. They are just not aware of this fact. Hopefully, since 
> the speed fetishism of our C past has started to decline, 
> there will be a new wave of more dynamic and flexible approaches. 
> I am convinced that the latter will turn out as much more 
> important in the long run.

Absolutely...  I think you just you gave very good examples 
of how we express our desire to get closer to "softer-software" with a
"more interactive, more humane, more flexible, easier, smarter, 
shall we say more Alexanderian" way to program.

But it seems odd we don't write or talk about what is going to get
us there.  To me, starting with a "homoiconic" language could be
a good start in terms of having the basic property to allow 
that kind of programming/environment later.

Thanks for the great insights on the usability aspects of
"homoiconic" systems as they apply to programming today -- that
is the crux of the feature, imo.


Pascal Costanza wrote:
> We should stop - we start to sound like religious zealots again. ;)

Yes, I guess it is somewhat obvious we do have a slight slant 
towards that "list thing" ;-)

 ---

A few years ago, Martine Devos, myself and a few others wrote a paper
on Scrum that told the story about how to write "softer software"
but it was a more of a cultural/people and/or method/process thing.

Now, I realize the complete picture is to include cultural/method/people
things -- Agility is you wish, coupled with a highly interactive
flexible programming system rooted on the "homoiconic" feature,

- Mike