Tag Info

Hot answers tagged

97

In layman's words: All programs can have bugs. Compilers are programs. Ergo, compilers can have bugs.


88

Writing a compiler seems like a much harder problem than an interpreter. That might be true today, but I would argue that it was not the case some 60 years ago. A few reasons why: With an interpreter, you have to keep both it and the program in memory. In an age where 1kb of memory was a massive luxury, keeping the running memory footprint low was ...


46

Yes You tend to find them more in languages that are actively being developed than in those that are relatively mature (and thus don't see a lot of change on a frequent basis). This is probably why most languages are released at various 'stages' of stability. A nightly build is far less likely to be stable than a release candidate, which itself is less ...


40

The fundamental point is that the computing hardware environment of the 1950s made it such that only a compiler was feasible given the batch-oriented processing of computers back then. At the time the better user interfaces were primarily limited to punch cards and teletype printers. In 1961 the SAGE system became the first Cathode-Ray Tube (CRT) display on ...


24

It is neither. Objective-C is a programming language. A programming language is an abstract concept. A programming language is a set of mathematical rules and definitions. Programming languages aren't compiled or interpreted, they just are. Compilation and interpretation aren't properties of a programming language, they are properties of, well, a compiler ...


24

It's worth noting that languages are not interpreted or compiled, but rather language implementations either interpret or compile code. You noted that Ruby is an "interpreted language", but you can compile Ruby à la MacRuby, so it's not always an interpreted language. Pretty much every Python implementation consists of an interpreter (rather than a ...


22

There can bugs even in hardware; a famous example is the Pentium FDIV bug. Without doubt there is the possibility that the compilers contain bugs.


21

Yes, you are missing something. Encapsulation is often described with metaphors of "hiding" or acting "defensive", as if client programmers were your enemy and you had to act stealthily and sneakily to defend yourself against their evil intentions. That is sometimes helpful; for instance, if you program extremely popular frameworks that have to maintain ...


16

Python will fall under byte code interpreted. .py source code is first compiled to byte code as .pyc. This byte code can be interpreted (official CPython), or JIT compiled (PyPy). Python source code (.py) can be compiled to different byte code also like IronPython (.Net) or Jython (JVM). There are multiple implementations of Python language. The official one ...


14

The simple answer to your question is to try Lisp, preferably in conjunction with SICP. Then you will be enlightened. That said... Code is Data Most languages make a sharp distinction between code and data; Lisp does not. This makes it possible to, for example, trivially write a Lisp parser in Lisp, and to manipulate Lisp code within Lisp. The best ...


13

It's important to remember that interpreting and compiling are not just alternatives to each other. In the end, any program that you write (including one compiled to machine code) gets interpreted. Interpreting code simply means taking a set of instructions and returning an answer. Compiling, on the other hand, means converting a program in one language to ...


13

Various comments have pointed out several ambiguities in the question and nuances to the answer, but the simple answer is no. The JVM and .NET Framework are Just-In-Time Compilers. They are still compilers, and do all of the work of a compiler. They take an intermediate language (bytecode), optimize it, and convert it into machine code. The only difference ...


11

The Python documentation, in the Lexical Analysis section, describes briefly how the indentation parsing works. In short, the tokeniser generates special INDENT and DEDENT tokens that are used by the parser when deciding where blocks of code start and end. These tokens (roughly) correspond to the { and } tokens in C-like languages.


10

The first programming languages were quite simple (no recursion for example) and close to machine architecture which was itself simple. The translation was then a straightforward process. A compiler was simpler as a program than an interpreter that would have to keep together both the data for program execution and the tables to interpret the source code. ...


9

There are two options here. 1) Don't implement if as a function. Make it a language feature with special semantics. Easy to do, but less "pure" if you want everything to be a function. 2) Implement "call by name" semantics, which is much more complicated, but allows compiler magic to take care of the lazy evaluation problem while keeping if as a ...


8

There is no technical standard that defines a scripting language. It's just a word that is defined by common usage, and like any other word in common usage, there is no guarantee that all the usages are consistent. Tackling your specific questions: The dynamic code generation they are talking about is machine code. In a classic interpreted language (think ...


8

Remember that whitespace appears as just another character to the interpreter. A tab is 0x09 in ASCII A space is 0x20 in ASCII An interpreter is little more than a pattern matcher that then triggers predefined rules.


8

Compilers and interpreters are software too, and thus they aren't free from any of the problems of other software. This is an example from a compiler as recent as MSVC 11 (2012), and here's an article on how they test the backend.


8

A processor executes machine instructions. They are the only thing that a processor understands. Java bytecode is an intermediate, compact, way of representing a series of operations (for want of a better term). The processor can't execute these directly. The Java Virtual Machine processes that stream of bytecode operations and interprets them into a ...


8

Yes, but more than that. All of the interpreter's code is interpreted by a lower level, including the "scan a piece of code" step. However, there are less levels than you think - more than three levels is rare. Jython is one example of an interpreter running on an interpreter. It runs Python code, and is itself written in Java, which is interpreted by a ...


7

This definition would clearly put the usual execution of Java bytecode in the domain of interpretation, no matter how much JIT compilation is done. I have encountered opinions in discussions on this site that clearly and vehemently state the opposite, i.e. that Java Bytecode execution thingies are compilers. Well, the two definitions aren't mutually ...


7

Here is a more recent paper by Simon Peyton Jones on the Spineless Tagless G-machine, which was (and still is) used as an intermediate language in the Glasgow Haskell Compiler: Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine (1992).


7

Why is the study of an interpreter that is written in the language it interprets so emphasized? In general, studying an interpreter gives you insight into its language and features. In general, studying code in a programming language is like practicing a spoken language by listening and reading: it familiarizes you with what that language can do, how ...


6

TD;DR: Strings are mutable. Symbols are not. Strings and symbols serve different purposes. an interpreter still has to parse the word that you typed in order to match it to a symbol :foo == "foo" could be determined by interning the string or turning the symbol into a string. In any event, if the interpreter interned every string it saw, it would have ...


6

There are many differences. First of all, think of the difference between a bytecode interpreter and a language interpreter. It's easy to interpret bytecode, because all commands follow a predictable format, but interpreting a language involves parsing and lexing -- operations that can be quite taxing, depending on the language. C# and Java don't only ...


6

This brings back the old times... I have a copy of the book, 3rd printing, 1975. I checked your listing and it's non-original. In the original source code the statements have no spaces and assignments have the keyword LET. For example 200 LETK=M:GOSUB600 The dialect is DIGITAL PDP-11 BASIC (not Basic-plus or BASIC-80). From experience, not all of these ...


6

A VM is a piece of software that offers a machine-like abstraction. In the context of virtualization, a VM might abstract hardware resources. In programming language VMs, the VM offers a machine model, e.g. with a specific instruction set, a number of stacks, and a memory model. It is true that we can interpret any language as an instruction set, but ...


6

No. The reason why there is speed difference between languages like Python and C++ is because statically-typed languages give compiler tons of information about structure of the program and data which allows it to optimize both computations and memory access. Because C++ knows that variable is of type int, it knows optimal way to manipulate that variable ...


6

Absolutely - an interpreter is just a "one line at a time" compiler. It performs much the same task, that of taking some form of human-understandable source code and turning it into something a computer processor can understand. A compiler will do this for entire source file(s), whereas an interpreter will do this on an as-read basis. You will need to ...


5

In CPython, allocation of tuples (basically immutable lists) can be slightly faster than an allocation of the equivalent mutable type with the same items. I vaguely remember similar rumors about immuable sets, but timeit didn't confirm it. Tuples can also be smaller than lists, from a few bytes to 50% (if you hit a spot where the list had to resize, and ...



Only top voted, non community-wiki answers of a minimum length are eligible