Following is a Funk program, a symbolic differentiation program.
It was written on a trial and error basis, without much computer algerbra
theory. The point is to show off Funk, not how little I know about computer
algebra.
Funk is an extremely simple and elegant language / formal system. It can be
completely defined in a few paragraphs, just like URMs or Turing machines.
But it is nevertheless a high level symbolic computation language, like Lisp
and Prolog, except that arithmetic is not built in and it is far simpler.
Funk is a pure symbol processing language. It backtracks to find multiple
solutions like Prolog. It can be viewed as a very natural an extension of a
finite state machine viewed as a digraph of states.
Please visit my web site. I have an ulterior motive: I need a collaborator
in the further development of Funk. Funk sits on the borderline between
computing and mathematics. So I need someone so inclined. But comments
are also welcome.
-Dave Davis
·······@spcunb.spc.edu
www.davestuff.org or www.spc.edu/~davis_d
Look under Computing, then under Funk.
============================================================================
: start
=> D tan u .
x .
: x : y : z
Const .
Func .
- - x => x .
- x .
sin + x y => + * sin x cos y * sin y cos x .
sin x .
cos + x y => + * cos x cos y - * sin x sin y .
cos x .
tan x => / sin x cos x .
exp + x y => * exp x exp y .
exp x .
ln * x y => + ln x ln y .
ln x .
D Const => 0 .
D sin x => * cos x D x .
D cos x => - * sin x D x .
D exp x => * exp x D x .
D + x y => + D x D y .
D * x y => + * D x y * x D y .
D / x y => / + * y D x - * x D y * y y .
D x .
^ x + y z => * ^ x y ^ x z .
^ x y .
* + x y z => + * x z * y z .
* - x y => - * x y .
* 0 x => 0 .
* 1 x => 1 .
* x 0 => 0 .
* x 1 => x .
* x x => x ^ 2 .
* x + y z => + * x y * x z .
* x * y z => * * x y z .
* x - y => * - x y .
* x y .
/ / x => x .
/ x 1 => x .
/ x x => 1 .
/ x 0 => DIV_ZERO .
/ x y .
+ * cos x ^ 2 y * sin x ^ 2 y => y .
+ 0 x => x .
+ x 0 => x .
+ x + y z => + + x y z .
+ x y .
: Const
0 . 1 . a . b .
: Func
u . v .
"David K. Davis" wrote:
> Funk is an extremely simple and elegant language / formal system. It can be
> completely defined in a few paragraphs, just like URMs or Turing machines.
> But it is nevertheless a high level symbolic computation language, like Lisp
> and Prolog, except that arithmetic is not built in and it is far simpler.
> Funk is a pure symbol processing language. It backtracks to find multiple
> solutions like Prolog. It can be viewed as a very natural an extension of a
> finite state machine viewed as a digraph of states.
What are the essential advantages of Funk over Lisp and
Prolog in practice? Thanks.
M. K. Shen
From: David K. Davis
Subject: Re: Funk - symbolic differentiation
Date:
Message-ID: <Go9I5H.7oD@spcuna.spc.edu>
In comp.lang.misc Mok-Kong Shen <·············@t-online.de> wrote:
: "David K. Davis" wrote:
: > Funk is an extremely simple and elegant language / formal system. It can be
: > completely defined in a few paragraphs, just like URMs or Turing machines.
: > But it is nevertheless a high level symbolic computation language, like Lisp
: > and Prolog, except that arithmetic is not built in and it is far simpler.
: > Funk is a pure symbol processing language. It backtracks to find multiple
: > solutions like Prolog. It can be viewed as a very natural an extension of a
: > finite state machine viewed as a digraph of states.
: What are the essential advantages of Funk over Lisp and
: Prolog in practice? Thanks.
: M. K. Shen
I believe that attached program could not have been written so transparently
and cleanly in Lisp or Prolog.
-Dave D.
David K. Davis <·······@spcunb.spc.edu> writes:
> I believe that attached program could not have been written so
> transparently and cleanly in Lisp or Prolog.
That may be fine for my day-to-day tasks involving writing programs to
do single variate differentiation, but frankly I don't spend much time
doing that, so the metric doesn't seem to fit with anything terribly
useful.
Parallel this, if you will, with the typical description of _A New
Macro Scheme For The Scheme Language_.
"We have a cool new notation that makes it really convenient for
you to have a new macro notation. We demonstrate how useful it is
by showing how to implement LET, IF, COND, and DO. See how useful
it is?"
And the answer is, that's _NOT_ particularly useful. I don't sit
around all day wondering if there might be some more pithy way of
defining LET, IF, COND, and DO. I've already got perfectly good
implementations of them.
As for symbolic differentiation, Peter Norvig's book has a pretty good
chapter on that; I've never gone through it in detail because I've got
a copy of MAXIMA kicking around on the off-chance that I need to
differentiate something complex, and I just don't spend much time
working with calculus equations.
Note that those are both worthy reasons not to care very much; you are
going to have to work _hard_ to motivate anyone here to get terribly
excited about your reinvention of a wheel that people don't have much
direct need for.
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www3.sympatico.ca/cbbrowne/oses.html
:FATAL ERROR -- YOU ARE OUT OF VECTOR SPACE
From: David K. Davis
Subject: Re: Funk - symbolic differentiation
Date:
Message-ID: <GoAqxx.M7n@spcuna.spc.edu>
········@acm.org wrote:
: David K. Davis <·······@spcunb.spc.edu> writes:
: > I believe that attached program could not have been written so
: > transparently and cleanly in Lisp or Prolog.
: That may be fine for my day-to-day tasks involving writing programs to
: do single variate differentiation, but frankly I don't spend much time
: doing that, so the metric doesn't seem to fit with anything terribly
: useful.
: Parallel this, if you will, with the typical description of _A New
: Macro Scheme For The Scheme Language_.
: "We have a cool new notation that makes it really convenient for
: you to have a new macro notation. We demonstrate how useful it is
: by showing how to implement LET, IF, COND, and DO. See how useful
: it is?"
: And the answer is, that's _NOT_ particularly useful. I don't sit
: around all day wondering if there might be some more pithy way of
: defining LET, IF, COND, and DO. I've already got perfectly good
: implementations of them.
: As for symbolic differentiation, Peter Norvig's book has a pretty good
: chapter on that; I've never gone through it in detail because I've got
: a copy of MAXIMA kicking around on the off-chance that I need to
: differentiate something complex, and I just don't spend much time
: working with calculus equations.
: Note that those are both worthy reasons not to care very much; you are
: going to have to work _hard_ to motivate anyone here to get terribly
: excited about your reinvention of a wheel that people don't have much
: direct need for.
: --
: (reverse (concatenate 'string ····················@" "454aa"))
: http://www3.sympatico.ca/cbbrowne/oses.html
: :FATAL ERROR -- YOU ARE OUT OF VECTOR SPACE
What I'm trying to rouse interest in is Funk as an extremely simple
formal system and programming language. It's quite beautiful.
What its practical possibilities are I'm not sure myself. But I do believe,
based on my fooling with it, that very some very transparent and pretty
programs can be written in it.
I understand your point on practicality, but not your point about reinvention.
-Dave
David K. Davis <·······@spcunb.spc.edu> writes:
> ········@acm.org wrote:
> : David K. Davis <·······@spcunb.spc.edu> writes:
> : > I believe that attached program could not have been written so
> : > transparently and cleanly in Lisp or Prolog.
>
> : Note that those are both worthy reasons not to care very much; you are
> : going to have to work _hard_ to motivate anyone here to get terribly
> : excited about your reinvention of a wheel that people don't have much
> : direct need for.
>
> What I'm trying to rouse interest in is Funk as an extremely simple
> formal system and programming language. It's quite beautiful.
It's not that I've lost my appreciation of beauty.
It's just that I've long ago gotten over searching for programming
languages that will offer me beauty. Beauty in a language only gets
you so far. After that, you have to have something to say.
Consider a poet. There is a time in life to learn many kinds of
poetry. And some human languages are probably better suited to poetry
than others. But at some point one has to stop and just get dirty
DOING things in whatever blunt way they've accumulated. Absent
actual experiences, what justification poetry.
Consider, too, that many arts have many expressional modes. You see a
sunset. Could you paint it in oils? Yes. Watercolors? Yes.
Crayons? Yes. Would each look different? Yes. Surely there are
artists who moved from style to style, and perhaps even got good at
it. But a lot of grand master artists had (and continue to have) a
specialty style where they focused. This was not a repudiation of the
other styles. Doing something in watercolor is not a statement that
oils have no purpose. But having to always follow the art-du-jour and
never beeing able to settle on a technique, to become expert at the
technique, and to finally just PICK A SUBJECT and USE the technique,
is to have wasted one's life.
Life is not about learning techniques. It is about doing something.
I always reserve a little bit of my day every day to learn new things.
I don't have a closed mind. But there are many, many new things to be
learned and I also have to have the discipline to not go after everything
because to go after everything is to go after nothing.
This is a newsgroup to talk about Lisp, a language I consider good
enough that it lets me get on to the business of doing something.
Forgive me if I both don't reject the notion that you have found
alternate beauty and don't "rally" to the eternal academic
Pablovian-syren's call of "ding, ding, ding, stop all useful work, the
road to aesthetic beauty calls"...
It's not even that I think that it's not interesting to find programs
that can't be written as elegantly in Lisp and other languages as in
your language. It's just again: this is not news. Let me say it as
clearly as I can: There is no such thing as a free lunch.
Conservation of expressivity. Every improvement in the expressability
of one concept causes a consequent lessening of expressability of
another. (Kind of like assigning Goedel numbers to programs. There
are a finite number of small numbers, so only certain programs can get
them. If you swap in a new program to a low number, you have to swap
what you had on that out to a higher number.) All languages bank on
the idea that you'll want to say certain things and not want to say
others. That there exists a program that is hard to express in Lisp
is not a surprise, it's a confirmation that my theory of mathematics,
physics, and philosophy is not magically violated in Lisp. What
matters to me is not that there exists a program that is hard to
express in Lisp but easy to express in other languages, but rather
that I can express the things I need to express in Lisp without undue
burden. And, largely, I feel I can. Where I can't. My first impulse
is rarely to switch languages. It's usually to write a macro or
affect the read syntax or something. (And I really enjoy that in
Lisp; I have never felt hampered by Lisp's macro system, only enabled
by it.) In a rare instance, I might want to do a foreign function
call. But again, the thing that matters is solving my own problems
(for my own application situations) and solving problems that others
appear to have a lot that are keeping them from succeeding
commercially. And for that, I've got tools that work.
From: David K. Davis
Subject: Re: Funk - symbolic differentiation
Date:
Message-ID: <GoBFG1.ED9@spcuna.spc.edu>
I agree with almost all you say. I'm not looking for converts. I'm looking for
someone or some few who want to play with the same toys I'm playing with.
Funk is a symbolic computation language, so is Prolog (a language I played
with for a few years). Before I retired, I made a living writing business
programs in a bunch of different languages, yes, I admit it, even Cobol.
I got into programming because I needed to make a living. I was very practical
for a long time. I started out as a mathematician, but got derailed, involved
in the anti-war movement, drove a truck for 10 years, and then became a
business programmer to feed my kids. BUT NOW I am not so practical. Now I feel
I must atone for those years of writing Cobol.
Suppose God turns out to be someone like Edsger Dykstra? What will I have to
say for myself? I could end up looking at core dumps for eons. Of course, God
might turn out to be Grace Hopper. But then I would meet the same fate, the
only difference being that her intentions would have been good, thinking that I
would be enjoying myself.
More seriously, I do believe Funk has potential practical value for certain
kinds of problems. I also believe beauty has an important role to play in
in programming. My first programs were truly ugly. Not because they were in
Cobol. I read Dykstra's a Disciplie of Programming, and in particular the
chapter on updating a sequential file. From then on I wrote programs that I
KNEW were correct, at least in their basic logic - at least when I had time.
I believe that the practicality of beauty is drastically underated.
Yes, I'm babbling.
-Dave D.
================================================================
Kent M Pitman <······@world.std.com> wrote:
: David K. Davis <·······@spcunb.spc.edu> writes:
: > ········@acm.org wrote:
: > : David K. Davis <·······@spcunb.spc.edu> writes:
: > : > I believe that attached program could not have been written so
: > : > transparently and cleanly in Lisp or Prolog.
: >
: > : Note that those are both worthy reasons not to care very much; you are
: > : going to have to work _hard_ to motivate anyone here to get terribly
: > : excited about your reinvention of a wheel that people don't have much
: > : direct need for.
: >
: > What I'm trying to rouse interest in is Funk as an extremely simple
: > formal system and programming language. It's quite beautiful.
: It's not that I've lost my appreciation of beauty.
: It's just that I've long ago gotten over searching for programming
: languages that will offer me beauty. Beauty in a language only gets
: you so far. After that, you have to have something to say.
: Consider a poet. There is a time in life to learn many kinds of
: poetry. And some human languages are probably better suited to poetry
: than others. But at some point one has to stop and just get dirty
: DOING things in whatever blunt way they've accumulated. Absent
: actual experiences, what justification poetry.
: Consider, too, that many arts have many expressional modes. You see a
: sunset. Could you paint it in oils? Yes. Watercolors? Yes.
: Crayons? Yes. Would each look different? Yes. Surely there are
: artists who moved from style to style, and perhaps even got good at
: it. But a lot of grand master artists had (and continue to have) a
: specialty style where they focused. This was not a repudiation of the
: other styles. Doing something in watercolor is not a statement that
: oils have no purpose. But having to always follow the art-du-jour and
: never beeing able to settle on a technique, to become expert at the
: technique, and to finally just PICK A SUBJECT and USE the technique,
: is to have wasted one's life.
: Life is not about learning techniques. It is about doing something.
: I always reserve a little bit of my day every day to learn new things.
: I don't have a closed mind. But there are many, many new things to be
: learned and I also have to have the discipline to not go after everything
: because to go after everything is to go after nothing.
: This is a newsgroup to talk about Lisp, a language I consider good
: enough that it lets me get on to the business of doing something.
: Forgive me if I both don't reject the notion that you have found
: alternate beauty and don't "rally" to the eternal academic
: Pablovian-syren's call of "ding, ding, ding, stop all useful work, the
: road to aesthetic beauty calls"...
: It's not even that I think that it's not interesting to find programs
: that can't be written as elegantly in Lisp and other languages as in
: your language. It's just again: this is not news. Let me say it as
: clearly as I can: There is no such thing as a free lunch.
: Conservation of expressivity. Every improvement in the expressability
: of one concept causes a consequent lessening of expressability of
: another. (Kind of like assigning Goedel numbers to programs. There
: are a finite number of small numbers, so only certain programs can get
: them. If you swap in a new program to a low number, you have to swap
: what you had on that out to a higher number.) All languages bank on
: the idea that you'll want to say certain things and not want to say
: others. That there exists a program that is hard to express in Lisp
: is not a surprise, it's a confirmation that my theory of mathematics,
: physics, and philosophy is not magically violated in Lisp. What
: matters to me is not that there exists a program that is hard to
: express in Lisp but easy to express in other languages, but rather
: that I can express the things I need to express in Lisp without undue
: burden. And, largely, I feel I can. Where I can't. My first impulse
: is rarely to switch languages. It's usually to write a macro or
: affect the read syntax or something. (And I really enjoy that in
: Lisp; I have never felt hampered by Lisp's macro system, only enabled
: by it.) In a rare instance, I might want to do a foreign function
: call. But again, the thing that matters is solving my own problems
: (for my own application situations) and solving problems that others
: appear to have a lot that are keeping them from succeeding
: commercially. And for that, I've got tools that work.
"David K. Davis" wrote:
>
> I believe that attached program could not have been written so transparently
> and cleanly in Lisp or Prolog.
There were very early programs developed for differentiation,
because that's comparatively simple of all CAS capabilities.
Without knowing their existence, I attempted in the sixties
to write a program in ALGOL60 to do (patial) differentiation,
with rules provided by the user, the coefficients of
the terms in the rules being read in and stored in a
matrix form, so that the machine could easily apply them
accordingly. That was surely a relatively primitive way of
doing the job, but the program helped my colleague and
me nonetheless to solve a problem that we repeatedly failed
to do with paper and pencil (in many days each time) due
to inevitable human errors.
M. K. Shen
David K. Davis <·······@spcunb.spc.edu> writes:
> * 1 x => 1 .
Don't you want * 1 x => x . ???
> + * cos x ^ 2 y * sin x ^ 2 y => y .
Why isn't that + * ^ cos x 2 y * ^ sin x 2 y => y . It seems to me
that all your operators are prefix except ^ which appears to be infix.
Ole
From: David K. Davis
Subject: Re: Funk - symbolic differentiation
Date:
Message-ID: <GoAowp.K3A@spcuna.spc.edu>
In comp.lang.misc Ole Rohne <·········@cern.ch> wrote:
: David K. Davis <·······@spcunb.spc.edu> writes:
: > * 1 x => 1 .
: Don't you want * 1 x => x . ???
: > + * cos x ^ 2 y * sin x ^ 2 y => y .
: Why isn't that + * ^ cos x 2 y * ^ sin x 2 y => y . It seems to me
: that all your operators are prefix except ^ which appears to be infix.
: Ole
You are correct on both counts. Funk runs much faster using prefix because
the interpreter scans left to write and constants are dealt with much faster
than variables.
-Dave D.
symbols are scanned left to right, and the more constants are to the left
David K. Davis <·······@spcunb.spc.edu> writes:
>Ole Rohne <·········@cern.ch> wrote:
>: David K. Davis <·······@spcunb.spc.edu> writes:
>
>: > * 1 x => 1 .
>
>: Don't you want * 1 x => x . ???
>
>: > + * cos x ^ 2 y * sin x ^ 2 y => y .
>
>: Why isn't that + * ^ cos x 2 y * ^ sin x 2 y => y . It seems to me
>: that all your operators are prefix except ^ which appears to be infix.
>
>You are correct on both counts. Funk runs much faster using prefix because
>the interpreter scans left to write and constants are dealt with much faster
>than variables.
In this day and age, it seems like a bad idea to design language syntax
based on efficiency of interpretation. Human factors are much more important.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
> In this day and age, it seems like a bad idea to design language syntax
> based on efficiency of interpretation. Human factors are much more
> important.
Mixed yes and no. I agree that good human interfacing is very very
important. After all that's at the end all what programming languages are
about. However a programming language should also be as easy as possible be
implemented. A popular negative example is C++, how long did it take
compilers got even anywhere near the idea? How many really ANSI
complicant C++ are out there? (0?)
- Axel
From: David K. Davis
Subject: Re: Funk - symbolic differentiation
Date:
Message-ID: <GoGuyJ.Aq@spcuna.spc.edu>
In comp.lang.misc Fergus Henderson <···@cs.mu.oz.au> wrote:
: David K. Davis <·······@spcunb.spc.edu> writes:
: >Ole Rohne <·········@cern.ch> wrote:
: >: David K. Davis <·······@spcunb.spc.edu> writes:
: >
: >: > * 1 x => 1 .
: >
: >: Don't you want * 1 x => x . ???
: >
: >: > + * cos x ^ 2 y * sin x ^ 2 y => y .
: >
: >: Why isn't that + * ^ cos x 2 y * ^ sin x 2 y => y . It seems to me
: >: that all your operators are prefix except ^ which appears to be infix.
: >
: >You are correct on both counts. Funk runs much faster using prefix because
: >the interpreter scans left to write and constants are dealt with much faster
: >than variables.
: In this day and age, it seems like a bad idea to design language syntax
: based on efficiency of interpretation. Human factors are much more important.
: --
: Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
: The University of Melbourne | of excellence is a lethal habit"
: WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
The syntax (of Funk) is not based on efficiency. This particular
Funk program is written in prefix notation in order to speed things up. I
wrote a similar program for infix expressions and it was much slower.
Funk is slow. There are various source level optimizations possible, but they
reduce transparency. I'm working on source level optimizers (rewriters).
-Dave D.
From: David K. Davis
Subject: Re: Funk - symbolic differentiation
Date:
Message-ID: <GoAq23.LqM@spcuna.spc.edu>
In comp.lang.lisp Ole Rohne <·········@cern.ch> wrote:
: David K. Davis <·······@spcunb.spc.edu> writes:
: > * 1 x => 1 .
: Don't you want * 1 x => x . ???
: > + * cos x ^ 2 y * sin x ^ 2 y => y .
: Why isn't that + * ^ cos x 2 y * ^ sin x 2 y => y . It seems to me
: that all your operators are prefix except ^ which appears to be infix.
: Ole
And there's another error:
* x x => x ^ 2 .
should be
* x x => ^ x 2 .
I couldn't figure out why it seemed to run correctly despite the errors
you pointed out! I think this is why.
Anyway, thanks.
-Dave
In article <··········@spcuna.spc.edu>, David K. Davis
<·······@spcunb.spc.edu> wrote:
>In comp.lang.lisp Ole Rohne <·········@cern.ch> wrote:
>: David K. Davis <·······@spcunb.spc.edu> writes:
>
>: > * 1 x => 1 .
>
>: Don't you want * 1 x => x . ???
>
>: > + * cos x ^ 2 y * sin x ^ 2 y => y .
>
>: Why isn't that + * ^ cos x 2 y * ^ sin x 2 y => y . It seems to me
>: that all your operators are prefix except ^ which appears to be infix.
I seem to recall the following trig identity from my youth:
sin^2(x)+cos^2(x)=1 .
>
>: Ole
>
>And there's another error:
> * x x => x ^ 2 .
>should be
> * x x => ^ x 2 .
From: David K. Davis
Subject: Re: Funk - symbolic differentiation
Date:
Message-ID: <GoD8v4.KDo@spcuna.spc.edu>
In comp.lang.lisp Sashank Varma <·············@vanderbilt.edu> wrote:
: In article <··········@spcuna.spc.edu>, David K. Davis
: <·······@spcunb.spc.edu> wrote:
: >In comp.lang.lisp Ole Rohne <·········@cern.ch> wrote:
: >: David K. Davis <·······@spcunb.spc.edu> writes:
: >
: >: > * 1 x => 1 .
: >
: >: Don't you want * 1 x => x . ???
: >
: >: > + * cos x ^ 2 y * sin x ^ 2 y => y .
: >
: >: Why isn't that + * ^ cos x 2 y * ^ sin x 2 y => y . It seems to me
: >: that all your operators are prefix except ^ which appears to be infix.
: I seem to recall the following trig identity from my youth:
: sin^2(x)+cos^2(x)=1 .
Yes, but that's not good enough here because
* + x y z => + * x z * y z
might have already separated x and y. Again, this program is simply illustrative
of what kinds of things one can do easily in Funk. The program itself is not
of significance except to show a quick and dirty Funk program.
-Dave D.
: >: Ole
: >
: >And there's another error:
: > * x x => x ^ 2 .
: >should be
: > * x x => ^ x 2 .
> Funk is an extremely simple and elegant language / formal system.
Interesting. Even in this message, where he tries to tell us the
advantages of the language, he has mistakes in his own coding?
"A N Neil" <······@nym.alias.net> wrote in message
······························@nym.alias.net...
>
> > Funk is an extremely simple and elegant language / formal system.
>
> Interesting. Even in this message, where he tries to tell us the
> advantages of the language, he has mistakes in his own coding?
>
So? What is that supposed to mean?
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "A N Neil" <······@nym.alias.net> wrote in message
> ······························@nym.alias.net...
> >
> > > Funk is an extremely simple and elegant language / formal system.
> >
> > Interesting. Even in this message, where he tries to tell us the
> > advantages of the language, he has mistakes in his own coding?
> >
>
> So? What is that supposed to mean?
I think it means the implementation could use a read-eval-print loop :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: David K. Davis
Subject: Re: Funk - symbolic differentiation
Date:
Message-ID: <GoCp6o.A2L@spcuna.spc.edu>
In comp.lang.misc Coby Beck <·····@mercury.bc.ca> wrote:
: "A N Neil" <······@nym.alias.net> wrote in message
: ······························@nym.alias.net...
: >
: > > Funk is an extremely simple and elegant language / formal system.
: >
: > Interesting. Even in this message, where he tries to tell us the
: > advantages of the language, he has mistakes in his own coding?
: >
: So? What is that supposed to mean?
: --
: Coby
: (remove #\space "coby . beck @ opentechgroup . com")
Thank you. I make lots of mistakes. I don't have a collaborator and its hard to
see one's own mistakes.
-Dave D.