From: Trans Date: 2005-01-30T06:55:50+09:00 Subject: Re: FYI: what's OOP's jargons and complexities? Mathieu Bouchard wrote: > 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. Its interesting what peopl take away from something. The thing that I focused on, and what I meant by what I had "figured out myself" was the encapsulation --i.e. that an class/object is just an ecapsulation, and a method an ecapsulation in an encapsulation. The purity thing didn;t strike me as much b/c that main 6 of one or half dozen of another. Either you lean toward types and key what methods do off those, or you len toward a univeral type and use lots of different methods --they "typing" ends up somewhere --either in the methods or the data. In OOP its all to the data, in so far as it is OOP. > > 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... Sure I started with BASIC and 6502 Asm on C64. > > 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. Oh no! I respectively disagree here. OOP made we add another layer of conern to my programming. There was nothing wrong with my code before --it worked quite well. You know my father was Cobol programmer and I tell you I think that man could have out written anyone here. He single handedly wrote CRM and Accounting applications that today would take dozens of progammers to do. But I don't have to go there to get at my point either. I used to maintain 1,000,000 lines of code for such an app all in MS compiled BASIC. It was all very well organized into small managble programs. And I could chrun'em out pretty quick. I think if we had to OOP that code, it would have been an absolute nightmare --in fact that's what that comapny started to do (to get with the "Windows" times) right after I left them. Two years later they were no longer in business. > 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...) So then you end up writing even crappier programs anyway b/c you don't really get the model the way it ought to be. So what's the point? Worse you don't even realize it till you go to add the last little feature and realize it screws the whole model up, and the only way to get it in there is to write a god aweful hack. And how do you know everything fits well in an OOP model 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. I agree with you there! > 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. Okay, I'll buy that explination I guess. OOP principles certainly have relavence. I'm not totally knocking them mind you. I simply think we haven't really seen them for what they are fully, which has created an over exuberhance for all things OOP and also set up some artifical barriers we must now contend. > > 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? Oh I'd probably Logo in a heart beat if ther were any _really good_ implementations. It's basically just slightly simplified-syntax lisp. And consider BASIC. Who would have ever thought BASIC would become a premier OOP langage? VB.net has the whole OOP thing going on now --in some ways even more so than Ruby. T.