Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
Per Westermark
11/12/11 06:11
Read: 429 times

#184678 - Not always worth it with interpreted languaes
Responding to: Andy Neil's previous message
Andy Neil said:
Indeed - but I was talking about the specific claim that removing the "build" step is an "advantage"

It is normally only on minimalisting target platforms, where it is a important advantage to remove the build step. That was why all our early microcomputer platforms had to settle for interpreted languges. They had a very simple and small "text-to-token" filter. And then they walked through these tokens, running a minimalisting virtual machine.

Today, compiler technology have reached a level where there exists a number of incrementative compilers. They can process a source file, pick up the single changed function, generate new virtual or native machine code for that function and then perform an incrementative linking with the rest of the program in almost zero time.

A number of compilers/linkers can even do that in the middle of a debugging session, and patch the running program on-the-fly and then let the developer continue single-stepping after having fixed the error. After the debugging has ended, the patched binary can be thrown away and the linker can create a fresh binary that does not contain the buggy code blocks that was patched around.

In the end, there are only really four situations (that I can see) where interpreted are good:
1) When the interpreter must run on the same hardware, and that hardware is tiny.
2) When target transfer times are very slow, so we don't want external builds and then wait for uploads but instead want to be able to make patch the application directly inside the target.
3) When there is a big advantage to be able to run self-modifying code - like having an end user supply a complex formula to a graphing web service.
4) When the language itself is extremely suitable for a specific problem, and there are no suitable alternative of a compiled language (too high price, not possible to run on target, licensing restrictions, ...)

I was pretty sure I had a fifth reason for interpreted solutions too, but sems to have dropped out of my mind while I was writing the first four. ;)

List of 17 messages in thread
Interpreted Languages?      Andy Neil      11/11/11 16:08      
   Sometimes it's hidden      Richard Erlacher      11/12/11 00:04      
      p-code      Per Westermark      11/12/11 05:04      
      P-code and others      Oliver Sedlacek      11/15/11 00:03      
      interpreter/compiler      Joseph Hebert      11/15/11 22:35      
         Debatable      Oliver Sedlacek      11/17/11 01:12      
            Not necessarily machine code      Matthias Arndt      11/17/11 01:19      
               Definitely debatable      Oliver Sedlacek      11/17/11 04:43      
                  Ofcourse not      Matthias Arndt      11/17/11 10:22      
   runtime errors      Jan Waclawek      11/12/11 05:22      
      You can't      Per Westermark      11/12/11 05:42      
      You missed the point!      Andy Neil      11/12/11 05:42      
         Not always worth it with interpreted languaes      Per Westermark      11/12/11 06:11      
            I like your thinking      Justin Fontes      11/15/11 10:40      
               Many FORTH implementations are interpreted, aren't they?      Richard Erlacher      11/15/11 11:08      
                  Forth      Per Westermark      11/15/11 11:29      
   Maybe a comparison?      Justin Fontes      11/15/11 10:14      

Back to Subject List