This lead to the development of the first generation of WYSIWYG tools that did produce bad layout as well. These became popular, so the second generation of browsers decided to make sure that they could accept those. Begin vicious cycle.

Nowadays, we're still stuck in the HTML problem, and I don't think that will ever be cured. But for so-called web application or interprocess communications, we have XML. There is *no* reason not to be able to write valid XML given the large number of tools, free, commercial, compiled, interpreted, or otherwise, out there; nor is there any reason not to read in only strict XML. However, the advantage of XML as a format is that one can include excess or alternative data to the format, which client A might not completely understand but can still produce an intended result, while client B can take advantage of. But the key point here is that the XML *must* be well-formed. If one gets bad XML, what should the error be the user? Hopefully, those that have worked with HTML over the years understand that malformed XML is potentally more dangerous than malformed HTML, and will take steps to tell the user of such.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

The web browser is an excellent example; the problem started, however, before NS was even NS -- the initial versions of Mosiac offered no clues to the user that the web page was malformed, and that trend has continued since. Is this necessarily a good idea? It's a big if, of course, but I would suspect that if my browser told me every time I encounted a page that didn't meet W3C standards, I'd be very very tired of getting that warning nearly all the time. From a UI stand-point, some would argue that not informing the user of a bad layout in a web page is a good thing (You should only tell the user that there's a serious error if they are supposed to take action to do something about it). But here, the problem was that there was no way of using the browser alone to determine bad makeup.

I wouldn't want the browser to pop up with a big freaky modal dialog every time I loaded a page with somewhat suspect HTML, but I would like to see some indication that the page isn't well-formed -- perhaps a message in the ubiquitous status bar to the effect of "This page is not valid HTML, and may not be displayed properly". As a user, I'd like to be told if the page I'm looking at is garbled (often one can tell immediately if a page hasn't rendered the way the designer would have liked, but I think it's reasonable to believe that some pages would be mis-rendered with subtle, important errors), and as a developer I'd sure like to know. (Of course, as a developer, I have plenty of HTML validators at my fingertips.)

And bringing this back on topic... this point generalizes fairly well to programming in general. That's why compilers have warnings as well as error messages. I see no reason why all programs, especially those that talk to people, should insist on conservatively correct input. If you get suspicious input, emit a warning and do the best you can. That way, if you're relying on vaguely bogus input from someone else's software (for instance), you can still get work done. The difference between this model and the web browser problem is that Our Favourite Web Browsers(tm) don't give any (easily accessible) warnings about malformed HTML, so Joe Luser has no idea that they've just written awful markup.

That said, within your own code strict adherance to contracts (for instance) is an excellent idea. If you're generating bogus data, you're going to want to know about it, not fudge it and hope for the best, and it's much more difficult to ignore a confess than a carp.

--
:wq

I would like to see some indication that the page isn't well-formed

Yes, and iCab does that, by putting a little smiley-face/frowny-face icon on the location panel. Of course, it's always frownyface on PerlMonks, so you can press it to get the errors. Here are the errors for this page as I type this:

http://www.perlmonks.org/index.pl?title=%28FoxUni%29%20Re%282%29%3A%20
+Larry%20vs.%20Joel%20vs.%20Ovid%20vs.%20Masem%20vs.%20Web%20browsers&
+parent=126653&lastnode_id=126653&node=Offer%20your%20reply&parent_nod
+e=126653
Altogether 79 errors found. Only  25 errors are listed below.
Error (9/4): The tag <layer> is not part of HTML 4.0.
Error (9/93): The end tag </layer> is not part of HTML. 
Warning (9/162): In the tag <TD> the attribute "WIDTH" should only con
+tain absolute pixel values.
Error (9/285): In the tag <IFRAME> the attribute "FRAMESPACING" is not
+ allowed.
Warning (9/606): In the tag <TD> the attribute "WIDTH" should only con
+tain absolute pixel values.
Warning (9/665): In the tag <TD> the value of the attribute "WIDTH" mu
+st be enclosed in quotes.
Warning (9/665): In the tag <TD> the attribute "WIDTH" should only con
+tain absolute pixel values.
Error (10/166): In the tag <INPUT> the attribute "BORDER" is not allow
+ed.
Warning (16/106): The tag <FONT> should no longer be used since HTML 4
+.0.
Error (16/120): The character '&' must be written as '&amp;'. 
Error (16/120): The character '&' must be written as '&amp;'. 
Error (16/200): The character '&' must be written as '&amp;'. 
Error (16/263): The character '&' must be written as '&amp;'. 
Error (16/1175): The character '&' must be written as '&amp;'. 
Warning (21/1): The tag <CENTER> should no longer be used since HTML 4
+.0.
Warning (24/3): In the tag <TD> the attribute "WIDTH" should only cont
+ain absolute pixel values.
Error (27/78): The character '&' must be written as '&amp;'. 
Warning (84/3): In the tag <TD> the attribute "WIDTH" should only cont
+ain absolute pixel values.
Error (85/32): The color name "eedddd" is not valid. 
Error (86/1): In the tag <TR> white space is missing as separator afte
+r the attribute "BGCOLOR". 
Error (86/1): In the tag <TR> the value of attribute "BGCOLOR" is miss
+ing. 
Error (86/1): The attribute "000000" is not part of HTML. 
Error (86/1): In the tag <TR> the value of attribute "" is missing. 
Warning (88/8): The tag <FONT> should no longer be used since HTML 4.0
+.
Warning (95/4): The tag <FONT> should no longer be used since HTML 4.0
+.
Error (102/1): In the tag <TR> white space is missing as separator aft
+er the attribute "BGCOLOR". 
Error (102/1): In the tag <TR> the value of attribute "BGCOLOR" is mis
+sing. 
Error (102/1): The attribute "000000" is not part of HTML. 
Error (102/1): In the tag <TR> the value of attribute "" is missing. 
Warning (104/8): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (111/4): The tag <FONT> should no longer be used since HTML 4.
+0.
Error (112/13): The character '&' must be written as '&amp;'. 
Warning (112/79): The tag <FONT> should no longer be used since HTML 4
+.0.
Warning (113/1): The tag <FONT> should no longer be used since HTML 4.
+0.
Error (114/286): The character '&' must be written as '&amp;'. 
Error (121/1): In the tag <TR> white space is missing as separator aft
+er the attribute "BGCOLOR". 
Error (121/1): In the tag <TR> the value of attribute "BGCOLOR" is mis
+sing. 
Error (121/1): The attribute "000000" is not part of HTML. 
Error (121/1): In the tag <TR> the value of attribute "" is missing. 
Warning (123/8): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (133/1): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (135/254): The tag <FONT> should no longer be used since HTML 
+4.0.
Warning (135/1488): The tag <FONT> should no longer be used since HTML
+ 4.0.
Warning (147/8): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (154/4): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (164/8): The tag <FONT> should no longer be used since HTML 4.
+0.
Warning (168/31): The tag <FONT> should no longer be used since HTML 4
+.0.
Warning (168/148): The tag <FONT> should no longer be used since HTML 
+4.0.
Warning (168/277): The tag <FONT> should no longer be used since HTML 
+4.0.
Warning (168/438): The tag <FONT> should no longer be used since HTML 
+4.0.
[download]

I'm still trying to work with the Everything-engine people to get them to put the right ampersand escaping in URLs. Most of the rest of that goes away if you start using CSS instead of explicit tags. But there's still the odd things, like unquoted parameters, for which all we can say is "sloppy coding, please fix up!".

-- Randal L. Schwartz, Perl hacker

I was going to comment on this to tye's post, but it's just as valid here.

"What if" Mosaic 0.9 had a pop up dialog that warned of invalid HTML, from day one? Where would we be now? Let me extrapolate:

Since it would be expected that web page designers would check their own pages using the first generation browsers, they would early on discover their page errors and fix them. The typical end user would have never seen these errors save from sloppy HTML writers that didn't test.

When the first generation HTML editors would be introduced, they would be careful to make sure that they produced clean, valid HTML code as to make less work on the end writer to clean up this code before it was put on the web.

From that point on, you'd get the same circle of dependacy as we had in reality, but this time with adherence on strictness. All HTML that would be published today, save by those that lack any QA, would be clean and well-formed...

...however, there is the Microsoft factor to consider here. It can be easily suggested that MS would have been to first to disable this pop up dialog to an option that could be turned off after the first instance, or disabled it completely. The implications of this are hard to determine; it could have speed up their 'domination' of the web by offering a solution that allowed 'bad' code through mostly unnoticably, or it could have caused them to be shuned by the community for trying to hide bad code. But once someone did that, others would have followed, and we might be back exactly where we are today, save for the lack of some HTML atrocities like BLINK and FRAME.

In the today of this history, we would have never accepted that pop-up message during causal browsing, but if history was slightly different, we may have been upset to not find it there when it was needed.

That's why I refer to the strength of XML; we as a collective computer community are not simply looking at XML as tag soup as HTML was originally, but as a well-structured document in terms of opening and closing tags with attributes. Assuming that you can properly write out this format (which is easy) and read in this format without accepting flaws (difficult, but people have put solutions in place for this already, no need to reinvent said wheel), then the rest of XML which allows for free format of data items is in place. And people do realize that, and are making sure that while they may be sending XML documents that have extra or lacking data, the XML is well formed and does not fail in parsing. This is a very good first step in more adaptable and usable data formats.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

What Larry stated is a commonsense and correct rule. A given program will be most effective in communicating if it is generous in what it accepts and strict in what it emits. You may prefer Netscape's breaking on certain constructs. But no matter what you prefer, it is a fact that Internet Explorer is better at communicating than Netscape is. Because it is more generous in what it accepts, and goes out of its way in what it emits to do things like work around broken browser version checks.

What you and Joel are saying is that communicating well is not always wanted! If I have barely learned another language, when I try to communicate I darned well want to deal with someone who will hear through my accent, mangled grammar, and know to point me to the bathroom now. If I am trying to learn how to be understood, I want that person to point out my mistakes, correct me, and be very strict in what they call acceptable.

So Larry is right. Browsers are great communicators. They bend over backwards to communicate. And that fact helped millions of novices, who are scared of their computers, to reach out and successfully communicate with each other. Had HTML been strict by default, I strongly doubt that that would have happened.

In so far as Joel is talking about something different than what Larry is, he is also right. Having all of these great communicating programs around has spoiled people. They succeed in communicating with the most popular browsers even though they are communicating really badly, and so have learned to be bad communicators. A world full of bad communicators is hard to understand.

But as long as Joel is talking about what Larry is, he is just plain and simply wrong. A program that refuses to implement simple workarounds for mistakes that you know are out there is worse at communicating. Period. There are cases where it fails to communicate, even though communication is demonstrably possible. Whether or not improving your program's ability to communicate leads to better communication is a different issue. There are tradeoffs both ways. And certainly if you are developing software, it is best to find out errors as quickly as possible. (Which is why I explicitly tell Perl with strict.pm to not try to be generous in figuring out what I meant to say...)

And IMO criticizing Larry Wall for a point he didn't make is just plain unfair.

tilly wrote:

And IMO criticizing Larry Wall for a point he didn't make is just plain unfair.

Mea Culpa :( I realize now that the root post came across differently from my intentions. I think Larry has an excellent idea. I just don't think most people (and that includes myself) have the skill to implement it.

I think, though, that your 'bathroom' analogy illustrates the difference between humans and computer (and demonstrates the breakdown of the analogy). A human is much better at interpreting meaning than a computer, but we still get things wrong. If I say "I want to hit the man with the shoe", technically, that means "There is a man with a shoe and I want to hit him." Many people, though, would incorrectly interpret this as "I have a shoe and I want to hit the man with it." That's what I mean when I think that people are often bad at liberally accepting input.

Now, if I feed that same sentence in a computer that has algorithms to understand English grammar, it may parse the grammar correctly, but get my intent wrong if I really did mean that I have a shoe that I want to hit someone with. How can a computer determine intent if the sentence fits the grammatical rules but doesn't mean what I meant? The more liberal we get, the more we open the room for ambiguity. The more paths a program can take to get to a solution, the more paths there are for bugs.

This is all about finding a good middle ground. That's tough to do.

Cheers,
Ovid

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

Hm. It's possible we interpret Larry's comment differently. Here's how I paraphrase it: "Forgive liberally; act responsibly. Communicate!"

I base that on a larger reading of the quote in question:

Of course, in Perl culture, almost nothing is prohibited. My feeling is that the rest of the world already has plenty of perfectly good prohibitions, so why invent more? That applies not just to programming, but also to interpersonal relationships, by the way. I have upon more than one occasion been requested to eject someone from the Perl community, generally for being offensive in some fashion or other. So far I have consistently refused. I believe this is the right policy. At least, it's worked so far, on a practical level. Either the offensive person has left eventually of their own accord, or they've settled down and learned to deal with others more constructively. It's odd. People understand instinctively that the best way for computer programs to communicate with each other is for each of the them to be strict in what they emit, and liberal in what they accept. The odd thing is that people themselves are not willing to be strict in how they speak and liberal in how they listen. You'd think that would also be obvious. Instead, we're taught to express ourselves.

I think my paraphrase fits the original context of this and other remarks by Larry.

It also suggests, I think, a rather simple solution to the "HTML problem." If browsers implemented a small indicator (or a toolbar button) that changed state when faced with malformed HTML (CSS, XML, or whatever), the person browsing the content could trigger a report of the problems. Something like this would be nice:

Missing </TABLE> tag.
Image (filename.gif) appears to be a JPG file.
<B> tags are deprecated, use CSS formatting instead.
Etc...
[download]

(It would be even nicer if the report could then be emailed to someone, such as the contact person of the site in question.)

Update for no_slogan: OTOH, it just might be impetus to fix the problems, donch'a think? Still, I was thinking of the idea for the people designing the site, then previewing the results. Given that, we could dispense with the email thing...just so long as the report is easily saveable to text.

This approach handles the problems that tye wants to prevent, provides an active solution, and lends itself to handling other problems that you (and Joel) mentioned. Consider:

• When provided different interfaces, choose the one that best fits the specific context.

  If none exists, then write wrappers to convert what you have to what you need...and then alert the author/maintainer to the discrepancy.

• When presented with incomplete (or incorrect) input, recover if you can or fail if you can't.

  If you fail, however, provide clear and easy-to-access information describing the failure and the solution to the problem.

• Instead of changing the behavior of existing interfaces quietly, document those changes as clearly and broadly as possible or (preferably) create a new interface that offers the new behavior while calling the original. This lets you deprecate the original behavior while allowing existing code to run until it can be refit.

• Instead of creating user-hostile tools that throw preferences, character sets, locale issues, and other problems commonly associated with international programming, create software tools that make it easy for the casual or untrained developer to deal with these and other common problems. IOW, make your libraries, modules, tools, componenets, and so forth as aware--and extensible--as possible. (While I agree with the basic sentiment that Joel was ranting about, I disagree with his conclusion. I prefer to test things heavily.)

  Similarly, provide ways to test for commonly encountered problems and specific information on resolving them. Don't force everyone else to claw their way up the same learning cliff that you had to.

• Given a specification (or contract, if you will) that doesn't specify what happens in a corner case, get that clarified by the contract sponsors. This would have been reasonably easy for the Netscape team to have done at the time and would have prevented, I think, a lot of the grief we're dealing with today.

• When encountering code that erroneously relies on undocumented behavior, shouldn't you simply treat it as a bug and fix it, rather than blaming someone else for the problem? (It's not Larry's fault that some 'softie changed a Windows API call. Nor is it his fault that one of your guys relied on undocumented behavior.)

• When you find a bug, fix it. (That's also part of the contract.) This includes legacy bugs, such as CSS Level 1 support (or lack thereof).

• When faced with tools that do not satisfy their contracts, contact the responsible parties and see if they'll fix the problems. If they don't, then either find a workaround or use different tools. Period. Life's too short to worry about broken promises.

I do agree that Design By Contract is a Very Good Thing^®; however, part of the contract is letting others know when the contract has been broken. (For more on the subject, I highly recommend The Pragmatic Programmer, which devotes a major section to the subject and also provides an interesting variation of Larry's comment.)

In short, I think Larry's spot on with his comment. We should forgive liberally, act responsibly, *and* communicate...just be nice about it. (Remember the last rule of perlstyle.)

Just because we're not good at something doesn't mean we should stop trying to practice it. There is, after all, only one way to get to Carnegie Hall.

--f

It would be even nicer if the report could then be emailed to someone, such as the contact person of the site in question.

This isn't going to scale for busy web sites. I doubt if the contact person (or the mail system administrator) is going to be happy when he comes in to work one morning and finds a couple of hundred thousand e-mails all saying, "your html is broken!"

Imagine working on a huge system where you have many virtually identical object methods that take a scalar, or an array, or an array ref, or a hash_ref using named parameters but won't accept a hash, etc. What interface do you use? And what if the data structure returned seems to be arbitrary? I've worked on systems that do that and they are Not Fun.

If the data structure returned is arbitrary, then the system is not being strict in what it emits. That's not the side of the contract that you're discussing.

With your IE example, it sounds like they're going too far in being liberal. If there was no MIME type given, or it was one the browser didn't understand, guessing the type from the content would seem reasonable. But ignoring a valid MIME type is just too much.

In your post, you confuse "being liberal" with "not being explicit". You can be liberal, but explicit if you put enough intelligence in the explicit description.

E.g., COBOL is a very non-liberal language, while ANSI C is a fairly liberal language in comparison, while still being perfectly explicit about what it will accept. Or take JCL, the job command language on most mainframes, and compare it with the POSIX standard "sh" shell implementation. Both are explicit, but the "sh" shell is much more liberal in what it accepts.

If talking about languages, being liberal while being strict is often called "expressive".

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

The Oak and the Reed from Aesop's Fables

     The Oak spoke one day to the Reed
     "You have good reason to complain;
     A Wren for you is a load indeed;
     The smallest wind bends you in twain.
     You are forced to bend your head;
     While my crown faces the plains
     And not content to block the sun
     Braves the efforts of the rains.
     What for you is a North Wind is for me but a zephyr.
     Were you to grow within my shade
     Which covers the whole neighbourhood
     You'd have no reason to be afraid
     For I would keep you from the storm.
     Instead you usually grow
     In places humid, where the winds doth blow.
     Nature to thee hath been unkind."
     "Your compassion", replied the Reed
     "Shows a noble character indeed;
     But do not worry: the winds for me
     Are much less dangerous than for thee;
     I bend, not break.  You have 'til now
     Resisted their great force unbowed,
     But beware.
     As he said these very words
     A violent angry storm arose.
     The tree held strong; the Reed he bent.
     The wind redoubled and did not relent,
     Until finally it uprooted the poor Oak
     Whose head had been in the heavens
     And roots among the dead folk.

Explicitly in reply to the UPDATE.

--
perl -p -e "s/(?:\w);([st])/'\$1/mg"

However, what do you propose? You're saying that the paradigm by which a (seemingly) large number of prominent applications do their business is flawed. Yet, you give no possible counter-solution.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Well, of course I do, silly :) Be strict in what you emit and accept. Masem made clearer the browser problem. If it was agreed from day one that Web browsers weren't going to put up with sloppy HTML, then we wouldn't have the mess we have today. XHTML is a great idea which might get around this, but HTML is pretty lousy.

In general programming terms, this means laying out clear standards with a very narrow interpretation. Oh, you can interpret your client's needs all you want and you should do your best to meet them, but give them 27 ways to solve the same problem and they are going to find bugs in your code. Give them one way and and you're much happier. But make sure you solve their problem.

That's not to say that you shouldn't have multiple methods of dealing with a programming problem. It's saying that you really, really need to look at the problem carefully and determine if those multiple methods are appropriate. On Windows, you can copy selected text with File->Copy, Cntl-C, or a right click to pull up a context menu. That seems fine because different people have different methods of learning and it's appropriate to cater to those. Internally, however, they had all better call one copy routine with identical data formats.

Now, how can you guarantee that all of those methods of copying text, images, or whatever are going to do exactly what you want? That's the tough part. Frankly, nothing irritates me more than copying text from a Web page, pasting it into an email and seeing a frickin' radio button show up. That even happens when I'm sending the email in PLAIN TEXT!!! That ain't a feature, in my book. But that's the result of being liberal in what to accept. How can you be strict in what you emit if you aren't sure at any given moment what you've accepted?

There's a time and place to be liberal in what to accept, but very few get it right. It's a good theory that most should put on an ivory tower and leave there. The more complex the system, the less likely that such "liberality", if you will, is going to please every one. If you're writing a mass-market tool like an OS, maybe this is necessary. If you're writing a financial application, do you want to be responsible for explaining to the client that they "misplaced" $30,000 because you were liberal with their Accounts Receivable? :)

Cheers,
Ovid

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

If it was agreed from day one that Web browsers weren't going to put up with sloppy HTML, then we wouldn't have the mess we have today.

And we might not have the popularity of the web we have today. Graceful failure is a good idea. Under your scheme all of the poor surfers of the world would be getting lots of errors from their browsers when those surfers have no control (and virtually no influence) over getting those errors fixed and many of them would have no idea what those errors mean.

The fact is that many decided to take advantage of one half of a sound principle by completely ignoring the other half of the principle. And only having one half of that principle is certainly not a good idea.

But putting the error checking and enforcement into a web browser client is a really bad idea. Error checking and enforcement needs to be as early in the process as possible. A much better idea would be to fix web servers so that they refuse to emit bad HTML rather than "fix" web browsers so that they refuse to display bad HTML!

It is a good idea to be at least somewhat lenient in what you accept. It is also a good idea to note cases where you were lenient in such a way that this information is likely to make its way back to the source. That back channel is often quite difficult to implement well. But a really horrible idea for such an implementation would be browsers giving errors to web surfers.

Now, being vague about what you accept is a bad idea. That is why the two halves need to go together. In order to be strict about what you provide, you have to define things clearly. Without that side of the coin, just being liberal about what you accept is trying to DWIM, which is (often) a nice feature of Perl but is usually a bad idea in any software that isn't interacting directly with a human.

And do you want to be responsible for explaining to the client that the $30,000 transaction couldn't go through because something changed how much whitespace is sent?

You can go too far in either direction. The idea of the principle is to prevent you from going too far in one direction. You are (in part) complaining about people going too far in the other.

But the complaint about browsers being too lenient is a bad form of wishful thinking. No one will ever produce a browser that is not lenient in what it accepts -- well, if they do, it won't get used much. Now a browser that tells you that it had to be lenient has its advantages, all of which are of no use (and some distraction) to the average web surfer and so will never become widely popular. And having some magical control to force all browsers to not be lenient or to at least complain loudly when they are force to be is, in fact, a very bad idea, unless you also design a way for those browsers to direct their loud complaints back at the authors of the bad HTML.

Go design that back channel first and then you can think about tilting against the "bad, lenient browser" windmill again.

        - tye (but my friends call me "Tye")

IE's being mistrusting of the webserver, rightfully so. But then it hides that fact, not letting programmers know about it. Naughty IE!

--
$Stalag99{"URL"}="http://stalag99.keenspace.com";

I have to pick you up, though, when you say that W3C standards are, in effect, a variant of Design by Contract. You know what you have to send and, in return, you know exactly what to expect. I don't think that this is true.

Going back to the first HTML rfc (#1866) (and this is historic-interest-only) we see the usual RFC-style vocabulary:

Here's part of the glossary:

    should
            If a document or user agent conflicts with this
            statement, undesirable results may occur in practice
            even though it conforms to this specification.
[download]

To me this seems fairly widely divorced from the idea of 'Design by Contract'. Far from knowing what to send, and knowing what to expect back, it's more like knowing what you could send and what you might receive.

The existing (stricter) standards have evolved from this permissive base - I wonder how much this permissiveness drove their widespread adoption?

andy.

Of course, in Perl culture, almost nothing is prohibited. My feeling is that the rest of the world already has plenty of perfectly good prohibitions, so why invent more? That applies not just to programming, but also to interpersonal relationships, by the way. I have upon more than one occasion been requested to eject someone from the Perl community, generally for being offensive in some fashion or other. So far I have consistently refused. I believe this is the right policy. At least, it's worked so far, on a practical level. Either the offensive person has left eventually of their own accord, or they've settled down and learned to deal with others more constructively. It's odd. People understand instinctively that the best way for computer programs to communicate with each other is for each of the them to be strict in what they emit, and liberal in what they accept. The odd thing is that people themselves are not willing to be strict in how they speak, and liberal in how they listen. You'd think that would also be obvious. Instead, we're taught to express ourselves.

Bleaoghgh%$%$#@!!!

You may feel much better afterwards, but consider the poor guy next to you with the ruptured eardrum. Ruptured eardrums should be prohibited.

On the other hand, we try to encourage certain virtues in the Perl community. As the apostle Paul points out, nobody makes laws against love, joy, peace, patience, kindness, goodness, gentleness, meekness or self-control. So rather than concentrating on forbidding evil, let's concentrate on promoting good.

i think they're both right.

larry's point is quite valid when you're dealing with just two interacting components. particularly if one of those components is a human (you're asking for trouble if you give a human a text box for input and say something like "just don't put any semicolons in there or it will break things") or otherwise not under your control.

joel simply points out that it doesn't scale very well to systems of more than two components.

anders pearson

I had worked up a post on this same subject, but did not feel I had it shaped up enought for posting.

Anyway, do not forget Carp::Datum as this module also support design by contract but in a different way than Class::Contract