That’s the best critique of PHP I’ve ever seen. Mostly I have fixated on the usual polluted namespace and crappy typing as well as the other warts.

For Wordpress this may be the case, but you then used that as an argument against the LAMP style separation, when the problem is Wordpress not LAMP.

My point being that the LAMP separation is the bare minimum for a reasonably scalable web app - for a large setup you’re likely to end up with more layers, not fewer, simply because you will end up wanting to be able to scale out at the pinch points, and the web application server and the database at the very least are completely different in terms of how you scale them.

My workplace uses Smalltalk and the stories I could tell! We are right this moment rebuilding everything in Javascript. There is no support available for Smalltalk any more, it’s an orphan.

It was terribly fashionable 10-15 years ago. But as gilmae said, I can’t see a smalltalk system running in Javascript unless you’re talking about one of those funky systems that spat out web pages directly from a running Smalltalk program, in which case you’ll still need something else at the back doing the grunt work.

I really, really miss the workspaces in Smalltalk, where you could just type a bit of code, say “do it” and look at the results. Makes incremental development trivial, but the whole system suffered from the tightly coupled syndrome. Since everything is running in one complete image, to deploy a program you throw things away (rather than in a normal environment where necessary things are included). Some developers just didn’t “get it” and struggled with the whole concept, never successfully packaged an image for deployment and relied on their cow-orkers to do it for them. These were smart people, but the whole environment is so alien it’s no wonder it withered (kinda like Pick which suffered in the same way).

That’s how the Lions club were doing things at the sausage sizzle at Bunnings the other day. Communists!

Do you have time for a question from a mere front-end user? Why does it take aeons for Wordpress to save a post containing an embed link to a YouTube video? I mean, it’s only HTML innit? I don’t see why the nature of what it links to would affect anything. Maybe this has something to do with the problems you describe but I’m too technically clueless to see it.

My workplace uses Smalltalk and the stories I could tell! We are right this moment rebuilding everything in Javascript. There is no support available for Smalltalk any more, it’s an orphan.

I mean, to work with an SQL database you need to know the schema anyway.

The neat thing about modern RDBMS’s is they contain the meta-information to discover bits of the schema - not quite self describing, but good enough to be able to write generic DB management tools and externally walk relational dependencies. The whole “object/relational impedence mismatch” is just a load of hooey - while it’s non-trivial to write a good object/db layer, they can be found just about anywhere so you can treat it as a solved problem.

James A wrote:

although some sort of file-based RDF store plugged into git would be hot. Hmm. Some sort of query language or ORM on top of small files stored in git would be hot.

James, it’s been done and it was called Pick - quite successful in it’s day (20 years ago it dropped off in competition with networked relational databases).

I don’t think you see my point. It’s not loosely coupled as it is now because I need to know the whole stack to scale up Wordpress — I need to know MySQL replication and possibly get up to speed on memcached. Each individual component is coherent, which is a good design indicator; but they are still too tightly coupled for my taste.

It’s been interesting getting feedback so far.

Not only that, but what you are proposing makes scalability a nightmare. Scaling the LAMP stack is usually easy:

You add frontends as required. Once you hit database limits, you add replicas.

A well written LAMP style application will handle this well. At some point you’ll add one or more caches to reduce load on the backends. And as with anything there’s a number of ways of tuning each element.

That some LAMP based apps aren’t designed to handle this well is an application problem, not a problem with the separation.

Now, there’s nothing wrong with for example linking the app into a HTTP library, as long as the interfaces are narrow and clearly defined, but the main reason people do that is when they use languages (like Ruby) where the startup cost for the interpreter is significant and/or where there’s poor support for the “traditional” model. In the Ruby community at least a lot of people have been clamoring for a mod_php like module for a while, and Passenger is promising to deliver at least part of that functionality for Rails, but even when using a standalone server, we tend to put things behind Apache, Nginx etc. - in a sense we’re adding a layer to the stack, not collapsing it.

Revisiting the interface boundaries is useful, but you’re arguing about layering that is well established for a reason: Separating out data storage for example is done exactly because scaling and managing storage and processing are vastly different in terms of how you approach it, and pinchpoints.

Separating out the data storage in a database (what type of database it is is secondary) allow you to scale each element based on when you run into limits, which is vital in a large scale environment. And nothing stops you from running it in a single process if you like - there’s always solutions like Sqlite. Again the point of the separation is stable interfaces, not whether or not it runs in the same process.

All of them were based entirely on “navigation” like the old IMS databases of crusty programmer nightmare - if you didn’t know where to start, you were stuffed.

I got to chatting with a professor of mine the other week about this. You’re quite right that most object databases are hiding the network-database nature of object graphs. My hunch is that the answer will actually be to bend object oriented languages to include relational theory, rather than treating RDBMSes as ugly, inconvenient but necessary datastores.

As for your story — you should write it up and submit it to the Daily WTF.

The performance nightmare is pretty obvious in most Java web applications - in theory the application server is responsible for managing all that icky HTTP, database and authentication goo in one place. In practice they turn out to be poorly performing piles of shit that still have byzantine configuration/tuning. This might be because Java also encourages flexibility at each layer so it’s not really an integrated system, it’s still a katamari of discrete components.

Most non-dedicated webservers (ie language libraries) tend to have poor performance - the way to performance is mod_perl, not use Apache; mod_python not import BaseHTTPServer. I think this is because the HTTP model is actually quite different to imperative programming, so naïve approaches just aren’t performant at all. And real-world web clients are frankly, a PITA - see LiveJournal’s creation of PerlBal, a reverse proxy that sucks the response into RAM then slowly (compared to LAN speeds) feeds it out to the client, just to free up the serving Apache for another request.

The real problem is PHP is just a poor language, encouraging raw SQL and bad templating - the base design of PHP was as a templating language, as shown by the name, PHP Hypertext Preprocessor, and though it’s outgrown this, people still use it that way. Use of higher-level constructs like ORMs and proper templating needs to be enforced - Steve Yegge puts it well when he notes Microsoft’s C++ framework outperformed Geowork’s assembly one because the Geoworks one had lost perspective and so wasn’t possible to optimise any more.

ORMs basically are a data storage library, so I guess you’re kind of right. Straight object stores (I’m thinking Zope here) however don’t have a history of high-performance, if only because the big-name SQL servers have had a lot more work put into optimising them. I’m not sure if I actually had a point in all of this, apart from ranting a bit, but oh well.

All of them were based entirely on “navigation” like the old IMS databases of crusty programmer nightmare - if you didn’t know where to start, you were stuffed. If you couldn’t remember the record layout, you were stuffed. If somebody accidently broke the only link to a big table of stuff, you were stuffed. Those old guys with long, grey beards know a thing or two if you come across them.

Some of the truly awful object DBs (not naming names) stored memory snapshots of your objects, so if you wanted to try sharing between ST and C++ or a PC and a Sun you were SOL. Some of them fell to bits when you changed your object as the object versioning stuff was either broken or missing. The good ones (that stored things in an architecture and language independent way) were like molasses and were fundamentally untuneable.

Then, one of the geniuses I worked with decided he could use the BLOB feature of Sybase to store objects if he shared the marshalling/unmarshalling code and had a library that checked the version of the object before loading it. That resulted in a runaway Smalltalk program that tried to store every object in a running image into the Sybase database. Same genius got knuckle rap, then went ahead and implemented it anyway with the broken feature (the bit that walked the object tree a leeetle too far when storing) sorta-kinda-fixed. Into production it went. Said application took 20 minutes to start after 3 months and as the data wasn’t indexable, it wasn’t tuneable and the Sybase DBA washed his hands of the team.

Then, an unnamed junior programmer “fixed” that feature in a running, production environment and hosed the app completely, resulting in much hair pulling and me having to debug it. Live. With crowd.

Object storage - just say no. Don’t get me started on Corba as I will have to punch somebody.

I don’t disagree with you — I am a big fan of relational databases.

“Some of my best friends are relational databases!”

For example, I work in a firm that does HR software. The next generation of product is currently being designed and I am definitely keen on using an RDBMS as the backing store and authoritative data model.