Eleanor McHugh wrote:
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
Bil K. wrote:
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
-
Rumor has it that Rubinius is migrating towards LLVM, which is also
written in C++.
-
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
Eleanor McHugh 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.
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 F. wrote:
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.
On 11/07/2008, M. Edward (Ed) Borasky [email protected] wrote:
I’m not sure C++ is any less portable than C, especially if you consider
the widespread use of the Gnu Compiler Collection.
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
Michal S. wrote:
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.
Which is why Ruby’s source is compatible with K&R C - before even
prototypes.