The Artima Developer Community
Sponsored Link

Weblogs Forum
Seeking the Joy in Java

53 replies on 4 pages. Most recent reply: Sep 5, 2007 7:33 AM by Mayuresh Kathe

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 53 replies on 4 pages [ « | 1 2 3 4 | » ]
Bill Venners

Posts: 2244
Nickname: bv
Registered: Jan, 2002

Re: Seeking the Joy in Java Posted: Aug 23, 2006 1:54 PM
Reply to this message Reply
Advertisement
> > Do you believe that another language for the JVM could
> > someday become as mainstream as Java? Do you know of
> any
> > language that might be capable of doing it?
>
> It seems to me that what a lot of people seem to miss is
> that the reason Java is so popular is that it doesn't
> contain all the complex features that advanced developers
> love yes I;m talking about Scala.) It's a language that
> an advanced developer can be fairly productive with while
> a average developer can still make sense of it.
>
In my blog post I was attempting to use Scala as an example and not claim it is the next great thing. I have only read its docs, and have never programed in it, so I have no opinion. But I can say that one thing that attracts me to Scala is not what it adds that Java doesn't have, but what it takes away. I don't appear to need to type as many semicolons and curly braces. I don't need to type as many type specifiers, as it attempts to do type inference where possible. It is hard for me to read, as a novice, so it doesn't seem as naturally intuitive as, say, Python. As far as the complex new features, that would be all the functional programming stuff, I'm interested intellectually in getting into that stuff because it is new for me.


> The
> syntax used to be very small. This made Java code easy to
> understand. You couldn't find Java code where you'd look
> at it and not understand what it was doing in terms of the
> syntax. The complexity explosion of 1.5 along with the
> sloppy way a lot of the features were shoe-horned (I
> think) is the beginning of the end for Java. Perhaps a
> cleanup and a true Java 2.o would fix it. I don't know.
>
I remember feeling a big chagrined by added complexity back in whatever release they added inner classes. Java programs got alot more verbose and harder to read right there. The addition of generics made Java code even harder to read. But I can still read it, and I'm glad those features are in there.

> But Scala? I think it's really cool but there's no way
> it's going to become mainstream. Sorry. It's a language
> for language designers not Joe Shmoe down the cube hall.
> You should see the looks I get when I mention implicit
> t parameters. Some poeple are horrified, others are
> completely lost. No one has said that they liked the idea.

Well, again, I'm not trying to push Scala, but use it as an example. Scala was the language that made me realize that perhaps a different language on the JVM could help us past the natural law problem. Because non-Java JVM languages need not be source compatible with Java itself, they have a lot more freedom to be elegant.

Bill Venners

Posts: 2244
Nickname: bv
Registered: Jan, 2002

Re: Seeking the Joy in Java Posted: Aug 23, 2006 2:25 PM
Reply to this message Reply
Hi Dick,

> I'd like to first say that there seems to be three schools
> of thought regarding the Java platform:
>
> (1) Don't touch Java. It's fine the way it is. "We"
> don't need anything else. Alternative languages on the
> JVM just cause confusion. And so on...
>
> (2) Extend Java to keep up with the features in other
> languages, probably most notably the features that will be
> coming in C# 3.0, as that is the biggest competition right
> now.
>
> (3) Stop "kludging" new features into Java and come up
> with a new JVM language that all the "cool kids" can
> enjoy, while remaining class compatibility.
>
> I probably fall into camp 3 more than any of the other
> ones, even though I don't have a problem with adding new
> features (such as closures), as long as its a well thought
> out process. Syntax is important.
>
I don't agree with 1. I think we should still continue to improve Java. I kind of agree with 2. It is important to have some of the same features to compete with C#, but really, whatever gets put into Java should really be right for Java, not just to get another item on a feature list. As far as 3 goes, I think you don't have to stop "kludging" new features into Java to also have a new JVM language.

In short, I think we should continue to improve Java, but I also would like to see a new language on the JVM become more mainstream.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Seeking the Joy in Java Posted: Aug 23, 2006 2:25 PM
Reply to this message Reply
> Well, again, I'm not trying to push Scala, but use it as
> an example. Scala was the language that made me realize
> that perhaps a different language on the JVM could help us
> past the natural law problem. Because non-Java JVM
> languages need not be source compatible with Java itself,
> they have a lot more freedom to be elegant.

I don't want to bang on Scala because do think it's a cool language. I guess my point is that adding sophisticated features that 'guild-member' developers love doesn't make a language popular in business. I would say the most successful language in business ever is COBOL.

I'd love to have a lot of these features too. It's just that that isn't what managers want. They don't want a language where every developer needs to be a superstar to program in it. There aren't enough superstars available and especially not at an affordable price.

I think Java strikes a pretty good balance of being accesible to the novice while allowing the expert to do more sophisticated things in a way that the novice can learn from easily. I think that's really the triumph of Java. Does it slow down the experts? Yes. If you have a full team of expert developers, it may not be the language for you. But most teams have a 1-to-2 or 1-to-3 ratio of experts to non-experts.

Bill Venners

Posts: 2244
Nickname: bv
Registered: Jan, 2002

Re: Seeking the Joy in Java Posted: Aug 23, 2006 2:40 PM
Reply to this message Reply
Hi Ivan,

> Scripting works great for smaller code bases, for
> expirable code bases, for the necessary glue that comes
> between various components of technology, but not as a
> main business language. The code will always hit the
> barrier of scale, whether it's in maintainability, or
> performance, or both.
>
This is my belief too. I haven't ever attempted to build a large system with multiple programmers with a scripting language, but my superstition is that static languages are more suited to that kind of scale.

> "Joy" in this new generation of Blog Driven Developers
> comes with the bliss of ignorance. Like I've said many
> times before; this generation will just have to relearn
> the lessons of the past.
>
I tried to emphasize in my blog that the "joy" people seem to feel when programming in Ruby or Python, or Smalltalk for that matter, seems to me primarily a satisfaction with how productive they are in those languages. So joy implies productivity. What I'd like is to have a more productive language than Java, that still lets me access the amazing fleet of Java APIs and speed-optimized JVMs.

A primary way that dynamic languages achieve their productivity boost is that dynamic typing provides a lot of freedom that can speed you up. Metaprogramming becomes easy. In Ruby, for example, it is quite easy to add a method to an existing object. But you also just have less finger-typing, and that does make a difference.

I don't want to use a dynamic language as my Java alternative for the JVM, though, because, well, freedom isn't free. When you throw out static typing, you throw out something I find quite valuable in the kinds of systems I want to run on the JVM. One thing I liked about Scala, for example, was that it is statically typed, but yet it does type inference where possible to minimize my finger-typing and code verbosity. Regardless of Scala's future, it did illustrate to me that it is possible to have a new language for the JVM that offers pretty much what Java offers, and more, but be more succinct, and be more intellectually cohesive. It is possible.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Seeking the Joy in Java Posted: Aug 23, 2006 3:14 PM
Reply to this message Reply
> Also, I think you need to distinguish between "shortcuts"
> and language features that are paradigm shifts. Java
> generics introduces a shortcut

I'm not sure how generics are a shortcut. They take a good bit of up front effort. I also disagree with this in general because generics make certain things feasible in Java when they were not before and (when used properly) can really enhance the clarity of code.

A really simple example is an indirect reference to an Object. A Pointer class, lets call it. Here's what it would look like pre-generics:
public class Pointer
{
    Object referent;
}


I think most java developers would look at that and think, "that's a great way to create some incomprehensible code." But with Generics you can do this:

class Pointer<E>
{
    E referent;
}


And there's really nothing wrong with that IMO. It's a hell of a lot better than an array of length one.

Maybe generics doesn't technically allow you to do anything you couldn't do before but it makes a lot of things feasible and could make a lot of code much more resuable.

There is a danger though. I've seen people writing some really stupid crazy code to get it to compile without casts and without warnings.

> Python list comprehensions
> are a different and clearer way of thinking about the
> problem. Ruby & Smalltalk continuations are a paradigm
> shift.

I thought Python also has continuations. Is that not the case?

Bill Venners

Posts: 2244
Nickname: bv
Registered: Jan, 2002

Re: Seeking the Joy in Java Posted: Aug 23, 2006 3:18 PM
Reply to this message Reply
> Bill Joy was right, it's worth the extra time to do things
> well rather than rush them out because it seems expedient
> at the time. And the argument that Java is successful
> weakens over time, as the initial flaws are added to and
> you end up with complexity accretion increasing over
> time.
>
That problem of flaws adding up over time is the natural law problem I wrote about. It is true of any language. The more you maintain backwards compatibility with each release, the more klunky the language becomes over time. As far as the state of Java when it was released, I think Naughton and Gosling were right. There was a tiny market window and they needed to hit it. Applets were to Java what Rails has been lately to Ruby, something that generated a lot of hype and excitement, which propelled the langauge ahead of alternatives. If they had waited to release until they had added generics, they surely would have missed that window.

> But the inability to fix the language, and the staunch
> declarations that it was all done right in the first place
> so it doesn't need fixing, is what will eventually
> cause Java to diminish. Not disappear -- C++ hasn't
> disappeared either, but both languages will move towards
> niches: C++ is a more powerful C, and Java has captured a
> great deal of knowledge in its libraries.
>
What "staunch declarations that it was all done right in the first place?" Doesn't all the features that have been added to the Java language over the years contradict that? Inner classes, enums, auto-boxing, annotations, generics, and now the closures proposal--all these features seem to indicate that someone somewhere thinks that Java wasn't "all done right in the first place."

> Whatever the justification, saying that you can't fix a
> language because of backwards compatibility is effectively
> the same as saying that you can know all the requirements
> for a project up front.
>
I think it is the same as saying that although it is frustrating to pay the cost of added complexity in the programmer's face, this is the tradeoff we have to pay to minimize the costs of breaking compatibility. Breaking compatibility is very costly to the existing users, and I agree with how Java has tried very very hard to avoid it. It has done it some times. Just last week, for example, I needed to compile some JSPs for the first time on Artima's new server. These were Jive Software's admin JSPs from an old Jive release that I'm still using, and in the version they were written enum wasn't a Java keyword. Now it is, and it turns out they used enum as a variable name in several places (a variable of type Enumeration). So I spent time to fix this problem. The incompatible afterthought of elevating enum to a keyword in Java 1.5 cost me money just last week.

> Gosling and Naughton thought that
> Java would never need such esoteric features as
> parameterized types (what generics should have been), so
> they didn't have to be put in at the beginning. If they
> had, C#'s generics mechanism would have paled in
> comparison, but because they've had to be retrofitted, the
> so-called "generics" in Java are really just syntactic
> sugar for autocasting, and the really useful features of a
> true parameterized type mechanism are missing.
>
I don't think Gosling and Naughton thought Java would never need parameterized types, just that they didn't have time to put it in and still meet the market window opening up for applets. Also, I think it is better get something simple out the door that is usable, and get experience with it. Find out what features users really want before you add them.

> Now they're talking about adding closures, another feature
> that they were sure they didn't need when the language was
> originally being designed. Based on the generics
> experience, I shudder to imagine what new Frankenstein
> will come out of this effort. If it's anything like
> generics, it will end up being something that vaguely
> seems like a closure mechanism, but will be loudly
> declared to be closures. And perhaps enough people will be
> fooled by this (again) that it will get by (although I
> wonder about that, since there will be enough Ruby
> programmers who know what they really are to raise a
> ruckus about it).
>
Have you read the closures proposal? It is very short. It didn't remind me of Frankenstein, and what they suggested did indeed seem to be what I understand closures to be. Most significantly, variables in the enclosing scope seem to be available in the closure. I'm curious how they will implement this under the covers, but it was nice to see that inner classes get the same thing. Inner classes will be able to access variables in the enclosing scope, even if they are not final.

> If they're not going to fix the language, I have to agree
> with you that a new JVM language should be created rather
> than these exhausting attempts to add such fundamental
> features while retaining backwards compatibility.
>
These two are not mutually exclusive, and I didn't intend to imply that the are. I believe we should continue to improve Java, because I and many many others will continue to use it. My point is that Java has come to a level of maturity that another language for the JVM could take the lessons learned from Java over the years, and provide a non-source compatible alternative to Java that is still binary compatible with it. These two things (continuing to improve Java plus making a new language) can both happen at the same time.

It reminds me a bit of Python 3000. I saw Guido give his Python 3000 talk, and he pointed out that Python 3000 will not be source compatible with previous versions of Python. This allows him to clean up things that time has shown him were a mistake, or at least not as desireable as some alternative. But in the meantime, Python 2 will continue to be improved.

> One of the most powerful ideas that I've seen in both
> Python and Ruby is the willingness to fix things in the
> language even if it breaks backwards compatibility. Python
> has done it when fundamental problems were discovered, and
> has improved the language and kept it growing in good
> directions. Apparently Matz is really planning on removing
> many of the Perlisms in Ruby -- the aesthetics of those
> Perlisms are primarily what has given me a bad taste about
> the language, so I'm really impressed by this.
>
Yes, but you don't have huge investments in code that costs you money to fix when those breaking changes are made and you want to use the latest release. Besides, Guido told me in his interview that he tries very very hard to maintain compatibility in new versions of Python (Python 3000 is a notable exception), and Java has made breaking changes. Does it all the time. Assert was another. I complained about the assert keyword to James Gosling in one of my interviews with him, and he said it didn't break much code to elevate assert to keyword status. Only problem with that theory is that every JUnit test case at that point likely was using assert as a method. JUnit's assertTrue method used to be called assert, and had to be changed when Java made that breaking change.

Note to language designers: always reserve more keywords than you actually are using in release 1, especially keywords like assert or enum that you might someday conceivable add as features.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Seeking the Joy in Java Posted: Aug 23, 2006 3:28 PM
Reply to this message Reply
When developing highly complex applications, language alone may offer but small productivity improvement in a project. Instead, we spend most of our time interacting with APIs to address specific application tasks, such as connecting to external resources, or authenticating users.

I couldn't disagree more. Programming in terms of (low level, device oriented, solution domain) APIs is a symptom of programming in a low level language with poor facilities for abstraction. Programming languages with good facilities for abstraction allow one to program in terms of problem domain concepts.

Bruce Eckel

Posts: 868
Nickname: beckel
Registered: Jun, 2003

Re: Seeking the Joy in Java Posted: Aug 23, 2006 3:48 PM
Reply to this message Reply
> I thought Python also has continuations. Is that not the
> case?

In Python 2.5 the 'yield' keyword is extended to create behavior that appears to be continuation-like, but I haven't studied it in depth so I can't say for sure.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Seeking the Joy in Java Posted: Aug 23, 2006 3:55 PM
Reply to this message Reply
> > I thought Python also has continuations. Is that not
> the
> > case?
>
> In Python 2.5 the 'yield' keyword is extended to create
> behavior that appears to be continuation-like, but I
> haven't studied it in depth so I can't say for sure.

I read an introductory book and I seem to recall it claiming that it has continuations.

yield in Python seems (to me) to make a method behave like an iterator. It almost seems like an inverted functional style of doing things.

Perhaps this is different from what is in Ruby, but it seems to me that the Python yield operation is a nice convience more than a paradigm shift. It doesn't appear to provide anything more than what you can do with a closure. Is there something more to it that I am not getting?

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Seeking the Joy in Java Posted: Aug 23, 2006 5:18 PM
Reply to this message Reply
> I couldn't disagree more. Programming in terms of (low
> level, device oriented, solution domain) APIs is a symptom
> of programming in a low level language with poor
> facilities for abstraction. Programming languages with
> good facilities for abstraction allow one to program in
> terms of problem domain concepts.

What do you mean by the difference between "solution domain" and "problem domain?"

In many Java applications, you would try to use a standard API for things that have been standardized, rather then re-inventing the wheel. For instance, to authenticate users, you'd use JAAS, to connect to a database, you'd use JDBC, and to handle HTTP requests, you'd use the servlet API.

Increasingly, more and more problem domains (or "solution domains"?) are being standardized, hence the greater reliance on APIs. I wouldn't view that as a minus, only a maturity of the Java landscape. But that also means that key functionalities are exposed via those APIs, and that's why I was mentioning that the quality of those APIs have a great impact on developer productivity, perhaps more than the Java language does.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Seeking the Joy in Java Posted: Aug 23, 2006 7:56 PM
Reply to this message Reply
> As another example, consider the camp that says that all
> classes should have interfaces, and all instances should
> be generated by factories. I think the complexity of the
> language encourages complexity in design and
> implementation.

The problem is that you're defining one model using the nomenclature of another model.

I would suggest that all classes are interfaces, and concrete classes are simply interfaces with implementation mixed in ;-)

As for factories, they only exist because Java doesn't use a virtual "new" (think "virtual methods", but applied to instantiation).

Peace,

Cameron Purdy
http://www.tangosol.com/

Bill Venners

Posts: 2244
Nickname: bv
Registered: Jan, 2002

Re: Seeking the Joy in Java Posted: Aug 23, 2006 8:24 PM
Reply to this message Reply
> > I also think there is a psychological mindset now in
> the
> > Java community that using simple tools for simple
> things
> > is passe, and that even for simple things you need to
> use
> > some kind of a framework.
>
> As another example, consider the camp that says that all
> classes should have interfaces, and all instances should
> be generated by factories. I think the complexity of the
> language encourages complexity in design and
> implementation.
>
I'm not sure I've seen either of these mindsets, but I do think the language affects the mindest of the programmer. There are things I feel perfectly comfortable doing in Python that I feel guilty doing in Java. I wrote about that here:

http://www.artima.com/weblogs/viewpost.jsp?thread=92979

As far as the camp that thinks all classes should have interfaces and all instances should be generated by factories, I think that's just an unfortunate design philosophy. I don't think you can blame the Java language for that one.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Seeking the Joy in Java Posted: Aug 24, 2006 5:57 AM
Reply to this message Reply
What do you mean by the difference between "solution domain" and "problem domain?"

I'm using the terms problem domain and solution domain as they are commonly used in (domain, product-line, software) engineering and as I'm familiar with those terms from books such as Generative Programming by Czarnecki and Eisenecker (they actually use "space" rather than "domain") and Multi-Paradigm Design for C++ by Coplien as well as articles dealing with the various aspects and techniques of the field.

The difference between a problem domain and a solution domain is largely context dependent. An example of a problem would be to parse a language specified by a BNF grammar. An example of a solution to the problem would be a recursive descent parser for the language. A problem domain is roughly a set of problems bounded in some meaningful way. An example of a problem domain would be parsing an arbitrary language defined by a BNF grammar. (This is an example of a rather specialized and "technical" problem domain for which good solutions are well known.) A solution domain (or space) consists of a set of implementation components with their possible combinations. An example of a solution domain would be recursive descent parsing using the Java language.

I hope this clarifies things for you.

Increasingly, more and more problem domains (or "solution domains"?) are being standardized, hence the greater reliance on APIs. I wouldn't view that as a minus, only a maturity of the Java landscape. But that also means that key functionalities are exposed via those APIs, and that's why I was mentioning that the quality of those APIs have a great impact on developer productivity, perhaps more than the Java language does.

Actually, the Java APIs standardize largely solution domain things. (Keep in mind that the terms (problem/solution domain) are context dependent. If you define the problem as "how to send strings containing SQL to the SQL database", then JDBC could be considered a (problem-oriented) domain specific embedded language for that, but that would be a silly problem space for an application developer.) Let me quote your own words:

"key functionalities are exposed via those APIs"

The point is that the APIs expose "functionality" provided by the underlying implementation technologies. An API in the sense that you are using mainly specifies an abstract machine, but machine nonetheless, that you program in specific ways to solve particular problems. The difference, when compared to a domain specific language, is that there is no simple mapping from the structure of the problem to a structure of a solution using a typical Java API. The best examples of domain specific (embedded or otherwise) languages are such that you solve problems in them largely by translitterating the (formalized) problem definition to the syntax of the DS[E]L. In other words, using a DS[E]L you write a specification of the problem in a declarative manner specifying little or no solution domain or implementation details. The structure of a program using a DS[E]L reflects the structure of the problem.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Seeking the Joy in Java Posted: Aug 24, 2006 6:33 AM
Reply to this message Reply
Personally, I don't use all the new features of Java. I am against feature creep. But every little thing helps, and if programming becomes easier with closures, then why not?

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Seeking the Joy in Java Posted: Aug 24, 2006 6:58 AM
Reply to this message Reply
> But Scala? I think it's really cool but there's no way
> it's going to become mainstream. Sorry. It's a language
> for language designers not Joe Shmoe down the cube hall.
> You should see the looks I get when I mention implicit
> t parameters. Some poeple are horrified, others are
> completely lost. No one has said that they liked the idea.

Well, I like the idea and some people I know do also ;-) Seriously, Scala is intended to be wide-spectrum language, in the sense that it gives great power and freedom to the library designer and at the same time makes programming easy for Joe average programmer. In fact, the hope is that we can grow a community of experts that will design killer libraries which are attractive for casual users (much more attractive than what could be done in Java, for instance).

Actors instead of threads are one example. I know of several other examples in development, such as a nice re-packaging of the Java Swing libraries that makes them much easier to use, specifically for non-experts.

The problem is that the two levels (for experts, respectively non-experts) get confused easily. Take implicit parameters as an example. They are the very thing that lets us address the problem that Bill mentions in his blog: namely that it might be too late to add closures to Java because Collection does not support higher-order methods auch as each. If you were programming in Scala, you could write a new class as follows:

class CoolScalaCollection[A] extends java.util.Collection[A] {
def each(operation: A => unit): unit
}

So far, so good. But the problem is that there is lots of Java code out there which produces a plain Collection, without the each operation. Not cool.

Now, with the following implicit definition you can magically upgrade *all* collections to support each:

implicit def javaCollectionsAreAlsoCool[A] (c: java.util.Collection[A]) = new CoolScalaCollection [A] {
def each(operation: A => unit) = ...
}

The trick is that the implicit conversion function gets applied whenever each is invoked on a plain old collection. Implicit parameters go one step further than this; they let you parameterize code with implicit things. This is very similar to the `contract' proposals for the next C++ standard.

There are many examples like this in the Scala libraries. So I think implicits are very useful to make great new libraries that can interact with old ones.

However, I agree with you that one should probably keep implicits away from novice programmers (or at least de-emphasize them); it's a feature that's easily abused.

In summary, yes, Scala is a language for language designers but in my opinion language design and library design is the same thing. Great APIs are languages in their own right. Scala tries very hard to support people trying to build them.

Cheers

-- Martin

Flat View: This topic has 53 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Seeking the Joy in Java Previous Topic   Next Topic Topic: Python Sprint @ Google


Sponsored Links



Google
  Web Artima.com   

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