[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Why Ruby interpreter is writed in c (not in c++)?

Ranieri Teixeira

7/11/2008 12:45:00 AM

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

Hi,
I've downloaded the sources of Ruby 1.8.7-p22 and compiled it with MS CL
compiler. Ok, very well. But, the code is in structured C, not in object
oriented C++. Why? C++ doesn't provides the sabe low level facilities as C
and the powerful abstractions, and good practices from the OOP paradigm?
Thanks

--
Ranieri Barros Teixeira
UFPA - FACOMP - CBCC
http://multiligado.blo...
21 Answers

Phlip

7/11/2008 1:33:00 AM

0

Ranieri Teixeira wrote:

> I've downloaded the sources of Ruby 1.8.7-p22 and compiled it with MS CL
> compiler.

What a pain! Next time, get CygWin, and compile with GNU C.

> Ok, very well. But, the code is in structured C, not in object
> oriented C++. Why? C++ doesn't provides the sabe low level facilities as C
> and the powerful abstractions, and good practices from the OOP paradigm?

All system-level engines are written in C, not C++. C has been a Standard for
much longer, and has more compliant compilers. So any engine that wants to run
on the widest number of platforms must use C. It compiles for everything from
wristwatches to Mars Rovers.

The point of OOP is rapid code changes. That contradicts the goal of
super-widespread portability. No matter what your language, you must
chose one or the other, not both. And Ruby is indeed coded in Object
Oriented C. The ++ does not magically make every program OO.

C++ would not necessarily make Ruby easier to code; C++ objects can never map
directly onto Ruby objects.

--
Phlip

John Joyce

7/11/2008 2:46:00 AM

0


On Jul 10, 2008, at 8:31 PM, phlip wrote:

> Ranieri Teixeira wrote:
>
>> I've downloaded the sources of Ruby 1.8.7-p22 and compiled it with
>> MS CL
>> compiler.
>
> What a pain! Next time, get CygWin, and compile with GNU C.
>
> > Ok, very well. But, the code is in structured C, not in object
>> oriented C++. Why? C++ doesn't provides the sabe low level
>> facilities as C
>> and the powerful abstractions, and good practices from the OOP
>> paradigm?
>
> All system-level engines are written in C, not C++. C has been a
> Standard for much longer, and has more compliant compilers. So any
> engine that wants to run on the widest number of platforms must use
> C. It compiles for everything from wristwatches to Mars Rovers.
>
> The point of OOP is rapid code changes. That contradicts the goal of
> super-widespread portability. No matter what your language, you must
> chose one or the other, not both. And Ruby is indeed coded in Object
> Oriented C. The ++ does not magically make every program OO.
>
> C++ would not necessarily make Ruby easier to code; C++ objects can
> never map directly onto Ruby objects.
>
> --
> Phlip
>
But Objective-C may soon.... MacRuby....

Dave Bass

7/11/2008 11:12:00 AM

0

phlip wrote:
> All system-level engines are written in C, not C++.
> ...
> It compiles for everything from wristwatches to Mars Rovers.

This is because object-orientation is unnecessary. Any job you can do
with it, you can do without it.

Those of us who have worked on large programs in Fortran, C and
assembler know that it's easy to write excellent software in an
imperative style, as you long as you have the discipline to structure
your data and program code sensibly.

OO is the latest fashion, but something else will come along soon, and
we'll all be deprecating OO.
--
Posted via http://www.ruby-....

Eleanor McHugh

7/11/2008 12:39:00 PM

0

On 11 Jul 2008, at 12:12, Dave Bass wrote:
> phlip wrote:
>> All system-level engines are written in C, not C++.
>> ...
>> It compiles for everything from wristwatches to Mars Rovers.
>
> This is because object-orientation is unnecessary. Any job you can do
> with it, you can do without it.
>
> Those of us who have worked on large programs in Fortran, C and
> assembler know that it's easy to write excellent software in an
> imperative style, as you long as you have the discipline to structure
> your data and program code sensibly.

Very true, although a large program in assembler is often a much
smaller program when rephrased in C and likewise when the C is
rephrased in C++. That's the primary win with OO - it reduces the
volume of code and hence eases the strain of remembering that code in
detail.

> OO is the latest fashion, but something else will come along soon, and
> we'll all be deprecating OO.

I'm not sure it will be superseded any time soon, objects being a very
natural way for people to think about real-world problems.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-...
----
raise ArgumentError unless @reality.responds_to? :reason

David A. Black

7/11/2008 12:50:00 PM

0

Hi --

On Fri, 11 Jul 2008, Eleanor McHugh wrote:

> On 11 Jul 2008, at 12:12, Dave Bass wrote:
>> phlip wrote:
>>> All system-level engines are written in C, not C++.
>>> ...
>>> It compiles for everything from wristwatches to Mars Rovers.
>>
>> This is because object-orientation is unnecessary. Any job you can do
>> with it, you can do without it.
>>
>> Those of us who have worked on large programs in Fortran, C and
>> assembler know that it's easy to write excellent software in an
>> imperative style, as you long as you have the discipline to structure
>> your data and program code sensibly.
>
> Very true, although a large program in assembler is often a much smaller
> program when rephrased in C and likewise when the C is rephrased in C++.
> That's the primary win with OO - it reduces the volume of code and hence
> eases the strain of remembering that code in detail.
>
>> OO is the latest fashion, but something else will come along soon, and
>> we'll all be deprecating OO.
>
> I'm not sure it will be superseded any time soon, objects being a very
> natural way for people to think about real-world problems.

I wonder, though. I think I think procedurally. With lots of rescue
clauses :-)


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails July 21-24 Edison, NJ
Advancing With Rails August 18-21 Edison, NJ
See http://www.r... for details and updates!

Eleanor McHugh

7/11/2008 1:07:00 PM

0

On 11 Jul 2008, at 02:31, phlip wrote:
> Ranieri Teixeira wrote:
>
>> I've downloaded the sources of Ruby 1.8.7-p22 and compiled it with
>> MS CL
>> compiler.
>
> What a pain! Next time, get CygWin, and compile with GNU C.
>
> > Ok, very well. But, the code is in structured C, not in object
>> oriented C++. Why? C++ doesn't provides the sabe low level
>> facilities as C
>> and the powerful abstractions, and good practices from the OOP
>> paradigm?
>
> All system-level engines are written in C, not C++. C has been a
> Standard for much longer, and has more compliant compilers. So any
> engine that wants to run on the widest number of platforms must use
> C. It compiles for everything from wristwatches to Mars Rovers.

It may well compile for them, but there are systems where even diet
libc would be too heavy a runtime requirement which is why many
embedded applications still use assembly language.

> The point of OOP is rapid code changes. That contradicts the goal of
> super-widespread portability. No matter what your language, you must
> chose one or the other, not both.

The point of OOP is that it cleanly encapsulates code and data to form
discrete black boxes. This makes it easier to design complex systems
and ideally reduces the volume of code which has to be remembered.
This can have the added benefit of enabling rapid code changes, but
it's by no means the main advantage.

The slow uptake of C++ for system-level coding owes much to the
historic poor performance of compilers in optimising virtual function
calls and the memory footprint of the runtime. In recent years both
considerations have become less important, but in the embedded sector
there is still a preference for assembly language and imperative
languages such as C or BASIC.

However even in the mid-90's people were demonstrating that C++ could
be every bit as speedy as C in real-world applications where memory
footprint was of lesser importance. Go play with a copy of BeOS which
was written in C++ and you'll see what I mean: it was running rings
around both the MacOS and Windows of its day. It was also portable,
being compilable with the Metrowerks compiler on PowerPC and GCC 2.95
on x86.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-...
----
raise ArgumentError unless @reality.responds_to? :reason

Eleanor McHugh

7/11/2008 1:09:00 PM

0

On 11 Jul 2008, at 13:50, David A. Black wrote:
> On Fri, 11 Jul 2008, Eleanor McHugh wrote:
>> On 11 Jul 2008, at 12:12, Dave Bass wrote:
>>> OO is the latest fashion, but something else will come along soon,
>>> and
>>> we'll all be deprecating OO.
>>
>> I'm not sure it will be superseded any time soon, objects being a
>> very natural way for people to think about real-world problems.
>
> I wonder, though. I think I think procedurally. With lots of rescue
> clauses :-)

Ruby-- perhaps ?;)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-...
----
raise ArgumentError unless @reality.responds_to? :reason

Phlip

7/11/2008 2:24:00 PM

0

Dave Bass wrote:

> phlip wrote:

>> All system-level engines are written in C, not C++.
>> ...
>> It compiles for everything from wristwatches to Mars Rovers.
>
> This is because object-orientation is unnecessary. Any job you can do
> with it, you can do without it.

Of course. The C source to Ruby has no OO. It just has lots of functions that
strictly apply to structures that might be of base or derived types, using
function pointers to override things.

Nope. No OO there!

--
Phlip

ara.t.howard

7/11/2008 2:29:00 PM

0


On Jul 10, 2008, at 11:57 PM, M. Edward (Ed) Borasky wrote:

> I'm not sure C++ is any less portable than C, especially if you
> consider the widespread use of the Gnu Compiler Collection.


my experience is that it really is. a few years back a group i worked
for moved from c++ to java for one reason: portability. the code they
wrote needed to run on machines all over the world and, despite the
fact that most pcs have good compilers there are still a lot of
servers and mainframes out there running scientific systems which do
not. it actually came as a surprise to me at the time.

fyi.

a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama

Eleanor McHugh

7/11/2008 2:51:00 PM

0

On 11 Jul 2008, at 15:23, M. Edward (Ed) Borasky wrote:
> Eleanor McHugh wrote:
>>> All system-level engines are written in C, not C++. C has been a
>>> Standard for much longer, and has more compliant compilers. So any
>>> engine that wants to run on the widest number of platforms must
>>> use C. It compiles for everything from wristwatches to Mars Rovers.
>> It may well compile for them, but there are systems where even diet
>> libc would be too heavy a runtime requirement which is why many
>> embedded applications still use assembly language.
>
> There's also another light-weight libc -- I forget the name, but
> there is a whole "buildroot" toolchain as well for embedded systems.
> Then, of course, there's Forth, which usually has an assembler built
> in.

Not to mention Forth can be compiled to a very minimal memory
footprint if necessary - even with OO extensions.

>> The point of OOP is that it cleanly encapsulates code and data to
>> form discrete black boxes. This makes it easier to design complex
>> systems and ideally reduces the volume of code which has to be
>> remembered. This can have the added benefit of enabling rapid code
>> changes, but it's by no means the main advantage.
>> The slow uptake of C++ for system-level coding owes much to the
>> historic poor performance of compilers in optimising virtual
>> function calls and the memory footprint of the runtime. In recent
>> years both considerations have become less important, but in the
>> embedded sector there is still a preference for assembly language
>> and imperative languages such as C or BASIC.
>
> There actually was a time when even the use of C was in doubt for
> embedded systems. An awful lot of Forth, Pascal, PL/M and assembler
> code was written before C compilers were good enough. Now, of
> course, the C compilers are good enough to build a high-performance
> Forth environment in C. :)

Heretic ;p


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-...
----
raise ArgumentError unless @reality.responds_to? :reason