Re: LISPPA

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

Date: 5 May 2004 11:24: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.
>
> 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.

I suppose that each legend based on a true story :-) .C or Pascal have
no legends regarding it. So, to see a reference on benchmarks would be
nice.

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

There are a few tools which allows to decrease footprint of a program
in "weaks languages": iteration instead of recursion and "local"
memory deallocation (at least). The "local" memory deallocation can
include:

- manually deallocation
- time of life of variable
- "semantics" deallocation (for example, reduced assignments in
LISPPA)

I do not see why using of last 2 cases leads to the writing less clear
programs.

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

Seems too categorical to be true. I can assure: Pascal has the dynamic
type checking. Take a look at the variant types. As for the type
inference, any Pascal compiler makes it at compile-stage. And, it
seems we already discussed it, please do not think about "average"
Pascal programmers very bad. Sorry that I need to repeat it.

>
> Making variable scopes and lifetimes clear has nothing to do
> with making their types explicit.

I never stated it.

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

??? See above: (I never stated it).

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

Honestly I do not have big experience in C/C++. My favorite language
is Pascal (Delphi). I'm programming in Pascal since 1990 year, my
previous language was FORTRAN-IV. So, the first my impression was the
power of compile-time error checking. If I have clean understanding
what I have to do, the rest is a simple thing, compiler finds my
errors like Word find my misprint. No "irrelevant nonsenses". (Yes, my
"Word" does not help me to write "poems in functional style", but it
is not an obstacle for writing another "poems" :-)

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

Knuth's trilogy is cool, but I had in mind another classic book: "The
design and analysis of computer algorithmes" (Aho, Hopcroft, Ullman).
It uses pseudo-pascal. Besides I like "Combinatorial algorithmes.
Theory and practice" (Reingold, Nievergelt and Deo), "Combinatoric for
programmers" (Lipsky), "Principles of Software Engineering and Design"
(Zelkowitz, Shaw, Gannon). All these books use pseudo-pascal I did not
mention "Algorithmes and data structure" (Wirth) as it is a "party"
book. :-)

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

It means to protest again bread and butter :-)

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

Please do not tell "they are", please tell "in my opinion, they are".
Categorical statements make discussion less interesting (in my opinion
:-)

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

I'm constantly trying to find out what is the "everything else one"?
Ok, I can guess: it is a sort of non-visual programming. :-) Moreover,
perhaps it is a sort of very difficult programming which compel me to
forget about nice editor, advanced debugger, third-party libraries.
But what I cannot understand is: how such difficult problem can exist
as "thing in itself" without necessity to integrate it with DBMS,
internet etc? But good IDE allows you to solve these
"input/deployment" problems easily.

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

:-)

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

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

CAR, CDR, CONS, EQ, ATOM.

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

I absolutely agree here. The functional approach should be used
"locally" and intelligently. The "alas" is another's "alas", not mine.

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

Too many auxiliary assignments is "evil" (in my opinion). :-) The
problem is similar to "goto" problem a bit. The "goto" exists, but
battle against "goto" was not useless: we got structured programming
as a result. The battle against auxiliary assignments leads to the
"functional appoach in the small". In particular, LISPPA illustrates
this tendency.

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

High order functions are available in Pascal via procedural types.

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

We already discussed the representation of facts, terms etc in Lisp
and Pascal + LISPPA. There are no big differences (please see above).
A query can be expressed as a term. So, no problem again. Moreover,
Pascal can provide more effective representation of terms in
comparison with Lisp. Once again, please see the theorem proving
program in paxPascal at the LISPPA site.

I mean the representation terms as "term" + "parameters".

Let's consider T term

 (f(x, y), g(x))

You see, the x variable is presented twice. To replace x with z (it is
a part of theorem proving algorithm), you have to make tour of tree in
Lisp.

In paxPascal you can represent the T term as

(f(p1, p2), f(p1)), where p1 is alias of x, p2 is alias of y. So (x,y)
represents parameters of T.

To rename variables of T, you have just to rename parameters. So, you
have linear algorithm instead of exponential one. This representation
also simplifies and speeds up the unification algorithm - heart of any
logical programming system.

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

Sorry, I have no this book. It would be really very interesting for me
to read it.

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

Yes, I know. But Common Lisp uses linked lists for the data
representation in the mentioned problem. As for the arrays for linear
algebra and related problems, I would prefer to use Pascal, not Common
Lisp.

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

Thank for the "to me" :-)

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

We are discussing the applicability of Pascal+LISPPA for simulation of
logical programming. You states it is not applicable. I remembered
VIRT as an imperative language with Modula-2 syntax as the first try
in this relation and mentioned that the first results in the theorem
proving were not very bad.

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

Oh, you "discovered" me. :-) I really have thought about competition.
But it is not the same as to say "forget Lisp. Your 40 years of
history is one big mistake". I repeat: I'm trying to reproduce
usefull features of Lisp and another languages in my experiment. Why
you see only "attack"? I want to learn and understand, not fight.

> Which is not only false but laughably false.

Please add "in my opinion". :-)

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

Let's see. Why not?

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

I do not consider all possible problems which "Lisp does well". But I
state that for many problems Pascal+LISPPA (Basic+LISPPA etc). can be
used with the same success or even better. These problems are:
knowledge representation, search algorithmes, symbolic computations,
interpreters of logic programming.

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

Sorry, I did not understand your question.

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

Ok.

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

Ok.

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

Ok.

Recruitment is not my goal at comp.lang.lisp.

Besides you are not quite right in your review.

In my opinion.

:-)

A.

Quantcast