Forwarded from Greg Schofield (Java)

Louis Proyect lnp3 at
Wed Apr 18 06:58:17 MDT 2001

What a pleasure to see Marxists seriously approaching this subject - I am a
fool for not finding this list earlier.

Fordism is certainly one aspect of problem and the constant tendency
towards bloating languages. Another is subtlety different a chronic
disconnection between management and production, reflecting the
disconnection between the bourgeoisie and the means of production.

Fordism, at least, was intended to increase actual production the same
cannot be said of what is happening with software which has delivered
negligible benefits in the face of revolutionary potential of hardware
evolution. Worse, the constant fads that infect the industry leads to large
software projects which never seem to be completed, that often add to the
complexities of production rather than higher productive gains.

The bloat of language is paralleled by the bloat of personnel, especially
management and design. Top down management leading to top down design and
implementation. The result is that the bottom usually is forced to contort
itself to work around software designed to give management illusional
control over production.

Capitalism is coming a cropper with computers, a communication device whose
one-to-many, many-to-one and many-to-many pathways is at odds with
managerial concerns.

There are ways out of the problem. One is empowering the user technically
(the user being the one who is transforming abstract electronic
communications into something productive).

The technique is code fragmentation, that is compiled code as generalised
fragments which are available to the user to co-ordinate with scripting and
GUI glue. The emphasis being beyond confined customerisation and into
evolving systems which are adapted to practical use.

I am no programmer but have been working in conjunction with Lestec who
produce MAID a REXX based GUI system which encourages by design fragmenting
scripting-code and discreet shared libraries of compiled-code. Needless to
say the response by the industry has been a deafening silence.

Rather than bloat, this approach leads to code shrinkage. Oddly because the
fragments are relatively independant, extending their power often leads to
simplyfing the script. Much of the conditional code does not get written as
it is implied by the GUI controls and the relationship between each. The
result is that application in a sense becomes more self-explanatory,
especially to a user who is looking at improving or pruning it down for
some other use.

Likewise the hardware hitting specs are incredibly low, JAVA and other OOPs
apps being notorious hogs at the CPU and RAM.

The way out therefore seems to be include a shift, a political shift as to
who is to have the practical power to adapt and refine (from developers to
users) couples with a technique that makes the "glue" (script + GUI) more
transparent. It follows that developers, rather than being employed cogs in
a large organisation would be more like journeymen of old, producing very
generalised compiled code which is accessed through scripts (perhaps this
is taking things too far).

My role (merely advisory and beta testing - not pecuniary) in this stemmed
from a perceived need to produce a app environment that was adaptable to
user needs, the political aspiration of making a package of digital tools
available to activists (Ie the computer as a branch office and
communication hub).

If comrades are interested I would very much like to debate practical code
fragmentation and generalisation - it is certainly no JAVA thing though.

Greg Schofield
Perth Australia.

Louis Proyect
Marxism mailing list:

More information about the Marxism mailing list