Two recent, seemingly unrelated, posts got me to thinking about an issue that's been bugging me. I wanted to reply to them, but since both of them (in my mind) are related, here's a new node.

tilly recently made a post about Microsoft being against Perl. He mentioned how the license for beta 2 of Microsoft's Mobile Internet Toolkit lists Perl as a 'verboten' tool for development if you use their toolkit. This is part of a multi-pronged attack by MS to ensure that those lured to the dark side stay there. Some of the prongs are:

  1. Restrictive licenses, as above
  2. FUD
  3. Locking users into the MS world via
    1. coding practices (explained later)
    2. architecture (their Kerberos implementation, for example)

In another post, deprecated wrote about de-inventing the wheel:

If you want to say: 
    use CGI :standard;

    # instead of...

    use CGI qw{ :standard };

[download]
I hope your script DOES break,

I agree with him because I feel that it's not good to use features in a way that's been deprecated, undocumented, or ambiguous (well, that's not quite he was saying, but pretty darned close). Now the obvious question is "how the heck are those two related?" The answer lies in point 3.a above: bad coding practices.

For example, in recent versions of IE, you can send a .gif image with a content type of 'text/html' and it will still render correctly. That's because IE will attempt to figure out the content-type and correct it if you have messed up. Now this seems like a nice thing to do. However, what happens is that many developers only test on IE and their Web pages break when displayed in other browsers.

Another, insidious example, is VBScript's date functions. VBScript uses the computer's locale settings to determine the date format that it should be expecting.¹ If it thinks that dates should be in a mm/dd/yyyy format, it will interpret 01/13/2001 as Jan 13, 2001. All well and good, right? Not quite. If you have 13/01/2001 for your date, it realizes that 13 is too large for the month and silently switches the month and day positions, resulting in the same date. Is this what you intended? Maybe, maybe not. It does mean that a program which appears to run correctly (but probably doesn't), cannot be easily ported to other languages since VBScript silently fudges things behind the scenes.

With IE attempting to determine content-type and VBScript attempting to figure out what you really meant with the date, we have MS products that are trying to infer meaning from data. This is a Bad Thing. Even AI systems can't infer meaning, they simulate the inference. When deprecated wrote that he wants use CGI :standard;, I understand where he's coming from. If this is documented and predictable, that's okay, but if it's not, then we shouldn't do that.

The way we instantiate objects is another example:

use Object;
my $foo = new Object;  # Bad
my $bar = Object->new; # Good

[download]

In this example, the assignment to $foo is potentially bad. If you have a &new in your current namespace, you will be passing 'Object' to that function. Not good. This is one case where I disagree with Perl's DWIM attitude. We have the potential for subtle errors as a result. Of course, anyone who's tried to instantiate another object while in an object constructor named 'new' is likely aware of this.

From what I can see, Perl doesn't suffer from this too much, but MS products do. The downside of this is that developers who get used to MS's handholding are less likely to develop robust applications. When the software is second guessing the developer, the developer loses the fine-grained control that he or she will eventually need. In fact, I suspect that some of the sites out there that say 'IE Only' have that notice because of the enforced incompetence that can come from using MS tools.

Cheers,
Ovid

Update: For the curious, the way to deal with VBScript's date handling problems is to create dummy data sets and use them for the data source and then verify that the output is what it's supposed to be. Did the code catch all instances of reversed month and day that it should? Naturally, this should be done with any code, but is doubly-important with MS crud due to the behind-the-scenes data munging it does. I can't tell you the agony I've had to go through when VBScript has altered my data, despite there being no code that could create the alterations!

1. Of course, using your computer's locale settings means that the same program can produce different output on different machines depending upon locale. So much for portability.

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

Replies are listed 'Best First'.
Re: Microsoft vs. Perl and sloppy programming - Wildly OT
by tinman (Curate) on Jun 22, 2001 at 00:24 UTC

    As just a few counter points.. I agree with you on your general argument, Ovid, but I think that your examples don't really support the points you're trying to make.. (at least, to me, they do not)...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)

    Sure, MS software does things implicitly.. if a developer is fool enough to only test on IE (or any one browser), then they probably deserve to be flamed to a crisp by users of other browsers.. I doubt that there is *any* browser that is fully spec compliant on all the complexities that are involved in rendering content on the World Wide Web.. a weak sort of example would be CSS support.. but on the other hand, does IE make life easy for its users ? sure.. you can go to a site, even with broken HTML, and still have IE make a reasonable effort to render the page.. As a web designer, I would not want to see this happen, but from a users perspective, this is a good thing.. (non-techies just want to see the content, they don't care why it broke, they just want to see the cute web page)... MS puts usability as a high priority item, and even if its a bitter pill for me to swallow, I have to admit that their software is "usable" to a pretty low common denominator... argue as you will that this is a bad thing, but to me, reaching the masses and making software easy to use not only ensures that it is a good product, but that more peoples lives are enriched because they can use the software without a lot of bother.. My mom would probably be a good example for this one :o). But if MS doesn't do it the right way, but only in the wrong way, then everyone *does* need to complain, and complain loudly at that :o)(ie: if sending image/gif didn't display the GIF file properly)

    Perl has this attitude as well, as you've noted.. the "Do What I Mean" and not necessarily what I say slogan.. just recently, I discovered that heredoc behaviour that I had never known about... Perl just took care of the messy details for me, and I got the job done, none the wiser that Perl was actually done a bit of juggling behind the scenes for me..that is part of why I think Perl is so usable for beginners.. (you don't get this compiler warning that barks out "data type mismatch on line x, I'm not going to run this for you"), Perl just does the job.. Perl isn't really going to care if you take a char value and try to add a number to it, Perl will do what you want.. (or what it thinks you want).. :o)

    I would submit that if Perl were not as usable as it is, and if only stars like merlyn and Tom Christiansen and lots of monks in this site were the only ones who could actually get Perl to do cool stuff, I wouldn't be on Perlmonks right now.. I'd be pounding away at some other language, cursing at the carpal tunnel syndrome that results from typing in too much code... :o) :o).. so, in my view, the agenda that Larry Wall and Microsoft have are different.. Larry Wall (I think) wants the language to be used (even baby Perl), so does Microsoft.. but Microsoft has a profit motive, and that means that they couldn't care less about whether you become a better programmer later on or not... Larry, on the other hand, wants you to become better at Perl and a better programmer (speculation, but I suspect this to be true).. so do the monks here.. which is why -w and use strict are recommended for almost each and every post...

    The point of implicit conversions and the like is simply that you aim for the common sense case. I'd probably appreciate the date conversion in VBScript, if I screwed it up.. I'd also appreciate a (optional) polite warning. To me, that is control and power. What I've found is that with MS stuff, you get power, but you do not always get control. If it doesn't work the way you want it to, too bad, call tech support, and for a price, we'll tell ya... I see no difference in Perl, to be honest. Until someone posts code to Perlmonks, we don't know if that person is using strict or not. They could be people who write excellent programs, relying on lots of behind the scenes fiddling that Perl does (I didn't write excellent programs, but I wrote a lot of stuff that worked ok, even without -w or use strict. Now that I know better, I look at my old code and shudder...) They could be lucky (or lazy!)enough to have not encountered a situation where their code could break.. Whatever.. but being allowed to write sloppy code isn't a purely MS thing, and I can think of worse things to accuse MS of...What is important to me, mostly, is that I can get the job done, albeit somewhat imperfectly, really fast.. that *does* count for something..

    Disclaimer: Now, for the purposes of this posting, I forget all the reasons why I hate MS, so I am ignoring their deliberate attempts at a monopoly, their ranting, their FUD, all of that.. What I'm trying to say is that they build software that appeals to the masses, and that's not a bad thing

    Observation: I seem to be writing really long posts these days.. sheez. I need to cut back on the coffee or soemthing :o)

[reply]

      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.

[reply]
[d/l]
        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

[reply]
[d/l]
[select]
Re: Microsoft vs. Perl and sloppy programming - Wildly OT
by xphase_work (Pilgrim) on Jun 22, 2001 at 00:50 UTC
    I completely agree with you ovid. I feel that one of the main reasons why you find more code like this with MS products is their GUI's.

    Case 1:
    Visual Basic
    Many people who work with the Visual Basic IDE have absolutly no idea what it is doing for them. Many know nothing at all about programming languages, and many don't think that anyone would have a different setup then they have. So when an IDE does things without their knowledge, they don't care at all.

    I used to work at a campus computer lab at the University of Pittsburgh, and people would ask questions about why some piece of Visual Basic code wasn't working on the computers in the labs, when it worked on their personal PC. Having absolutely no knowledge of VB, I wan't much help.

    NOTE: I am aware that ovid was talking about VBScript, which is not Visual Basic, but the point is the same.Also, this only refers to the Visual Studio VB RAD IDE thingy, as that is the only thing I've seen used.

    Case 2:
    Front Page and IE
    My second issue is that large amounts of people use FrontPage, and FrontPage Express(what ever the version that ships with IE) to create web pages. The HTML generated via these programs is awful. Most of the time it will only render properly on IE, and sometimes it won't even render correctly on IE. It is very difficult to read, redundant, and does not conform to any HTML standard.

    An even worse crime then using FrontPage to develop HTML is using the Microsoft Office programs to develop it for you. Before looking at HTML generated by word, I'd never seen four identical font tags surrounding one word before.

    I also agree that with perl you can write poor and non-robust code with perl, but I think that by having(in most cases) to type the code yourself, and if you Use strict warnings and diagnostics or die like a good programmer, then your code turns out much better.

    -xPhase

    UPDATE: Fixed a spelling mistake, thanks to tadman

[reply]
Re: Microsoft vs. Perl and sloppy programming - Wildly OT
by sierrathedog04 (Hermit) on Jun 22, 2001 at 04:17 UTC
    Microsoft funds ActiveState's development of Perl for Win32. The president of ActiveState claims that his company is responsible for most of the development of new versions of Perl.

    Even if ActiveState's claim is overstated, it cannot be denied that the Win32 port of Perl helps the Perl language immensely, and that Microsoft foots the bill for it. Funding development of Perl is a strange way to try and kill it off.

    I say, let's be programmers, not conspiracy theorists. What good would killing Perl do Microsoft? Perl is not Java. It doesn't compete with C++ or even Visual Basic. It competes with Java and Unix shells.

    Now why would Microsoft want to kill it?

[reply]
      Perl played the role of poster child for the open source revolution quite well, thank you very much. Microsoft is now trying to come up with a coherent anti-opensource policy that doesn't involve developing, distributing, and supporting software at competitive (ie pretty low) profit margins.

      While Perl itself does Microsoft no harm, I could well understand some there seeing it as the thin edge of the wedge for open source solutions. After all in learning Perl you learn a good chunk of the essence of Unix. Plus you get exposed to radicals who honestly think it is OK to develop good software and just let people use it for free, which makes you more inclined to make decisions that avoid contributing to the Microsoft gravy train.

      Now assuredly this is stupid and counter-productive on technical grounds. I would be shocked and amazed if Microsoft didn't have people who really believed it was a Good Idea for Microsoft to support open source software. Including Perl.

      But it isn't that unreasonable for some of them to want to make sure that Perl is caught in the cross-fire. And judging from one EULA on one key product, that contingent may have more influence than I would like.

[reply]
        Even more OT - sorry

        Microsoft has supported competitors before, this was cited by MS during the anti-trust trials as an example of their benevolence. Cynics would claim it as MS having enough investment capital to burn that they can easily afford to spend $100m on PR exercises.

        Given the current MS attitudes, I think you're right - the anti open source faction has gained control, I don't expect their support for Activestate to continue.

        I suspect that currently MS is quietly confident that the anti-trust suit will be quashed by the Bush admin. So we can expect lots more aggressive moves like this - makes sense, open source is now their biggest competitor.

        Overall I'd say this will hurt Microsoft, more than it will hurt open source. It's harder to quash a community of individuals than it is a few shareholders and directors. Plus attacking open source will build up its credibility... at least they're not laughing at us any more.

        "The future will be better tomorrow."

[reply]
        Plus you get exposed to radicals who honestly think it is OK to develop good software and just let people use it for free, which makes you more inclined to make decisions that avoid contributing to the Microsoft gravy train.
        Isn't that what Microsoft itself did with Internet Explorer? They developed software that was better than the competition (Netscape) and they gave it away for free.

        It is ironic that one of the federal government's complaints against Microsoft was that it gave IE away for free and thus prevented its competitor Netscape from charging for an inferior product. Apparently, Microsoft is always wrong. It is wrong if it gives its stuff away (IE) when others charge, and it is wrong if it charges for its stuff (Windows) when others give it away.

[reply]
Re: Microsoft vs. Perl and sloppy programming - Wildly OT
by thraxil (Prior) on Jun 22, 2001 at 01:43 UTC
[reply]
Re: Microsoft vs. Perl and sloppy programming - Wildly OT
by InfiniteSilence (Curate) on Jun 22, 2001 at 23:31 UTC
    I used to be a big Microsoft only developer. It was a lot like having those blinders on that horses wear. You develop tunnel vision regarding new and different technology. The fact is that open source is far more responsive to client's needs than proprietary software. The advantage that large corporations have over open source developers is organization and money. Microsoft can allocate resources (human and financial) to beat anybody in the market. The DOJ has only slowed them down. But open source is different. You can't 'get' the open source market. It has too many heads and hands. It is too fluid. The distribution of Internet Explorer is not an example of open source. It is an example of the power of freeware. Freeware = Marketing. That's all. The free distribution of IE was a market technique to destroy a competitor in a market space that has only begun to realize its potential: the internet. Killing off the other babies in the womb is the natural behavior of a shark. Microsoft has learned this technique well. As the internet age emerges, they are prepared to dominate. Developers are among those at risk as Microsoft's sphere of influence increases. They will be enculturated in Microsoft philosophy and problem solving techniques. The history of computing will be replaced by the biography of Bill Gates. The way to keep your skills sharp is to keep your mind free of influences. Make your own decisions and participate in open source development initiatives actively. Let people know about open source and what you are doing and why. The more people who understand the difficulties of prospering in a monolithic computing culture the easier it will be to overcome the darkness before us.

    Celebrate Intellectual Diversity

[reply]

Back to Meditations