Java-the-language is dead.
Get over it, and realize that because of that fact, you'll probably come to depend upon Java more than you ever thought possible.
Emerick's point is that many systems languages—languages used very widely in creating infrastructure software—reach a level of maturity beyond which new language additions produce diminishing returns. He believes that Java has reached that point some time ago:
It seems that Sun decided long ago, through pressure from its customers and developers, that compatibility is more important than innovating at the language level. With that, managing Java and the JDK became more an exercise in stewardship than anything else...
That may make the Java language dead with regard to features, but it's hardly useless – it's simply transitioned to be the stable "systems language" for the JVM that a large swath of programmers (who Sun likely correctly identifies as being uninterested in things like closures, syntactic improvements, etc. etc.) happen to use for applications as well.
Trading off "progress" for stability bestows upon Java at least two characteristics that are shared by other systems languages:
Screaming into the void about how improvements and changes should be made yesterday is generally pointless and irrelevant
Knowing that the language is essentially fixed for years to come means that it fades into the background as a very useful artifact for those that want to build on top of a system with well-known characteristics
Emerick points to many unsuccessful attempts to add features such as closures to Java:
Closures are never going to be added to the Java language. Done, and done. And if closures aren't going in, then you can surely bet that other things aren't going to make it, either. To further make the point, Joe [Darcy] commented on an earlier blog post ..., saying in reference to a question about why the Java standard libraries don't slough off deprecated APIs:
To date, we have valued continued binary compatibility with code calling the deprecated elements more than cleaning up the API.
Emerick notes that Java's maturity and stability means that Java can emerge as an even more important language:
The upshot of all this is that it's more likely than not that over the course of the coming years, your life (and quite likely your professional life as well, if you're involved in software) will come to rely upon Java, the JVM behind it, and many different other language stacks built on one or both of those technologies...
In the end, we might have all been better off if the current state of affairs had arrived years ago. A steady drip, drip, drip of Java language improvements serves only to keep developers tied around what is functionally a frozen language, and away from superior alternatives (on the same JVM platform!) if they're so inclined to look up from their work.
Do you agree with Emerick that Java has reached a period of stability and, further, that because of that it will become an even more prominent language? And do you believe that the vast majority of Java developers, according to Emerick's blog post, are really not interested in more advanced language features and are content with what Java offers today?
Java hit a sweet spot in the software landscape when it first appeared with its right mix of simplicity, power, and JVM & library support and it continues to do so.
Most Java developers are quite content with this combination. The evolution of IDEs, static analysis and bugfinding tools, and other developer productivity tools have cemented this. And fortunately, the era of J2EE and other such monstrosities has come and gone ...
Python and Ruby will have their niches, but as a general purpose, performant, VM based language and platform, Java rules and will do so for quite some time.
One "solution" would be to finalize Java 7 as "classic Java" (with continued support in the compiler/JVM for "classic" Java applications), and then Java 8 (and moving forward) would be Scala.
This would include the discontinuation of the name "Scala", leaving the reference "Java" to referring to the formerly-known-as-Scala language, and "Classic Java" referring to the frozen spec of what we currently know as Java (v1.x - v7.x).
This would breathe new life into Java/JVM and provide an architectural/syntactical transition to the next-generation of functional/OO hybrid, terse-by-convention languages.
Since Odersky (et al) developed the current Java compiler, it isn't so much of a stretch than it appears at first glance.
This is predicated on Odersky and his team "wanting" to be the next Java. And most likely a new process for evolving the language (JCP sucks).
If Scala's assumption of the Java lineage occurs, then using 'Scala' in the enterprise would have little or no push-back from management.
> Just a thought... > > One "solution" would be to finalize Java 7 as "classic > Java" (with continued support in the compiler/JVM for > "classic" Java applications), and then Java 8 (and moving > forward) would be Scala. > > This would include the discontinuation of the name > "Scala", leaving the reference "Java" to referring to the > formerly-known-as-Scala language, and "Classic Java" > referring to the frozen spec of what we currently know as > Java (v1.x - v7.x). > > This would breathe new life into Java/JVM and provide an > architectural/syntactical transition to the > next-generation of functional/OO hybrid, > terse-by-convention languages. > > Since Odersky (et al) developed the current Java compiler, > it isn't so much of a stretch than it appears at first > glance. > > This is predicated on Odersky and his team "wanting" to be > the next Java. And most likely a new process for evolving > the language (JCP sucks). > > If Scala's assumption of the Java lineage occurs, then > using 'Scala' in the enterprise would have little or no > push-back from management. > > Like I said, just a thought...
Yeah, and lets tag everything we ship with ".NET" on it to confuse everyone what .NET is.
And yeah, lets call it Java 5. No, wait, Java 1.5.
Been there, done that.
No thanks.
Maybe Oracle should change its stock ticker to SCALA? (What's "Oracle" in Italian?)
java will slowly move from production area to maintenance area and will be replaced by another jvm language (scala?) in the production area. which is good :) the functional/oop hybrid trend in language developments is evident.
My whole point was to start discussion as to what's "next" in the Java world; if Java developers were going to let all of the hard work on getting Java to be accepted as an enterprise development platform by the pointy-haired management types (I've been in the trenches for 12 years on this front), or maintain that hard-won enterprise real estate with a next-gen func/oo language, possibly Scala.
The pedigree and provenance of Scala is unquestionable and, although it did give me a laugh, comparing it to labeling everything .NET "to confuse everyone" is a bit disingenuous.
And I've been through the 1.5/5.0/1.6/6.0 marketing weirdness as well but this would be clean demarcation (7.x -> 8.0) so I don't think the 1.5/5.0 point is entirely applicable, although I well understand the sentiment.
What I was proposing for discussion is how the Java community can move forward without being relegated to legacy and maintenance modes.
To do this, a disruptive change needs to take place, like the PERL 5.x -> 6.0 decision made by Larry Wall. Wall said of the move: "the Perl 6 approach is to break everything that needs breaking all at once."
But the move doesn't have to 'break' everything since there's a distinct line between Java and Scala so 'classic Java' applications would continue to function with no need of modification.
So since this level of disruptive and critical architectural change has never been done before, no one has 'been there, done that.'
After putting the 'thought' of replacing Java with Scala in-place into some context, it's just that, a thought.
The larger question, .NET and stock ticker references aside, is what the Java community is going to do moving forward and how we can build on the success of Java (it's treated me and my family well over the years).
Essentially, what's next? And how do we get there?
Is it a patchwork of JVM-based scripting and programming languages? Do we go ambling along as a merry band of byte code gypsies?
With the legion of Java professionals looking down the barrel of the Oracle Sun acquisition and the stagnation of the JCP, now's definitely the time for a tectonic shift.
For me, personally, the biggest issue is productivity: I want to be more productive on the Java platform than I can be with the Java language, but I also want to use all Java has to offer. At that point I can use JRuby or some other JVM language (although the number of really mature JVM languages is not that high, IMO). And I think that's a valid route, although in my case I found that not only did I prefer Scala's static typing (which is absolutely fantastic when you have 100s of classes in a project), but I also like the rigorous thinking that Odersky & Co. invested into Scala.
So while Java can become a "systems language," I think that enterprise IT folks at some point would want to squeeze more productivity out of their developers, and then they'll have to make a choice, they'll have to look at something new -- because their competitors or developers at other firms might become more productive over time, and the entire productivity standard on the JVM might be raised. That's one of the reasons, I think, why Java became so widely adopted in the first place - developers could accomplish more of the stuff they needed to in shorter time and with less lines of code. So I somewhat disagree with the original post that Java will became even more widely used.
For me, the Scala route has been working out very well, and I sure hope the Scala ecosystem builds out even more, mainly in the direction of making it even more convenient to use the most important Java APIs from Scala, IDE support, etc.
in another words, scala needs to be promoted more. since it's a jvm language, it allows you to reuse a lot of java code, which on another hand, is leaving you a little space for the breakthrough we need. thinking of scala, it reminds me that it does almost nothing for desktop clients. same mistake like with java X years ago.
I find Scala a little "too much". Maybe it will grow on me, but there seem to be many places where they are different than Java just for the sake of being different.
Wondering if some form of "Scala-Lite" would be the way to go. Take the really good ideas from Scala and maybe drop a few of the others.
> I find Scala a little "too much". Maybe it will grow on > me, but there seem to be many places where they are > different than Java just for the sake of being different. > > Wondering if some form of "Scala-Lite" would be the way to > go. Take the really good ideas from Scala and maybe drop > a few of the others.
Agreed. Scala has become a bit too complex to my taste, which makes me really sad.
I think Fan (http://fandev.org/) is shaping up to become a very interesting compromise between Java and Scala, and the recent announcement of an Eclipse plug-in is making me even more enthusiastic about it.
Back to Frank's point about productivity: I don't think that a language that's more compact and more expressive than Java will necessarily lead to higher productivity, especially if that language has crossed that complexity threshold.
> Agreed. Scala has become a bit too complex to my taste, > which makes me really sad. > > Back to Frank's point about productivity: I don't think > that a language that's more compact and more expressive > than Java will necessarily lead to higher productivity, > especially if that language has crossed that complexity > threshold.
Cedric,
I'm just curious, What features of Scala do you think are too complex?
I've been using Scala in a largish project for the past couple of months, and have found that I can get away without using some of the more esoteric language features -- but those features are there for the times when I do need them.
> I find Scala a little "too much". Maybe it will grow on > me, but there seem to be many places where they are > different than Java just for the sake of being different. > > Wondering if some form of "Scala-Lite" would be the way to > go. Take the really good ideas from Scala and maybe drop > a few of the others. > I have heard the Scala-lite suggestion before. I have tried to think of what could be removed. You could certainly remove things, which would make the language simpler, but in exchange you always end up making something more complex in your code or life. Although the Scala language is indeed complex in certain ways, there isn't much accidental complexity in there. Everything is really there for a reason, and so if you take something out you lose as well as gain. That doesn't mean some people wouldn't rather have a simpler language even if it make certain aspects of their code or life complex.
One concrete example I can give is that Scala has both abstract type members and generic type parameters. These two features are to a great extent redundant, so you might imagine dropping one. So which would you drop? Well, Java gets by just fine without abstract type members, so my first guess would be to drop type members. However, Java actually does have type members, because inner classes are a sort of type member, but it is less general than in Scala. (One way Scala is *simpler* than Java is it has far fewer special cases.) But Java also doesn't have traits, and it turns out that abstract type members make life simpler when you want to let people mix in definitions of abstract types via traits. I just described that here:
So, yes, you could drop abstract type members in an attempt to make a Scala-lite, but if you keep traits, you just added some pain to the programmers lives who want to use Scala-lite to let people mix in abstract type definitions via traits. And I think you should definitely keep traits, because they really rock.
> > I find Scala a little "too much". Maybe it will grow > on > > me, but there seem to be many places where they are > > different than Java just for the sake of being > different. > > > > Wondering if some form of "Scala-Lite" would be the way > to > > go. Take the really good ideas from Scala and maybe > drop > > a few of the others. > > > I have heard the Scala-lite suggestion before. I have > tried to think of what could be removed. You could > certainly remove things, which would make the language > simpler, but in exchange you always end up making > something more complex in your code or life. Although the > Scala language is indeed complex in certain ways, there > isn't much accidental complexity in there. Everything is > really there for a reason, and so if you take something > out you lose as well as gain. That doesn't mean some > people wouldn't rather have a simpler language even if it > make certain aspects of their code or life complex. > > One concrete example I can give is that Scala has both > abstract type members and generic type parameters. These > two features are to a great extent redundant, so you might > imagine dropping one. So which would you drop? Well, Java > gets by just fine without abstract type members, so my > first guess would be to drop type members. However, Java > actually does have type members, because inner classes are > a sort of type member, but it is less general than in > Scala. (One way Scala is *simpler* than Java is it has far > fewer special cases.) But Java also doesn't have traits, > and it turns out that abstract type members make life > simpler when you want to let people mix in definitions of > abstract types via traits. I just described that here: > > http://www.artima.com/weblogs/viewpost.jsp?thread=270195 > > So, yes, you could drop abstract type members in an > attempt to make a Scala-lite, but if you keep traits, you > just added some pain to the programmers lives who want to > use Scala-lite to let people mix in abstract type > definitions via traits. And I think you should definitely > keep traits, because they really rock.
I haven't use Scala enough to know how it really fills, but I find big languages scary. I was looking at Felix the other day, which contains everything: object oriented programming, functional programming, compile-time programming, an open grammar, garbage collection, multiple dispatch, etc...in theory, it sounds nice, but in practice, it seems scary. Felix is around for a few years, but I've never heard being used anywhere.
> Cedric, > > I'm just curious, What features of Scala do you think are > too complex? > > I've been using Scala in a largish project for the past > couple of months, and have found that I can get away > without using some of the more esoteric language features > -- but those features are there for the times when I do > need them.
Well, this in itself should raise a red flag. What good is a language if you need to intentionally not use some of its features in order to produce large quantities of maintainable code? Doesn't this remind you of C++? Every company that I have worked at has an internal "C++ guide lines" document that says exactly what to use and what not to use. Interestingly, these documents vary quite a bit from one place to the other. Some argue that it can be seen as a strength of the language, a bit like Word or Excel that have thousands of functions that very few people use but which make it possible for so many different scenarios to be covered.
Back to your question.
While there are a few features that I'm not very fond of and that I documented on my blog (namely, implicits, matching and structural typing), each individual feature of Scala sounds great on paper, and I mean that literally (I quite enjoyed your book for that reason). I think that what makes Scala difficult is the combinatorial explosion of all these features, especially when you start using Scala's generic type system extensively.
I have browsed quite a bit of Scala source code of big projects to get a feel for what Scala looks like in the trenches, and I was quite disappointed to see that all the neatness that I found in your book is gone. All the compactness and functional beauty that Scala seems to make so easy to generate disappears to be replaced by hardcore C-like thick code. Even closures and matching become difficult to read.
I'm also regularly frightened by the snippets of code that I read on a daily basis on the Scala mailing-list. Maybe this should not come as a surprise since the list is meant to investigate and elucidate the dark corners of Scala, but I never had this problem with the Fan mailing-list.
Just my 2c.
-- Cedric
Flat View: This topic has 27 replies
on 2 pages
[
12
|
»
]
Previous Topic
