Language-oriented or Metadata-driven?

Sergey Dmitriev has a great article on what he, and others, have called Language Oriented Programming.  Go read it, it’s a great piece.  As we’re heavily engaged in building Domain Specific Language tools at present we’re obviously swimming in the same sea.  However, I’m keen to look at LOP and DSLs as only one aspect of the bigger picture – I’m especially reticent to attach too strongly to any meme that appears to put the focus solely on programming.

Enterprise system development these days has almost as much emphasis on configuration of middleware and packages, specification of deployment options and physical rig topologies.  It is also hugely influenced by the need to meet non-functional requirements, a subject on which programming languages have typically had remarkably little to say.  This is a major reason why UML isn’t the whole answer.
What seems to be needed is a consistent metadata substrate encompassing all of these things.  Then tooling and transformations can readily be used to link together different islands within the substrate, validate consistency, manage dependencies etc.  Clearly all of the components of a heterogeneous system aren’t going to use the same technology to manage their metadata anytime soon, so good adapters are necessary to make various stores available.
However, this huge sea of metadata is intimidating and full of detail.  I see Languages as a vital enabling technology here to help abstract this problem into something that humans can manage more reliably.  Languages will drive the generation of custom application code.  Languages will configure middleware.  Languages will allow specification of performance requirements.  Crucially, statements in the same language will bridge all, allowing the human who knows they want a new Database to specify that intent.  A different human will have codified what detailed information is needed to populate the islands of metadata and what supporting frameworks are required to make the right things happen at deployment time, at application run time, at monitoring time or any other part of the lifecycle.
Gradually we’ll grok this approach for abstracting and coordinating the complexities of our horizontal technologies and move on into the realms of our vertical domains – then we’ll really be getting towards our Software Factories vision.

Comments (6)

  1. Mark Mullin says:

    Hmmm – this is old hat, after a fashion – it’s fundamentally related to Kurt Godel’s work – a common form of this complaint is ‘if all you have is a hammer, then everything looks like a nail’

    This is one space where I’d give .net a great deal of credit. I develop several mixed language applications using .net/windows as the fundamental platform – screaming fast graphics/math in C++, all the UI and communications in C#, and P# (a .net prolog) for a lot of the business rules and decision trees)

    And thats the rub I see – the ability to create variant procedural languages is certainly beneficial, but not all problems are best solved procedurally – it was the example of a ‘collections’ language at the end that got my attention, thats an issue often much better addressed by declarative languages like Prolog than by procedural languages

    I’d agree with your comments on metadata, but I’d also observe that language isn’t so much the issue as ‘mechanism’. If I’m doing a ui my mechanism is fundamentally an asyncronous event system (procedural languages cause you to get all bloated with one line functions), if I’m doing calculations my mechanism is functional, and if I’m trying to determine the truth or falsity of a combination of metadata/data then my mechanism is declarative.

  2. GarethJ says:

    I don’t see a reason why DSLs that provide functionality have to be procedural. I can quite happily see one of our DSLs being used to generate onto a functional layer or a mixture. I think that’s really one of the beauties of not being an embedded macro approach (as some of the Lisp diehards seem to be keen on) – there’s really no forced connections in technology choice between a higher abstraction language, a transformation language and a lower abstraction language – the metadata (and .Net APIs to access it) is the only common denominator.

    I can imagine some formulaeic (sp?) DSL being translated via a C# based translator into Prolog quite happily