[crdoconnor]

It is. That's the truly awful thing about it - it is a turing complete language that kind of pretends not to be.

This is why templating languages are better at helping you maintain separation of concerns - they physically won't let you put business logic in the view layer because they aren't turing complete. XSLT will.

[dragonwriter]

Not being Turing-complete doesn't prevent you from putting business logic in the view layer, it just means that you are likely to run into some limitations doing that (as there are some computable functions that can't be done in the templating language so that you probabaly will run into some business logic that can't be done in it.)

This might further discourage putting business logic in the view layer, but, OTOH, it just as easily result in developers starting to go down the logic-in-view road, running into things that don't work there, and then ending up with some business logic in the view and some business logic in more appropriate layers.

And there's really nothing inherent in view transformations vs. business logic that necessarily makes the latter sufficiently served by a weaker computational model than a Turing complete one, so not having a Turing complete language for the view can result in view transformations in other layers or constrain the flexibility of presentation if that isn't done.

[crdoconnor]

>And there's really nothing inherent in view transformations vs. business logic that necessarily makes the latter sufficiently served by a weaker computational model

There is. View transformations are essentially configuration. As such, the ideal language for describing them is declarative.

To keep declarative languages clear, you need to make them not be turing complete. If they are turing complete they become unpredictable and difficult to understand.

Business logic requires turing completeness and usually requires mutable state.