On Feb 11, 2:57 am, “William J.” [email protected] wrote:
RAM running gentoo with entire system compiled with
let bailout = 4.0
if zi2 + zr2 > bailout then
let i = iterate
done;
print_endline “”;
System.Console.Write (Sys.time () - start_time);
print_endline “”;
This is over twice as fast as the OCaml version.
F# is impressive.
On 10.02.2009 19:42, David M. wrote:
It does, actually, assuming you called it with a hash of options. Perl
objects are most commonly a blessed hash.
That’s the first flaw of Perl’s OO: you have the free choice to use
hashes or arrays (or even scalars?) as objects.
a user from passing in a function to override one of mine, thus creating a
b: 12345,
that both Foo and Bar are classes, each of which may have methods of
their own – in this case, Bar’s methods (or properties) override Foo’s.
Really? I’d say they are overridden by Foo’s because this comes later.
But I’m not a JavaScript expert.
To get something even close in Ruby, I’d have to do this:
f = OpenStruct.new
class << f
def c
#some method
end
end
No. This is a one off shot. To get the equivalent of the JavaScript
version (if my JS does not fail me), you need to define a method which
does the initialization, e.g.
def Foo(o = Object.new)
class <<o
attr_accessor :bar, :baz
def c
printf "bar=%4d, baz=%4d\n", bar, baz
end
end
o.bar = 123
o.baz = 890
o
end
Then you can do
x = Foo
y = Foo(Bar.new)
z = Foo(any_other_expression)
Although I have to say that I’d rather package this in a module and do
module Foo
def self.create(o = Object.new)
o.extend(self)
o.bar = 123
o.baz = 890
o
end
attr_accessor :bar, :baz
def c
printf “bar=%4d, baz=%4d\n”, bar, baz
end
end
The details really do not matter. My point is simply this: I prefer to
use Ruby over Perl because of the clean syntax as well as the profound
OO. And I still have all (or at least most of) the options I have in
Perl’s bare metal world. I find the balance in Ruby highly superior.
Because in Ruby hackery (or call it “metaprogramming”) is an add on,
i.e. you can use it in special situations, while in Perl you need to
do it to get basic things (OO) to work.There are, however, libraries to make the OO less painful in Perl.
Which still makes them non core artifacts and leave the option for
multiple OO models in the same program. Doesn’t sound healthy to me.
Now, not doing that often is probably a good idea – not using
Kernel#eval often might also be a good idea. But I don’t like it when a
tool tells me what I may or may not do, simply because it’s not a good idea.
Maybe you haven’t come to appreciate the power gained from restriction.
Often more creativity and productivity is unleashed in more restricted
environments.
I’m not trying to sell Perl’s OO as the best thing, or even “better”.
But I’m defending it as inherently less useful than Ruby’s.
Is this really what you intended to say?
Someone
might as easily say that Ruby’s OO is inherently less useful than
Java’s, because Java does stricter (static) type-checking.
As always it depends on the point of view - or the criteria you apply.
I do mostly OO programming - even in scripts - and for that I appreciate
the way OO is done much more than Perl’s way.
Cheers
robert
On 09/02/2009, David M. [email protected] wrote:
variables – so why should ‘self’ be exempted from the “quacks like” rule?
Actually you sort of can except the binding is not permanent.
module Kernel
module Q175
Require = Kernel.instance_method :require
def scan
…
end
end
undef_method :require
def require file
loc = Q175::scan file
res = Q175::Require.bind(self).call file
STDERR.puts “require: #{file} => #{loc}” if res && loc
res
end
end
Thanks
Michal
Michal S. wrote:
theme? After all, what ties the method to the object – isn’t it mostly
going to be calling instance methods, and occasionally accessing instance
variables – so why should ‘self’ be exempted from the “quacks like” rule?Actually you sort of can except the binding is not permanent.
No, I don’t think so. I’ve tried in a method somewhat similar to yours,
and I get the same results.
module Kernel
That’s probably why. Everything includes Kernel, so if you grab an
UnboundMethod from Kernel, you should be able to apply it everywhere.
Try this:
module Foo
def foo
:foo #ok, I’m unimaginative
end
end
Foo.instance_method(:foo).bind(Object.new).call
See what happens? Doesn’t matter whether Foo is a class or a module, you
can only bind methods of it to objects which are somehow its
descendants. If it’s a module, you can only do this to things which have
included that module, making it somewhat less useful.
Speaking of which, modifying Kernel – yet another thing more dangerous
than letting UnboundMethods bind to anything.
Robert K. wrote:
But this does not set properties, does it?
It does, actually, assuming you called it with a hash of options.
Perl objects are most commonly a blessed hash.That’s the first flaw of Perl’s OO: you have the free choice to use
hashes or arrays (or even scalars?) as objects.
Why is this a flaw? In Ruby, everything’s an object. On closer
examination, we use instance variables in objects more or less the same
way a Perl object would use hash members.
thus creating a spontaneous new child of both Foo and Bar. Keep in
mind that both Foo and Bar are classes, each of which may have
methods of their own – in this case, Bar’s methods (or properties)
override Foo’s.Really? I’d say they are overridden by Foo’s because this comes
later. But I’m not a JavaScript expert.
Since Foo is a user-definable function, it’s actually entirely up to the
author of said function. I believe the sample I gave was using the
argument to override defaults in Foo.
To get something even close in Ruby, I’d have to do this:
f = OpenStruct.new
class << f
def c
#some method
end
endNo. This is a one off shot.
You’re right. I was simplifying.
end
o.bar = 123
o.baz = 890o
end
I suppose that is roughly equivalent. I would have chosen something
else, like:
module Foo
def a
…
end
…
end
def foo(o = Object.new)
o.send :include, Foo
end
So, you can get close with something like:
foo(
OpenStruct.new(
:a => ‘some_string’,
:b => 12345
).extend(Module.new {
def c
# some method
end
})
)
I don’t know about you, but that reads a lot less naturally to me.
Fortunately, Ruby is flexible enough that if I really wanted it, I could
probably define some DSL that does the right thing – something like:
foo(MyStruct.new {
a ‘some_string’
b 12345
c do
# some method
end
})
The details really do not matter. My point is simply this: I prefer
to use Ruby over Perl because of the clean syntax as well as the
profound OO. And I still have all (or at least most of) the options I
have in Perl’s bare metal world. I find the balance in Ruby highly
superior.
I agree. Or rather, not so much because the OO is profound, but because
it is much cleaner to access, for most things.
Because in Ruby hackery (or call it “metaprogramming”) is an add on,
i.e. you can use it in special situations, while in Perl you need to
do it to get basic things (OO) to work.There are, however, libraries to make the OO less painful in Perl.
Which still makes them non core artifacts and leave the option for
multiple OO models in the same program.
I don’t see that being more of a problem than duck typing vs other
models in Ruby.
If you want to be consistent within a program, write up a coding style
for that program. If you want your language to enforce a coding style,
Java and Python will each do that for you, in their own ways.
Now, not doing that often is probably a good idea – not using
Kernel#eval often might also be a good idea. But I don’t like it when
a tool tells me what I may or may not do, simply because it’s not a
good idea.Maybe you haven’t come to appreciate the power gained from
restriction. Often more creativity and productivity is unleashed in
more restricted environments.
Like Picasso’s Blue Period, I get it. And it can certainly be useful for
learning.
I still don’t see why it’s good for the environment to do that
restriction, rather than making it self-imposed. Certainly, I almost
never allow myself to use eval, and my code is better for it – but note
that key word. Almost never.
I’m not trying to sell Perl’s OO as the best thing, or even “better”.
But I’m defending it as inherently less useful than Ruby’s.Is this really what you intended to say?
Probably not. Probably “defending it as not inherently less useful…”
Someone might as easily say that Ruby’s OO is inherently less useful
than Java’s, because Java does stricter (static) type-checking.As always it depends on the point of view - or the criteria you apply.
I do mostly OO programming - even in scripts - and for that I
appreciate the way OO is done much more than Perl’s way.
I do mostly OO programming, and I prefer Ruby – but as a matter of
taste. I’ve just had enough experience with Perl to respect it, too,
even its object system.
I’ve also had enough experience with PHP to lose all respect for it…
The problem with PHP is they have absolutely no taste. (Apologies to
Steve Jobs.)
William J. wrote:
seconds. This is an Intel® Core™2 CPU 6320 @ 1.86GHz box w 2GB
RAM running gentoo with entire system compiled with
CFLAGS="-march=prescott -O2 -g -pipe" + feature splitdebug (
everything compiled with debug except mandInC ). -rwxr-xr-x 1
rthompso staff 7104 2009-02-10 23:36 mandInCTo make timing more accurate, let’s calculate the set 100 times
but draw it only 1 time.Result: 1.99286559999999 (laptop with 2GHz Pentium M)
Echo delay is 2s and 23737us
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
/**
this function is for computing the time difference between timeval x
and y
the result is stored in result
*/
int
timeval_subtract (struct timeval *result, struct timeval *x, struct
timeval y)
{
/ Perform the carry for the later subtraction by updating y. */
if (x->tv_usec < y->tv_usec) {
int nsec = (y->tv_usec - x->tv_usec) / 1000000 + 1;
y->tv_usec -= 1000000 * nsec;
y->tv_sec += nsec;
}
if (x->tv_usec - y->tv_usec > 1000000) {
int nsec = (x->tv_usec - y->tv_usec) / 1000000;
y->tv_usec += 1000000 * nsec;
y->tv_sec -= nsec;
}
/* Compute the time remaining to wait.
tv_usec is certainly positive. */
result->tv_sec = x->tv_sec - y->tv_sec;
result->tv_usec = x->tv_usec - y->tv_usec;
/* Return 1 if result is negative. */
return x->tv_sec < y->tv_sec;
}
int iterate (double x, double y)
{
int BAILOUT = 16;
int MAX_ITERATIONS = 1000;
double cr = y-0.5;
double ci = x;
double zi = 0.0;
double zr = 0.0;
double zr2 = 0.0;
double zi2 = 0.0;
int i = 0;
double temp = 0.0;
while (1)
{
i += 1;
temp = zr * zi;
zr2 = zr * zr;
zi2 = zi * zi;
zr = zr2 - zi2 + cr;
zi = temp + temp + ci;
if ( zi2 + zr2 > BAILOUT)
{
return i;
}
if ( i > MAX_ITERATIONS)
{
return 0;
}
}
}
int main()
{
int y = -39;
int x = -39;
int i = -1;
int loop = 1;
struct timeval start, stop, echodelay; // start, stop and echo
delay times
if((gettimeofday(&start, NULL)) == -1)
{
perror("gettimeofday");
exit(1);
}
for (loop == 1; loop <= 100; ++loop)
{
for (y = -39; y <= 39; ++y)
{
if (loop == 1){printf("\n");}
for (x = -39; x <= 39; ++x)
{
i = iterate(x/40.0, y/40.0);
if (loop == 1)
{
if (i == 0)
printf("*");
else
printf(" ");
}
}
}
}
if((gettimeofday(&stop, NULL)) == -1)
{
perror("gettimeofday");
exit(1);
}
/* compute time delay */
timeval_subtract(&echodelay, &stop, &start);
printf("\nEcho delay is %ds and %dus\n", echodelay.tv_sec,
echodelay.tv_usec);
return 0;
}
William J. wrote:
seconds. This is an Intel® Core™2 CPU 6320 @ 1.86GHz box w 2GB
RAM running gentoo with entire system compiled with
CFLAGS="-march=prescott -O2 -g -pipe" + feature splitdebug (
everything compiled with debug except mandInC ). -rwxr-xr-x 1
rthompso staff 7104 2009-02-10 23:36 mandInCTo make timing more accurate, let’s calculate the set 100 times
but draw it only 1 time.Result: 1.99286559999999 (laptop with 2GHz Pentium M)
mono + F# = 3.919404 ( hits 3.9x… range consistently)
On Thu, Feb 12, 2009 at 04:52:50AM +0900, David M. wrote:
But I think that’s getting even more offtopic, so to bring it back to
Ruby… The one piece that really seems out of place is the Regex
syntax, but I can’t complain. Everything else, whether pure or not,
comes together in such a way as to make it easy to turn it into whatever
you need – Markaby is another example of why not to build templating
into the core language. Why put something in the core language when it
can be done in a DSL?
My attitude is that PHP is a DSL. It actually started out as a DSL
written in Perl, in fact – then spun off into its own monstrosity,
notable in positive respects just for its eventual ubiquity and the fact
it ran faster on its own than it did as a Perl library. I guess that’s
just one man’s opinion, though.
On Thu, Feb 12, 2009 at 03:47:39AM +0900, Mike G. wrote:
Yet that’s the Ruby way: create an object and “let it ride”. Just start
quacking and go. To hell with the indoctrination ceremonies which
bestow permission to quack. Strange women lying in ponds distributing
swords is no basis for a system of government!
That is a beautiful segue into cultural reference, an apt summation of
your message as a whole in a concluding statement, and the tail end of
what was a well presented address of Igor’s entire attitude in this
thread. Well done.
David M. wrote:
All objects respond to .nil?, and I’m surprised you made it this far in
a discussion of Ruby without knowing about this.And, since classes are open, you can do this:
class NilClass
def nil?
false
end
endGo ahead, type that into irb. Watch it crash on the very next command.
I have told you are the master of sabotage. Now tell me why on Earth
would one define things like { true==false } and { 2+2==5 }. I have more
trouble with Ruby crashing because of your sabotage! But that I can live
with, since I understand that Ruby internals depend on the premise {
true != false }!
As for your surprise that how far I have come, I must tell you that I am
only surprised I keep debating you. This is what happens when one
engages in public debates 
Much of what you are saying may be true
from your perspective, however, I simply do not have time to babble so
much.
Mike G. wrote:
If you are committed to measuring everything in accordance with Booch,
you will find a whole legion of sinners here. Indeed, that I and others
keep wondering why you are not using Java or C++ makes sense in light of
this. For the most part Ruby goes duck-typing route, which is
fundamentally different than the route of Java or C++
patterns/methodologies you find in Booch.
Perhaps you are mislead by the nature of the discussion here, which has
deformed into something other than what the thread’s title suggests. I
am not an OO purist and should basically be rather surprised at most of
what you’ve said above, mostly because of how I entered this discussion.
Let me repeat:
Ruby and Perl are two totally different programing
environments and are really not to be compared with regards
to their run time performance. With Ruby the performance
issue is shifted to the entire project life cycle, and indeed
to the complexity of the project. Mere execution time of an
application represents only a tiny fraction of what is truly
measured when comparing procedural language like Perl and
object oriented Ruby. If you compare the two languages in
this respect Perl doesn’t come even close to where Ruby stands.
In fact I believe if you look at performance issues from this
angle, Ruby stands out very proudly as the best performing
programming language of all times.
Most likely, with my focus on OO, I am also responsible for the
splintering of this discussion into many branches. But the fact remains
that despite some of its immaturities Ruby is one of the best OOPLs
around today.
I have also repeatedly praised Ruby’s inherent duck-typing philosophy,
which ironically seems to be one of the strongest points my opponents
make, when they mindlessly and unjustly build it up as significant
Ruby’s flaw. The other point that I was arguing was that Ruby’s
flexibility is not its fault but its strength, which again the opponents
of the idea that Ruby is setting standards for future OOP language
developments are constantly attacking with irrelevant arguments. They
support their attacks by dissecting nonsensical algorithms that in
normal circumstances indeed are inherently bad or even evil. Ruby with
many of its extensions, some of which indeed are shared with more
procedural Perl and OB (object-based) Lisp, but especially, as you say,
with its ability to allow programs to effectively rewrite and redefine
themselves at runtime, is a powerful tool. All these attributes do not
make Ruby a procedural language, it remains one of the best, if not The
best, OOPLs around today!
Take the example of delegation. There is no notion of Java-like
interfaces or C+±like classes of just pure virtuals. In Ruby a
delegate can have no relation, ancestry-wise, to the object it wraps.
It violates all the Booch rules: it should be outlawed!
I could not disagree more. You are suggesting the rigidity that can only
be attributed to literary interpretation of the “scripture”. It is in
fact Ruby’s virtue that it did away with unnecessary virtuals and
abstract classes. But as I am repeatedly saying, it is up to the
designer to ignore these features or reinforce them. Go ahead and
reinforce them with an “abstract” class of “virtual” methods that do
nothing but throw exceptions, to make sure you actually define them. At
the end My code will be shorter and more elegant, and true, for a Java
or C++ virtuoso perhaps less legible.
Chad P. wrote:
I’m not sure you’re clear on the definition of “orthogonal”.
. . . and OOP is actually very hierarchical in a lot of ways,
at least as practiced in most languages – including, to a
lesser extent, Ruby.
The term “orthogonal” is not an OOM (OO methodology) term, though it is
often used in texts and discussions pertaining to OO. Its meaning in OOM
discussions is an evolved meaning that expands even the definition in
Oxford dictionary, where it is explained merely as something
“right-angled”. Logically in OOM the term loosely means “the opposite”.
An object organization is flat organization, and is orthogonal to
structured pyramid organization. “Is-a” relationship defines hierarchy
and is orthogonal to “has-a” relationship which represents aggregation
or composition. In flat organization one set of rules apply, while in
the structured organization orthogonal rules apply. In this respect
procedural programing is orthogonal to OOP. Now the tricky part is that
OO includes procedural programming as a “part-of” or a “has-a” thing.
This means that programming in procedural way in an OOPL should be
possible without any effort, however, the reverse is not true because
the two programming paradigms are orthogonal. Again this does not mean
that in procedural language it is not possible to program in OO
programing paradigm, it only takes extraordinary effort and/or overhead
to do so. This is how orthogonality is accounted for with respect to OOP
and procedural programming.
Perl is an excellent example of what was just said. It takes an
extraordinary effort to use it as an OOPL. It requires that the
programmer knows much more about OO rules than the programmer who uses
Ruby where everything is an object. A totally and utterly different
question is whether you use these languages correctly be it Perl, C,
C++, Java, Ruby or ooCobol. This is where most of us fail most of the
time, and that is why Design Patterns and Booch OOA/D exist.
Igor P. wrote:
def nil?
false
end
endGo ahead, type that into irb. Watch it crash on the very next command.
I have told you are the master of sabotage.
Why am I still feeding this troll?
Now tell me why on Earth
would one define things like { true==false } and { 2+2==5 }.
For fun.
But no, you wouldn’t on a real project. Because despite what you seem to
think, the fact that a language feature is there doesn’t in any way
imply that you have to use it.
I have more
trouble with Ruby crashing because of your sabotage!
Oh, you mean you’ve actually defined things like (nil.nil? == false)?
That’s not very smart.
Much of what you are saying may be true
from your perspective, however, I simply do not have time to babble so
much.
And yet, obviously, you do, or we wouldn’t have received this message.
Something to think about before you reply.
The only thing you don’t seem to have time for is forming a logical
argument.
I have also repeatedly praised Ruby’s inherent duck-typing philosophy,
which ironically seems to be one of the strongest points my opponents
make, when they mindlessly and unjustly build it up as significant
Ruby’s flaw.
I don’t think anyone’s suggesting it’s a flaw – only that your
philosophy would seem to make it one.
For example, if duck typing is not a flaw, why should I not be able to
borrow methods from unrelated classes? If the method works, clearly the
two classes are of the same duck type.
The other point that I was arguing was that Ruby’s
flexibility is not its fault but its strength,
Ah. So when it’s flexibility you like, it’s a strength. When it’s
flexibility you don’t like, it’s “anarchy”. Got it.
All these attributes do not
make Ruby a procedural language,
Ruby can, in fact, be used as an exceptionally good procedural language.
Take the example of delegation. There is no notion of Java-like
interfaces or C+±like classes of just pure virtuals. In Ruby a
delegate can have no relation, ancestry-wise, to the object it wraps.
It violates all the Booch rules: it should be outlawed!I could not disagree more. You are suggesting the rigidity that can only
be attributed to literary interpretation of the “scripture”. It is in
fact Ruby’s virtue that it did away with unnecessary virtuals and
abstract classes.
Looks like you also don’t understand sarcasm.
Chad P. wrote:
I’m not sure you’re clear on the definition of “orthogonal”.
Logically in OOM the term loosely means “the opposite”.
I have never heard it used to mean that, in computer science or
otherwise.
It means, roughly, neither dependent nor mutually exclusive – if two
things are orthogonal, they have no side effects on each other.
For example, object oriented programming is orthogonal to regular
expressions. You can have a language with rich regex support and no OO,
or, conversely, a language with rich OO and no builtin regex support. Or
you can have a language with both – in which case, you can probably
make large changes to the object system without affecting regexes, and
vice versa.
Within an object system, I might call two modules “orthogonal” if I can
include one, the other, neither, or both into my class without any
problems – and, specifically, if I can include both without one
affecting the other. I believe Comparable and Enumerable are orthogonal
in that way.
Further reading:
I think you’ll probably find that you are the only person on this forum
using “orthogonal” to mean “opposite”, because it does not. In fact, you
will not find “opposite” on that page – despite wildly different
definitions in each of the eight fields mentioned.
I wonder why you didn’t simply say “opposite”, if that’s what you meant?
Or were you just trying to sound smart by using big words?
Looks like you also don’t understand sarcasm.
Well David, sarcasm does not bode extremely well with written text.
On Fri, Feb 13, 2009 at 06:22:45AM +0900, Igor P. wrote:
Perhaps you are mislead by the nature of the discussion here, which has
deformed into something other than what the thread’s title suggests. I
am not an OO purist and should basically be rather surprised at most of
what you’ve said above, mostly because of how I entered this discussion.
Actually, he was probably misled by the fact that you keep using the
“fact” that Perl is a “procedural language” as a means of attacking it,
and holding up Ruby’s OO-ness as proof of its superiority, then follow
that up by holding up Booch as the standard of all that is good and
right
in the world of programming technique.
many of its extensions, some of which indeed are shared with more
procedural Perl and OB (object-based) Lisp, but especially, as you say,
with its ability to allow programs to effectively rewrite and redefine
themselves at runtime, is a powerful tool. All these attributes do not
make Ruby a procedural language, it remains one of the best, if not The
best, OOPLs around today!
I don’t think anyone’s talking about Ruby’s duck typing as a flaw of the
language. One or two may have used its duck typing as being similar to
some of the more dynamic aspects of Perl (and JavaScript), however, in
pointing out that dynamism isn’t always bad. You seem to completely,
and
repeatedly, miss that point in your attacks on Perl, though – when you
keep using its more dynamic aspects as “evidence” of how much it sucks.
The point people are trying to make when they bring up Ruby
characteristics like duck typing is not some claim that duck typing
sucks, as you assert here, but that duck typing is good, thus proving
that your distaste for Perl’s similarly dynamic characteristics is just
that: your distaste. It’s not a universally accepted sign of badness,
as you seem to want everyone to believe.
In fact, it may have been implied that, in attacking Perl for its
dynamic
characteristics while blindly praising Ruby’s in almost the same breath,
you are behaving hypocritically. From where I’m sitting, that’s exactly
what you seem to be doing; praising Ruby for things that are, in
principle, exactly the same as the things for which you deplore Perl.
designer to ignore these features or reinforce them. Go ahead and
reinforce them with an “abstract” class of “virtual” methods that do
nothing but throw exceptions, to make sure you actually define them. At
the end My code will be shorter and more elegant, and true, for a Java
or C++ virtuoso perhaps less legible.
You’re the one trying to use the “scripture” as the final Word on all
that is good and right in the world of programming. The above quote was
just someone applying your own “logic” to Ruby, and showing you that
your
ham-fisted attempt to wield Booch as a bludgeon in this discussion
doesn’t achieve what you seem to think it does – elevating Ruby to the
status of “awesome” while bringing Perl down to the status of “suck”.
often used in texts and discussions pertaining to OO. Its meaning in OOM
This means that programming in procedural way in an OOPL should be
possible without any effort, however, the reverse is not true because
the two programming paradigms are orthogonal. Again this does not mean
that in procedural language it is not possible to program in OO
programing paradigm, it only takes extraordinary effort and/or overhead
to do so. This is how orthogonality is accounted for with respect to OOP
and procedural programming.
I know it’s not an OO term. Where did you get the crazy idea I
suggested
it was?
The term “orthogonal” never means “opposite”, ever – except in
cases
where it is misused, as you used it, just as “infer” never means “imply”
except when misused, and “car” never means “golf club” except when
misused, and “Empire State Building” never means “Eggs Benedict” except
when misused.
The use of the term “orthogonal” in discussions such as this should only
be used metaphorically, and metaphorically “opposite” would be something
that goes back whence the compared object came, not in a completely
different direction the way “orthogonal” does.
On Fri, Feb 13, 2009 at 07:26:11AM +0900, David M. wrote:
Why am I still feeding this troll?
I think it’s because, like me, you may still not be 100% certain whether
he’s a troll or just thick-headedly incapable of grasping your argument.
The only thing you don’t seem to have time for is forming a logical
argument.
. . . or understanding one (yours).
Ah. So when it’s flexibility you like, it’s a strength. When it’s
flexibility you don’t like, it’s “anarchy”. Got it.
I just quoted this because it bears repeating, in case he didn’t notice
it sufficiently well the first time.
make large changes to the object system without affecting regexes, and
Orthogonality - WikipediaI think you’ll probably find that you are the only person on this forum
using “orthogonal” to mean “opposite”, because it does not. In fact, you
will not find “opposite” on that page – despite wildly different
definitions in each of the eight fields mentioned.
Excellent explanation. Thank you for expanding upon my point so
clearly.
On Fri, Feb 13, 2009 at 10:19:38PM +0900, Marc H. wrote:
Looks like you also don’t understand sarcasm.
Well David, sarcasm does not bode extremely well with written text.
The sarcasm in question struck me as incredibly obvious and well
placed. Honestly – do you think it could be reasonably believed that
anyone was seriously recommending that anything not endorsed by Booch
should be ripped out of the Ruby language?
Chad P. wrote:
David M. wrote:
Oh, you mean you’ve actually defined things like
(nil.nil? == false)? That’s not very smart.
Indeed, any logical premise is possibe until proven wrong. There are
domains in which true == false, or 2+2=5 for that matter. They are yust
not the domains you usualy work in. Your writing shows limited
flexibility and rigidity that are the thing of the past.
Logically in OOM the term loosely means “the opposite”.
I have never heard it used to mean that, in computer science or
otherwise.
Of course not - this is not hard to guess from your anything but
enlightening arguments. The keyword in my definition of the term
orthogonal is “loosely”, which you missed despite including it in the
quote. For OO and procedural programming the orthogonality comes to mind
due to the fact that the first deals with vertical pyramid - structured
organizations, while the other with flat object organizations. It is
not so much that these two are opposite, but they definitely are
perpendicular to each other. The fact that each of these two
organizations in their respective domains employ orthogonal operations
makes them loosely opposite. Of course if you have trouble seeing what’s
orthogonal, you are at a loss here. If you would ever open Grady Booch’s
OOA/D or Ivar Jacobson’s OO Software Engineering you would see countless
occurrences of this term. In fact one of the first things you ever learn
in Booch is about the orthogonality of the class and object structure,
whereby each complex system can be viewed as both a class structure and
as an orthogonal to it object structure. Class exhibits a “is-a”
relationship property while object structure its orthogonal or opposite
“has-a” relationship. On the other hand Jacobson’s analysis model is
based on there dimensional space defined by three mutually orthogonal
entities: behaviour, presentation, and information (data) … Needless
to say that the two OOM models were accepted by every other computer
scientist and they subsequently use the term in question throughout
their work. You really do not have to advertise your ignorance 
Chad P. wrote:
Actually, he was probably misled by the fact that you keep
using the “fact” that Perl is a “procedural language” as a
means of attacking it, and holding up Ruby’s OO-ness as
proof of its superiority, then follow that up by holding
up Booch as the standard of all that is good and right
in the world of programming technique.
Indeed, Perl is a procedural language, and the OO is only its extension.
You either did not read my posts or perhaps you want to ignore all the
arguments that explain how OO is a bonus in Perl, and that it is far too
much trouble to use. The true Perl power is in it’s procedural features,
and its OO extension spells trouble for every project that reaches the
entry level complexity if managed by Ruby. It may appear that I have
been too negative about Perl, but that is not really how I feel about
it, namely, I love Perl but not for its OO features but for what it
really is - and that undoubtedly is one of the pearls between the
procedural languages. Hey, C can also be used as a language in OO
environment thanks to its GNOME extension, and I can argue that C/GNOME
combination is much more powerful than Perl’s OO extension!
Igor P. wrote:
Chad P. wrote:
David M. wrote:Oh, you mean you’ve actually defined things like
(nil.nil? == false)? That’s not very smart.Indeed, any logical premise is possibe until proven wrong. There are
domains in which true == false, or 2+2=5 for that matter. They are yust
not the domains you usualy work in.
I’d be curious to know in what Ruby application a true==false or 2+2=5
is actually a good idea.
For OO and procedural programming the orthogonality comes to mind
due to the fact that the first deals with vertical pyramid - structured
organizations, while the other with flat object organizations. It is
not so much that these two are opposite, but they definitely are
perpendicular to each other.
In fact, they are orthogonal – in the computer science definition of
the term. That is, you can easily have both in a language. Both Perl and
Ruby are proof of this – you can write Ruby code which is barely even
aware of the fact that it is dealing with objects, and you can write
Perl code that doesn’t so much as touch a bare string without going
through an object.
For that matter, we have even more blatant examples: C++ is an
object-oriented language, and people are often encouraged to use objects
almost exclusively, instead of primitives. It is also almost a perfect
superset of C, a procedural language. Do you consider C++ to be “only”
an extension, and not “true” OO?
The fact that each of these two
organizations in their respective domains employ orthogonal operations
makes them loosely opposite.
Perhaps. But they are not mutually exclusive, as I have shown. And I
didn’t need an argument from authority to do it.
If you would ever open Grady Booch’s
OOA/D or Ivar Jacobson’s OO Software Engineering you would see countless
occurrences of this term.
Probably using it properly, I would guess.
You really do not have to advertise your ignorance
Let me ask something – does anyone else reading this thread think I am
wrong?
I’m certainly ignorant with respect to those particular authors. I also
don’t find them very relevant – my peers seem to be agreeing with me,
despite your veiled (and blatant) character attacks, in lieu of actually
putting up an argument.
Does that mean that all of us are wrong, and you are right?
If so, you’re unlikely to convince us of our “ignorance” by continuing
to cite various authors who may or may not actually agree with you.
You’re going to have to actually think about what you’re saying.
Indeed, Perl is a procedural language, and the OO is only its extension.
You either did not read my posts or perhaps you want to ignore all the
arguments that explain how OO is a bonus in Perl, and that it is far too
much trouble to use.
How is “too much trouble” in any way an objective argument?
You know, from now on, I’ve decided I’m not going to write unit tests.
They are too much trouble. (Sarcasm, if you didn’t get that.)
The true Perl power is in it’s procedural features,
Wrong. “The true Perl” power rests in two things:
There is more than one way to do it.
Easy things are easy, and hard things are possible.
Ruby borrows from all over the place, including Perl – the regex syntax
is pretty obviously lifted straight from Perl, to where it’s almost
surprising that it doesn’t use libpcre. For that matter, so is the
ability to use or imply parentheses, and the general philosophy of “Do
What I Mean”, especially with regards to syntax.
and its OO extension spells trouble for every project
Have you looked at CPAN lately? It seems just about every project at
least provides an OO interface. They are quite useful, and there are a
few libraries which are OO, convenient to use, and much farther along
than anything Ruby has to offer. POE::Component::IRC is an example –
completely object-oriented, both internally and in usage, and yet better
than anything I have found so far in Ruby.
In fact, I’ll suggest that the very existence of POE is a
counterexample. That “OO extension” doesn’t seem to have spelled trouble
here. It seems to have spelled success.
Hey, C can also be used as a language in OO
environment thanks to its GNOME extension, and I can argue that C/GNOME
combination is much more powerful than Perl’s OO extension!
Having not used that, I can’t comment, but let’s take a step back.
Ruby is written in C. In fact, Ruby provides a C API.
So what’s the difference between programming Ruby in C, using the C API,
versus writing it in Ruby?
Syntax, mostly.
I think you would find that with the right preprocessor, Perl is no less
object-oriented than Java, which is only slightly less so than Ruby
(Java has primitive types). And as a nice side effect, Perl might even
let you write such a preprocessor as a module – just look at the
ACME::Lingua::Pirate::Perl for an example.
And I think that with enough metaprogramming, there really isn’t very
much Ruby prevents you from doing that you could do with Perl. About the
only thing I can think of is that rebinding example I ran into, and Perl
does multi-inheritance instead of mixins.
No, if you were looking for a fundamental difference, of the kind that
might be worth debating, are between languages like these and languages
like Erlang, Haskell, Scheme, and so on – languages of a completely
different paradigm – instead of realizing TIMTOWTDI.
After all, why should you care? If I got UnboundMethod#rebind!, I
strongly doubt it would force you to rewrite a single line of code
you’ve written, or even to realize it had happened. It wouldn’t shake
the foundations of your ivory tower of the Holy Order of Object
Orientedness any more than the fact that Ruby is written in C would, or
the fact that Kernel#autoload uses the native C’s require instead of
whatever Ruby Kernel#require you overload, or the fact that Rubyists
sometimes do stupid things like using string comparisons to test
versions.
The stronger argument might be that it’s hard to do, and that it would
change the internal representation of Ruby objects and classes too
much – as opposed to changing the philosophical, platonic ideals of
Ruby objects. It might also be conceptually difficult to do – there
might be many things I haven’t thought of, that become undefined, in the
same way that it’s hard to prevent an object from being modified while
it’s being iterated over.
But is that true? I haven’t heard it from you or anyone else, and I
don’t know. But those are the worthwhile arguments to have – is it
actually difficult to do this, and will it actually cause problems? Or
are we just trying to protect programmers from themselves, instead of
treating them like adults?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs