[HN Gopher] Compiled and interpreted languages: Two ways of sayi...
___________________________________________________________________
Compiled and interpreted languages: Two ways of saying tomato
Author : jasim
Score : 31 points
Date : 2023-01-10 20:25 UTC (1 days ago)
(HTM) web link (tratt.net)
(TXT) w3m dump (tratt.net)
| gumby wrote:
| Of course even if you don't use a bytecoded language, your object
| code is interpreted by a program, the micromachine, in your CPU
| (unless you are running something VERY simple like a Z80 or small
| AVR, which implements the machine code in hardware).
|
| One of the nice perspective insights from 3Lisp, which of course
| was very high level!
| eatonphil wrote:
| It's a long (but good) article, so don't miss the conclusion:
|
| > Another thing I hope that I've indirectly shown, or at least
| hinted at, is that any language can be implemented in any style.
| Even if you want to think of CPython as an "interpreter" (a term
| that can be dangerous, as it occludes the separate internal
| compiler), there's PyPy, which dynamically compiles Python
| programs into machine code, and various systems which statically
| compile Python code into machine code (see e.g. mypyc).
|
| (Emphasis mine:)
|
| > There are interpreters for C and C++ (e.g. Cint or Cling).
| jacquesm wrote:
| > There are interpreters for C and C++
|
| Usually those are for (large) subsets of the language though.
| eatonphil wrote:
| Sulong is another. But yeah maybe not 100% compatible, I
| don't know.
|
| https://github.com/graalvm/sulong/blob/master/docs/ARCHITECT.
| ..
| dcow wrote:
| Yes this is a well written and fun piece. I suspect when most
| people say X is a compiled|interpreted language, they are
| semantically meaning "the de facto implementation of X is..."
| but nonetheless, this piece is one of those moments that really
| revisits and unambiguously resolves a discussion that many
| probably hadn't bothered to worry about for years. In other
| words, I think I decidedly have a new take for the next time
| this type of questions comes up over lunch (:
| saurik wrote:
| What was your old take from before reading this article?
| dcow wrote:
| I probably would have entertained one of the two stances "X
| is compiled" or "X is interpreted", not questioning the
| implied "de factor implementation of X..." and engaged in a
| pedantic back and forth. Now I'd probably link this article
| and argue "it depends on the implementation" and ask "what
| is a compiler anyway".
| [deleted]
| kerblang wrote:
| You could just use Java as the example: Compiled to bytecode,
| which is executed by a runtime interpreter. So: It's compiled &
| interpreted.
| svieira wrote:
| Compiled to bytecode which is executed by a runtime interpreter
| which traces the values passing through sections of it and uses
| those values to perform additional runtime optimizations on the
| newly annotated code and compile the new representation into
| machine code (or faster interpreted code). So you're right
| twice!
| [deleted]
| erk__ wrote:
| One of my favourite things about the question between compilers
| and interpreters is the Futamura projections [0] which is a way
| of using partial evaluation to construct both things. It could be
| interesting if we see that getting used more explicit than
| something like GraalVM which one could argue is getting there.
| [1]
|
| [0]: http://blog.sigfpe.com/2009/05/three-projections-of-
| doctor-f...
|
| [1]: https://news.ycombinator.com/item?id=18995651 (and the
| parent: https://news.ycombinator.com/item?id=18995498)
| RcouF1uZ4gsC wrote:
| 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.
| naasking wrote:
| You can probably draw a sharp line in two ways:
|
| 1. You're interpreting if syntactic tokens _directly_ drive
| evaluation. So only first two are interpreted.
|
| 2. Interpreters take syntactic input and evaluate to a result
| that comes from running the program, a compiler takes syntactic
| input and outputs a program that must then itself be run to
| compute the result.
|
| That said, I agree that "interpreted language" or "compiled
| language" is not a formally correct term, it's a connotative
| definition implying what's typical or the purposes for which a
| language may be suited.
| 082349872349872 wrote:
| my sharp line is "what do you see when profiling?"
|
| if you see the program's inner loops, it's been compiled
|
| if you see the language's inner loops, it's being interpreted
| ErikCorry wrote:
| It really depends which profiler you are using. If you
| profile with a profiler designed for the low level language
| you will see more level things.
| 082349872349872 wrote:
| profiling at the executable/machine-code level
| naasking wrote:
| What about qsort?
| 082349872349872 wrote:
| same thing, only what you see will tell you whether the
| library in which qsort was defined has been compiled or is
| being interpreted.
|
| ie, in the latter case, you'll see the language's dispatch
| loop in the "hot" range, as it interprets the def'n of
| qsort at multiple recursion levels... (and this signature
| will be independent of whether or not calls in each level
| are made on their own or combined horizontally to gain
| nested parallelism)
___________________________________________________________________
(page generated 2023-01-11 23:01 UTC)