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.blogspot.com/
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
Ranieri Teixeira 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?
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 rubinius c++ - Google Search
Regards,
--
Bil Kleb
Ranieri Teixeira wrote:
[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.
Thanks
--
Ron Fox
NSCL
Michigan State University
East Lansing, MI 48824-1321
But Objective-C may soon.... MacRuby....
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
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.
--
Posted via http://www.ruby-forum.com/\.
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-brains.net
On 11 Jul 2008, at 02:31, phlip wrote:
----
raise ArgumentError unless @reality.responds_to? :reason
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.
On Thu, Jul 10, 2008 at 10:31 PM, phlip <phlip2005@gmail.com> 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
--
Ranieri Barros Teixeira
UFPA - FACOMP - CBCC
http://multiligado.blogspot.com/
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.
--
Posted via http://www.ruby-forum.com/\.
Bil Kleb wrote:
Ranieri Teixeira 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?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 rubinius c++ - Google Search
1. Rumor has it that Rubinius is migrating towards LLVM, which is also written in C++.
2. I think Ruby was born in the mid-to-late gcc 2 era, and I think maybe even gcc 2.9.5 was available. gcc runs just about everywhere, and was often competitive with "native" compilers even back then. I think gcc 4.3.1 still runs on a Motorola 68000, or at least will cross-compile to it. 
I'd think the real sticking point would have been the *Microsoft* compilers. Microsoft C with a POSIX library is relatively similar to most of the rest of the world, but Microsoft C++ is a whole other ballgame. And I think back then, Microsoft was still deluding themselves and the rest of the world that Windows NT on an Alpha was a viable product.
Speaking of which, one of the things that killed Windows NT (4) and its successors on Alphas was the fact that they had severe performance problems, which came from the fact that they were emulating Intel hardware for some time-critical operations. "Premature optimization is the root of all evil." "Hardware is cheaper than programmers." Yeah, right.
--
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.
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
On 11 Jul 2008, at 12:12, Dave Bass wrote:
----
raise ArgumentError unless @reality.responds_to? :reason
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
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.
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.
--
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
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.
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.
--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama
Ranieri Teixeira 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...)
Even GCC does not run everywhere.
And what's worse, for every older C++ project you need appropriate
vintage of GCC (or whatever compiler the authors used). There are both
binary-level and source-level differences between different major (and
even minor) versions of GCC. This is because the standard was (is?)
relatively rapidly evolving, and the compilers could not pick up the
changes and fix all deficiencies, or conform in all areas that were
newly standardised immediately.
Thanks
Michal
On 11/07/2008, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
I'm not sure C++ is any less portable than C, especially if you consider
the widespread use of the Gnu Compiler Collection.
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.rubypal.com for details and updates!
ara.t.howard 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.
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.
On Jul 10, 2008, at 11:57 PM, M. Edward (Ed) Borasky wrote:
--
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
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-brains.net
On 11 Jul 2008, at 15:23, M. Edward (Ed) Borasky wrote:
----
raise ArgumentError unless @reality.responds_to? :reason