General talk about software patterns

[Pascal Costanza <costanza AT web.de>]

On 16 Aug 2004, at 6:28, Mike Beedle wrote:

> Pascal Costanza writes:
> > Hm, at the moment I am skeptical that this term can turn out
> > useful. As far as I understand the term at the moment, not only
> > Lisp is homoiconic, but also assembly language (or better: machine
> > language) would be. In machine language, both data and programs
> > are just (sequences of) machine words.
>
> Pascal:
>
> I think the rule of thumb is that programs need to be indistinguishable
> from data, and that this "data" could be modified and then executed.
> So to qualify, machine language would have to have the equivalent of
> "eval" in Lisp... and create dynamically code segments.

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.

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.

The downsides of these two ways to achieve "homoiconicity" is that in 
machine language, one can too easily shoot oneself in the foot - and 
that's why higher-level programming languages have been invented to 
save you from the need to manually code the common idioms. (Especially 
note that modern runtime systems - like the HotSpot JVM - heavily rely 
on self-modifying code.) With load-time transformation (and general 
program transformation) approaches for Java, and other languages from 
the C heritage, the downside is that it takes far too much machinery - 
big libraries, big frameworks - to reintroduce homoiconicity again on a 
too high level.

The accomplishment of languages like Smalltalk, Lisp and Scheme is that 
they have managed to find a sweet spot in between: It's straightforward 
and relatively easy in those languages to make use of reflective 
features, but it's still structured enough to not introduce too many 
accidental sources of bugs. (The fashionable scripting languages of 
today use strings for reflective features - eval and the likes - which 
I find are still too low-level.)

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 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 aproaches, 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.

> Pascal Costanza writes:
> > The only thing I can really tell for sure is that Common Lisp is the
> > best language out there. ;)
>
> Here, I strongly agree :-)

:) JMangler actually was my first Lisp program, without me being aware 
of it. It feels like a strange encounter when I take a look again at 
the code I have written back then, and I can actually see how I 
subconsciously emulated the backquotes and splice operators for 
s-expressions that I am now used to. Very strange indeed...

> Great quote ...  Definitely something to think about.

We should stop - we start to sound like religious zealots again. ;)



Pascal

--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."