but a good developer can write good, clean code in either one.
Every language/IDE combination encourages a 'default' coding approach, I agree that the PHP 'default' coding approach tends to be to create a hopeless muddle of assorted, random crap.
OTOH, which would you rather have...a coder who is currently being 'forced' to write marginally better code in Python than he would in PHP because of the language constructs, or a coder who understands good code design and knows how to apply it?
A good coder will be a good coder in any language, the fact that a crappy coder can be made to look marginally better if they are forced to use Python just doesn't feel like much of a win to me.
(In fact the latest version of PHP (5.3) can, but for years PHP has been lacking this, so the point stands.)
No amount of "good code design" can work around core features that are missing from a language.
The argument that all languages are more or less equal is as nonsensical as saying all cars are more or less equal, or all guns are more or less equal -- it ignores the tremendous advantage that using good tools can provide.
"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.
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.
> (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.
a coder who is currently being 'forced' to write marginally better code in Python than he would in PHP because of the language constructs, or a coder who understands good code design and knows how to apply it?
That's an esoteric question.
A good coder wouldn't choose PHP in first place, unless there are pressing reasons (i.e. a legacy code-base).
Consequently you can speed up your hiring process simply by weeding out candidates who propose to use PHP.
FWIW my hiring process rarely includes a request that candidates propose the language that they will perform their work in.
(oh, and its not an esoteric question. It is a deeply practical one. I desperately want to hire good, pragmatic coders, not people who are only capable of writing good code if they are in an environment that makes it easy)
Well, you probably want your coders to create and maintain an environment that makes it easy to write good code in. PHP has no place in such an environment.
Moreover it's highly unlikely that a good coder would apply for a PHP job in first place.
> Well, you probably want your coders to create and maintain an environment that makes it easy to write good code in. PHP has no place in such an environment.
I agree with the second part, but I think the first part is wrong.
I think he wants coders to create and maintain software that the company will use on a daily basis, in which case, PHP is perfect for that.
Agreed. Even if these two pieces of code might accomplish the same thing, at least the Python version doesn't make me want to stab myself in face whenever I write it:
object.method_name(arg1,arg2,arg3)
(Python's *args and **kwargs are especially useful in these types of situations.)
Although PHP is slowly adding useful modern language features (lambdas, closures), some of the syntax really is terrible. I honestly can't imagine anyone preferring the former to the latter, at least in this example.
I disagree.
Python, by design, makes it hard to write bad code. PHP, by design, encourages bad code.