The editor is very different as well: Mathematica pioneered the notebook concept that was copied by Jupyter, and the Mathematica user experience is still much more comprehensive and tightly integrated than anything else.
For linear algebra, they both use Intel MKL under the hood and get exactly the same performance.
https://stackoverflow.com/questions/34347985/clojure-no-cons...
[1]: You can see the implementation of Clojure's cons cell here: https://github.com/clojure/clojure/blob/clojure-1.9.0/src/jv...
In Lisp cons cells are the basic data type from which lists, trees, cyclic lists, etc. are created,
In Clojure it's not.
Second, in Clojure, you can certainly make lists, trees etc. from cons cells. It's just that vectors and maps are more common.
Third, Clojure is not only a Lisp (https://clojure.org/about/lisp), but an exceptionally good one at that. I'm amazed that some people find that controversial. I love Scheme and Clojure, and the thought that they're not both Lisps -- something immediately obvious to any long-time Lisper like me -- strikes me as patently bizarre. Clojure is not only a very good Lisp, but celebrated among Lispers for facilitating Lisp's rise in popularity in recent years.
Lisp, too, has vectors not made of cons cells.
> make lists, trees etc. from cons cells
It's just that they aren't. Clojure uses persistent lazy sequences not made of cons cells as its basic data structure. And it has strange behavior:
user=> (conj '(1 2) 0)
(0 1 2)
user=> (cons 0 '(1 2))
(0 1 2)
user=> (class (conj '(1 2) 0))
clojure.lang.PersistentList
user=> (class (cons 0 '(1 2)))
clojure.lang.Cons
user=> (class (cons 1 2))
IllegalArgumentException Don't know how to create ISeq from: java.lang.Long clojure.lang.RT.seqFrom (RT.java:542)
Does not look like Lisp to me.
> Clojure is not only a very good Lisp
It's a good programming language, but not a very good Lisp - since it is mostly incompatible and lacks a lot of the usual Lisp features.
Clojure requires that the second element in the pair be an ISeq.
> since it is mostly incompatible and lacks a lot of the usual Lisp features.
I and many others disagree, including Clojure's designers, who designed it as a Lisp. Homoiconicity, macros, S-expressions and FP make a language a Lisp. OCaml and SML are about as different as Scheme and Clojure, yet no one thinks they're not both MLs.
Lisp doesn't have such a requirement and does not have 'ISeqs'.
> I and many others disagree,
That does not make a convincing argument, since you have never used an actual Lisp - as you recently said.
> including Clojure's designers, who designed it as a Lisp.
Derived from Lisp mostly as a blend of FP, Java hosting/integration and Lisp ideas.
> Homoiconicity, macros, S-expressions and FP make a language a Lisp.
Lists are deprecated in Clojure (for maps, sets, vectors, ...), No interpreter, no Lisp down to the metal, no Lisp in Lisp, no images, core Lisp data structures look different, different API, different syntax, impoverished REPL, strange numerics, Java leaking in many places, lots of compromises because of implementing it on top of a not-Lisp-friendly VM, ...
Lisp derived, but Lisp looks & feels a bit different.
For what it's worth, both Wikipedia and the official Clojure website call Clojure a dialect of Lisp (https://en.wikipedia.org/wiki/Lisp_(programming_language), https://clojure.org/)
Chance that it does not work is high.
Now change the code that it runs. Chance that you had to rewrite the code mostly is high.
It's a dialect of Lisp in the sense that it is an incompatible branch / fork with a Java runtime (it's a hosted language) and a bunch of newer functional data structures replacing old-fashioned lower-level stuff from Lisp.
Clojure needs a total and complete rewrite which doesn't only affect the syntax but program logic. Thus Clojure does not run Lisp code. How can it be a Lisp when it does not run Lisp code?
You're welcome to draw the line wherever you want, maybe for you conses are mandatory in a Lisp language but I don't really understand what you hope to gain from this discussion. I might as well say "tail call optimization is absolutely mandatory in any self-respecting Lisp, therefore CL isn't a proper Lisp dialect".
This is effectively the same level of discussion as a Java programmer saying that C++ isn't "true OOP" or an Haskell enthusiast claiming that Scheme isn't a true functional language because it allows side-effects. It's just silly gatekeeping that doesn't lead anywhere interesting.
If you want TCO in CL then use one of the dozen implementations which supports it.
People btw. used to write some non-trivial code which ran in both Scheme and CL with the help of a Scheme on top CL, a compatibility layer or a translator. But that's now relatively rare.
Lisp is a family of languages - within which Scheme and CL are just as syntactically incompatible as CL and Clojure.
Other Lisps in that main line are Portable Standard Lisp, Le-Lisp, Emacs Lisp, ISLisp, ...
There are quite a few branches with less (Scheme) or more incompatible languages (ML, Dylan, Clojure, ...).
Don't think of Mathematica as a computer algebra system. It is much more than that, fully capable of numerical computation, and just the unique term rewriting programming language makes it worth checking out.
Yes, of course they do. For example, if they want to obtain a general, symbolic, solution to a problem, rather than estimates of particular numerical values. I'm sorry to sound a bit dismissive, but on HN it is common to hear people say stuff like "Oh, I find code much more helpful than math" and it's a bit embarrassing.
Just to give one example out of the entire universe of human mathematical activity, suppose you're doing statistical inference. You've developed a likelihood model for the data-generating process, and now it's time to implement the actual inference, say in a Bayesian MCMC, or a rejection sampler, or importance sampler, or whatever. Those are numerical algorithms of course; but they need to repeatedly evaluate the likelihood function at millions of different points in parameter space. Now, your likelihood function, was developed to model the real world. And perhaps the resulting equations are a little complicated. You may be able to achieve a vast speed-up of your numerical algorithm if you use a symbolic algebra system to find/confirm a symbolic simplification of your likelihood function.
Aside: You're commenting in a style that fits YouTube, or maybe Reddit, but this site has a different commenting culture/style.
Is there a way to access the database without the language?
It then originally has a large library of facts and rules for a large amount of mathematical domains. This has been expanded over time into lots of knowledge about the world (physics, biology, astronomy, ...).
Programming is often done with multimedia-rich notebooks.
https://reference.wolfram.com/language/ref/entity/Planet.htm...
So it's some kind of knowledge-based system for mathematical related domains,