Re: Microsoft vs. Perl and sloppy programming

While I sort of agree with you, I strongly object against your biasm. Both Microsoft and Perl are doing DWIM. Either you think DWIM is good, or it's bad and you prefer BSDM, but I find it silly to say that when Microsoft is doing it, it's evil, but when Perl is doing it, it's good. Same for IE and Netscape. Netscape has been second guessing document authors longer than that Bill Gates realized the internet was here to stay.

I don't think VB produces unpredictable results. That the return value of a function depends on the data passed to it isn't strange at all. Lots of function in lots of languages do so! As for the setting of locale, well, that's a parameter as well. Does Perl also have unpredictable results because the return value of uc and lc depend on locale? sort depends on locale as well, and some regexes too. Does that make Perl unpredictable? What about binary | and ^, where it matters whether the operands are strings or numbers. Or post/pre increment, where it can matter whether something was used in numeric context or not. I'd say that's far more "unpredictable" than the date function in VB.

The solution is of course here. I believe that DWIM is a powerful feature. But just like powertools, they aren't for everyone. They are powerful in the hands of a master, and dangerous for those who cannot deal with them.

-- Abigail

Comment on Re: Microsoft vs. Perl and sloppy programming - Wildly OT Select or Download Code

Replies are listed 'Best First'.
Re: Re: Microsoft vs. Perl and sloppy programming - Wildly OT by iakobski (Pilgrim) on Jun 22, 2001 at 18:13 UTC
I don't think VB produces unpredictable results. That the return value of a function depends on the data passed to it isn't strange at all. Lots of function in lots of languages do so! I have to say I think Ovid's example is a good one. I recently had to debug a bit of VB code that was giving unpredictable results - It was supposed to check the date of a remote file and update the local file if it was out of date. This worked most of the time, but some users in some locations reported that they sometimes could not see updates at the beginning of the month. It turned out that one of the dates was using the machine locale and the other was using the US date format. Now this is a bug and clearly should not work if you are on a european locale. But VB in its infinite wisdom was not raising an error or even reporting a warning when given a US date of 13/5/2001 - it just tried out all the other date formats in the locales table until it worked! This is unpredictable because it depended on when the remote file was updated, when the local user last got a copy of it, whether they noticed it was out of date and whether it is currently the end of the month. This is not DWIM! A bug like this needs to be known about ASAP, not a year down the line (I wasn't the first to look for the cause of the bug!) The difference between a feature like this and Perl's undocumented DWIMs is the intelligence of the designer: the VB feature was never thought through: the code doesn't change but as you go through the month whether it is right or wrong does change. -- iakobski	[reply]

Replies are listed 'Best First'.

Re: Re: Microsoft vs. Perl and sloppy programming - Wildly OT
by iakobski (Pilgrim) on Jun 22, 2001 at 18:13 UTC

I don't think VB produces unpredictable results. That the return value of a function depends on the data passed to it isn't strange at all. Lots of function in lots of languages do so!

I have to say I think Ovid's example is a good one. I recently had to debug a bit of VB code that was giving unpredictable results - It was supposed to check the date of a remote file and update the local file if it was out of date. This worked most of the time, but some users in some locations reported that they sometimes could not see updates at the beginning of the month.

It turned out that one of the dates was using the machine locale and the other was using the US date format. Now this is a bug and clearly should not work if you are on a european locale. But VB in its infinite wisdom was not raising an error or even reporting a warning when given a US date of 13/5/2001 - it just tried out all the other date formats in the locales table until it worked!

This is unpredictable because it depended on when the remote file was updated, when the local user last got a copy of it, whether they noticed it was out of date and whether it is currently the end of the month. This is not DWIM! A bug like this needs to be known about ASAP, not a year down the line (I wasn't the first to look for the cause of the bug!)

The difference between a feature like this and Perl's undocumented DWIMs is the intelligence of the designer: the VB feature was never thought through: the code doesn't change but as you go through the month whether it is right or wrong does change.

-- iakobski

[reply]