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
> [EMAIL PROTECTED]
> ∑ http://xahlee.org/
>
--
http://mail.python.org/mailman/listinfo/python-list
