I've been thinking more about PHP after my last post. Here's another post along the same lines. In summary, there's a kind of admission on all sides that PHP lets people with no programming skill program, producing bad software, but actually producing. Some people think that's okay, some don't; I definitely believe that is okay, even if it doesn't lead to the technical decisions I want.

But PHP is still a horrible language. It's okay that PHP mixes HTML and code. It is okay that some of its data structures are sloppy, like arrays. It's okay that it's not very object oriented. But some things aren't okay. The quoting rules are horrible, and the database access is horrible, and several other pieces are just incredibly stupid.

PHP was not designed by good language designers. I don't even think it was designed by people interested in language design. Which is strange in a way, because there's far more people interested in language design than there is room for languages. But maybe it took bad (or at least disinterested) language designers to create something that didn't overthink the problem, so that they approached the design much like beginning programmers would eventually approach the language itself.

But you don't have to be disinterested to create an a language or environment good for beginners. And you don't have to make stupid decisions to mirror the stupid decisions your language users will later make.

So it makes me think; what could really be the better PHP? Something that flows more comfortably towards "good" web programming practice (e.g., MVC), but doesn't require those practices. Something that suggests techniques to users, even very primitive techniques that seem entirely obvious to an experience programmer.

I think the active page model is a good place to start, allowing a gradual move from static HTML to dynamic. I think databases should be considered from the start, because that's just obvious and universal at this point. I imagine something like ezSqlObject (even though I don't think that code is maintained anymore, and I probably wouldn't base it directly on SQLObject). You have an object that represents your database, attributes that represent tables, etc. There is no "model"; database access is procedural.

To allow better flow to MVC, you should be able to mix the active pages with Python code, and you should be able to put a block of Python code at the top of your page. Code reloading must happen totally transparently and reliably.

It needs to be a multiprocess server, not threads (maybe one process and multiple interpreters); this is one of the big features of PHP. It needs to have a complete server setup. PHP gets by with nearly everyone using Apache, and it does well -- the constraint is a feature. Less to think about.

To be really like the PHP process model, the only current option for Python is to use CGI. This is not actually realistic. But I think it is possible, given the appropriate monitoring and isolation to get nearly as reliable a system. That means a really reliable master process, with subprocesses that are monitored and managed. The only Python system I know that really does this is SkunkWeb, though a complete system would probably be more extensive still.

Errors should initially display as simply as possible, possibly allowing you to dig in. I imagine some notion of "library" versus "application" code (probably based on package), and the most minimal error message shows the outermost frame of application code. From there you can expand, but most errors are trivial and can be best detected with this separation. This is true of experienced users too, and certainly it's a UI principle that we could stand to use elsewhere; but it's especially true for new users, and the intimidation of a full traceback is a problem.

We should build other tools into the system, like code editing. This doesn't mean storing code in a database ala Zope, it just means one less bit of overhead to getting started. Figuring out how to handle editing is a significant overhead. The TurboGears toolbox is an example of providing good through-the-web tools; these should just be tools, not frameworks. No frameworks!

For the actual pages, what template? I'd probably suggest Cheetah or Spyce. Though I mention Django in the previous post, it is not powerful enough to be used without Python code, nor does it allow the flow from HTML, to simple page, to complex page, to MVC; it's missing a step.

I also think that the template should be textual, not markup-based. People will be editing these pages in their text form; maybe you can edit markup-based templates using WYSIWYG tools, but you certainly can't add all the logic you need to make a dynamic site. Like Django, it only really works when used in concert with a "real" programmer. If you are editing text, you should be working on the text level. Spyce, unlike Cheetah, is really targetted at exactly this model; that said, Cheetah is entirely capable of this model. So it's a toss-up to me. They both do a good job of embedding Python into markup, which is not easy. Myghty is also usable in this same way, but I find it rather complex.

I think an object explorer would also be a very nice tool, but I won't go into the design. It would be a very interested project, though. Think of live objects. The multiprocess thing makes this hard, though. Maybe it's good to expect a single-process non-concurrent development mode.

Another important key will be a rich library of routines for typical web programming tasks. That's the thing I praise so much in the PHP post; Python supports this well, but there isn't really such a library just for web programming. It can't be a framework, it shouldn't be very object oriented. I think namespaces are completely okay (you don't have to be quite as flat as PHP), but import management is problematic.

I think Pylons is going in a good direction in terms of these routines. First is the WebHelpers module (with no particular attachment to Pylons or Myghty, except being codeveloped). The other thing they are doing is a per-application module where you import all your helpers (by default just the WebHelpers package, but you can add imports there). Everything imported into this special module is available as a global variable in your pages. I think this is a good way of balancing explicitness with easy and casual availability of simple routines. The initial set of imports should be fairly rich.

Anyway, there's a simple outline. I don't think any one part of it requires anything too radical -- except for the process model (and reloading goes with that). That part is hard, but very very important. We can't clone PHP to achieve that -- mod_python is not really equivalent to mod_php. And using Apache as the app server works in PHP because their standard library is entirely in C.

Since Python is a capable language for writing library code, this is not an option; most of the standard library is already written in Python. There's other similar aspects to PHP we can't clone -- mod_php is much much closer to Python CGI than to mod_python, in my opinion. I think for Python to make this work we need more flexibility than we can get being embedded in Apache.

Anyway, there's some thoughts for ya'.