Ugh, more replying.

[Christopher Barry]

lafitte@math.huji.ac.il wrote:
> Christopher Barry wrote:
> 
> <snip>
> > Try writing a program that produces as output an *exact* copy of it's
> > source. For example, you write a file called foo.c, then:
> > $ cc foo.c -o foo
> > $ foo > foo.c
> <snip>
> 
> Are you trying to make the tunes list sound as sci.math? :(
> Anyone who has gone thru some computability course should know
> how to do this stupid thing. A friend of mine told me about this mailing
> list and I thought there would some more serious material.
> Let stop the bolony talking and continue the good work.
> 

Just can't seem to get away now....

I did mention that foo.c might insult the intelligence of a few. The
point is that there is a lot of talk of things on this list that are
difficult to even conceptualize, and that programming very, very simple
to conceptualize things that require little code with simple constructs
to work can be very difficult with currently available methods. It's not
as though you can type into the buffer of an editor the text:

	output own source code

and (realistically) apply a compiler to it to generate a binary that
outputs above text.

There's been this talk of "holistic code generation" and various types
self referencing functionality and my point is that you're not going to
be able to code these type of things by drawing pictures and clicking
buttons or expressing your ideas to your computer in any sort of
ambiguous way, but you're going to have to bend over backwards to get
even simple Tunes type things to work by typing an enormous ammount of
unintuitive and unambiguous code dumbed down to the point that the
current intelligence mechanisms in place on computers today are able to
'comprehend' it and generate it into the format they understand.

Anyways, there have been a number of replies to things I've said, and
maybe some time I'll get around to addressing them, but I don't need
this to start sucking up all of my time just yet.

I'd like to mention that I really like what I've been seeing just
recently. David Manifold is looking real sharp and go-get-um' with his
recent posts about addressing finer points and getting some real work
done.

Before I finish up this one small mail though I'd like to express my
concerns to Brian Rice and David Manifold who both have begun to or plan
to start writing Tunes in the C programming language. I'm sure you guys
know all about C's history and what it's original design goals and
purpose was so I won't beat that story to death again, but let me
mention that Lisp was designed by the AI community to be as suitable as
possible for the programming of intelligent mechanisms and this was a
primary design goal, and it took precedence over other considerations
like systems programming and performance and financial and marketability
and audience and ease of compiler writing considerations.

Lisp is very difficult to get started with, especially when you're
really comfortable with and used to C. You must learn to rethink in
general how you approach a programming task with Lisp.

In general, you can write programs in Lisp with 1/3rd to 1/10th the
source code of C, and if what you write is useful, it generally has a
wider and more general purpose usefulness and reusability to.

Even if you aim to write something in C, Lisp usually provides a rapid
way to prototype it and proof-of-concept it.

But Fare pointed out well I think where Lisp is deficient for
programming Tunes, but I can't think of anything better around to get
started with. If you use C you're just wasting your precious human
intelligence mechanisms paying attention to details that the Lisp
compiler and language is intelligent enough to take care of for you.

That said, I do 99% of my programming in C, because 99% of the Free
Software I use is written in it and I can't go readily about making
modifications in Lisp. That and the fact that the egcs -O6 and -m*
optimization flags generate insanely fast code with tiny image sizes and
someone really needs to write an optimized Lisp -> RTL front end for it.
If I had enough skills to write enough of that to get the interest and
help of others to help finish it, I would, but Lisp compilers are
insanely complex and the task is out of my league.

Also, since Fare is using mostly Scheme (which in the case of Tunes is
probably just as suitable as Common Lisp if not more so), if you guys
used it then you guys could more readily share code, as the reuse value
as mentioned earlier is much higher.

Christopher