Ok, this is a rant, so be prepared to hear some whining. I have spent almost two days trying to compile Apache Axis2, for I needed a java web services solution. I could have used the latest binaries, but the problem is there is a bug in the eclipse plugin source, and IF I can get my hands on the plugin sources, I can fix it.

I won’t get into story of my frustration, but let me tell you this. At the moment, the latest downloads of Apache Axis2 can not be compiled using the instructions in the bundle. I have failed to find other instructions, and I had to switch to Metro. It is really interesting that such a well known project is not providing a source bundle which you can compile by following instructions. Some of the subdirectories (like the eclipse plugin dir) contains instructions which use maven1, and the main readme uses maven2.

I’m sorry but I simply do not have the time to dig into all source tree and maven. I just want to get an eclipse plugin source tree so that I can work on it. Maybe I am too stupid for Apache Axis, but I simply can not do it. I hate this when it happens, and it happens from time to time, but I did not expect this in Apache Axis2. You can check for my posts in axis mail list, which have not reached a solution.

In the past, scripting has been a real strength of Microsoft technologies. I’ve seen some very capable solutions built with visual basic, and as new generations of technologies emerged, I expected Microsoft to provide more robust solutions.
Scripting is important, because it lets you come up with flexible solutions. Most of the arguments which are against scripting for large scale development focus on weak type checking, and performance. However, scripting has one very important advantage: when you build a core set of functionality which covers the basic requirements of a domain, scripting gives you the ability to provide this functionality to others who might have less information about the domain.

When you can make junior developers create a solution for you, you have a cost advantage. Using scripting gives you the ability to come up with domain specific languages, which are the way of the future in my opinion. Scripting also has some technical advantages, which lets you work in a loosely coupled environment. You can dynamically update scripts, which has many benefits compared to usual code, compile and deploy scenario. I might be a little bit exaggerating, but recent approaches like Ruby on Rails are close to scripting solutions, even though dynamic languages is the correct definition for them.

The problem is while Sun seems to be embracing this idea, Microsoft seems to be getting away from it. In the past Microsoft’s scripting solutions provided very nice features to pass native objects back and forward between compiled domain and scripting domain. After 6 years, scripting seems to be going into a certain subdomain in Microsoft world, which is management. Monad seems to be the only active scripting effort of Microsoft, and it does not seem to be positioned like the good old scripting host, which you could drop onto a form (both for vb and windows forms) and use.

There are products/technologies like VSA which looked like the new scripting solution from Microsoft for a while, but they are dead now. So Microsoft, what are you going to do with this? WPF and XAML has great potential for scripting support, but it appears to be only supported in Silverlight! Why on earth do you provide dynamic language support to Silverlight and do not build it into WPF? Maybe they will, but the overall direction of scripting for Microsoft is very vague at the moment, and this creates a serious disadvantage for me. Let’s just hope it will get better (maybe in the form of dynamic language support) when vs.net 2008 is released.