🚀 go-pugleaf

Anil Joshi writes:

   Why should I bother about how many levels of interpretation is going
   on? Look at the original ALGOL syntax for dereferencing. The language
   processor dereferences a pointer as many times as required leading to a
   cleaner semantics.

I beg to differ.  The levels of evaluation are extreemly important to
the power of Lisp (any version).  It is quite easy to write a function
that allows unknown ammounts of arguments, which themselves may be
evaluated by the eval-loop.  This allows small ammounts of code to do
enormouse amounts of work.

   >   Is it advantageous over the other syntax or is it because one
   >   is forced to use elisp (GNU emacs coming from MIT and MIT being
   >   the bastion of Functional Programming Langs. esp. LISP) and the
   >   designers have chosen elisp as the language for emacs editor.

Excuse me... it is symbolic programming... Lisp is designed for
symbolic manipulation.  What rock have you been hiding under since
Project MAC?  Lisp was designed to manipulate symbols.  Variables are
untyped, it is the information that is typed.  Why do you think Lisp
is still the dominant language for AI, even though it is over 30 years
old?

   >You have to do the same thing if you are calling regexp routines
   >from C or C++, both of which use the backslash character as an
   >escape mechanism in their string syntax.  (Which other languages
   >use backslash in their strings?)

   The concept of backslash to escape a character is what I am objecting
   to.

Why do you object?  How else do you propose to escape certain
characters?  There is also the '|' escape mechanism for larger
ammounts of code.

   >   I don't see any advantage of using LISP syntax over say REXX
   >   for editor macros. I can do better in REXX than LISP.

Yes, but what about REAL extensions and adaptability.  I have used
REXX, and while it is nice, I'll take Lisp (or TECO).

   >also.  There is no difference in their power.  Lisp is merely a
   >much easier language to use.  If you don't think Lisp is easier,
   ^^^^^^^^^^^^^^^^^^^^^^^ I beg to disagree. I find that programming
   in LISP is quite contorted.  PROLOG is better.

Being both fluent in Prolog and Lisp, as you are apparently not, I can
say Lisp is easier because it is, above everything else, consistant.
Once you learn the basics of S-expressions, the rest of the language
falls into logical place.

   Have you used REXX/XEDIT or CLISTs/ISPF? I find that it is easier
   to write in REXX. I do agree that I haven't programmed much in
   ELISP.  Looks like you do not know anything about IBM Mainframe
   editors/programming environments either.

So why are you bashing (no pun intended) Elisp if you proclaim your
ignorance of it?  I have used dinosaurs with great unease as I dislike
being told what I can and cannot do.  I have survived Fortran on an
IBM 3090 and NEVER will I go back.

   >   and emacs has gone one step further in widening the gap by introducing
   >   an entirely new set of utilities/interfaces/langauges/tools.

   >Emacs is really an interface on top of the other interfaces.  Ordinary
   >users don't have to deal with more than Emacs.  Programmers should have no
   >problem dealing with multiple interfaces, otherwise perhaps they should
   >seek a different career.

   I think you will find the situation quite different in data processing
   in the industry. If you know only UNIX and nothing else, your job
   options are quite severely curtailed. Could you please tell me how
   emacs interfaces with any of the DBMS's on UNIX? (or any other OS?).

Quite nicely, given Elisps ability to handle management of other
processes.   If it doesn't interface, it's not to hard to make it
work.  I have seen an SQL client built around Elisp which is quite
nice.  The key, which I believe you are missing, is not ease of use,
so much as power.  I refuse to be told that I can't do something.  If
I can conceive of it, I want to be able to do it, and within all
reasonable expectations (of mine), Elisp fits this mold, but then I
sit here with 2 Lisp machines next to me (one running ZMacs).

   >   But GNU emacs is in my opinion is a step backwards in terms of bringing
   >   computing closer to the users.

   >What?!?!?  How long have you been using Emacs???

   Not for long. But I have read the manuals (both GNU Emacs and
   ELISP).  I read the manuals end-to-end first before I try to do
   anything.

Aha! I found your problem... you have to read manuals first.
Definately not a hacker :-)!  If I cannot learn something without
manuals, then it is not intuitive in my opinion, and I learned Emacs
without a manual, just a little card that had a few command on them
(like C-s, C-f, etc..) from the local University.  I learned Elisp by
reading Elisp code, but I do admit I have a copy of the Elisp manual
for a backup when I'm not quite sure if what I'm doing is the best
way.

   No. If you have one shell language that is actually a great advantage.
   You win.

Only if it the right shell language. REXX is not that, nor is TSO/E.
Bash is about the best I have found, but Perl is wonderous, too bad it
isn't the shell. :-)

   'for all i in *.c'
    do
      emacs -batch -l xyz -u whatever
    endfor
   '
   where xyz has to be written in ELISP. Why not make ELISP the standard
   shell language? That will address all the objections I have raised re.
   emacs/UNIX.

For some people Emacs is the standard shell... I know many people who
have /usr/local/bin/emacs as thier shell in /etc/passwd around here.
Also, Elisp is powerful language, and sicne most machines don't handle
cons cells natively, except Lisp machines :-), where Lisp is the
shell, it is ineffecient to run a GC all the time.

   >This is false garbage.  call-process doesn't create a shell, it
   >simply forks and execs the process directly.

   I meant a process.

Then say it.  A process involved little resource, where as a shell
would require 2 processes to be spawned.  There is a big difference.

   Which Operating Systems and why is it impossible? If so, there is
   something wrong with the OS design.

Why incure the overhead of making the shell handle execution, when
using a one line system call, you can do exactly what the shell would
do?  Most 'modern' OSs, which excludes IBM mainframes, do not allow a
call back to the shell which has been suspended for execution of a
command, that's why you can always throw up another shell.

   >   I can go on..but the point is that there are some user
   >   interfaces that should have been incorporated into emacs to
   >   make it more user-friendly and they can be found in editors
   >   from non-UNIX world.

   >I think the point is that you don't know what you're talking about.

Agreed... You come from a world that the GNU project abhores, in my
opinion.  We are attempting to build a UN*X clone, not an IBM
mainframe clone.  Emacs has been around a long time, and in most
people's opinion, who have spent time with it, is the best editor ever
(maybe TECO ;-) ). 

I do not believe you understand the ideas behind Emacs.  Emacs is a
TEXT EDITOR, not a WORD PROCESSOR.  If you wish to do fancy formatting
(beyond code), use TeX or Texinfo, or something like that that does
real typesetting.  Kludging Emacs to handle stuff like that is
pointless, it's not what Emacs is designed for.  Emacs is an editor
first and formost.

Chris
--
| Chris Petrilli
| petrilli@gnu.ai.mit.edu
| I don't even speak for myself.