The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

compilers and interpreters

Hi,
Which came first, compiler or interpreters? If compilers came first, then there was a reason for inventing interpreters. While learning python (stopped learning perl) I have learned some great features about interpreted languages, and I want to know why all new languages aren't interpreted?

Say, something like interpreted Java or C++, it will save a lot of programming time, bugs, debugging times etc...

Don't you think so?
wannabeboy-3 Send private email
Thursday, April 14, 2005
 
 
" I want to know why all new languages aren't interpreted?"

Usually for performance reasons, and actually most "interpreted" languages aren't really interpreted either. Most new Languages compile down to bytecode before they are run by a VM... There is actually very little difference between a interpreted and compiled language today, unless you look really close into it.

But you are not far from the mark I prefer the term dynamic language and they are actually quite popular.
Paracelsus
Thursday, April 14, 2005
 
 
It used to be about speed, but speed is not so important anymore.
Mike
Thursday, April 14, 2005
 
 
I guess one can call an assembler a compiler:
translates symbolic assembler code into machine code.
This is very old.

On the other hand one can call a command line processor an interpreter: parses and executes commands.
This is also very old.

Any computer operation, including programming, before those two technologies was something completely different from modern experience.
Erik Springelkamp Send private email
Thursday, April 14, 2005
 
 
I see not everything is clear to you.
How soft relates to hard may not be related how soft relates to the wet.
If soft is weak, then hard cannot help it.
Jouni Osmala Send private email
Thursday, April 14, 2005
 
 
Edit&Continue in debugging is a bit of line-blurring between compile and interactive coding.

It is more a tool question than anything else why C++ is a edit-compile-debug type of thing rather than a edit-debug type of thing - if that compiling still happens, it can be hidden by the tools.
i like i
Thursday, April 14, 2005
 
 
Compilers have become less relevant with the increase in processor speed.

In the past a compiled program would be 10x faster than an interpreted alternative.  Just a few years ago that additional performance made a real difference to the user's experience.

I think there are two factors that have significantly blurred the lines between compiler and interpreter.

First, processors are so much faster.  The performance gain of using a compiler is not as important now.

Second, improvements in technology.  Take a look at OCaml for a taste of the future.  It has all the benefits of an interpreted language, but in the language shootout it is matching C for peformance.
Ged Byrne Send private email
Thursday, April 14, 2005
 
 
>> Say, something like interpreted Java or C++, it will save a lot of programming time, bugs, debugging times etc...

Interpreted languages save you a lot of time for small problems. When programs get really big, you are better off with a compiler for a statically typed language. Beyond a few ten thousand lines of code the increase in speed that languages like Eiffel and Ada can offer you is incredible and completely unexpected, because they slow you down in the small.

I agree that interpretation vs. compilation is an implementation detail, but one with many implications for language design. However, it would be nice to have an interpreter and a compiler for the same language, so that switching becomes a seamless experience.

BTW, what is a debugger?

http://www.hello.nl/articles/TheDebuggerisdeadlonglive.html
http://www.hello.nl/articles/Writingbettersoftwarewith.html
Karel Thönissen Send private email
Thursday, April 14, 2005
 
 
Despite what others have said about bytecode and VMs, there is still a difference between a 'compiled' language like Java and an interpreted language like Python. However, scripting or interpreted versions of Java are also available - take a look at Beanshell, for example. Or scripted extensions to Java such as Groovy.
full.name()
Thursday, April 14, 2005
 
 
Karel: "However, it would be nice to have an interpreter and a compiler for the same language, so that switching becomes a seamless experience."

My fingers itched to write, but there are languages that do that already. But after reading your writing... You probably know what languages they are.

BTW thanks for the links.
Paracelsus
Thursday, April 14, 2005
 
 
Karel-

Interesting articles, but I must admit I'm somewhat skeptical.  Tell me, how would you use assertions or design-by-contract to find the bug in this code:

buffer[i] = (char_t)(((readByte() & 0x0F) << 12) |
    ((readByte() & 0x3F) << 6) |
    (readByte() & 0x3F));
Ken Send private email
Thursday, April 14, 2005
 
 
"Which came first, compiler or interpreters?"

The interpreter came first. The CPU is actually an interpreter for the executable. ;)
IC
Thursday, April 14, 2005
 
 
Originally, people wrote their programs in Hex opcodes.

Then came the concept of the 'assembler' -- a simple language (three to five character words -- LDA, STA, JMP) that mapped one-to-one into Hex opcodes.

Then came the "higher-level-language" -- Cobol first, then lots of others -- Pascal, Modula2, C, etc.  English-lite language with simplified syntax (compared to English, anyway) for expressing with NO AMBIGUITY various language constructs -- IF-THEN-ELSE, WHILE-DO, FOR-DO, etc. 

These were compiled into assembly, then run through an assembler to produce Hex opcodes, then run through a loader to put them on the machine as an executable program.

A typical compiler would be a multi-pass compiler -- first pass to find symbols and destination addresses, second pass to generate assembly with correct jump destinations.  Took time.  Clunky.

Then came interpreters -- the first one was Basic, I believe.  Driven by small computers, with very small storage limitations.  A Basic interpreter allows you to load the run-time (and IDE), then write and run your code.  Your code is compiled into 'tokens' -- each of which select a piece of run-time library code at run time.  Runs much slower (10x?  100x?) than an equivalent compiled program.  Can take much less space than an equivalent compiled program.  And converting source into tokens is not nearly as complicated as the multi-pass compilation and assembly.

Borland combined the two models with its Turbo Pascal, which was an IDE and run-time library that could compile so fast it looked like it was interpreted -- but generated true compiled code, so the result ran 10x faster than Basic.

Then there's the whole class of "Virtual Machine" (VM) languages -- of which Java is the most recent.  These compile into 'Byte Code', which then get run by a VM.  Sounds suspiciously similar to 'interpreted', doesn't it?

And I've left out Lisp and Scheme -- which I understand were designed to be incrementally compiled.  Visual Basic IS incrementally compiled -- I understand they have a Forth-ish stack-machine implementation under the hood.
AllanL5
Thursday, April 14, 2005
 
 
Oh, and the reason why all new languages aren't interpreted -- speed of execution.  Even with today's 3 Ghz processors, a compiled C++ program runs faster than a Java VM program.  There may come a time when the speed difference doesn't matter, but for now it is still a factor.

Having said that, aren't all new languages interpreted now?  Perl, Python, PHP, Java -- all VM based.  .NET -- all run on a 'framework'.
AllanL5
Thursday, April 14, 2005
 
 
Though a "framework" does not make a language interpreted.  A "framework" can also be a very large runtime library.  .Net is compiled to a VM (msil) - which could be interpreted - but then in some (many?  most?) the results of that get compiled down to actual executables.
Aaron F Stanton Send private email
Thursday, April 14, 2005
 
 
"Then came the "higher-level-language" -- Cobol first, then lots of others -- Pascal, Modula2, C, etc.  English-lite language with simplified syntax (compared to English, anyway) for expressing with NO AMBIGUITY various language constructs -- IF-THEN-ELSE, WHILE-DO, FOR-DO, etc. "

Cobol was not first, Fortran was (1954), then B-O (1957, precursor to cobol), then LISP (1958).  Cobol came out of B-O about a year after Lisp came out (1959).

You can see a diagram here:
http://www.levenez.com/lang/history.html#01
Andrew Hurst Send private email
Thursday, April 14, 2005
 
 
JScript .NET has both an IL compiler and a true interpreter -- that's how we got "eval" working in JS.NET.  (A parse tree can either spit itself out as IL or execute itself.)

JScript Classic, on the other hand, compiles everything to bytecode, whether its in "eval" or not.

Ironic, isn't it?  Everyone thinks that JScript classic is "interpreted" but in fact the much more advanced .NET version of the language is the one with the actual interpreter.
Eric Lippert Send private email
Thursday, April 14, 2005
 
 
Thanks Andrew, I see you are correct.  How did Fortran get to be first, I wonder?
AllanL5
Thursday, April 14, 2005
 
 
There used to be a joke in Software:

Q: "What language will we be using in the year 2000?"

A: "I don't know, but they'll call it Fortran!"

I believe this referred to the dramatic changes that occurred to Fortran as it evolved from I to II to IV to Fortran 77 to Fortran 90.

Now it does seem as if C/C++ has taken over that role.

I still miss Pascal, though.
AllanL5
Thursday, April 14, 2005
 
 
Plankalkül, 1941-45, by the inventor of the first electronic computer, Konrad Zuse.
Karel Thönissen Send private email
Thursday, April 14, 2005
 
 
You know. Python is a compiled interpreted language...

Notice how all your .py get converted to .pyc if you import them somewhere else. The difference between interpreted and compiled is blurring at an astounding rate.

Now, interpreted languages have been around pretty much since Lisp (maybe earlier?) and have been getting nearly as efficient as modern compiled languages.

I've seen some benchmarks where numerical python was nearly as fast C for scientific computing and Perl can be nearly as fast as C for text processing. Certainly less bug prone!
Alexandre Carmel-Veilleux Send private email
Thursday, April 14, 2005
 
 
Just to reiterate, the .NET and Java VMs are *not* interpreters. High-level language source code is compiled into byte code, but the byte code is also *compiled* into machine code at runtime, for every new function that gets called.

After this "just-in-time compilation" has happened, the CPU only runs the machine code for the function. Current Java VMs even have adaptive optimization for frequently called methods that will re-compile the byte code.
Chris Nahr Send private email
Thursday, April 14, 2005
 
 
So Chris has now enlightened us that there is now a new category -- Just In Time Compilation.  The Byte code is compiled into machine instructions when a call is first made by the Virtual Machine.

I guess once you have a VM in there, all kinds of neat things can happen.
AllanL5
Thursday, April 14, 2005
 
 
"I've seen some benchmarks where numerical python was nearly as fast C for scientific computing and Perl can be nearly as fast as C for text processing."

Those "benchmarks" are fake. I'm speaking of Python here but AFAIK it's the same with Perl. The Python code in question is really only some simple stub code that calls into high-performance libraries written in... wait for it... C.

Try to write those numerical or text processing algorithms directly in Python, and you'll get a performance that's maybe 0.01% of C.

At the end of the day those are still just scripting languages, and unsuitable where runtime performance is critical. You'll find out the moment you try to run an algorithm for which there's no C implementation in the standard library...

Granted, the above is true to *some* degree for any language that isn't a portable macro assembler. However, if you need to implement a custom algorithm in "real" languages such as C# and Java you'll still get 50-80% of C speed, not the ridiculous sub-1% performance that Python delivers.
Chris Nahr Send private email
Thursday, April 14, 2005
 
 
Yes, .Net and Java both use Just in Time Compilation, but you can also use an interpreter on the bytecode.  An interpreter is typically much more easily ported to a new CPU, for example.  It lets you get code up and running sooner, and then you tack on the JIT after the fact.  It's how Mono has been doing things for a while now, whenever they port to a new platform.  The interpreter goes first.
Aaron F Stanton Send private email
Thursday, April 14, 2005
 
 
Chris, I know full well that the benchmarks call library in C. If you want to get pedantic, the whole interpreter is written in C.

It would be incredibly stupid for Interpreters to implement all their functions and features in the interpreted language.

While I'm at it, I disagree that JIT VM are not also a form of interpreter. The program is taken in as byte-code and/or text and then executed. The exact emthod of execution is irrelevent. As far as the user is concerned, the behaviour is the only thing that matters.
Alexandre Carmel-Veilleux Send private email
Thursday, April 14, 2005
 
 
>> " I want to know why all new languages aren't interpreted?"

cause somebody gots to be writing the interpreter so your language can run sparky. duh.

i think all young programmers who can't C suck. Java is cake; its like living in la la land...oh it runs any where; its fast, and i don't have to mess with anything difficult like a real OS or graphical interfaces!!! YEAH.

I give a simple test to potential programmers....
1) write a hashtable in c with hash function, add, and remove.
2) port it to java

if you can't do the 1st, then how would you even really grasp how the second works. I just think developers that can only develop in interruptive languages are pussies. When you write real software for real customers who have real demands, sometimes you have to do things like read data from propetary drivers for some new device or service so your software can interopt and the user with smile and be happy.

This is why all the looser develpers are hitting Apple and using it to do development on...Linux isn't real, and "well, we're too cool to develop products for real people." it nothing but guys buying stylish equipment so they have a better chance of getting laid.

if you can C, you can't create Java.
Lemon Obrien III Send private email
Thursday, April 14, 2005
 
 
A JIT compiler can actually restructure the code to improve efficiency, translating the bytecode into native machine language and then passing execution to the generated code.  An interpreter does no such restructure and has no innate knowledge of the underlying architecture of the CPU, memory layout, or OS.
Aaron F Stanton Send private email
Thursday, April 14, 2005
 
 
" An interpreter ... has no innate knowledge of the underlying architecture of the CPU, memory layout, or OS."

What do you mean by "innate knowledge"?
wannabeboy-3 Send private email
Thursday, April 14, 2005
 
 
"An interpreter ... has no innate knowledge of the underlying architecture of the CPU, memory layout, or OS."

Oh my god..  somebody quickly tell Sun and Apple to stop booting their computers with FORTH!!
Almost Anonymous Send private email
Thursday, April 14, 2005
 
 
Fine.  I'm done here.
Aaron F Stanton Send private email
Thursday, April 14, 2005
 
 
>> What do you mean by "innate knowledge"?

i think its secual; but i'm a geek and haven't had sex ever AH AH AH "innate knowledge"

excuss me guys, i'll be back in five.
Lemon Obrien III Send private email
Thursday, April 14, 2005
 
 
Joel on the horror of multi-pass compilers of old:
http://www.joelonsoftware.com/articles/fog0000000023.html
bof.
Thursday, April 14, 2005
 
 
"It would be incredibly stupid for Interpreters to implement all their functions and features in the interpreted language."

I agree... and why is that? Because pure interpretation is *too slow*!

"While I'm at it, I disagree that JIT VM are not also a form of interpreter."

Well, then you have just contradicted yourself. As it happens, JIT-based languages *can* implement all their functions and features directly, excepting only the lowest-level bit twiddling.
Chris Nahr Send private email
Friday, April 15, 2005
 
 
"excepting only the lowest-level bit twiddling. "

What?
Jonathan
Friday, April 15, 2005
 
 
Oh, how nice.  We haven't had a pointless religious war in so long! 

The issue of whether a JIT compiler is an interpreter or not doesn't really matter.  As long as you understand what it does, how it provides better performance than a 'pure' interpreter, and how it differs from a 'pure' compiler, you should be good to go.

I stand by my assertion that it's a 'new beast', neither fish nor fowl, neither pure interpreter nor pure compiler.  It's a clever approach to keep the benefits of an interpreted language (small stored size), while reducing the performance hit (instead of running slow all the time, runs slow only the first time a function is used).
AllanL5
Friday, April 15, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz