From: Samantha Atkins (samantha@objectent.com)
Date: Wed Mar 17 2004 - 00:18:16 MST
On Mar 16, 2004, at 5:55 PM, Mark Waser wrote:
> Ah good. I think we're getting somewhere . . . .
>
>> Write me a function that returns a function in XML alone (no external
>> code allowed). For that matter, write me a function that does any
>> computation at all in XML alone. This is why I find this discussion
>> so amazingly strange.
>
> Clearly this can't be done. XML is a data-definition language. I'm
> not
> making XML a programming language. I'm making a programming language
> which
> is XML-compliant. My point is that if you make a language
> XML-compliant
> there is a large set of standards, tools, thought, infrastructure, and
> excitement that you could benefit from.
hmmm. I still don't see what this adds to programming languages per
se. For that matter, I am not sure if you could define a non
XML-compliant language, i.e., one that you could not represent at the
syntax and documentation levels (and some meta of these) in XML. I
believe you made this point earlier. I don't see where the *data*
standards, tools, thoughts, infrastructure and so on for XML greatly
benefit language which, as you admit, have quite significant non-data
characteristics.
>
>> Lisp is as efficient in its compiled form as C with a bit of care.
>> It
>> is quite scalable. To argue that it is not would be effectively to
>> argue that no languages are scalable as every other language can be
>> expressed in Lisp. That is rather a lot of power.
>
> The compiled code of ANY compiled programming language is as
> efficient as
> any other if it is used with a bit/a lot of care, compiled well, AND
> if it
> uses the same algorithms. There is, however, a huge difference between
> compiled code and functions that are declared at run-time unless your
> environment takes the time out from execution to compile those.
In the Lisp world you could consider compilation simply another
transformation of the data/code without even stepping out of Lisp. That
is pretty cool in my book. With Lisp macros you can in many cases
compile on first use in even such totally dynamically created code and
work at full compiled speed from then on. Lisp communities invented
JIT compiler technology over a decade before Java was even an idea.
> Further,
> there is a huge difference in the speed and scalability of data access
> and
> lookup methods. LISP innately causes the programmer to look at
> everything
> as a list.
This hasn't been true for over 2 decades. Perhaps you need to update
your knowledge of Lisp.
> Would you rather look-up your first name in an ordered list of
> names or in a balanced b-tree? Yes, the balanced b-tree could be
> expressed
> LOGICALLY in list form but the tree-balancing operations required
> during
> addition and deletion would not be as optimized (scalable) as with a
> raw,
> specially designed data structure.
Are you making some claim that that sort of data structure can't be
built quite simply and efficiently in Lisp?
> The problem that I have with virtually
> every LISP environment is the same problem that I have with most other
> programming environments. It tries to - - nay, insists that it - - do
> EVERYTHING, including things that it isn't good at.
>
Lisp is good at far more than you seem to be aware of.
- s
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:46 MDT