Weblogs Forum - Seeking the Joy in Java

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Seeking the Joy in Java

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

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 53 replies on 4 pages [ « | 1 2 3 4 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Seeking the Joy in Java

Posted: Aug 24, 2006 6:56 AM

Martin, I guess what I am trying to say is that I think that Scala could be a great language but that the complexity is going to be very difficult for a lot of developers to swallow.

The major issue that I see is a lack of transparency. In your example, I can add an each method to Collections. Great for me because I understand (basically) how that works. But a developer that hasn't studied the documentation closely will be scratching his or her head trying to figure out how you can call a method on a collection when it's not part of the collection interface. It's not really something you can figure out just by looking at the code. It's voodoo to anyone who hasn't fully grasped the implicit feature.

There are very few things like this in Java. That's part of why it's been successful in my estimation. I don't have to develop in Java everyday or remember a lot of obscure rules to figure out what a snippet of code does.

Perhaps I am being too pessimistic but if you want to make this more palletable, you need to make it more understood, an not hide it in the shadows. Developers don't like surprises.

The other thing I think you can address right now it the documentation. One of the things I found really frustrating was that the Ord class described in the tutorial does not exist. Once I found the Ordered class, it didn't conform to the API. This might seem trivial but it really dampened my enthusiasm for learning the language.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Seeking the Joy in Java

Posted: Aug 24, 2006 8:27 AM

> Martin, I guess what I am trying to say is that I think
> that Scala could be a great language but that the
> complexity is going to be very difficult for a lot of
> developers to swallow.
>
> The major issue that I see is a lack of transparency. In
> your example, I can add an each method to Collections.
> Great for me because I understand (basically) how that
> t works. But a developer that hasn't studied the
> documentation closely will be scratching his or her head
> trying to figure out how you can call a method on a
> collection when it's not part of the collection interface.
> It's not really something you can figure out just by
> y looking at the code. It's voodoo to anyone who hasn't
> fully grasped the implicit feature.

Good points. But what are the alternatives? I can think of three:

1. Forget about each in collections.
2. Start from scratch, and forget about code that creates old-style collections.
3. Require that users write lots of wrapper code that transforms old style into new style collections.

I think (1.) is giving up, and (2.) is impractical. Remains (3.), creating wrappers. That's what's often done in practice, but it's very cumbersome. It gives you the kind of verbosity that often hides rather than clarifies meaning. So one way to regard implicits is that they are automatically generated wrappers.

With the right tool support, this could be practical also for inexperenced users. For instance, we could have a mode in the IDE which shows automatically generated implicits in the source. That would remove the voodoo and put implicits on the same level as, say, refactorings. I'll see whether we can that build the Scala Eclipse plugin.

> The other thing I think you can address right now it the
> documentation. One of the things I found really
> frustrating was that the Ord class described in the
> tutorial does not exist.

The tutorial was out of date with the API in that respect. Thanks for pointing this out!

-- Martin

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Seeking the Joy in Java

Posted: Aug 24, 2006 8:48 AM

> Good points. But what are the alternatives? I can think of
> three:
>
> 1. Forget about each in collections.
> 2. Start from scratch, and forget about code that creates
> old-style collections.
> 3. Require that users write lots of wrapper code that
> transforms old style into new style collections.
>
> I think (1.) is giving up, and (2.) is impractical.
> Remains (3.), creating wrappers. That's what's often done
> in practice, but it's very cumbersome. It gives you the
> kind of verbosity that often hides rather than clarifies
> meaning. So one way to regard implicits is that they are
> automatically generated wrappers.

I like this idea of implicits and I am warming up to them more and more. They seem to also allow a 'bolt-on' approach to OO. For example, I'm a big proponent of mimimalist interfaces in Java because they are much easier to implement (which is why we should be creating interfaces: so people can implement them) but the obvious trade-off is that they may take more effort to use.

The implicit feature (I think) solves this. It allows me to create my minimalist interface and provide bolt-ons for the convienience features. Even better, (I think) it allows anyone to provide sets of convienience methods for specific needs without procedural style helper classes.

> With the right tool support, this could be practical also
> for inexperenced users. For instance, we could have a mode
> in the IDE which shows automatically generated implicits
> in the source. That would remove the voodoo and put
> implicits on the same level as, say, refactorings. I'll
> see whether we can that build the Scala Eclipse plugin.

When you say 'automatically generated' you mean the additions to a class provided by the implicit wrapper, right? Implicit objects are not being created automatically or anything are they?

> > The other thing I think you can address right now it
> the
> > documentation. One of the things I found really
> > frustrating was that the Ord class described in the
> > tutorial does not exist.
>
> The tutorial was out of date with the API in that respect.
> Thanks for pointing this out!

I also seem to recall that the variance specified in the API was not what was actually in the definition of Ordered but this could be a misunderstanding on my part.

I guess the real issue with implicits isn't the feature but making the value well known and understood. I don't think keeping features from people that we don't trust is a good solution.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Seeking the Joy in Java

Posted: Aug 24, 2006 9:04 AM

> 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?

I suspect you're thinking about the "old" python 2.4 yield, which only produces a value. Any function with a yield became a generator.

The new Python 2.5 yield not only produces a value when the function suspends, but can accept a value when some outside agency asks the function to resume. That way there can be two-way communication between coroutines (which is what the new yield is designed to support: not continuations per se, but corountines).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Seeking the Joy in Java

Posted: Aug 24, 2006 9:21 AM

> The new Python 2.5 yield not only produces a value when
> the function suspends, but can accept a value when some
> outside agency asks the function to resume. That way there
> can be two-way communication between coroutines (which is
> what the new yield is designed to support: not
> continuations per se, but corountines).

OK, thanks for the clarification. What would be the distinction between this and a continuation? If you want to just point me to a reference that will be plenty helpful. Thanks.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Seeking the Joy in Java

Posted: Aug 24, 2006 12:43 PM

> OK, thanks for the clarification. What would be the
> distinction between this and a continuation? If you want
> to just point me to a reference that will be plenty
> helpful. Thanks.

Here:
http://en.wikipedia.org/wiki/Continuation
and here:
http://www.intertwingly.net/blog/2005/04/13/Continuations-for-Curmudgeons

Although it seems to me that the effect of the new 2.5 version of yield *does* store state, so it might be possible to use it as a continuation. Or maybe it doesn't store enough state. I'm sure the issue will resolve itself over time.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Seeking the Joy in Java

Posted: Aug 24, 2006 4:55 PM

Or we could all go back to programming in Smalltalk, which really, what Java is trying to become. What's missing? Decent dynamic invocation, message sending (vs function calling) semantics, resumable exceptions.

At some point, you have to realize that bolting wings on your car is not going to fly.

I'm sticking with the balloon.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Seeking the Joy in Java

Posted: Aug 24, 2006 5:43 PM

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.

I don't think even the most hardcore ruby or pythonista would allocate "throwing out" manifest typing. Its useful, to a point. But it really ought to be optional. Because sometimes its inappropriate and a pain to work around.

OTOH, I think Java is a rush job, got lots wrong, borrowed too much from another failed experiement (C++) and I'd like to think we've learned that there are some key postulates that don't hold up. I don't see any reason to fix it. Best leave it as is and build something new that can interoperate. Required manifest typing is a mistake. Function calling vs message sending is a mistake. Lack of closures was a mistake. The choice of looping structures is pure cargo cultism. The syntax is a mistake. Checked exceptions is a mistake. It all adds up to overhead with no payout.

Junk it and move on.

FWIW, the garbage I'm reading about how "ruby probably won't scale to the level of Java because its too loosey goosey" is bollocks. Huge systems have been built in Smalltalk (a whole phone company was built on it) and Rails and they scale BETTER than rigid runtimes like Java because they are more flexible.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Seeking the Joy in Java

Posted: Aug 24, 2006 7:05 PM

> OTOH, I think Java is a rush job, got lots wrong, borrowed
> too much from another failed experiement (C++) and I'd
> like to think we've learned that there are some key
> postulates that don't hold up. I don't see any reason to
> fix it. Best leave it as is and build something new that
> can interoperate. Required manifest typing is a mistake.
> Function calling vs message sending is a mistake. Lack
> k of closures was a mistake. The choice of looping
> structures is pure cargo cultism. The syntax is a
> mistake. Checked exceptions is a mistake. It all adds up
> to overhead with no payout.
>
> Junk it and move on.
>
> FWIW, the garbage I'm reading about how "ruby probably
> won't scale to the level of Java because its too loosey
> goosey" is bollocks. Huge systems have been built in
> Smalltalk (a whole phone company was built on it) and
> Rails and they scale BETTER than rigid runtimes like Java
> because they are more flexible.
>
Oh, oh. Ye olde static versus dynamic typing debate seems to want to rise up again. Perhaps I should create a forum just for that debate. I've expressed my opinion in many other incarnations of this debate, that different jobs require different tools. For the kind of systems I want to run on the JVM, for those kinds of jobs, I really prefer static typing.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Seeking the Joy in Java

Posted: Aug 24, 2006 7:36 PM

[i[static versus dynamic typing debate seems to want to rise up again. Perhaps I should create a forum just for that debate. I've expressed my opinion in many other incarnations of this debate, that different jobs require different tools.[/i]

Uh, you conveniently opted to ignore my first statement. Manifest typing is occasionally valuable. So why not make it optional? Why must it be this or that? I'd like to have both. Sometimes its helpful, sometimes its a hindrance.

I like working ObjectiveC because IF I bother to type annotate a variable, then the compiler checks how I use it. But if I don't, it leaves me the hell alone without forcing me to sprinkle casts all through my code.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Seeking the Joy in Java

Posted: Aug 25, 2006 4:12 AM

> Uh, you conveniently opted to ignore my first statement.
> Manifest typing is occasionally valuable. So why not
> t make it optional? Why must it be this or that? I'd
> like to have both. Sometimes its helpful, sometimes its a
> hindrance.
>
> I like working ObjectiveC because IF I bother to type
> annotate a variable, then the compiler checks how I use
> it. But if I don't, it leaves me the hell alone without
> forcing me to sprinkle casts all through my code.
>
I didn't realize ObjectiveC let you do that. I'm curious how that works. If a variable is not given a type specifier, does it have a type? I.e., is type inferencing going on? Or do method invocations from that variable use the reflection approach? If the latter, I'm curious when you use one versus the other. You kind of have both tools available in the same language. How do you apply them in practice in a single app?

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Seeking the Joy in Java

Posted: Aug 25, 2006 11:21 AM

> If a variable is not given a type specifier, does it have a type?

Its based on C so C builtins follow all the usual rules, but object are either specific pointer types or id (object but I don't know what kind).

NSDictionary* dict = [NSDictionary new];... [dict foo]; // warning NSDictionary does not respond to foo

id dict = [NSDictionary new];....[dict foo]; // no warning

>is type inferencing going on?

No, its vanilla dynamic typing ala Smalltalk. If a message is sent (and this is message sends, not function calls like Java or C++) and the object does not respond to that selector, then forwardInvocation: aMessage is sent allowing you to handle the miss - such as in the case of a proxy. The default implementation of that calls doesNotUnderstandMessage: aMesssage which will raise an exception.

>Or do method invocations from that variable use the reflection approach?

Its message sends - not function invocations. See:
http://www.blackbagops.net/?p=70

>If the latter, I'm curious when you use one versus the other.

I seldom use id unless I'm doing something really dynamic using proxies or dynamic adaptors (you can adapt two objects with one smart proxy like this)

forwardInvocation: aMessage
{
if ([obj1 respondsTo: [aMessage selector]])
[aMessage invokeWithTarget: obj1];
else if ([obj2 respondsTo: [aMessage selector]])
[aMessage invokeWithTarget: obj2];
else [super forwardInvocation: aMessage];
}

Thats it, no replicating the entire protocol of each object and writing individual forwarding functions. After all, I have real work to do.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Seeking the Joy in Java

Posted: Aug 26, 2006 2:20 AM

> But a developer that hasn't studied the
> documentation closely will be scratching his or her head
> trying to figure out how you can call a method on a
> collection when it's not part of the collection interface.
In an IDE, you can ctrl+click on "each" and you'll see where it is defined. That way, you'll understand the feature at once.

I think C# has an easier syntax tough:
public static void each(this Collection, delgate d) {..}

This is the way that LINQ works:
mycollection.select(..).where(..)

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Seeking the Joy in Java

Posted: Aug 26, 2006 3:46 AM

> I think C# has an easier syntax tough:
> public static void each(this Collection, delgate d) {..}
>
> This is the way that LINQ works:
> mycollection.select(..).where(..)

Right. LINQ is another example for the need to extend existing classes. The advantage of implicits over LINQ's
method additions is that you can use them as automcatic conversions:


  val cc: CoolCollection = new java.util.HashMap

works, and would be augmented to:


  val cc: CoolCollection = javaCollectionsAreAlsoCool(new java.utilHashMap)

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Seeking the Joy in Java

Posted: Aug 26, 2006 4:28 AM

> The advantage of implicits over LINQ's
> method additions is that you can use them as automcatic
> conversions:
Hmm. That looks a lot more complicated than the C# version to me. I'm wondering

1) Do you have an example which is more convincing (like the LINQ one)

2) where could an IDE help me understand
val cc: CoolCollection = new java.util.HashMap
There is no "each" where I can click on - thus making it harder to understand.

Flat View: This topic has 53 replies on 4 pages [ « | 1 2 3 4 | » ]

Previous Topic

Next Topic