ircmaxell

> Pretty much every PHP app in the world shares a database. So you've shifted your scaling problems from an area that programmers understand and control to a 1-MLOC mystery.

True, however in my experience it's pretty easy to scale the database layer. One beefy DB server can easily handle 2 or 3 front end servers with even mild caching. If you get aggressive in the caching strategy, one DB server can handle up to 10 front end boxes. And if you need to scale beyond that, replication is a well understood paradigm (sure, not by normal app developers, but there's plenty of resources out there).

> I bring this up because I have a few friends who make their living saving the asses of PHP programmers who buy the notion that PHP is magically easy to scale.

I never said that it was magically able to scale. I said that the language is easy to scale. What you do with it is on you. So if you're writing garbage code, you're going to get garbage scalability...

My intention was the full process from creating the first file, to getting a server to serve the content is far easier to do in PHP than Python (granted, in Python it's pretty much boilerplate, but there's a lot more than needs to happen).

As far as the benefit of first-class vs libraries for handling the request, that's something to consider (as there are arguments on both sides)...

A very important difference for a C developer. For a PHP developer reading C, it's a pretty good analogy that gets the point across without causing too much confusion...

@jakejake Wordpress uses a procedural version of the mediator pattern (just like Drupal's hooks).

As I said in my post, just because an application doesn't use classes, doesn't mean it's not OOP or borrowing OOP patterns (and Drupal is actually a pretty good example of that).

Well, that just executes code. That doesn't alter your application flow, unless you do that during runtime at (for lack of a better word) cutpoints. And if you do it there, it's basically Chain of Responsibility, without the "chain can be cancelled" part.

Just because the pattern has a name, doesn't mean it can't be simple. In fact, a lot of the patterns are implemented all over the place under different names and with slight tweaks.

An important point is to understand the difference between the patterns, and know how to identify them. You can call a cow a lion, but it'll still moo just the same...

If that's all that your code does, then that's fine to use #1. But in a larger class, it's needlessly cluttering the class with operations below its abstraction level. Why should a logger care about file locks and the such? Why should you care about file locks when editing the logger? Hint: You shouldn't normally.

As far as "the complexity is hidden", you're absolutely right. I want that complexity hidden. By hiding the complexity in this way, I can reduce duplication and at the same time make the code far easier to read. Sure, you do need to dig through more levels of abstraction if you need to debug something. But abstracting in this way enables bugs to be fixed far easier, since the methods are really small and simple, the "ripple" effect is far easier to understand and contain.

Think about how long it took you to understand what log() did. With the first one, you needed to parse a whole lot of detail (including the flag passed to fopen, the two exception checks, the arguments passed to flock, the fprintf declaration and the flock call arguments). With the second, all you needed to do is read the two steps: 1. createLogMessage() and 2. file->append($message). At a glance you know what the method is supposed to be doing.

Why is there such a hang up that people want to know what code is doing at all levels? If you name your APIs well, you should be able to look at the method's name (and perhaps its arguments in some cases) and know without a doubt what it's doing (at least to the abstraction level the API is designed for). If you really need to know details, you can go deeper, but I know when I read $file->append($message) that I'm appending a message to a file. I don't need to worry about anything else 99.9% of the time. So I'd rather get the clean win with well named APIs, than spend my time sifting through methods like the first one...

Thank you for the comments! My point wasn't to show how wasteful or bad rainbow tables are. My point was that brute forcing is actually significantly easier than people realize (to the point of being almost as efficient as rainbow tables depending on the circumstances). And since any standard measure that prevents brute forcing will also help prevent rainbow tables, the point that I was trying to convey is that you should not try to protect against rainbow tables exclusively, but you should try to protect against brute forcing and get the rainbow table protection that comes naturally from that step...

With respect to the 4 character password limitation, that was mainly to show how powerful brute forcing can be, not how bad rainbow tables are.

Sure, you can make a dictionary rainbow table based off a normal english dictionary with perturbations (caps/symbol replacements) and have it be more efficient than a brute force for any size. But I was looking at it form a guaranteed match aspect, not a "probable match". So for a guaranteed match against an 8 character password, the rainbow table would have to be gigantic, but brute forcing would likely not take as much time.

Perhaps I should have presented it a bit differently. But I purposely wanted to take the worst case approach to demonstrate just how efficient brute forcing can be. If that painted a slightly tainted picture, then fine. But I think it got the point across (although how it got it across has been questioned)...

The point was that a good programmer is a good programmer regardless of their tools. And a bad programmer will always be a bad programmer no matter how much their tools do for them.

Spend time becoming a good programmer, and you'll be better off in the long run. If you don't want to spend that time, go find another profession...