6 ms·

I found that "just using it as a lisp" was a huge pain: the fact that Mathematica is, as you say, "actually a rule rewriting engine" kept causing it to behave i

by cdwhite 12y ago

I found that "just using it as a lisp" was a huge pain: the fact that Mathematica is, as you say, "actually a rule rewriting engine" kept causing it to behave in ways that looked absolutely bonkers if you were trying to think Lisp. The jungle of function-definition-like expressions and the scoping constructs were particularly bad, but I also found that the language & the culture made it far too difficult to write readable code. (I find my eyes glazing over almost immediately when I try to read the Wolfram blog: it's so very hard for me to see the structure of the code.) Perhaps once you become happy with the core principles of the language all of this gets better, but I spent quite a lot of time thinking it and never really got there. Moreover, I never figured out how to do iterations quickly; even once I got the thing working, it was prohibitively slow. Ultimately I re-wrote it in Julia, which was a much better fit for the problem (exact diagonalization of a one-particle tight-binding Hamiltonian). That was a rather more pleasant experience. Now, this is in part about the problem domain: I wasn't doing any symbolic manipulation, though (IIRC) I was comparing my results with those from some symbolic calculations. (Honestly, I feel pretty stupid for having even tried to do it in Mathematica in the first place.) The lesson I learned, though, was to never use Mathematica for anything beyond basic symbolic calculations---integrals, that sort of thing. My experience with Mathematica is sort of like my experience with Fortran: if you stick to the sorts of problems for which it was developed (hard-core numerics for Fortran, symbolic manipulations for Mathematica), it's great, but if you want to do something more general you're in for a rough time. (I understand Fortran's gotten progressively better, but I don't have any experience with anything after 95, and even that was a codebase heavily inflected with 77.)

taliesinb 12y ago
> I found that "just using it as a lisp" was a huge pain: the fact that Mathematica is, as you say, "actually a rule rewriting engine" kept causing it to behave in ways that looked absolutely bonkers if you were trying to think Lisp. Can you give an example of bonkers-ness? The functional parts of Mathematica/WL (by which I mean the equivalents of fold, filter, map, etc) are pretty straightforward and should be quite easy for a Lisp programmer to pick up. See [0]. In fact the suite of functions you have available for basic list and hashmap manipulation is probably one of the richest among languages in this space. Btw, its called a "term rewriting system", not a "rule rewriting engine". > Moreover, I never figured out how to do iterations quickly; even once I got the thing working, it was prohibitively slow. It's a bit odd to criticize a functional programming language for not having super-fast 'for' loops. But you can use Compile[1] if you want to write fast procedural-style code. We also do some amount of JIT compilation. > Ultimately I re-wrote it in Julia, which was a much better fit for the problem (exact diagonalization of a one-particle tight-binding Hamiltonian). That was a rather more pleasant experience. Did you really want to write diagonalization from scratch? Why not use the superfunction Eigensystem [2], which has been honed by many experts over many years? > Now, this is in part about the problem domain: I wasn't doing any symbolic manipulation, though (IIRC) I was comparing my results with those from some symbolic calculations. (Honestly, I feel pretty stupid for having even tried to do it in Mathematica in the first place.) > The lesson I learned, though, was to never use Mathematica for anything beyond basic symbolic calculations---integrals, that sort of thing. That's basically nonsense. Wolfram|Alpha is a multi-million line Mathematica/WL system that goes far beyond symbolic manipulation. As a totally random example, take Facebook social network analysis [3]. Note to self: clearly we aren't making it easy enough to understand what WL can do, especially for people who pick it up for one specific thing. The video helps a bit, and there is the fast introduction for programmers [4]. [0] http://reference.wolfram.com/language/guide/FunctionalProgramming.html http://reference.wolfram.com/language/guide/FunctionalProgra... [1] http://reference.wolfram.com/language/ref/Compile.html http://reference.wolfram.com/language/ref/Compile.html [2] http://reference.wolfram.com/language/ref/Eigensystem http://reference.wolfram.com/language/ref/Eigensystem [3] http://www.wolframalpha.com/facebook/ http://www.wolframalpha.com/facebook/ [4] http://www.wolfram.com/language/fast-introduction-for-programmers http://www.wolfram.com/language/fast-introduction-for-progra...
- lispm 12y ago
  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.
  - taliesinb 12y ago
    > 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/ScopingConstructs.html http://reference.wolfram.com/language/guide/ScopingConstruct... [2] http://reference.wolfram.com/language/tutorial/CompilingWolframLanguageExpressions.html http://reference.wolfram.com/language/tutorial/CompilingWolf...

by cdwhite 12y ago

taliesinb 12y ago

> I found that "just using it as a lisp" was a huge pain: the fact that Mathematica is, as you say, "actually a rule rewriting engine" kept causing it to behave in ways that looked absolutely bonkers if you were trying to think Lisp. Can you give an example of bonkers-ness? The functional parts of Mathematica/WL (by which I mean the equivalents of fold, filter, map, etc) are pretty straightforward and should be quite easy for a Lisp programmer to pick up. See [0]. In fact the suite of functions you have available for basic list and hashmap manipulation is probably one of the richest among languages in this space. Btw, its called a "term rewriting system", not a "rule rewriting engine". > Moreover, I never figured out how to do iterations quickly; even once I got the thing working, it was prohibitively slow. It's a bit odd to criticize a functional programming language for not having super-fast 'for' loops. But you can use Compile[1] if you want to write fast procedural-style code. We also do some amount of JIT compilation. > Ultimately I re-wrote it in Julia, which was a much better fit for the problem (exact diagonalization of a one-particle tight-binding Hamiltonian). That was a rather more pleasant experience. Did you really want to write diagonalization from scratch? Why not use the superfunction Eigensystem [2], which has been honed by many experts over many years? > Now, this is in part about the problem domain: I wasn't doing any symbolic manipulation, though (IIRC) I was comparing my results with those from some symbolic calculations. (Honestly, I feel pretty stupid for having even tried to do it in Mathematica in the first place.) > The lesson I learned, though, was to never use Mathematica for anything beyond basic symbolic calculations---integrals, that sort of thing. That's basically nonsense. Wolfram|Alpha is a multi-million line Mathematica/WL system that goes far beyond symbolic manipulation. As a totally random example, take Facebook social network analysis [3]. Note to self: clearly we aren't making it easy enough to understand what WL can do, especially for people who pick it up for one specific thing. The video helps a bit, and there is the fast introduction for programmers [4]. [0] http://reference.wolfram.com/language/guide/FunctionalProgramming.html http://reference.wolfram.com/language/guide/FunctionalProgra... [1] http://reference.wolfram.com/language/ref/Compile.html http://reference.wolfram.com/language/ref/Compile.html [2] http://reference.wolfram.com/language/ref/Eigensystem http://reference.wolfram.com/language/ref/Eigensystem [3] http://www.wolframalpha.com/facebook/ http://www.wolframalpha.com/facebook/ [4] http://www.wolfram.com/language/fast-introduction-for-programmers http://www.wolfram.com/language/fast-introduction-for-progra...

lispm 12y ago
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.
- taliesinb 12y ago
  > 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/ScopingConstructs.html http://reference.wolfram.com/language/guide/ScopingConstruct... [2] http://reference.wolfram.com/language/tutorial/CompilingWolframLanguageExpressions.html http://reference.wolfram.com/language/tutorial/CompilingWolf...