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, its 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 didnt 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

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 dont 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.

I don’t disagree with you — I am a big fan of relational databases. I am also interested in the so-called ‘impedance mismatch’ between object oriented programming and databases, which is a related problem.

I’m not proposing flatfiles as an alternative. Possibly something along the lines of persistent objects as you can find in several flavours in Smalltalk and Common Lisp. You give up some of the declarative advantages of an RDBMS, including fast, flexible ad hoc querying, in exchange for an almost invisible data layer.

Most LAMP software is just using MySQL store-and-fetch, not decision support, so in this case the tradeoff could be sound.

It was about complexity that might not really be necessary.

That perhaps is a reflection on Wordpress, rather than unnecessary complexity. I remember thinking much the same thing on first encountering database programming – thinking it was an overly complex way to solve something easy (i.e. what’s wrong with flat files?). In some cases, flat files are perfect, but for anything where the data is going to get large, you need indexing capabilities, an interface to make programming easier, mechanisms to clean up removed data without fragmentation ruining things, concurrency features etc. As soon as you step beyond trivial, complexity starts to compound. I think it’s hard to characterise as unnecessary even if you aren’t using 100% of the features available.

I would equate schema evolution and object versioning – there’s just no getting away from breaking an interface every now and again. That’s a problem that there is no solution to.

I’d agree about HTTP though – it’s simple protocol, widely implemented and there are few risks in “re-inventing the wheel” because it’s not much more complex than a wheel. Databases and database implemention, however, is a different animal.

MySQL has other uses than a backend for Wordpress

Yes, but Wordpress doesn’t really use a fraction of what a full SQL database provides, but still gets all the complexity.

I do recognise that there are problems with versioning, but that’s a problem with schema evolution too. Common Lisp has some degree of hot-swappability and Erlang (to pick a currently trendy example) even more so.

As for the HTTP server, that problem has been solved so thoroughly so many times it’s not funny. People don’t want pure HTTP servers any more; they want a plugin engine built around the protocol. It seems to me to be valid to fold HTTP into a plugin or library and include it in the base application.

I suppose I didn’t really make my point well. It wasn’t so much about performance tuning; that was just the example. It was about complexity that might not really be necessary. Performance tuning is more complex because I have to do it in a bunch of places.

Fundamentally, I think it’s been tried and rejected (probably guaranteeing it’ll be tried again). .NET comes to mind – everything is floating around as a library of some sort, but it still doesn’t buy you the convenience of not having to tune the different layers when you hit a performance problem.

I think the ultimate incarnation of this kind of thinking was the early object based systems (Lisp or more specifically CLOS, and Smalltalk). Everything you need was embedded in a running “image” with Smalltalk, with loose coupling being the object interfaces. It *still* needed tuning when it performed badly.

So, in a long winded way, I don’t think tighter or looser coupling of code bases really buys you much when performance is a problem, as the problem is really taking general purpose code and specialising it. Every time a bit of specialisation takes place, you get an incompatible fork of something and suddenly you’re up Mac Plus creek without a ram stick, while your competitors sail past having successfully compromised.