First they ignore you
then they ridicule you
then they fight you
then you win
    -- Mahatma Gandhi
Chinese => English     英文 => 中文             
随笔-221  评论-1047  文章-0  trackbacks-0

It's become apparent that dynamic programming languages such as Ruby, Python and even Java/ECMAScript are coming into vogue for developers on the cutting edge. Ruby on Rails has done much to promote the Ruby programming language and Ajax is focusing more interest on JavaScript. Python hasn't found its muse yet, but its also gaining more attention. The age of dynamic programming languages is imminent. What I mean is, a time when dynamic programming languages are the norm, rather than the exception, is just around the temporal corner.

Within the next five years most organizations will use dynamic programming languages in some enterprise development. Not all development: There will always be a need for conventional programming languages which allow you to detect bugs at compile time rather than run time. However, the times when dynamic languages are dismissed as "dangerous" or "toys" is coming to a close.

While cutting-edge developers are flocking to dynamic languages like Ruby, the mainstream of the development community has been less inclined to adopt dynamic languages. There are two reasons for this: FUD and Productivity. Fear, Uncertainty, and Doubt (FUD) continue to muddy the waters for developers who are trying to grok the significants and use of dynamic programming languages. It's not unusual to hear people say that dynamic languages are "toys" or are "dangerous". What I've discovered, however, is that these same people usually have little or no experience with a dynamic language. The FUD was born and propagated out of ignorance as is usually the case with these things. There is, however, a far more pragmatic reason why dynamic languages have not been taken up by the masses: Productivity. Learning a new programming language platform is not a small endeavor. While syntax of a language can be fairly easy to learn, learning an entirely new set of libraries is a huge obstacle. For example, Java programmers spend proportionally much more time learning how to use standard, enterprise, proprietary, and open source APIs than they do the syntax. In fact, I would say the ratio is something like 20:1 the first year and 100:1 thereafter.

If you've spent all of your mental effort learning how to properly use Java packages and APIs (rather than syntax) then the thought of throwing all that time away in order to learn a completely new platform may seem ... well ... stupid. Or more accurately, its not a pragmatic choice when the advantages of the new platform are not obvious. Essentially, everything a Java developer knows about accessing databases, manipulating strings, doing input and output, etc becomes obsolete. In addition, the new platform may not have as strong of an ecosystem as Java.

In the case of mainstream Java developers, its seems less than optimal, for example, to change platforms to something like Ruby. Don't get me wrong! I'm a big fan of Ruby, but to be perfectly honest compared to the Java Platform the Ruby platform is positively anemic. The number of APIs (libraries) and the size of the Ruby ecosystem pales in comparison to the Java platform. There are probably around 4 million or more Java developers in the world. I would be surprised if there were more than 100 thousand Ruby developers and probably only 50 thousand that use Ruby on a daily basis in production code. Of course that's pure speculation, the real numbers for Ruby might be smaller or larger but few people would argue that the size of the Ruby development community is anywhere near the size of the Java development community.

Dynamic programming languages (e.g. Ruby, Python, JavaScript) are generally much more productive than conventional programming languages. In my research, which now spans about 3 years on the subject, I've consistently found that developers are about five times more productive with a dynamic language than they were with a conventional language in the same context. This means that once you've mastered a dynamic language, the benefits are enormous in terms of productivity and maintenance. Less code is much easier to maintain provided its clean code.

So this creates a Catch-22 of sorts: Dynamic languages are much more productive yet it would take time for developers to learn a new platform, so much time in fact that in the short run it would cost more to move to Ruby or Python than would be saved by the productivity of these languages. In addition, there really isn't a dynamic language with the same ecosystem and infrastructure as Java - so adopting a dynamic language necessitates accepting less in terms of resources, tooling, and skilled people.

The solution, therefor, would seem to be a dynamic language that is based on a platform with which the Java community is already familiar. There are many dynamic languages that have been created for the Java platform including Jython, JRuby, BeanShell, Pnut, and others but of these I believe that Groovy has the most potential. The primary reason is that Groovy is being standardized within the Java community. Although standardization is never a measure of quality, the horrible truth is technology does not win on merit alone. Companies will understandably be more comfortable adopting a language that has been standardized via the same process that standardizes J2SE and J2EE than a language that is not. Right or wrong, the powers that make decisions look to standardization as a litmus test for acceptance and usage.

Besidies being standardized, Groovy has the advantage of being a dynamic language that was built from the ground up with Java developers in mind. It's retains much of the same syntax and semanitics familure to Java developers while also offering dynamic language features like dynamic typing, mixins, and closures. These are the types of features that make dynamic languages much more productive than conventional languages. Finally, all the Java APIs that you use today can be used in exactly the same way in Groovy. Groovy compiles into byte code, so any Java API you can import and access in a Java program you can import and access in Groovy.

The Groovy standard (JSR 241) was started close to three years ago and is now coming to fruition. To some that seems like a really long time, but this is an opinion that is not based on a historical understanding of how long it takes a language to mature. Ruby, for example, which is just now getting a lot of attention has been in development in the open source community for 13 years, JavaScript for 14 years, and Python for 15 years. The fact that its taken only 3 years for the Groovy language standard to be developed is actually a phenomenal achievement.

The future seems obvious: Dynamic languages are growing in popularity and their productivity and broad applicability cannot be ignored. The Java platform is supported by a huge ecosystem of 4 million-plus developers and thousands of tools and APIs. If any dynamic language is to be successful it has to (a) be standardized (b) appeal to Java developers (c) be fairly easy to learn, and (d) leverage the existing Java ecosystem. There is only one dynamic language that meets those needs and that's Groovy.

The hype surrounding Groovy has died down and buzz about the project has been pretty quiet and in my opinion that’s the best thing that could have happened. The result is a language that has had time to be developed into something that is going to be truly useful. In many respects Groovy is the best combination of the Java platform and dynamic language design. Groovy has been quiet, but like a sleeping giant Groovy will awaken and effectively take over as the dominate dynamic programming language after it becomes a JCP standard.


原文地址:http://rmh.blogs.com/weblog/2006/02/groovy_the_slee.html

附:2007年Groovy好事连连
posted on 2007-03-21 21:05 山风小子 阅读(667) 评论(0)  编辑  收藏 所属分类: Groovy & Grails