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 27, 2006 7:42 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

Worthless.

> and here:
> http://www.intertwingly.net/blog/2005/04/13/Continuations-f
> or-Curmudgeons

This one uses Python as for it's continuation example.

Can you explain what's different in Ruby about them?

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Seeking the Joy in Java

Posted: Aug 28, 2006 1:31 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)

How about adding a type Complex to a language which does not have it? I want:

- all arithmetic operations defined on Complex
- mixed arithmetic, i.e. float+complex, complex+float
- int, float, etc should conform to Complex.
- no language changes
- no changes to existing classes.

In Scala, this is possible, and implicits play an important role. To see how it is done, look at Scala's implementation of BigInts, which uses the same techniques.

More generally, implicits give you all the power of Haskell's type classes, but in a much more lightweight package. Type classes have recently been shown to be very useful for software extensibility in general. See:

http://lambda-the-ultimate.org/node/1657

So, in summary, Scala implicits are indeed more complicated than C#'s method extensions. They also give you much more in return.

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

I'm thinking of a little marker at the new java.util.HashMap. When you click on the marker you get to see the implicit wrapper. Also, when you hover over HashMap you might see all its members, plus the members that get introduced by the implicit wrapper, but the latter in a different color. I'm just speculating, but surely there are possibilities.

Vladimir Nesov

Posts: 27
Nickname: robotact
Registered: Aug, 2005

Re: Seeking the Joy in Java

Posted: Aug 28, 2006 5:39 AM

Without requiring to implicitly add fields (which looks like multiple inheritance) implicit functions are the same functions in abstract classes or additionally enabled functions with implementations in interfaces.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Seeking the Joy in Java

Posted: Aug 28, 2006 7:17 AM

> I'm thinking of a little marker at the

new
> java.util.HashMap

. When you click on the marker you
> get to see the implicit wrapper. Also, when you hover over
> HashMap you might see all its members, plus the members
> that get introduced by the implicit wrapper, but the
> latter in a different color. I'm just speculating, but
> surely there are possibilities.

A different color might work but I believe that with mixins and implicit wrappers a type could have methods contributed from several different sources. In order not to get lost in all that, it would be nice to be able to see where the contributions came from in a quick way. Maybe it's another panel on the window, I don't know. One of the things which was frustrating to deal with in Eclipse when I had to maintain code with lots of extension was that it was often time-consuming to track down which class contributed the 'active' implementation of a method. If we could see an overview (a tree maybe) of all the methods under their contributors I think that would be really helpful.

Roger Voss

Posts: 27
Nickname: rogerv
Registered: Aug, 2005

Re: Seeking the Joy in Java

Posted: Aug 31, 2006 7:50 AM

Dude! You can have your cake and eat it too.

Groovy is the perfect compromise answer:

* It accepts the Java language syntax (at least up to 1.4 - needs more work to accept Java 5 features). It is perfectly interoperable with Java classes in terms of consuming - can even consume code that uses generics (because of typer erasure). Plus compatible Java classes can be written in Groovy and compiled to byte code .class.

* Groovy has closures and like VB, can be used in typeless manner or will enforce typing if types are declared. In general has enough cool features too keep Ruby envy at bay. (Of course has much better Java integration story than JRuby or Jython as one just uses the Java class libraries for Groovy's runtime instead of porting in a foreign class library.)

* Groovy is more unfettered in terms of embracing new innovative features than is the Java language proper. Hence makes sense to do innovation in Groovy while leaving Java stable and still basically coherrent as a language.

* Me thinks its actually preferrable to segregate the two programming styles and Groovy combined with Java accomplishes that.

Sun and Java community should give up trying to shoe horn difficult new features into Java and instead concentrate on making Groovy the flag ship companion language. Ultimately Groovy could become "Java2".

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Seeking the Joy in Java

Posted: Aug 31, 2006 1:55 PM

> How about adding a type Complex to a language which does
> not have it? I want:
This can all be done in C# 3.5

> - all arithmetic operations defined on Complex
operator overloading

> - mixed arithmetic, i.e. float+complex, complex+float
> - int, float, etc should conform to Complex.
public static Complex operator+(this float, Complex c)
etc.

> - no language changes
> - no changes to existing classes.
yup

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Not Feeling So Groovy

Posted: Aug 31, 2006 4:06 PM

> Dude! You can have your cake and eat it too.
>
> Groovy is the perfect compromise answer:
>
> ...
>
> Sun and Java community should give up trying to shoe horn
> difficult new features into Java and instead concentrate
> on making Groovy the flag ship companion language.
> Ultimately Groovy could become "Java2".
>
I was very excited about Groovy's potential when I first heard of it, which was quite early on. I wanted to join the project, but realized I just didn't have time to do anything useful. But I was a bit disappointed in one of the features you mention: it will take Java code (up to 1.4, as you mentioned). I find Java code a bit verbose and would really have preferred something not so Java-looking.

I like the idea that Groovy uses Java libraries natively, because with JRuby or Jython, you really have two sets of libraries to deal with: the Ruby/Python one and the Java one.

While I think Groovy is important and useful, I don't think it is a substitute for Java, because its dynamic typing will have a runtime performance effect. It is a different kind of tool, suited for different kinds of tasks. Large swaths of any program are irrevelant to performance, of course, and if you can predict what those are, then Groovy might be a good fit. Unit tests could be written with Groovy for example, and maybe it would be fast enough. (But on the other hand, unit tests are something you want to run very fast.)

But where I use Groovy, I lose the ability to get basic refactoring support (such as rename method) with as much accuracy, simply because there is less information in the code for the refactoring tool to work with. I find it hard to believe the productivity boost I get using Groovy the language would be worth the loss of some of those tools. That's something I liked about Scala: it had a lot of the functional features, code conciseness, and such of languages like Ruby and Python, but was still statically typed. And like Groovy, it very smoothly integrates with Java APIs.

My point is that I think Scala, because it is statically typed, is more suitable as a Java substitute than Groovy. I see Groovy more as an augmentation to Java, a way to do areas of the code that are a good fit for being "scripted."

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: Not Feeling So Groovy

Posted: Aug 31, 2006 5:47 PM

Thanks for starting such a fascinating post. I hope we can learn from history. Fortran 2003 added polymorphism and Fortran 2008 adds coroutines to a language that began waning when Fortran 8x arrived in 1992. The sadness is is like the feeling of watching an over-the-hill Ali or Tyson fight years after their glory days.

Java's glory days are today. The language changed the world by combining the best of Simula,C,C++,Smalltalk to make something bigger. Rather than tarnish this by bolting on more we should focus that creativity on Ruby, Scala, Nice.

Or by identifying what the best of all these languages and Java, Python, Smalltalk, C#, C++ and Perl would look like and creating it.

Mayuresh Kathe

Posts: 2
Nickname: mayuresh
Registered: Sep, 2007

Re: Seeking the Joy in Java

Posted: Sep 5, 2007 4:33 AM

> Do you believe that another language for the JVM could someday become as mainstream as Java?

Yes, I believe, its called Fortress ( http://research.sun.com/minds/2005-0302/ ), Guy Steele has designed it for high productivity.

Take a look at the following links too:
http://en.wikipedia.org/wiki/Fortress_programming_language
http://fortress.sunsource.net/

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

Previous Topic

Next Topic