Business Innovation Patterns.

[swestrup]

Nothing profound here, but I thought I would write this down before the idea slipped away.

Once upon a time Christopher Alexander wrote "A Pattern Language" about ways of designing buildings that were pleasant to live in. While the book had many omissions and contained much that was apocryphal, or at least wildly inaccurate, it had a large friendly cover. It also got people thinking about overlapping patterns in design space. From that thinking emerged, a number of years later, the software industry's current obsession with design patterns. Now, for the most part this is a good thing™ as making people think about the abstract design elements in their code helps make the code better, although many of the books I have read on the subject also follow the tradition of many omiissions, and much that is inaccurate. Lately there has been evidence that this subfield is starting to mature and more competent books are now being written, but that's beside the point.

What I recently noticed when I sat down to write up all of the various business notions that I have had, is that they seem also to follow a set of design patterns. If I worked hard I could probably extract a set of business design patterns and write a book about it. I wonder if it would sell?

Comments

[pphaneuf.livejournal.com]

Ah, yes, JIT. I figured it'd get there eventually.

I'm still a bit too attached to the current output of my compiler (as in "what can I do *today* to make it suck less" rather than think of "how it *really* ought to be") to go there. I'd love a perfect world, but I'm in this one, and it's really far from perfect!

By output of the compiler, I mean an ELF or a PE binary, not anything in particular that C++ outputs, like vtables or whatnot. But generating code and changing object layout at runtime (which basically requires generating code if you want to do it efficiently) is a bit too iffy (code that doesn't go in the text segment!?! whee!!!).

I agree that it'd be nice if C++ typed in the forwardings for me, but I like remembering that what I'm doing sucks, so I don't mind it too much. At least, if we could have tail calls for methods with identical signatures (which is perfectly easy in x86 (and probably others) assembly, it's just the stupid C/C++ not letting me generate the code I want and even know how to do!), it'd be a bit less bad...

I used to like dynamic method dispatch, but it seems to me that considering each method individually is a bit of a risky business. Really, methods are not islands, they go with something. At a first level, you could say that some groups of methods go together, but the important part is that they go with a contract of some sort, they go with their semantics. So vtable-style interfaces seems to me like a good compromise, as they also happen to be a thing you can associate the contract with.

Hmm, do you need GC for first-class closures? Say that what I deem first-class in a closure is the Perl-style syntactic sugar, but underneath, they can be done in C++ with an object that has a single operator() method. Thus, they're an object like any others, and the lifetime rules that work with other objects would also work with them. It might be GC, but could be whatever else you normally have.

Heck, I do this in C++ all the time now, it's just that the syntax is horrid, and it shouldn't have to be.

[sps.livejournal.com]

No, you can't have first class closures without GC, just because the closure is the mother of all references. You can't really expect programmers to deal with storage allocation once you've given them pointers, but consider that a first class closure can end up calling itself without knowing about it in advance, maybe even end up storing itself in a global, and then try to figure out when you can deallocate the things it's captured!

I believe that Perl currently uses reference counting, and some code will leak storage badly. With normal objects you can give annoying advice like 'zero it out when you think you;re done with it', of course (and Perl does), but with a closure you'd need a dangerous level of reflection even to be able to do that much.

And don't get me wrong - I disassemble the output of the compiler as a regular bit of my debugging strategy. I just don't think that static compilation is the best known technique. Even if it's often the best implemented.

When you say 'methods are not islands' and need contracts, it sounds like you're asking for interface-checked mixins to me ;).

And C++? It should simply never have happened. Like Perl it grew rather than being designed; unlike Perl it wasn't grown by someone who had a serious devotion to engineering. Or so it seems to me.

[pphaneuf.livejournal.com]

Your last comment rings so true to me.

Perl uses reference counting, yes, with surprinsingly good results. I like the deterministicality (that's a word?) it exhibits. I think the problem is when refcounting is used completely by itself, that's when you have circular references and just can't avoid them. But if you have various types of references to correctly reflect the underlying design, you're fine (at least an owning reference that increases the refcount and a non-owning reference that gets notified when the object goes away, preferably also a non-owning reference that has scope-garanteed lifetime, for parameter passing).

Well, I don't know about mixins, but I'm asking for interface checking, that's for sure!

[sps.livejournal.com]

Yeah, when you get bitten is when you have a transient value with a subpart that is 'really-truly' circular (in the sense that you'd have to add an otherwise completly unnecessary data structure to do the owning if you wanted to tease out the different roles as you describe).

Of course, one approach to this is to separate ownership from references, and provide 'arenas' to do the owning with a stipulation that you can do what you like with a reference but it must never outlive its target's arena. If I have to have explicit storage management in a language that's more the flavour I'd like.

(It also avoids the overhead problem of refcounting - contrary to popular belief, GC is much faster than refcounting, because all there's no overhead for use, and somewhat faster than alloc/free, ebcause there's no cost for disposal unless you actually need destruction.)

[pphaneuf.livejournal.com]

Yeah, the "really-truly" circular is a bit annoying, sometimes, but I find it very rare in actual use that it is not worth throwing out the whole model for just that case.

Arenas just like the Objective-C (which uses refcounting) auto-release pools, you mean? :-)

The trick with refcount is to remember that very few references are actually owning references. If you keep that in mind, you end up twiddling the refcount a whole lot less (you use scoped references for parameter passing, for example, and increase the refcount only when you actually save the reference for longer).

It is true that GC can have better overall throughput, but I like the bounded times of refcounting rather than the bursty random lags of GCing. Again, games and event-driven network servers, a bounded overhead is sometimes preferable...