6 ms·

The content on the pages clearly explain the differences. Mathematica is a symbolic language based on 'rewriting' There are other examples - Prolog would be an

by lispm 3y ago

The content on the pages clearly explain the differences. Mathematica is a symbolic language based on 'rewriting' There are other examples - Prolog would be an example, a logic language. Also most other computer algebra systems are in this category, similar to Mathematica: Macsyma/Maxima, Axiom, ... > WolframLang has all the characteristics of LISP It has many, but there are a lot of differences, too. The big difference is the actual engine. Mathematica is based on a 'rewrite system'. It translates expressions by applying rewrite rules. Lisp evaluates expressions either based on an interpreted evaluator or by evaluating compiled code. Lisp has macros, but those can be transformed before the code is compiled or running. The practical effect is that in many Lisp implementations usually all code is compiled, incl. user code. Mathematica uses C++ then. Most of the UI in Mathematica is implemented in C++, where many Lisp systems would implement that in native compiled Lisp. Thus the computation is very different. Using a rewrite system for programming is quite clunky and inefficient under the hood. A simple example would be to look how lexical closures are implemented. Another difference is that Mathematica does not expose the data representation of programs to the user all the time, where Lisp programs are also on the surface written as s-expressions (aka symbolic expressions) in text. The linked page from the Mathematica book also claims that Mathematica is a higher level language. Which is true. Lisp is lower level and languages like the Wolfram Language can be implemented in it. That's one of its original purposes: it's an implementation language for other ('higher-level') languages. Sometimes it already comes with embedded higher-level languages. CLOS + MOP (the meta-object protocol) would be an example for that.

mathisfun123 3y ago
> Another difference is that Mathematica does not expose the data representation of programs to the user all the time, where Lisp programs are also on the surface written as s-expressions (aka symbolic expressions) in text. I have already addressed this: FullForm https://reference.wolfram.com/language/tutorial/Expressions.html#14609 https://reference.wolfram.com/language/tutorial/Expressions.... >Thus the computation is very different. Using a rewrite system for programming is quite clunky and inefficient under the hood. A simple example would be to look how lexical closures are implemented. You're skimming a couple of paragraphs without actually knowing much about Mathematica. It's absolutely not the case that Mathematica is purely a redex system; it's just that it's very good at beta reduction because it has a strong focus on CAS features.
- lispm 3y ago
  > I have already addressed this: FullForm No you haven't addressed it. The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation. > it's just that it's very good at beta reduction and not so good at compiling code... https://reference.wolfram.com/language/ref/Compile.html https://reference.wolfram.com/language/ref/Compile.html See "Details and Options"
  - mathisfun123 3y ago
    >The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation. I have no clue what you're talking about - it's an available primitive and I use it all the time. >and not so good at compiling code... Lol I am 100% sure that the majority of lisps cannot be aot compiled.
    - lispm 3y ago
      > I have no clue what you're talking about That's not good. Try again. In Lisp adding two numbers looks like this is source code: (+ 1 2) CL-USER 41 > (+ 1 2) 3 If I quote the expression and evaluate it, the result is (+ 1 2) CL-USER 42 > (quote (+ 1 2)) (+ 1 2) Thus in Lisp the textual representation of code and code as data are the same. Not so in "Wolfram Language": a + b has a FullForm which looks differently. The user does not write ALL of the code in FullForm notation. Source notation a + b FullForm Plus[a, b] Lisp: Source notation (+ a b) FullForm (+ a b) Can you see the difference? > Lol I am 100% sure that the majority of lisps cannot be aot compiled. I'd expect that they can. That's a feature since 1962. SBCL for example does AOT compilation by default, always. * (disassemble (lambda (a) (+ a 42))) ; disassembly for (LAMBDA (A)) ; Size: 36 bytes. Origin: #x7006DC83B4 ; (LAMBDA (A)) ; B4: AA0A40F9 LDR R0, [THREAD, #16] ; binding-stack-pointer ; B8: 4A0B00F9 STR R0, [CFP, #16] ; BC: EA030CAA MOV R0, R2 ; C0: 8B0A80D2 MOVZ R1, #84 ; C4: 3CAA80D2 MOVZ TMP, #1361 ; C8: BE6B7CF8 LDR LR, [NULL, TMP] ; SB-KERNEL:TWO-ARG-+ ; CC: DE130091 ADD LR, LR, #4 ; D0: C0031FD6 BR LR ; D4: E00120D4 BRK #15 ; Invalid argument count trap NIL Looks like native ARM64 code to me.

by lispm 3y ago

mathisfun123 3y ago

> Another difference is that Mathematica does not expose the data representation of programs to the user all the time, where Lisp programs are also on the surface written as s-expressions (aka symbolic expressions) in text. I have already addressed this: FullForm https://reference.wolfram.com/language/tutorial/Expressions.html#14609 https://reference.wolfram.com/language/tutorial/Expressions.... >Thus the computation is very different. Using a rewrite system for programming is quite clunky and inefficient under the hood. A simple example would be to look how lexical closures are implemented. You're skimming a couple of paragraphs without actually knowing much about Mathematica. It's absolutely not the case that Mathematica is purely a redex system; it's just that it's very good at beta reduction because it has a strong focus on CAS features.

lispm 3y ago
> I have already addressed this: FullForm No you haven't addressed it. The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation. > it's just that it's very good at beta reduction and not so good at compiling code... https://reference.wolfram.com/language/ref/Compile.html https://reference.wolfram.com/language/ref/Compile.html See "Details and Options"
- mathisfun123 3y ago
  >The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation. I have no clue what you're talking about - it's an available primitive and I use it all the time. >and not so good at compiling code... Lol I am 100% sure that the majority of lisps cannot be aot compiled.
  - lispm 3y ago
    > I have no clue what you're talking about That's not good. Try again. In Lisp adding two numbers looks like this is source code: (+ 1 2) CL-USER 41 > (+ 1 2) 3 If I quote the expression and evaluate it, the result is (+ 1 2) CL-USER 42 > (quote (+ 1 2)) (+ 1 2) Thus in Lisp the textual representation of code and code as data are the same. Not so in "Wolfram Language": a + b has a FullForm which looks differently. The user does not write ALL of the code in FullForm notation. Source notation a + b FullForm Plus[a, b] Lisp: Source notation (+ a b) FullForm (+ a b) Can you see the difference? > Lol I am 100% sure that the majority of lisps cannot be aot compiled. I'd expect that they can. That's a feature since 1962. SBCL for example does AOT compilation by default, always. * (disassemble (lambda (a) (+ a 42))) ; disassembly for (LAMBDA (A)) ; Size: 36 bytes. Origin: #x7006DC83B4 ; (LAMBDA (A)) ; B4: AA0A40F9 LDR R0, [THREAD, #16] ; binding-stack-pointer ; B8: 4A0B00F9 STR R0, [CFP, #16] ; BC: EA030CAA MOV R0, R2 ; C0: 8B0A80D2 MOVZ R1, #84 ; C4: 3CAA80D2 MOVZ TMP, #1361 ; C8: BE6B7CF8 LDR LR, [NULL, TMP] ; SB-KERNEL:TWO-ARG-+ ; CC: DE130091 ADD LR, LR, #4 ; D0: C0031FD6 BR LR ; D4: E00120D4 BRK #15 ; Invalid argument count trap NIL Looks like native ARM64 code to me.