I agree completely about the java apis. I can't think of a single java SDK api that I'd want to leverage in another language. Importing and using 3rd party java APIs is important of course.
If you have closures, all the Java collection APIs aren't desirable (not that they are desirable anyway). Calendar API is a disaster. File APIs are way over-engineered. etc. However, I really have to question the decision to support the .net runtime. I'm sure some shops want it, but most don't. It will fragment the community. You will have .net specific fan libraries that wrap up .net libraries as well as fan wrappers around java specific libs. I personally would rather see the energy spent in advancing the language and building frameworks with it. What I'd like to see is a copy of Ruby on Rails (Fan on Rails). Using RoR is a joy, but the run-time is a joke and static typing would increase perf by a huge factor as well as making tooling much better. What makes Ruby so nice isn't just the language features it's stuff like: 1) rake - rake is the best build framework I've ever seen. I am a huge automation fan, and I find it amusing that people in the java world don't seem to automate anything. reason? because it's PITA with ant/maven/etc. build scripts should be done in real languages! Notice how Ruby has all sorts of great projects for deployment, EC2 management, driving test frameworks, etc. There is some of this in the java world, but all this stuff comes out first in the Ruby world because it's so much easier. 2) set directory structure in rails, no question/debate how to set up your project, where to put your tests, config, database definitions, models, controllers, views, etc 3) gems - gems are a much easier way to manage libraries than jars. no classpath hell 4) database migrations (rails feature) - I still haven't seen anyone else do this (right) for some reason, even though EVERY ONE NEEDS IT (almost)! 5) config files that mix code with configuration (nature of interpreted languages is you can do stuff like put conditionals and loops in your xml/yml configuration, or even just write a config file in ruby). would be wonderful if fan could run some interpreted code (compile when file is read?) in addition to build time compilation 6) ability to run scripts in the language, instead of dropping to the OS shell languages. have you even looked at the tomcat .sh scripts? YUCK. if-then hell. every platform is a little different 7) console mode - groovy's console is nicer with copy/paste and such. I'd love to see Fan ship with a nice console client that has auto- complete and can "hook" into a running process so you have all the app state/settings available Frameworks/platform features like these mean that developers spend more time building features and solving business problems instead of building out "infrastructure". On Dec 22, 5:58 pm, 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 -~----------~----~----~----~------~----~------~--~---
