Jump to content
  • Advertisement
Sign in to follow this  
kuramayoko10

Programming languages characteristics and behaviors

This topic is 1968 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am trying to find characteristics in programming languages that "define" or indicate that it is compiled or interpreted.

 

I even tried asking it on StackOverflow. However no one answered it and 5 users downvoted it without explanation.

Either the answer is "There is none" or people misunderstood it.

 

The first misunderstanding is people answering:

 - Compiled languages are translated to the machine code of a specific machine, it analyzes the whole code at once, can perform optmizations on compile time, etc.

 - Interpreted languages are translated to a different kind of bytecode where a Virtual Machine has to interpret it and then translate to the machine it is running on; It analyzes the code on the fly, can present more precise error message, it distributes the program as a small package, etc.
 

Those are characteristics of the process compilation/interpretation and not the language itself.

 

I am looking for something like:

  1) Compiled languages present system calls or OS specific code.

 

Does anyone know any reference or example that confirm/deny the above?

Share this post


Link to post
Share on other sites
Advertisement
Though, in general, the more often the term "undefined behavior" comes up in the language specification, the less likely it is the people designing the language had an interpreter in mind for the implementation.

Share this post


Link to post
Share on other sites
It helps not to think of compilation and interpretation as binary options. They are more like a continuum. Virtual machines can fall between pure compilation and pure interpretation, for example.

Share this post


Link to post
Share on other sites

However, in some languages you can "rewrite" the code inside of your program. That is, in your code, you can possibly write code that generates other code (at run time) and runs the generated code. These types of languages are often interpreted, but again, you can compile these languages too (you just have to make the program capable of compiling the generated code).

You mean you don't just call mprotect(&main, ...), and overwrite your existing codepage with raw x86 assembly?

Kids these days... *shakes head*

Share this post


Link to post
Share on other sites

It helps not to think of compilation and interpretation as binary options.

Yes, you are right. My post doesnt emphasize this but I was not trying to segregate the languages.

I think it is possible to design a hybrid language, that is partially compiled and partially interpreted, right?

 

 

>>- Interpreted languages are translated to a different kind of bytecode where a Virtual Machine

Not exactly, a Virtual Machine has a different purpose, Java is a compiled language and still uses a VM.

The idea is more of a translator, I know, but it is generally called emulator/virtual machine...

Java has some static compiling options, but it stil partially interpreted, right?

 

 

EDIT: Thanks for making me read the wikipedia article again. I found a quote similar to Cornstalks there

 

Theoretically, any language may be compiled or interpreted, emulated or executed natively, so this designation is
applied purely because of common implementation practice and not some essential property of a language.

 

I will review language design, computer grammar, etc. smile.png

Edited by kuramayoko10

Share this post


Link to post
Share on other sites
Any language that has has the ability to execute an arbitrary string as code needs to have an interpreter, and those are the languages that use interpreters as the primary launch point. You could compile such a language in principle, any code using the "exec" functionality would need to compile in an interpreter. Especially problematic are cases where exec is used commonly, such as when implementing exceptions in perl.

Similarly languages that provide a runtime interface to the implementation of the abstract machine, like java's ClassLoader, is difficult to make work when the language is not implemented as designed. It's essentially the same issue; the language specifies how code is loaded at runtime, including code that doesn't need to be loaded at runtime. So it's difficult to write a conforming compiled implementation that acts like an interpreted implementation.


However, these days interpreters usually compile critical parts of the execution during the course of a run, using a JIT. They aren't pure interpreters.


Compiled languages have no problem being interpreted, and indeed interpreters do exist for traditionally compiled languages. Having an interpreter provides rapid startup, which can speed up development.

Share this post


Link to post
Share on other sites

Any language that has has the ability to execute an arbitrary string as code needs to have an interpreter, and those are the languages that use interpreters as the primary launch point.

You can always ship a compiler and linker with your software, and exec() can invoke the compiler and linker, and load the resulting executable into the current process image...

 

It's not pretty, but it's been done more than a few times, and I wouldn't really call it an "interpreter".

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!