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

On Jul 12, 6:03 pm, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
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

Come on. You know what I am getting at. I can write very fast and
"type-correct" CL code in implementation X using

(low-level-stuff::*. 40.0 2.0)

Moreover

CL-USER 40 > (= (+ 1.0 (+ 2.0 3.0)) (+ (+ 1.0 2.0) 3.0)) ; LWM on an
Intel Mac.
T

So: which is "correct"? LWM or Ocaml? And why? Or isn't this just the
the well known "thou shall not compare two floating point numbers?"




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.

Maybe. Deep, deep down, at least until some time ago, mathematica was
all Conses. I have not checked it lately.

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

Scala is a language on its own as is F#. I have not played around
with Scala (which looks like a "lets-look-like-C" language), but I
have been playing with F#, which is well integrated within MSVS and it
is nice to use. But that is a MLish language.

You are not seeing pattern matching popping up in Java 7 (is it?).
Same for the next C#.

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.

Nope. camlp4 does not count as an argument. It is a preprocessor
outside the core language. I do not know F# dom, but I would be
surprised if it were different.

Put it this way. Get me away from actual work and saturday afternoons
writing on CLL :) and I will get you an extended CL written *in* CL
that did pattern matching (avec pattern compilatiòn). Bottom line:
you can throw mud at Lisp... it still looks like a ball of mud. You
can't throw mud at OCaml, it'll just look like a muddy camel :) (Pun
intended and waiting for the unescapable witty retorts :) ).

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.

What false statements am I making? (The camlp4 topic is one were we
obviously disagree, but I would not call that "misrepresenting").

We may look at certain aspects of the languages differently, but I am
not misrepresenting MLish languages at all. At least I do not think I
do. I reserve my sarcasm for true SLDJs :)

Cheers
--
Marco

.

Relevant Pages