I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Do You Really Need Java 7?

10.17.2008
| 27381 views |
  • submit to reddit

It's a long wait for Java 7 and there's a lot of speculation about what we can expect once the final JSR is out. I took a look through the what's coming up to find out if there's anything I actually needed.

One thing that struck me about the whole thing is that maybe there's less demand for a new Java version because of the following reasons:

  1. The advancements made in both Java 5 and 6 have satisfied most of our development needs from the JDK.
  2. One of the main things I was looking forward to in future versions was the reduced footprint from the JRE. Once again, that's already cleared with with Java 6 Update 10. 
  3. We've got so many frameworks out there, that we are no longer so dependent on JRE changes
  4. There's a whole lot of focus on JavaFX releases from Sun. Maybe this has taken over from old fashioned excitement about the next major version of Java.

Either way, from reading various breakdowns and predictions about Java 7, I decided to put together my own list of what I'd like to see happen.

No Closures

Neal Gafter has a closures prototype completed, but I'm still not convinced that it should be part of Java 7. When I interviewed Joshua Bloch a few months back I asked him for his opinion on the closures debate. 

As readers of the first edition know, I value simplicity and clarity above all else. So it should come as no surprise that I don't want to see anymore major additions to the Java programming language. It's already as complex as a language should be. If Java programmers want to use features that aren't present in the language, I think they're probably best off using another langauge that targets the JVM, such a Scala and Groovy.

I agree 100% with this. Simplicity is key and the thought of having closures in there just muddies the waters.  This feature has caused so much of a split in the Java camp, that it just doesn't feel right to include. Not for now at least. For those of you unfamiliar with closures, there's a good introduction here.

Better I/O

This is definitely something I'm looking forward to. The introduction of NIO was great a few years back. JSR 203  will include much better filesystem APIs. There's a good overview of the JSR over at David Linsin's blog, and on this article from Java.net. 

Making Swing Easier

I'm not saying it's too complicated right now or anything, but JSR296 would be a welcome addition. It has the aim of making desktop applications easier to create in Swing - which is something that's needed. The Eclipse RCP has raised the bar for desktop applications, and Swing needs to be able to compete. This specification will make it easier, and faster,  to get your Swing applications off the ground.

There's an excellent article on the Sun Developer Network outline how the new Swing Application Framework can be used. Geertjan has also written a nice account of what it actually means. 


If you want to keep track of what's going on in Java 7 discussions, the best place to go is Alex Miller's linkblog on the topic. It's been a great basis for me to get some insight into what may be coming up.

You've read what I'd like included, but what do you think is most important? And do you actually need Java 7?

Comments

Ricky Clarkson replied on Sun, 2008/10/19 - 2:24am in response to: J Szy

Despite having edit rights on FCM, the closure proposal for Java I mostly agree with is BGGA.  BGGA, last time I looked, was under the Java Research Licence.  This is really wholly inappropriate for 'non-trivial projects'.  I've noticed that it's been checked into the openjdk mercurial repository, which might make it now GPL+Classpath.

"My, even Python only has simple lambdas".

Python's lambdas are closures in the same sense as the closures being talked about for Java.  They are restricted to being one expression, which is fine for functional code.  Most Java code is imperative though, so the closure proposals for Java try to address this.  Also, Python has list comprehensions, which consume lots of use cases for lambdas.  And the name of a function can be passed around in Python to be invoked, much like method references in BGGA and FCM, which makes the single-expression limitation less important.

Ricky Clarkson replied on Sun, 2008/10/19 - 3:06am in response to: J Szy

"I want to see not only the syntax but also the impact that the change would have on the rest of the code."

So look at any program using closures in any language and translate it to not using closures.  Then compare.

"Would it lead to more or less duplication?"

Less. 

"Would it make refactoring easier or harder?"

Neither.  Try it out in Visual Studio 2008.

"Would it play well with existing language features or not?"

Try it out with the BGGA prototype.  BGGA is explicitly designed to work well with the existing language features.

Karl Peterbauer replied on Sun, 2008/10/19 - 7:24am in response to: Mikael Grev

Please explain why closures decrease Java's ease of use.

Mikael Grev replied on Sun, 2008/10/19 - 7:38am in response to: Karl Peterbauer

It adds to the coplexity of the language. There will be more way to do the same thing. People that already "know" Java will need to go back and relearn this. As fas as BGGA goes there is also alot of quite complex things that is introduced, such as how return and break are treated.

For us intetested in the language this isn't a problem but most Java developers are just using the language to get something done and will never for instance go to javalobby.org...

I think the fact that the language will be more complex is undisputed. The question is whether the gains are larger than the complexity increment. Joshua Bloch, which is without a doubt a very credited Java lanugage expert, thinks so and so does most "normal" developers I talk to think.

Karl Peterbauer replied on Sun, 2008/10/19 - 9:32am in response to: Mikael Grev

Yes, closures add yet another way of doing things, but they give us the ability to express things more precisely.

Example: I'm a web developer. Java web developers are familiar and comfortable with JSP's expression language (stuff like ${person.lastName} or ${person.address.zip}), although there are countless drawbacks (yet another language to learn (sic!), untyped, brittle IDE support, poor refactoring, ...). JSR 295 (beans binding) takes the same road, adding yet another way of doing things to the desktop world.

Drastically spoken: The most prominent UI toolkits in Java (JSP/JSF in the web world and Swing in the desktop world) effectively dump Java in favor of a weird scripting language, simply because of a lack of expressiveness in Java. It's time to fix this mess.

 

Marek Lewczuk replied on Sun, 2008/10/19 - 12:25pm

For me there is only one syntax change that MUST be included in Java 7 - import aliases. Not having this features is just a nightmare for bigger projects - right now all classes must have stupid prefixes. It is quite easy to implement this, so I hope people that decide about Java 7 will hear my voice. Just imagine code like this:

import java.awt.Popup as AwtPopup;
import java.swing.Popup as SwingPopup;
import java.swingx.Popup as XPopup;
import my.package.swing.Popup as MyPopup;

public class Popup extends MyPopup {
}

 

Best wishes,

ML

Mark Thornton replied on Sun, 2008/10/19 - 1:59pm in response to: Marek Lewczuk

I would rather not see import aliasses in Java 7

Ricky Clarkson replied on Sun, 2008/10/19 - 2:06pm in response to: Mikael Grev

You could argue that any syntax improvement adds to the complexity of the language.  The most obviously-good syntax improvement I can think of making for Java is the import alias that someone else in this thread suggested.  For reference, Scala does it as: import java.util.{List => JavaList}.  The braces are helpful there because in Scala an import statement may import more than one item.  For Java, import java.util.List as JavaList; would be unambiguous.  (incidentally I think the braces could be removed from Scala's syntax there)

Now, I don't actually care about this import syntax one jot, but I can see that it would have no negative effects on the readability of code (unless you're expecting people to write import java.util.List as Supercalifragilisticexpialidocious; - a language can't prevent idiocy, it can only not encourage it). Yet in the same way, someone can easily discount this change as "adding to the complexity of the language".  With such an argument, progress can never be made, and all projects should be frozen at their 1.0 release.

So for closures, rather than generically saying "adds to the complexity of the language", try to give actual problematic cases, e.g., "makes program XYZ slower than when using anonymous classes", or "doesn't work with generics", etc.

It's not exactly true that people who already know Java will need to relearn this.  APIs designed for closures will be able to be used, though awkwardly, without using closures.  The only time they'll need to understand closures is when reading code containing them.  In this case they'll have a choice between spending 5 minutes learning about closures, or using the refactoring tools in their IDEs to change the code to the Java 5 version.

The treatment of return and break in BGGA are there to make stuff like:

time() {

   expensive code that might return or break from loops

}

work, i.e., to make closures not have silly corner cases and arbitrary restrictions.

I'm a bit uncertain what you meant regarding Josh Bloch.  I think there might have been a typo there.  He seems in favour of providing a half-written specification for a half-useful variant of closures, and spreading doubt about them using words like "we don't want another generics".  Generics were years and years in the making and were botched at the last moment (wildcards) by Sun ignoring the guy who created them (Martin Odersky, creator of Scala and javac 1.3, the first javac to include support for generics) and by using a relatively closed process.

Mark Thornton replied on Sun, 2008/10/19 - 2:48pm in response to: Ricky Clarkson

[quote=rickyclarkson]

or using the refactoring tools in their IDEs to change the code to the Java 5 version. [/quote]

I can't imagine that being permitted in a team context.

 As for generics, only removing the compatibility constraint would have allowed a substantially better result. I think that constraint was out of bounds for the development team. I don't recall the pre-wildcard version of generics as being better, and quite a few people struggled with it.

Ricky Clarkson replied on Sun, 2008/10/19 - 6:09pm in response to: Mark Thornton

I'm sure we all here know that we have to work to the level of the worst programmer in our team.  There are a couple of cases here:

1. We are the worst programmer; that's why we have to refactor our colleague's code to not use closures, so that we can understand it.  We should either learn how to use closures, or our team should stop using them.  (Or we should be removed from the team..)

2. We are refactoring to make sure that we understand how the implementation works, and aren't actually going to check in the result.

Note that number 2 is entirely realistic, because a refactor to remove a closure (or insert one) is a local refactor; it has no effects on other files.

Yardena Why replied on Sun, 2008/10/19 - 6:17pm

Regarding generics, they would have been useless without wildcards. And Martin Odersky was part of GJ, so it does not look like Sun was ignoring him at all. And anyone who cared, could have downloaded GJ prototype and provided feedback on JSR-014.

As for closures, so what if there are some complex corner-cases? There are plenty of those in "core" Java, and Josh Bloch knows it very well, after all, he co-authored Puzzlers with Neal Gafter! Enums, which Josh Bloch designed, also have quirks. I wonder if this "closures puzzler" by Neal Gafter (which, of course, is really an Enums puzzler) was a clever tongue-in-cheek response to Josh Bloch's critisism of closures. And BTW many "average" Java programmers are frightened at the sight of Enums no less than of Generics. So this argument can be used against any feature.

I think BGGA closures would improve Java a lot. I played with the prototype, and would use closures in real projects the minute I can.

P.S. Funny someone mentioned LINQ here, because closures were added to C# because of LINQ. LINQ also makes use of properties, extension methods, type inference, - "Lost In Translation: Formalizing Proposed Extensions to C#" paper gives a full account. Actually I'd like to see all those features in Java, and LINQ too (ha ha, sweet dreams), and not because C# has them, but because I think they'd be very useful.

Honey Monster replied on Sun, 2008/10/19 - 7:05pm

P.S. Funny someone mentioned LINQ here, because closures were added to C# because of LINQ.

That is not correct. Closures were introduced in C# 2.0 where they were called anonymous methods.Anonymous methods were full-featured closures complete with variable/parameter capture. LINQ was introduced with C# 3.0 and relies heavily on lambdas which is a somewhat related concept, but not quite the same. In C#, a lambda is interpreted as either an inline function (possibly but not nessecarily a closure) or as an expression tree (a data structure).

In the context of this discussion it is perhaps interesting how the syntax introduced in C# for closures was superceded a few years later by lambdas (which can be closures), i.e.

delegate(int a, int b) { return a*b; } 

can now also be written

(int a,int b) => a*b 

You could say that they jumped the gun with the anonymous method syntax and have added superflous syntax to the language.

J Szy replied on Mon, 2008/10/20 - 3:20am in response to: Ricky Clarkson

[quote] Python's lambdas are closures in the same sense as the closures being talked about for Java.  They are restricted to being one expression,[/quote]

Which Java closures-to-be are not. That's quite important a difference.

[quote]which is fine for functional code.[/quote]

Last time I checked Python was hardly a functional language. I must have missed something.

[quote]So look at any program using closures in any language and translate it to not using closures.  Then compare.[/quote]

The same program using named classes' instances instead of anonymous functions, and explicit argument passing instead of variable capture is way more readable, easier to understand and extensible. No surprise there, I'd say.

[quote]"Would it lead to more or less duplication?"

Less.[/quote]

I wouldn't be so sure. Blogs are certainly full of examples of how closures reduce duplication and complexity and make flowers grow but the real life could prove otherwise. 

I'm already tired of finding anonymous classes repeated over and over again. But why are they repeated? I beliveve there are three reasons: it's easy to do, the boilerplate code is generated by the IDE one click and it's only few lines of the code; it's anonymous: it's harder to find whether a teammate had written a similar class before than if they were named; it's hard to promote to a named (nested or top level) class: it is usually required to examine the code to find captured variables and convert it to accept them passed explicitly.

Closures would be even easier to write in place: the code is nearly the same and the boilerplate is gone; they are even "more anonymous": with anonymous classes one has to name their superclass or the interface implemented, but closures no longer require this, only a function signature; it's even harder to promote to a named class: captured variables are writable and there may be non-local exits (though BGGA restricted closures don't allow non-local exits and issue a warning if a captured variable is written to). 

This means all the reasons why anonymous classes are often repeated are significantly stronger for closures, and this is why I don't believe closures would reduce duplication in real life code.

[quote]"Would it make refactoring easier or harder?"

Neither.  Try it out in Visual Studio 2008.[/quote]

I've already provided an example where refactoring is significantly harder, that is promoting a closure to a named class (a method thereof) vs. promoting an anonymous class.

 

Otengi Miloskov replied on Mon, 2008/10/20 - 3:38am in response to: J Szy

Python is not functional language, Python is a multiparadigm scripting language.

A real functional programming language is Haskell, and let me tell you is a beauty pure real language. Another one is Erlang is functional with heavy concurrency concepts.

Python borrowed concepts from Haskell and another functional languages but thats all, that is different of what they are saying here about Python.

IMHO if I will replace Java in the future I will get into Scala, Clojure or Haskell. Those 3 languages are wonderful and support concurrency concepts and immutability, For Scala and Clojure those can reuse Java frameworks and Libs and they sit on top of the JVM.

George Jiang replied on Mon, 2008/10/20 - 7:19am in response to: JeffS

LINQ is pretty kick-@ss.  It's much nicer than regular ORM like JPA/Hibernate.  In fact, LINQ is a layer on top of ORM datasets in ADO.net, and integrates simple query syntax within the language.  Very elegant, clean, and powerful.

 These are either "LINQ to SQL" or "LINQ to Entity".

 

I'd rather see something similar in Java, as a higher priorty than Closures.

LINQ is closure in C#.

 

Werner Keil replied on Mon, 2008/10/20 - 7:48am in response to: JeffS

Well, EclipseLink by Oracle (and partly IBM or Sun?) is an example where a JSR has actually been implemented by an Eclipse Project.

JavaFX seems like a desparate move against players that seem a bit too big at first sight. Adobe (Flex), Microsoft (Silverlight) and also Google with some diverse projects here and there such as GWT.

Sun has recently also purchased MySQL. So if anybody might want to "eat" them, best guess would be either IBM or Oracle. Microsoft would have the money, but despite some unusual friendlyness towards Eclipse and projects funded by Microsoft like "Silverlight for Eclipse" other than that even buying Yahoo in the end might seem more logical. Google has the money, but they don't care much about any standards or conventions, see Android, Chrome, etc. The only thing they seem to be participating a bit is Guice towards WebBeans, but that's mostly a JBoss gig. RedHat I don't know, but of course some of those companies like Novell or RedHat might also profit a lot if they really dared to make a bid for Sun?

 Re: JSRs, there seems to be a lot of "Googlemania" these days throwing out new JSRs that have not even barely reached EDR stage into the public and considering them the "Next Big Thing" to ba part of Java 7...

JSR-296 or 310 are such examples.

Sure each of them covers important aspects and would benefit Java a lot. On the other hand things partly applied in JavaFX like XML-based UI definitions are nowhere to be found in 296 so far. And there are more than a Dozen competing quasi standards in Java alone (XUL, Android, etc.) not to mention Microsoft or Adobe.

310 is at least "passively" supported by Google, but their own attitude towards such standards and rather throwing quarter-baked "Cookies" into the Web than doing anything properly becomes clear, when you see this implemented in 3 (!) mostly identical competing ways implemented in Eclipse alone!
- ICU (also supported by IBM and Google, used especially in Android and of course Eclipse)
- OSGi according to their SpecLead Peter Kriens also has Date and Time classes
- Mylyn contains a lot of Date, Time and Daylight Saving algorithms again by itself neither using any of the other so far.

Take 2 different approaches in a future Java 7 (nobody can remove the old ones immediately, even if the new framework might do lots of things better, deprecating for another 3-5 JDKs is all you can do here ;-) and the chaos is worth than with Logging or Versioning/Module disputes.

The latter has also been a high target for Java 7 once, but maybe difficulties with OSGi here might have slowed things down?

Last but not least, one that has passed EDR already and given proof, it can even solve a few basic problems Java always had like no support whatsoever for Financial and Currency problems (not that ALL of the current Financial problems would be solved by that, but at least Thousands of Banks and Financial Services could stick to ONE framework instead of developing 1001 Nightmare versions on their own, each incompatible with others and error-prone, especially in "Clounds" and Offshore scenarios)

I'm talking about JSR-275, just in case you might be wondering ? ;-)

Ricky Clarkson replied on Mon, 2008/10/20 - 7:48am in response to: Yardena Why

Generics might need wildcards, but really only for a very small fraction of cases.  What Java mainly has wildcards for, things like void sort(Collection<T>, Comparator<? super T>), would be better with variance annotations, whereby Comparator itself declares that it's safe to use a Comparator<X> where a Comparator<Y> is expected, where Y extends X (e.g., using a Comparator<Number> to sort a List<Integer>.  That way you wouldn't have to repeat the ? super or ? extends in every single covariant or contravariant use.

Scala does this, Comparator would look like: trait Comparator[-T] { def compare(one: T, two: T): Int }

There still are uses for wildcards but they are so small that they might even be omitted if a library can help.

I wasn't saying that Sun ignored Odersky throughout, but as far as I know they commissioned him to build GJ and then when they released Java 5 they were no longer in much contact with him.  He definitely didn't add wildcards.

I'm not sure how LINQ uses properties.

Ricky Clarkson replied on Mon, 2008/10/20 - 8:41am in response to: Honey Monster

It really depends what definition of closure you're using.

The original definition, as far as I know, dates back to the original papers on Scheme, where it's a compiler (or interpreter) implementation technique for making functions as values able to capture their enclosing scope (in SICP you'll see something related as the environment model).

Over time, because it's always used for implementing the same thing, functions as values able to capture their enclosing scope, people have called Smalltalk's blocks closures, JavaScript's anonymous functions closures, and even Java's anonymous classes.  Java's anonymous classes are implemented by closures in javac, so this isn't wildly inaccurate.

The current crop of proposals for Java are closures in this sense.  BGGA's normal syntax for closures { inputs => expression } is pretty much a lambda, as in C#'s: Func<int, int> doubleIt = x => x * 2;  So in general, try not to get too bogged down by terminology here; most likely if someone says lambdas are closures, they mean the right thing, they just say the words oddly.  I've taken to using the inaccurate terms (in Javaland) to avoid the terminology problems.

Mark Thornton replied on Mon, 2008/10/20 - 8:51am in response to: Werner Keil

I like JSR 275 too, but then I have scientific training. I have noticed that some (many?) non scientists find the rigorous approach to units to be very hard to swallow. Scientists can see only disaster in a non rigorous approach to units. It is hard to reconcile these viewpoints.

 As JSR-310 is being developed in the open, the EDR stage is of less significance than with more closed JSRs. With other JSRs the EDR is often the first view outsiders have of it.

Mark Thornton replied on Mon, 2008/10/20 - 8:59am

I think making  generic parameters co-variant by default like arrays is probably the right answer (see http://www.artima.com/weblogs/viewpost.jsp?thread=222021), but I don't know whether we can get there from where we are.

Avoiding variance altogether (as with C#?) is also unsatisfactory. Too many things that appear reasonable can't be done.

Werner Keil replied on Mon, 2008/10/20 - 10:02am

That's a good point.

I know there are some Eclipse projects where the incubation stage is somewhat "broken", but at least the Nebula project (a bit like Swing for SWT ;-) continues to work there outside the constraints an "official" incubation by Eclipse Foundation would put upon it. Other projects with the same icon have stopped development, so this is hard to know in other communities, too. The problem about 310 is that there are so many parallel developments equally "open" as OSGi, or (covering both aspects of 275 AND much more of 310) ICU.

I wouldn't say the same for JSR-296, since it is only driven by Sun so far. Maybe if it is part of OpenJDK you might call this "open".

 I fully understand and agree, that an RI called "JScience" as well as the whole process so far attracts only academics or scientists. While I have an academic background, too having worked in the industry for nearly 2 decades now means I may be able to see both worlds unlike many other people who never knew the other.

 A financial framework maybe not necessarily based on JSR-275 (though there is a tiny, not very actively propagated proof of concept in JScience;-) directly is something, Java, Eclipse or both can profit a lot. Not just for the Financial industry (at least those surviving their current crisis)

Mark Thornton replied on Mon, 2008/10/20 - 11:05am in response to: Werner Keil

I couldn't find any duplication between JSR310 and OSGI. Given the inadequacies of the existing Java date/time classes it is no surprise that there are numerous alternatives, however JSR-310 is the only one I have seen being proposed for Java 7.

 Here is someone else's thoughts on 275: http://www.jroller.com/scolebourne/entry/jsr_275_suitable_for_java

Werner Keil replied on Mon, 2008/10/20 - 12:54pm in response to: Mark Thornton

Maybe less in OSGi (there only the personal statement of Peter Kriens, its SpecLead has so far been made, I use it in Eclipse/Spring, but don't have time to study its insight to such extent) but if you check out ICUJ you'll find plenty, some on "Units", but much more on things like TimeUnits, or entire Holiday Calendars for many parts of the world, other than the GregorianCalendar...

 Re: link, that's quite old.We had a meeting in London at QCon I believe early this year. Where more SpecLeads met than maybe even at JavaOne...?;-) Rod Johnson was there, and so was Stephen Colebourne.

Thus we had a lot of time to discuss differences in the 2 he mentioned and potential synergies. He was also on the forefront of people claiming a Money/Financial API was missing most badly in Java btw (I guess you won't read it there ?;-) but that he neither had time himself nor know anybody at first guess who would build such an API or JSR...?

 I'll try to gather a few people at ESE next month, many of whom dealing with Business or Financial apps under Eclipse or Java. To see, wheter one of their projects or something independent of those might be suitable for a Financial Market Framework.

After all, java.util.Currency is much more inferiour than the whole Date/Time class issue.
It takes no domain or "Model" related part of the problem into consideration, while some of the current Date/Time classes do.

So 310 is trying to make something better or at least different/easier, that has existed for a long time.
A very difficult task which I tribute them my deepest respect if succesful, but we all know, no system in the world will offer fully automated migration of existing code, so the old classes will have to sit side by side (or maybe in a different package, see "concurrency" etc.) with new ones, if 310 was introduced with some JDK.

275 is different. It is something that has not been part of Java before. Thus it is easier to introduce, but if people might think it is too scientific or exotic for the general public, then there are plenty of javax.* projects out there with a similar fate. 

And of course except one tiny class and a few (pretty miss-named methods btw) definitions for their names and codes, currencies and financial markets are also something never supported by Java or most other languages so far. Unless they want to leave it to all the new DDD thoughts like Grails (they have a good example of how this might look like in Java btw) JavaFX or so, this is something either of the standard bodies should deal with rather sooner than later.

George Jiang replied on Mon, 2008/10/20 - 4:43pm in response to: JeffS

[quote=jas_ejb]

Autoboxing is a nice convenience.

[/quote]

 

But Auto-unboxing is horrible.

George Jiang replied on Mon, 2008/10/20 - 4:50pm in response to: Jean-Francois Poilpret

[quote=jfpoilpret]

In my company, we are using essentially Java, C# or PHP for our various projects.

In the PHP team, nobody is using objects (PHP has them!).

In the C# team, nobody is using delegates, let alone closures.

In the Java team, people are using generics (no choice when you use some Collections!) but nobody (almost) develops genericized classes/methods.

[/quote]

 

You kidding?

 If you don't use delegate, you don't use Winform or ASP.NET. If you don't use Winform or ASP.NET, you don't use C#.

What exactly is your company using C# for?

Jean-Francois P... replied on Mon, 2008/10/20 - 7:05pm in response to: George Jiang

As far as I understand (but I am not a .NET expert, and this thread is about Java, by the way;-)), when you use WinForm or ASP.NET, much of the work is done by the tools in VS (which I don't find a good thing because developers know the tools better than the language and the code those tools generate for them).

I believe delegates usage is generated by these tools, so no apparent need for developers to know this part of the language, they know the tools better.

And that's one major problem with .NET, young developers love it because of the VS tools but they generally don't understand what's behind.

Do they need to understand what's behind? Sure! Most of the time of a system is maintenance, not development.

George Jiang replied on Mon, 2008/10/20 - 7:47pm in response to: Jean-Francois Poilpret

[quote=jfpoilpret]

And that's one major problem with .NET, young developers love it because of the VS tools but they generally don't understand what's behind.

Do they need to understand what's behind? Sure! Most of the time of a system is maintenance, not development.  In fact, Delegate is so widely used in the C# community, I will be surprised if an average C# developer does not have a good understanding of Delegate.

[/quote]

 I have done Winform myself. Though VS generates some of the stuff, you definitely need a good understanding of Delegate to do real life Winform development.

Claus Luethje replied on Tue, 2008/10/21 - 2:09am in response to: Marek Lewczuk

Hi Marek,

I think import aliases are a bad idea (tm), because maintenance of other peoples code will become a nightmare as the same Object might get different names in the same application.

Static imports go in the same direction (although not as far), and I banished them from in-house development as they hurt more than they do good. Code readibility suffers, as you're uncertain if a certain method ist local or statically imported from someplace else.

I consider static import a pain, but aliases are much worse.

Just my 2ct,

Claus

Ricky Clarkson replied on Tue, 2008/10/21 - 4:21am in response to: J Szy

It's more likely that Python code is going to be expression-orientated than in Java, so having lambdas as a single expression is not too bad for Python.  Also, as I said, in Python you can use a function as a value (just miss off the () and you have a function object, rather than an evaluated function), so there is an alternative already there.

Guido dislikes lambdas, and has a philosophy that says there should be one way to do everything.  He wanted to remove lambdas in Python 3000, but realised that list comprehensions can't completely replace lambdas, so he relented.  He likes list comprehensions, so he's gone back a little on the "one way to do everything" motto.  He could have removed list comprehensions instead, but he didn't, showing that his design philosophy for Python is not actually based around some rules as he has stated but around his own likes and dislikes (which is fair enough).

"The same program using named classes' instances instead of anonymous functions, and explicit argument passing instead of variable capture is way more readable, easier to understand and extensible."

Here's one for you, from C# 3.0:

Console.WriteLine((from x in new []{1, 2, 3} select x * 2).ToArray()); // this will print 2, 4, 6.

Here's one for you, from Scala:

println(for (i <- 1 to 10 if i % 2 == 0) yield i * 10) // this will print 10, 30, 50, 70, 90.

Please port either or both of those to Java, and then with a straight face say that the result is more readable.

"it's anonymous: it's harder to find whether a teammate had written a similar class before than if they were named; "

Often I name my anonymous instances, e.g. public static final Function<Integer, String> intToString = ...

With an expressive type like Function it would be easy to search the code for something similar to what you wanted.

An anonymous class is not hard to make into a nested class.  It takes me, an emacs user, a minute for a reasonably large class.  It takes an Eclipse user three clicks (then a bit of editing to compensate for Eclipse's mistakes).

 I have to wonder why you are making it into a nested class though.  I do it because we have a coding standard that I disagree with; that anonymous classes should not be larger than 20 lines.

"it's even harder to promote to a named class: captured variables are writable"

Again, this is a mechanical translation that is trivial to do in an IDE, and for someone who understands how closures work it's easy to do in a normal text editor too.  Again, I don't know why you'd want to promote a closure to a named class.  That's like saying you want to promote a for loop to gotos.

Ricky Clarkson replied on Tue, 2008/10/21 - 4:51am in response to: Mark Thornton

Generic parameters being covariant makes broken code start compiling.  Holy batshit, that's a bad idea.

List<Cat> cats = new ArrayList<Cat>();

List<Animal> animals = cats;

animals.add(new Dog());

System.out.println(cats.get(0));

The above code fails to compile, though its translation to arrays compiles and gives an ArrayStoreException.  This indicates that arrays are broken.  Generics shouldn't be made to behave in the same broken way.

I dislike the lack of variance in C# but I haven't actually come across a case where it's annoying.  But that's all it is, annoying - you can always do some cruft to work around it.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.