Let's start at the end: code and data. How are they separated?

First consider those three famous security holes: "buffer overflow, sql injection and cross site scripting (i.e. xss.) They're all caused by exploiting the blurry line between data and code.

So it's easy to jump to the conclusion that a blurry line between data and code is dangerous... we're only safe if we keep our data and our code separate.

But this is powerful magic: mingling code with data is powerful stuff! yes, it must be handled with care, but it must be handled.

Lisp is generally said to blur the line between data and code, because you can't interchange one into the other so easily. <rolls eyes... he's mentioning lisp again... here we go> chill winston! it will be okay!. But I don't see where this makes lisp so special. The whole von neumann processor architecture, is based on reading instructions and data from the same place.

Oh, here's a quote from Paul Snively that says it well:

So this incessant harping on data-as-code and code-as-data in Lisp merely obscures the fact that data is code and code is data in computing. That's the lesson of Lisp, but unfortunately it's gotten lost in the Lisp dogma.

This reminds me of something I heard at uni, and haven't thought about until now: There were apparently some early processor architectures in which data and instructions were kept in separate memory units. The 'instruction pointer' would be up to one place in the instruction memory, and the 'data pointer' would be up to a different place in the data memory. (Ah! It's called the Harvard Architecture, tanks agen, wikipedia)

This model died, and von neumann architecture won out. So, tody we have "instructions and data" in the same place, interchangeable and ultimately it's anybody's guess what makes for data and what makes for code.

_{You might say that code is 'whatever gets executed.' But, if code isn't yet executed it's still code, not just data. And just because code has been executed doesn't mean it stops being data. So I don't think there's a distinction between them at low levels. At higher levels, there can appear to be a distinction, but at the highest levels, the distinctions dissappear again, lisp etc. Anyway, I'm lost in this paragraph: i'll move on to the next biot: the separation of business rules from everything else.}

Keep your business rules in your business rules layer.

This is pretty much accepted dogma in the n-tier custom software world where I live. But it's impossible to enforce absolutely.

What exactly is a business rule? How and when does it differ from everything else in the solution?

i like this quote from wikipedia:

"There exists no definition of business logic in any programming language specification or API, nor in any academic research. However, usage of the term persists in trade publications..."

but be careful -- if you stop believing in the existence of 'business rules' you might vomit up the kool aid -- spit out the red pill, and do a Gunderloy ;-).

So what am i saying? have i become a business rules atheist?

Never -- i've just started to realise that there's some business rules that live in the presentation layer. There are some business rules that live in the database. And there are some things that aren't business rules that live in the business layer. It's all fluid, like Thermodynamics, baby

• cheap to change,
• not repeated,
• easy to use,
• available when needed

Much to say -- but no motivation to share it (right now).

The final topic is separation of content and presentation... but right now the brain is overloaded. Discuss quietly amongst yourselves. Teacher has a headache.