Jump to content

  • Log In with Google      Sign In   
  • Create Account

Programming languages characteristics and behaviors


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
20 replies to this topic

#1 kuramayoko10   Members   -  Reputation: 386

Like
0Likes
Like

Posted 26 February 2013 - 01:50 PM

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?


Programming is an art. Game programming is a masterpiece!

Sponsor:

#2 Cornstalks   Crossbones+   -  Reputation: 6989

Like
7Likes
Like

Posted 26 February 2013 - 02:02 PM

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

I can't think of any. If you can make an interpreter for a language, you can make a compiler for the language. If you can make a compiler for the language, you can make an interpreter for it too.

 

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).

 

There's no rule that says "this language must be compiled" and "this language must be interpreted."


Edited by Cornstalks, 26 February 2013 - 02:06 PM.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#3 kuramayoko10   Members   -  Reputation: 386

Like
0Likes
Like

Posted 26 February 2013 - 02:13 PM

Thanks Cornstalks.

That is one of the responses I was looking for.


Programming is an art. Game programming is a masterpiece!

#4 SiCrane   Moderators   -  Reputation: 9595

Like
0Likes
Like

Posted 26 February 2013 - 02:24 PM

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.

#5 ApochPiQ   Moderators   -  Reputation: 15698

Like
2Likes
Like

Posted 26 February 2013 - 02:32 PM

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.

#6 Rod Ochoa   Members   -  Reputation: 123

Like
0Likes
Like

Posted 26 February 2013 - 02:39 PM

>>- 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.

check classic references:

http://en.wikipedia.org/wiki/Interpreted_language

http://en.wikipedia.org/wiki/Compiled_language


Edited by Rod Ochoa, 26 February 2013 - 02:41 PM.


#7 swiftcoder   Senior Moderators   -  Reputation: 9991

Like
1Likes
Like

Posted 26 February 2013 - 02:45 PM

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*

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#8 kuramayoko10   Members   -  Reputation: 386

Like
0Likes
Like

Posted 26 February 2013 - 02:53 PM

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, 26 February 2013 - 02:56 PM.

Programming is an art. Game programming is a masterpiece!

#9 King Mir   Members   -  Reputation: 2000

Like
2Likes
Like

Posted 26 February 2013 - 02:54 PM

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.

#10 swiftcoder   Senior Moderators   -  Reputation: 9991

Like
0Likes
Like

Posted 26 February 2013 - 03:00 PM

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".


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#11 King Mir   Members   -  Reputation: 2000

Like
0Likes
Like

Posted 26 February 2013 - 03:06 PM


>>- 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?


Java is best view as interpreted Bytecode, with a Just In Time compiler. Which is functionally equivalent to saying that java bytecode is an interpreted language, because the effect of the JIT is to provide speedup, while retaining the rapid startup advantages of an interpreter (although Java is a bit poor at rapid startup, because the JVM is so complex.)
 


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?


That's what a JIT is.

#12 King Mir   Members   -  Reputation: 2000

Like
0Likes
Like

Posted 26 February 2013 - 03:29 PM

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.

I disagree that this is the way a programmer should look at language choice. But it is true from an interpreter design perspective.

For a programmer choosing a language, an interpreted language is a language that's a bit slower, but provides rapid launch, since you don't need to compile and run. Even despite advances in compiler and interpreter, languages tend to be the determining factor in programmer priorities with respect to to runtime efficiency verses rapid development and other advantages of interpreted languages. If your only priority is speed, go native. If you want rapid development and security, go interpreted and managed.

#13 swiftcoder   Senior Moderators   -  Reputation: 9991

Like
1Likes
Like

Posted 26 February 2013 - 03:40 PM

an interpreted language is a language that's a bit slower, but provides rapid launch, since you don't need to compile and run

"Rapid launch" is almost certainly the wrong terminology. Interpreters generally have much longer launch times than compiled code, due to the time it takes to parse the source code, and any warm up time for the JIT.
 
I presume you mean rapid edit->compile->run cycles?


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#14 King Mir   Members   -  Reputation: 2000

Like
0Likes
Like

Posted 26 February 2013 - 03:44 PM


an interpreted language is a language that's a bit slower, but provides rapid launch, since you don't need to compile and run

"Rapid launch" is almost certainly the wrong terminology. Interpreters generally have much longer launch times than compiled code, due to the time it takes to parse the source code, and any warm up time for the JIT.
 
I presume you mean rapid edit->compile->run cycles?


Yeah, that. Except that's the wrong word too, because interpreted languages don't have a compile cycle as such. But the idea is there.

#15 Telastyn   Crossbones+   -  Reputation: 3726

Like
1Likes
Like

Posted 26 February 2013 - 04:17 PM

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".

Quoting for emphasis. .NET has one as part of the standard install (though you need elevated privledges to use it of course). Wrapping that into a simple exec()call is dead simple.

 

The categorization between compiled and interpreted isn't nearly as useful as it was 15 years ago.



#16 ApochPiQ   Moderators   -  Reputation: 15698

Like
1Likes
Like

Posted 26 February 2013 - 05:27 PM


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.

I disagree that this is the way a programmer should look at language choice. But it is true from an interpreter design perspective.

For a programmer choosing a language, an interpreted language is a language that's a bit slower, but provides rapid launch, since you don't need to compile and run. Even despite advances in compiler and interpreter, languages tend to be the determining factor in programmer priorities with respect to to runtime efficiency verses rapid development and other advantages of interpreted languages. If your only priority is speed, go native. If you want rapid development and security, go interpreted and managed.


I have no idea how what you said in any way disagrees with what I said.

My point is that languages are not "interpreted XOR compiled." My point is that most languages, especially today, fall somewhere in between. What you call "native" or "interpreted and managed" is meaningless. Is JITted C# native code? Is C++ interacting with the .Net framework via COM managed code?

#17 Bearhugger   Members   -  Reputation: 560

Like
1Likes
Like

Posted 26 February 2013 - 07:09 PM

Even for old technologies, there are a lot of gray zones.

 

Take a language like Visual Basic, for example. You write your program, hit Play and it starts right away, no compile or anything, and you can pause and edit the code anytime during debug, so interpreted, right? But wait, when you're ready to release it, you compile it directly to machine code as a .exe file and ship it as any other executable. So what is it?

 

In addition, Visual Basic has the Variant data type which is the default and behaves like a variable from interpreted languages (ie: a Javascript 'var') but it binds to the COM/OLE VARIANT datatype and needs no interpreter to make it work.

 

I tend to separate languages in 4 classes:

* Binary: Assembler. Self explanatory.

* Native: Compiled directly to machine code. (C, C++, Pascal, FORTRAN, etc.)

* Scripting languages: Compiled from text files at runtime. (Ruby, Python, JavaScript, VBScript, F#, Lua, etc.)

* Virtual machines: Compiled to intermediate bytecode and interpreted by a virtual machine at runtime. (Java, C#, VB.NET, J#.)

 

That still does not cover everything though. Objective-C, for example, compiles to machine code but it has a mini-virtual machine for handling the message dispatching and garbage collection. Visual Basic is an oddball as I have mentionned. Also, where does C++/CLI fit?



#18 Cornstalks   Crossbones+   -  Reputation: 6989

Like
0Likes
Like

Posted 26 February 2013 - 07:25 PM

* Virtual machines: Compiled to intermediate bytecode and interpreted by a virtual machine at runtime. (Java, C#, VB.NET, J#.)

C# is not interpreted by a virtual machine, and most implementations of Java are not either. Nor is VB.NET. I can't comment on J#, since I don't know it.
 
These languages are JIT. Yes, they're compiled into intermediate bytecode, but when you actually launch it, they are compiled into native machine code and run. They're not interpreted at runtime by a virtual machine.

 

Also, there are compilers for Python and many other "scripting" languages (so they're actually compiled straight to machine code). It's okay to point out that these scripting languages are often interpreted from a text file at runtime, but it's also important, given this thread's context, to point out that this isn't always the case, and there's nothing limiting these languages from being compiled into native machine code (well, the only limitation is that someone has to take the time to write such a compiler).


Edited by Cornstalks, 26 February 2013 - 07:29 PM.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#19 frob   Moderators   -  Reputation: 21233

Like
1Likes
Like

Posted 26 February 2013 - 07:27 PM

As others have tried to point out, your question doesn't make sense.

It is a false choice. It is not an either-or question.

Imagine these analogues:

A certain document is written in English; does that mean it was published in a book or instead published on a web site?
A certain automobile can go fast; does that mean it drives on regular roads or instead drives on a race track?
A certain fabric is soft and fluffy; does that mean it is used in clothing, or instead used for blankets?

The answer can be both, or neither, or a combination, all at once.
Check out my personal indie blog at bryanwagstaff.com.

#20 King Mir   Members   -  Reputation: 2000

Like
0Likes
Like

Posted 26 February 2013 - 08:26 PM


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".


The terminology is murky, but even if the call to exec does not have a pure interpreter phase, building a JIT compiler into your executable is as much a redundancy as building a pure interpreter into the executable. So it can be useful to call an implementation of exec that implements a runtime compiler as an interpreter. Regardless, the existence and possibility of exec is a characteristic indicative of an "interpreted language".

Edited by King Mir, 26 February 2013 - 08:27 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS