WordPress is great from a blogger's viewpoint. I happen to like it a lot. It can be slow loading from a reader's viewpoint (and sometimes from the admin's viewpoint). And from a coder's viewpoint, WordPress is one giant platter of spaghetti code. It's ugly!
I've been using WordPress for a few years now. The last time I created a theme (template, whatever you want to call it), I had very little experience with PHP and really didn't know the difference between well-written code and poorly written code. I make websites for a hobby. With many hundreds (if not a couple thousand) of hours of experience learning about, reviewing existing code, and writing my own code, I can now say with a bit of knowledge that WordPress is very poorly written. I've read similar comments on webmaster forums by experienced PHP developers.
Using memory caching via an accelerator to reduce loading time is not an option for the majority of bloggers, and is not for me. My web host does not have caching as I am on a shared server. And I am not going to use up all my allotted disk space caching blog pages to disk. Most bloggers are not on dedicated servers. Even if an accelerator is offered on a shared web host, with hundreds or thousands of other websites on the server, the PHP code is probably not going to remain in cache for long. That means often all 76 files that comprise the basic core of WordPress are going to have to be loaded from hard disk and that takes a significant amount of time. In between loading files for one WordPress blog, the server very well may processing requests for other sites. So it isn't like the server stops doing everything else to process 76 includes for your site.
WordPress is in serious need of a rewrite from the bottom up. That doesn't mean that all the existing WordPress code needs to be trashed. I'm sure a lot of it could be reused in an object-oriented format using classes.
Some have pointed out elsewhere that WordPress needs to maintain backwards compatibility so existing plugins and other features continue to work or whatever. If that is the case, then WordPress is only going to get more and more bloated and slower loading as time goes on. If each page view requires the loading of 76 include files now, what will the number be in a few years???
PHP is not like C++ or other languages and you cannot code for it the same way. Languages like C++ are compiled. You could have 1000 included files and it will not matter because the compiler is going to create only one executable file or library. PHP, on the other hand, is not compiled, it is interpreted. The code has to be read from hard disk or from memory (if you have an accelerator), compiled, and executed every time someone views a page. This alone is a huge amount of overhead. The most time consuming part of it is loading the included files from disk. A typical web server can compile and execute thousands of lines of PHP code in the same amount of time it takes to seek and read one file from the hard drive. So having 76 files included on every page view is very inefficient.
With interpreted languages like PHP, programming efficiency is much more important than with compiled languages. The goal should always be to reduce overhead as much as possible. Since file access is the most time consuming part of generating a webpage, that must be the place to start when optimizing a PHP application. If the core installation of PHP could reduce the number of included files from 76 to say 10 (or even 15), that would mean that 66 files would not be included making the blog much faster loading for the majority of webmasters who do not have caching on their servers.
Another area for optimization is to not include files that are not needed or used. I mentioned in my first post that the WordPress importer file was being included on every pageview even though it is not being used by visitors to the blog. There is no excuse for inefficient programming like this! I could go on and on about what I saw in WordPress' code that makes me shake my head like accessing basic variable information using function calls instead of variables such as wp_header(). But I'm not going to do that now.
If others think that 76 file includes to view a page using the basic core installation of WordPress is horribly inefficient and wasteful, I would suggest they speak up and make some noise. Because as time goes on, WordPress code will only get uglier, more bloated, and slower loading. 76 included files on every page view now, maybe 100 in a couple years, and maybe 120 a couple years after that. It's ridiculous, really.
Lulio Sr: I've been writing PHP code as a hobby for over 5 years now and still learn new things every day.