I think your objection is overstated. Creating a
language that all users can use, no matter what
platform, seems like a good thing to me. Of course,
capitalist entities will attempt to use that language
in ways that benefit them or to bastardize (as
Microsoft has), but they do that to *everything*,
don't they?
--- Louis Proyect <[EMAIL PROTECTED]> wrote:
> 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
=== message truncated ===
=====
Subscribe to the Chico Examiner for only $30 annually or $20 for six months. Mail cash
or check payabe to "Tim Bousquet" to POBox 4627, Chico CA 95927
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
