Skip to Content.
Sympa Menu

patterns-discussion - Re: [patterns-discussion] Homoiconicity Pattern Language?

patterns-discussion AT lists.cs.illinois.edu

Subject: General talk about software patterns

List archive

Re: [patterns-discussion] Homoiconicity Pattern Language?


Chronological Thread 
  • From: Pascal Costanza <costanza AT web.de>
  • To: "'Patterns-Discussion'" <patterns-discussion AT cs.uiuc.edu>
  • Cc: Mike Beedle <beedlem AT e-architects.com>
  • Subject: Re: [patterns-discussion] Homoiconicity Pattern Language?
  • Date: Sun, 15 Aug 2004 12:42:38 +0200
  • List-archive: <http://mail.cs.uiuc.edu/pipermail/patterns-discussion>
  • List-id: General talk about software patterns <patterns-discussion.cs.uiuc.edu>


On 15 Aug 2004, at 11:46, Mike Beedle wrote:

However, it has been in the literature for longer than
I expected. As Ralph pointed out -- Kay was using the term
in 1968, which leads me to believe it may have been in use
in computer languages circles for at least a few years earlier.

Maybe someone could ask him.

The term does make sense as far as describing a fundamental
language feature:

homoiconic ~ same form or representation (of data and programs)
(my translation from etymologies)

Sadly, although the concept has been around for a while,
the majority of languages do not have this feature,

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.

The reason why I am skeptical is this: There are lots of terms floating around in computer science that seem to want to indicate a certain quality that we should want as programmers. Like typed, strongly typed, dynamically typed, compiled, object-oriented, class-based, functional, higher order, platform-independent, garbage collected, well-founded, minimal, standardized, and so on, and so on. However, none of these terms really reveal whether a language is actually good or not. For each of those categories, we can most certainly give examples of extremely sucky languages, so they are not sufficient conditions. Furthermore, for each of those categories we can probably find pairs of programming languages that don't share the same characteristics, so they aren't even necessary conditions. Effectively this means that they don't tell you anything interesting. The quality of a programming language must be a quality without a name then, right?

So currently, I have the preliminary feeling that the term "homoiconicity" probably also turns out as one that really doesn't tell us whether a language is good or not. I am rather convinced by now that choosing a programming language is a very personal and subjective thing. Similar to choosing a musical instrument, for example. (It's important to note that this doesn't make it an unobjective choice! It's pretty common that people with different personal preferences can come together and produce something valuable for other people, not only for oneself - like in a band or an orchestra, for example. Why should that be different in our profession?)

The only thing I can really tell for sure is that Common Lisp is the best language out there. ;)

- Mike

"It is time to unmask the computing community as the
Secret Society for the Creation and Preservation of
Artificial Complexity (formal sense)."

Yes, exactly. We do this because it gives us power over others. Here is a favorite quote of mine:

"Sadly, society and parents insidiously put out messages from childhood on that others know what's best. Many people are deeply conditioned to expect and hope some outside agency, power or person will solve their problems. Letting go of expectations or even wanting this is difficult, partially because what one is left with is oneself and all of one's limitations."
Joel Kramer, Diana Alstad, The Guru Papers - Masks of Authoritarian Power

That book tells you quite a few things about programming languages.


Pascal





Archive powered by MHonArc 2.6.16.

Top of Page