Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp]) 
Author Message
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

Quote:


> | Being able to build an executable program which can run on different
> | computers that don't have Lisp is not just a commercial concern.

>   but if you want to run it on such computers, won't they _get_ a Lisp?
>   ...
>   I regard the .fasl files as Lisp's "executables",

Excellent points.

Certainly within the freeware arena, they are no less painful to start
than x windows is to get running on linux.  Some people might think
starting a program from a shell instead of clicking with a mouse means
it's not a "real" program, but by that argument, linux out of the box
is such a system.  I still have to type startx manually because I haven't
found the place to edit in the thing that says xdm should run by default
at startup.  [hints by private e-mail are welcome].



Wed, 24 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

Quote:



[my blathering about markets deleted]

Quote:
>   this assumes that the issue in question is sufficiently important that
>   the open market will be where the decisions are made.

Yes, I agree this is an issue.  I don't think the market will decide small
things well--only coarse-grain things.  But many of these discussions
are over "What's Really Important" and I do think the market's failure to
spawn new variant products over certain issues is a quasi-proof that those were
not the key things people saw as important.


Wed, 24 Oct 2001 03:00:00 GMT  
 Newbie question

Quote:

> I stand corrected.  However, beside being interesting, why should a
> X *server* be built in CL at this time in history?

No reason.  The original point was that someone said you couldn't
write a C compiler in Lisp easily and I pointed out that not only had
this been done (and fortran, Pascal), but that the compiler was
competent enough to compile the MIT X server which worked presumably
reasonably well considering the HW it ran on.

--tim



Wed, 24 Oct 2001 03:00:00 GMT  
 Newbie question

Quote:

> The point is probably this: A C++/Java compiler cannot catch all
> errors, especially not design or logical errors, but at least it
> catches most simple errors like typos, passing the wrong number of
> arguments, passing a wrong argument, etc.  With existing Lisp
> implementations many such errors are detected only at runtime even
> when declarations are used. This is less problematic with mainline
> code which is likely to be run by the developer anyway, but typos in
> sections of the source code that are less frequently run have the
> habit of crashing in the hands of a user, or the QA department if
> you're lucky. Yes, you should test all your code, but the kind of bug
> we're talking about is often introduced by changes that are so
> 'obvious' that many developers don't imagine a bug may have been
> introduced.

Again, I want to say: this is a good theoretical point, but do you
know of any evidence that it causes large Lisp systems to be less
robust than large C++ systems.  I know of none, but I have not looked
that hard.

--tim



Wed, 24 Oct 2001 03:00:00 GMT  
 Newbie question

Quote:

> Others have mentioned CMU CL as well, I'll take a look at this.
> Unfortunately, it won't help in my current situation where we depend
> on third-party packages which are not available for CMU CL, not to
> mention a heavy investment in our own existing code.

If you care that deeply about static checking of things like argument
counts, I'm pretty surprised you haven't taken one of the
publically-available who-calls things and modified it to warn you
about all this stuff.  Lisp is remarkably flexible in this regard.
test harnesses are another good thing that you can write pretty
trivially in Lisp but are way hard in C++ say.

--tim



Wed, 24 Oct 2001 03:00:00 GMT  
 Newbie question

Quote:

> LISP's object-oriented paradigm is powerful and yet... It's essentially
> dynamic operator overloading, which is about as interesting to an object
> modeller as a stack of bricks.  Although this is certainly only an
> opinion and perhaps a trend, object orientation is centered on message
> passing, while LISP's object orientation is based on function calls
> (still).  I won't say its not USEFUL, but its not attractive, and its
> not a step forward unless you are writing "toy" applications.

Please, read some history.  Lisp's object-orientation is based on
function-calling *now*.  Once upon a time when Lisp was younger there
were systems based on explicit message passing.  Unfortunately message
passing is not as general as function calling because you can only
pass messages to one object at a time without twisting your brain so
hard it breaks.

And if you like message passing such a lot just implement it, it's not
exactly hard:

    (defmacro define-message (name &optional (signature '(arg)))
      `(progn
        (unless (fboundp 'name)
          (defgeneric ,name ,signature))
        (defvar ,name #',name)
        ',name))

    (declaim (inline send))
    (defun send (thing message &rest args)
      (declare (dynamic-extent args))
      (apply thing message args))

--tim



Wed, 24 Oct 2001 03:00:00 GMT  
 Newbie question

Quote:

>  (defun foo (list x)
>    (declare (type cons list)
>             (type integer x)
>             (values integer))
>    <body>)
> I have always wondered why this is not an accepted solution (modulo
> syntax of course). I sort of understand that having simply VALUES as a
> 'declaration identifier' (3.3.3 ANSI CL) may cause some problems at
> the DECLAIM/PROCLAIM level (it wouldn't be clear what the declaration
> would apply to), but the idea seems correct.  CMUCL has an
> implementation of this scheme.

There is a slightly trivial but unfortunate problem with this in that
Symbolics CL (and perhaps also the other LispM flavours of Lisp) uses
a VALUES declaration in a different way -- namely to tell the system
what the *names* of the value(s) that the function returns are.  This
is used pervasively by the many tools that tell you things about the
function you're looking at.

I guess it's no longer a real problem that Genera does this, except
that there are still large Lisp systems which have this convention in
them.

--tim



Wed, 24 Oct 2001 03:00:00 GMT  
 Newbie question

Quote:
> People can, with their kids, teach them to click on the "lisp" icon
> and then teach them to type (load "...").  That's all that's needed.

You could just make a .BAT file that does your vendor's equivalent of
"lisp -eval '(load "...")", and then put that on the Windows desktop
with a cute icon, or do the equivalent thing for a Mac or your X
window manager. A 3-year-old might have trouble typing (load "...")
(especially if "( )" are labeled as "[ ]" like on my keyboard (-; ),
but clicking an icon and then using a cute Garnet app with a mouse or
trackball should be doable.

Quote:
> Geez, even getting my linux to run at my house (and it wasn't wholly
> free-there was a substantial media cost) took me a billion (ok, only
> probably a hundred) recompiles of the kernel (which I should
> remember to go delete sometime :-).  Was THAT a barrier to linux
> success?  I just don't think so.

I've only had my own PC since 1997 (before then all I had ever done
with computers was use a little AOL and play a little DOOM on my
friends' DOS/Windows PCs), and about 6 months after I got it I tried
to install Linux. I finally succeeded in getting the partitions done
and my PS/2 mouse working with X and PPP working and the 10 other
show-stoppers that took 3-5 hours a piece of tearful frustration, but
there were still all kinds of problems like "netscape bus errors" that
crashed it and netscape's fonts being ugly as hell (no decent
font-server installed yet) and the netscape 24-bit color bug. In the
end I gave up and kept using a mix of Windows 95 and NT until sometime
in earlier 1998 when I finally got sick enough of Windows that I
installed Debian again and forced myself to use only it (and I
painfully worked my way through K&R's _The C Programming Language_ at
this time and became quite a vi-user/C-hacker for awhile <shudder>).

Other friends of mine have tried to do Linux and failed (even with the
occassional hand-holding and guidance from me and with other luxuries
I didn't have (like a CDROM instead of via FTP)). The point of all
this is that it _IS_ a barrier to Linux success, if you interpret
Linux success to mean getting the largest user-base possible by
migrating Windows-users.

But hey, it's free software... except RedHat charges $50 per
tech-supported license and I hear only has robots on tech-support duty
and replying to emails.

Christopher



Wed, 24 Oct 2001 03:00:00 GMT  
 Newbie question
Quote:

>>>> On the subject of "Re: Reasons for rejecting Lisp (was Re: Newbie questions [Followup to   comp.lang.lisp])"
>>>> Sent on Sat, 08 May 1999 02:48:05 GMT


 >>
 >> Having to pay $3000 to be able to build simple executable
 >> programs is part of that perception.

for CLISP (from the impnotes.html):

<p>There are two different ways to make CLISP "executables" for
Windows platforms.

<ul>
 <li>Associate the "mem" extension with
     "c:\clisp\lisp.exe -m 10M -M %s".
 <li>Associate the "fas" extension with
    "c:\clisp\lisp.exe -m 10M -M c:\clisp\lispinit.mem -i %s".
    Alternatively, you may want to have a function <code>main</code> in
    your files and associate the "fas" extension with
    "c:\clisp\lisp.exe -m 10M -M c:\clisp\lispinit.mem -i %s -x (main)".
</ul>

<p>The clicking on the compiled lisp file (with "fas" extension) will
load the file (thus executing all the code in the file), while clicking
on the CLISP's memory image (with "mem" extension) with start clisp with
the given memory image.

<p>The function <code>(<strong>lisp:saveinitmem</strong>
                       &amp;optional (<var>filename</var> "lispinit.mem")
                       &amp;key :quiet :init-function)</code>
saves the running CLISP's memory to a file.  If the <code>:quiet</code>
argument is not <code>nil</code>, the startup banner and the good-bye
message will be suppressed. The <code>:init-function</code> argument
specifies a function that will be executed at startup of the saved
image.  The starting package of the new image is the one in which you
were when you invoked <code>lisp:saveinitmem</code>.

CLISP is covered by GPL, but you may distribute commercial applictions.
Read the license.

--
Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Why do we want intelligent terminals when there are so many stupid users?



Wed, 24 Oct 2001 03:00:00 GMT  
 Newbie question

Quote:

> I just want to make it very clear that the language is a lot more
> accomodating than that, and as a rule, I doubt there's much of anything
> for which the above statement is true, in the sense that the language
> permits you to build whole new languages inside it (unlike many other
> languages).  And I get frustrated when people push back on the language to
> solve problems they could solve themselves, especially when the "solution"
> is about 1-line long.

I used the inital pseudo-code fragment as an example of the kind of
thing that it would be nice to do. It would be nice IMHO to have some
such succint syntax in a number of differnt situtions, not just in the
top of a defun form.

Most problems could be solved by people in one way or the other, but
then what is the point of standardising stuff. When something is
likely to be widely used it's worth standardising. I may be entirely
wrong, but I suspect that if CL incorporated a standard, succinct
syntax for associating types with symbols and checking the types of
objects then it would get used a lot more then the current, somewhat
verbose, ways of doing this is.



Wed, 24 Oct 2001 03:00:00 GMT  
 
 [ 350 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software