"Can PHP do this?"

well, as you've pointed out yourself, yes it can.

"for years PHP has been lacking this, so the point stands."

Im sorry? I must be missing the point. How does the presence (or absence) of a particular language feature prove or disprove the point that bkrausz made originally?

"..<snip>...it ignores the tremendous advantage that using good tools can provide."

not really. well, kind of.

so the thing is that if I take the things that (in my experience) work to make a project successful, and I squash them all up into a big ball, and then I take that ball and I split it up into two heaps....one heap consisting of the things that the developers brought to the project and one heap consisting of things that the language brought to the project...and I look closely at the relative sizes of those two heaps....then almost always the heap of things that the developers brings is a lot larger; so much larger in fact that in general the effect of the programming language can be ignored.

That is a pretty general statement, and there are clear cases where it is simply not true, but in general it is true, and I would particularly claim that in the case of a web application and choosing between PHP or Python, it absolutely is true. In the hands of good developers either will solve the problem well, both will provide a good, readable and maintainable code base. In the hands of an idiot, neither will be any good.

"Im sorry? I must be missing the point. How does the presence (or absence) of a particular language feature prove or disprove the point that bkrausz made originally?"

Yes, you are missing the point. I refer to closures, the feature at the core of functional programming, not just any "particular language feature". Functional programming is an extremely powerful tool to wield, and has been absent from PHP since its inception until very recently.

A great developer with a functional programming tool in hand is able to well outperform a great developer who must work around its absence.

Here's a paper that surfaced to the front page of HN recently on the importance of functional programming: http://news.ycombinator.com/item?id=1482797.

This is just one example, but a very potent one, of why language selection matters.

yeah, closures are good.

we really do appear to be having two different discussions, Im neither claiming that PHP is 'better' than Python nor am I arguing against functional programming.

I am simply arguing that the most important thing in a project is the quality of the developers, not the language they chose; and that given a good developer and a choice between PHP and Python I would almost certainly find the relative language features so entirely unimportant that I would choose the language based on stupid things like what language the existing codebase is in, what language the developer preferred and had most experience in and how recently I had been frustrated by the languages in question.

OTOH, I am always willing to debate the relative importance of language features, so by all means lets go there.....

Closures in particular are a very powerful tool in async/multi-threaded environments, but in the stateless/sync environment of a web application environment, they collapse down to syntactical sugar, and solve nothing that cannot be solved in other ways.

The software industry has, by and large, been working around the absence of closures for years....I certainly wont argue that it is better because of it, but to claim that PHP has been seriously crippled by the absence of closures over the years is to entirely overlook and understate the multitude of other problems its users have had to overcome.

"I am simply arguing that the most important thing in a project is the quality of the developers, not the language they chose"

I agree with the first part, but I think the language choice is integral to just how good those good developers can be.

I don't believe for a minute that a great developer can develop in PHP without being seriously crippled by it.

Functional programming has a tremendous amount of value outside of async/multi-threaded environments that cannot simply be replaced by other means. There are real limits to the amount of modularity one can achieve without functional programming, and modularity is key to great programming. I'd point you again to this paper: http://news.ycombinator.com/item?id=1482797

The state and history of the software industry at large only demonstrates that the majority of software developers in key technical positions within the industry are and have been less than great.

But if your argument is that PHP is "good enough" given a bunch of average developers... well then, yes, probably. Certainly plenty of good software has been written in PHP. I'd just argue that with the right developers it's far less than optimal, and that the choice of language could easily be the difference between the success and failure of a complex project.

"Functional programming has a tremendous amount of value outside of async/multi-threaded environments that cannot simply be replaced by other means."

Functional programming, or closures? I said: "Closures in particular are a very powerful tool in async/multi-threaded environments, but in the stateless/sync environment of a web application environment, they collapse down to syntactical sugar, and solve nothing that cannot be solved in other ways."

I made absolutely no statement regarding functional programming in general, and the label 'functional programming' applies to a much broader set of topics than just closures, so I am entirely at a loss as to why you think it makes sense to 'rebut' my statement about closures with something about functional programming?

"There are real limits to the amount of modularity one can achieve without functional programming, and modularity is key to great programming."

I entirely agree, modularity is good.

"The state and history of the software industry at large only demonstrates that the majority of software developers in key technical positions within the industry are and have been less than great."

indeed.

"But if your argument is that PHP is "good enough" given a bunch of average developers..."

LOL.

It really wasn't.

Im glad you like functional languages and closures, you really should check out Scheme - its even MORE functional than Python.

> Closures in particular are a very powerful tool in async/multi-threaded environments, but in the stateless/sync environment of a web application environment, they collapse down to syntactical sugar, and solve nothing that cannot be solved in other ways.

Every feature in every language is syntactic sugar for ASM instructions and solves nothing that cannot be solved with raw machine code. It's precisely the expressiveness of the higher-level features that gives them their power.

"Closures in particular are a very powerful tool in async/multi-threaded environments, but in the stateless/sync environment of a web application environment, they collapse down to syntactical sugar, and solve nothing that cannot be solved in other ways."

Closures allow for abstractions that are impossible to achieve without them. Yes, you can always get the same functionality, but you will be forced to deal with a weaker abstraction.

PHP has closures however.

> (In fact the latest version of PHP (5.3) can, but for years PHP has been lacking this, so the point stands.)

Actually, it's been able to do that for a LONG time. Pretty sure (99.9% sure here) you could do that in PHP 4, and probably in PHP 3 as well (but really, it's been so long, forgive me for not remembering). Different syntax, of course, but yeah, you could do that.

PHP 5.3 essentially just made it more explicit.

Edit: When I say different syntax, I mean slightly different syntax, obvious, because it's Python being reference. The end result, however, is the same.

And, if I may be so bold, the PHP way prior to PHP 5.3 (though still supported), encouraged a cleaner implementation then the 'Cook' example demonstrated in the link above.

Well, I guess I'm asking for trouble arguing against a language I have no development experience in.

A quick Google search shows that PHP 5.2 and earlier seem to support something like the anonymous functions required in the example I linked to above -- via the create_function method. But using it in practice appears to be full of ifs, buts and complexities: http://nz.php.net/manual/en/function.create-function.php#706...

But maybe one could get it work if used with care.

If I were ever chained to a desk and forced to work with a PHP framework like Drupal that does not yet support v5.3, I'd look in to this.

Otherwise I'd choose a language that cares more for concepts like readable code and deep modularity.

Actually, older versions of PHP could do that, too, as long as you pass the function names as strings. $functionName() works fine in PHP < 5.3, though I'm not sure when it was introduced.