What are OOP's Jargons and Complexities?
in [Perl]
|
Prev: swift MT940 files
Next: Is there neq for strings?
From: Xah Lee on 23 May 2005 06:23 What are OOP's Jargons and Complexities Xah Lee, 20050128 The Rise of Classes, Methods, Objects In computer languages, often a function definition looks like this: subroutine f (x1, x2, ...) { variables ... do this or that } In advanced languages such as LISP family, it is not uncommon to define functions inside a function. For example: subroutine f (x1, x2, ...) { variables... subroutine f1 (x1...) {...} subroutine f2 (x1...) {...} } Often these f1 f2 inner functions are used inside f, and are not relevant outside of f. Such power of the language gradually developed into a style of programing. For example: subroutine a_surface () { coordinatesList = ...; subroutine translate (distance) {...} subroutine rotate (angle) {..} } Such a style is that the a_surface is no longer viewed as a function. But instead, a boxed set of functions, centered around a piece of data. And, all functions for manipulating this piece of data are all embodied in this function. For example: subroutine a_surface (arg) { coordinatesList = ... subroutine translate (distance) {set coordinatesList to translated version} subroutine rotate (angle) {set coordinatesList to rotated version} subroutine return () {return coordinatesList} if (no arg) {return coordinatesList} else { apply arg to coordinatesList } } In this way, one uses a_surface as a data, which comes with its owe set of functions: mySurface = a_surface(); mySurface(rotate(angle)); // now the surface data has been rotated mySurface(translate(distance)); // now its translated newSurface = mySurface(return()) So now, a_surface is no longer viewed as a subroutine, but a boxed set of things centered around a piece of data. All functions that work on the data are included in the boxed set. This paradigm possible in functional languages has refined so much so that it spread to other groups and became known as Object Oriented Programing, and complete languages with new syntax catered to such scheme emerged. In such languages, instead of writing them like this: mySurface = a_surface(); mySurface(rotate(angle)); the syntax is changed to like this, for example: mySurface = new a_surface(); mySurfaceRotated = mySurface.rotate(angle); In such languages, the super subroutine a_surface is no longer called a function or subroutine. It is now called a “Classâ€Â. And now the variable holding the function "mySurface = a_surface()" is now called a “Objectâ€Â. Subroutines inside the function a_surface() are no longer called inner-subroutines. They are called “Methodsâ€Â. The act of assigning a super-subroutine to a variable is called instantiation. This style of programing and language have become so fanatical that in such dedicated languages like Java, everything in the language are “Classesâ€Â. One can no longer just define a variable or subroutine. Instead, one creates these meta-subroutine “Classesâ€Â. Everything one do are inside Classes. And one assign Classes inside these Classes to create “Objectsâ€Â. And one uses “Methods†to manipulate Objects. In this fashion, even basic primitives like numbers, strings, and lists are no longer atomic entities. They are now Classes. For example, in Java, a string is a class String. And inside the class String, there are Methods to manipulate strings, such as finding the number of chars, or extracting parts of the string. This can get very complicated. For example, in Java, there are actually two Classes of strings: One is String, and the other is StringBuffer. Which one to use depends on whether you intend to change the data. So, a simple code like this in normal languages: a = "a string"; b = "another one"; c = join(a,b); print c; or in lisp style (set a "a string") (set b "another one") (set c (join a b)) (print c) becomes in pure OOP languages: 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()); } } Here, the "new String" creates a String object. The "new StringBuffer(40)" creates the changeable string object StringBuffer, with room for 40 chars. "append" is a method of StringBuffer. It is used to join two Strings. Notice the syntax "c.append(a)", which we can view it as calling a inner subroutine "append", on a super subroutine that has been assigned to c, where, the inner subroutine modifies the inner data by appending a to it. And in the above Java example, StringBuffer class has another method "toString()" used to convert this into a String Class, necessary because System.out.println's parameter requires a String type, not StringBuffer. For a example of the complexity of classes and methods, see the Java documentation for the StringBuffer class at http://java.sun.com/j2se/1.4.2/docs/api/java/lang/StringBuffer.html (local copy) In the same way, numbers in Java have become a formalization of many classes: Double, Float, Integer, Long... and each has a bunch of "methods" to operate or convert from one to the other. Instead of aNumber = 3; print aNumber^3; In Java the programer needs to master the ins and outs of the several number classes, and decide which one to use. (and if a program later needs to change from one type of number to another, it is often cumbersome.) This Object Oriented Programing style and dedicated languages (such as C++, Java) have become a fad like wild fire among the programing mass of ignoramuses in the industry. Partly because of the data-centric new perspective, partly because the novelty and mysticism of new syntax and jargonization. It is especially hyped by the opportunist Sun Microsystems with the inception of Java, internet, and web applications booms around 1995. At those times, OOP (and Java) were thought to revolutionize the industry and solve all software engineering problems, in particular by certain "reuse of components" concept that was thought to come with OOP. As part of this new syntax and purity, where everything in a program is of Classes and Objects and Methods, many complex issues and concept have arisen in OOP. We now know that the jargon Class is originally and effectively just a boxed set of data and subroutines, all defined inside a subroutine. And the jargon "Object" is just a variable that has been set to this super subroutine. And the inner subroutines are what's called Methods. ---------- to be continued tomorrow. This is part of an installment of the article “What are OOP's Jargons and Complexities†by Xah Lee, 20050128. The full text is at http://xahlee.org/Periodic_dosage_dir/t2/oop.html © Copyright 2005 by Xah Lee. Verbatim duplication of the complete article for non-profit purposes is granted. The article is published in the following newsgroups: comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns Xah xah(a)xahlee.org ∑ http://xahlee.org/
From: Wibble on 23 May 2005 07:14 You're point being...? I'm an old lisp hacker too, and lisp developed objects too, because they're cool and useful (Flavors & CLOS). Java has inner classes also, and nobody misses FLET & LABELS. Limiting responsiblity and enhanced type safety, as well as improved readablity are a win hands down over the bad old days. Lisp is not a more advanced language than Java. Its 30+ years older and shows it in alot places. Lisp has some things I wish were in Java but the corralary holds true. Object orient programming in Lisp is nice too. Xah Lee wrote: > What are OOP's Jargons and Complexities > Xah Lee, 20050128 > > The Rise of Classes, Methods, Objects > > In computer languages, often a function definition looks like this: > subroutine f (x1, x2, ...) { > variables ... > do this or that > } > > In advanced languages such as LISP family, it is not uncommon to define > functions inside a function. For example: > subroutine f (x1, x2, ...) { > variables... > subroutine f1 (x1...) {...} > subroutine f2 (x1...) {...} > } > > Often these f1 f2 inner functions are used inside f, and are not > relevant outside of f. Such power of the language gradually developed > into a style of programing. For example: > subroutine a_surface () { > coordinatesList = ...; > subroutine translate (distance) {...} > subroutine rotate (angle) {..} > } > > Such a style is that the a_surface is no longer viewed as a function. > But instead, a boxed set of functions, centered around a piece of data. > And, all functions for manipulating this piece of data are all embodied > in this function. For example: > subroutine a_surface (arg) { > coordinatesList = ... > subroutine translate (distance) {set coordinatesList to translated > version} > subroutine rotate (angle) {set coordinatesList to rotated version} > subroutine return () {return coordinatesList} > > if (no arg) {return coordinatesList} > else { apply arg to coordinatesList } > } > > In this way, one uses a_surface as a data, which comes with its owe set > of functions: > mySurface = a_surface(); > mySurface(rotate(angle)); // now the surface data has been > rotated > mySurface(translate(distance)); // now its translated > newSurface = mySurface(return()) > > So now, a_surface is no longer viewed as a subroutine, but a boxed set > of things centered around a piece of data. All functions that work on > the data are included in the boxed set. This paradigm possible in > functional languages has refined so much so that it spread to other > groups and became known as Object Oriented Programing, and complete > languages with new syntax catered to such scheme emerged. > > In such languages, instead of writing them like this: > mySurface = a_surface(); > mySurface(rotate(angle)); > > the syntax is changed to like this, for example: > mySurface = new a_surface(); > mySurfaceRotated = mySurface.rotate(angle); > > In such languages, the super subroutine a_surface is no longer called a > function or subroutine. It is now called a Class . And now the > variable holding the function "mySurface = a_surface()" is now called a > Object . Subroutines inside the function a_surface() are no longer > called inner-subroutines. They are called Methods . The act of > assigning a super-subroutine to a variable is called instantiation. > > This style of programing and language have become so fanatical that in > such dedicated languages like Java, everything in the language are > Classes . One can no longer just define a variable or subroutine. > Instead, one creates these meta-subroutine Classes . Everything > one do are inside Classes. And one assign Classes inside these Classes > to create Objects . And one uses Methods to manipulate > Objects. In this fashion, even basic primitives like numbers, strings, > and lists are no longer atomic entities. They are now Classes. > > For example, in Java, a string is a class String. And inside the class > String, there are Methods to manipulate strings, such as finding the > number of chars, or extracting parts of the string. This can get very > complicated. For example, in Java, there are actually two Classes of > strings: One is String, and the other is StringBuffer. Which one to use > depends on whether you intend to change the data. > > So, a simple code like this in normal languages: > a = "a string"; > b = "another one"; > c = join(a,b); > print c; > > or in lisp style > (set a "a string") > (set b "another one") > (set c (join a b)) > (print c) > > becomes in pure OOP languages: > 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()); > } > } > > Here, the "new String" creates a String object. The "new > StringBuffer(40)" creates the changeable string object StringBuffer, > with room for 40 chars. "append" is a method of StringBuffer. It is > used to join two Strings. > > Notice the syntax "c.append(a)", which we can view it as calling a > inner subroutine "append", on a super subroutine that has been assigned > to c, where, the inner subroutine modifies the inner data by appending > a to it. > > And in the above Java example, StringBuffer class has another method > "toString()" used to convert this into a String Class, necessary > because System.out.println's parameter requires a String type, not > StringBuffer. > > For a example of the complexity of classes and methods, see the Java > documentation for the StringBuffer class at > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/StringBuffer.html > (local copy) > > In the same way, numbers in Java have become a formalization of many > classes: Double, Float, Integer, Long... and each has a bunch of > "methods" to operate or convert from one to the other. > > Instead of > aNumber = 3; > print aNumber^3; > > In Java the programer needs to master the ins and outs of the several > number classes, and decide which one to use. (and if a program later > needs to change from one type of number to another, it is often > cumbersome.) > > This Object Oriented Programing style and dedicated languages (such as > C++, Java) have become a fad like wild fire among the programing mass > of ignoramuses in the industry. Partly because of the data-centric new > perspective, partly because the novelty and mysticism of new syntax and > jargonization. > > It is especially hyped by the opportunist Sun Microsystems with the > inception of Java, internet, and web applications booms around 1995. At > those times, OOP (and Java) were thought to revolutionize the industry > and solve all software engineering problems, in particular by certain > "reuse of components" concept that was thought to come with OOP. > > As part of this new syntax and purity, where everything in a program is > of Classes and Objects and Methods, many complex issues and concept > have arisen in OOP. > > We now know that the jargon Class is originally and effectively just a > boxed set of data and subroutines, all defined inside a subroutine. And > the jargon "Object" is just a variable that has been set to this super > subroutine. And the inner subroutines are what's called Methods. > > ---------- > to be continued tomorrow. > > This is part of an installment of the article > What are OOP's Jargons and Complexities > by Xah Lee, 20050128. The full text is at > http://xahlee.org/Periodic_dosage_dir/t2/oop.html > > © Copyright 2005 by Xah Lee. Verbatim duplication of the complete > article for non-profit purposes is granted. > > The article is published in the following newsgroups: > comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer > comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer > comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns > > Xah > xah(a)xahlee.org > http://xahlee.org/ >
From: Mike Meyer on 23 May 2005 10:39 "Xah Lee" <xah(a)xahlee.org> writes: So now we find out that Xah Lee is as ignorant of other programming languages as he is of Python and Perl. > In advanced languages such as LISP family, it is not uncommon to define > functions inside a function. For example: > subroutine f (x1, x2, ...) { > variables... > subroutine f1 (x1...) {...} > subroutine f2 (x1...) {...} > } Nested subroutines date back to Algol, which was first specified in the 50s. > So now, a_surface is no longer viewed as a subroutine, but a boxed set > of things centered around a piece of data. All functions that work on > the data are included in the boxed set. This paradigm possible in > functional languages has refined so much so that it spread to other > groups and became known as Object Oriented Programing, and complete > languages with new syntax catered to such scheme emerged. Actually, classes and other OO concepts come out of simulation programming, not as an outgrowth of nested functions. Most of the features one associates with OO languages were present in Simula. Function nesting and classes were viewed as independent features. Some OO languages support nesting, others don't. I think it was Grace Murray Hopper commenting on Ada who said that "With classes, nesting is for the birds." > This style of programing and language have become so fanatical that in > such dedicated languages like Java, everything in the language are > Classes . Strictly speaking, this isn't true of *any* language. Even the most fanatical of languages distinguish between classes, objects and methods. But IIRC, Java comes with a set of low-level types that don't have classes associated with them. > This Object Oriented Programing style and dedicated languages (such as > C++, Java) This is pretty sloppy english. You imply that C++, like Java, is pure OO language - meaning that there are no freestanding functions or variables. That's false. > have become a fad like wild fire among the programing mass > of ignoramuses in the industry. Partly because of the data-centric new > perspective, partly because the novelty and mysticism of new syntax and > jargonization. Actually, C++ became popular because it promised access to the power of OO programming while leveraging the programmers familiarity with C. In reality, it combined the worst features of both. Java became popular because it fixed some of the problems with C++ while leveraging programmers familiarity with C++ and promising "run anywhere" capability. Personally, I think that these two languages are good examples of someones ability to design a popular language being much better than their ability to design a good language. But that's a matter of opinion, and as such is debatable. > It is especially hyped by the opportunist Sun Microsystems with the > inception of Java, internet, and web applications booms around 1995. At > those times, OOP (and Java) were thought to revolutionize the industry > and solve all software engineering problems, in particular by certain > "reuse of components" concept that was thought to come with OOP. At that time, OOP was pushing 30 years old. Some people were using it and getting that component reuse that it promised. Others were using it and discovering that designing reusable classes is *hard*. It was clear to pretty much everyone that OOP wasn't a silver bullet. > We now know that the jargon Class is originally and effectively just a > boxed set of data and subroutines, all defined inside a subroutine. And > the jargon "Object" is just a variable that has been set to this super > subroutine. And the inner subroutines are what's called Methods. This is simply ludicruously wrong. > to be continued tomorrow. Please don't waste our time. <mike -- Mike Meyer <mwm(a)mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
From: Jonathan Bartlett on 23 May 2005 10:29 Mike Meyer wrote: > "Xah Lee" <xah(a)xahlee.org> writes: > > So now we find out that Xah Lee is as ignorant of other programming > languages as he is of Python and Perl. I think you're misreading some of what is being said. > Nested subroutines date back to Algol, which was first specified in > the 50s. I think the author was speaking in terms of how high a level of a language it is, not necessarily how recent it is. > Actually, classes and other OO concepts come out of simulation programming, > not as an outgrowth of nested functions. Most of the features one > associates with OO languages were present in Simula. Again, I think the author was pointing out that it is an outgrowth logically, not necessarily historically. There is a basic equivalence between a class and a group of functions closed over the same variables. I mention something similar in an IBM DeveloperWorks article here: http://www.ibm.com/developerworks/linux/library/l-highfunc.html > Function nesting and classes were viewed as independent features. Some > OO languages support nesting, others don't. I think it was Grace Murray > Hopper commenting on Ada who said that "With classes, nesting is for the > birds." Doesn't this quote show the opposite? > Strictly speaking, this isn't true of *any* language. Even the most > fanatical of languages distinguish between classes, objects and > methods. I think the point was that in Java everything is done within the context of a class. You can define methods, but only as a part of a class. You cannot define a function or even a variable that stands on its own. > But IIRC, Java comes with a set of low-level types that don't have > classes associated with them. But still, it does not allow you, the programmer, to do the same. Jon ---- Learn to program using Linux assembly language http://www.cafeshops.com/bartlettpublish.8640017
From: Thomas G. Marshall on 23 May 2005 14:04
Paul McGuire coughed up: > Is this supposed to be some sort of wake-up call or call-to-arms to > all the CS lemmings who have been hoodwinked by Sun into the realm of > jargon over substance? ....[rip]... > You certainly seem to have a lot of energy and enthusiasm for these > topics. It would be nice if you could find a way to illuminate and > educate, without falling prey to the urge to pontificate. If you > really have some points to make, put away the breathless and profane > debate style - it just gets in the way of anything you're trying to > say. Really, we are *mostly* adults here, and can make up our own > minds on most things. Of the many things that bother me about his post is his tendency to voice his conclusions as if they would be universally arrived at given his data. {shrug} Paying attention to this guy's post has proven to be a complete WOT. -- I've seen this a few times--Don't make this mistake: Dwight: "This thing is wildly available." Smedly: "Did you mean wildly, or /widely/ ?" Dwight: "Both!", said while nodding emphatically. Dwight was exposed to have made a grammatical error and tries to cover it up by thinking fast. This is so painfully obvious that he only succeeds in looking worse. |