java: vending machine software (long)

Java seems to be catching on in a big way (only a few months ago,
the hook-line-and-sinker interest by MS would not have been conceivable)
and seems to be leading to some radical new programming and
cyberspace paradigms. I thought I would try to anticipate some
of these future developments. what does it mean that "the network
is the computer"?

there are three very important aspects of Java in my view that make
it much more than your everyday programming language, and all of
these could be classed as "revolutionary" if they stay airtight
and hold up to the rigors of worldwide keyboard banging. not all of these are 
recognized for their importance or potential future significance
at the moment. 

1. it can be easily translated across platforms. this translation
is far more robust and reliable than say the supposed portability
of "C" which is in fact not very portable and whose "portability" seems
largely an illusion at times. complicated makefiles with a zillion
special cases are far from seamless. Java has reached the level
of almost "foolproof portability". of course there are some minor
sacrifices (such as possibly) efficiency. however Java has always
been designed with high efficiency in mind.

2. the security aspects are extremely significant. the end design goal
of course is that the end user should never have to worry about whatever
software he downloads-- he can run it all knowing it is theoretically
impossible for it to screw up his system. all other schemes, such
as a "software certification authority" which e.g. MS has been
pursuing, seem inferior to some degree. 

3. the whole concept of an "applet" is again very critical to the
Java design. the name connotes something that is trivial to run, and
may be tiny. i.e. one might be running tiny little programs all day
instead of monster applications that we have right now. the philosophy
is of "lean and mean" vs. the massive dinosaur. one way to state it
would be to say that the applet is a program with "small granularity".

==

now, all the above elements are present in various languages and
platforms, but Java has focused on refining them to the utmost degree,
to the point that every nonprogrammer can use a Java application without
worrying about compilation or whatever. this goal of "increased sophistication
for the less sophisticated" has always been foremost in software
development, and alas has largely been lost in the minds of many 
designers. (look how many years it took MS to come up with the
concept of "plug and play" when it would seem like an obvious
feature from the very beginning of computing). the process of
complex program translation/porting
has been reduced to the minimum of clicking on a hypertext button.

 look how many countless
man-lifetimes have been wasted by beginners trying to hack through
their autoexec.bat, config.sys, and whatever else silly configuration
files the software requires them to tweak. look at the lifetimes wasted
on bad IRQ settings. what utter shamefulness, to think that all this
could have been averted by a few farsighted designers who took the
time to "do it right" the first time around and develop standards
that didn't require a burden on the human, but instead put it where
it belonged: on the designer!! those who argue, "yes, but as soon
as you learn this stuff its not a big deal" are completely missing
the point.

the point that I am getting to is that I think we are entering a new
era of "seamlessness" everywhere in cyberspace, and java is going to
be a big part in helping that goal be achieved. we are going to see
our machines rarely ever ask us for ridiculously arcane or abstruse
information such as IRQ settings, IP addresses, or require
us to maintain it--things we should not have to care about as humans.
its really amazing how often designers simply replace one set of 
problems with another set, and these people are increasingly going to
have to get their act together in the future as people simply don't
tolerate poorly designed software that requires them to do things
they shouldn't have to do.

==

Java reminds me in many ways of the Unix operating system. now I'm
not claiming a parallel in the "use" of the language, but the
design goals are somewhat similar. Unix was broken down into very
fine "pieces" of code that could be interchanged and plugged into
each other in the same way that subroutines or classes can be 
shared today. the obvious goal is to have the ability to string
pieces of code together, no matter how small or how large. this
goal has largely eluded software programmers. it seems that after
code gets to a certain size it becomes far less able to be used
as a module or subroutine to other code. it seems one has to
constantly invent new languages to string all this code together
(machine language, C, then shell scripts, then an operating system
on top of that, then a network).

 I believe we are moving toward an environment in which code
becomes incredibly interchangeable. the entire cyberspace will
be seen in the same way that we see our own local computer system
today. cyberspace will be thought of as an enormous code library
that one can "link to" in any way one likes with one's own code.
the distinctions between operating system, computer languages,
shell scripts etc. are all going to blur into one massive, 
unified algorithmic structure.

"object oriented programming" is slowly moving in this direction.
it does seem to be that the basic unit of software is not a
"subroutine" or an "application" but an "object" and that this
paradigm can be utilized in almost any situation, at any level.

Unix has what I describe as "fine granularity" and was designed
purposely and almost fanatically to have this feature. in short it
is the philosophy that no code is an island and no matter what 
hierarchy of code one is talking about, from subroutines all the
way up to complex applications, standards should exist that let
it all "interoperate" in automated fashions. 
 a shell script is merely a way of treating
large pieces of code as subroutines. (one can get their exit
status, pass parameters on a "command line" etc.)

Unix succeeded in bringing the "interchangeable code" concept up
higher in the hierarchy to shell scripts and OS utilities etc.--
but it had to keep inventing new languages at every level to
do so.

to say that Excel "interoperates" with some other software seems
deceptive, if one is using the term in the same way it was
used in Unix. the user has to click around in menus to accomplish
what they want; whereas the situation of making the software so
that it can be called as a subroutine from code requires an entirely 
different design. when Excel began allowing all its features to
be called from Visual Basic functions, such that a series of mouse
clicks and operations implied a particular Visual Basic program,
is the direction I am referring to.

today we see code as something hiding behind user interfaces. but 
increasingly in the future, we are going to be able to see the
code itself and view the user interface as simply a kind of
"grafting" on top of it. it is a sort of "handle" that lets one
access the code. there are other "handles" that can be created to
use the same code, such as a specialized language, subroutines that
name the code, or objects. generally objects are going to win out
in the future as the "thing" that describes all code. the object
paradigm does come very close to the goal of interchangeable software
parts. increasingly the objects that hide behind complex applications
are going to become "visible" to the end user who can combine them in
novel ways. the analogy I like to use is that the "hood of the car"
can be opened to let people to tinker with the engine.

==

when one thinks about this, I think it becomes clear that we are going
to see many, many new standards for code communication in the future.
if we don't want all these java applets to be isolated, we are likely
to see many standards emerge that allow people to write applets
that "fit into" various places in a sort of "plug and play" 
approach. in Unix, the standards that were devised were shell scripts
and command line parameters. much effort went into trying to deal
with compatibility of command line arguments and that kind of thing.

these standards will tend to define things like "the standard methods
that [x] java widgets must support, and in what ways". I expect
to see a lot of these standards be developed and proliferate.

in fact, musing on all this reminds me that it seems to me the
heart of computing involves creating standards and interfaces, 
and that very few computer languages address this aspect of
computation. I'm toying with the idea of inventing a computer language
that actually manages standards. (future posts on this will probably
go to coderpunks)

==

now a few words about something I talked about in the title, or 
"vending machine software". I imagine we are going to see a whole
new paradigm for software use in the future that is going to absolutely
baffle companies used to the old paradigm, and who built their
kingdoms on it, the most obvious being Microsoft.

the key concept is to combine cyberspace, digital cash, microcurrency,
applets, and interchangeability into a new complex holographic recipe. 
imagine in the future that massive single, "circumscribed" 
applications such as Excel
become more rare, and instead what develops is an incredible variety
and diversity of applets around the world.

 I suspect that in the
future, people will use software something like the way vending 
machines work. you look around, pick the exact thing you want in the moment,
and pay a pretty small fee. you may come back later and pick something
else out. eventually I think cyberspace is going to look like one massive
application that one can click anywhere to do anything. anyone will
be able to put their own "code" into this massive vending machine.
sophisticated methods of organizing the hierarchies to aid finding
what you want quickly will evolve, just as Yahoo and all the other
search services are now proliferating.

the point is that you no longer "buy" an application-- you pay for
each individual use of pieces that exist all over cyberspace, i.e.
every time you "call" a subroutine, so to speak. the cost-per
use is so low that you don't mind this, and in fact you probably save
a lot of money in the long run, because you only pay for what you use.
furthermore, the software is very specialized and you can get applications
that are very much tailored to what you want them to do-- they require
less and less configuration. entire companies will specialize in delivering
what you want very quickly if what they are selling is not exactly what
you want that moment.

people will in fact create massive applications that are strings of
subroutines of software written elsewhere all over the world. I think
that rapid network speeds will actually allow software to be written
that doesn't reside on a local computer, but in fact in which some
subroutine calls happen over a network!! the parameters and return
data are passed over the network, and the code never runs on a local
computer.

notice the "boundaries" of such an application seems to shift 
dramatically. you cannot "circumscribe" such an application as easily,
it is not one "thing" that runs isolated on your own computer. it
is a sort of holographic element in a massive algorithmic universe
that calls on all kinds of other elements in the universe.

it may be possible to build in the same kinds of "resistance to
errors" in this kind of computation that we now have in TCP/IP
protocols. i.e. if a certain module fails, the system may automatically
call up other modules that work.

all of this requires a reliability and complexity we do not have
at the moment, but I see major hints of it in our 
current system, and I believe we are
rapidly evolving towards the above scenarios.

the above cannot really be realized so long as people insist on
selling their code as if it is a massive product that has to be purchased
and shipped somewhere in shrinkwrapped packaging. as we begin to move
away from the concept of, "you are buying the right to use this program
whenever you want for a lot of money" to "you are buying this particular
computation or use of the algorithm for a small fraction of the development 
cost", the above system will begin to proliferate and blossom.

==

what does this all mean to existing (software) 
companies? increasingly, the value
of a company of people, or some kind of structure, will be how well
it can coordinate people and resources to accomplish some particular
goal. but the company will increasingly have to compete with other
structures that may be more able to coordinate resources efficiently.
if an incredible groupware program evolved, for example, that let 
people coordinate themselves and others as "efficiently" or more
so than a company does today, companies in the modern sense would
tend to die out. a "company" becomes a virtual collection of people
and resources to accomplish a common goal, but the geographic
localization/focus characteristic of modern companies will be seen
as something as an anachronism.

a company that is drowning in inefficient bureacracy will tend to
find that people will simply go elsewhere and find more efficient
methods of "plugging in" their value, because they are better paid
by some structure that does not waste their energies.

I am not saying above that bureacracy is evil-- we are going to find
out what kinds of bureacracy (or "coordination") 
is really necessary in the future, and
what kind is superfluous, burdensome, and inefficient, as people increasingly 
move out of/away from structures running amuck in the latter.

-----BEGIN PGP SIGNED MESSAGE-----

"Vladimir Z. Nuri" <vznuri@netcom.com> writes:
> Java seems to be catching on in a big way (only a few months ago,

These are important ideas.  I found them explored very nicely
in several papers written by Drexler and Miller (circa 1988!).  They
are available in the collection "Ecology of Computation (1988)" and
via the Agorics Home page (http://www.webcom.com/~agorics).

It seems that with the Web and Java now widely available the technical
means to implement these ideas are getting visibly closer.

> when one thinks about this, I think it becomes clear that we are going
> to see many, many new standards for code communication in the future.

The most interesting thing I've heard along these lines was described
in a talk by Matthew Fuchs.   He suggested the idea of using something
like SGML (of which HTML is a subset) to communicate between smart
agents.  The idea is to provide a machine understandable equivalent
of a web form which could be used to send info back and forth.  In
this application display instructions are not important, what is
important is the meaning assigned to the keywords.  For example, in
a simple web page you might use <title>, <body>, <author>, <h1>, etc.
The browser knows how display these because for simple documents they
have a well defined meaning, but an automatic document indexer could
also easily find the title and author.

Consider an airline reservation system.  It might support a variety of
commands to answer queries and make reservations.  Clearly once the
*meaning* is in hand, crafting a way to display it would be easy.  So
you have a scheme which can be used with equal facility by
either a human or a machine.  This allows for smooth transition from
human mediated to automated steps in a larger project (e.g. plan a trip
visiting these five cities) where some parts have been automated (e.g.
airline reservations) and other parts have not (say, hotel reservations).

Further, the system can be built out of layers of objects that give
meanings to various keywords.  Consider a bunch of keywords and
associated Java applets that understand dates and times (they know about
timezones and daylight savings and weekends and so forth).  Another
level of objects knows how to manage schedules, and still another
layer knows about travel arrangements.  The system used by a particular
airline uses all these objects to provide an interface for communicating
with customers (or their automated agents).

Java seems ideal suited to be the active lubricant in such a system.

Ted Anderson

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMWK8PwGojC9e/wyBAQFuVAQA0Z4qjeIs2j8bxEYqaxuwQLdw49oXTX5a
sN9L75sy8AmdMJjDfBuo8Kij7Iyx/ZrexJp/lsGS0pC76OpafNs0nfckQsblmrA5
9BzHe+PmDgPtJOvdCJYnR624PuioGihD/J8l2YZFf7/OfaRCXW2q/HvcBeuDWseS
zSIumBmiObo=
=F+Zv
-----END PGP SIGNATURE-----

"Ted Anderson" <Ted_Anderson@transarc.com> writes:
> 
> "Vladimir Z. Nuri" <vznuri@netcom.com> writes:
> > Java seems to be catching on in a big way (only a few months ago,
> 
> These are important ideas.  I found them explored very nicely
> in several papers written by Drexler and Miller (circa 1988!).  They
> are available in the collection "Ecology of Computation (1988)" and
> via the Agorics Home page (http://www.webcom.com/~agorics).
> 
> It seems that with the Web and Java now widely available the technical
> means to implement these ideas are getting visibly closer.
> 
Agorics is a company devoted to commercializing these ideas (Mark
Miller is one of the founders.  They're building a language for this
called Joule with some interesting properties.  Electric Communities
(http://www.communities.com), a "sister" company, has rolled a number
of these ideas into E, an extension of Java for safe, distributed
communications.  

> > when one thinks about this, I think it becomes clear that we are going
> > to see many, many new standards for code communication in the future.
> 
> The most interesting thing I've heard along these lines was described
> in a talk by Matthew Fuchs.   He suggested the idea of using something
> like SGML (of which HTML is a subset) to communicate between smart
> agents.  The idea is to provide a machine understandable equivalent
> of a web form which could be used to send info back and forth.  In
> this application display instructions are not important, what is
> important is the meaning assigned to the keywords.  For example, in
> a simple web page you might use <title>, <body>, <author>, <h1>, etc.
> The browser knows how display these because for simple documents they
> have a well defined meaning, but an automatic document indexer could
> also easily find the title and author.
> 
> Consider an airline reservation system.  It might support a variety of
> commands to answer queries and make reservations.  Clearly once the
> *meaning* is in hand, crafting a way to display it would be easy.  So
> you have a scheme which can be used with equal facility by
> either a human or a machine.  This allows for smooth transition from
> human mediated to automated steps in a larger project (e.g. plan a trip
> visiting these five cities) where some parts have been automated (e.g.
> airline reservations) and other parts have not (say, hotel reservations).
> 
> Further, the system can be built out of layers of objects that give
> meanings to various keywords.  Consider a bunch of keywords and
> associated Java applets that understand dates and times (they know about
> timezones and daylight savings and weekends and so forth).  Another
> level of objects knows how to manage schedules, and still another
> layer knows about travel arrangements.  The system used by a particular
> airline uses all these objects to provide an interface for communicating
> with customers (or their automated agents).
> 
> Java seems ideal suited to be the active lubricant in such a system.

This is a pretty good summation, without the slides.  What I'd add,
though is that I want the smart agents to be our WWW browsers (whose
intelligence I can extend either through local development or by
retrieving software over the Web).  I want the browser to be the
gateway integrating my local environment with the big world out there
and I want it defending my interests.  (I also want to get rid of the
word "browser" because it is too limited.)

If the Web is going to support social interactions and growth to a
zillion nodes, it has to move from a client/server architecture (good
for a browsing human) to a peer-to-peer architecture, like EDI, but
without requiring ISO or ANSI approval to do anything ('cause my agent
will do most of the browsing of the 100 potentially interesting sites
).  We need a "meta-standard" for creating and combining
domain-specific "mini-standards," and let the mini-standards battle it
out in the marketplace.  SGML and IDL are two potential
meta-standards.  Java provides a way to communicate base line
functionality the first time I see a new standard.

At the bottom of my home page are two recent paper submissions on
this.  The first ("Beyond the Write-Only Web") might be particularly
interesting to this group as it talks about how to make a
self-modifying malicious Java applet in the spirit of Ken Thompson's
Turing Award Lecture.

Matthew Fuchs
matt@wdi.disney.com
http://galt.cs.nyu.edu/students/fuchs
Mobile distributed objects, distributed coordination, and lots and
lots of languages

TA:
>The most interesting thing I've heard along these lines was described
>in a talk by Matthew Fuchs.   He suggested the idea of using something
>like SGML (of which HTML is a subset) to communicate between smart
>agents.
>
..
>Further, the system can be built out of layers of objects that give
>meanings to various keywords.  Consider a bunch of keywords and
>associated Java applets that understand dates and times (they know about
>timezones and daylight savings and weekends and so forth).  Another
>level of objects knows how to manage schedules, and still another
>layer knows about travel arrangements.  The system used by a particular
>airline uses all these objects to provide an interface for communicating
>with customers (or their automated agents).
>
>Java seems ideal suited to be the active lubricant in such a system.

yes, I didn't get into some of what you are talking about in my essay,
but that's something very significant that is going on right under
our noses this minute: the formatting of vast kinds of data into
SGML systems.  I have a book called "writing SGML DTDS". it seems
pretty boring-- it talks about how to create tags and all that, and
doesn't give a "big picture scenario" of what this technology can
lead to-- which is unfortunate, because the end result of it it
all is extremely significant.

the framework I like to use to describe this technology is to portray
it as the steps that are necessary to create the "paperless office".
this was a holy grail that computers were supposed to deliver many
years ago, and many have noted the irony that the exact opposite seems to have 
happened in that computers are generating mountains of paper.

it is clear that to achieve the paperless office, many, many standards
have to be devised an adhered to for the formatting of information in
documents.  SGML is intended to be a high-level total overview 
architecture that can encompass all document definitions created by anyone,
and allows embedding of different formats within formats, so that a 
massive hierarchy of interchangeable formats can be constructed.

EDI or electronic data interchange format for billing that many companies
are using (I don't know anything about it I assure you) is an example
of the kind of standardization that is gradually taking place.

whether Java is the "ideal language" to handle all this I think remains
to be seen. I expect amny new languages and concepts to be developed
that focus on the creation/manipulation of document standards. an
object-oriented paradigm will be important in this endeavor, though,
I agree. your idea of relating "documents" and "objects" I definitely
expect to see as a strong emerging paradigm. 

a document will be thought
of as an "object" whose local data are the blanks in the form, and the
document can perform some operations on that data using its "methods".
also the hierarchy you described is very nicely imposed on documents:
a very general "bill" class might have only a "payer/payee/amount/desc"
fields, and all kinds of comkpanies would create their unique 
subclasses that describe their own internal company forms. general
methods would be overridden, etc.

what this is all moving toward, imho, is a kind of  "information assembly
line". imagine every task in the world today that involves nothing
but shuffling information from one form to another, in a way that 
requires "logic" but not human intelligence (i.e. could be programmed
if the data were available in digital form and inputs/outputs were hooked
up properly). I predict that wherever this is the case, there is going
to be a gradual motion toward automization of these processes. 

also note that the concept of an "object" tends to become far less
local and more universal. there may be "objects" "out there" in cyberspace
that you can manipulate and subclass as if they were sitting on your
own computer. but because they are so universal, other companies or
individuals anywhere on the planet may be using the same objects. at
various levels in the hierarchies of data, it is all interchangeable
and related.

this all suggests an amazing new collaboration between 
companies to create standards where everyone benefits. in today's
system, companies tend to behave as if they are isolated entities who
all survive at the expense of the other. I believe this concept will
largely dissipate as companies see themselves as fitting into special
places in a characteristic "niche" of the ecosystem of business. they
will see themselves as components in a massive computing system that
interface to each other via cyberspace. cyberspace becomes then a
kind of nervous system for an entire nation (which it already is,
just not as overtly).

it is quite surprising that given how far we are into the Information Age
how much information and data has resisted the gradual trend toward
automization. many, many companies are interested in "reengineering"
for this reason: they want to take full advantage of technology, but
realize how incredibly difficult this is to do when you have 
decades of "status quo" type procedures calcified into the system that
tend to be hostile & resistant towards automization.
the job of turning documents into data is actually quite herculean--
we have a tendency to see it as trivial but the amount of labor involved
in "conversion" can be enormous. the payoffs are very significant once
you have converted your atoms to bits, though.

the corporations of the future I imagine will have incredible fluidity
without the cost in lack of security. in other words, they will
be able to dynamically "re" configure themselves to suit the instant
because they will have highly organized and malleable 
"central nervous systems" that govern the information flow within them.
these systems will be built out of massive hierachies of document
format standards and enormous, seamless flows of data.

someday, I think every form that is in existence will have an
electronic description similar to SGML syntax, and every aspect of
data shuffling in companies and between them that can be automated,
will be.  its going to be quite awhile before this achieved however.

thanks for your reactions to the writing, which have caused a whole new
avalanche of neurons to fire.. <g>