Lynn Conway: ArchJava

Even though electrical engineering and computer science work with the same parts, they are structured in remarkably different ways.  Each deals with unique aspects of optimizations, unique concerns.  Computer scientists are bound by the rules and speed of the underlying circuitry, electrical engineers by the rules and speed of physics.

For the most part, it is highly reasonable that circuits and software be architected in profoundly different ways.  But to fully understand the reasons for this, the differences should be noted: so what would circuit design look like in Java?  To prod this line of thought, I traveled back to 1982 to interview a young[er] Lynn Conway, co-founder of VLSI, the methodology which gave rise to the development of microprocessors.

Kurt: Mr. Conway, it's--
Conway: Miss.
Kurt: Yes, right, Ms. Conway, sorry.  What were the primary concerns that went into VLSI?
Conway: Hang on, you say you're from the future?
Kurt: 2009 to be exact.
Conway: So what, am I dead or something in 2009?
Kurt: No, no, you're very much alive... you see I just have this blog?
Conway: Blog?
Kurt: I mean, I write these articles in which I interview people from across time.
Conway: Wait, wait, can I ask you a question?
Kurt: Not really, no.  Time paradoxes and all if you learn too much--
Conway: So, you travel through time, make me question my sanity just for some journalistic gimmick?  You could have just talked to me in 2009--
Kurt: Look, Conway, it's not the same.  Just believe this from a man who has been all over time.  It's not the same thing.
Conway: Not the same how?
Kurt: ...people just don't give you the same kind of respect as--
Conway: So you haunt me through time so that you can talk to me without your lingering insecurities--
Kurt: Damnit, woman!  Look, just answer: could you design a good circuit in which all data was either public or private... I mean contained within a component, or accessible by the entire microprocessor?
Conway: God, no.  You have any idea the kind of wasted routing bandwidth that would result in?  Do you have any idea the kind of architectural follies that could result in?  There are advantages in limitations.  But you know what?  When 2009 rolls around, I'm gonna find you and we're going to have a little talking to.  This entire science-fiction charade--
Kurt: Well, young Lynn Conway, it was great, I'll talk to you then goodbye.

Maybe she's right... maybe I'm abusing the power granted to me by my technology.  Perhaps there is too much danger in all of time being publicly accessible.  Regardless...

She asserted the point I was trying to get at.  Just because computers exist in a realm of infinitely arbitrary definition, there are dangers with viewing them as infinite tapes.  Java is used to build enormous systems, yet these are all based upon a rather rigid, and sometimes dangerous level of openness: that all public methods are fully public, accessible by any component within the same project (or by any project invoking its .jar).

Though programmers can define whatever layers, structure, and hierarchy they please, the integrity of that structure is inherently dependent upon the integrity (and knowledgeability) of its programmers.  Many of us have experienced the frustration of having added functionality to the wrong area of an unfamiliar system.  But we must realize that such a blunder was assisted by the language itself-- we were given a structure in which code could be located in a large number of locations, the integrity of architecture was mutable by individual, unrelated decisions.

ArchJava poses an interesting concept: enforce a program's structural integrity through the language itself.  By modifying the standard notion of class interfaces into a far more hierarchical structure, one should theoretically prevent the accidental manipulation of the program's core organization.

There are downsides.  Java already has a notion of hierarchical structure--it's package system.  Imposing another layer could potentially complicate program structure by requiring multiple parallel organizational systems.  But are these trade-offs worthwhile?  In future interviews, we will discuss the mechanisms by which large-scale projects maintain their integrity, and where the balance of flexibility should be falling.