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.
 
Published 30 November 04 10:12 by GarethJ
Filed under:

Comments

# Mark Mullin said on November 30, 2004 9:29 PM:
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.
# GarethJ said on November 30, 2004 9:42 PM:
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
# Aali's blog said on December 7, 2004 2:56 PM:
# Aali's blog said on December 7, 2004 3:02 PM:
# GarethJ s WebLog Language oriented or Metadata driven | Outdoor Ceiling Fans said on June 2, 2009 1:31 PM:

PingBack from http://outdoorceilingfansite.info/story.php?id=59977

# GarethJ s WebLog Language oriented or Metadata driven | Toe Nail Fungus said on June 13, 2009 7:38 AM:

PingBack from http://toenailfungusite.info/story.php?id=8785

New Comments to this post are disabled

Search

This Blog

Disclaimer
The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.
All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

Tags

Archives

Architects who Model

DSL Tools Team

Links

Syndication

Page view tracker