XSL(T) and Dates 
2007.06.04 15:24 - Work-related
Because XSLT 2 support doesn't yet exist for the MSXML parser, I'm limited to solutions centered around XSLT 1. Quickly hit upon the EXSLT project, but the options there are decidely limited. In particular, there doesn't appear to be a satisfactory implementation of parse-date, which is the function I actually need.

But, a-ha! There is a project, MVP XML, which is an implementation of the EXSLT project in .NET. This might work if, having chased them through three different generations of links (from gotdotnet.whatever to Sourceforge to Codeplex) I was not greeted with a notice that the server is down for maintenance.


I have to do some conferring tomorrow anyway, so I may ask if we can't get all the dates in the XML file in a format that doesn't suck. (Two-digit years? Is it 1987 again?)

[Update: the Mvp.Xml site is up now. Hooray.]
  |  [ 0 trackbacks ]   |  permalink
On Stopping Power 
2007.04.24 10:12 - Guns, Work-related
Today's Three Panel Soul probably captures the exact reason I feel mildly uncomfortable discussing guns at work. Mildly uncomfortable. Not enough that I didn't spend an hour talking handguns with one of the other devs yesterday afternoon.
  |  [ 0 trackbacks ]   |  permalink
Language Griping 
2007.02.26 14:04 - Work-related
I was hired into a Java-programming position last May which, almost immediately (and well before I got to do any Java programming) became a .Net programming job. This is mostly okay. .Net is likely to be more saleable down the road, and it's a vast improvement over MFC in most regards. Still, I find myself pining for Java, now and then. (Also for Scheme, but that's not a problem specific to C#.)

C# is, mostly, a nice language. And it does have some nice features that Java really, really ought to have had ages ago. However, I sometimes run into a feature of the language that just gives me screaming fits.0 The one that's most often the bane of my existence is the lack of a throws clause on function declarations. I think I have a fair idea why they did this1, but it's really a major pain. Exception-safe code is a non-trivial enterprise when you know where your exceptions can come from. In C#, exceptions can, basically, be thrown anywhere, at any time (as far as you know). Granted, you're not going to be able to do much about the ones that really can be thrown anywhere, but there's also no way to guaratee that an object implementing an interface will actually behave the way you expect, because an important part of the contract is missing.

And documentation is no substitute, really. Although lots can be done to prevent docs from getting out of date with respect to the source code, there's no guarantee that everything will be documented, or documented correctly.

In any case, contract programming is, really, a no-go. The contract can change and you won't know until the application blows up messily. (In Java, you know at build that something's gone awry.)

0. Not actually. Well, there's no screaming involved. It's usually pretty irritating, though.
1. It allows derived interfaces to throw exceptions not specified above them in the class hierarchy. This allows for more generic interfaces. At least, I think that's the reason.2
2. It's probably also the case that they felt like too many Java programs just threw try { [...] } catch (Exception e) {} blocks in to avoid exception handling entirely. I would submit that making exception handling more difficult is probably not the solution. In practice, I think the C# solution probably encourages more of that, because you no longer have the same degree of certainty about thrown exceptions.

  |  [ 0 trackbacks ]   |  permalink