T
Trans
Nice. I look forward to the next installment.
Of course I had basically figured the jist of this out already, but
this post states it very nicely and quite clearly. I think alot of what
makes OOP popular is that people actually like a certain amount of
complexity --it gives them something to do and to "know". That's not
to say it doesn't have some merits --it does help code reuse a little,
but I don't know how well it really offsets the added hoops it creates.
I recently rewrote a program something like 15 times before I felt like
I got the "object model" right.
Thanks,
T.
Of course I had basically figured the jist of this out already, but
this post states it very nicely and quite clearly. I think alot of what
makes OOP popular is that people actually like a certain amount of
complexity --it gives them something to do and to "know". That's not
to say it doesn't have some merits --it does help code reuse a little,
but I don't know how well it really offsets the added hoops it creates.
I recently rewrote a program something like 15 times before I felt like
I got the "object model" right.
Thanks,
T.
J
Joao Pedrosa
Hi,
I'm working with about 16k LoC of Ruby and I had to do some drastic
improvements to it and I think that the general OOness of it was
enough to keep it all working while I messed with it. I wouldn't
recommend doing it on production code that you need ready by the next
week, but it definitely helps when you are still in the development
process.
I feel like I can break Ruby code knowing that I will be able to fix
it. The only exception is the "end" keyword which if missing is
terrible, but if you kept the file small enough you can handle that,
even without the right tools.
It's a nice feeling to know that we can hack several scripts, merge
them, create new ones, mess with the old ones, etc, without everything
falling apart.
Basically, code should be inside modules. Don't "include AModule"
outside of a module, or you may hit some conflicts. Split your code
evenly among files. "Reopen" the same modules in different files, if
needed.
That said, I even used some Polymorphism, so OO in Ruby is really
useful. I found that I could avoid many copy/pastes by using OO
properly.
If I had to fight with Static Typing while doing so many changes to
the code, many "ideas" would be lost while I would be trying to make
it compile to verify the changes. It's really a different process. We
do get errors, but not in the Static Typing sense and there isn't a
debugger with breakpoints, only "p"s and "puts"s here and there.
It's a different mindset. When I used Delphi, I would often get angry
at Delphi for making me repeat some unwanted steps prior to doing
something else, or when it would simply say "Insufficient Memory"
declaring end of the programming session for me.
I prefer Ruby.
Cheers,
Joao
I'm working with about 16k LoC of Ruby and I had to do some drastic
improvements to it and I think that the general OOness of it was
enough to keep it all working while I messed with it. I wouldn't
recommend doing it on production code that you need ready by the next
week, but it definitely helps when you are still in the development
process.
I feel like I can break Ruby code knowing that I will be able to fix
it. The only exception is the "end" keyword which if missing is
terrible, but if you kept the file small enough you can handle that,
even without the right tools.
It's a nice feeling to know that we can hack several scripts, merge
them, create new ones, mess with the old ones, etc, without everything
falling apart.
Basically, code should be inside modules. Don't "include AModule"
outside of a module, or you may hit some conflicts. Split your code
evenly among files. "Reopen" the same modules in different files, if
needed.
That said, I even used some Polymorphism, so OO in Ruby is really
useful. I found that I could avoid many copy/pastes by using OO
properly.
If I had to fight with Static Typing while doing so many changes to
the code, many "ideas" would be lost while I would be trying to make
it compile to verify the changes. It's really a different process. We
do get errors, but not in the Static Typing sense and there isn't a
debugger with breakpoints, only "p"s and "puts"s here and there.
It's a different mindset. When I used Delphi, I would often get angry
at Delphi for making me repeat some unwanted steps prior to doing
something else, or when it would simply say "Insufficient Memory"
declaring end of the programming session for me.
I prefer Ruby.
Cheers,
Joao
M
Mathieu Bouchard
But OOP is there to simplify things, not complicate them. If things become
complicated then OOP is used wrong or is used for the wrong problem. The
goal of good programming is to write simple programs, not to write OOP
programs. One should map patterns of thought to patterns of mechanisms in
the most convenient way possible. Clinging to recipebooks and phrasebooks
and taking guidelines as if they were hard rules, those are things that
make verbose and clunky programs, OOP or not. Every useful mechanism can
be subverted into uselessness. OOP is simple, but teaching how to use OOP
is hard (and often not well done) because teaching how to use any set of
language constructs is hard.
If you have hoops in your model then your model can be simplified, and
should, save for those hoops that are specifically there for a future
benefit of extensibility.
_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
C
Charles Miller
Nice article. I'd love to see it written without all the inaccuracies
and obvious bias.
Charles
-- Contributing to the heat death of the Universe since 1975
(e-mail address removed) http://fishbowl.pastiche.org
T
Trans
Hi Mathieu Bouchard,
First off I'm wondering if you read the referenced post?
I've been programming for over 20 years. I would not call myself a
great programmer, but I'm okay. I was first interoduced to OOP via VB
and then really hunkerd down with it in Ruby. So maybe 5 or so of OOP.
In the past I could just sit down and hammer out a pretty nice program.
But with OOP I find myself spending much more time on the "proper
model". OOP has made me an aweful programmer by comparision. Yea, so
great others can more easily use my code. That's nice. But it sure as
hell doesn't make my coding any simpler.
Take the simple example I just went through, where I had to figure our
how to best represent a encapsulation of "how to find a piece of
subtext" and the encapsulation of "what to create when you find that
thing", and there were various parts shared among them, so I wnated to
modularize, but it's tricky b/c modules don't include class level stuff
(without wrtting some meta-code to manually do it) and subclassing a
class that extends a module which extenda a module doesn't seem to fly
(I beleive that was the pattern) and not to metntion the well known
DynamicModuleInclusion problem (inlcuding a module in a module poist
instantiation), well needless to say it took quite sometime to find
something "artisian" --and I won't even do into the same old same old
with trying to get access to an object far up the hierarchy fromthe
bottom (always fun to pass a self down four levels ;-)
Now my problems aside, consider all those OOP design patterns. All very
cool I think, but a whole lot more complexity. OOP is NOT simple.
Otherwise it wouldn't be so difficult to teach. I don't believe
teaching how to use any set of language constructs is neccessarily
hard. Kids program in Logo! Becoming an expert is hard, _especailly in
a hard thing_.
I don't find this comment intereting:
I respectively disagree. I think OOP itself can often make that more
difficult.
T.
First off I'm wondering if you read the referenced post?
I've been programming for over 20 years. I would not call myself a
great programmer, but I'm okay. I was first interoduced to OOP via VB
and then really hunkerd down with it in Ruby. So maybe 5 or so of OOP.
In the past I could just sit down and hammer out a pretty nice program.
But with OOP I find myself spending much more time on the "proper
model". OOP has made me an aweful programmer by comparision. Yea, so
great others can more easily use my code. That's nice. But it sure as
hell doesn't make my coding any simpler.
Take the simple example I just went through, where I had to figure our
how to best represent a encapsulation of "how to find a piece of
subtext" and the encapsulation of "what to create when you find that
thing", and there were various parts shared among them, so I wnated to
modularize, but it's tricky b/c modules don't include class level stuff
(without wrtting some meta-code to manually do it) and subclassing a
class that extends a module which extenda a module doesn't seem to fly
(I beleive that was the pattern) and not to metntion the well known
DynamicModuleInclusion problem (inlcuding a module in a module poist
instantiation), well needless to say it took quite sometime to find
something "artisian" --and I won't even do into the same old same old
with trying to get access to an object far up the hierarchy fromthe
bottom (always fun to pass a self down four levels ;-)
Now my problems aside, consider all those OOP design patterns. All very
cool I think, but a whole lot more complexity. OOP is NOT simple.
Otherwise it wouldn't be so difficult to teach. I don't believe
teaching how to use any set of language constructs is neccessarily
hard. Kids program in Logo! Becoming an expert is hard, _especailly in
a hard thing_.
I don't find this comment intereting:
I respectively disagree. I think OOP itself can often make that more
difficult.
T.
G
gabriele renzi
Trans ha scritto:
notice that the post is also a flamebait, crossposted to
comp.lang.perl.misc, comp.lang.python, comp.lang.lisp, comp.lang.scheme,
comp.lang.c, full of dumb stuff like this:
public class test {
public static void main(String[] args) {
String a = new String("a string");
String b = new String("another one");
StringBuffer c = new StringBuffer(40);
c.append(a); c.append(b);
System.out.println(c.toString());
}
}
presented as "pure OOP language".
I, as a dumb java programmer would write:
public class test {
public static void main(String[] args) {
String c = new String("a string" + " another one");
System.out.println(c);
}
}
but obviously in a pure oo language such as ruby you won't need this.
notice that the post is also a flamebait, crossposted to
comp.lang.perl.misc, comp.lang.python, comp.lang.lisp, comp.lang.scheme,
comp.lang.c, full of dumb stuff like this:
public class test {
public static void main(String[] args) {
String a = new String("a string");
String b = new String("another one");
StringBuffer c = new StringBuffer(40);
c.append(a); c.append(b);
System.out.println(c.toString());
}
}
presented as "pure OOP language".
I, as a dumb java programmer would write:
public class test {
public static void main(String[] args) {
String c = new String("a string" + " another one");
System.out.println(c);
}
}
but obviously in a pure oo language such as ruby you won't need this.
P
PA
Ditto
Hmmm... I rather see OOP as providing a sense of structure and
organization. In other words, a consistent way to "package"
functionalities. If this is beneficial or not is largely in the eyes of
the beholder.
Cheers
P
PA
Nice article. I'd love to see it written without all the inaccuracies
and obvious bias.
Think of it as a "opinion piece". Plus, "inaccuracies" and "bias" are
underrated.
In any case, perhaps this is an opportunity for you to to expend on:
http://fishbowl.pastiche.org/2005/01/17/language_of_the_year
Cheers
P
PA
J
James Britt
Charles said:Nice article. I'd love to see it written without all the inaccuracies
and obvious bias.
Nicely put.
When I got to part that asserted, "in such dedicated languages like
Java, everything in the language are 'Classes'," little trolls started
dancing in my head.
James
P
PA
Trolling trolls or not, is it not the case that everything in Java has
to be part of a class one way or another? This is at least what I have
gathered from my somewhat limited exposure to the Beast of Santa Clara.
But perhaps I have missed something obvious?
Cheers
T
Trans
Flambait? Trolls? If you think it so, why then do feed the fire?
Well, probably b/c you are a dedicated OOP advocate. That's fine, but
address the main of the opinion piece, if you disagree, rather than
resorting to the pitfulness of slander.
It is your judging it such that I see as troll and flamebait. I
respectively ask that you show more respect for other's endeavors.
T.
Well, probably b/c you are a dedicated OOP advocate. That's fine, but
address the main of the opinion piece, if you disagree, rather than
resorting to the pitfulness of slander.
It is your judging it such that I see as troll and flamebait. I
respectively ask that you show more respect for other's endeavors.
T.
J
James Britt
PA said:
That's different from saying that "everything in the language are [sic]
'Classes'"
And then following that assertion with a straw man example of class bloat.
James
J
James Britt
Trans said:
Or not.
People here have been encouraged to read the article. I found it flawed
to the point of incoherency. I have no interest, though, in running
through it trying to correct the "mistakes", as I think that indeed
would be feeding the troll.
And, yes, I appreciate the irony of this very post.
James
L
Lyle Johnson
I am not taking a side on this particular post of Xah Lee's. I would
make note that he is sort-of an infamous Internet troll, especially
beloved by members of the Perl community.
T
Trans
And then following that assertion with a straw man example
Okay, it was a poorly written example, and perhaps done so to
exagerate. But even with a better example, the main of the argument
isn't invalidated.
Somone says, "Look this whole thing is rotten cheese." And you pull out
a nugget and say, "No, this part is actually edible." It dosen't mean
the rest of it's still not rotten. Now I'm not saying OOP is rotten
cheese, but I'm not so sure your piece tastes all that much better
either.
T.
Okay, it was a poorly written example, and perhaps done so to
exagerate. But even with a better example, the main of the argument
isn't invalidated.
Somone says, "Look this whole thing is rotten cheese." And you pull out
a nugget and say, "No, this part is actually edible." It dosen't mean
the rest of it's still not rotten. Now I'm not saying OOP is rotten
cheese, but I'm not so sure your piece tastes all that much better
either.
T.
T
Trans
James!
Your not willing to correct his mistakes as _that_ would be feeding the
troll, but you are willing take the time to bad mouth it and shout
"troll!" ?
You do have a strange sense of irony!
T.
Your not willing to correct his mistakes as _that_ would be feeding the
troll, but you are willing take the time to bad mouth it and shout
"troll!" ?
You do have a strange sense of irony!
T.
D
Douglas Livingstone
Trolling trolls or not, is it not the case that everything in Java has
From the article:
a = "a string";
b = "another one";
c = join(a,b);
print c;
In Ruby:
a = "a string"
b = "another one"
c = a + b
print c
And everything still gets to be objects
Douglas
From the article:
a = "a string";
b = "another one";
c = join(a,b);
print c;
In Ruby:
a = "a string"
b = "another one"
c = a + b
print c
And everything still gets to be objects
Douglas
P
PA
Bah. Same difference.
Well, straw man perhaps, but rather a telling one.
After all, if the always so helpful javac compiler could be tuned down
a bit, a bare bone Java class would need to look something like this:
import java.lang.Object;
import java.lang.String;
import java.lang.StringBuffer;
import java.lang.System;
public class HelloWorld extends Object
{
public static void main(final String[] someArguments)
{
Buffer aBuffer = new Buffer();
aBuffer.append( "Hello " );
aBuffer.append( someArgument[ 0 ] );
System.out.println( aBuffer.toString() );
}
}
But thanks to the rich sugar based Java diet, you could get away with
just this:
public class HelloWorld
{
public static void main(final String[] someArguments)
{
System.out.println( "Hello " + someArgument[ 0 ] );
}
}
I heard that excessive intake of sugar is quite bad for your health
though.
Cheers