Interesting take on Paradigms (OO vs Procedural)
in [Cobol]
|
From: Rick Smith on 11 Apr 2008 13:03 "Joe Zitzelberger" <zberger(a)knology.net> wrote in message news:zberger-A7F0BE.00153011042008(a)ispnews.usenetserver.com... > In article <13uq9i0e2sfdd1a(a)corp.supernews.com>, > "Rick Smith" <ricksmith(a)mfi.net> wrote: > > > < http://www.cs.berkeley.edu/~jrs/4/lec/14 > > > ----- > > Why did the originators of object orientation rename "structures" to > > "objects" > > and "procedures" to "methods"? Hubris and arrogance, in my opinion. Some > > people believe object orientation is a completely new "paradigm" for > > programming. The best known paradigms for computer languages are these. > > > > - Procedural languages: Fortran, C, Pascal > > - Functional languages: Lisp, Scheme, Haskell > > - Logic languages: Prolog > > - Object-oriented languages: Java, Smalltalk, C++ > > > > The first three of these really use very different ways of thinking about > > how > > to program a computer. Object-oriented languages are mostly a gloss on > > procedural languages. > > > > The one part of object-orientation that really stands out, and might give it > > claim to being a separate "paradigm," is _polymorphism_. > > ----- > > I think you have missed the lightbulb moment. I had my "lightbulb moment" when I read the quoted text and decided that it was an "Interesting take on Paradigms (OO vs Procedural)". Perhaps, the "you" to whom you are referring should have been "he or she". <g> > As "structure" is not an "object". Nor is a "procedure" a "method". > > An "object", in pure OO thought, is a bundle of zero or more structures > AND zero or more procedures together. It seems to me that, "in pure OO thought," there must be at least one data item and one procedure taken together with a capability for passing messages, and, in that sense, COBOL 68 could be used for OO modeling because it has all the necessary elements: working-storage and procedure division takrn together with inter-program communications. Reality is a bit less pure though and one must account for multiple instances of objects and object persistence. When these are taken into account, it is, perhaps, easier to consider the "structures" as the "objects". On a historical note, "object-oriented" was first used, in 1981, by Dr. Alan Kay to describe concepts used in Smalltalk-80. Apparently others found the concepts more interesting than the language and soon began adapting and developing other languages to use the concepts. Then, by consensus, it was decided that Simula 67 was the first object-oriented language. < http://searchsoa.techtarget.com/news/interview/0,289202,sid26_gci962762,00.html > has an interview with Dr. Kay. The last question "Do you have any advice for up and coming developers?" has a rather interesting conclusion. ----- But, in fact, the urge of everyone is to just implement. You know, talent comes in a bell curve. The middle of the bell curve is 67%. When you have 2 million people implementing without dealing with the best ideas from the 2 million, you're going to get maybe 1.4 million bad systems. -----
From: tlmfru on 11 Apr 2008 13:54 If I may stick my oar in here - Pete, make sure that when you use a term with meaning in both OO and non-OO that your reader knows exactly what you mean. A discussion between us last year foundered when you used a word - function - that meant in non-OO terms that the program /system did not perform that particular necessary process, while in OO it means something completely different. Natural language is slippery. PL .. Richard Brady <rrllbrrady(a)worrlldnet.att.net> wrote in message news:e1KLj.88781$D_3.36594(a)bgtnsc05-news.ops.worldnet.att.net... > Pete Dashwood wrote: > [snip] > > The important (to me...), and usually overlooked by people obsessed only > > with coding, thing here is the CONCEPTUAL use you get from an Object. This > > is BECAUSE it is as you described above. Identifying Objects conceptually > > and building them in code go hand in hand in my book. I have never > > considered Objects to be ONLY the "instantiation in memory of a defined > > computer Class", even though that is all they are to a program. PEOPLE can > > use Objects (conceptually) and can model with them, modify them, (without > > committing any computer code to memory), do walkthroughs with them, and > > conceptually juggle with them to get a better solution. That is just as > > important in an Object Oriented approach to problem solution, as the > > technical details which apply to computer code. > > > [snip] > > Absolutely. The fact is that when you encapsulate behaviours and properties > > into an Object, the synergistic whole, is far greater than the sum of its > > parts. The code representation is only ONE aspect of it. > > > > Pete. > > OK Pete, > At the risk of getting you in serious trouble again, here I have these > files to read containing data. How does this data constitute an object > and after I've manipulated the heck out of it generating the view I > wish, how do I save the object(s) to media (disk, print or screen)? > > Thanks for this and other insights. > > Regards, > Richard Brady
From: Rick Smith on 11 Apr 2008 14:29 "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:6688cfF2ii6kvU1(a)mid.individual.net... > > > "Joe Zitzelberger" <zberger(a)knology.net> wrote in message > news:zberger-A7F0BE.00153011042008(a)ispnews.usenetserver.com... [snip] > > You can certainly use OO compilers to write procedural type code as you > > describe -- or you can use procedural only compilers to write OO style > > code as long as you enforce your the OO rules yourself. > > Absolutely. The fact is that when you encapsulate behaviours and properties > into an Object, the synergistic whole, is far greater than the sum of its > parts. The code representation is only ONE aspect of it. Pete, sometimes you make it too difficult for me to not care! <g> The fact is that were one to encapsulate behaviors and properties into (a COBOL 68 program as) an object, it would not be more than what it appears to be. Add inheritance and polymorphism and the picture changes dramatically. The ability to substitute (an object of) one subclass with (an object of) another subclass (both derived from the same class), with no change to the underlying code, is what I see as synergistic. [I think the above also helps demonstrate why "object" should not be used. It is difficult to define a proper relationship between objects without reference to "class".]
From: Pete Dashwood on 11 Apr 2008 20:36 "Richard Brady" <rrllbrrady(a)worrlldnet.att.net> wrote in message news:e1KLj.88781$D_3.36594(a)bgtnsc05-news.ops.worldnet.att.net... > Pete Dashwood wrote: > [snip] >> The important (to me...), and usually overlooked by people obsessed >> only with coding, thing here is the CONCEPTUAL use you get from an >> Object. This is BECAUSE it is as you described above. Identifying Objects >> conceptually and building them in code go hand in hand in my book. I have >> never considered Objects to be ONLY the "instantiation in memory of a >> defined computer Class", even though that is all they are to a program. >> PEOPLE can use Objects (conceptually) and can model with them, modify >> them, (without committing any computer code to memory), do walkthroughs >> with them, and conceptually juggle with them to get a better solution. >> That is just as important in an Object Oriented approach to problem >> solution, as the technical details which apply to computer code. >> > [snip] >> Absolutely. The fact is that when you encapsulate behaviours and >> properties into an Object, the synergistic whole, is far greater than the >> sum of its parts. The code representation is only ONE aspect of it. >> >> Pete. > > OK Pete, > At the risk of getting you in serious trouble again, here I have these > files to read containing data. How does this data constitute an object > and after I've manipulated the heck out of it generating the view I wish, > how do I save the object(s) to media (disk, print or screen)? > Well the serious trouble is something I'm quite used to... although it is getting tiresome lately. Maybe I'm getting old...:-) The only good thing about banging your head against a wall is that it is nice when you stop. However, I believe your enquiry to be a fair one so I'll respond. I have bookshelves full of books. The data in them, just like your files, in and of itself, does not constitute objects. So, the answer to your first question is: "Data is not an object". However, if I decide to extract and organise some of the data in my books, I can build an object from it. For example: I want to find out about the life of Rudyard Kipling. I go to the bookshelves (or the Internet) and read some biographies about him. I notice certain salient points (his date of birth, when he died, points about his early childhood, what shaped him... etc.) I read some of his stories and poetry and consider them. Now I can say I have some knowledge about Kipling. (It is no longer just data; it is abstracted into a concept of Kipling... If I come across a quotation or lines extracted without attribution, I can make a reasonably accurate guess as to whether Kipling may have written them. This is more than I can get from just the facts alone.) Then I do the same with Edgar Allan Poe. I find there are parallells with building a concept of Poe and building a concept of Kipling. If I abstract these common concepts I arrive at the idea of a "Writer". This is a "Class" of information. Within this Class of "Writers", I can visualise specific instances. (Kipling and Poe are just two instances of an "Object" within this Class.) Now let's look again at your questions... "How does this data constitute an object..." Answer: It doesn't until you make it do so. The point is that the Object is conceived, and then the data is loaded to it. The bookcase is an amorphous collection of data, your files are organised into records and each of these records COULD be about a specific writer, but in both cases, the data needs to be populated into an object instance before we can claim to have a specific Kipling object or a specific Poe object, within the class of writers. "...and after I've manipulated the heck out of it generating the view I wish, how do I save the object(s) to media (disk, print or screen)?" By adding methods to the object (or letting it invoke other methods in other Classes) that let it generate a view of itself and let it save its properties. These methods can be parameterized and the parameters can be passed from external programs or by using the GET and SET methods inherent in the object. If you compare this with standard batch processing it is not as efficient. You must instantiate an object in your initialization and then load the data for each record on your file to it, as the data is read. You then invoke your manipulation method(s), your view method(s), and your storage method, and repeat the process. Although this sounds unwieldy, there are actually some benefits in doing it. 1. It allows separation layers so that code which does view processing, code that does DB access, and code that does other functions can be layered into an n-tier approach easily. Object methods are small and encapsulated; easily shared, replaced or enhanced. (MS are making a big deal in .NET currently about the MVC facility that has just been announced. This stands for "model-view-control" and allows web based systems to separate code as just described: The data model (LINQ or SQL) is separated from the web page view (HTML, AJAX, Silverlight, JavaScript, etc), and both are separated from the control code (C#, VB, etc. (OO COBOL can also be used)) which is placed on a "code-behind" page attached to the .aspx page. Some of us have been doing this manually for some time now, but it will be nice to have it automated... 2 The "control logic" is much shorter (and therefore easier to modify) than it would be for a Batch program that implemented all of this monolithically. Nevertheless, we don't usually use Objects for Batch processing. It is totally hopeless for me to take specific instances of current procedural approaches and show how they could be implemented using OO. (Besides it is counter productive, because it just confirms the prejudices... OO is not as good at procedural processing as procedural programs are. That doesn't mean there is no room for OO or that OO has no use. In fact the OO paradigm unlocks doors that procedural code simply cannot penetrate. I really can't be bothered arguing this any more... the world has voted with its feet; several hundred million programmers world wide have gone with it; if less than 100,000 COBOL people want to resist, I can't see that making any significant difference. OO is not about pedantic arguments on the exact shade of meaning of a theoretical term. (well, OK, it IS in CLC... :-)), it is about an approach to system development that is more intuitive for non technical people, quicker, smarter, and MUCH more cost effective than carving lines of code by hand. But don't take my word for it... look around, see where the jobs are. > Thanks for this and other insights. Thank you for your courtesy. You are very welcome. Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 11 Apr 2008 20:50
"tlmfru" <lacey(a)mts.net> wrote in message news:yDNLj.27645$KJ1.1559(a)newsfe19.lga... > If I may stick my oar in here - Pete, make sure that when you use a term > with meaning in both OO and non-OO that your reader knows exactly what you > mean. Peter, I'm getting so tired of this I can't be bothered any more. I'm happy to discuss Object based development and relate how I use it. I'm not happy to enter an academic argument about the intimate details of OOA, OOD, and OOP, because it really isn't relevant (in those terms) to what I do every day, and I haven't worked on any sites where it is. I work on sites where they use Object approaches (as I do myself) to achieve useful solutions. Nobody I know, who actually works in the real world rigidly applies this theory.(And I have worked with people who are expert in it) It is relevant insofar as an academic understanding is required; not to actually get stuck in and build systems with it. And you don't need a masters degree in computer science to understand OO. > > A discussion between us last year foundered when you used a word - > function - that meant in non-OO terms that the program /system did not > perform that particular necessary process, while in OO it means something > completely different. Get over it. :-) > > Natural language is slippery. Yes, it is. Oddly enough I write thousands of words every year, have them published in various magazines, newspapers, and on the web, and this is the ONLY place where people have trouble understanding me... I have to ask myself whether my time here is being well spent. Pete. -- "I used to write COBOL...now I can do anything." |