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?

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

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:
Quoted text here. Click to load it

Re: What are OOP's Jargons and Complexities?

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?

Please do some informed research and homework before spouting off with
such blather.  Sun Microsystems is hardly The Great Satan of OOP,
trying to foist object-speak on the rest of humanity.  The object
concepts of classes, methods, instances, inheritance, polymorphism,
etc. were already well on their way into the CS consciousness before
Java came on the scene.  To attempt to relate the emergence of object
concepts as starting with Java simply illustrates a lack of historical
awareness.  To omit so obvious a Java precursor as Smalltalk seriously
undermines any authority you may have once had on this topic.

It is easy to attack "terminology" as "jargon," but in fact, precise
definitions of terms help improve communication of complex concepts.
Unfortunately, some of the concepts *are* complex - we just recently on
this forum had someone ask about "polymorphism" when what they really
meant was "overloaded method signatures."  (It is even more unfortunate
that language features such as overloaded method signatures and
operator overloading get equated with OOP, simply because OO language
XYZ supports them.)  I would say that terminology becomes jargon when
it introduces new terms that do not really help describe any new
concepts, but simply raise an arbitrary barrier to new students of the
field.  And *any* complex field's terminology will be perceived as
jargon to those who have not done adequate study - are you about to
begin a parallel crusade to attack the jargon-spewing conspiracy among
quantum physicists, what with their terms of top, down, spin, charm,
muon, meson, lepton, etc.?

Your complaint about Java requiring all code to reside in a class is
not new.  It is a common newbie issue that one has to get past "static
void main(string[] args)" just to do a simple "Hello, World!".  But
this seems to be a minor point for someone as authoritative as yourself
to waste over 1000 words on.  All computing languages have good and bad
features.  Determining whether Java's "classes-only" language design is
"good" or "bad" is something of a point of view - let it go that some
folks find it overly purist and a nuisance, while others like the
uniformity of implementation.

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.

-- Paul

Re: What are OOP's Jargons and Complexities?

Paul McGuire coughed up:
Quoted text here. Click to load it


Quoted text here. Click to load it

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.
  Paying attention to this guy's post has proven to be a complete

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.

Re: What are OOP's Jargons and Complexities?

Xah Lee wrote:

Quoted text here. Click to load it

Yes and it is easy to communicate a class which represents some thing
determined by object oriented analysis and can be graphed as an element
of an UML diagram in your development team. This is simply the state of
the art in the IT industry and if FP-people or followers of any other
alternative programming style can communicate their concepts and design
patterns via type-classes or parentheses as well or better than they
will going to lead the dicourse and OO will fall apart. I'm just
sceptical that this is going to happen.


Re: What are OOP's Jargons and Complexities?

Xah Lee wrote:
Quoted text here. Click to load it

The actual Java parallel to what you have written above is:

     String a = "a string";
     String b = "another one";
     String c = a + b;
     System.out.println (c);

Quoted text here. Click to load it

Byte, Short, Integer, Long, Char, Float and Double are wrapper classes,
which exist chiefly to allow primitive content to be stored in
collection classes.

byte, short, int, long, char, float, and double are primitives.

Quoted text here. Click to load it

This has nothing to do with object orientation or classes, but with
strong typing, which is important for program verification, and an
inescapable necessity for compiling to efficient object code. Strong
typing has been a feature of mainstream programming languages since the
late 1950's.

John W. Kennedy
"The bright critics assembled in this volume will doubtless show, in
their sophisticated and ingenious new ways, that, just as /Pooh/ is
suffused with humanism, our humanism itself, at this late date, has
become full of /Pooh./"
   -- Frederick Crews.  "Postmodern Pooh", Preface

Re: What are OOP's Jargons and Complexities?

John W. Kennedy wrote:

Quoted text here. Click to load it

I'm just curious, what do you mean by /strong/ typing, and which strongly
typed languages do you know?

Re: What are OOP's Jargons and Complexities?

Java or even C is more strongly typed than lisp or tcl which
dont really have a concept of a typed variable.
Lisp only does runtime type checking unless you do wierd
unnatural things.

I suppose ADA or Eiffel might have stronger typing than
java, but I dont know those languages.

I guess strong is relative.

alex goldman wrote:
Quoted text here. Click to load it

Re: What are OOP's Jargons and Complexities?

Quoted text here. Click to load it
You get terminology totally wrong here. As already said, Lisp is
stronger typed than C, but C is statically typed, whereas Lisp is
dynamically typed. In Lisp (or Scheme), all variables have types:

(define foo #(1 2 3))
(vector? foo) => #t
(boolean? foo) => #t

See http://cliki.tunes.org/Type%20System .

Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

Python is executable pseudocode, Perl is executable line-noise.

Re: What are OOP's Jargons and Complexities?

Andreas Rottmann wrote:

Quoted text here. Click to load it

Hmm.. weird Scheme you're using here.
Normally you have to quote the vector (see R5RS, 6.2.6) because it is
not self-evaluating, and boolean? should not return true on vectors (6.3.1).

I get (on scheme48):

(define foo '#(1 2 3))
(vector? foo)  => #t
(boolean? foo) => #f


Re: What are OOP's Jargons and Complexities?

Thats how common lisp specifies a vector.

Andreas, your link indicates that lisp is a Weakly typed language not
strong.  Theres no compile time type semantics, at least in CommonLisp,
MacLisp, ZetaLisp or FranzLisp.

(setq foo #(1 2 3))
(setq foo 1)
(setq foo "Whatever")

Theres no type associated with foo, only with what the variable is
currently referencing.

 From your link:
   When the types detected or declared are strictly enforced by the
   language's semantics, the language is strongly-typed.
   when the semantics of the language allows for inconsistencies between
   the compile-time type and the run-time type, the language is

Matthias Buelow wrote:
Quoted text here. Click to load it

Re: What are OOP's Jargons and Complexities?

Quoted text here. Click to load it

There are runtime semantics that enforce types.

Quoted text here. Click to load it

Yes, the compile-time type of 3 is integer, and the runtime type of 3
is also integer.  There is no inconsistency.  Compare that with C,
which lets you cast 3 to a pointer.

Re: What are OOP's Jargons and Complexities?

Wibble wrote:
Quoted text here. Click to load it

I think that such terms of art are sufficiently broad and
subject to interpretation that it is now necessary for each
researcher to say exactly what they mean by a claim placing
a language in a category. That definition must be taken
into account when interpreting the claims that particular
paper makes about those language categories.

That so many researchers have chosen to use the same terms
(static, dynamic, strongly, weakly ... ) to describe subtly
different things is distressing.


Re: What are OOP's Jargons and Complexities?

Quoted text here. Click to load it

I used to have a bunch of comp sci questions I would ask interview victims.  
One of them was "what does it mean when a language is strongly typed?"  I
once had somebody tell me it meant the language had long variable names,
and thus took a lot of typing.

Re: What are OOP's Jargons and Complexities?

Quoted text here. Click to load it

But that's incorrect.  Strong typing means there's a lot of variables
whose names are in ALL CAPS.

Re: What are OOP's Jargons and Complexities?

Quoted text here. Click to load it

That should have been `weekly typed', according to the link below.
Maybe there is also `daily typed' or `monthly typed'?

Quoted text here. Click to load it

URL: http://www.cs.uu.nl/~piet [PGP]
Private email: piet@vanoostrum.org

Re: What are OOP's Jargons and Complexities?

On 5/23/2005 at 7:54:24 PM, alex goldman wrote:

Quoted text here. Click to load it

"Strongly typed" is not a very useful term, unless your intent is to
generate confusion or start an argument.  Unfortunately, there is no
consensus as to what the term means.


John McGrath

Re: What are OOP's Jargons and Complexities?

John McGrath wrote:

Quoted text here. Click to load it

If the language allows the programmer to write programs from the 'slack'
domain, by saying "just trust me on this", then it's not strongly typed.

What other meanings are there? I wasn't aware of the lack of consensus.

Re: What are OOP's Jargons and Complexities?

alex goldman wrote:
Quoted text here. Click to load it

There is a difference between getting a core dump when you invoke
undefined behavior on some object, or just getting an exception. You can
programmatically react to an exception to do something meaningful but
not to a core dump. Some people use the term weak typing to refer to
languages that potentially core dump whereas they use the term strong
typing for languages that don't.


2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net /

Re: What are OOP's Jargons and Complexities?

On 5/26/2005 at 3:11:44 AM, alex goldman wrote:

Quoted text here. Click to load it



John McGrath

Site Timeline