Then you are using the restrictions of the mini-language to discipline yourself? It's a good thing to put up fences which thou shalt not pass, but it's better to have them "inside".

It's not so much a restriction as merely a place where it starts getting interestingly harder.

I don't consider the edge-of-road markers that make a very loud noise in my car when I start to drift a "restriction" either. After all, I can ignore the noise, and keep driving off to the emergency shoulder, as I might need to do occasionally. However, it's a nice warning that I need to rethink what I'm doing.

TT's limits are more like Perl's "warnings": they can be ignored if you choose, but they seem to kick in almost always at the right time. After all, the thing I wrote to handle my photograph library is a huge 400-line TT component, and it does an insanely large amount of data wrangling that really belonged in a controller somewhere. But I still use that in production (until I replace it with something more ajax-like soon).

And that's what I like about TT. I can putter around in it, and do model and controller things there, but I'm well aware that it should really be moved somewhere else. With Mason applications, I often see a ton of code in a URL that really belongs in a testable class as a controller or model code, because with Mason, the cost is actually less to put it at a URL instead of in the proper place. This is the danger of Mason (similar to the danger of PHP).