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

Marco Antoniotti wrote:
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 also know what you're glossing over.

What is the result of:

1. / 0

is it an integer divide by zero exception or the special floating point
infinity?

The static error you describe forces the programmer to clarify the code
before the program can be run. Claiming that to be "mildly stupid" is
mildly stupid. Implying that floats and ints should be interchangeable when
they have wildly different properties is considerably more stupid.

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?

If you are trying to compare my OCaml code with your Lisp translation then
your Lisp translation is wrong.

And why?

Because you used the wrong numbers. Specifically, you used decimals that
happen to have exact representations in machine-precision floating point so
the results happen to be equal for that particular case.

Or isn't this just the the well known "thou shall not compare two floating
point numbers?"

Which is part of my point that Don Geddis' argument that Lisp's integers
make it more suitable for mission critical applications in the specific
context of rockets is completely ridiculous because floats are the source
of far more errors than ints and Lisp is no better than C in that respect.

If someone said "Mathematica is better because it bundles interval
arithmetic" then I would be inclined to agree.

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.

Mathematica is similar to Lisp in many ways but it does use vectors entirely
rather than cons cells. I think the Lisp community have a huge amount to
learn from Mathematica because it addressed so many of Lisp's deficiencies.

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 don't know what you mean by "a language on its own" but F# is being
productized by Microsoft and placed along C# and VB as their next
generation language for .NET.

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.

F# is MLish, yes.

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

F# is the next C# and it does have pattern matching.

Scala is considered to be the next Java by many of its proponents and it
also has pattern matching.

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.

Camlp4 is a preprocessor (just like Lisp's macros) but it can be used
interactively and it is part of the core OCaml distribution.

So OCaml is actually every bit as extensible as Lisp and, of course, many
people have published extensions for it. For example, Martin Jambon has
extended OCaml's ordinary pattern matching to also support regular
expression matching, by writing a camlp4 syntax extension:

http://martin.jambon.free.fr/micmatch-howto.html

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

You are grossly underestimating the effort required to Greenspun modern
language features.

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?

Every single statement you have made about OCaml's extensibility has been
completely wrong. You appear to have read and misunderstood the Wikipedia
page without actually trying to find how people have already used camlp4 to
do all of the things that you are claiming to be impossible.

Again, you are proving my point about Lispers. You should get out there and
learn more about modern languages by actually using them. Once you know the
facts you will be able to substantiate your arguments but, of course, if
you knew the truth you would not be using Lisp...

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

Relevant Pages

  • Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
    ... amount to learn from Mathematica because it addressed so many of Lisp's ... What do you think Mathematica can learn from Lisp? ... are overestimating the "language merits" of Mathematica as far as its ... go beyond our discussion of Lisp, MLish and pattern matching. ...
    (comp.lang.lisp)
  • Re: ILC2005: McCarthy denounces Common Lisp, "Lisp", XML, and Rahul
    ... >> the language should be available to users. ... In the design of Common Lisp, I asked Dave Moon (one of the architects ... Now, there are good kinds of low-level, like the way that floats are ...
    (comp.lang.lisp)
  • 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: Whats the best language to learn...
    ... on processors designed to run Lisp and Lisp OSes. ... byte-addressed memory, has native support for variable-sized value types, ... popular OO language, rather a language about like that of Delphi would have ... lisp, java, ruby, etc. ...
    (comp.programming)
  • Re: Program compression
    ... TM> supported by your favorite language (LISP) are good concepts. ... then call the Java compiler to compile that source file to a Class ... TM-STC> Since static type checking makes run-time type checks unnecessary, ...
    (comp.programming)