in reply to Re^9: Perl 6 Module manager
in thread Perl 6 Module manager

I'm not sure that I buy the too complex argument. RTF is pretty well supported elsewhere and supports most of what word supports, except the bits that probably shouldn't be incorporated into a document format anyway, like some of the macro stuff which is just plain dangerous.

A little documentation goes a long way. If the word format(s) were documented, it would be possible for other programs to interoperate with them. But that takes will, and the vision to see that open formats generally benefit everyone, not just the originators. Proprietory formats are not illegal, or even immoral, just bad for business--for everyone, producers and consumers alike--but try convincing marketing types of that.

With the word format, I often think that the reluctance to document it is as much to do with embarrassment over some of the cruft that made it's way in there in the early years, and persists for compatibility, as any malevolance. The same applies in other areas also.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^11: Perl 6 Module manager
by BerntB (Deacon) on Apr 21, 2006 at 14:52 UTC
    (I do not want to talk about rtf. A long time ago, I tried to get different versions of Word to accept rtf from a generator I wrote. It might be better today.)

    With the word format, I often think that the reluctance to document it is as much to do with embarrassment over some of the cruft that made it's way in there in the early years
    Non-monopolies generally don't have trouble with integration. Microsoft could at any time publish internal documentation for the modern formats.

    It is a basic strategy of monopolies to avoid interoperability. Microsoft is an example, e.g. the problem with protocols for file servers are well known -- and is a part of the EU complaints, IIRC.

    I really don't understand how you can argue against this? It seems quite well documented, etc.

[reply]
      I really don't understand how you can argue against this?

      Actually, I think we are agreeing :)

      My point was that I don't think the complexity issue is the source of the problem with interoperability. It is the lack of documentation for that complexity, and the lack of the will to document it. It's just another form of the universal ill of protectionism.

      However, I don't think that protectionism through proprietary formats is the preserve of monopolies--though it is most effective and damaging there. For example, there is no monopoly in the RDBMS field, but the big four achieve a similar form of protectionism--usually termed 'lock-in'--through their proprietary extensions to the open standards.

      In part, this is the fault of the conservatism of the standards bodies that are generally reluctant to incorporate new features and extensions to the standards before some (nearly impossible) level of universal consensus is reached. This means that the standards usually lag the requirements and possibilities of the leading edge by 5 or 10 years. In doing so, it creates the possibility for each producer to provide for the shortfall in proprietary extensions that effectively lock-in all their users that need the features and make use of the extensions.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        Your point about the standard process was interesting. I haven't thought about it like that, but I think I buy your argument.

        It fits well with e.g. extensions to C/C++ compilers. Few would use vendor specific extensions (outside Windows) today for those languages, but (more than) a decade ago -- there might have been a case. For sql, vendor specific extensions might be a case today. And, as you write, the standardisation process have ground to cover there.

[reply]

In Section Meditations