Package compilation files are now stored as shared libraries with native (assembly) code compiled by LLVM in them. This is not a Julia-specific byte code format but actual raw assembly instructions, and for the same (simple) algorithm you would get roughly the same assembly code as you would get from C++, Rust, C, etc. When a package is loaded and a function within it is called, the already compiled native code runs.
As been said, it is a free world but I think your usage of the word interpreted differs vastly from the majority. No one will throw you in jail if you call a banana an apple but the risk is that you get misunderstood and if you write things like tutorials you might confuse other people.
Late entry to the conversation here, the reason why I preferred Juat-Ahead-Of-Time compiled as the moniker for Julia is that it in creates the right mental image.
JIT languages are often tracing JITs, anyone who might have done performance work in Java knows the frustration of fighting the tracing JIT since the code under observation changes while being measured.
Even with all the work we have done on latency improvement, setting user expectations that the first call might be slow due to compilation is important.
In any given execution a user is likely to use both the compiler and interpreter, but if you run Julia with --compile=no you will see that certain things don’t work and need the compiler.
As others have said compilation vs interpretation is a implementation choice, not a language feature
It’s interesting to me because my impression is the opposite. I guess it is difficult to collect statistics on this, but I’m sure I’ve heard the word applied to languages with a wide variety of implementation strategies. It may just be that I’m “too young”—at least as a programmer. By the time I started programming, there were already no general purpose language implementations that fit the traditional definition of interpreted and the term was nonetheless applied to all kinds of language implementations that provide a similar workflow to Julia, regardless of what they compile to (for they all compile to something).
It occurs to me that part of the problem may be that there really are no other mainstream languages that have a similar execution model to Julia and any explanation using standard terminology requires a lot of qualification (or the invention of new terminology, e.g. JAOT, which requires explanations in any case).
And anyway, the only issue here is that if you call Julia an interpreted language there are certain associations connected to that that will make people think Julia is structured and executed in a way which it isn’t. So unless you also want to write 4 paragraphs elaborating on what you actually mean when you say “interpreted language”, I think it is just best to be pragmatic and avoid using that exact terminology to describe Julia.
Right, but by that logic you need to write four paragraphs to describe what Julia actually does at runtime anyway, because any terminology related to common language implementation strategies may be misleading.
What do you think is beneficial to an end-user when you think interpreted? Just say that instead.
Tutorial introductions needn’t (and really shouldn’t) be a legal document or a canonical reference. Get folks excited and give them a grounding for what to expect from the language!
If you’re wondering @ninjaaron why the julia community is so allergic to the language being labelled as “interpreted”, I think it’s pretty simple. People typically associate “interpreted language” with performance compromises, and julia typically allows one to write code that does not carry any of the performance compromises associated with interpreted languages, and the julia community is very proud of the fact that their highly interactive dynamic language is not only fast, but can roll with the fastest languages out there.
How does julia attain these performance characteristics that match the most speedy of compiled languages? Well, julia does it by compiling and optimizing code, and julia evangalists typically want to go through great pains to convince others that yes julia is indeed super fast, so they really don’t like it being labelled as an interpreted language. (even when the whole interpreted/compiled thing is a bit of false dichotomy and can be considered a waste of time to argue about or categorize on a language level)
This really gets to the root of it, I believe. It feels like the community here has landed on a narrower definition of “interpreted” than what I observe on other corners of the web specifically so that the word cannot be applied to Julia. It’s a response to a perceived marketing issue.
The people I mainly interact with, both in person and online, if they don’t know anything else about Julia, they know it’s fast—though they may be shocked how fast when you show them a few benchmarks and run some example code. I concern I run into more frequently is that they expect the language to be more cumbersome to use than Python.
So, to sum up, I guess my experienced is that people don’t need to be convinced that Julia is fast, but rather that it’s friendly. I guess I’m using the word “interpreted” for the same reason others wish to avoid it: I perceive a marketing problem and I want to use language that will counteract it.
edit: perhaps one main difference is that I’m often trying to make the case for using Julia as a general purpose programming language outside of scientific domains, so in that sense, the audience is rather different.
I think we might be allergic to it, too, because we are generally a bunch of nerds --even among programmers-- and being a hair pedantic comes with the territory
“Julia is an interactive language with a REPL in the way that Python (or R, or Matlab, or Erlang) is, except instead of bytecode compiled, it directly compiles to machine code the first time any function is called. It also has compiled code caching, so it can compile functions at install time so they are fast to call even the first time.”
This isn’t exactly paragraphs of text, I think it gets accurately to the nature of the language.
A dummy definition could be: in an interactive language if the first execution of a code follows an identical path than a subsequent execution, the code is fully interpreted. If the first execution is special by doing code transformations that are cashed, then the code has been (at least partially) compiled.
is it possible to mark this thread solved? if OP has found satisfying enough solution and wording recommendation for the repo write-up. This is getting long without any new information IMHO
FWIW, I’ve never participated or even come across any other compiled-vs-interpreted terminology discussion in the Julia fora before this, and the (rough, rule-of-thumb kind of) mental model when I hear “interpreted” is immediately “flexible but slow”. That is to say that it’s not a perception limited to the Julia community, and it might just be that different people attach different intuitions to these words. The basic definition of “interpreted” and “compiled” (and the vagueness of the terms) have been brought up before, but in both our cases, what we’re doing is extrapolating beyond the definitions to intuitions we hold about “interpreted” languages.
So practically speaking, the upshot is that, given:
I’m using the word “interpreted” for the same reason others wish to avoid it: I perceive a marketing problem and I want to use language that will counteract it.
the most prudent way is to not assume what the reader will extrapolate from the term, since different groups will take different things from the word. You might consider different phrasings to try to avoid the problem, like “Julia is a Just-Ahead-of-Time compiled language, which provides interactive features like interpreted languages commonly do”.
The first time a method is called with specific constellation of types. One method definition in source may be compiled numerous times to specialize for each set of concrete types it dispatches on. Julia’s execution model is indeed quite unique.
Yeah, I was trying to balance “technically correct” and “comprehensible” there, but this is probably unnecessarily intimidating-sounding to a newcomer. You can just call it JIT-compiled instead, the point is to try to balance the different interpretations people might have and not to assume one is universal or even significantly more common than the other.
Since @ninjaaron has been holding down their side solo, I just want to back them up a little.
If I’m talking to my colleague who works exclusively in R or Python and is mostly a statistician who happens to write programs, they aren’t going to parse “dynamic/interpreted/interactive/JIT/JOAT/byte-code/source-code/machine-code/…” If I say, “Julia is interpreted like Python, but it is mind-bogglingly faster, closer to C once it gets rolling,” even if they have a preconceived notion about what interpreted means, I answer that concern within a sentence. If they ask, “Oh! How does it even do that?” Then I might start talking about the compilation model, the TTFX tradeoff, caching, blah, blah, all while trying to assess if they are still interested, understanding, etc.
On the internet, we are on a stage before the world, so we can’t depend on feedback and context. In this case, being precise matters. Starting with “Just-ahead-of-time” and an explanation probably makes sense.
But 99.9% of the time I’m explaining Julia, I have a really strong understanding of my audience. If @ninjaaron heads off performance concerns, then the spirit of “interpreted” might capture exactly what they’re trying to communicate within the context of the rest of the sentence/paragraph/audience background/etc.
So to answer “Is it [technically] wrong to call Julia interpreted” Yeah. “Is it [strategically] wrong to call Julia interpreted”… depends on context for me.
To argue against myself, though, I’m not sure I can think of a time when “interpreted” is more helpful than “interactive”. The latter captures the workflow experience just fine to me without any technical issues.
