> A good example is phil's list of Java APIs he hates. > > 1) Calendar. Calendar is going out in favour of JSR 310. Presuming > > Stephen can find some help. > > 2) File: There's an entirely new File API coming in java7, spearheaded > > partly by Carl Quinn, in fact. > > Clearly phil isn't up to date, or he's deliberately not telling the > > whole story to paint java's APIs as worse than they really are. > > Well I've been waiting for java 7 for a long time now (Java 6 was released in 2006). And they *STILL* haven't decided what's in it. Looks like Java 7 will be released in Q1 2010. So we will start seeing wide adoption in 2011.
But I agree that if the language were to wrap up an leverage java code behind the scenes, that would be fine. All I care about it the API, which is the developer's user interface. But leveraging the Java API either directly or indirectly doesn't matter as far as Fan is concerned. They made their choice long ago. But for my "dream language" (which doesn't exist best I can tell), I agree that I'd probably just build a better interface on top of java's collection API, File API, etc. They are already optimized and tested.... I think making access to Java APIs as easy as possible is definitely a good thing. But unfortunately because of the .net compatibility layer you can't count on them being available :( I haven't seen what java integration looks like in Fan, anyone have a link (google didn't turn up anything for me, best I can tell it doesn't exist yet). On Dec 23, 8:46 am, Reinier Zwitserloot <[email protected]> wrote: > How about a way to monkeypatch existing APIs so that the > representation does not change (and is thus 100% compatible with > everything else on the JVM), but the API doesn't have these warts you > speak of. Then you're three quarters of the way there to a system that > allows you to evolve APIs without breaking code that was written for > the old API version (just give them a monkeypatched view of the new > one). > > NB: Python and Ruby's take on monkeypatching is a runtime adjustment > that has dynamic scope. A much better would be a pre-run runtime > adjustment (java's premain), with lexical scope. > > Best of both worlds. > > I get why you'd want to start from scratch, but one must understand > that this is a missed opportunity in regards to giving those switching > from Java to your language a common ground to work with. Remember, > Java's syntactical similarity to C is often claimed to be a major > reason for java's success in the enterprise. It's hard to prove, but > it seems to make sense. The similarity doesn't have to be syntax > related. Having all the common library tools work virtually equal to > what switchers are used to, at least switchers that are working with > newer more modern versions (e.g. by all means ditch calendar and date > altogether and stick with jodatime - people who are willing to > consider switching languages at this stage are most likely using > jodatime already anyway! - same for the fork/join framework and using > java.util.concurrent instead of synchronization primitives, and prefer > event listeners by composition of many small classes instead of adding > the XListener interface to the GUI class file itself and / or writing > a separate interface. An in-place anonymous inner class declaration is > so similar to a 'closure' that having a language that actually > implements listeners as closures is only a very minor adjustment). > > There's also the issue of effort: Having the java APIs verbatim means > you've got waahaaay less work cut out for you in regards to libraries, > allowing you to focus more on the language itself. Which gives you > time to come up with neat new tricks to let APIs evolve in a way that > old API 'views' can be provided to code that was written with the old > deprecated API in mind. > > A good example is phil's list of Java APIs he hates. > > 1) Calendar. Calendar is going out in favour of JSR 310. Presuming > Stephen can find some help. > > 2) File: There's an entirely new File API coming in java7, spearheaded > partly by Carl Quinn, in fact. > > Clearly phil isn't up to date, or he's deliberately not telling the > whole story to paint java's APIs as worse than they really are. > > Have a look at how jython pulls off some java integration tricks: > > If there's an addXListener(XListener x) method, where XListener has > methods of the form onX(XEvent z), then jython allows you to write: > > button.actionPerformed = lambda evt: self.doSomething() > > pretty crazy syntax sugar, perhaps, but that extensive syntax sugar > can be applied automatically in a deterministic fashion. > > On Dec 23, 1:58 am, Brian Frank <[email protected]> wrote: > > > Depending on the goals, the standard library is an integral aspect of > > a programming language. Certainly a language like Groovy is designed > > to embrace the Java library, but the intent of Fan was to start with a > > clean slate from the decade of cruft which has set into the Java > > libraries. So for us there is no separation in our problem space > > between language and library - part of our mission is to provide a > > better library for core functions. I personally think the Java > > libraries need a lot more fixing than the Java language. > > > Although we just recently added a Java FFI which lets you use any Java > > library seamlessly - so if there is a desire to just use Fan against > > existing Java libraries, then that is now easy. And we will do > > likewise for .NET. > > > I feel portability between Java and .NET is immensely important, which > > is why we do it. I can assure you from first hand knowledge that the > > number of shops who care about this issue is not small at all, it is > > an absolutely huge problem for a lot of companies. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
