Archive for January, 2011

When Coding Fails

No Comments »

I needed to rescue all the photo’s on a 2.5″ drive. It had a S-ATA interface. I had all the software but not the hardware. So I went out and bought a S-ATA to USB3 gadget. Though the computer reading the disk had only USB2, I bought the USB3 device because (I thought) I knew USB3 is 100% compatible with USB2. Needles to say, it failed work. After some reading specs I find that a USB3 socket delivers 900mA where USB2 can drive a maxium of 500mA. Remembering an USB2 device that had a Y-shaped cable and two connectors it hit me. All I needed to do was add a USB2 connector to the power circuitry. Took 20 minutes. And so, my fellow coders: code not what your code can’t do for you – ask what you can do for your code.

π


Consider a Domain Specific Language

No Comments »

There I was, in this meeting. A domain specialist had build a prototype in Excel/VBA. The commercial recode was an pseudo Excel engine, coded in PHP, with the prototype expressions shoehorned into it. I’ll pause while you recover. They had replaced the domain specialist with a programmer where they should have replaced Excel with a DSL. And here is why.

 A DSL drastically lowers the implicit domain knowledge in your code. 

Let me examplify; implement “If you have been married for more than half the fiscal year…” given the implicit knowledge: Dutch law mandates that you can D.I.V.O.R.C.E only after being marriage for at least a year.

In a generic language (given some suitable library) one could write: if (is_married_on($year, 6, 30)) reasoning that who has been married the middle day of the year, must have been been married for at least the first or the last half.

Apart from the hard to spot bugs in this code, it is hard to understand what constitutes being married more than half a year. Is it 183 days and 184 in a leap year? Being married the first three and last three months of the year?

Look at three examples in an imaginary predicate logic like DSL:

{all "married" | day $Y 30 6} ->
{sum #day "married" | year $Y} >= 183 ->
{max #day "married" | year $Y} > {sum #day | year $Y}/2 ->

How easy it is for the domain expert to express things much more explicit. A generic language would need a huge number of domain specific library call’s with extreme explicit naming and still would not get close to offering a flexible and explicit alternative. Besides, it is nice to use some explicit language now and than.