I was recently asked, why did you choose Phobos? It made me stop and ponder all of the other scripting technologies I looked at, and why I settled on learning, developing, and writing about Phobos. Besides the requirement of being open source, here is my short list of importance.
1) It must be simple to use. Simplicity translates into more productivity.
2) It must be powerful. I do not want to reinvent the wheel for everything I need to
do.
3) It must be based on a somewhat standard deployment infrastructure. Some projects
are good at specific things, but once needs grow outside the original bounds, it
becomes difficult to meet advanced needs.
4) The language must be easy to use.
The best feature I find about Phobos is its simplicity. The way the infrastructure is laid out is incredibly simple, but powerful. There are minimum requirements to interface between the pieces, and yet the interfacing can be as complicated as you need it. You can abstract as much or as little as you want. Subclass as much or little as you want. Phobos is simple, but very flexible.
The second feature of being powerful. This is simplistic. You do not get more powerful than the Java platform. With Phobos, Java object integration is as native as Java. If your a Windows programmer, it is as native as using COM or .Net objects. When you look at large enterprise applications, a great majority are running on Java. This power is available to you as a script writer. With this integration, power, and Java market share, pieces can be dropped right into Phobos. For example, if you need to accomplish a certain task like make a connection to a database, you do not need to find a Phobos specific example on how to do it. You can take any basic Java example and rewrite it using JavaScript and the Java objects. This means that every piece of Java code on the Internet is now a Phobos example. If you stop and think about it, that thought is pretty incredible for a scripting language. We can conclude that in order to use Phobos effectively, we do not need millions of developers to have years of experience using it and writing examples of how to get things done, because we already have that. You can become very productive immediately.
Third. With the rapid pace of change in operating systems, servers, security and software, a solution based on a standard deployment platform is important. There are many good products out there, but if you invest years of development into an application, you want to be sure that it will run on the platforms of the future. Java containers and Java fill this need. They are standards based and deployed worldwide. Projects who maintain their own deployment infrastructure or app server, must change with the times. With deployment to a standard Java app server, we can be assured applications will run in the future.
Fourth. The language must be easy to use. I do not want to compare the pros and cons of different languages, but I will say that JavaScript is everywhere because of the Web. Many solutions are trying to give developers tools to avoid writing JavaScript. With a debuggers now available in NetBeans and in FireFox, why not just write JavaScript for web applications?
I recently saw an article touting Adobe's new AIR development server, DARE. It stated that this server would allow you to test AIR applications on your local machine. It would be as easy as changing a few lines of code and refreshing your browser. DARE will greatly increase web productivity and make it much easier to develop web applications. Is this really cutting edge? Is that what they are saying? We have had that with PHP and ASP for years. Anyway, I am not going to rant, but I will say that Phobos and Netbeans have this as well. No need for compile or deployment, just a browser refresh, and you do not have to use proprietary technology.
Friday, April 11, 2008
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment