http://article.gmane.org/gmane.comp.python.general/384636
Cheers
···
--
PA, Onnay Equitursay
http://alt.textdrive.com/
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.
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
cmiller@pastiche.org http://fishbowl.pastiche.org
Hi,
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.
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
···
On Sat, 29 Jan 2005 14:55:51 +0900, Trans <transfire@gmail.com> wrote:
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".
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.
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.
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.
···
On Sat, 29 Jan 2005, Trans wrote:
_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Trans ha scritto:
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.
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.
Nice. I look forward to the next installment.
Ditto
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".
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
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:
Cheers
···
On Jan 29, 2005, at 10:49, Charles Miller wrote:
Nice article. I'd love to see it written without all the inaccuracies and obvious bias.
--
PA, Onnay Equitursay
http://alt.textdrive.com/
"The next Xah-lee post contest"
http://article.gmane.org/gmane.comp.python.general/384713
Cheers
···
On Jan 29, 2005, at 06:55, Trans wrote:
Nice. I look forward to the next installment.
--
PA, Onnay Equitursay
http://alt.textdrive.com/
Charles Miller wrote:
···
On 29/01/2005, at 10:30 AM, PA wrote:
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
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:
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.
I respectively disagree. I think OOP itself can often make that more
difficult.
T.
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
···
On Jan 29, 2005, at 15:23, James Britt wrote:
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.
--
PA, Onnay Equitursay
http://alt.textdrive.com/
String c = new String("a string" + " another one");
System.out.println(c);
The challange was:
Store two strings, a and b, in memory. Combine those two strings and
store them in memory. Take the data in memory and send it to the
standard output.
Your code only does:
Store a tring in memory, then send it to the output.
I don't speak Java, so I don't know what the best answer to the
original challange was; perhaps someone can help me out?
I'm sure that most of these problems are static typing problems
anyway, in the original code a and b were never defined as being
strings. This has nothing to do with OOP, it is just advcation for
dynamic typing (or even Duck typing
Douglas
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.
PA wrote:
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.
Trolling trolls or not, is it not the case that everything in Java has to be part of a class one way or another?
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
···
On Jan 29, 2005, at 15:23, James Britt wrote:
Trolling trolls or not, is it not the case that everything in Java has
to be part of a class one way or another?
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
Douglas Livingstone wrote:
I don't speak Java, so I don't know what the best answer to the
original challange was; perhaps someone can help me out?
public class test {
public static void main(String args) {
String a = "a string", b = "another one", c = a + b;
System.out.println(c);
}
}
Xah Lee usually talks about things, he doesn't understand. He's also unable to learn anything new, from the explanations he receives. There are many reasons to criticize Java, but it's unlikely that Xah will ever come up with any of them.
···
--
Florian Frank
First off I'm wondering if you read the referenced post?
If you mean the one from gmane.org, yes, and I think it misses a few
things.
The word "purity" it uses is straight from Java gospel, and ignores other
definitions of purity in OOP thinking. From my perspective, purity means
that a language _integrates_ the concepts of OOP quite deeply into its
design. If OOP was only added as an afterthought (C++ over C) then more
purity can be achieved by reexpressing parts of the base language so that
OOP can be better integrated with it. In that sense, both C++ and Perl get
the spirit of OOP better and deeper than Java because they offer features
to allow user-defined code to look like the base non-OOP language.
Purity is only mentioned a bit, but all of the article seems to be
attacking mostly Java, with little evidence of any research into other
approaches to OOP. For something in a Python newsgroup I'd expect
something more enlightened than that.
I've been programming for over 20 years.
Same here, although I started quite young and half of the years involved
almost only BASIC and LOGO...
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.
Here's my impression of your situation, which is also a lot my personal
experience:
OOP made you raise your standards enormously, and ask yourself lots of
questions and doubt of your ways to write code. This is good, but there
has to be some kind of stopper, to avoid getting in an endless loop of
rewriting programs. It's good to plan for future expansions, but it
shouldn't be overdone. In particular, there is no single ideal way that a
program should be written, and some redesigns may look like switching from
one ideal to another and back and forth and getting lost. Extreme
Programming methodology mentions that problem and advocate a more
laid-back attitude about this (just code the "minimum" and redesign only
to fill in new actual needs or to shorten the program... well that's _my_
interpretation of it anyway...)
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)
[...]
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.
First, the module-vs-class concept of Ruby is superfluous, and it's a
pity, because CommonLisp has the same mixin system using only classes, and
so demonstrates you don't need modules. Apparently Modules were introduced
to make things more intuitive, but my experience has been the reverse, and
I have spent significant time circumventing that distinction.
Apart from that, I'd like to give the example of Complex Numbers. In
Mathematics, Complex Numbers are defined by an extremely short
formula: i*i=-1. That doesn't seem very complex, isn't it? Then you can
work out a full course explaining to students the _consequences_ of that
little formula on usual arithmetics. However, Complex Numbers are very
much used in practice, as a way to _simplify_ formulas, some becoming 3
times shorter or even better. Some things even look like they were made
for being used with complex numbers. (ask physicists and engineers)
I think it's a good example of a tradeoff, of having to learn more
complexity, to later be able to reduce it even more in various
situations. Just like OOP.
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_.
Oh yeah. But then, you wouldn't use Logo to code the projects you have
today. Why is that then?
···
On Sat, 29 Jan 2005, Trans wrote:
_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Trans wrote:
Flambait? Trolls? If you think it so, why then do feed the fire?
Well, probably b/c you are a dedicated OOP advocate.
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
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.
···
On Sat, 29 Jan 2005 23:55:51 +0900, Trans <transfire@gmail.com> wrote:
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.