The Artima Developer Community
Sponsored Link

Java Community News
Java Futures Panel at TSS Symposium

9 replies on 1 page. Most recent reply: Apr 3, 2006 12:16 PM by Isaac Gouy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 9 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Java Futures Panel at TSS Symposium Posted: Mar 29, 2006 11:19 AM
Reply to this message Reply
Summary
Last week's ServerSide Java Symposium concluded with a panel about the futures of Java that included half a dozen Java thought leaders. The discussion focused on what Java can learn from scripting frameworks, such as Rails, where open-source is leading Java, and why open-source is not free.
Advertisement

An increasingly favorite passtime of Java thought leaders is to ponder about the future of Java - or even whether there is a future for Java.

There are two reasons such discussions might be enlightening: Java as a language is now over a decade old, and one must wonder what the developer community has learned over this time and how Java developer's are responding to that experience. And, second, non-Java solutions are increasingly emerging for problem domains that have traditionally been among Java's strongest aspects, such as enterprise Web application development. (A third reason to pay attention to such debates might be the entertainment value obtained when the predictions made at such panels turn out to be so off the mark.)

Last week's TSS Symposium in Las Vegas concluded with such a panel, including Ari Zilka (president and CEO of Terracotta), Bruce Snyder, Bruce Tate, Cameron Purdy (Tangosol), Floyd Marinescu (founder of TheServerSide.com), and Rod Johnson (founder of the Spring framework).

According to a recent eWeek article about the panel, among the issues discussed were scripting languages. Predictably, Bruce Tate reiterated his well-known position, "I think Java is in trouble on the low end because Java is not approachable anymore." Others responded in strides. Floyd, for instance, is quoted as saying that "Ruby is a symptom, not a solution. I think there's a strong need for whatever the Web platform is to integrate with Java." Rod Johnson, however, remarked that he did not see an uptake in Spring integration with scripting languages.

Cameron Purdy is quoted to comment about open-source and why companies should aim to make their engineers rich:

Anything we take for granted is going to be covered by open source sooner or later. If commercial companies can't innovate fast enough to outrun it, it will cut into the funding for commercial R&D. But if we keep ahead we'll be able to attract the best engineers and entrepreneurs. If we can't enable people to get rich we won't be able to attract the best and the brightest.
But Rod Johnson, who makes a living providing commercial support for Spring, disagreed:
I disagree with people who believe the role of open source is to take the place of commercial software. [...] There's no mission to rid the world of commercial software. [...] Open source is not free; it's open, it's not necessarily free [...] We definitely are going to see that open-source software does make people rich.

Other aspects of the discussion focused on EJB 3.0 and AJAX.

What do you think of the future of Java? Are the points brought up in this panel valid? Do you see the panelists' points being relevant in your Java-related work?


Ivan Lazarte

Posts: 91
Nickname: ilazarte
Registered: Mar, 2006

Re: Java Futures Panel at TSS Symposium Posted: Mar 30, 2006 2:31 AM
Reply to this message Reply
I wrote a forum post on this at the java.net forums, basically asking the question, Is Bruce Tate Still Relevent?

Read it here:
http://forums.java.net/jive/thread.jspa?threadID=14208&tstart=0

I'm tired of a "Rails future" and a "Java past". I'm all for scripting language/dynamic frameworks, but blindly spreading the gospel of one framework is really just propaganda and marketing instead of insight. Maybe he strives to be Rails' Paul Graham...

In complete contrast, someone like Rod Johnson is for level-headed discussion and information exchange. Too bad the news sites are so quick to promote inflammatory "Java is dead" headlines instead of real communication like his.

---

Java is nowhere near threatened. Any high-level language that features duck-typing cannot replace Java, it simply wont. It will generally be slower, and it wont scale to large projects.

As someone who has done web development since '99 or so, I've moved *to* Java from scripting languages. There are so many reasons why, but the list is almost identical to the scripting language benefits.

To everything simply add "is a major convenience for small and expirable projects but becomes a major hassle when the code base is large, or the team has changed over time"

1. dynamic typing
2. speed sacrifices for code convenience
3. conventions over configuration

It's simply true, and experience has taught me that lesson many many times.

Ruby on Rails is a great mom and pop shop maker, and that's fine; but then it's major enemy is php, which dominates that market. It should pick it's battles carefully lest it awaken the sleeping giant.

So far Java for the web has stayed out of the mom and pop shop business, but now we're being goaded into proving how it's capable of handling those cases too.

The community will respond dramatically. I don't doubt that a Java-based superior framework to Rails is under development or will be developed soon and showcased.

V.H.Indukumar

Posts: 28
Nickname: vhi
Registered: Apr, 2005

Re: Java Futures Panel at TSS Symposium Posted: Mar 30, 2006 5:32 AM
Reply to this message Reply
Another new acronym that I do not have much fancy for is AJAX. The browser + web was simply not meant to simulate stateful applications. It just gets more and more complicated to build applications that can be maintained easily if we use the JavaScript mess (JS is a good language, but its implementation accross different browsers is hell). Web is good for publishing, but when it comes to complex user-friendly applications, it just becomes a maintainance hell. Moreover, we can never be sure how the browser manufacturers will respond in the future (hit: Internet Explorer & XAML).

Bill Venners

Posts: 2251
Nickname: bv
Registered: Jan, 2002

Re: Java Futures Panel at TSS Symposium Posted: Mar 30, 2006 4:17 PM
Reply to this message Reply
> I'm tired of a "Rails future" and a "Java past". I'm all
> for scripting language/dynamic frameworks, but blindly
> spreading the gospel of one framework is really just
> propaganda and marketing instead of insight. Maybe he
> strives to be Rails' Paul Graham...
>
It is funny because I think Ruby on Rails marketing has made both Java and Python folks feel a bit like Java marketing in the mid-90s made C++ people feel--like their language was being misrepresented by the marketing hype of a wildly successful upstart. I do see Rails as being marketed, and marketed well, but I also have found the marketing message to be quite honest. Rails proponents have drummed one message repeatedly: Rails helps you build web apps fast. And it does. They also point out that Ruby is very fun to program in. And it is. That's the marketing, yes, but on those points I agree with the marketing message. They tend to not talk about scalability until asked, but then they do have an answer. I'm very nervous about the scalability with Rails, but for many applications, "Mom and Pop" as you call them, I expect Rails will scale well enough.

Nevertheless, that single message that Rails helps you build web apps fast has worked very well at marketing Rails. But there's also an anti-Java message in the marketing too. They talk about how much more verbose and less elegant Java is than Ruby, and these are valid observations. But the marketing aspect is that you don't hear mention much of the tradeoffs.

For example, in Java you have primitive and wrapper types. In Ruby, if I understand it correctly, you just have what would equate to wrapper types. Numbers are objects. (I'm not sure of this in Ruby, so please correct me if I'm wrong.) This bifurcation between primitive and wrapper types in java adds complexity. You might not think the primitive/wrapper difference such a big deal, but I once gave a Java class to a group who had previously programmed in languages like Visual Basic and COBOL, and they were being retrained to program with Java servlets. This class really got hung up on this primitive/wrapper type thing. They couldn't understand why you needed two kinds of integer. I think half the class still didn't really feel they understood it after 15 or 20 minutes of talking about it.

The reason Java has that bit of complexity is for performance. Here's what Gosling said about it in an old interview:


Bill Venners: Why are there primitive types in Java? Why wasn't everything just an object?

James Gosling: Totally an efficiency thing. There are all kinds of people who have built systems where ints and that are all objects. There are a variety of ways to do that, and all of them have some pretty serious problems. Some of them are just slow, because they allocate memory for everything. Some of them try to do objects where sometimes they are objects, sometimes they are not (which is what the standard LISP system did), and then things get really weird. It kind of works, but it's strange.

Just making it such that there are primitive and objects, and they're just different. You solve a whole lot of problems.


And:


James Gosling: That's one of the reasons that primitives are not objects, because it is so nice to be able to just replicate them. When you pass an integer to a method, you don't have to pass the pointer to that integer. You can just replicate that integer and push it on the stack. So, it's a different integer. The same value, but a different integer and you can't actually tell. And if you look at a complex number class in C++ versus complex numbers in Fortran. In Fortran, they do all kinds of goofy things allocating complex numbers to registers, which really doesn't work in C++. And that mostly has to do with the fact that in C++, they are still objects and they have an identity. It's this whole platonic thing about identity. The nit that causes problems with optimizers and immutable objects is that as soon as you have a notion of identity that is independent of the value, then various things get really hard.


From:

http://www.artima.com/intv/gosling313.html

Ruby's design center is more aimed at the development experience than runtime efficiency. Here's what Matz, the creator of Ruby, had to say about it:


Bill Venners: In an article, you wrote, "Ruby's primary focus is productivity." How does Ruby help productivity, and what about efficiency and robustness? Productivity, efficiency, and robustness are all good things. How do you trade those off in Ruby?

Yukihiro Matsumoto: In my point of view, efficiency and productivity are the same thing, because we focus on programming efficiency, not runtime efficiency. I don't care about runtime efficiency. The computer goes faster and faster every year, so I don't really care about performance. Actually, I care about performance when I'm implementing the Ruby interpreter, but not when I'm designing Ruby. The implementer should care about performance, but the designer shouldn't. If you care about performance, you will focus on machines in design instead of on humans. So you shouldn't focus on performance in design.


From:

http://www.artima.com/intv/tuesday3.html

Ruby feels easier to learn and use than Java. Java programs can go much faster at runtime than Ruby programs. These are not accidents. It's how the languages were designed.

Rails marketing hasn't talked much about these tradeoffs, and to me that's the hype part of the marketing. Matz himself had no problem talking about where he felt Ruby was a good fit. Here's something from farther down in the interview at the URL I gave previously:


Bill Venners: One of the arguments made by static typers in the static versus dynamic typing debate is that static compile-time type checking helps programmers make robust systems. What is Ruby's attitude about robustness?

Yukihiro Matsumoto: The Ruby language itself doesn't care about robustness. Actually, the implementation of the interpreter, which is written in C, should be robust. No Ruby code should crash the interpreter. So I try to make the interpreter robust, but the language itself in its design does not care about robustness for two reasons. First, you need to test the system anyway to be robust. So we encourage unit testing using a testing framework to help achieve robust systems. The second reason is that programs written in dynamic languages are very easy to run and check. So for day-to-day programs that aren't not as serious as enterprise systems, you don't have to be as robust. It's not worth the cost of declaring types, for example. And because there are so many dynamic checks in dynamic languages, in most cases something very terrible usually does not happen. For example, Ruby checks array boundaries, so you don't have buffer overwrites. Ruby doesn't provide direct address manipulations, so you can't crash the stack space. Therefore in Ruby, I want to enable programmers to get a program ready to test in a short time by making programmers productive.


> Java is nowhere near threatened. Any high-level language
> that features duck-typing cannot replace Java, it simply
> wont. It will generally be slower, and it wont scale to
> large projects.
>
> As someone who has done web development since '99 or so,
> I've moved *to* Java from scripting languages. There are
> so many reasons why, but the list is almost identical to
> the scripting language benefits.
>
> To everything simply add "is a major convenience for small
> and expirable projects but becomes a major hassle when the
> code base is large, or the team has changed over time"
>
> 1. dynamic typing
> 2. speed sacrifices for code convenience
> 3. conventions over configuration
>
> It's simply true, and experience has taught me that lesson
> many many times.
>
I'd like on Artima to try and help people understand what the real tradeoffs are, so they can make wise decisions about which tool to apply to which problems. As part of that effort, I'd like to explore what scalability problems dynamic languages actually have that people haven't been able to overcome. Because even if I have to buy twice as many servers, that still could be cheaper than paying for twice as many developers. Maybe, I don't know, because I've never used a dynamic language to do anything besides relatively simple scripts.

Could you share some of the real-world problems you encounted when trying to scale something written in a dynamic language, and why you couldn't overcome it with techiques like clustering?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Java Futures Panel at TSS Symposium Posted: Mar 31, 2006 11:03 AM
Reply to this message Reply
"For example, in Java you have primitive and wrapper types... The reason Java has that bit of complexity is for performance."

Hmmmm.

"Q: C# ...What do you think is the best feature of it...

A: To me it would probably be a geeky thing like the unified type system, the fact that you can start out looking at the language, you can just go 'Everything in the language is an object' and then later on you can sort of learn about the finer distinctions, about value types versus reference types, but there's this conceptual simplification that you can say 'Everything in here is an object', so in that sense it's a true object oriented programming language."

34:25 Life and Times of Anders Hejlsberg
http://channel9.msdn.com/ShowPost.aspx?PostID=159952

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Java Futures Panel at TSS Symposium Posted: Mar 31, 2006 11:39 AM
Reply to this message Reply
As part of that effort, I'd like to explore what scalability problems dynamic languages actually have that people haven't been able to overcome.

I'd like to hear about something more specific than "dynamic languages" - the devil is in the details - see "The adventures of scaling" parts 1,2&3
http://poocs.net/articles/2006/03/27/the-adventures-of-scaling-stage-3

Bill Venners

Posts: 2251
Nickname: bv
Registered: Jan, 2002

Re: Java Futures Panel at TSS Symposium Posted: Mar 31, 2006 3:58 PM
Reply to this message Reply
> "For example, in Java you have primitive and wrapper
> types... The reason Java has that bit of complexity is for
> performance."

>
> Hmmmm.
>
> "Q: C# ...What do you think is the best feature of
> it...
>
> A: To me it would probably be a geeky thing like the
> e unified type system
, the fact that you can start out
> looking at the language, you can just go 'Everything in
> the language is an object' and then later on you can sort
> of learn about the finer distinctions, about value types
> versus reference types, but there's this conceptual
> simplification that you can say 'Everything in here is an
> object', so in that sense it's a true object oriented
> programming language."
>
I think the C# design is very nice, better than Java, because it has the performance benefits of primitive type without the conceptual bifurcation, and you can define your own value types too. There's still the notion of boxing and unboxing, which means that eventually programmers will likely have to understand the two worlds, but at least in C# the boxing and unboxing was done automatically from the beginning. In Java it came in in 1.5, I think.

My understanding of Python and Ruby, though, is that all numbers are objects on the heap. If that's true, then it is still conceptually simpler than C#, but doesn't perform as well. Anders talked about that here:

http://www.artima.com/intv/choices3.html

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Java Futures Panel at TSS Symposium Posted: Mar 31, 2006 6:05 PM
Reply to this message Reply
My understanding of Python and Ruby, though, is that all numbers are objects on the heap. If that's true, then it is still conceptually simpler than C#, but doesn't perform as well.

First, let's be more abstract, if we don't care about resource-use or performance then we also don't need to care about C# boxing. Now we've got that out of the way, let's take another look at the difference between Lisp Smalltalk Python Ruby etc integers and C# ints.

The real conceptual simplification is that we have an integer type with automatic coercion between limited-range small integer and large integer representations. Numbers don't wrap around to negative values when they exceed long.MAX_VALUE (Java), nor raise an OverflowException (C#), they just coerce to a large integer representation.

(Of course, it's sometimes nice to have specific 32/64 bit representations as well as limited-range small integers.)

Ivan Lazarte

Posts: 91
Nickname: ilazarte
Registered: Mar, 2006

Re: Java Futures Panel at TSS Symposium Posted: Apr 3, 2006 5:21 AM
Reply to this message Reply
"Could you share some of the real-world problems you encounted when trying to scale something written in a dynamic language, and why you couldn't overcome it with techiques like clustering? "

Our scaling issues encompassed performance as well, but maintainability was the dominant cost by far. At worst, the interplay between the too magnified the problem. For instance, developer A creates a custom caching system to solve a performance problem that occurs intermittently. Developer B is tasked with fixing a host of bugs a while after Developer A has left the job. Developer B never liked A's implementation anyway; how about a re-write? The development cost promises to be low...

Long story short, the system became a mess through small concessions, one day at a time. Maybe the code is stiff with legacy dependencies, or is too slow to build on top off, or features 6 versions of quite nearly the same thing, somewhere, the language always seemed to be the culprit. When I ask myself what was the cause, I see these as the answers

1. A language that promotes freedom over rigidity.
2. A language that features poor performance.

In the end, I don't count adding app servers as scalability. That is are one factor, and really an over-simplification of the problem.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Java Futures Panel at TSS Symposium Posted: Apr 3, 2006 12:16 PM
Reply to this message Reply
"When I ask myself what was the cause, I see these as the answers
1. A language that promotes freedom over rigidity.
2. A language that features poor performance.


I'm unclear why you see those as the answers.

"developer A creates a custom caching system... Developer B is tasked with fixing a host of bugs... never liked A's implementation anyway; how about a re-write..."

afaict these are failures in the development process - I've seen similar incidents on projects based on very different programming languages.

Flat View: This topic has 9 replies on 1 page
Topic: Java Futures Panel at TSS Symposium Previous Topic   Next Topic Topic: Legacy Data and Agile Development


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us