Structure, Properties, and Instructions

LOL Someone tell me if this has already been done. Every time I do this kind of right-brain drift, I glide into an area that was fully fleshed out 30 years ago.

In web development, there’s a neat model for separation of concerns that goes like:

  • HTML: provides structure of the page. i.e. the layout
  • CSS: provides the styling
  • XML: provides content

So, in a sophisticated web site, HTML defines the layout, CSS provides the look of the page, and XML pours the words in place. There are lots of ways to do that, whether you use server-side XSLT, client-side javascript, client-side XSLT, a templating language. There are lots of other possibilities. But it makes for a nice clean separation of concerns: structure, style, and content.

I’ve been jealous of that for a long time, and I wish I could do that in my programs.

Wait — I already do. When I build an application with Spring, I’m splitting out structure, properties and instructions into Spring config files, and dynamic Java files. Rather, I separate out static structures and properties into Spring configuration, while my Java code defines the dynamic parts of the program — the instructions.

It would be neat if there were an even cleaner separation. Like a language which is really three languages:

  • Declarative class definitions which define the structure of classes (class names, properties, and relationships). In addition, this declarative code would declare what classes are instantiated at application startup, and how they are wired together.
  • Declarative instance properties which define the properties of classes that are instantiated.
  • Imperative code that provides instructions for how class objects behave.

A while back, just for fun, I created a library called “Cascading Property Pages” which was a curly-bracket notation for attaching properties to objects. It cascaded, so you could composit property sets, and had a couple of different ways to attach a property page to an object through an object factory.

I think it would be fun to dust that off and tie it together with the notion of having a declarative class & instance definition language, and a more-or-less “flat” imperative instruction language for binding functionality to objects.

One thought before I let that thought drift off into the Internet Ether…. I’ve noticed for a long time that OO methodology is, for a lot of practical purposes, Dead On Arrival in the software industry. A tremendous number of people I work with — some of them very smart — just don’t understand OO. Rather, what they do is wrap structural code in objects. They are essentially writing compiled scripts.

I think the big surge in dynamic scripting languages owes a lot to that. A lot of the really smart guys using scripting languages pretty much ignore the OO aspects of those languages, and just write long, complicated procedural scripts, usually with a light amount of structure or factoring.

If the imperative instruction language was essentially just that — a way to transcribe process flows, independent of some sort of object structure — it might jibe with the actual practices in the industry. But because the instructions are independent from the structure — that is, not tied to a bad, dysfunctional, poolry thought-out structure — it would be easier to recombine the functionality into stronger class structures.

Or not. My little girls are keeping me super busy these days. Maybe when they go to college, I’ll write my 3-in-1 language, and show the world what it missed!


Leave a comment

Filed under opinionizing

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s