I emailed this to may college drop-out Web programming son in New Zealand.
I'll see what he thinks about it. Proyect and others might enjoy his
thoughts on progamming and the 20-something's Web culture at
www.benbrown.com
-----Original Message-----
From: Louis Proyect [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 09, 2001 11:04 AM
To: [EMAIL PROTECTED]
Subject: [PEN-L:10029] Java
Last week I was at Sun's education center in NYC taking Introduction to
Java 275. All of the programmers on the Financial Front-End system I work
on are being trained in the language in order to migrate the user interface
to the worldwide web, where more and more of Columbia's internal business
functions are being housed. Java not only provides access to the Internet,
it also supposedly will make applications building easier because it is an
"object oriented" language. In object orientation, the goal is to make
programs like replaceable parts in a personal computer, for example. The
paradigm is a factory assembly line rather than the messy, chaotic world of
the individual programmer. This, of course, is the kind of world that I
feel comfortable in.
I work primarily in Perl nowadays, the seventh or eighth language I've
worked in over the past 33 years. With Perl, I can create a "hello, world"
program as follows:
---
#!/usr/local/bin/perl
print "hello world";
---
With Java, the same code would do the trick, according to the Sun student
guide:
---
public class TestGreeting {
public static void main(String[] args) {
Greeting hello = new Greeting("hello");
hello.greet("world");
}
}
public class Greeting
private String salutation;
Greeting(String s) {
salutation = s;
}
public void greet(String whom) {
System.out.printlin(salutation + " " + whom);
}
}
---
Now, any reasonable person might ask why all the extra code is needed. The
answer, in a nutshell, is that it helps to support reusability. For
example, the keywords "public" and "private" tell Java whether one program
can access another program's function. In the world of object orientation,
this is called "information hiding". From the standpoint of a Marxist
programmer like myself, it is a tip-off that management would prefer a more
compartmentalized world than has been the case historically. For example,
if a program (called a 'class' in the OO world) does payroll calculations,
one might decide to make the 'salary raise' function (called a 'method' in
the OO world) private.
The other important OO "breakthrough" is its strict adherence to a
hierarchical schema in which one class can be inherited from another. It is
reminiscent of Aristotle's attempt to classify the natural world with
animals at the highest level. Within animals, you have birds, fishes,
mammals and insects. Within insects, you have worms, spiders, moths, etc.
In the business world, such a hierarchical approach would gladden the
hearts of any management for obvious reasons since they see things in a
top-down manner. In the brokerage industry, instead of animals you might be
dealing with securities at the highest level. Beneath securities, you would
have stocks and bonds. Within bonds, you would have government bonds,
corporate bonds, commercial paper, etc. Any process that is common to all
securities would be "inherited" by lower level classes.
While this methodology might be quite useful in the animal world where
evolution ended long ago for most species, in the business world it can be
problematic. For instance, if a brokerage house is bought by a bank, and if
Glass-Steagall is relaxed, then one might want to merge banking and
securities class hierarchies. This is easier said than done.
If there is anything that my 33 years in the industry has taught me, it is
that programming can not be easily converted into a Fordist type
discipline. When I first entered the field and until 1970 or so, "anything
goes" was the operating principle. Armed with Cobol, programmers were given
free rein to solve a problem in any manner they chose. Since this was
before the computer science days, many programmers were like myself:
refugees from the humanities.
The first attempt to rein in the programmers occurred in the 1975 to 1985
period under the rubric of structured programming methodologies (SDM). With
SDM, there were certain prescribed ways to design systems and write
programs. For designers, this meant preparing elaborate blueprint-like
diagrams that showed how one process interacted with one another.
Individual programs were required to follow certain "dos" and "don'ts". For
example, a "go to" instruction was absolutely prohibited. "Go-to less"
programming would supposedly have ushered in a more mechanized world that
put a premium on predictability rather than creativity. It failed since it
was difficult to enforce.
The next big revolution was called CASE, which stood for Computer Aided
Software Engineering. Instead of writing programs, programmers would feed
requirements into a program that would then crank out software. CASE was
hyped relentlessly. Columbia University contracted with a consulting
company that was very big in CASE tools in 1990, the year I came aboard. My
job was to recommend CASE tools and work with programmers to make them more
productive. Somewhere along the line, CASE lost its allure. Perhaps the
best explanation is that the CASE tools were hard-wired to produce a
certain kind of software, such as Cobol. But in the rapidly changing
technical environments of the 80s and 90s, such an approach might be
insufficient.
That is where Object Orientation comes in. The consulting company we were
in a partnership with saw OO as the greatest thing since sliced bread. This
magic elixir would make it possible to turn everything at the university
into an object which could be shared across business lines. A student
object's methods could be shared by the registration system, the payroll
system, etc. At least that was the justification.
I warned against OO back in 1994. I said that it might make sense for a
relatively static environment such as you find in a software vendor like
Microsoft, where a product can be created from scratch. In the university,
not only would you have to account for "legacy" systems that defied
objectification, you also had frequent occasions to purchase packages from
outside vendors that followed their own hierarchies, not ours. They went
ahead and developed a Facilities Management System using Smalltalk, an OO
language, that never was implemented. Not only was the system difficult to
modify for reasons alluded to above, it was also highly bloated. In other
words, it had all the same faults as the products being developed by Bill
Gates and company.
I really have no choice except to get up to speed in Java. The world of
programming is changing all around me and I have to stay current with the
latest technologies. Perhaps a medieval guild craftsman like myself is a
dinosaur doomed to extinction anyhow. Newer programmers tend to have
computer science degrees and are less interested in creativity than in
money to begin with. In the Java class, we were asked to introduce
ourselves on the first morning, including one personal datum. The other
programmers, who were young enough to be my children, said: "I just got
back from Las Vegas. I stayed up all night long having a wild time" or "I
am a big summer Olympics fan. Last year I went to Australia just to see the
games." When it came to me, I said, "I run a Marxism list, whose web site
gets 6,000 hits per month."
Call me brontosaurus.
Louis Proyect
Marxism mailing list: http://www.marxmail.org
