What are OOP's Jargons and Complexities?

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 =3D ...;
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 =3D ...
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 =3D a_surface();
mySurface(rotate(angle));        // now the surface data has been
rotated
mySurface(translate(distance));  // now its translated
newSurface =3D 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 =3D a_surface();
mySurface(rotate(angle));

the syntax is changed to like this, for example:
mySurface =3D new a_surface();
mySurfaceRotated =3D mySurface.rotate(angle);

In such languages, the super subroutine a_surface is no longer called a
function or subroutine. It is now called a =E2=80=9CClass=E2=80=9D. And now=
the
variable holding the function "mySurface =3D a_surface()" is now called a
=E2=80=9CObject=E2=80=9D. Subroutines inside the function a_surface() are n=
o longer
called inner-subroutines. They are called =E2=80=9CMethods=E2=80=9D. The ac=
t 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
=E2=80=9CClasses=E2=80=9D. One can no longer just define a variable or subr=
outine.
Instead, one creates these meta-subroutine =E2=80=9CClasses=E2=80=9D. Every=
thing
one do are inside Classes. And one assign Classes inside these Classes
to create =E2=80=9CObjects=E2=80=9D. And one uses =E2=80=9CMethods=E2=80=9D=
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 =3D "a string";
b =3D "another one";
c =3D 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 =3D new String("a string");
String b =3D new String("another one");
StringBuffer c =3D 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...ringBuffer.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 =3D 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
=E2=80=9CWhat are OOP's Jargons and Complexities=E2=80=9D
by Xah Lee, 20050128. The full text is at
http://xahlee.org/Periodic_dosage_dir/t2/oop.html

=C2=A9 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.progra=
mmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xah@xahlee.org
=E2=88=91 http://xahlee.org/

>or in lisp style
>(set a "a string")
>(set b "another one")
>(set c (join a b))
>(print c)

This code has a syntax error. If you use "set" then you have to quote
the first argument:
(set 'a "a string")
Alternatively, you could use the more popular setq or setf:
(setq a "a string")
(setf a "a string")
Setq is a macro whose only purpose is to transform (setq x y) to (set
'x y) while setf is a far more powerful macro that can sometimes
perform function inversion to accomplish its task.

>So, a simple code like this in normal languages:
>a = "a string";
>b = "another one";
>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());
>    }
>}

I don't think it has to be that complicated. I'm new to Java, and don't
have a compiler handy, but wouldn't this work?

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

> a simple code like this in normal languages
How do you define a "normal" language? Your view seems rather narrow.

> or in lisp style
LISP isn't a normal language? So is it an "abnormal" language, since it
doesn't fall into your "normal" and "OOP" world of computer
programming? If find your arguments so far to be nonsensical since
you're having trouble with simple classification.

> becomes in pure OOP languages
Funny how you use the most concise syntax possible for your favored
languages and the least concise possible for your OOP example. A better
Java example would be:

public class test {
public static void main(String [] args) {
String a = "a string";
String b = "another one";
String c = a + b;
System.out.println(c);
}
}

Oddly enough, that's only two logical lines longer than your supposedly
superior examples. Of course, you also need to consider that many
programming languages (that happen to not be OOP) require some form of
framework such as library inclusion of a function at the top lexical
level to act as an entry point, so most runnable examples will be
longer and more complicated whether they be OOP or not. Your example
translated to C would look like this:

#include <stdio.h>
#include <string.h>

int main(void)
{
char *a = "a string";
char *b = "another one";
char c[20];
strcpy(c, a);
strcat(c, b);
puts(c);
return 0;
}

C isn't OOP, yet the code is longer than even your verbose Java example
and not any easier to understand to a newcomer. Though C isn't a high
level scripting language, so it may be "abnormal" according to your
definition of programming languages.

> This Object Oriented Programing style and dedicated languages (such
as C++, Java)
You realize that C++ isn't an object-oriented programming language,
right? It's a multi-paradigm language that supports several programming
styles, among which, one is OOP. In fact, to make the best use of C++,
you would find yourself mixing multiple styles together to get the
powerful flexibility that makes good applications.

> among the programing mass of ignoramuses in the industry
You don't seem like such a bright bulb yourself. Perhaps if you gave a
more objective and well thought out comparison of OOPL and non-OOPL
then I (and probably most everyone else) wouldn't shrug you off as just
another biased fool who has his head too far up his own ass to smell
the bullshit.

By the way, I'm not a fan of OOP, so my opinion is based completely on
how you presented the material, not my own opinion of the topic.

Duck Dodgers wrote:

> Your example translated to C would look like this:
> #include <stdio.h>
> #include <string.h>
> int main(void)
> {
>   char *a = "a string";
>   char *b = "another one";
>   char c[20];
>   strcpy(c, a);
>   strcat(c, b);
>   puts(c);
>   return 0;
> }

ITYM:

#include <stdio.h>
#include <string.h>

int main(void)
{
char *a = "a string", *b = "another one", c[20];
puts(strcat(strcpy(c, a), b));
}

/* ;-) */

Jirka

If you're going to critize programming paradigms - and specific
languages - wouldn't it be GREAT to actually be fluent in the languages
you're talking about? There are quite a few problems with the things
you've said:

> 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.
>

No, this is incorrect. There is no possibility to actually model
subclasses if a Class only was a "supersubroutine".

> 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 is simply NOT TRUE. Java has primitive number types, which makes
these simple to work with, very much like C data types.

> 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.

This is, as almost all your statements, not true. What you don't mention
is that PrintStream.println() actually is overloaded to take an Object,
and call that objects toString() automatically.

> 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...ringBuffer.html

This doesn't actually SAY anything. I could give you a few links to CLHS
pages, which define the functions and macros for working with strings
and sequences, and you would easily find as much complexity there.

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

As already been noted here, the idiomatic Java way of writing this looks
somewhat like this:

public class Test {
public static void main(final String[] args) {
final String a = "a string";
final String b = "another one";
final String c = a + b;
System.out.println(c);
}
}

Furthermore, you could do this in a simple functional style like this:
public class Test {
public static void main(final String[] args) {
System.out.println("a string" + "another one");
}
}

> 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.

This is also incorrect. The String class is the only one class available
for handling strings. The StringBuffer/StringBuilder is simply an
utility class.



I do not say that OO is good for everything. In fact I hold the opposite
view, that it's harmful in many instances. The Lisp way is almost always
better. This critique is purely based on the fact that your column was
very full of errors and omitted information.

/O

> ITYM:
>
>   #include <stdio.h>
>   #include <string.h>
>
>   int main(void)
>   {
>     char *a = "a string", *b = "another one", c[20];
>     puts(strcat(strcpy(c, a), b));
>   }
>
>   /* ;-) */

Just for the record, in Java you could write:

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

All of this is irrelevant, the point is that the comparison by the OP is
meaningless as an example of what OOP leads to.


--
Morten

> ITYM:
>
>    #include <stdio.h>
>    #include <string.h>
>
>    int main(void)
>    {
>      char *a = "a string", *b = "another one", c[20];
>      puts(strcat(strcpy(c, a), b));
>    }
>
>    /* ;-) */

You're cheating ! :-)

public class test {
public static void main(String [] args) {
String a = "a string", b = "another one";
System.out.println(a + b); // yes, I know you already know that :-)
}
} // Java - 1 ; C - 0... O:-)


--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

"Jirka Klaue" <jklaue@tkn.tu-berlin.de> wrote:

> ITYM:
>
>    #include <stdio.h>

And _I_ think you all mean: "Oops, we shouldn't have followed up to a
known kook and/or troll".

HTH; HAND.

Richard

On 23 May 2005 03:21:30 -0700
"Xah Lee" <xah@xahlee.org> wrote:

> Ill-informed drivel

___________________
/|  /|  |                  |
||__||  |      Please do   |
/   O O\__         NOT      |
/          \     feed the    |
/      \     \     troll      |
/   _    \     \ ______________|
/    |\____\     \     ||
/     | | | |\____/     ||
/       \|_|_|/   \    __||
/  /  \            |____| ||
/   |   | /|        |      --|
|   |   |//         |____  --|
* _    |  |_|_|_|          |     \-/
*-- _--\ _ \     //           |
/  _     \\ _ //   |        /
*  /   \_ /- | -     |       |
*      ___ c_c_c_C/ \C_c_c_c____________


--
Stefaan
--
As complexity rises, precise statements lose meaning,
and meaningful statements lose precision. -- Lotfi Zadeh