RES: what's OOP's jargons and complexities?

[André de Leiradella <leiradella@...>]

> http://article.gmane.org/gmane.comp.python.general/384636

Quoting Xah:

	"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 variables inside these Classes to
create "Objects". And one uses "Methods" to manipulate Objects. In this
fashion, even data types like numbers, strings, and lists are no longer
atomic data types. They are now Classes."

He clearly lacks a deeper knowledge of Java. Java has 8 basic types:
booleans, bytes, chars, shorts, ints, longs, floats and doubles. Those
types aren't instances of any class and the JVM has dedicated opcodes to
deal with them. The plus operator isn't a method from a "Number" class,
it's just an operator implemented with opcodes like iadd, ladd, dadd...
I wrote a VM for Java, so trust me on that.

The classes that wrap the basic types were written because many methods
of many Java classes take an Object as an argument, for instance the
Hashtable class and the type of it's keys and values. How does one use
the Hashtable with integer keys? Wrapping an int with an Integer
instance. I don't like it as every interaction with this Hashtable will
have lots of "new Integer(id)", but if Java used dynamic types, that
need would go away.

	"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."
	
String manipulation is even harder on other languages, I think everyone
on this list know how "strings" in C are manipulated.

	"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());
	}
	}"
	
In C it would be:

int main(int argc, char argv[]) {
	char a[] = "a string";
	char b[] = "another one";
	char *c;
	
	c = malloc(strlen(a) + strlen(b) + 1);
	strcpy(c, a);
	strcat(c, b);
	return 0;
}

I think Java, considering it being a strongly typed language, does it
better.

	"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.)"
	
Wrong.

class Test {
	public static void main(String[] args) {
		double aNumber = 3;
		System.out.println(Math.pow(aNumber, 3));
	}
}

Changing the type of the number can be hard if the type is used across
an entire application (like changing Lua to use ints instead of
doubles).

	"because of psychological push for purity, in Java there are no
longer plain subroutines. Everything is a method of some class. Standard
functions like opening a file, square root a number, for loop thru a
list, if else branching statements, or simple arithmetic operations...
must now some how become a method of some class. In this way, the OOP
Hierarchy is born.
	
	Basic data types such as now the various classes of numbers, are
now grouped into a Number class hierarchy, each class having their own
set of methods. The characters, string or other data types, are lumped
into one hierarchy class of data types. Many types of lists (variously
known as arrays, vectors, lists, hashes...), are lumped into a one
hierarchy, with each node Classe having their own set methods as
appropriate. Math functions, are lumped into some math class hierarchy."
	
Whow, this guy knows nothing about Java. Again, basic types are just
basic types, their respective classes are just wrappers with specific
usages. And the Math class is just a bunch of methods grouped and anyone
can write Math.sin(o) or Math.sqrt(a). Doesn't Lua do the same?
Modularity is good.

What about if/else branches? There are many opcodes to compare/branch in
the JVM, and how could a method you call cause a jump to a different
place in the callee?

	"Now suppose the plus operation +, where does it go? Should it
become methods of the various classes under Number headings, or should
it be methods of the Math class set? Each language deals with these
issues differently. As a example, see this page for the hierarchy of
Java's
core language classes:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/package-tree.html";

In neither of them. Operators are implemented as opcodes.

	"But now with the pure OOP style, there can no longer be just a
number or this_file path, because everything now must be a Object. So,
the "this_file", usually being just a string representing the path to a
file on the disk, is now some "file object". Initiated by something like

	this_file = new File("path to file");

	where this file class has a bunch of methods such as reading or
writing to it.

	see this page for the complexity of the IO tree
	
http://java.sun.com/j2se/1.4.2/docs/api/java/io/package-tree.html

	see this page for the documentation of the File class itself,
along with its 40 or so methods and other things.
http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html";
	
Compare it with the minimal approach of C. What happens is that Java is
bloated with classes to "help" programmers do their job. Do you want to
read from memory (a byte array) instead of a file? Use a
ByteArrayInputStream. Do you want to write objects to make them
persistent across runs? Use a DataOutputStream. You can even combine
things and write an object to memory...

	"Tomorrow i shall cover more manmade jargons and complexities
arising out of the OOP hype, in particular Java."
	
Then he should buy himself a good Java book and perhaps read the JVM
Specification...

There is just one point in which I agree with Xah: reusability. OOP
languages are as good with reusability as are their programmers. But
that's not a problem with OOP. Libraries are sets of functions and
procedures related to each other, tied together in some way. But how
many times you dreamed about a library having just one more function or
characteristic? It's hard to satisfy everyone. (humm... Lua is a library
that implements a embeded script language, I wish I could do OOP with it
;)

I think what makes OOP good is encapsulation (do you see or *want to*
see OpenGL's internals while using it's functions?), specialization
(which you can use to extend functionality to add something you miss
without having to have access to the class or module being extended, and
requires inheritance of course) and polymorphism (which let's you
combine classes to do things in a way that is very hard to do in non-OOP
languages, such as reading data from a socket, from a file, from a pipe
or from memory, where that data could be compressed or not, using the
same methods for all of them).

Sorry for this OT post, but Xah claims deserved an explanation before
everyone starts thinking that OOP is a bad thing per se.

And please don't get me wrong, just because I like Java it doesn't mean
I wish to see Lua with all those classes, I just want to *be able* to
build my own class tree to match my needs.

Regards,

Andre