Re: SBCL is now faster than Java, as fast as Ocaml, and getting better

On Jul 12, 4:00 pm, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
Don Geddis wrote:

The parentheses in Lisp do not occupy cognitive effort. Real Lisp
programmers (but perhaps not you) don't really even see them.

Real Lisp programmers (not you) recognise the inherent flaws in the language
and leave Lisp to use any of the better, more modern alternatives.

Last I checked a lot of us are still hanging around here :)

So, yes, it is appropriate to "ignore" the parentheses, when estimating
how complex a piece of Lisp code is.

Let's just see what that does. Consider this Lisp:

(define Y
  (lambda (f)
    (let ((future
            (lambda (future)
              (f (lambda (arg)
                   ((future future) arg))))))
      (future future))))

This is what you want to count:

define Y lambda f let future lambda future f lambda arg future future arg
future future

From which it is clearly impossible to decipher a working program. So your
point is obviously wrong. In reality, deliberately miscounting the number
of tokens was just clutching at straws. A desperate attempt to make Lisp
look less stupid.

let val x = 40 + 2.0;;

yielding an error is what I call mildly stupid. :) After all we all
know the rules about '+' since junior high.


And the expert Lisp programmers who invented Dylan, OCaml, SML...

Ahem, Dylan is a relatively good thing, but it is CL down to the
core. Cleaned up as much as you want, but that is what it is. And it
may be that is was Java to make Dylan wimper. Moreover, it has been
accepted that Dylan Big Mistake was to abandon S-expr syntax. As per
the ML lineage, it started earlier than current Lisp and it started in
the very mathematic/logic oriented world. And even that is a path
strewn with somewhat dead bodies. How many people remember OBJ?

People with no experience  
in the language believe (incorrectly) that the parentheses require
cognitive effort and make the code more complex.

So you are saying that people who do not even know Lisp complain about its
deficiencies? Has it occurred to you that people who do not even know Lisp
cannot be aware of its deficiencies?

ACTUAL lisp programmers do not cite the parentheses as a disadvantage.

Circular argument: you just defined programmers who cite superfluous
parentheses as a disadvantage as non-Lisp programmers.

So what you're really saying is that people who don't know any better don't
complain. I'd agree with that but it applies just as much to the tiny
lingering Lisp community as it does elsewhere. Observe how Lispers not only
fail to understand the benefits of pattern matching but are even oblivious
to its increasingly widespread use.

I have not seen pattern-matching pop up in Java or C#...

(Conversely, most cite them as an advantage, particularly when editing
code.)

Because they are still using text editors because they are stuck in the 20th
century.

In fact, from time to time various lisp programmers embark on a syntax
change to lisp, to eliminate the parentheses, spurred by the same error
you make here. Each time, they eventually realize that nobody cares about
their efforts, and they were wrong to believe that they were solving a
real problem in the language.

That is also obviously wrong. The creators of the ML family of languages
embarked on that journey and they not only completed it, creating a new
family of languages without superfluous parentheses, but the fruits of
their labour (OCaml and F#) are now used by more people than Lisp ever was.

Your last sentence can only be greeted with a "maybe". As per the
first part, it is mostly true. Yet, there is *no* way to add new
language features to such languages: any new "language" in the style
of MLish syntax needs a fresh "compiler". Witness the interesting
PADS/ML work.

The only way you could possibly have remained oblivious to this is by
burying your head in Lisp and not learning about the alternatives. So you
just made my point. Thank you.

... and telling people who chose to stick to CL (also after having
used ML/Haskellish systems and/or written other languages' compilers
and systems) that they are stupid where is getting you?

Cheers
--
Marco


.

Relevant Pages

  • Re: I finally understand why Im not allowed to use Lisp
    ... language is powerful syntax and abstractions. ... I heard it when I used Lisp for ANYTHING. ... author of that bit of code was one of their /best/ programmers and I would do ... Management assumes that any software will have high maintenance costs. ...
    (comp.lang.lisp)
  • Re: (Prolog + LISP + Erlang) with integration issues versus C++
    ... advantage by always using appropriate tools, instead of C++/Java all the time, then you'd better deal with hiring some more language-open programmers. ... Ask Lisp compilers how "supercede" is spelt. ... That means writing everything in one language at all practical. ... My ideal for the future is to develop a filesystem remote interface and then have it implemented across the Internet as the standard rather than HTML. ...
    (comp.lang.lisp)
  • Re: Python syntax in Lisp and Scheme
    ... applications recreating Lisp, ... trying to morph into a language with the sophistication of Lisp. ... As for non-professional programmers, the next question is whether a good ...
    (comp.lang.python)
  • Re: Python syntax in Lisp and Scheme
    ... applications recreating Lisp, ... trying to morph into a language with the sophistication of Lisp. ... As for non-professional programmers, the next question is whether a good ...
    (comp.lang.lisp)
  • Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
    ... Still requires explicit deconstruction in Lisp but not in OCaml. ... Only if you ignore the superfluous parentheses that make up most of the ... expression in some language. ... around comma-separated lists, when those lists are to be treated as a ...
    (comp.lang.lisp)