What are OOP's Jargons and Complexities?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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, ...) {
  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
  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
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();

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);

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

For a example of the complexity of classes and methods, see the Java
documentation for the StringBuffer class at
(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

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

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

© 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:

∑ http://xahlee.org /

Re: What are OOP's Jargons and Complexities?

So now we find out that Xah Lee is as ignorant of other programming
languages as he is of Python and Perl.

Quoted text here. Click to load it

Nested subroutines date back to Algol, which was first specified in
the 50s.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Strictly speaking, this isn't true of *any* language. Even the most
fanatical of languages distinguish between classes, objects and

But IIRC, Java comes with a set of low-level types that don't have
classes associated with them.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

This is simply ludicruously wrong.

Quoted text here. Click to load it

Please don't waste our time.

Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Re: What are OOP's Jargons and Complexities?

Mike Meyer wrote:
Quoted text here. Click to load it

I think you're misreading some of what is being said.

Quoted text here. Click to load it

I think the author was speaking in terms of how high a level of a
language it is, not necessarily how recent it is.

Quoted text here. Click to load it

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:


Quoted text here. Click to load it

Doesn't this quote show the opposite?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

But still, it does not allow you, the programmer, to do the same.

Learn to program using Linux assembly language

Re: What are OOP's Jargons and Complexities?

Jonathan Bartlett wrote:

Quoted text here. Click to load it

I think you're giving the author too much credit.

Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max /
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
   Love is the true price of love.
   -- George Herbert

Re: What are OOP's Jargons and Complexities?

Quoted text here. Click to load it

Given how clear Lee's writing is, that's certainly possible.

I note that, while you disagree with my interpretation of what Lee said,
you trimmed the text under discussion in *every* case. That sort of makes
the discussion moot. I don't care enough about the subject to dig out his
original quotes. I do stand by my interpretation of them as radically wrong,
which is par for the course for Lee. If you really want to discuss these,
please repost your comments, leaving Lee's text in place.

Quoted text here. Click to load it

I don't think so. I had originally written a comment to the effect that
early OO languages seemed to include it or not, with no apparent rhyme
or reason. The GMH quote was meant to show that nesting - or lack of it -
was pretty much irrelevant. I left out the intervening text.

My bad.

Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Site Timeline