The same thing that makes
our naming policy difficult to understand?
Ok, that sounded a little bit unfriendly. My apologies. Your name just looks obviously fictitious to me, and please forgive me if this merely shows my cultural prejudice.
I would not say that Java in itself is difficult to understand. Systems in Java can be difficult to understand, but then again almost any non-trivial system is difficult to understand. Think of a bacterium or a cell of the human body. Think of a simple proton consisting of three quarks and a bunch of gluons.
The reason is that, even if you have a good understanding of the individual constituents, the interactions between these constituents are often complex and non-trivial.
Software development -- as most other engineering disciplines -- is the art of building larger components from smaller ones. Its success is determined by our (in)ability to think of suitable high-level abstractions for the larger components we build. Ideally, they from a coherent, sealed, opaque whole that make sense in themselves and do not require you to be aware of the smaller building blocks that went into them.
Take the Java programming language, for example. Sun took the hardware the machine runs on and the little instructions the CPU executes and built higher-level abstractions out of them. You work with these abstractions -- an Object. A java.net.Socket. As such, these abstractions are extremely successful; you rarely have to worry about what actually happens under the hood.
As a developer, you often work with even higher-level abstractions. Library writers have taken the Java platform and built the next level up. Databases, application servers, graphing libraries, that kind of thing. This is where our ability to achieve this ideal of a coherent and opaque abstraction often starts to break down. Many databases do not allow you to completely forget completely about the physical records that are being written on disk somewhere. Working with application servers often requires an intimate knowledge of the plumbing that goes into them, especially if you are to understand their quirks (and the
EJB tier is the worst offender by far).
The problem is that, because of the cracks that show up in our building blocks, they start to interact and react in complex and hard to understand ways.
The actual application code that is generally being developed is a total horror. Yup, that's you and me
Upon the flawed abstractions discussed above we usually build outright ill-thought-out, misconceived, dysfunctional abstractions and assemble these into an application. As a developer, you need to be aware of several layers at once, and you need to make sense of highly complicated interactions which cross a number of layers.
This is why Java is hard to understand. And C. And C++. And C#. Pascal. Perl. Python. And most other programming languages under the sun. The few exceptions have for various reasons failed to make a significant dent in mainstream software development.
- Peter
[ November 29, 2002: Message edited by: Peter den Haan ]
