Summary
I just came across Steve Yegge's "Execution in the Kingdom of Nouns," which (might) provide much of the explanation for why Java programs always seem to end up being excessively verbose.
Advertisement
Here is the article, if you haven't seen it (it's from 2006). His point is that Java has gone so overboard into "everything is an object" that it prevents simple and clear expressions of ideas. His very clever translation of Ben Franklin's poem "For want of a nail" into Java makes the point better than anything.
So here's my question: if closures allow you to be slightly more verby and slightly less nouny (in Yegge's frame of thought), will it allow programmers to create programs that are easier to read?
Or will over 10 years of ingrained culture overwhelm any attempts to solve this problem? Which is to say, will Java programs continue to look pretty much the same regardless of additional language features?
If there isn't a way to turn the ship at this point, then the early decision made by Gosling et. al. (to wit, that it was more important to get Java "to market" than to try to get generics and closures and the like into the language) is not something that can be fixed by later patching.
This is what determines the architecture of any software system: the core decisions that influence everything else in the system. These are decisions that you must get right, while other issues can be resolved at a later time through strategic designs. These decisions must be made by an experienced architect who knows what he or she is doing -- a lot to ask, but that's what "architect" is supposed to mean.
At the Java Posse Roundup '08, in the last technical session, we once again discussed the future of Java. We might have come to the conclusion that backward compatibility is being maintained primarily to serve companies that have no intention of upgrading to newer versions of Java anyway.
The most successful languages have been easy transitions from existing languages, so that the knowledge of programmers does not have to be discarded. C++ was extremely successful because it allowed C programmers an easy transition. Java has been equally successful because it provided a transition from C++.
Would it make sense to create a "Java 3K" (playing off of Python 3000, the name given by Guido Van Rossum to the once far-off, backwards-incompatible, fixed-up version of Python which is now going to appear sometime later this year)? A new version of Java that still runs on the JVM and has syntactic similarity with old Java, but is not hobbled with any kind of backward compatibility issues, so it can have real generics, closures, get rid of primitives, etc. If a company didn't want to move to Java 3K -- the same company that probably hasn't upgraded to Java 5 -- then it continues working with what it already has. But programmers who are being held back by the old issues and old bad decisions made in old Java can easily move forward into Java 3K, with only a small learning curve and virtually no productivity shortfall.
From reading the various Python mailing lists, it seems like the biggest stumbling block with the move to Python 3000 is 3rd party libraries. Guido and company openly admit that it will take years before 3.0 is a reasonable default for most people, because even if your project can be easily ported, the 3rd part libraries you depend on will take a long time to get working on the new version.
By having the new and old Javas both running on the same JVM, this wouldn't be a problem, so at a glance it seems like a much more feasible idea. However, the maybe-just-as-big problem for Java would probably be tool support. While I vastly prefer Python to Java as a language, Java wins hands down when it comes to great tools; the Matisse gui builder is head and shoulders better than comparable Python gui tools, just to name a single example.
So to make the switch to Java 3000, not only would tools have to be modified to work with the newer Java, they'd need to be able to work with both Javas simultaneously, since large projects would certainly end up needing to use libraries written in both Javas. This isn't a problem for Python 3.0, since Python projects will be written in either 2.x or 3.x but not both.
With all that being said, I would LOVE to see a Java 3000, and I imagine that such problems are surmountable if Sun ever decided that this was worth doing.
I know this entry focuses on closures, but isn't the current controversy just a symptom of a larger problem, that of Java not being particular suitable for language evolution and a common notion that verbosity reads easier? As in, why have de-facto language support when the GoF book shows it can be solved by the clever use of interfaces?
When one looks at the mentality of Java and its hardcore developer community, it's clear that less verbosity has never been a priority and is sometimes even frowned upon. It took 8 years to get a type-safe Enum (now my favorite Java construct) and now people are claiming it's too late for properties and events.
Extension methods, type inference, decimal literal, operator overloading etc. and all the other little goodies that could make life easier for the developer is often bashed by people invoking the kitchen-sink argument. Even if it opens up for such brilliant and non-verbose features as LINQ.
So I don't think closures will make Java particularly less verbose, after all, few developers need to write fork-join frameworks. I fear it will become yet another half-hearted patch, expand the life of Java a little but also open up for a whole new slew of puzzler's.
I've been rooting for a next-gen Java for years, sadly Sun seems more interested in arm-wrestling with Adobe and expanding perifial language support than fixing/improving Java and recreate the excitement they did in the 90's.
(Someone's bound to say it, might as well be me...)
Java3k == Scala. Seriously. Scala stays about as close as possible to Java while addressing exactly the concerns you mention. They're committed to the JVM and seamless integration with Java libararies. But perhaps most importantly, it has precisely the advantage you mention: it builds smoothly on an existing language. This is a great thing about Scala: when in doubt, you can always fall back on Java intuitions. The result might not be perfect Scala style, but it won't be terrible, and it will always work. Anyone who remembers moving from C to Java will recognize how important this is.
I realize Scala may not be for everyone, and that's fine. But it is definitely very much in the niche you describe, and for that reason alone is worth a serious look. I can't find anything in your original post that doesn't apply to Scala.
Nah, Scala is a research language without an IDE and with bad documentation. Granted, it's the best bid currently but it is far too academic for the average corporate developer.
> It provided a transition from Visual Basic or Delphi to Java.
I don't agree, both Visual Basic and Delphi are based on a very strong component model - that's what makes them so pragmatic. Java has no component model, or at best, multiple broken ones.
> > Java3k == Scala. > > Nah, Scala is a research language without an IDE and with > bad documentation. Granted, it's the best bid currently > but it is far too academic for the average corporate > developer. >
Can we imagine a "Blue Collar" subset of Scala? There is some IDE support in Eclipse and arguably features such as advanced refactoring are quite doable in a static language. A more pragmatic question may be: given how far JRuby has come is there still a chance for Scala to catch up?
No, closures will not make java less verbose, due to the following facts:
* They will not put type inferencing in for argument types. * Checked exceptions will bleed into closure declarations. * There is a suicidal commitment to non-local returns. * There is a comical commitment to "user defined control structures" which are perhaps the least useful, er, use of closures. * There is a suicidal and comical commitment to allowing every possible variable capture semantic, with various and sundry notations to pick between them.
All but #2 are addressable right now in the "consensus" (ha!) closure proposal, but they won't be addressed because, well, because.
> * There is a suicidal commitment to non-local returns.
Depending on the proposal you are talking about. The only one having non-local returns is BGGA, because it focuses on the biggest hammer available to hit every nail existing.
> * There is a comical commitment to "user defined control > structures" which are perhaps the least useful, er, use of > closures.
I thought, you were arguing facts on not making Java less verbose. Control abstraction definitely reduces verbosity.
> All but #2 are addressable right now in the "consensus" > (ha!) closure proposal, but they won't be addressed > because, well, because.
Well, the "consensus" is, that we all want closures and see a huge benefit for Java in having them. It's not about a particular proposal or a final set of semantics or syntax. If you have ideas, concerns, requirements, etc. on closures, join the supporters and/or propose alternatives.
I disagree. Scala is far away from Java. It's interoperability very well should be matched in J3K, but the language itself is completely foreign for Java developers.
The major problem I see with those languages is their tendency to add up new keywords and symbols instead of using as few language constructs as possible and shift the power on design and usability towards APIs.
To me, J3K would be: - drop primitives - make operators become methods - make classes become real objects (enabling meta-objects) - make methods become first-class members - shift control structures to API solutions - keep Java "look and feel" - keep interoperability with JVM-based languages
To begin with, I don't like the idea of closures. Neither do I like things like properties or events. The more different constructs there are in a language, i.e. the richer its grammar and syntax are, the harder it is to learn and read. What good is less verbosity, if you spend twice as much time reading the code?
IMO, there's a good reason Java is verbose: Java code using reasonable names is easy to read - a lot easier than less verbose equivalent C++ code. (Just my opinion, but then again, I never liked C++.) Also IMO, using state of the art IDEs makes the verbosity no pain at all when writing code.
IMO, there are three things to make Java both less verbose and better: proper generics (what's in 1.6 is a joke, not really generics), operator overloading, and a smarter array syntax. As far as I can judge this, you need to extend the JVM for proper generics, but not break backwards compatibility, but you only need to change the compiler in order to add operator overloading. As for the array syntax, IMO we can live with this, especially if arrays get replaced by smarter containers - quite doable, if operator overloading is provided.
As far as I can think of, the typical use of closures will be in writing event handlers a la swing. IMO, there is little difference between using closures or using anonymous inner classes in such situations.
If Java ever gets operator overloading, I can think of an implementation of events and properties which isn't part of the language. You get rid of the set/get idiom for properties, and use plain assignments instead, and you get to hook methods into objects as listeners, and all these without adding more constructs to the language.
> IMO, there's a good reason Java is verbose: Java code > using reasonable names is easy to read
I'm sorry but this is bullshit. There are multiple languages that are widely considered easy to read yet aren't anywhere nearly as verbose as Java. Python, for example.
Java is verbose not because it's easy to read, java is verbose because the most trivial thing takes lines and lines of code.
> - a lot easier than > less verbose equivalent C++ code. (Just my opinion, but > then again, I never liked C++.)
One should hope so as that's what Java pretty much started from.
> Also IMO, using state of > the art IDEs makes the verbosity no pain at all when > writing code.
Well your opinion is wrong on that. Maybe you don't realize it because you've always lived in javaland, maybe you don't realize it because each iteration of your IDE of choice makes java a bit less painful, but the requirement of a 500Mb ram footprint IDE to edit java code in a not-too-painful way makes java's verbosity and issues even clearer.
Not to mention, the IDE excuse could be accepted if the IDE was part of the language, à la Smalltalk Environments. Alas, they aren't, and thus are merely crutches and bandaids over the inadequacies of the language.
And your opinion on first-class functions and closures is irrelevant as you've quite clearly never practiced a languages where they were widely used, or even used at all.
> To me, J3K would be: > - drop primitives > - make operators become methods
Scala did both, reducing so much complexity. Its really too bad that Java has primivites from the start, as it seems to be just a little bit more work for the compiler.
> - make classes become real objects (enabling > meta-objects) > - make methods become first-class members
Could you explain these a bit, maybe provide an example why these are useful, especially in a static type/compiler language?
> - shift control structures to API solutions
I think the strongest argument for BGGA proposal is that it enables that quite nicely.
> > To me, J3K would be: > > - drop primitives > > - make operators become methods > > Scala did both, reducing so much complexity. Its really > too bad that Java has primivites from the start, as it > seems to be just a little bit more work for the compiler.
Smalltalk has this since last century, so Scala actually only reinvented a wheel ;) Primitives (including arrays) are the worst thing to be put as non-OO elements into a high level language. It's always a pain to develop around these elements, so one can handle them equally to objects.
> > - make classes become real objects (enabling > > meta-objects) > > - make methods become first-class members > > Could you explain these a bit, maybe provide an example > why these are useful, especially in a static type/compiler > language?
Meta object programming saves from implicit contracts and (ugly) workarounds like Aspect-oriented Programming. Think about all those factories, which only are to provide some implicit standard interface to create some objects from dynamically added classes etc. First-class methods kind of provide what one desires with closures: functional programming in an object-oriented way. It's passing bound and inner methods instead of some alien functional construct.
> > - shift control structures to API solutions > > I think the strongest argument for BGGA proposal is that > it enables that quite nicely.
Similar to First-class methods, which puts those into Java-like style and semantics.
> Backwards Compability
I'm quite mixed on it. My experience tells me, that commercial projects usually take a very long time before changing to a newer version of the underlying technology (and they won't pick the latest then either). No matter, whether or not the new version is claimed compatible. For a J3K I'd assume a compatibility wrt. using existing libraries and some migration path for applications would be sufficient to reach the same goal. The QA has to be done anyways, and usually a platform version change will go hand in hand with a refactoring of the application itself.
Flat View: This topic has 70 replies
on 5 pages
[
12345
|
»
]
Previous Topic
