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
