tinman wrote:

please do understand that I have nothing but respect for you, and this is in no way meant to be anything like a personal attack :o)

tinman: no need to explain. Reasonable people can disagree and I have absolutely no issue with that. I gave your post a ++ because it was well thought out.

I think I could almost agree with you if MS gave the programmers the option to suppress these features. If I want to send my HTML docs with a content-type of "text/plain" and not have them rendered as HTML, I should be able to do that.

It used to bug me about Netscape that it wouldn't render a table that was missing a closing table tag. Now, however, I'm happy about that. How many designers out there are producing better tables because of that? Browsers have, for a long time, been very forgiving about bad HTML. What does that do? It encourages bad HTML. I don't claim to write perfect, W3 specs HTML, but I'm not bad. When I first started, however, my HTML was a mess. I didn't know it, though, browsers were so nice to me. Now I struggle to unlearn bad habits.

MS, by trying to second-guess programmers has allowed them to focus on quantity, not quality. Perl, on the other hand, while it definitely has a DWIM attitude, it's fairly well documented and predictable. Here are some examples that will definitely trip up new programmers, but once you understand what's going on, you can produce code that does what you intend without tripping up (those on the beginners-cgi mailing list will recognize this from today's emails):

my $number_of_pets = ('dog','cat','iguana');
print $number_of_pets;

my @pets = ('dog','cat','iguana');
$number_of_pets = @pets;
print $number_of_pets;

$number_of_pets = ('dog','cat',@pets);
print $number_of_pets;

@number_of_pets = ('dog','cat',@pets);
print scalar @number_of_pets;
[download]

All of those examples will generate consistent, reproducible results, even though the results will be strange to some. VBScript's date functions, by contrast, will have unpredictable results depening upon your data and your locale. This is not good. I don't mind DWIM, so long as it's predictable. I can't get that with MS. As a result, many MS programmers just kind of 'slide by' and hope things work. That's what I object to.

Cheers,
Ovid

Update: Hmm... twice in as many days, Abigail has come behind me and pointed out flaws in my logic. I am unused to Perl having locale dependant functions (since I've only used it in the US). On the other hand, since I programmed in VBScript in Amsterdam, locale was a much more serious issue. That's US-centric thinking for you.

That being said, there's still the issue of VBScript silently switching the month and day if it thinks the programmer screwed up. Ditto for IE ignoring the content-type header. I am not aware of any cases where Perl munges your data without your knowledge.

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

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

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