Re: The Problem with Programming
Posted: Nov 29, 2006 9:15 AM
> > I am already seeing the leading edge of the Java continent
> > crumbling into the onrushing sea, so I hope to figure out
> > what comes next
> Out of curiosity, what are your thoughts on this, if any?
I have lots of thoughts on it, but I'm not sure how "timeless" they are because they are likely more _reaction_ to those failings that I see in Java and other languages than _vision_ of how things should be. (As but one example, I think C# is an excellent example of a result of myopic "here's how I would have done it" thinking.)
I would suggest some general attributes of languages moving forward, as opposed to concrete predictions; note that I couch these vis-a-vis Java:
* The object-based programming metaphor will likely be retained by the next major language wave, just because it is [relatively] well-understood by the current generation of programmers.
* I would expect that both "AOP" and "inheritance" as separate concepts from composition will disappear. It seems logically obvious to me that "mix-ins" and "inheritance" and "composition" and "aggregation" are all just facets of the same basic concept, and it should be possible to cleanly merge them. Ruby is likely halfway there already.
* Similarly, there will be no fundamental difference between an interface, an abstract class and a concrete class.
* The divide between primitive types and reference types (and related topics such as boxing) will likely disappear, although all the above will obviously still exist at some level (just as a pointer to a pointer to an array of function pointers exists in C++, but we choose to refer to it as an object).
* To eliminate primitive types and be broadly deployable to many platforms while providing efficiency close to current languages / runtimes, the virtual machine will have to define all types as we currently define interfaces, but it will also have to define the behavior of those types as the language defines final classes (such as boxing classes: Integer, String, etc.) in Java. In other words, the programmer will likely treat all types as objects (including intrinsically machine-supported types), yet the runtime will have the choice of "inlining" the functionality (e.g. "native" methods in Java, as well as specific methods that Hotspot has hard-coded awareness of) versus using the "default runtime library" implementation.
* At a low level, the "word" size may be 64-bit, but many platforms (mobile included) will probably stay 32-bit for the next 5 years. That means that the language should largely mask the detail of the word size (including array offsets, etc.) from the programmer. This would imply that an array type (for example) would itself be an interface, with the index operations being parameterized using a more abstract index type (e.g. "number"). Again, the Hotspot type technology is responsible for avoiding Smalltalk-like performance, but the language (VM in this case) needs to be designed explicitly to facilitate that.
* Intrinsic decimal type (IEEE 754r) are a sorely missing feature of Java and other languages. FP (binary and decimal) will need to support at least 32/64/128-bit. Unfortunately, no higher precision standard exists yet (e.g. 256 bit).
* All aspects of the objects will be conceptually virtual invokes, including properties (nee fields), methods and constructors. Obvious minor implications: No more accessor / mutator boiler-plate. No more boiler-plate factories (virtual "new").
* The language run-time needs to be designed for virtualization. Java is a b*tch to virtualize due to a complete lack of modularization within the VM (classloader partially excepted).
* R.I.P. fields, "static", "interface". These are left-over language anachronisms.
* The runtime will itself be completely visible within the runtime. Reflection, introspection, dynamic classes -- these are just the tip of the iceburg. What about variables? They are objects too. Instructions? The stack frame? Almost everything the runtime does should be expressable in terms of the same building blocks that one builds applications from (i.e. object classes).
* Exposing the runtime in detail in terms of the same model as applications employ, and driving toward more virtualization will mean that security can no longer be an after-thought. A closed-loop, archtitected-in, provable security model will be required.
The only question is do we just want an incrementally better Java (which would likely break backwards compatibility), or is it a fundamentally new language / runtime. My guess is that we'll see both.
> > so I can stave off my own inevitable
> > obsolescence.
> I appreciate the humility and all but give me a break.
> You clearly have skills that are much more long-lasting
> g than knowing how to use language X, as I hope I also do.
The problem isn't skills, it's attitude. People get old and [mentally] brittle just as code does, and we get stuck in our old ways. I assume that I am no more immune to that than other people, such as obviously-smart people like BS.