The Polyglot Programmer
In twenty five years of programming, I've used a couple of dozen programming languages -- perhaps ten or twelve to write serious programs. (I once counted at least ten languages as part of my work on Perl 6 and Parrot; generally two or three for most of my Parrot work.) I've also used at least that many markup languages for serious projects.
Good programmers seem to end up as polyglot programmers. The Pragmatic Programmers have long advised learning a new language every year. Not only does it stretch your mind to move to different syntax and paradigms, but it's a great way to see how idioms in different languages make certain problems easier and harder to solve.
The Language of the Domain
Lisp and Scheme and Smalltalk and Forth programmers all talk about building programs bottom-up, where in effect you create a vocabulary which describes the domain of the problem, then solve the problem by reusing that vocabulary. Though many developers are severely wrong about domain-specific languages, successful software often requires the use of language specific to the problem domain for the names of entities and APIs and other software artifacts.
In one sense, software development is sympathetic magic.
Unsympathetic and Cruel Science
Consider HTML. Consider CSS. They're declarative languages intended to describe semantic elements of a document. The lines get fuzzier when describing CSS, as the extensible nature of HTML and XML attributes allow some degree of customization to insert further semantic descriptions (see microformats) -- but make no mistake. These are languages designed to describe documents and styles. If your business is selling fire engines, you have to add the relevant domain concepts of a fire engine body, chassis, color, siren, model, and engine yourself.
That's not bad -- but likely you've already expressed these concepts in your business logic already.
That's three programming languages and at least two markup languages.
Complexity is a Pervasive and Subtle Trap
The HTTP model -- document-based distributed computing on a global scale -- offers tremendous benefits which overcome some of its limitations. In a similar way, the relational model confers many benefits for data storage and retrieval, especially when multiple applications share the same store. As well, one of the hardest-learned lessons of software development is that separation of concerns is more than a good idea. Business rules and presentation logic are different things.
Yet perhaps this separation has gone too far. Perhaps in trying to exploit the benefits of the HTTP/REST model, we've piled language upon language and paradigm atop paradigm, and the artificial complexity of the system grows and grows, until the mishmash between each layer of this rickety tower threatens to overwhelm our solutions.
I'm not arguing that we should all become monoglots again. To the contrary! I wonder, though. Is the current model of building web applications sufficiently simple, or is it holding back systems which would be better, more reliable, more robust, more correct, and easier to build and maintain?