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

Marco Antoniotti wrote:
On Jul 12, 4:00 pm, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
Don Geddis wrote:
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.

Except those rules do not apply in the context of floating point arithmetic,
e.g. associativity:

# (0.1 +. 0.2) +. 0.3 = 0.1 +. (0.2 +. 0.3);;
- : bool = false

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.

Mathematica abandoned s-exprs and is a resounding success.

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.

All such paths are strewn with failures. That is an inevitable consequence
of progress.

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

Look at Scala and F#.

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.

That is not true. Look at camlp4, for example. Then look at the F# code dom.
Finally, consider what it takes to create a "fresh compiler" when the
source to the original is available.

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?

Again, you are just proving my point. You are claiming to be familiar with
alternatives whilst simultaneously making false statements about them and
then claiming that Lisp is Blub.

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

Relevant Pages

  • Re: Why Lisp supposedly "sucks for game development"
    ... of source code) was written in GOAL (Game Object Assembly Lisp), ... advantages of having a custom compiler. ... then "suspend" and allow other code to execute. ... of the top ten Lisp programmers in the world) wrote GOAL. ...
    (comp.lang.lisp)
  • Re: Chestnut Lisp translator
    ... Can't say, but superficially there's a big, clear difference in syntax ... between the lisp family and what most programmers will have seen before: ... and it also doesn't fit with that collection of languages. ... Maybe we need a text along the lines of "lisp for programmers from the ...
    (comp.lang.lisp)
  • Re: static, dynamic and implicitely typed languages
    ... programming languages but nothing about theses. ... In some decades a compiler might be more intelligent than any human ... Lisp then perhaps lisp community is going to shring. ...
    (comp.lang.lisp)
  • Re: LISPPA
    ... difficult to receive good criticisms about lisp by people who know ... that powerful languages have, which may not be problems with less ... the programmer must add extra code -- type annotations -- to support ... the compiler is just another ...
    (comp.lang.lisp)
  • Re: demonic problem descriptions
    ... floating point, fixed point, and rationals. ... Lisp doesn't offer the one that's limited, inexact, and slow. ... Most other languages in use today have chosen to only provide ... > programmers have to know how to use floats. ...
    (comp.lang.lisp)