Tim Bray: Languages Cost

Tim Bray writes about custom document schemas:


HTML isn’t unusual. Documents are hard to design, and general frameworks for families of documents are even harder. The conventional wisdom back in the day was that to get yourself a good DTD designed, you were looking at several tens of thousands of dollars.

Then, once you’ve got your language designed, you start the hard work on the software. Frameworks like XSLT help, but no significant language comes without a significant cost in software design.

As I've often said here ("here" in the general sense that is), XML vocabulary design is language design. Language design is hard. Hard things often cost.

However, Tim wants us to believe that one language is enough. I really hope he is wrong about that...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Tim Bray: Languages Cost

Ehud:
Tim wants us to believe that one language is enough. I really hope he is wrong about that...

Central to Tim Bray's argument is the point that the languages that define documents correspond to authoring environments. That's not so true of the correspondence between programming languages and programming environments.

This could be due to the number of people or the nature of the people doing authoring vs. programming. Actually, I think the two effects to hand in hand. Fewer people programming means that the available tools put less effort into creating their own environment, so that programmers often must be able to live with the languages themselves.

Well..

I am not sure I agree with the emphasis on authoring environment even when applied to documents. Tools are important, but they are no substitute for epxressive semantics.

Now, obviously Tim knows this seeing as he worked on SGML way back then.

More

Jon Udell talks about the importance of this issue.

Schemas vs. Programming Languages

What Tim is focusing on is interoperability. It's not so much that he's espousing one language, just not the complexification that comes with everyone defining their own language from scratch (and doing it poorly). We've seen this mess before. It's called the 1960s.

Today, we don't have one programming language, but we have a few major contenders. If you want to get an idea across, there are a handful of languages at your disposal -- C, Java, Lisp, etc. There's still room to experiment and innovate in the fringes, or create "enterprise grade schemas" for very targeted applications. But creating a language is a huge amount of effort -- both in terms of XML vocabularies and programming languages -- and quite easy to do poorly.

I think the world Tim is cautioning us against is one much like the 1960s, where every application is written in a different language that is subtly or deeply incompatible with every other language in contemporary usage.

By starting with one, universally supported language (e.g. C or XHTML), we can accomplish a whole lot more together than if we all spoke different languages. Furthermore, the transition from one to two to five languages is much easier than the transition from 1,000,000 down to 100,000 down to 10,000.