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

Don Geddis wrote:
Jon Harrop <jon@xxxxxxxxxxxxxxxxx> wrote on Sat, 12 Jul 2008:
Kaz Kylheku wrote:
62 tokens.

Only if you ignore the superfluous parentheses that make up most of the
Lisp code, which is absurd because they are essential in Lisp.

What ought to matter is the cognitive effort required to write or
understand the code.

But we cannot quantify that so we quantify related features like lines,
bytes, non-whitespace bytes and tokens. Lisp is grossly verbose by all of
those objective metrics.

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.

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.

Terseness isn't everything, and let's not forget that it is one dominant
attribute of obfuscated programming contest entries.

You may have noticed that almost all programmers disagree with you: huge
numbers of superfluous parentheses being one of the most complained about
disadvantages of Lisp.

Complained about ... by NON-lisp programmers.

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

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.

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

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.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
.

Relevant Pages

  • Re: CollabRx seeks brilliant engineers for an excellent e-science adventure
    ... belief that lisp programmers are smarter/better. ... Java or PHP programmers. ... a type of language that attracts a personality that meets my perceptions ...
    (comp.lang.lisp)
  • 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)