1. Forum
  2. Usenet
  3. COMP.LANG.LISP

  • CL Lickspittles

    From B. Pym@21:1/5 to All on Sun Sep 29 00:35:53 2024
    XPost: comp.lang.scheme

    (let ((x 5))
    (mapcar (function (lambda (y) (+ x y)))
    '(3 5 7)))
    (8 10 12)

    Programmers who are human get tired of typing and seeing
    "(lambda" as an indication of an anonymous function. They
    wish that something shorter like "(fn" could be used.
    However, disciples of CL are willing and eager to make it even
    longer by putting "(functon" in front of it---despite the fact
    that doing so is a pleonasm; "lambda" is a macro that expands
    to "(function (lambda".

    CL lickspittles always try to make their code as ugly
    and bloated as possible.

    Daniel Weinreb, 24 Feb 2003:

    Having separate "value cells" and "function cells" (to use
    the "street language" way of saying it) was one of the most
    unfortunate issues. We did not want to break pre-existing
    programs that had a global variable named "foo" and a global
    function named "foo" that were distinct. We at Symbolics
    were forced to insist on this, in the face of everyone's
    knowing that it was not what we would have done absent
    compatibility constraints. It's hard for me to remember all
    the specific things like this, but if we had had fewer
    compatibility issues, I think it would have come out looking
    more like Scheme in general.

    Jeffrey M. Jacobs:

    The CL effort resembles a bunch of spoiled children,
    each insisting "include my feature or I'll pull out, and
    then we'll all go down the tubes". Everybody had vested
    interests, both financial and emotional.

    Jeffrey M. Jacobs:

    CL is a nightmare; it has effectively killed LISP
    development in this country. It is not commercially viable
    and has virtually no future outside of the traditional academic/defense/research arena.

    Bernard Lang:

    Common Lisp did kill Lisp. Period. (just languages take a
    long time dying ...) It is to Lisp what C++ is to C. A
    monstrosity that totally ignores the basics of language
    design, simplicity and orthogonality to begin with.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From usuario@21:1/5 to All on Thu Oct 3 20:05:02 2024
    XPost: comp.lang.scheme

    El Sun, 29 Sep 2024 00:35:53 -0000 (UTC), B. Pym escribió:

    (let ((x 5))
    (mapcar (function (lambda (y) (+ x y)))
    '(3 5 7)))
    (8 10 12)

    Programmers who are human get tired of typing and seeing "(lambda" as an indication of an anonymous function. They wish that something shorter
    like "(fn" could be used. However, disciples of CL are willing and eager
    to make it even longer by putting "(functon" in front of it---despite
    the fact that doing so is a pleonasm; "lambda" is a macro that expands
    to "(function (lambda".

    CL lickspittles always try to make their code as ugly and bloated as possible.

    Daniel Weinreb, 24 Feb 2003:

    Having separate "value cells" and "function cells" (to use the "street language" way of saying it) was one of the most unfortunate issues. We
    did not want to break pre-existing programs that had a global variable
    named "foo" and a global function named "foo" that were distinct. We at Symbolics were forced to insist on this, in the face of everyone's
    knowing that it was not what we would have done absent compatibility constraints. It's hard for me to remember all the specific things like
    this, but if we had had fewer compatibility issues, I think it would
    have come out looking more like Scheme in general.

    Jeffrey M. Jacobs:

    The CL effort resembles a bunch of spoiled children,
    each insisting "include my feature or I'll pull out, and then we'll all
    go down the tubes". Everybody had vested interests, both financial and emotional.

    Jeffrey M. Jacobs:

    CL is a nightmare; it has effectively killed LISP development in this country. It is not commercially viable and has virtually no future
    outside of the traditional academic/defense/research arena.

    Bernard Lang:

    Common Lisp did kill Lisp. Period. (just languages take a long time
    dying ...) It is to Lisp what C++ is to C. A monstrosity that totally ignores the basics of language design, simplicity and orthogonality to
    begin with.

    Well, I'd say Scheme and CL are both today equally bloated.
    Scheme looks minimal, but the truth is that in order to be
    usable, you depend on tons of modules.
    You'll need either SRFI's and/or ICE-9's on Guile to do anything decent;
    even for SICP you need two SRFI's (203 and 216) to do the exercises
    under Chicken Scheme.

    With Scheme you are lost on a sea of submodules and SRFI's.

    With CL you might use closer-mop from QuickLisp if you like
    objects to behave universally the same and that's it.

    With MCClim your GUI will work on most libre CL implementations,
    and QuickLisp will handle any dependency seamlessly. Fire and forget.

    Also, for the 3 major books, a plain CL compiler (SBCL, CCL or ECL)
    will work as is.

    - Common Lisp: An Interactive Approach <-novices
    - A Gentle Introduction to Symbolic Computation <-advanced
    - Paradigms On Artifical Intelligence Programming <- almost expert

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to usuario on Sun Oct 6 03:39:57 2024
    XPost: comp.lang.scheme

    On Thu, 3 Oct 2024 20:05:02 -0000 (UTC), usuario wrote:

    Well, I'd say Scheme and CL are both today equally bloated.
    Scheme looks minimal, but the truth is that in order to be usable, you
    depend on tons of modules.

    So what would you consider to be a usable language that wasn’t “bloated”?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)