Re: LISPPA

From: Gareth McCaughan (gareth.mccaughan_at_pobox.com)
Date: 05/05/04 

Date: 05 May 2004 00:49:26 +0100

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"?
>
> The speed of execution and the minimization of expenditure for the
> memory resources.

Most things you can do in C, Pascal or Basic you can also
do in Common Lisp with code that runs about as fast. Some
varieties of low-level bit diddling are still easier to
do efficiently in C. (Some are easier to do efficiently
in assembler.) The slowness of Lisp is mostly an urban
legend.

It's true that Lisp programs are usually more memory-hungry
than programs written in C or Pascal. As against that, they
usually have considerably fewer memory-related bugs. Memories
are so big these days that memory use only matters much for
large programs, and it's not clear that *large* Lisp programs
are much more memory-hungry than *large* programs in weaker
languages.

>> 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.

"Any Pascal programmer"? The huge majority of Pascal programmers
are not in a position to have an educated opinion on whether
static type checking and explicit type declarations make for
better programs than dynamic type checking and type inference,
because the huge majority of Pascal programmers have never used
any language with dynamic type checking and type inference for
anything other than trivial tasks. (I suspect most of them
have *never* used one at all.)

Making variable scopes and lifetimes clear has nothing to do
with making their types explicit. Common Lisp does scoping
just as cleanly as any of the languages you prefer, even
when you're not declaring any types at all. Why on earth
should it be necessary to declare the type of a variable
in order to establish its scope?

> 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.

You have given no evidence. As for your "majority of bugs":
my experience is as follows. When I am writing in C or C++,
I commit a substantial number of trivial errors that the
compiler catches. Some of them have to do with the types
of variables. I make these errors, the compiler tells me off,
I fix them. When I am writing in Common Lisp, I do not make
nearly so many of these trivial errors.

One reason for this is that many of the errors are *consequences*
of the type system. Many others are consequences of other
misfeatures of C or C++. It is not a merit in a language that
it creates ways of going wrong and then warns you when you
fall into them.

Another reason, I think, is that when writing in C or C++
there is so much irrelevant nonsense that you have to be
thinking about that your brain has less attention available
for thinking about other things, like all the bugs you're
putting into your code.

>> 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...

As someone has already pointed out, there are books on
AI and books on algorithms-and-data-structures-and-all-that
that use Lisp syntax. The most famous of all "algorithms
and data structures and all that" books would be Knuth's
three volumes, which use ... an assembly language of his
own invention.

(I have three AI books ready to hand. One uses Lisp notation
for its algorithms, one uses pseudo-Pascal, and one doesn't
have any formally stated algorithms at all.)

> 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. :-).

Right. You could ask: How long did it take before you
could read this stuff fluently? and compare the answers
for different languages. That's still sensitive to what
languages people learn first. I predict that the difference
between Lisp and Pascal will be small, and that both will
be far ahead of most assembly languges.

>>> big number of IDEs,
>
>> Why would that be an advantage? One is enough. Perhaps zero
>> is enough.
>
> New protest against evidence :-)

What does that mean?

> 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? :-)

I would prefer to ask: Why do you sometimes think things are
obvious when they are obviously false? :-)

> If you have tools of visual programming, nice editor, advanced
> debugger: why it is not important?

The question I asked was: why is it an advantage to have many
different IDEs? Actually, I'll concede that maybe having a
couple of decent ones is good, because people's tastes vary.
(Though the advantages of consistency might outweigh that,
if there were just one but a very good one.)

"Perhaps zero is enough" wasn't an entirely serious statement,
but there *are* plenty of people who find fancy graphical IDEs
less productive than, say, Emacs and the usual collection of
Unixy stuff. If by "visual programming" you mean the sort of
thing VB does for you, that's very valuable when you're building
GUIs but much less useful for everything else one does when
programming. Yes, a good debugger is very useful. It doesn't
need to be graphical. Yes, a good editor is very useful. It
doesn't need to be part of an IDE.

I've seen people be very productive indeed in Emacs. I've
seen prople be very productive in Visual Studio, too.

By the way, Lisp does have IDEs. All the commercial CL
implementations have them. There's also an excellent
(though unfortunately not yet entirely mature) Emacs-based
Lisp development environment, with the charming name
of SLIME.

>> 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.

Fine. I shan't try to stop you :-).

>>> 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.

I don't understand; sorry.

>> 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.

You say "alas"; I say "thank goodness". I want to have
functional programming *available*. I don't want to be
forced to use it all the time. Sometimes a loop is just
a loop.

> But, for example,
> if the assignment operator is "evil", the language should allow to
> restrict the using assignments.

The assignment operator is not evil. Unless you mean
specifically C++'s assignment operator, which conflates
assignment and copying in a brain-damaging way. That's
evil, all right.

> 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.

All of which are poorly supported by C, Pascal and Basic.
(Except for recursion, which is passably supported by all
modern languages.)

> > - 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.

Yes. But you referred specifically to C, Pascal and Basic.
Those languages do not have automatic memory management.
(Actually, maybe Visual Basic does.)

> 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.

It is very rare for the GC to be a bottleneck. But I do quite
like languages like Modula-3 where automatic and manual memory
management can coexist happily.

>> 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.

No, I do not just mean the representation of terms. I mean
that when you have a language that's basically designed for
one sort of programming and you try to use it for another,
some things tend to be expressed in ugly ways. For instance,
if you try to do object-oriented programming in plain old C
you have to build your own method tables and write explicit
code to use them. This ends up being verbose and hard to read,
in comparison with languages that have syntactic support for OO
such as Objective-C and C++. (And that's just about the only
time you'll hear me saying that C++ is easier to read than
something else.)

Similarly, if you try to do logic programming in, say, Pascal
then things that Prolog has special notation for -- adding
facts to the database, making queries -- needs to be done
in a more explicit way, which again will be verbose and hard
to read.

The same would be just as true in Common Lisp, except that
Common Lisp has powerful features for syntactic abstraction --
macros and a configurable reader -- so that you can write
logic programs in Common Lisp that are nearly as clear and
concise as they would be in Prolog. You can find some nice
examples in Norvig's excellent book "Paradigms of artificial
intelligence programming".

As for the performance of arrays versus linked lists -- you
*do* know that Common Lisp has arrays too, right?

>> 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.

It doesn't look "absolutely painless" to me, in comparison
with doing such things in Lisp.

> 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.

I have no idea what conclusions you think look premature
because 7 years ago you wrote something that gave you
better performance for theorem proving than something
else.

>> 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").

No, I realise. But ... you came into comp.lang.lisp, saying
"look at my wonderful new thing, which gives all the power
of Lisp to C, Pascal and Basic". And, actually, that *is*
an attack on Lisp, because it's saying that Lisp doesn't
offer anything valuable beyond Pascal + heterogeneous arrays.
Which is not only false but laughably false.

> 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.

It looks to me as if you have conflicting requirements.
On the one hand, you want something that's completely
familiar to Pascal programmers, something that's just
Pascal with a few little bags on the side. On the other
hand, you want something that's just as good as Lisp
for solving hard problems. I'm sorry to be the bringer
of bad news, but I don't think you can have both at once.

>> 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 :-)

I'm not irritated by the name. I'm irritated only by the fact
that you seem to consider that this shallow resemblance to
Lisp makes your languages just as effective as Lisp for the
things Lisp does well. Believe me, it doesn't.

> 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.

No one is disputing that you can use heterogeneous arrays
when writing programs that do symbolic computation. Why
would they?

>>> In another hand, any declarative model of
>>> computations can be easily implemented as a set of classes
>>> written in the language.
...
>> 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.

"Painless" is like "readable": it's relative to what
you're used to. I expect that in the early days of
assembly language programming, *that* was advertised
as a way to write complicated programs painlessly. In
fact, it did remove a lot of the pain, but then new
kinds of pain were discovered. So then along comes
FORTRAN, which lets you write your scientific software
painlessly, using real mathematical notation. Um,
except that it turns out that there are other sources
of pain too even when you write in FORTRAN. So it goes:
every advance in programming technology seems like it
might mean an end to pain, but in fact it just means
that you get to discover some new (and hopefully less
awful) kinds of pain.

I do not accept that "any declarative model of computations
can be easily implemented as a set of classes written in
the language". It may be true for people who don't feel
pain at having to write similar boilerplate code over and
over again, but I am not one of those people. It may be
true for people who don't mind code that's twice the length
it should be, but I am not one of those people. It may be
true for people who don't mind having the important material
in their software obscured by syntactic irrelevancies, but
I am not one of those people. 

-- 
Gareth McCaughan
.sig under construc
Quantcast