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???
--
Posted via http://www.ruby-forum.com/.
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] Interpreter (computing) - Wikipedia
2011/1/13 Sai Babu <sateesh.mca09@gmail.com>:
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
imobachgs at gmail dot com
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.
--
Posted via http://www.ruby-forum.com/.
The question doesn't really make sense. "Interpreted" and "scripting" are
just two attributes that can apply to languages. Many scripting languages
are interpreted.
Both of those terms are somewhat controversial. The term "scripting
language" doesn't really mean anything. Many languages can be used to
write scripts, depending on how you define "script".
Also, "interpreted" really describes a particular implementation, not the
language itself. The most popular Ruby implementations are interpreted,
but there is nothing that would prevent it from being compiled. There are
several C interpreters available, even though C is usually compiled.
Sai Babu <sateesh.mca09@gmail.com> wrote:
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???
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
"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
On Thu, Jan 13, 2011 at 5:00 AM, Sai Babu <sateesh.mca09@gmail.com> wrote:
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???
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
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.
--
Posted via http://www.ruby-forum.com/.
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?
--
Posted via http://www.ruby-forum.com/\.
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
2011/1/12 Imobach González Sosa <imobachgs@gmail.com>
2011/1/13 Sai Babu <sateesh.mca09@gmail.com>:
> 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] Interpreter (computing) - Wikipedia
--
Imobach González Sosa
imobachgs at gmail dot com
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...
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
On Thu, Jan 13, 2011 at 11:05 AM, Mike Stephens <rubfor@recitel.net> wrote:
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?
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
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.
2011/1/13 Mike Stephens <rubfor@recitel.net>:
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?
Mike Stephens wrote:
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?
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
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
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.
On Thu, Jan 13, 2011 at 8:16 AM, Brian Nicar <surprisevalley@verizon.net>wrote:
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.
--
Tony Arcieri
Medioh! Kudelski
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?
--
Posted via http://www.ruby-forum.com/\.
There already are Python compilers, and I would assert that Ruby contains
no fundamentally different concepts.
IronRuby is compiled, although admittedly in two steps.
Mike Stephens <rubfor@recitel.net> wrote:
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?
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
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.
On Thu, Jan 13, 2011 at 1:58 PM, Tony Arcieri <tony.arcieri@medioh.com> wrote:
On Thu, Jan 13, 2011 at 8:16 AM, Brian Nicar <surprisevalley@verizon.net>wrote:
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.
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale