Re: LISPPA

From: Alexander Baranovsky (ab_at_cable.netlux.org)
Date: 05/04/04 

Date: 4 May 2004 03:29:37 -0700

>> My remark has been related to the word "includes". The Lisps cannot
be
>> a match for such imperative languages as C, Basic or Pascal in view
of
>> effectivity of programming,

> What do you mean by "effectivity"?

The speed of execution and the minimization of expenditure for the
memory resources.

>> compile-time type checking,

>Compile-time type checking is nice. But, at least when
>comparing Lisp with languages like C, Pascal and Basic,
>it just isn't worth the pain. The small gain in safety
>and convenience is much, much more than offset by the
>verbosity, the inconvenience whenever anything needs
>to be changed, and the near-impossibility of interactive
>use. With the time dynamic typing saves me, I can put
>more care into checking the safety of my code in other
>ways. The bugs that my C compiler catches for me are
>the trivial, shallow ones that I'd have caught myself
>anyway.

Any Pascal programmer will testify that the compile-time error
checking is huge advantage. Not only type checking but explicit
declaration of variables allows to avoid many problems related to the
scope, time of life etc. These "trivial" bugs are dangerous.

I can accept that Lisp tries to compensate of the lack of compile-time
error checking by means of another tools, but please do not protest
against evidence: if majority of bugs can be fixed before execution,
it is advantage.

> clean
> algol-liked syntax and readability,

>The syntax of Lisp is much cleaner than that of any of
>your preferred languages. It is, indeed, not Algol-like,
>and apparently that's a problem for you. That's fine;
>it's a problem for many people. But please understand
>that *your* difficulty with the syntax of Lisp is not
>*our* problem. "Readability" is almost entirely a
>consequence of familiarity. "Lisp is less readable"
>can be paraphrased as "I haven't used Lisp so much".
>Boring.

:-)

Open any book devoted to algorithmes and data structures, or better:
open book "AI.Structures and Strategies for Complex Problem Solving"
by George Luger. You will find algorithmes written in pseudo-pascal,
not in Lisp. Open book "Symbolic logic and mechanical theorem proving"
by Chang and Lee and compare source code presented in Appendix A with
the translation of the code presented at my site...

I understand you. If somebody is writing programs in assembler during
25 year, he will tell that *your* difficulty with the syntax of
assembler is not
*his* problem. :-). No, I do not compare Lisp and Assembler. I'm
trying to tell about tradition in the representation of algorithmes.

>> big number of IDEs,

>Why would that be an advantage? One is enough. Perhaps zero
>is enough.

New protest against evidence :-) Please understand, my position is
absolutely non-agressive, unlike some Lisp programmers in this thread.
I do not mean you, I respect your professional approach to the
discussion. But why sometimes you are trying to discuss obvious
things? :-)
If you have tools of visual programming, nice editor, advanced
debugger: why it is not important?

>> huge amount of investments

> Ah yes, money-oriented programming. The new paradigm.

:-)

This is one of sides of reality which reflects the general recognition
of mentioned languages.

> and huge number of users.

>If you feel unsafe when you're doing something that millions
>of other people aren't also doing, then by all means go and
>use Visual Basic.

No, no. My intention is contrary. I'm trying to extend mentioned
imperative languages with new tools which will allow to increase the
applicability of those languages for the wide set of interesting and
science-intensive problems.

>> Does it mean I consider Lisp as a bad or useless language? Not, of
>> course. For example, I like the idea to derive language from a
minimal
>> set of base concepts,

> Common Lisp is no more "derived from a minimal set of base
> concepts" than Pascal or C.

My statement "I like the idea" has been related to Lisp.

>Nor is our preference for Lisp entirely a matter of
>wanting "convergence" between imperative, functional
>and logic programming.

>C, Basic and Pascal are inferior for "such convergence"
>because
>
> - without lexical closures they are unusable for
> functional programming;

> - making a sharp distinction between expressions
> and statements, and forbidding lots of useful
> stuff to occur in the former, they are painful
> for functional programming;

This is true. The functional model is just a "point at infinity" for a
good imperative language. Alas, we will not able to reduce the
programming as a whole to the functional paradigm. But, for example,
if the assignment operator is "evil", the language should allow to
restrict the using assignments. It leads to idea of representation of
complex transformations and algorithmes in a concise form which hides
internal mechanismes of memory allocation, pointers and big number of
"auxiliary assignments". Another ideas such as recursion, high-order
functions etc can be considered as properties of "good" imperative
language.

> - lacking automatic memory management, they are
> difficult to use effectively in any style that
> isn't explicit about the sequence of operations,
> which makes functional programming (and many
> other things) very unpleasant.

Many imperative languages support it: Java, C# and other. However, in
my opinion, the "good" language should support both automatic memory
management and a possibility to free memory explicitly (for example,
in long loops). Any model of garbage collector has bottlenecks,
professional programmer should know how the garbage collector works to
write effective and safe programs.

>I'm not particularly interested in "logic programming",
>neat though it is, so I shan't comment on the deficiencies
>of your preferred languages as substrates for logic
>programming beyond saying that the reason why Lisp is
>usable for logic programming is its capacity for syntactic
>abstraction, which is another conspicuous lack in the
>languages you prefer.

I guess, you mean the representation of terms. But array is not less
suitable for it than lists. Compare

(f (g x y) a)

and

[f, [g, x, y], a]

I do not see big differences. Moreover, the presence of the random
access as property of array, can increase the performance.

>They have other deficiencies compared to Common Lisp,
>which aren't a matter of being unsuitable for "convergence"
>or unfit for "symbolic computation".

May be "yes", may be "no". But please take a look at the theorem
proving program presented at LISPPA site before any conclusion. You
will see that the problem of programming of "kernel" of the logic
programming is absolutely painless.

Btw, I wrote my first interpreter (for the VIRT language) 7 years ago.
It was written bad, the interpreter was slow. However it provided
better performance than XLISP for the theorem proving. Ok, XLISP is
not Common Lisp, VIRT is not Delphi. Even my present paxScript is more
fast than VIRT in 8 -10 times. So, your conclusions look as premature
ones.

>Please try to understand the following: There are more
>reasons for using Common Lisp than you think there are.
>(There are doubtless more reasons for using C, or Fortran,
>or Haskell, or 6502 assembly language, than you think,
>too.) You have somehow got the idea that (1) Lisp is all
>about "symbolic computation" for AI, and (2) the only
>thing that makes Lisp good for "symbolic computation"
>or for AI is its support for heterogeneous lists. Neither
>of those things is true. So your repeated statements that
>"LISPPA" makes C, Pascal and Basic suitable replacements
>for Lisp by enabling them to do "symbolic computations"
>completely miss the point, and would completely miss
>the point even if it were true that Pascal+LISPPA is just
>as good for symbolic computation as Lisp. Which it isn't.

Please understand me too :-) The "attack" of Lisp never was my goal
(however, it is not the same as to consider Lisp as a "sacred cow").
Lisp, functional and logical languages are useful sources for ideas in
view of an imperative programmer. If they are more suitable for a
class of problems at present time, I'm trying to understand "why" and
to find a "good replacement" in imperative language such as Pascal,
I'm trying to find another tools to solve the same problems with the
same success or even more effectively. My audience is C, Pascal, Basic
and Java programmers par excellence, LISPPA has been designed for
these languages. But personally for me, it is interesting to know
reaction and Lisp programmers as well.

>I dare say that adding heterogeneous arrays to Pascal is
>an improvement, just as you say it is. That's nice. Well
>done. But please leave Lisp out of it, because what you've
>done doesn't have anything to do with Lisp other than
>the name.

:-)

I'm sorry about the name. May be just this point irritate Lisp
programmers very much and "processing of dynamic data structures based
on the polymorphic arrays" would be more better and painless :-) But I
have thought that consideration "array vs list" can be interesting for
wide area of symbolic computations and AI applications. Indeed, the
term

(f (g x y) p(a))

can be considered as list of lists and as array of arrays. This
duality has been reflected in the "LISPPA" name.

>> In another hand, any declarative model of
computations
>> can be easily implemented as a set of classes written in the
language.

>(So you aren't talking about C or Pascal, then, but about some
>extensions of them with classes like C++ or Delphi.)
>
>Any "declarative model of computations" can be easily
>implemented by a set of assembly-language routines and
>suitable conventions for calling them. It'll hurt, though.
>Likewise for "declarative programming" in any language
>that's much like C, Basic or Pascal.

We are discussing tools of painless, native implementation.

>> A lot of programmers can be interested to add AI functionality to
>> already existed applications as extra module in C, Basic or Pascal,
>> new effective solutions will be developed in the framework of
>> component-based architecture...

>"Component-based architecture"? Man, that's so 20th-century.
>It's all web applications and XML nowadays. You're on the
>wrong bandwagon.

I never hear that the component-based architecture has been abolished.
:-)

A.

Gareth McCaughan <gareth.mccaughan@pobox.com> wrote in message news:<87smehmbii.fsf@g.mccaughan.ntlworld.com>...
> Alexander Baranovsky wrote:
>
> > My remark has been related to the word "includes". The Lisps cannot be
> > a match for such imperative languages as C, Basic or Pascal in view of
> > effectivity of programming,
>
> What do you mean by "effectivity"?
>
> > compile-time type checking,
>
> Compile-time type checking is nice. But, at least when
> comparing Lisp with languages like C, Pascal and Basic,
> it just isn't worth the pain. The small gain in safety
> and convenience is much, much more than offset by the
> verbosity, the inconvenience whenever anything needs
> to be changed, and the near-impossibility of interactive
> use. With the time dynamic typing saves me, I can put
> more care into checking the safety of my code in other
> ways. The bugs that my C compiler catches for me are
> the trivial, shallow ones that I'd have caught myself
> anyway. The ones it doesn't catch are the subtle ones
> that are easier to find when I'm not wasting neurons
> on the hassle of static typing.
>
> Now, if you were offering something like ML or Haskell
> where you hardly ever need to declare types explicitly
> becausae the inferencer is so clever, you'd have a point.
> But you aren't.
>
> > clean
> > algol-liked syntax and readability,
>
> The syntax of Lisp is much cleaner than that of any of
> your preferred languages. It is, indeed, not Algol-like,
> and apparently that's a problem for you. That's fine;
> it's a problem for many people. But please understand
> that *your* difficulty with the syntax of Lisp is not
> *our* problem. "Readability" is almost entirely a
> consequence of familiarity. "Lisp is less readable"
> can be paraphrased as "I haven't used Lisp so much".
> Boring.
>
> > huge number of libraries,
>
> Yes, C wins there; maybe Basic too, if you mean Microsoft
> Visual Basic. I'm not so sure about Pascal, but maybe you're
> right.
>
> > big
> > number of IDEs,
>
> Why would that be an advantage? One is enough. Perhaps zero
> is enough.
>
> > huge number of applications,
>
> The number of applications written in a particular language
> may (debatably) be some sort of *measure* of its quality,
> but it isn't itself an advantage or a disadvantage of the
> language.
>
> > huge amount of
> > investments
>
> Ah yes, money-oriented programming. The new paradigm.
>
> > and huge number of users.
>
> If you feel unsafe when you're doing something that millions
> of other people aren't also doing, then by all means go and
> use Visual Basic.
>
> > Does it mean I consider Lisp as a bad or useless language? Not, of
> > course. For example, I like the idea to derive language from a minimal
> > set of base concepts,
>
> Common Lisp is no more "derived from a minimal set of base
> concepts" than Pascal or C.
>
> > But why Lisp programmers think that the
> > imperative platform and such languages as C, Basic or Pascal is an
> > unsuitable base for such convergence? Indeed, there are no big
> > problems to fit mentioned imperative languages for the symbolic
> > computations.
>
> It's got nothing much to do with "symbolic computations";
> the large majority of stuff done in Common Lisp doesn't
> take the form of "symbolic computations". It happens that
> Lisp is particularly good at such things, but there are
> lots of other things it's particularly good at.
>
> Nor is our preference for Lisp entirely a matter of
> wanting "convergence" between imperative, functional
> and logic programming.
>
> C, Basic and Pascal are inferior for "such convergence"
> because
>
> - without lexical closures they are unusable for
> functional programming;
>
> - making a sharp distinction between expressions
> and statements, and forbidding lots of useful
> stuff to occur in the former, they are painful
> for functional programming;
>
> - lacking automatic memory management, they are
> difficult to use effectively in any style that
> isn't explicit about the sequence of operations,
> which makes functional programming (and many
> other things) very unpleasant.
>
> I'm not particularly interested in "logic programming",
> neat though it is, so I shan't comment on the deficiencies
> of your preferred languages as substrates for logic
> programming beyond saying that the reason why Lisp is
> usable for logic programming is its capacity for syntactic
> abstraction, which is another conspicuous lack in the
> languages you prefer.
>
> They have other deficiencies compared to Common Lisp,
> which aren't a matter of being unsuitable for "convergence"
> or unfit for "symbolic computation".
>
> Please try to understand the following: There are more
> reasons for using Common Lisp than you think there are.
> (There are doubtless more reasons for using C, or Fortran,
> or Haskell, or 6502 assembly language, than you think,
> too.) You have somehow got the idea that (1) Lisp is all
> about "symbolic computation" for AI, and (2) the only
> thing that makes Lisp good for "symbolic computation"
> or for AI is its support for heterogeneous lists. Neither
> of those things is true. So your repeated statements that
> "LISPPA" makes C, Pascal and Basic suitable replacements
> for Lisp by enabling them to do "symbolic computations"
> completely miss the point, and would completely miss
> the point even if it were true that Pascal+LISPPA is just
> as good for symbolic computation as Lisp. Which it isn't.
>
> I dare say that adding heterogeneous arrays to Pascal is
> an improvement, just as you say it is. That's nice. Well
> done. But please leave Lisp out of it, because what you've
> done doesn't have anything to do with Lisp other than
> the name.
>
> > In another hand, any declarative model of computations
> > can be easily implemented as a set of classes written in the language.
>
> (So you aren't talking about C or Pascal, then, but about some
> extensions of them with classes like C++ or Delphi.)
>
> Any "declarative model of computations" can be easily
> implemented by a set of assembly-language routines and
> suitable conventions for calling them. It'll hurt, though.
> Likewise for "declarative programming" in any language
> that's much like C, Basic or Pascal.
>
> > A lot of programmers can be interested to add AI functionality to
> > already existed applications as extra module in C, Basic or Pascal,
> > new effective solutions will be developed in the framework of
> > component-based architecture...
>
> "Component-based architecture"? Man, that's so 20th-century.
> It's all web applications and XML nowadays. You're on the
> wrong bandwagon.