Ruby is interpreted and scripting language?

[Sai Babu]

I am ruby fresher.
i have studied that
"Ruby is a pure object oriented interpreted and scripting language".

I would like to know what is the difference between interpreted language
and scripting language???

Any Please Help Me???

 

[Imobach González Sosa]

I am ruby fresher.
i have studied that
"Ruby is a pure object oriented interpreted and scripting language".

I would like to know what is the difference between interpreted language
and scripting language???

Any Please Help Me???

I think they're different things. Ruby is an interpreted language in
the sense that Ruby code is interpreted and executed 'on the fly' by
the Ruby interpreter. You can read more about that subject in the
wikipedia[1].

About the 'scripting language' label I guess that it has to do with
the capabilities and simplicity of Ruby to be used to develop system
scripts and that kind of stuff. But nowadays I'm not sure if it's
applicable yet, because I think that Ruby work great for other
scenarios outside scripting.

But it's just my opinion and probably I'm terribly wrong

[1] http://en.wikipedia.org/wiki/Interpreted_language

--=20
Imobach Gonz=E1lez Sosa
imobachgs at gmail dot com

 

[Mike Stephens]

Once upon a time scripting referred to facilities that were rather
limited and typically providing a programmatic interface to another
application or operating system. They would mainly be interpreted.

What's happened since is it has become acceptable to have general
purpose languages which are not compiled so you get things like Ruby or
JavaScript which are much like traditional languages like C++ but are
also similar to yesterday's scripts in the sense you can just bring up
and editor, type a few lines and just run it without further messing
about.

People use the word 'script' in connection with Ruby but it
really has no significance.

 

[Mike Stephens]

Tim Roberts wrote in post #974545:

The most popular Ruby implementations are interpreted,
but there is nothing that would prevent it from being compiled.

Surely you can't ultimately compile Ruby? The essence of it is it is
dynamic so you don't know what the code will be until the point of
execution?

 

[Robert Klemme]

Tim Roberts wrote in post #974545:

Surely you can't ultimately compile Ruby? The essence of it is it is
dynamic so you don't know what the code will be until the point of
execution?

Well, the JVM proves that it's possible. You "only" need
sophisticated dependency tracking and need to recompile whenever a bit
of code changes.

Cheers

robert

 

[Jonas Pfenniger (zimbatm)]

Surely you can't ultimately compile Ruby? The essence of it is it is
dynamic so you don't know what the code will be until the point of
execution?

By doing static analysis, you can determine a lots of things that can
be compiled. The difference with a static language, are for the corner
cases, for example if you introduce a new method to a class, or load
new code into the VM, .... In these cases, you need a fallback.
Typically, the runtime includes an slower path for these cases, like
an interpreter, or an AOT compiler.

 

[Brian Nicar]

As I see it, a language that is interpreted utilizes a middle-man to make
calls to the system, allowing for greater flexibility when generating and
modifying code in a dynamic environment. The interpreter is compiled and
contains attributes that allow it to facilitate transactions with a 'script=
'
written in the proper lexicon. A balance is struck (hopefully) between the
speed / efficiency of a compiled program and the flexibility of one that is
executed on-the-fly.

Script merely refers to an informal style of writing. Handwriting for
example. Not particularly apt nowadays but it is not hard to see how the
designation came into being from a historical perspective. Down and dirty
comes to mind... ;>)

Cheers!

Brian

I am ruby fresher.
i have studied that
"Ruby is a pure object oriented interpreted and scripting language".

I would like to know what is the difference between interpreted languag= e
and scripting language???

Any Please Help Me???

I think they're different things. Ruby is an interpreted language in
the sense that Ruby code is interpreted and executed 'on the fly' by
the Ruby interpreter. You can read more about that subject in the
wikipedia[1].

About the 'scripting language' label I guess that it has to do with
the capabilities and simplicity of Ruby to be used to develop system
scripts and that kind of stuff. But nowadays I'm not sure if it's
applicable yet, because I think that Ruby work great for other
scenarios outside scripting.

But it's just my opinion and probably I'm terribly wrong

[1] http://en.wikipedia.org/wiki/Interpreted_language

 

[Robert Klemme]

I am ruby fresher.
i have studied that
"Ruby is a pure object oriented interpreted and scripting language".

I would like to know what is the difference between interpreted language
and scripting language???

"Interpreted" is an attribute of a /language implementation/ which
describes _how_ this implementation _executes programs_. "Scripting"
is an attribute of a /language/ which describes the usage of it. So
both are really orthogonal concepts although - as has been mentioned
before - scripting languages are often interpreted.

Earlier on there were basically only interpreters and compilers for
languages. Today the spectrum is much broader. We actually have
languages that are both at the same time; if you need an example, you
can look to Java: Java programs are usually compiled - to a specific
byte code. During execution this byte code is interpreter and hot
spots are compiled to native machine language. Actually if a class is
replaced the code will be interpreted again etc. So there are
multiple modes of operation. I am sure similar reasoning applies to
languages on CLR (Microsoft's version of a virtual machine).

Cheers

robert

 

[Oliver Schad]

Tim Roberts wrote in post #974545:

Surely you can't ultimately compile Ruby? The essence of it is it is
dynamic so you don't know what the code will be until the point of
execution?

That's pretty wrong of course from a theoretical point of view.

For example in C++ you can perfectly modifiy everything at runtime you
have full access to all data structures and code. So you can add methods
or kill them but you have to do it all by hand (find data structures in
memory, reallocate memory, reorganize the data structures, insert
machine code which you maybe did compile at runtime).

Regards
Oli

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

As I see it, a language that is interpreted utilizes a middle-man to make
calls to the system, allowing for greater flexibility when generating and
modifying code in a dynamic environment.

I'd say that's fairly close to my definition.

Compiled languages translate the source code into machine language and
execute it directly on the host CPU. Source code can either be compiled
ahead-of-time (e.g. with a compiler you invoke that outputs a host
executable) or just-in-time (JIT) as the programming language is executing.

Interpreted languages use a virtual machine or AST walker to perform the
execution. There can be an intermediate step wherein the source code is
translated to an intermediate bytecode.

Many language runtimes implement a hybrid of these two approaches, and start
by interpreting all code then finding "hot spots" via runtime profiling and
compiling those.

 

[Joseph Lenton]

My personal definition of a compiled language is one that is outputted
into a target code that is not a part of itself; regardless of if it is
machine code, intermediate byte code or source code for another
language.

An interpreter is then one where itself is the target; including if it
both uses an intermediate bytecode or just walks the program directly
executing it the fly. If it in turn targets another system, like
outputting native code, it's no longer an interpreter as it's not
targetting itself (and as it's using just-in-time compilation).

These days the term 'scripting language' is too ambiguous to have a real
formal definition (at least for general usage). It's more like lots of
scenarios that explain what people typically mean. To me it's any
language where the executable is stored as source code; like JavaScript,
PHP and Ruby. An example could be that if built a system where C++
source code is compiled on the fly before being executed (and so C++
source code are now executable applications) C++ becomes a scripting
language on that system.

But people also refer to scripting langauges as meaning glue code to use
seperate applications or components of a different system to complete a
task (like writing a bash script to merge files) or as an embeddable
language within a system (like Lua is often used for scripting games).
Although both of those examples can potentially fit into my first
definition.

 

[Brian Nicar]

[Note: parts of this message were removed to make it a legal post.]

I find this whole thread very interesting for the very validation that you
don't ask experts for advice. Everyone wants, to their credit, to provide
rich detail. Yet, the original question was from a noobie who does not (it
would seem) speak or write English very well (although, that could be my
misconception). Anyway, food for thought...

 

[Mike Stephens]

Brian Nicar wrote in post #974860:

I find this whole thread very interesting for the very validation that
you
don't ask experts for advice.

Brian, you seem to be saying that people have gone into too much depth.
That doesn't seem true to me but anyway surely that's what these sorts
of boards are all about?

 

[Rick DeNatale]

I'd say that's fairly close to my definition.

Compiled languages translate the source code into machine language and
execute it directly on the host CPU. Source code can either be compiled
ahead-of-time (e.g. with a compiler you invoke that outputs a host
executable) or just-in-time (JIT) as the programming language is executing.

Interpreted languages use a virtual machine or AST walker to perform the
execution. There can be an intermediate step wherein the source code is
translated to an intermediate bytecode.

Many language runtimes implement a hybrid of these two approaches, and start
by interpreting all code then finding "hot spots" via runtime profiling and
compiling those.

These are all really implementation choices rather than a
characteristic of the language itself.

Traditionally, a compiler was a separate program which translated
source code into linkable object code. The way you get an executable
module in a 'traditional way' is to run several units of source code
through one or more compilers, which one depending on the language of
each source code unit; then run the resulting object code units
through a linker (or linkage editor if you have an IBM heritage) to
produce loadable modules.

I think the 'scripting language' moniker started out as describing
things like Unix shell scripts, which didn't go through this process
but were directly executable, being interpreted by the shell. They
were viewed as languages for quick tasks, with real programs to be
written in real languages with a traditional tool chain.

It's interesting that even in this traditional view, even a language
like C goes through a "middle man to make calls to the system" in the
form of a standard subroutine library, at least some of which is
likely written in Assembly language. And that an assembler is really a
kind of compiler, albeit for a very low level language close to the
target hardware.

More and more, implementations bring the compiler and linker functions
inside the tent. There are variations on what kind of output the
'compiler' produces. Typically it's some form of machine instructions
for a higher level virtual machine rather than the real hardware.
There are implementations of languages like C which actual compile to
such a virtual machine, and not to hardware instructions. The
performance of such implementations can be surprising, since the
virtual machine instructions can be more compact, resulting in less
virtual memory overhead. There have also been implementations of
languages like Smalltalk which have compiled to machine instructions
rather than byte codes, and again the performance was surprising. For
example, back in the 1980s the folks at Digitalk (which later merged
with ParcPlace and I guess is now Cincom) got tired of hearing about
their Smalltalk V being 'interpreted' and came out with a release
which did just as I described, it generated 80286 machine
instructions. The result was that it actually ran slower than the
implementation which used byte codes, because it's quicker for a
virtual machine to execute byte codes which are already in real memory
rather than waiting for the faster machine code to be swapped in from
disk.

Thats one of the reasons why hot-spot is good, it makes a nice
speed/space tradeoff, keeping the working set smaller while allowing
frequently executed code to be re-compiled for speed.

There are various kinds of interpreter. Traditionally an interpreter
executes some internal representation of code, which might be an
abstract syntax tree, or threaded code, or the like. On the other
hand a virtual machine can be viewed as an interpreter of what are
loosely called byte codes, and in reality a hardware computer is an
interpreter of machine instructions.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale