Are dynamic languages the next best thing?

31 October 2007

We had a preview of Ivan’s talk this morning comparing the up-and-coming IronRuby dynamic language in .NET with C# 3.5.

My first impressions of Ruby on Rails and IronRuby are that they give you fast results now, but at the cost of maintainability later (since everything’s a tradeoff). But, maybe maintainability doesn’t matter so much, because its faster to just re-write it.

In C# & Java, I like the fact that an interface is a contract and the implementation is abstracted away from caller. Dynamic languages lose this explicit interface-driven-design in favour of a test-driven-design.

At the end of the day, its what gets better results for less effort that matters so it will be interesting to watch if dynamic languages can improve project success rates and deliver cheaper and better quality software.

Are dynamic languages the next best thing? Ivan definately thinks so and will be writing more about IronRuby on his blog.

Leave a Comment » | .NET, Software, Technology | Permalink
Posted by Andrew

Thanks MBUnit

18 July 2007

Unit testing can be very satisfying, especially when tests fail.  If your tests always pass, then you start to wonder if the tests are working.  I was wondering this yesterday, so I added some extra assertions, thinking that one of these two tests must fail:

Assert.AreNotEqual(firstInvoiceNumber, secondInvoiceNumber);
Assert.AreEqual(firstInvoiceNumber, secondInvoiceNumber);

Wrong.  They both passed.  After some more testing,

string firstInvoiceNumber = string.Format("{0}", "TEST");
string secondInvoiceNumber = string.Format("{0}", "TEST");
string firstInvoiceNumber1 = "TEST";
string secondInvoiceNumber1 = "TEST";
Assert.IsTrue(firstInvoiceNumber.Equals(secondInvoiceNumber));
// PASSES
Assert.AreEqual(firstInvoiceNumber, firstInvoiceNumber1);
// PASSES
Assert.AreEqual(secondInvoiceNumber, secondInvoiceNumber1);
// PASSES
Assert.AreEqual(firstInvoiceNumber, secondInvoiceNumber);
// PASSES
Assert.AreNotEqual(firstInvoiceNumber, secondInvoiceNumber);
// PASSES
Assert.AreEqual(firstInvoiceNumber1, secondInvoiceNumber1);
// PASSES
Assert.AreNotEqual(firstInvoiceNumber1, secondInvoiceNumber1);
// FAILS

So, don’t trust your unit tests any more than you trust your code.  “It must work because it compiles” doesn’t apply to unit tests either.

2 Comments | .NET, Software | Permalink
Posted by Andrew