See what I said below about how much I prefer JPQL and Spring Data... Personally, I really do not have a problem with this.
And yet some very complex solutions were solved with very simple languages, before Java was conceived.
So we're stuck with these complicated compile-time rules for defining everything in terms of a procedural language. We come up with complicated templates and generics for getting one set of methods to work with two types of data. Objects are needlessly serialized and deserialized to pass between systems, and programmers are needlessly spending time writing such methods.
I'm surprised that scala's paradigm of having actors work on data hasn't caught on more. When you separate them from the start, new modules are way easier to right, and integration time drops to near zero.
Or more accurately, the problem is that Java was a new language shoehorned into being "like" a language that was never meant to hold the concepts that Java demands. In some cases this manifests itself in more syntactical ways; C's pragmatic but unsophisticated approach typing works well for C, but starts to become a real burden when you start adding more sophisticated concepts onto the language. (Were generics really a concept that were ever appropriate for something like C? Generics deserve a more considered treatment; a language with structure and syntax designed with them in mind.) In other cases the impact is more clear but inexplicable; "In Java Everything is an Object"(tm)... except for the things that are not.
The end result is a language that is ugly and clumsy to work with without some pretty advanced tooling, all for reasons that really have no business being real problems. Shameful (primarily cosmetic) flaws forced upon Java by the business decision: "make it reminiscent of C".
I have the same complaint about C++. Had Java and C++ not burdened themselves with the design requirement of looking like C, they would be much better languages. Languages that stray further from the mold, like Scala or Go (I am thinking particularly of their abandonment of C inspired defines, in favor of a more Pascal approach), are more pleasant to work with for it. Perhaps this damages adoption.. but that is another matter I think.
The same could be said about Ruby and it's relationship to Perl and Python. It has cultural roots in those languages, but is often regarded to be better rather than worse. (As a die-hard Perl developer I disagree, but I don't hold a grudge.) All three are also considered to be C-like languages too, and they don't suffer the problems Java has.
One could argue that Java's problem was that it was designed for programming VCRs, DVD players, and Cable-TV boxes, and similar equipment, but the got stretched and pulled into environments it just wasn't ready for. That, plus Sun's hyper-aggressive marketing machine to turn Java into the language-for-everything, created the beast that it has become.
My personal view is that Sun turned Java into a programming language for charge-by-the-hour consultants. The culture of over-engineering exists because it takes a lot more time to design software that way, more time and larger teams to implement software that way, and specialized hard-to-transfer knowledge to maintain that kind of software. This all benefits the consultants and hurts the companies paying for the software to be built, which only makes sense if Sun was intentionally pushing Java that way.
I wouldn't describe C# as a language that I like, but I think it too has benifited from breaking the mold of C more than Java did (though I attribute most of it's superiority to its designers simply making better decisions in several places). Named and optional arguments stand out in my mind as ways C# did something that had no precedence in C, while Java still has not. (There is that double squiggly bracket trick, but you have to admit that is pretty shoddy).
I do like the way jfb suggests using the concept of 'affordances' with languages/environments, to analyze what sorts of code they encourage. But to really do that, we'd have to actually identify these specific affordances, which i'm not sure how to either.
(And as far as your particular line of argument -- does anything in a processor know what an 'actor' is either? If not, I believe you that you find 'actor' a better abstraction than 'class', but it must not have anything to with either one being something the lower-level computer architectural abstractions 'know about')
There's a saying that one can write COBOL in any language, but nobody is born itching to POST INCREMENT C BY ONE. A given technology has a spirit; that spirit guides the usage of the technology; and people who use that technology, and share a sufficiency of that spirit, will find a welcoming home. That spirit is intrinsic to the technology; changing Java to not rely on Simula style classes for code namespacing would destroy Java -- it'd be something very different, and the usage of this new language would mean entirely new styles of conceptual organization.
I'm not taking a stance in this post on the aesthetics of the various ways to organize programs; but I do think that the forensic exercise of determining the -- I dunno, zeitgeist? -- of a technology is an interesting, rich one.
Unfortunately, Java is also not a very powerful language. Many of those OO gymnastics are only relevant because the language isn't expressive enough to achieve the same results in a simpler, more direct way. Java is the language where design patterns in the Gang of Four sense first became popular, and it's often been suggested that design patterns indicate missing language features.
Exactly right. In previous decades, had they been using modern terminology, calling conventions would no doubt be covered by plenty of "design patterns". We don't speak of calling conventions that way now because languages provide that for us.
For better or worse, Java has much simpler semantics.
PS: THE Java® SE 7 Edition of The Java Language Specification describes all the features that have been added to the Java programming language in Java SE 7. It also integrates changes made to the Java programming language under maintenance since the Third Edition in 2005. http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf. It's 670 pages long.
Unfortunately, among the major industrial programming languages, that is far from the longest specification out there. Moreover, some of the major industrial programming languages don't even have a standard reference specification. Notwithstanding its length, the Java spec is actually fairly efficient and well-organised in comparison.
And if we actually used those languages, we would probably be seeing much lower bug rates in production software already and we could start looking into what else could be improved next. Unfortunately, most of the popular industrial languages don't even get that far. :-(
Paradoxically, this assignment has given me a great deal of respect for the idiots who conceived of the damned thing in the first place.
the perceived elegance of this approach makes junior CS college student eyes glow when s/he first hears about it, and that glow continues for, in the best case, at least a decade after college.
At which point I bring you the story of the king's toaster [1] (which is a cautionary tale, not an aspirational story, just in case that should be unclear to anybody).
------------------------------------------------
Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob and a lever. "What do you think this is?"
One advisor, an engineer, answered first. "It is a toaster," he said.
The king asked, "How would you design an embedded computer for it?"
The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years.
With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes and waffles; pork divided into sausage, links and bacon; and poultry divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs, and various omelet classes.
The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself'. The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs.
Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too.
We must not forget the user interface. The lever that lowers the food lacks versatility and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface.
When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it and the message 'Booting UNIX v. 8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook.
Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)."
The king had the computer scientist thrown in the moat, and they all lived happily ever after.
[1] http://www.ee.ryerson.ca/~elf/hack/ktoast.html