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

[Ranieri Teixeira]

[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

 

[phlip]

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.

 

[John Joyce]

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


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.

But Objective-C may soon.... MacRuby....

 

[Dave Bass]

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.

 

[Eleanor McHugh]

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

 

[David A. Black]

Hi --

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.


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

 

[Eleanor McHugh]

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


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

 

[Eleanor McHugh]

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

 

[phlip]

phlip wrote:

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!

 

[ara.t.howard]

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://codeforpeople.com/

 

[Eleanor McHugh]

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.

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

 

[Eleanor McHugh]

I'm not the heretic -- the heretics are the people who added "labels
as values" to gcc, and the gForth team that exploited it.

I never did understand why both K&R and ANSI-C lacked computed gotos -
it's not like C does much else to protect a programmer

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Ranieri Teixeira]

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

Thank you Philip.
I'm happy with you reply. My dream is to have a full UNIX compliant machine
to start developing C software, like the good Ruby.
CygWin does that miracle for me?
Thank you for your time and att.

 

[Lloyd Linklater]

The point of OOP is rapid code changes.

Actually, the point of OOP is that the old procedural approach led to
unwieldy programs when it was but a few hundred thousand lines long. It
adds stricter controls and code changes were easier to do.

OOP languages have more overhead. Low level work, like system level
stuff, needs to be as lean and mean as possible because it is used so
much. e.g. If you had a well written application but the one loop that
runs many many times for each thing it did turned out to be bloated it
would slow everything down. The foundation needs to be as clean as
possible. That gives the developer the freedom to write junk code at
the high levels and still have a tenable program.

 

[phlip]

CygWin does that miracle for me?

CygWin is the GNU toolkit ported to Windows. It gives you Bash, X, gcc, g++, and
all the toys that Linux & BSD programmers enjoy.

It also comes with a non-heinous Ruby, but I don't know how the others here
would recommend that, because I only use it for trivia. You can also use CygWin
in conjunction with the Windows One Click Installer Ruby.

(I install Linux on every box and notebook that gets near me, except the one box
I keep legacy versions of MS Office and Visual Studio on...)

 

[Bil Kleb]

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?

1) Ruby was born long before C++ compilers were even close to portable,
and according to Ara, they weren't portable even a few years ago.

2) Rubinius' core VM is currently in C++ -- see http://is.gd/RJE

Regards,

 

[Dave Bass]

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.

It may be natural for some people, but I have to force myself into
trying to think in an OO way. I think procedurally, but that may well be
a result of too much Fortran, Basic and assembler in my formative years.
;-)

It seems very natural to me to say "Here's some data; perform this
process on it". I like to think of data as analogous to nouns, and
procedures as analogous to verbs. So "process(data)" seems like English
to me, very natural.

Most of my programs have this form:
- Input some data
- Process it
- Output the result

but that might just be the sort of programming I do (engineering and web
mostly). In an OO language like Java or Ruby I tend to do this sort of
thing:

dp = DataProcessor.new
dp.load(data)
dp.process
results = dp.get_output

Not very OO-orthodox, I suspect.

Dave

 

[Ron Fox]

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.

Close but not really. The primary purpose of OO is that it provide a
higher level of abstraction than C does. One that can get closer to
the problem being solved than C does in natural use.

This >can< result in less code, but the main win is that it results in
a better mapping of the program to the problem, and a better
understanding of the program by the programmers.

Naturally, all of this assumes you know what you are doing

 

[Ron Fox]

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

Because the implementers made that design choice.

 

[phlip]

Close but not really. The primary purpose of OO is that it provide a
higher level of abstraction than C does. One that can get closer to the
problem being solved than C does in natural use.

This >can< result in less code, but the main win is that it results in a
better mapping of the program to the problem, and a better understanding
of the program by the programmers.

You describe an "Object Based" system.

The main win of an OOP is virtual methods have language support, reducing the
odds of a misfire when you override a method. The alternative is messy function
pointers that might point to garbage, or NULL.

Overriding methods, in turn, allow old code to call new code, so you can easily
change a program by adding to its lists of concrete classes, while leaving the
abstract classes alone. The "Open Closed Principle".

This benefit makes code harder to read and understand, not easier.