6 ms·

Good point! However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. There is no

Good point! However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. There is no such thing as an "interpreted language", a language is just a set or rules and keywords. Everything you can fit into Backus–Naur form is already a language even if it doesn't have any implementation nor compiler neither interpreter. Just as a piece of evidence, there are interpreted C++ (http://www.artificialworlds.net/wiki/IGCC/IGCC http://www.artificialworlds.net/wiki/IGCC/IGCC) and AOT Python (https://github.com/exaloop/codon https://github.com/exaloop/codon) implementations.

RcouF1uZ4gsC 4y ago
You are missing the forrest for the trees. When people refer to a language, most often they are using it as a synecdoche to refer to the whole language ecosystem and not just the the formal language definition. If you look at the Python ecosystem, it is most definitely interpreted.
- nvrspyx 4y ago
  Off topic, but thank you for introducing the word "synecdoche" to me.
  - narcraft 4y ago
    Movie recommendation: Synecdoche New York
  - zelphirkalt 4y ago
    Now the question for non-native speakers is: How to pronounce that word? ;D
    - nvrspyx 4y ago
      Sin-eck-da-key Or at least, that's how I'm hearing it from Google.
    - drowsspa 4y ago
      I'd pronounce it See-Neh-Doal-Kee
      - aliqot 4y ago
        there is no L in it
        drowsspa 4y ago
        L sounds like a short "OO" in Brazilian Portuguese, and he asked how a non-native would pronounce it...
        cirospaciari 4y ago
        Exactly
  - j33zusjuice 4y ago
    Did you look up how to pronounce it? I was mispronouncing it for like a year after seeing “Synecdoche New York” (it’s kinda pretentious, not for everyone). My coworker laughed at me when I said the name to him. I’d only ever seen it written, and did not look at a pronunciation chart. Wah wah. Just in case anyone else is getting it wrong like I was … https://youtube.com/watch?v=v-n1vGeVIXo https://youtube.com/watch?v=v-n1vGeVIXo (But really, https://youtu.be/u8_LDxZReTc https://youtu.be/u8_LDxZReTc)
- zelphirkalt 4y ago
  Personally, I often find myself saying things like "the <lang> ecosystem" to avoid this. I think it is fair to have a discussion about terminology and arguing with the actual meaning of terms. When there is a technical difference, it would be good to acknowledge that difference between terms. It does not hurt anyone to do that. One can still say something like: "When we communicate I will use the word x for meaning y, because it is shorter and more convenient."
goatlover 4y ago
For all practical purposes, a programming language is defined by it's general real world implementation, and not it's specification. Maybe not so much for computer scientists, but for programmers, Python is interpreted with some JIT alternatives and C++ is compiled.
- okaleniuk 4y ago
  Numba is a Python compiler for heterogeneous programming. It builds kernels with the same back-end NVCC does. With the equivalent AST, the kernel code it also equivalent. We adopted it last year, and we don't rewrite code in C++ for GPGPU anymore. We save tons of effort on rewriting and even more on support. How is this computer science?
- zelphirkalt 4y ago
  This is false. Making a new implementation is a practical purpose. Any new implementation will have to work with the spec, instead of idiosyncracies of other implementations. Ergo there are practical purposes which go by how the language is defined in its specification. Some languages have more of a proper spec than others, of course. If we look at for example Scheme dialects, then they often change their implementation for better conformance with the various rnrs standards. New Scheme dialects often early on try to conform very much to the standard to avoid issues later on.
  - IshKebab 4y ago
    > Making a new implementation is a practical purpose. Not yet it isn't. At least not for Python. I mean there are plenty of alternative implementations of Python but they aren't practical because they don't work with CPython modules (as far as I know anyway) so approximately nobody uses them. The de facto spec is "what CPython does".
    - cirospaciari 4y ago
      PyPy work well with CPython modules but the performance is not that great, with CFFI performance is really good in PyPY, HPy project will change this https://hpyproject.org/ https://hpyproject.org/
JustSomeNobody 4y ago
> ... I'm fighting with within my company for a long time... I bet that's fun. > There is no such thing as an "interpreted language"... In the common vernacular, yes, there are.
ModernMech 4y ago
That’s the old way of language design; used to be that to create a “programming language”, you’d write a spec and call it a day. That just doesn’t fly anymore. These days, you actually have to implement a parser and compiler, and not only that, you have to write the entire standard library as well, along with a toolchain complete with debugger, profiler, package manager, language server implementation, etc. All this is to say that a programming language these days is really the sum of its parts, not a spec.
kaba0 4y ago
The language describing the syntax of a language is very different from its semantic interpretation. E.g. many languages’ syntax is context-free, yet the languages themselves are almost always Turing-complete.
jchw 4y ago
Even if there isn't literally such a thing as an "interpreted language" there are absolutely design choices made in Python that you wouldn't make if you wanted it to be fast at runtime. To be fair, this is also true of JavaScript, but in Python the choices were literally intentional, as simplicity of CPython and elegance of the language were long valued over performance. OTOH, interpreting C++ is actually a pain in the ass due to design choices it makes specifically regarding the semantics of translation units. You can see similar pain when trying to say, make a Go REPL: it's just not tuned for this. It is of course technically possible to compile almost anything ahead-of-time. But, if you effectively wind up having to ship an interpreter or JIT into the resulting binary to run some code anyways, it's almost for naught. Both Python and JavaScript have eval. Python also has several other cases like Pickle where this can be an issue. PyPy being a JIT makes a lot of sense because it wants to be a drop-in replacement, and that makes the most sense for a language with these constraints. Codon can do AOT, but for practical reasons it is not nearly a drop-in replacement for CPython, just like the other Python AOT implementations. A practical Python AOT is not compatible with loads of things that people associate with Python, like Django. PyPy is compatible with more, but even it is far from a drop-in today, and that is a problem. > A language is just a set or rules and keywords. Everything you can fit into Backus–Naur form is already a language even if it doesn't have any implementation nor compiler neither interpreter. This is objectively true. However, in practice, there are a finite number of available toolchains for any given language that exist today, and creating new ones is a non-trivial endeavor, especially production-quality ones. A language is just a set of rules and keywords. However, when people use Python and write Python, they are not merely writing Python to fit into those keywords and rules. They're writing Python to be executed and solve a problem, typically using CPython. Python is a language, but it's also an ecosystem. In the same token, if something like Codon doesn't even support all of the things you can fit into Backus-Naur form about Python as it is in CPython and PyPy, can it even be called Python in this sterile technical sense?
phkahler 4y ago
>> However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. My advice to you: Stop fighting that "misconception". See the other responses to back up the idea that Python is interpreted. The existence of a Python compiler is also not relevant here, as the linked project does not list that as a supported Python variant. Let's assume that by some technicality you are not wrong. The "misconception" is so common that it is generally a fact in peoples mind. Rather than convince them, you are destroying your own credibility and probably making a fool of yourself in their eyes. And remember, I prefaced this with you not being wrong. It's worse for you if you are wrong. Just stop for your own good.
- okaleniuk 4y ago
  Sorry, I didn't make it clear before. I'm winning. My credibility is well protected by our AWS bills. Last year we adopted Numba for GPGPU programming. It is a Python compiler with LLVM back-end and full CUDA support. It generates the same code that NVCC (CUDA compiler for C++) does only it compiles Python code and not a C++ .cu dialect. No one in our organization writes heterogeneous code in C++ anymore.
- BobbyJo 4y ago
  Common nomenclature is a hard thing to rally against, and probably not worth the fight.
- RHSman2 4y ago
  Like asking an engineer not to argue a detail!!!
- dymk 4y ago
  While I also find arguing for the sake of arguing tiresome, the comment your responding to makes a good point. The linked project beats Go fibers using PyPy, which is JIT compiled, where hot codepaths are not interpreted. A language is a set of rules (hopefully described in a specification...) - you can have interpreted C++, or compiled Python. The popular implementations are just that: implementations, of which others exist. > Rather than convince them, you are destroying your own credibility and probably making a fool of yourself in their eyes. I'd understand where you were coming from had the parent comment not explained what they meant and given examples.
pdpi 4y ago
> There is no such thing as an "interpreted language", a language is just a set or rules and keywords. Sure there is. Even if it is technically possible to write an interpreter for a "compiled" language, or a compiler for an "interpreted" language, language design really pushes you towards one or the other. "Technically possible" can also represent a very real challenge, as that set of rules and keywords might make ahead-of-time compilation either impossible or pointless. E.g. any language that exposes `eval` with an arbitrary argument will still need to ship an interpreter as part of the runtime even if you compile some of the code ahead of time. Monkey-patching is common in Python and Ruby, and is pretty hostile to compilation. Codon has several documented limitations around this. Perl 5 famously can't be statically parsed without evaluating the code as you go, which completely defeats any attempt at compiling it. Inversely, You can write an interpreter for C++, but features like `consteval` and `constexpr` are meaningless without ahead-of-time compilation.
- dymk 4y ago
  > Inversely, You can write an interpreter for C++, but features like `consteval` and `constexpr` are meaningless without ahead-of-time compilation. No they're not, `constexpr` and `consteval` indicate where you can use an expression, not when in the compilation/interpretation pipeline they need to be evaluated. The spec does not say that C++ has to be compiled, nor does the spec say "A compiler must execute `constexpr` expressions prior to entering `main()`". If you think this is just being pedantic, well, that's kind of the point of a spec.
j1elo 4y ago
Language is used to communicate. And not needing to be absurdly verbose in everything that one says, is a virtue and a need for efficient transmission of concepts and idea. So when someone says "Python is an interpreted language" they are pleading to an implicit preexisting shared knowledge about the nature of the most commonly found usage of the concept. Granted, when this shared knowledge doesn't match, that's where misunderstandings can happen, but that's the nature of human language. In this case I'd be hard pressed to think that any misunderstanding could have been possible for the immense majority of people reading this.
MobiusHorizons 4y ago
There are language features of dynamic languages like python that prevent them from being compiled to machine code. That is to say, the compiler can’t know what assembly to output from the code itself, it also has to know some type information which isn’t available until runtime. I would encourage you not to fight the classification of interpreted language as your primary argument. You will likely lose credibility with the listener before you have a chance to make any good points. You could for instance say “just because the reference implementation is slow doesn’t mean there is no hope for the language becoming fast”. There is some truth to the argument. JavaScript has become a reasonably fast language with all the engineering effort spent on engines for it. But I would also spend some time learning about what makes dynamic languages hard to compile. I think you will find that some features of the language must be dropped to achieve fully aot compilation. The classic example would be eval() which invokes an interpreter from inside the language, but there are usually other features.
deleted 4y ago
[deleted]
dang 4y ago
We detached this subthread from https://news.ycombinator.com/item?id=34323277 https://news.ycombinator.com/item?id=34323277.

RcouF1uZ4gsC 4y ago

You are missing the forrest for the trees. When people refer to a language, most often they are using it as a synecdoche to refer to the whole language ecosystem and not just the the formal language definition. If you look at the Python ecosystem, it is most definitely interpreted.

nvrspyx 4y ago
Off topic, but thank you for introducing the word "synecdoche" to me.
- narcraft 4y ago
  Movie recommendation: Synecdoche New York
- zelphirkalt 4y ago
  Now the question for non-native speakers is: How to pronounce that word? ;D
  - nvrspyx 4y ago
    Sin-eck-da-key Or at least, that's how I'm hearing it from Google.
  - drowsspa 4y ago
    I'd pronounce it See-Neh-Doal-Kee
    - aliqot 4y ago
      there is no L in it
      - drowsspa 4y ago
        L sounds like a short "OO" in Brazilian Portuguese, and he asked how a non-native would pronounce it...
        cirospaciari 4y ago
        Exactly
- j33zusjuice 4y ago
  Did you look up how to pronounce it? I was mispronouncing it for like a year after seeing “Synecdoche New York” (it’s kinda pretentious, not for everyone). My coworker laughed at me when I said the name to him. I’d only ever seen it written, and did not look at a pronunciation chart. Wah wah. Just in case anyone else is getting it wrong like I was … https://youtube.com/watch?v=v-n1vGeVIXo https://youtube.com/watch?v=v-n1vGeVIXo (But really, https://youtu.be/u8_LDxZReTc https://youtu.be/u8_LDxZReTc)
zelphirkalt 4y ago
Personally, I often find myself saying things like "the <lang> ecosystem" to avoid this. I think it is fair to have a discussion about terminology and arguing with the actual meaning of terms. When there is a technical difference, it would be good to acknowledge that difference between terms. It does not hurt anyone to do that. One can still say something like: "When we communicate I will use the word x for meaning y, because it is shorter and more convenient."

goatlover 4y ago

For all practical purposes, a programming language is defined by it's general real world implementation, and not it's specification. Maybe not so much for computer scientists, but for programmers, Python is interpreted with some JIT alternatives and C++ is compiled.

okaleniuk 4y ago
Numba is a Python compiler for heterogeneous programming. It builds kernels with the same back-end NVCC does. With the equivalent AST, the kernel code it also equivalent. We adopted it last year, and we don't rewrite code in C++ for GPGPU anymore. We save tons of effort on rewriting and even more on support. How is this computer science?
zelphirkalt 4y ago
This is false. Making a new implementation is a practical purpose. Any new implementation will have to work with the spec, instead of idiosyncracies of other implementations. Ergo there are practical purposes which go by how the language is defined in its specification. Some languages have more of a proper spec than others, of course. If we look at for example Scheme dialects, then they often change their implementation for better conformance with the various rnrs standards. New Scheme dialects often early on try to conform very much to the standard to avoid issues later on.
- IshKebab 4y ago
  > Making a new implementation is a practical purpose. Not yet it isn't. At least not for Python. I mean there are plenty of alternative implementations of Python but they aren't practical because they don't work with CPython modules (as far as I know anyway) so approximately nobody uses them. The de facto spec is "what CPython does".
  - cirospaciari 4y ago
    PyPy work well with CPython modules but the performance is not that great, with CFFI performance is really good in PyPY, HPy project will change this https://hpyproject.org/ https://hpyproject.org/

JustSomeNobody 4y ago

> ... I'm fighting with within my company for a long time... I bet that's fun. > There is no such thing as an "interpreted language"... In the common vernacular, yes, there are.

ModernMech 4y ago

That’s the old way of language design; used to be that to create a “programming language”, you’d write a spec and call it a day. That just doesn’t fly anymore. These days, you actually have to implement a parser and compiler, and not only that, you have to write the entire standard library as well, along with a toolchain complete with debugger, profiler, package manager, language server implementation, etc. All this is to say that a programming language these days is really the sum of its parts, not a spec.

kaba0 4y ago

The language describing the syntax of a language is very different from its semantic interpretation. E.g. many languages’ syntax is context-free, yet the languages themselves are almost always Turing-complete.

jchw 4y ago

Even if there isn't literally such a thing as an "interpreted language" there are absolutely design choices made in Python that you wouldn't make if you wanted it to be fast at runtime. To be fair, this is also true of JavaScript, but in Python the choices were literally intentional, as simplicity of CPython and elegance of the language were long valued over performance. OTOH, interpreting C++ is actually a pain in the ass due to design choices it makes specifically regarding the semantics of translation units. You can see similar pain when trying to say, make a Go REPL: it's just not tuned for this. It is of course technically possible to compile almost anything ahead-of-time. But, if you effectively wind up having to ship an interpreter or JIT into the resulting binary to run some code anyways, it's almost for naught. Both Python and JavaScript have eval. Python also has several other cases like Pickle where this can be an issue. PyPy being a JIT makes a lot of sense because it wants to be a drop-in replacement, and that makes the most sense for a language with these constraints. Codon can do AOT, but for practical reasons it is not nearly a drop-in replacement for CPython, just like the other Python AOT implementations. A practical Python AOT is not compatible with loads of things that people associate with Python, like Django. PyPy is compatible with more, but even it is far from a drop-in today, and that is a problem. > A language is just a set or rules and keywords. Everything you can fit into Backus–Naur form is already a language even if it doesn't have any implementation nor compiler neither interpreter. This is objectively true. However, in practice, there are a finite number of available toolchains for any given language that exist today, and creating new ones is a non-trivial endeavor, especially production-quality ones. A language is just a set of rules and keywords. However, when people use Python and write Python, they are not merely writing Python to fit into those keywords and rules. They're writing Python to be executed and solve a problem, typically using CPython. Python is a language, but it's also an ecosystem. In the same token, if something like Codon doesn't even support all of the things you can fit into Backus-Naur form about Python as it is in CPython and PyPy, can it even be called Python in this sterile technical sense?

phkahler 4y ago

>> However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. My advice to you: Stop fighting that "misconception". See the other responses to back up the idea that Python is interpreted. The existence of a Python compiler is also not relevant here, as the linked project does not list that as a supported Python variant. Let's assume that by some technicality you are not wrong. The "misconception" is so common that it is generally a fact in peoples mind. Rather than convince them, you are destroying your own credibility and probably making a fool of yourself in their eyes. And remember, I prefaced this with you not being wrong. It's worse for you if you are wrong. Just stop for your own good.

okaleniuk 4y ago
Sorry, I didn't make it clear before. I'm winning. My credibility is well protected by our AWS bills. Last year we adopted Numba for GPGPU programming. It is a Python compiler with LLVM back-end and full CUDA support. It generates the same code that NVCC (CUDA compiler for C++) does only it compiles Python code and not a C++ .cu dialect. No one in our organization writes heterogeneous code in C++ anymore.
BobbyJo 4y ago
Common nomenclature is a hard thing to rally against, and probably not worth the fight.
RHSman2 4y ago
Like asking an engineer not to argue a detail!!!
dymk 4y ago
While I also find arguing for the sake of arguing tiresome, the comment your responding to makes a good point. The linked project beats Go fibers using PyPy, which is JIT compiled, where hot codepaths are not interpreted. A language is a set of rules (hopefully described in a specification...) - you can have interpreted C++, or compiled Python. The popular implementations are just that: implementations, of which others exist. > Rather than convince them, you are destroying your own credibility and probably making a fool of yourself in their eyes. I'd understand where you were coming from had the parent comment not explained what they meant and given examples.

pdpi 4y ago

> There is no such thing as an "interpreted language", a language is just a set or rules and keywords. Sure there is. Even if it is technically possible to write an interpreter for a "compiled" language, or a compiler for an "interpreted" language, language design really pushes you towards one or the other. "Technically possible" can also represent a very real challenge, as that set of rules and keywords might make ahead-of-time compilation either impossible or pointless. E.g. any language that exposes `eval` with an arbitrary argument will still need to ship an interpreter as part of the runtime even if you compile some of the code ahead of time. Monkey-patching is common in Python and Ruby, and is pretty hostile to compilation. Codon has several documented limitations around this. Perl 5 famously can't be statically parsed without evaluating the code as you go, which completely defeats any attempt at compiling it. Inversely, You can write an interpreter for C++, but features like `consteval` and `constexpr` are meaningless without ahead-of-time compilation.

dymk 4y ago
> Inversely, You can write an interpreter for C++, but features like `consteval` and `constexpr` are meaningless without ahead-of-time compilation. No they're not, `constexpr` and `consteval` indicate where you can use an expression, not when in the compilation/interpretation pipeline they need to be evaluated. The spec does not say that C++ has to be compiled, nor does the spec say "A compiler must execute `constexpr` expressions prior to entering `main()`". If you think this is just being pedantic, well, that's kind of the point of a spec.

j1elo 4y ago

Language is used to communicate. And not needing to be absurdly verbose in everything that one says, is a virtue and a need for efficient transmission of concepts and idea. So when someone says "Python is an interpreted language" they are pleading to an implicit preexisting shared knowledge about the nature of the most commonly found usage of the concept. Granted, when this shared knowledge doesn't match, that's where misunderstandings can happen, but that's the nature of human language. In this case I'd be hard pressed to think that any misunderstanding could have been possible for the immense majority of people reading this.

MobiusHorizons 4y ago

There are language features of dynamic languages like python that prevent them from being compiled to machine code. That is to say, the compiler can’t know what assembly to output from the code itself, it also has to know some type information which isn’t available until runtime. I would encourage you not to fight the classification of interpreted language as your primary argument. You will likely lose credibility with the listener before you have a chance to make any good points. You could for instance say “just because the reference implementation is slow doesn’t mean there is no hope for the language becoming fast”. There is some truth to the argument. JavaScript has become a reasonably fast language with all the engineering effort spent on engines for it. But I would also spend some time learning about what makes dynamic languages hard to compile. I think you will find that some features of the language must be dropped to achieve fully aot compilation. The classic example would be eval() which invokes an interpreter from inside the language, but there are usually other features.

deleted 4y ago

[deleted]

dang 4y ago

We detached this subthread from https://news.ycombinator.com/item?id=34323277 https://news.ycombinator.com/item?id=34323277.