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 T. 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 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.
There are actually starting to be some decent “system-level engines”
written in C++, and their authors have, IMHO, made compelling arguments
in favor of C++ over C. Two that stand out in my mind are the L4/OKL4
microkernels, and the Low Level Virtual Machine (LLVM) projects. Both
are open source, and if you’re interested, you can hunt down their web
sites and see why they chose C++ over C.
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.
I’m not sure C++ is any less portable than C, especially if you consider
the widespread use of the Gnu Compiler Collection.
M. Edward (Ed) Borasky
http://ruby-perspectives.blogspot.com/
“A mathematician is a machine for turning coffee into theorems.” –
Alfréd Rényi via Paul Erdős
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.
On Jul 10, 2008, at 8:31 PM, phlip wrote:
facilities as C
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…
On 11 Jul 2008, at 12:12, Dave B. wrote:
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
raise ArgumentError unless @reality.responds_to? :reason
On 11 Jul 2008, at 02:31, phlip wrote:
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-brains.net
raise ArgumentError unless @reality.responds_to? :reason
Hi –
On Fri, 11 Jul 2008, Eleanor McHugh wrote:
assembler know that it’s easy to write excellent software in an
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
On 11 Jul 2008, at 13:50, David A. Black wrote:
clauses
Ruby-- perhaps ?
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
raise ArgumentError unless @reality.responds_to? :reason
Dave B. 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!
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.
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. 
M. Edward (Ed) Borasky
http://ruby-perspectives.blogspot.com/
“A mathematician is a machine for turning coffee into theorems.” –
Alfréd Rényi via Paul Erdős
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.
ara.t.howard wrote:
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.
Java is also easier to read and write than C++ – a lot easier. And
I’ll bet a definition of a brass monkey that there were two camps. One
wanted to write C++ because it was faster than Java and the other wanted
to write Java because it was easier to read and write and more portable.
In the case of Windows PCs / Servers, there are definitely some “seams”
in C/C++ relative to Unix and, if it matters, VMS.
M. Edward (Ed) Borasky
http://ruby-perspectives.blogspot.com/
“A mathematician is a machine for turning coffee into theorems.” –
Alfréd Rényi via Paul Erdős
On 11 Jul 2008, at 15:23, M. Edward (Ed) Borasky wrote:
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.
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-brains.net
raise ArgumentError unless @reality.responds_to? :reason
On 11 Jul 2008, at 16:10, M. Edward (Ed) Borasky wrote:
Eleanor McHugh wrote:
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 ;pI’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
raise ArgumentError unless @reality.responds_to? :reason
Eleanor McHugh wrote:
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
I’m not the heretic – the heretics are the people who added “labels as
values” to gcc, and the gForth team that exploited it.
http://www.complang.tuwien.ac.at/forth/threaded-code.html
–
M. Edward (Ed) Borasky
http://ruby-perspectives.blogspot.com/
“A mathematician is a machine for turning coffee into theorems.” –
Alfréd Rényi via Paul Erdős
phlip wrote:
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.
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.
Ranieri T. wrote:
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…)
Ranieri T. wrote:
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?
-
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. -
Rubinius’ core VM is currently in C++ – see rubinius c++ - Google Search
Regards,