What are OOP's Jargons and Complexities?

G

Greg Ewing

Anno said:
These languages had an axe to grind. They were designed (by Niklas
Wirth) at a time of a raging discussion whether structured programming
(goto-less programming, mostly) is practical. Their goal was to prove
that it is, and in doing so the restrictive aspects of the language
were probably a bit overdone.

This doesn't sound right. That argument might still have
been active at the inception of Pascal, I'm not sure. But
Pascal *does* have a goto statement, although you were
punished a little for using it (numeric labels only, which
had to be declared before use). And surely no-one was arguing
against structured programming by the time Modula came along,
much less Oberon.

The restrictiveness of these languages was mainly in the
type system, which is quite a different issue. And, as has
been pointed out, relaxing the type system of Pascal just
a little has resulted in a very successful family of
languages (UCSD, Turbo, Apple Pascal, etc.)
 
R

Ray Dillinger

Matthias said:
And btw., I haven't used Pascal in a dozen years but my latest info is
that Turbo Pascal still lives in the form of "Delphi" for the Windows
platform. Surely not "dead" as I understand it.

There's also FreePascal, which compiles approximately the
same language as Turbo Pascal/Delphi, (and inherits most of
Borland's linguistic extensions) and is opensource, works
fine on Unixes, etc. It's in active use by several people,
making games.

Bear
 
X

Xah Lee

The Rise of “Inheritanceâ€

In well-thought-out languages, functions can have inner functions, as
well as taking other functions as input and return function as output.
Here are some examples illustrating the use of such facilities:
subroutine generatePower(n) {
return subroutine (x) {return x^n};
}

In the above example, the subroutine generatePower returns a function,
which takes a argument and raise it to nth power. It can be used like
this:
print generatePower(2)(5) // prints 25

Example: fixedPoint:
subroutine fixedPoint(f,x) {
temp=f(x);
while (f(x) != temp) {
temp=f(temp);
}
return temp;
}

In the above example, fixedPoint takes two arguments f and x, where f
is taken to be a function. It applies f to x, and apply f to that
result, and apply f to that result again, and again, until the result
is the same. That is to say, it computes f[f[f[...f[x]...]]].
FixedPoint is a math notion. For example, it can be employeed to
implement Newton's Method of finding solutions as well as many problems
involving iteration or recursion. FixedPoint may have a optional third
parameter of a true/false function fixedPoint(func,arg,predicate) for
determining when the nesting should stop. In this form, it is
equivalent to the “while loop†in procedural languages.

Example: composition:
subroutine composition(a,b,c,...) {
return subroutine {a(b(...c...))};
}

The above example is the math concept of function composition. That is
to say, if we apply two functions in sequence as in g[f[x]], then we
can think of it as one single function that is a composition of f and
g. In math notation, it is often denoted as (g∘f). For example,
g[f[x]]→y is the same as (g∘f)[x]→y. In our pseudo-code, the
function composition takes any number of arguments, and returns a
single function of their composition.

When we define a subroutine, for example:
subroutine f(n) {return n*n}

the function is power of two, but the function is named f. Note here
that a function and its name are two different concepts. In
well-thought-out languages, defining a function and naming a function
are not made inseparable. In such languages, they often have a keyword
“lambda†that is used to define functions. Then, one can assign it
a name if one so wishes. This separation of concepts made many of the
lingustic power in the above examples possible. Example:
lambda (n) {return n^2;} \\ a function
(lambda (n) {return n^2;})(5) \\ a function applied to 5.
f = lambda (n) {return n^2;} \\ a function is defined and named
f(5) \\ a function applied to 5.
lambda (g) {return lambda {g(f)} } \\ a function composition of
(g∘f).


The above facilities may seem exotic to industrial programers, but it
is in this milieu of linguistic qualities the object oriented paradigm
arose, where it employees facilities of inner function (method),
assigning function to variable (instantiation), function taking
function as inputs (calling method thru object), and application of
function to expressions (applying method to data in a class).

The data-bundled-with-functions paradigm finds fitting application to
some problems. With the advent of such Objet-Oriented practice, certain
new ideas emerged. One of great consequence is the idea of inheritance.

In OOP practice computations are centered around data as entities of
self-contained boxed sets (objects). Thus, frequently one needs
slightly different boxed sets than previously defined. Copy and Pasting
existing code to define new boxed sets quickly made it unmanageable. (a
messy set of classes). With powerful lingustic evironment and
habituation, one began to write these new boxed-subroutines (classes)
by extending old subroutines (classes) in such a way that the new
subroutine contains all variables and subroutines of a base subroutine
without any of the old code appearing in the body of the subroutine.
Here is a pseudo-code illustration:
g = subroutine extend(f) {
new variables ...
new inner-subroutines ...
return a subroutine that also contains all stuff in subroutine f
}

Here, “extend†is a function that takes another function f,and
returns a new function such that this new function contains all the
boxed-set things in f, but added its own. This new boxed-set subroutine
is given a name g.

In OOP parlance, this is the birth of inheritance. Here, g inherited
from that of f. f is called the base class or superclass of g. g is the
derived class or subclass of f.

In functional terms, inheritance mechanism is a function E that takes
another function f as input and returns a new function g as output,
such that g contained all enclosed members of f with new ones defined
in E. In pure OOP languages such as Java, the function E is exhibited
as a keyword “extendsâ€. For example, the above code would be in
Java:
class g extends f {
new variables ...
new inner-subroutines ...
}

Here is the same example in Python, where inheritance takes the form of
a class definition with a parameter:
class g(f):
new variables ...
new inner-subroutines ...


Data are the quintessence in computation. Because in OOP all data are
embodied in classes, and wrapping a class to each and every variety of
data is unmanageable, inheritance became the central means to manage
data.

-----
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
(e-mail address removed)
∑ http://xahlee.org/
 
A

Andrea Griffini

Of course it is a language, just not a standardized one (if you include
Borland's extensions that make it practical).

The history of "runtime error 200" and its handling from
borland is a clear example of what I mean with a product.

You are of course free to call even Microsoft Access a
language (and make long term investment on it) if you want.

Andrea
 
D

Dale King

Anno said:
Tassilo v. Parseval said:
Also sprach Dale King:

David Formosa (aka ? the Platypus) wrote:

On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval


[...] I haven't yet come across a language that is both statically and
strongly typed, in the strictest sense of the words. I wonder whether
such a language would be usable at all.


Modula2 claims to be both statically typed and strongly typed. And
your wonder at its usablity is justified.

I used a variant of Modula-2 and it was one of the best languages I have
ever used. That strong, static type checking was a very good thing. It
often took a lot of work to get the code to compile without error.
Usually those errors were the programmers fault for trying to play fast
and loose with data. But once you got it to compile it nearly always worked.

I am only familiar with its successor Modula-3 which, as far as I
understand, is Modula-2 with uppercased keywords and some OO-notion
bolted onto it (I still recall 'BRANDED' references).

I have to say that doing anything with this language was not exactly a
delight.


I've been through Pascal, Modula2 and Oberon, and I agree.

These languages had an axe to grind. They were designed (by Niklas
Wirth) at a time of a raging discussion whether structured programming
(goto-less programming, mostly) is practical. Their goal was to prove
that it is, and in doing so the restrictive aspects of the language
were probably a bit overdone.

I fail to see how they were that different in terms of structured
programming than C. The main benefit I was talking had more to do with
types. It had types that were not compatible just because they had the
same base type. For example you could have a type inches that was an
integer and a type ounces that was also integral. Just because they were
both integral did not make them type compatible. You couldn't just
assign one to the other without you as the programmer explicitly saying
that it was OK (by casting).

In the environment I was programming in (engine controls for cars) where
safety was a critical thing and a programming bug could kill people that
safety was a very good thing. I think that also has a lot to do with why
the government uses Ada.
In the short run they succeeded. For a number of years, languages of
that family were widely used, primarily in educational programming
but also in implementing large real-life systems.

In the long run, the languages have mostly disappeared from the scene.

I've posted before that hardly any language that has ever been somewhat
popular has actually died (depending on your definition of that word).
When asked for someone to name one once I got Simula for example (the
forerunner of OO languages). Turns out that it continues to actually
grow in popularity.
It has been discovered that "structured programming" is possible in
about any language. It turns out that programmers prefer the
self-discipline it takes to do that in a liberal language over the
enforced discipline exerted by Papa Pascal and his successors.

There are lots of reasons they have not taken over, although Ada is
still in wide use. It seems to me that too many people like playing with
dangerous power tools without the guards in place.
 
M

Matthias Buelow

Andrea said:
The history of "runtime error 200" and its handling from
borland is a clear example of what I mean with a product.

Hmm, I had to google this up...

Quite embarrassing, but it's a runtime bug and got nothing to do with
the language per se. And it certainly manifests itself after the
hey-days of Turbo Pascal (when Borland seems to have lost interest in
maintaining it.)

mkb.
 
A

Andrea Griffini

Quite embarrassing, but it's a runtime bug and got nothing to do with
the language per se. And it certainly manifests itself after the
hey-days of Turbo Pascal (when Borland seems to have lost interest in
maintaining it.)

The point is not the bug, of course, but how borland handled
it. It appeared when the user community of borland pascal
was well alive and kicking, but borland didn't even invest
5 seconds for the issue. The users had to fix the library
themselves (possible because at that time with Borland Pascal
you were getting the whole source code of the library; but
note that it was a 100% genuine bug due to misprogramming,
fixing it even on a dead product would have been the a nice
move from borland). The user community went even further,
as so many executables were written witn borland pascal that
a special tool for binary patching executables was built
(actually a few of them, as being unofficial it wasn't
that simple to get to know that such a tool existed, so
different people independently resorted to the same solution).

Andrea
 
X

Xah Lee

The Rise of Class Hierarchy

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 somehow become a method of some class. In this way, coupled
with the all-important need to manage data with inheritance, the OOP
Class 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 Classe node having its own set methods as appropriate. Math
functions, are lumped into some math class hierarchy.

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
(local copy)

OOP being inherently complex exacerbated by marketing propaganda, and
the inheritance and hierarchy concept is so entangled in OOP, sometimes
OOP is erroneously thought of as languages with a hierarchy. (there are
now also so-called Object-Oriented databases that ride the fad of
“all data are trees†...)

Normally in a program, when we want to do some operation we just call
the subroutine on some data. Such as
open(this_file)
square(4)

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
(local copy)

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 (local copy)

-------
to be continued...

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
(e-mail address removed)
∑ http://xahlee.org/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,781
Messages
2,569,619
Members
45,316
Latest member
naturesElixirCBDGummies

Latest Threads

Top