As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've always had a thing for dynamic code. Code that's really easy to add cool new features to, without doing much work. For that reason, I build lots of dynamic frameworks and use them in my projects. Some are small, some are big.
As an example, I built a small custom error reporting framework that I still use in almost all of my projects today.
Here's a quick example of how it works:
error_reportLibrary.php - This is where all the magic happens. The class and all the methods sits here. This is the file included when the framework is needed.
error_reportConfig.php - This is where my configuration goes (error types, ect). Here's an example of this file, which shall give you a pretty good explanation of how the small framework works:
(the comments in the code should explain what each element does as a setting)
# ------ Main Settings ---------
$error_handlingSettings['errorStat']=true;//set this to false, and I wont display any errors. I don't care what the other errorTypes have to say.
$error_handlingSettings['default_highlight_color']="red";//this is the default highlight color that will be used if no color is defined for a specific errorType
# ------ Open API -------
$error_handlingSettings['open_api']['status']=true;//set this to true and I'll show errors for the Open API
$error_handlingSettings['open_api']['highlight_color']="#0ff";//shall I highlight any errors that occur for this specific type? if so, set this to a color.
$error_handlingSettings['open_api']['onRemoteAddr']=true;//shall I display errors to specific IP addresses?
$error_handlingSettings['open_api']['remote_addr'][]="86.8.168.228";//so I will show to this IP
$error_handlingSettings['open_api']['remote_addr'][]="127.0.0.1";//and this IP
# ------ SQL Core -------
$error_handlingSettings['sql_core']['status']=true;//set this to true and I'll show errors for the SQL Core
$error_handlingSettings['sql_core']['highlight_color']="orange";//shall I highlight any errors that occur for this specific type? if so, set this to a color.
$error_handlingSettings['sql_core']['onRemoteAddr']=true;//shall I display errors to specific IP addresses?
$error_handlingSettings['sql_core']['remote_addr'][]="86.8.168.228";//so I will show to this IP
$error_handlingSettings['sql_core']['remote_addr'][]="127.0.0.1";//and this IP
So as you can probably tell, each error type is simply a different part of the project I'm using the framework on (for example, SQL Core is the database framework I use. So if any db query issues occur, this errorType will be looked at when printing errors).
So for printing errors, this is the syntax:
errorModule::doError("errorType","error messege");
As you can see, there are some extra little things I can do. Like display to certain IP addresses and highlight the error text, which I can confidently say: will not affect the scalability of the framework.
Remember, the above is just an example of the dynamic frameworks I create/use in my projects.
Now, to the question(almost): I've been told by a few of my colleges that dynamic frameworks like the above are terrible when it comes to scalability. Regardless of the fact that they are very maintainable. So if I used the above framework on a web app that got 1M+ requests a day, it would totally screw up...
Now I'm not apposing against their opinion (actually....) but I would like to know why this is? Why is a dynamic framework like the above considered bad for scalability?
I think you're missing the point when creating a 'dynamic framework.'
A lot of my earlier PHP code functioned sort of like this; a class with a bunch of methods and maybe a construct method that set up a state, using globals to track configuration in arrays. These all used a lot of memory compared to a wholly OOP approach; and while yes less memory and faster than an 'off the shelf' solution; nothing compared to the way I design frameworks now.
It doesn't appear you are taking advantage of things like interfaces, abstract classes, both class and interface inheritance and so forth. These types of frameworks do scale because the original code base is so small and take advantage of specific OOP functionality (like PHP 5.x's magic methods.)
Multiply a script that you felt was fast enough running on server that's not taxed very much by say 100 and, you've got problems; and you're running out of memory, hitting pages outs; and things will crawl to the point you're forced to reboot/throw more resources at the server.
Why? Poorly written procedural code that tries to act OOP, even tries to look like it, is just wrapping up old habits in a new package.
PHP is slow and clunky in general. It's high-level, which means each line carries "baggage". It's common that a single line of PHP code will convert to a slew of low-level instructions.
You can still scale 'dynamic' frameworks that rely heavily upon PHP's underlying system, and don't waste a lot of time or memory with high-level abstractions.
In my opinion, large, "convenient" frameworks often cause more problems than they solve once shit hits the fan in a production environment. My favorite teachers always reminded me to K.I.S.S. -- Keep It Simple Stupid.
Of course, If you want truly scalable performance you may want to compile your php with hiphop or write your application in a compiled language like C++ or D.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
We're using ORM in PHP on our team, and I've noted in two separate projects that, even though we've specifically talked about good MVC design at length, that ORM appears to be allowing people to do DB queries from the View layer and creating difficult-to-maintain code.
I'm leaning towards the opinion that ORM makes it too easy to make queries under the covers that the programmer doesn't think about. By returning ORM objects to the view layer the programmer is essentially leaking a database connection to a layer that should not have it.
Am I thinking about ORM correctly here? If so, why is it so darn popular? If I'm not thinking about it correctly how should I address these issue?
I'd say that you're not thinking about it correctly. ORM by and of itself does not promote bad practices, at least, not in the way you're experiencing it.
ORM is a tool, just like any other framework, api or whatever, you can use it correctly or not.
It sounds more like the problem is that the developers in your team doesn't have a clear understanding of the MVC pattern. I'd start with addressing that issue first.
I think it's quite a common problem with the MVC pattern that developers tend to use the views and controllers for things that they aren't supposed to do. The reasons might be many, but whenever you work with something like this, I beleieve the problem usually starts with something similar to this thought:
"It such an simple little thing I'll just do it here instead, there's
no point doing it all over there."
Basically when trying to decouple design and business logic there will always be situations when it's easier to implement some piece that actually belongs in the business layer in the presentation layer. It mustn't mean that the developer is bad, but it might show some lack of experience or laziness. I know I've been guilty of this exact thing several times, like when developing for Android (never professionally though :)).
How about trying to figure out some sample-case that uses some of the bad practices that you've noticed and have some sort of coding-dojo where you as a team make that code nice and correctly implemented, and if you have time, show the actual benefits of having stuff where they belong. I'd strongly advice against using actual code unless you've written it yourself or the developer responsible for that code is okay with being mangled in front of other devs. But this obviously depends on the culture in your company and if the developers are interested and open for these kind of things. I personally would love having similar things at my workplace.
I don't know that having small ORM calls in the view layer is necessarily bad. For example, I might have foreach (Category::getAll() as $Category): as the loop to list categories on a page. The connection doesn't leak into the scope of the view (or at any rate it certainly shouldn't) since it is encapsulated by the ORM. I could assign the result of this call in the controller and pass the array of objects to the template (and I certainly will with more complex calls) but imo trivial cases are fine in the view.
The biggest problem with ORMs in my experience is the growth of "n+1" database query counts. Normally a one:many list on a screen can be rendered from a single query, but ORMs make it extremely convenient to use a primary loop with one table, and then to do an individual select for each instance of the secondary table. This is inefficient, but you'll only notice when your database starts to creak with the expanded number of queries it is having to deal with.
The best guard against this is to ask your developers to run a toolbar in dev mode (such as the Symfony2 toolbar, PHP Debug or similar) which shows them the number of queries required to build a screen. When trivial screens start needing more than 50 queries (or whatever ceiling you specify) then they need to refactor.
Also, it's worth choosing an ORM that has a reasonably expressive query syntax, otherwise your devs will be shirking back to "raw SQL" mode, which defeats some of the reasons of having the ORM in the first place. For the same reason - and Daniel makes this point well - offering training to your devs on using ORMs effectively is a great idea.
Doing queries from views is a bad practice. You can do it, but is better doing it through the controller via Ajax Requests or whatever you consider suitable.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I was reading the article "PHP Sucks, But It Doesn't Matter" by Jeff Atwood.
In the comments he writes:
That said, I absolutely think it's important for PHP devs to be aware of the architectural limitations of PHP, and understand the alternatives.
What are those limitations and how do they compare with other scripting / weakly typed languages?
Also, what are the alternatives in those conditions where limitations need to be avoided?
There are basically two real limitations I see:
PHP is a fully synchronous language. This has impact on which things you can easily implement in PHP and which not. For example implementing a Long Polling driven chat application isn't trivial, because PHP would need block one process per chatter. I'm not saying it's impossible, you can hack around this limitation using some PHP Daemon library. I'm just saying that this is one of the cases where other languages, like JavaScript, are more appropriate (NodeJS).
PHP is slow. Please don't understand this an an offense. It's a fact that PHP - as implemented by Zend - is slow compared to other scripting languages. This typically is no problem when building websites, but you obviously can't do certain things: Implementing a ray tracer in PHP is definitely a bad idea - whereas in JavaScript you could do this.
But apart from that, I think that PHP is pretty multi-purpose. You can use it for nearly anything - and I do ;)
Take a look at the date. The article was written in 2008.
It means, that if you'll see the PHP5.3 advantages, you'll find there many things, like closures and namespaces, which were in other languages before. Some of them is already affected the architecture of famous frameworks, like Symfony.
And that list will never be complete.
Meanwhile, I meet a lot of people who think that "weak typing" language is an architectural problem itself.
Then, some people think that inline regex syntax is good thing in, for example, JavaScript, but others think, that "different language" must be written down in string constants there, as in PHP. Etc.
I'll take a stab at this without getting too into the nitty gritty:
The initial design of PHP as a collection of functions still shows through.
Object-oriented patterns that have been implemented in the latest PHP 5 releases are still half-baked and lack multiple inheritance (or "mixins"), proper module support, and are designed to be backwards compatible with the CoF (collection of functions) design.
Method overriding and callbacks are not supportive natively.
Closures. They are there, but they are very weak.
Errors vs Exceptions — methods are inconsistent in which they use (thanks again to CoF design), and error-handling is half-baked.
I'm sure I'm stepping on someone's toes here and I'll get any angry mob, but I'm also sure that I still didn't hit everything. It's largely subjective, but it's easy to see what is to dislike when you stack PHP up next to Ruby or Python.
I don't find it odd anymore that all of "PHP SUCKS" articles are coming from developers accustomed to established Microsoft technologies.
What I do find odd are statements that indicate that PHP is a spaghetti code. It's completely up to the author of the code whether the code will be spaghetti or if it'll use certain design rules when approaching the problem.
The reason a lot of PHP code out there is spaghetti code is because examples and tutorials are such that they don't teach beginners the good coding practices. Also, people are quick to grasp examples like hello world or connecting to MySQL, doing a query and looping over the result - but that's it, that's where ALL tutorials stop. I still haven't found a tutorial that covers the following:
what is a framework and what it helps with
what are data structures and data types (explained in a way a normal human can understand)
what is an array, what are array dimensions, how do arrays work, what are arrays useful for
what is object oriented code, why object oriented code, how does PHP do it, what is considered good, why are there patterns out there and so on
As you can see, a beginner programmer won't be bothered to learn all of those points outlined above, I know that because I was a beginner too and did all the mistakes beginners do. However, even if someone doesn't know how to program, they can still create useful applications.
Many popular scripts were written by people who knew WHAT they want to achieve, however they did not know HOW to properly design the environment (framework) in which they'll deploy their php code.
That's why we see scripts that become incredibly popular due to the ease of their use as a regular user which are hard to extend looking at it as a developer, using weird function names, odd coding conventions and no commenting.
Also, what's ridiculous is saying PHP is slow which is absolute nonsense. When I come across such statement, I want to shoot myself in the head for reading such a blog entry.
One has to know several things before making such a statement:
PHP is a scripting language, that means the interpreter is invoked every time someone requests a PHP page which takes A LOT of CPU power. That has been addressed by using bytecode caching mechanisms such as APC which stores the copy of pre-interpreted piece of the script in memory. The results are impressive, and I kid you not - execution for some of my scripts goes from 20 milliseconds to 1 microsecond, where some benefit "only" 5 times. That's on a system that serves 1 thousand concurrent users. Now, if someone wants to tell me that 1 microsecond is slow (or 5 milliseconds) - I'll take that as bullshit.
PHP is not the only thing involved in serving a web page. There's also underlying server (Apache) which has its own issues, there's MySQL which runs queries - and who says all queries are optimal? There's the network, there's the hard disk, there's the CPU, there are tons of other processes. Configure Apache with PHP-FPM, optimize MySQL to perform good on 8 core machine with 16 gigs of ram, use APC, use Memcache - and voila, you're getting an incredibly fast, scalable system capable of serving an incredible amount of traffic.
Languages that PHP is being compared to are often "compiled" into the bytecode and then executed by
You can extend PHP yourself. Assuming a PHP function is slow, NOTHING prevents anyone from creating a .so in C that is able to do the job faster and then hooking everything up trough extension in PHP. Not that I know what would such job be that would require that, but such a thing IS possible.
Sadly, and I say sadly because I respect certain programmers and admire their work (and I'm by no means a PHP fanboy) but it hurts me when I see uneducated, inexperienced and subjective comments about a tool which spreads misinformation.
As for why big websites use PHP - because it's fast. Because they laid proper foundations before starting the projects. Because it's free, extensible and scalable. Because it follows C syntax. Because you can extend it when you need it to be faster. Because it runs on a free operating system. Because it's easy to use.
PHP is improving everyday. It is open source and used all around the world. That said, when you have a problem, it is most probable that you will find your solution or get help faster than any other language.
The very reason of this article, I believe it is simple. If you (or in that matter any other programmer) used to code in C++, Java etc.. they had a lot of possibilities such as OOP coding and PHP was limited in the beginning.
It is a good thing that PHP has many built-in functions / methods / classes so you don't have to spend hours to code some function / class / method which PHP already has.
You don't have to (and you shouldn't) try to memorize all these functions. It is useless to memorize all of them (which one is doing what, how to use it etc). Imagine you are working on some project which took you 4-5 months to finish (yeah big one (: ) You are not going to use all these functions in all the projects and eventually you will forget what they were doing since you don't use them often.
The point is, you should know the syntax of PHP. When you need to do something, check first if PHP already has what you want to do in its library. Check the manual to see how to use it. This way, you will also LEARN (NOT MEMORIEZE) the ones you use often and this information will be hard to forget.
PHP or any other programming language is just like a normal language which we humans use daily to communicate with each other. If you don't use it, you will forget.
PHP 5.3 and above brought many features. Static feature is one of the biggest feature for me. It made my life so much easier that I can't even begin to describe.
Since PHP is that famous and open source web scripting language, Facebook developer team created HipHop.
What HipHop does is, takes the data from PHP and sends it to C++. C++ does all the process and sends back results to PHP for outputting.
The whole idea of HipHop was to make Facebook use less servers & improve the page display times.
Now you tell me if this seems limited and / or slow to you?
i dont think there is anything like 'architectural limitation' for php. developer knowledge limitation might be the reason. read this http://www.quora.com/What-is-Facebooks-architecture . most of the time, non-world-class developer does not know how they could use php to its full capabilities.
I would assume he is referring to the fact the the OOP portions of PHP are not the greatest compared to languages that are purely object oriented.
Architecture Limitations in Addition to nikic's answer
Writing extensions for PHP is a PITA. Not as bad as with Perl or Java, but not as easy as it could be. The ease of extensibility champion is still TCL which hails from the early 90's. Nearly any C function taking char* can be made into a TCL extension.
Embedding PHP in other systems. mod_php, gtk.php.net shows it can be done, but Guile and TCL are much easier to embed.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
It is widely believed that PHP is the easiest programming language to learn for a beginner. The argument goes that PHP is the easiest language to use for getting a quick prototype up-and-running.
Why might this be? What, specifically, makes PHP easier to use than other languages?
Would this remain true, even when learning to use the object-oriented aspects of PHP? Or is it actually the object-oriented aspects of PHP that make it easy to learn? How does it compare with other web programming languages?
PHP is native to the web. While Ruby and Python have much cleaner syntax, more elegance, and more power, there will always be a layer of abstraction between Ruby/Python and the web itself -- after all, they were designed for much wider domains than the web.
Newbies to programming are typically newbies to sysadmin, and getting to Hello World in a Rails or Django is pretty painful -- for some even prohibitively so -- compared to PHP.
For newbies, it's easy to conceptualize that typing in:
http://mysite.com/something.php
...will execute the code stored in the file:
/path/to/mysite's/webroot/something.php
This simple one-to-one routing also mirrors that of HTML and other static files.
Beware, however, because this one-to-one routing also leads to security problems (i.e. people tend to keep all of their executable code within the webroot -- even secure code, which may contain passwords, hash salts, and other Privacy-Important code). Combine this with a lack of sysadmin experience, and many sites on the web are a chmod away from being totally exposed.
Responsible PHP like Symfony helps people avoid this, but Symfony requires the same level of sysadmin chops as Rails and Django.
Object oriented programming is optional
PHP is forgiving
The script continues running on minor faults.
When E_NOTICE (or even E_WARNINGs) are suppressed, the errors aren't even noticeable.
But also in the small things like substr: In C# you'll get a big fat exception when you'll try substr($text, 3) on a $text with 1 character.
Great online manual
http://php.net/manual/
Quick and Dirty is the default
The language is filled with useful shortcuts.
PHP lets me express what I want without typing an essay.
Conceptual simplicity.
A php site can consist of one file representing one page, with the dynamic content embedded within the static markup as needed. You can scan down a simple php file and see everything defined and run sequentially.
With a simple php site, there is no learning curve where one has to figure out in what file a specific piece of logic belongs, or in what external file a function has been defined.
...
Of course there is a reason that frameworks like rails provide lots of files and a fixed structure, and I would definitely recommend using one for any sizeable (and probably almost every small) site.
I do think though that it's this very low barrier to entry that is responsible for a lot of php's popularity.
I don't think that there's any reason a better php style system couldn't be written in ruby or similar - think just directories and .erb and .haml files and nice 4.days.ago syntax. But most people who could do this see the value in the extra tools that a framework provides. Sinatra is a minimal framework, in which it's possible to define an entire site in one file, but even it has routing powered by code instead of just directory and file naming.
PHP have many web tutorials and books about it, it's free and popular which makes PHP communities bigger. And also it's intuitive.
While PHP is far from the best web programming language, it's the most common (in terms of availability in hosting packages), the most popular (even in things like tags here on SO), it has some of the best documentation, and it's one of the least strict in terms of having to follow any sort of standards.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a project with very messy code - lots of duplication and dead code here and there.
Some time ago there was zero code coverage by unit-tests but now we're trying to write all new code in T.D.D. manner and lowering technical debt by covering "old" code by unit-tests as well(test-last technique).
Business logic's complexity is quite high and sometimes no one can answer whether some methods are used or not.
How this dead code methods can be found? Extensive logging? Higher test coverage?(It is not very easy because customers want new features to come out)
xdebug's code coverage tools allow you to test which lines of code are actually being executed, without needing to put trace statements in all of the functions/methods.
Example:
<?php
xdebug_start_code_coverage();
function a($a) {
echo $a * 2.5;
}
function b($count) {
for ($i = 0; $i < $count; $i++) {
a($i + 0.17);
}
}
b(6);
b(10);
var_dump(xdebug_get_code_coverage()); // array '/path/file.php' => array line_number => int 1 or 0.
?>
It's a little late now, but PHPDCD claims to do this statically, which should give you a much more informative result than having to profile actual code execution with xprof / xdebug.
I don't know of a way to detect code that is completely unused, that may be beyond the abilities of all the tools out there. But in terms of the tools out there, hit https://phpqa.io/ for a good rundown of them.
So far, one of my favorites in phploc which tears apart your code from an Object Oriented perspective and gives you details on how many classes vs how many functions vs how many tests vs average loc per function vs Cyclomatic Complexity.
My next favorite is phpcpd which is the "PHP Copy-Paste Detector". It tokenizes your entire codebase, looks for common signatures, and gives you a list of files with line numbers.
There are lots of other tools on that page, choose the ones that are useful to you.
We're actively using these tools in web2project and in the two years since we forked from dotProject, we've dropped about 35% of the codebase from refactoring, eliminating duplication (originally 12%, now about 2.5%), and generally structuring things better. And that's counting our 15k+ lines of Unit Tests. :)
I would recommend running through the system with xdebug profiler (http://xdebug.org/docs/profiler).
Run through the system the view the logs with http://code.google.com/p/webgrind/ and physically see what's being called.
Regarding profiling tools, if you decide to go that way you may take a look at xhprof http://developers.facebook.com/xhprof/
It has smaller size of the output files and web interface that you could embed into your app for continuous tracking. It is able to generate visual representation of call tree. I recommend it over xdebug for that purpose.
See the SD PHP Test Coverage Tool. You exercise your code any way you like, including (or not) running test suites any way you like. At the end of execution, you can see a display of what code was executed (there are screenshots at the website). Code that is not executed may be dead, and requires some more analysis on your part, but if you exercise the system well, unexecuted code is either error handlers or really dead stuff. The PHP Test Coverage tool does not require any changes to your PHP server.
The SD CloneDR tool finds duplicate code across very large source code bases. It is language sensitive (covering C, C++, Java, C#, Ada, Fortran as well as PHP4 and PHP5) so it isn't fooled by changes in formatting, whitespace or the presence or absence of comments. It will detect exact copy clones, and near miss clones. The website shows example clone reports for several languages.
I believe that someone has implemented a flavor of Structure101g that uses xdebug data - s101 will then detect any unused clusters, i.e. files that use each other but are disconnected from the main codebase.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm not a fan of PHP or spaghetti code, or anything like that, but in my experience WordPress works amazingly well, it's well organized, and I've never come across any hard to understand code. The documentation is incredibly thorough, any security flaws are fixed within seconds, and it "just works". Not to mention that it does EVERYTHING, and it has an awesome plug-in system. Oh, and "the Loop" is awesome. I've never had any problems doing simple modifications to the code or to themes.
Can you guys give any specific examples of what you don't like about it, or what you would have programmed differently? I just don't understand why it gets such a bad rap. I wish my own software worked as well and had as many features and looked as nice.
I'm a fan of WordPress, but there are definitely issues that impede coders trying to work with it. As a small example, there's get_the_content() (returns) and the_content() (prints), but there's get_permalink() and the_permalink(). Then, there's just the_date(), because it accepts an argument indicating whether you want it to print or return. This kind of thing drives even an experienced WP person up the wall, because you've always got to be Googling the usage - and it speaks to a deeper lack of attention to detail in the code.
Another glaring issue is the lack of built-in caching. It even used to have it, but they ripped it out and never replaced it. You shouldn't need a third-party plugin to have basic caching in a system like WordPress, particularly with all the other bells and whistles it builds in.
To paraphrase (supposedly) Churchill, though, "WordPress is the worst blogging system... except for all the others".
I've written many custom applications in PHP/MySQL over the years - from tiny to huge. Not having taken the time to learn the details of WordPress, I find it very frustrating to work with (under the hood).
Subjectively:
Very poor naming conventions
Execution flow is bizarre
General lack of organization
Hard to audit what happens when
etc...
Their concepts of usability is great, and support for plugins is also great. I'd just love to see the system re-engineered with those principles, but with a disciplined and clear development methodology.
I'm sure the next guy would say "no it isn't, bla bla bla", but that is just my opinion after bumping into it (hosting, modifying) about 3 times.
It's a subjective question for sure. From experience I've notice WP takes way, way more server resources than other systems or my custom code. I've had to move WP sites off my servers as a consequence. So my experience suggests there are some memory use issues.
As an exercise try going through the code, tracing the logic from the start of a request to a page, and look at how many objects are loaded, how many methods are called before any HTML is output.
Apart from what's been mentioned already:
No sane templating system. All those years and they still have PHP code intertwined with HTML, and default templates that have no support for i18n or l10n whatsoever (hard-coded strings, hard-coded date formats, etc.).
Multiple entry points - maybe it's just me, but it's annoying. Especially when some of those are way too big.
When you have to be sure of a statement that is made by "everyone", if you can, is trying to check it for yourself.
And you can do something in your statement: just read Wordpress source code. Some modules are good, some are a mess, some others are just normal. But all of them compose a great blog system that are used by thousand of people around the world that are more interested in writing good stuff instead of complaining about "how ugly" is a particular source code. In summary, the Wordpress creators have a shippable product that is useful.
In the end, it doesn't matter. If you want a perfect blog system, you can always write one yourself.
Can you guys give any specific
examples of what you don't like about
it, or what you would have programmed
differently?
I would have added more comments.
On a separate note, the most recent version of Wordpress introduced a labyrinthine piece of code that denies access to pages that:
1. Aren't in a menu or submenu
2. Aren't in the $_registered_pages variable.
A lot of plugins for earlier versions of Wordpress have been broken by this new security measure.
Finally, sessions. Wordpress does its very best to get out of your way by handling all its session data in a separate manner from PHP's built-in $_SESSION variable, but it doesn't give you the option of starting the PHP session, you have to add that to the core program yourself. I haven't found documentation that would allow us WP hackers and plugin writers to take advantage of the pre-existing WP session yet, either.