Comment by lispm | Hacker News Reader

Comment by lispm | Hacker News Reader

Parent Full thread

As you can see from the doc, functional programming is completely underspecified in Mathematica. How does lexical binding / closures /... work? I fear these are all dirty hacks and performing very poorly. Why isn't it better specified? Because Wolfram wants to prevent competition? From here it looks like the implementation is the spec. There is no rigorous language spec, which is quite poor for a language used in Mathematics.

The compile function spec -as little as is there - does not make me happy as a Lisp programmer. The compile function has only very limited capabilities...

From the doc:

> Compiled code does not handle numerical precision and local variables in the same way as ordinary Wolfram Language code.

This is a huge warning sign. It does not even say HOW it works differently. Mathematica from a language implementation point is stuck in the 70s... They have fancy stuff on top, but the basic language looks broken. The Lisp and FP communities faced these implementation and semantics problems (like lexical binding, having an interpreter and compiler with same semantics, implementing optimizing compilers for the full language, ...) in the 70s and 80s. Scheme, ML and other languages showed how this stuff should be specified and implemented.

> As you can see from the doc, functional programming is completely underspecified in Mathematica.

That inference is not correct. That doc is one of many hundreds of 'guide pages' that collect together various functions by domain/concern. It's not meant to be the exhaustive proof of "WL is a modern functional programming language with all the features you expect".

> I fear these are all dirty hacks and performing very poorly.

Why do you fear that? From my experience we're about on a par with CPython.

> Why isn't it better specified?

There is a gargantuan library of documentation, available both offline and online, that covers every area of the language, including core language areas like scoping.

> Why isn't it better specified? Because Wolfram wants to prevent competition?

We don't need to obscure how the language works to prevent competition, we can rely on the fact that it would take hundreds of engineers (with a full spectrum of domain knowledge) a decade to replicate the kind of functionality we have.

The exact thing you seem to want, which is "what does a LISP programmer need to know about WL?" doesn't exist, but perhaps it should! It might make sense to add Block, Module, and With to the functional programming page, though the Scoping Constructs guide [1] is the place to start understanding our scoping.

> > Compiled code does not handle numerical precision and local variables in the same way as ordinary Wolfram Language code. > This is a huge warning sign.

Again, you seem to have little patience for documentation. The notes in the function page are a summary of salient points, rather than an essay about every detail. The tutorial goes into more depth [2].

And specifically: precision tracking is something almost no-one else does. BLAS can't do it -- so yes, the semantics have to change if you want speed. Lisp and the FP community would have the same problem if they represented quantities with the generality we do.

[1] http://reference.wolfram.com/language/guide/ScopingConstruct...

[2] http://reference.wolfram.com/language/tutorial/CompilingWolf...

> The exact thing you seem to want, which is "what does a LISP programmer need to know about WL?" doesn't exist,

I would want a spec of the basics of the language. Not a collection of vague statements and some examples.

> The tutorial goes into more depth [2].

A tutorial goes into more depth than the main documentation? Really?

If you read the tutorial, you see that the compiler is far from being able what a modern compiler for Lisp, SML, OCAML or Haskell does. The Wolfram compiler is mostly there to speed up some simple numeric processing. As you can see the parameters need to be numbers or 'logical variables'.

> compilation can speed up execution by a factor as large as 20.

Which is completely vague...

> For more complicated functions, such as BesselK or Eigenvalues, most of the computation time is spent executing internal Wolfram Language algorithms, on which compilation has no effect.

That more or less shows how primitive the compiler is.

> Compile can handle approximate real numbers that have machine precision, but it cannot handle arbitrary‐precision numbers

...

> An important feature of Compile is that it can handle not only mathematical expressions, but also various simple Wolfram Language programs.

Wow.

> Thus, for example, Compile can handle conditionals and control flow structures.

Really.

I want a good "what does a LISP programmer need to know about WL?" :-)---or, rather, a nice, conversational tutorial, a "WL for Lisp programmers" that discusses not just the things you need to know, but the underlying philosophical similarities and differences and the pitfalls you're liable to encounter if you try to make the transition.

(I also want an open-source implementation, but it would seem that isn't on the table.)

WL is similar to Python: it is predominantly an interpreted language. Where that becomes a problem, we wrap other libraries, or move small chunks of code into a VM to avoid the cost of the evaluator, or to C and then compile that (a rather roundabout way of doing things that will improve when we move to LLVM).

But as I said before, CPython is a close analogy for where we are at. What we don't have yet is the equivalent of PyPy. Still, if you were to make this kind of dismissive critique against the maintainers of CPython, I think most people would find it kind of silly.

Also, one should note that this documentation was written during an era when perhaps most of Mathematica's user base were people doing math, for which the primary use for compilation was things like plotting, numeric solving, and so on. The language of the tutorial reflects that heritage. At this point we should probably rewrite it.

If there is something like a Wolfram Language, it better should be documented like other 'programming' languages. The core of the language is underspecified. Even the small Scheme standard is much more rigorously specified, including an attempt on a formal semantics.

Reply on news.ycombinator.com