3 ms·

I am going to hard disagree. This analysis focuses on the language specification and ignores the wider picture. The first question we have to ask about a lang

I am going to hard disagree. This analysis focuses on the language specification and ignores the wider picture. The first question we have to ask about a language is what caused it to be created. Making a language is a lot of effort (though it can be a lot of fun), and there has to be a reason for it (even if it just curiosity). Now to simplify stuff, let us choose to ignore purely exploratory languages. The first question to ask is what problem the author was trying to solve with the language. Take a look at C and AWK in which Brian Kernigan was heavily involved. The design goals for C were a lot different than the design goals of AWK. This led to C generally being compiled, and AWK being interpreted. In addition, in the case of C, there were deliberate decision decisions made to make it easier and to compile and optimize (for example all the undefined behavior). Now let's take a look at Java. The solution space that this was aiming for from nearly the beginning was a high-performance language compiled to a virtual machine using garbage collection. A lot of design decisions were made for the language with that goal in mind. Or look at C++. The design goals basically necessitated a compiler (even if the output of the compiler was C as CFront did) vs an interpreter. In addition, an ecosystem of a language is much more than the language, and can even be more important than the language itself. And the ecosystem, for the most part picks a side in the interpreted vs compiled debate. You could have a Java without the JVM, but you would lose access to a lot of techniques, libraries, debugging tools, and development tools that you have now. C++ does have interpreters, but these are all "use at your own risk" and many libraries will behave in weird ways (with regard to static initialization, etc) since they are being used in an unintended manner. I don't think anybody uses an interpreted C++ in a production system, and rather it is used more for exploratory development and analysis. Similarly a compiled python loses compatibility with certain libraries and there are issues that pop up that you would not have with the more widely used interpreted version. So yes, theoretically languages can be compiled or interpreted, but practically from the design going forward, usually one or the other is explicitly or implicitly aimed for, and using a language against that grain can lead to a lot of unnecessary pain.

hot_gril 4y ago
It's fitting that the title mentions tomatoes. Using Python as a compiled language is like eating a tomato as a fruit.
- JonChesterfield 4y ago
  Python is a great example of a compiled language for things like this. It's "known" that it's an interpreted language. Because it allows monkey patching and the like it's also challenging to statically optimise in a compiler. Yet cpython leaves compiled bytecode files scattered around on disk so most python programmers will also have wondered "what are these .pyc files" at some point. It then gives you tooling to poke around the bytecode which is clear enough that you can read it. I once gave a talk showing x64 and bytecode side by side for some arithmetic function and if you pick the example carefully they line up well. Then there's cython and pypy to point to for different points in the design space than cpython, or jython if you want to talk about the jvm. There's probably one on .net and iirc truffle has an implementation as well. The abandoned unladen swallow. So there's loads of python implementations all approaching the interpreted vs compiled tradeoffs differently.
  - hot_gril 4y ago
    Yes, you can still optimize around Python that way. The big difference in end result vs C comes from how Python prioritized runtime flexibility, while C aimed for speed by ensuring the compiler knows more about the program execution beforehand (mainly the size of every variable). The difference is most obvious looking at arrays of fixed-size integers, where a C int* far outperforms a Python list of ints no matter the implementation. Python list is actually a different thing because it has variable-sized integers and can take other objects too, so you can't optimize around that but could do so with a more specific fixed-size int array interface... which is what NumPy did.

hot_gril 4y ago

It's fitting that the title mentions tomatoes. Using Python as a compiled language is like eating a tomato as a fruit.

JonChesterfield 4y ago
Python is a great example of a compiled language for things like this. It's "known" that it's an interpreted language. Because it allows monkey patching and the like it's also challenging to statically optimise in a compiler. Yet cpython leaves compiled bytecode files scattered around on disk so most python programmers will also have wondered "what are these .pyc files" at some point. It then gives you tooling to poke around the bytecode which is clear enough that you can read it. I once gave a talk showing x64 and bytecode side by side for some arithmetic function and if you pick the example carefully they line up well. Then there's cython and pypy to point to for different points in the design space than cpython, or jython if you want to talk about the jvm. There's probably one on .net and iirc truffle has an implementation as well. The abandoned unladen swallow. So there's loads of python implementations all approaching the interpreted vs compiled tradeoffs differently.
- hot_gril 4y ago
  Yes, you can still optimize around Python that way. The big difference in end result vs C comes from how Python prioritized runtime flexibility, while C aimed for speed by ensuring the compiler knows more about the program execution beforehand (mainly the size of every variable). The difference is most obvious looking at arrays of fixed-size integers, where a C int* far outperforms a Python list of ints no matter the implementation. Python list is actually a different thing because it has variable-sized integers and can take other objects too, so you can't optimize around that but could do so with a more specific fixed-size int array interface... which is what NumPy did.