The following represents an attempt at a very simple view of the levels in Mathematica code:
We have had lots of questions about deployment and compiling Mathematica code to C. Some of these for speed, others for deployment. My interests go to deployment.
While some have mentioned in various comments that compiling "symbolic code" presents a "hard" problem or that lots of Mathematica has lots of complicated things that make it difficult to compile, I don't have a clear grasp of what really stands in the way of Wolfram doing this.
At some point all code that runs on a computer gets expressed at a machine code level. The C code to which some Mathematica code can compile clearly sits above this.
The answers to How to specify Mathematica as a programming language? provide some context for thinking about all of this.
I appreciate that Wolfram might have other business priorities. Those don't concern me in this question.
To my mind the design of a programming language/tool as compiled or interpreted seems more like a business/marketing decision rather than a hard choice that completely locks a language into one or the other. Why should such a design choice limit a universal machine?
I have wondered if everyone would regard such a question as this as out of scope here, but I do think someone could provide a specific answer and an answer would go a long way to understanding what we can do, what we could do, and perhaps what Mathematica will never enable us to do.
So, simply and directly, I'd like to know what technical obstacles prevent all Mathematica code from compiling to C (byte-code would do too ;-)?
DSolve
, for example, if I recall correctly is about 10000 pages of mostly Mathematica code. Can you imagine how many people and hours must be invested in order to make it in C? And what will be the gain of this endeavor? $\endgroup$Compile
produces by default) is really just a low level interpreted language. Mathematica is a high level interpreted language. Mathematica is typically "slow". Compile's byte code is typically "fast". Your question is: why can't Mathematica run faster? Or what can't Mathematica be translated into something that will run faster? Am I correct? Or is the question only about deployment (not speed)? $\endgroup$ToExpression@FromCharacterCode@{50, 43, 50}
? Or even something as simple as<<file
. It think with a language like Mathematica that makes no real distinction between code and data, the difference between compiled and interpreted is more than just a marketing decision. $\endgroup$