Lambda the Ultimate

Well, I guess I was wrong about that...

I'll help with that, Ehud. ;-)

For me, the biggest language design lesson in BC4J is that you should be sure you have a standard problem before you provide a standard solution, i.e. library or framework.

I used an early incarnation of BC4J a couple years ago, and though it was a valiant effort at a standard solution, it was too complex and not flexible enough along the axes of decision that any enterprise app must face.

A library or framework necessarily must make some of those decisions a priori, and this hampers adaptability if your particular situation calls for a different set of choices.

Another issue that this paper raises is the problem with the term "business logic". Much as in the more general case where the distinction between code and data is one of convenience rather than fundamental, whether something is "business logic", "data logic" or "application logic" is quite fuzzy.

Most often they are defined by where you put them rather than what they do. This is another problem of the general framework: you must shoehorn your problems into the slots it provides, creating distinctions where there are none and lumping together things that are distinct.

Though reuse has become a holy grail, and "reinventing the wheel" a universal term of abuse, this instance shows that sometimes using a framework or library is NOT the best solution to a given problem.

Are OOP aplication framworks inherently less flexible than functional approaches (e.g., think high order programming)?

Are "business rules" realy a useful abstraction?

I agree 100%, and this is a point I was trying to make in my diatribe against standardization in the XQuery Formal Semantics topic.

It's the "rose colored glasses", paradigms, and Sapir-Whorf all over again, ain't it?

The influence is much more subtle then simply deciding whether you have a "standard problem." It's really that when you are tied to this sort of mental model, every problem looks "standard," when in fact none are.

Ditto with workflow...

All I heard, reading that paper, was the sound of vendor whispering sweet nothings into the ears of PHB...

Opinions?

The fundamental problem here is complex, distributed applications with varying requirements and performance profiles.

I'm not sure any programming paradigm will solve that particularly well. (Though I haven't used Erlang; I gather it is a "hero language" in this domain)

Are "business rules" realy a useful abstraction?

Sort of. ;-) It does describe a "real thing", but that thing is a grouping of different things created by the accident of historical development that divided client from server, interface from data. "Business logic" is that stuff that falls through the crack between the two.

A more holistic view of applications makes "business rules" just part of the domain logic.

I think this depends on a combination of the domain, the particular problem in that domain, and the design of the framework.

If it so happens that the domain has a well-defined and constrained range of problems with well-known solutions, either will do fine for you.

Equally, if the DSL or framework happens to have been designed with exactly your type of problem in mind, even in a more complex domain, you can probably use either quite well.

I think first class functions, syntax extensions, etc. simply allow you to "subvert" a framework or DSL (or, in some case, general PL) that wasn't really designed well for your problem. Why not rethink what you need instead?

I think you misunderstood me. I think DSLs can offer more flexibility this way, if these tools are taken into account during the design. I think flexibility/extendability is essentail for software engineering.

I think this depends on a combination of the domain, the particular problem in that domain, and the design of the framework.

Is this conclusion based on some practical experience you can share with us?

I'd be at a loss even to compare the two. The notion of DSL is relatively well-defined: it's just a programming language minus a parser. "OO application framework" can mean practically anything you like: a library in an arbitrary programming language perhaps even with associated external tools and environmental dependencies.

OTOH, if there's an advantage to DSL's it stems from that well-definedness. It's not too hard to describe the semantics of a DSL, but OO application frameworks are typically large and ill-specified. Just think of Java's AWT, which is notorious for its variable behavior on different platforms; the problem isn't that different platforms have different GUI behaviors, but rather that there is no clear description in the docs of exactly what behavior a user can expect on every platform.

Or consider the wxWindows framework. The manual is thousands of pages long and it still relies ubiquitously on assumptions about what, for example, a "tree control" is.

I think first class functions, syntax extensions, etc. simply allow you to "subvert" a framework or DSL (or, in some case, general PL) that wasn't really designed well for your problem.

I don't think so. In a DSL, one gives a signature and a semantics for a set of primitives; the first-class functions are sort of a free completion of that signature which typically gets inherited from the underlying language, so they're just a conservative extension and consequently can't subvert anything.

What I might argue is the implied assumption that a PL must be functional in order to effectively host DSLs.

Business logic is to logic, what military intelligence is to intelligence

What I might argue is the implied assumption that a PL must be functional in order to effectively host DSLs.

I suppose it depends on what you mean by functional, but Python for instance is quite amenable to the implementation of little languages - David Mertz's articles on declarative programming in Python demonstrate this quite effectively, I think. I could quite happily develop a naive "business rules" framework in pure Python - as happily as I could in Scheme, for instance. But this is partly because Python has an inbuilt syntax for lists, tuples, list comprehensions and so on - it helps a lot if such things are on hand to begin with.

On occasions when I've needed to do this "in real life", it's tended to be either with a use-once-and-throw-away XML vocabulary and a bit of plain imperative code (in VB6) to parse and execute it, or with an SQL database used entirely to perform set-based operations to filter out subsets of data into separate queues for different types of actions. In the latter case, the database is almost never used for long-term persistence - it's just a convenient way of applying logic expressed in the form of set-based queries. (Actually I lie, slightly: a couple of applications use the same database to keep an audit log).

On one occasion I did write a screenscraping client for a 3270 terminal emulator that exposed an API via the MS scripting control that could then be scripted in plain Javascript. One irony of this was that the Javascript code was in some ways better written than the VB6 code for the rest of the application - try...catch...finally is a lot cleaner than On Error Goto...

and

Chris: For every business rule I've ever seen documented, I usually encounter at least 10 exceptions to the rule.

Finally, Dominic: All I heard, reading that paper, was the sound of vendor whispering sweet nothings into the ears of PHB.

These statements are the essence of the "business rules" problem. First is the capriciousness of what the "rules" are. Second, that every vendor wants you to implement the rules in their system, and wants you not to implement them in other systems.

And so the challenge, once you've convinced projects to take requirements seriously at all, the challenge is to be able to express the rules in a simple notation that can be maintained and executed cheaply.

The trouble in most business environments is not that the rules are complicated, but that they are scattered across systems and not expressed in simple, executable notations, if they are expressed explicitly at all.

Well, no one can disagree with that, in principle. The slippery zone begins when one must decide how much flexibility and extendability should be built into a current project, or, on the other end, when you must decide to extend an existing framework or start afresh.

The odds of some framework (or DSL) solving once and for all a problem space with many variables seems pretty darn slim to me, but it is possible that someone will have an epiphany that simplifies large swaths of the field.

Is this conclusion based on some practical experience you can share with us?

Ah, where to begin. ;-) I can illustrate just with the title example. BC4J (to be fair, the version that existed around 2000) was supposed to be a general framework for database access for n-tier Java-based apps.

The problem with this is that n-tier Java-based apps are not even remotely all the same. They require vastly different capacity, have different complexities of data, interface, etc.

Now there are some well known variables in this domain (see e.g. Fowler), but their ranges are big enough that there really can't be a one-size-fits-solution.

So BC4J (as does any software design) had to make choices, say about how caching is handled, and each choice reduces the range of problems for which it is suitable.

We can contrast this with, to take a trivial example, the collections libarary in Java. Lists, trees, hashes, etc. are all well-studied, clearly specified data structures with well-known properties. Unless you need something very unusual, you can expect that you can build upon it for any of your likely needs.

I see that I've worded things too generally.

I'm don't believe that first-class functions or syntax extensions are a bad thing in general.

I'm thinking of a particular type of bad design that relies on a "Deus Ex Machina" of unconstrained additions to the framework to fix future problems that were not foreseen:

"So we'll stick an extra parameter on that takes arbitrary code that we then pass to eval, just in case we need some new behaviour in there."

"So we'll stick an extra parameter on that takes arbitrary code that we then pass to eval, just in case we need some new behaviour in there."

This sounds more like The Curse of the Windows API than anything...

Most business rules are straightforward, and we may hardly think of them as "rules"--things like All changes to the customer database must have corresponding audit entries or All data in validated fields must be checked against the appropriate validation table. They're in to enforce business or legal mandates (the audit entries are an example of this), or to maintain database integrity. Still, they're important to the operation of the organization and as such a fair amount of effort is put into making sure they're enforced. Nobody, after all, likes getting unpleasant letters from the SEC (or your national equivalent).

The interesting bits come up partly because of the development environment--a variety of programmers of varying levels of competence and incompetence--and partly because of the distributed nature of the applications being delivered, as most of them are at least client-server, if not 3 or more tier apps.

In the ideal world, all programmers would be supremely competent, and all the validation and rules enforcement can be done at the client end. Unfortunately we don't live in the ideal world, and validation can't be done in the client. There may be many different clients of varying degrees of correctness, as well as clients written with the express purpose of defrauding or circumventing controls. As such, you really want smart servers and dumb clients, if for no other reason than to centralize the validation and controls to minimize the number of people and code modules to trust.

Pushing against this are real-world performance issues--the central server may not have the capacity to handle all the validation, auditing, and rules enforcement logic, so it must be split, which brings you back to the client server problem, since the split gets you a client and a server, which then ultimately leads to a distribution of trust. Which pieces of the system do you trust, which don't you trust, how do you distribute that trust amongst parts of the system, and how do you validate those things that you don't trust?

Currently much of the trust distribution, at least in the business rules case that this paper refers to, is done administratively with little or no techincal support outside perhaps some identity validation. Building the technical underpinnings of a trust system (though no trust system can ever be implemented entirely technically--there has to be some administrative component in it) is an interesting problem area.

Trust issues aren't entirely restricted to the "systems on distributed machines" case either--there are trust issues involved even within a program, between the program and the OS, or the program and the libraries the program uses.

But it seems to me that in general business rules are not really business rules, but rather that it's a generic term used for those parts of the application logic that are simple to describe. That's why I don't really trust the notion of business rules...

Gaah, just sat in another meeting this morning with managers of technical areas who pointedly changed the subject any time the subject got remotely "technical". (Good thing I'm changing my job soon).

"Business rules" for these people means rules at a high enough level of abstraction for them to understand. "Do the thing that I want, followed by the other things that I want, and keep the compliance guys off my back". Sometimes these rules map cleanly to precisely-definable chunks of application logic, and often they don't (and the details have to be thrashed out in interminable meetings with people who aren't interested in - precisely - the details). I'm convinced, in what will no doubt seem an unreasonably snotty and self-righteous way, that nothing pitched to such people can have any real value as a tool for defining, implementing or managing the behaviour of any remotely complex business application...

Rant over ;)