Geekstorming

Half-baked idea ahead!

So I’m reading Lambda the Ultimate, and pondering programming languages. It occurs to me that what the world seriously is in dire need of is some way to build re-usable control structures. To enforce design patterns.

Mid-level programming, I call it.

Think about it — all we have is if statements and a couple of different kinds of loops. Recently, we got exceptions.

Functional languages and meta-programming are, naturally, great for this. Since control structures are just functions anyway, build whatever you want. Go nuts. Fine and dandy, for problems which can be mapped nicely onto functions. But what about our poor, neglected imperative languages?

Here’s my first proposal for you — the Transaction structure. I was recently creating a nice little class at work which took care of a bunch of common functionality across a wide selection of tools. The “Connect” method of this class set up a connection to a vehicle, did some discovery as to what hardware was on the vehicle network, and in some cases detected the version of the embedded software on the vehicle for reasons too stupid to go into here. Point being, I needed to rollback the entire operation if any one of the steps along the way failed. In an imperative langauge, the only way to do this is to either copy-and-paste the rollback code after checking for failure at each step (ugly), or setting and checking a flag which tells your method just how far you got, and incrementally rolling back based on that (also ugly).

I implemented a checkpointing library once. It was so much extra code to do something like that that I would never have used it in a project that didn’t say, “The customer needs high availability, and we wrote this high availability toolkit.”

When we have tools to generate commonly re-implemented code, we need to start taking a serious look at our programming languages.

What I am envisioning would be not only covering those cases where the syntax is ugly. It would tighten the semantics of a particular block of code to the specifications of the structure. If I say, “I am using a singleton pattern here,” then I shouldn’t be able to not use a singleton pattern, or use it incorrectly. The redundant code is generated for me behind the scenes, and I can get on with the actual domain-specific bits of my application.

I gather this is sort of what using Forth is like. Except that everybody who uses Forth derives impossible amounts of joy from reinventing the wheel.

I see a standard library of mid-level control structures. A common vocabulary for users of the language.

Please, functional language people. Educate me on how this functionality has been available for fifty years in LISP. Then, nothing would please me more than to be pointed to a standard library of control structures for a commonly-used functional language. A “But this minimal set of functions in the language is all you need to do anything!” will not cut it. A turing machine is also all you need to do anything. I want to see strict semantics for a set of common control structures needed for inherently state-based problems. (Obviously, non-state-based problems map onto functional programming very well already.)

I am feeling very sleep-deprived for no readily apparent reason. I know that the above posting is meandering, not at all cohesive, and has a lot of paragraph breaks in it. Still, I think it contains interesting ideas which I would be happy to partake in lively debate about. I should totally be running a blogging system with a comment feature (such as NewsBruiser). Instead, email me!