Yeah, I didn’t go too much into the scientific method and the peer review process here, very good points. So far, I haven’t had any fundie action, which is too bad (how much you want to bet that if I they will argue from one of the stances I said not to bother with…)

I’ll add a note about the scientific method: everything that stands the test in science is based on hypothesis backed by rigourous testing and empirical evidence. If someone wants to question the methods used to reach the conclusion reached (for example, evolution), all they need do is look up the standing scientific research, attempt to produce different test results and submit the new, contradictory, results to peer-review and meta-analysis. It’s that ability to validate each individual part of a scientific theory that gives scientists such a solid foundation on which to base their work.

My main problem is that I want to keep template-specific CSS and JavaScript in with the HTML, yet render incrementally. That can’t happen unless you compile the templates or have a two-pass interpreter, because the stylesheets have to be linked to from the HEAD. Another problem that seems to trip up a lot of template languages is that they look down on the designers as “dumb” and/or try to completely separate “presentation” and “logic”. But presentation logic, although it is logic, still belongs in the presentation! It’s just something we don’t always see when we start designing a “lite” template system.

The advantage of Smarty over PHP is that they’ve put in a bunch of conveniences, like (IIRC) the html_options function, and it’s easier to work with simple braces than the PHP open/close tags. But I’m convinced (through hard-earned experience) that trying to stuff all your variables into a cannon and blast them into a template in one shot is the wrong approach.

Being a big proponent of OO, MVC, ActiveRecord and all that crazy crap I see things differently.

First of all, you have to think about corporate lame-o software development means. It means you have ten or twenty people working with each others’ code every day. As well, people aren’t emotionally invested in the code or the company to a strong degree so a developer could leave his job suddenly. Those who are left (and those who are newly hired) have to maintain buddy’s old code.

Developer Alice goes in and writes users.py and defines getUsers to return a list of dictionaries where the keys are the fields in the user table. Developer Bob writes getWidgets and returns a list of indexed tuples whose positions are the fields in the table (keyed by some constants that map to integers). Developer Carl thinks the whole thing is dumb and refuses to write sprockets.py because it’s simpler to write queries in raw SQL. Who is right? They all are. Given context each approach is valid. And with today’s multicore multi-gigahertz holy-crap-it’s-fast processors each approach will be fast enough.

So then Developer David walks in and he doesn’t know what to do. He’s got three completely different interfaces for business object things. He goes to Alice and she explains users. He goes to Bob and, well, Bob is in a lot of meetings and doesn’t have time to chat. And Carl, well, he moved to Mountain View and is working for Google. So David has to read all that code and try and figure out the mindset of the developers who wrote it. Then he has to memorize all the interfaces. Maybe then he can get some work done. Though a system with only three business objects is pretty unusual. How many exist in our current project? 20? 30? 50?

The idea with OO, modularity, and libraries is that you don’t have to memorize as many interfaces for objects. You do, however, have to memorize those libraries but at least that documentation is collectively maintained across projects (assuming you’ve picked a project with good documentation. Like Pylons. Maybe not like Pylons. :\)

Now, a good developer writing good code can write modular and useful code without any straightjacketing OO libraries. Fact, not everyone is a good coder. Fact, even good coders write terrible code sometimes. I know I’ve written lots of it. email me and I can give you a tour of my mistakes…

Of course these OO libraries are straightjacketing. They DO try and turn programmers into asssembly line workers, because most companies need assembly line code. Most companies don’t even need good programmers, just acceptable programmers.

What’s a good programmer in a corporate programming job to do? Try to find ways to tailor the straightjacket to not suck so much, and to reduce the ways of making mistakes. (Often OO libraries don’t prevent mistakes, they merely move them to another level– no more SQL syntax errors, but goofy object operations galore). If you think foo.bar.models.users.User.find is goofy, find a way to make it less crappy.

I don’t know… I don’t think I’ve really argued very well here. Just throwing in a few ideas to muddy the waters.

There are all kinds of reasons why we won’t, though, most of which could be lumped together under the difficulty with which a camel can get through the eye of a needle.