One argument script pimps use frequently is that it doesn’t matter what tools a contractor uses to build a house as long as the finished product is the same.

The problem with this argument is that the premise and the analogy are flawed.  Comparing the language to the tools is not quite accurate.  The language is more aptly compared to the building materials used instead of the tools.  The tools would instead include things like the IDE.  With the analogy corrected we now see that the choice of building material is very important.  Using 2x4's instead 2x6's will have a big impact on insulation properties (thicker wall cavities) and cost. 

Is this important?  Absolutely!  

Unfortunately, too many scripting language fans (script pimps) make the same flawed analogy in order to justify the use of their pet language instead of a higher performance language like C++ (or C#, Java, etc).  Scripting languages like Ruby are slower then compiled languages.  Also their nature precludes them from having good IDE support.  This is because much of the meaning (context) can’t be derived until runtime so things like IntelliSense become difficult if not impossible to implement. 

Following the scripter’s analysis we are supposed to assume that scripting languages allow faster construction which I would say is another falsehood.  Yes, some contractors might be able to cut wood just as fast with a handsaw but most want to use as much automation as possible.  Hence, table saws, compound miter saws with laser guides, etc.  These automation tools are closer to Visual Studio than VIM. 

In my experience with Ruby (among other languages) I found that the resulting programs were usually slower, which a scripting language will be by its nature.  I also found that the emperor wears no clothes!  Shockingly, developing in a scripting language is slower because of the lack of automation tools.  Example, try to find all references to variable in a Ruby on Rails project.  Now try the same thing in a C# project using Visual Studio.  In Visual Studio it’s a right click and “Find All References”.  In VIM you could search for the references but you don’t have any support for context.  You don’t know that is the only reference to that variable.  You are using a handsaw instead of the best tools available.

I'm sorry but reality demands that 1 = 1 and slower is slower and speed is important.

I'm working right now on creating a service that operates on messages with javascript.  The service is java and javascript makes a natural choice since almost everyone has to use javascript these days for that pesky web development. 

I'm using the Rhino package from Mozilla.  Right now I'm very impressed with the ease of use of this package. 

The main driver behind this is processing plain text.  Plain text just can't be changed to XML via XSLT.  So obviously a nice scripting language could manipulate the message to add tags and parse for naughty characters that XML doesn't like. 

I will post on how this turns out.

The Log4j project has become the de facto logging standard in the java community.  Even with the introduction of built in logging in J2SE 1.4, Log4j still remains the premiere logging framework for java.  The built in library java.util.logging provides convenience but lacks the features of the more mature Log4j.  However, not including the extra appenders and formatting that Log4j offers the function of the two libraries are very similar.  In my opinion you are much better off using the Log4j framework from the start and sticking with it.  The extra functionality has been worth it, at least in my experience.

Another advantage of Log4j is that there are versions of Log4X available for almost every major language.  I also use Log4net for my C# development and it is very nice to be able to switch languages but maintain a very familiar framework.  Almost all the configuration and even the method calls and classes remain virtually unchanged.  One caveat is that Log4net is in some kind of purgatory at the Apache foundation waiting for official project status.  I notice most of their releases are labeled as beta but I have not had any issues with it so far.  Your mileage may vary.

When you need logging, Log4X should be your first choice no matter what language you are using. 

I've been thinking recently about a possible maturity index for languages/platforms.  I use Java and C# as my main development languages.  They are very similar in syntax and in function.  If you can do something in one language you can probably do it in the other.  The differences are usally a bit of "syntactic sugar."  The major difference is the maturity of the documentation and of the available "code in the wild" by which I mean demo, samples and full fledged open source libraries.  Java has this in spades.  C# and by association .NET have a lot of this and it is growing each day, however Java has a much bigger head start and a more-open source build-it-yourself mentality. 

Hence the point of this post.  VB was my first language.  I came in to it at version 6, obviously at the end of its life cycle.  However, VB was in its prime.  You could find books, magazines, samples and examples galor.  Programmers had explored every angle of VB, not only had they put on the rubber glove and explored its orifaces but they had opened it up and shined the light on its entrails.  VB was a mature, highly productive platform, which is something that Java is now and C# is definetaly becoming. 

This is not to put down C#.  On the contrary, when C# has the maturity that Java now enjoys it should be a true work of art.  I think that as the .NET platform enters into version 2 we should see C# hit its sweet spot.  The major thing I see holding it back is the lack of open-source (read FREE) software.  Obviously it is designed and publilshed by Microsoft for the intent of selling MS product.  I see promise in that most popular Java utility libraries (JUnit, JDoc, Log4J) have been ported to .NET.  I would like to see more enterprise applications out there.  An open source appserver and web server would be nice.  Some decent object pooling and threading libraries would help. 

I think these will come, its just a matter of maturity.