Some of the other talks at the Creativity World Forum look interesting too. Steve Wozniak's talk, for example.
The Cleese video is down, but many of the other videos, such as Wozniak's, are still up.
EDIT: It appears all the videos on the site are abridged. The Cleese talk on Youtube is probably the same as appeared here before the video was removed.
(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.
If you have to ask this question, you're out of your technical depth.
The best thing you can do is promote the guy who's clamoring the loudest to steer clear of PHP to technical lead, and defer all future technical decisions to him.
The language is just a tool. Consider car racing. If you have a poor driver in the fastest car, it won't make a difference. No matter how fast the car is that he's driving, he's going to lose. And if you have a great driver in a slow car, no matter how good he is, he's going to be limited by the speed of his car.
If you have a poor technical lead, it won't matter what language you choose. You can give him a great language, but he will not understand and take advantage of its best features. If you have a good technical lead, but you choose a bad language, the quality and pace of his development will be forever limited by the language.
(And in the context of a team, the abilities of the team to make good technical decisions are limited by the technical direction your technical lead sets -- which is why you need the most talented guy in the position of technical lead.)
The guy on your team who is the most against using PHP is likely the one who best understands the ways in which PHP will limit your team. You do not have the deep technical understanding to make these judgments, and for that reason (without taking months of hard work to gain such understanding) you should defer to him.
Yes, some of the largest websites are written in PHP. But you do not have the same level of resources to throw at the problem that they have.
You're also starting your development at least 5 years later than any of the largest websites that you refer too. Frameworks/plugins/communities evolve quickly. There were more reasons 5-10 years ago to choose PHP then there are today. Companies that have already written millions of lines of code in PHP will find it very hard to switch to another language -- but you do not have to deal with the weight of such legacy issues.
As a small team, you need to look for every advantage you can get. Choosing a programming language that makes your developers more productive is an important part of that.
If you care about framework, community and plugins, Ruby is also a better language than PHP, and Rails provides these three things in spades. Assuming you don't have a good system administrator on your team, companies like Engine Yard and Heroku provide scalable managed Ruby on Rails hosting -- so you can outsource combating issues like down-time and data loss.
"The guy on your team who is the most against using PHP is likely the one who best understands the ways in which PHP will limit your team. You do not have the deep technical understanding to make these judgments, and for that reason (without taking months of hard work to gain such understanding) you should defer to him."
sorry, what? the guy on his team who is most against using PHP could equally well be an idiot who is simply repeating stuff he has heard on the web by rote, using regurgitated puff to hide his complete lack of understanding of both the issues and the languages themselves.
Your willingness to entirely overlook that possibility and to make the kind of sweeping statements you have made in your post in the absence of any data causes me to doubt that you have the kind of experience and technical expertise that is required to make that kind of statement.
I don't envy the position of any non-technical person that has to make key technical decisions on a technical project.
Ultimately it takes a good developer to spot a good developer, so a non-technical person seeking to build a "robust web application" starts at a huge disadvantage.
Without understanding the pros and cons of each language choice, all he can do is gamble on finding a smarter person than himself that he can trust. I'm advocating he choose the anti-PHP guy, slightly tongue-in-cheek, because given the limited amount of information presented, that choice gives him the best odds.
Being in the position of having to make such a bet is less than desirable, but given his lack of technical knowledge, what else would you have him do?
Im not clear what makes you think the OP is a non-technical person? The question he phrased was the exact question that he should have asked, what is unfortunate (but unsurprising, given the complexity of the answer) is that nobody seems to be answering it clearly.
He asked:
"How will it impact my webapp if it is written in Python and not PHP"
That is a fantastic question, and it deserves better responses than the 'language x sucks' ones it is mostly getting.
The simple fact that he asked the correct question gives me a great deal of faith that he is in fact technically inclined, technically able and has some development experience. The way in which it was phrased makes me believe that english is not his habitually spoken language.
He clearly does lack experience in using Python, and is (quite reasonably) hesitant about plunging into a different language without attempting to find out more about it.
"I'm advocating he choose the anti-PHP guy, slightly tongue-in-cheek, because given the limited amount of information presented, that choice gives him the best odds."
it really doesn't. some quite ridiculously stupid people are anti-PHP.
Given the information available, I would advocate that he use the language that the majority of people on his team are most familiar with. Nothing like having a team learn an entirely new language and associated design skills to bog down a project.
"gives me a great deal of faith that he is in fact technically inclined, technically able and has some development experience."
I'm sure he has development experience. But too limited an amount.
It is a valid question, but I don't think any response provided here can properly demonstrate to him the value of a language like Python over a language like PHP. No more than someone could teach him to fly a plane in the span of a post like this. It's not a simple subject, by any means.
The best anyone can do is point him to resources that he could study and learn over a period of time -- or advise him to listen to someone talented that he trusts.
I'd be very careful listening to anyone advocating PHP for a project starting from a blank slate. Yes, there are talent developers that prefer PHP. And there are many more poor developers that prefer PHP as is the most popular default choice for those that lack experience, are not comfortable with their own technical judgement, or believe that all languages are more or less equal.
Many on HN would argue that a top-tier developer would not choose PHP, period. But you may not be able to get hold of a top-tier developer -- and in that case a team of solid PHP developers may be the best available choice, if not the best possible choice, particularly if you've worked with them before, and the project is technically simple and limited in scope.
I agree on the power of inhibition, but I think the second point you alluded to is the larger one -- the ability to remove the stimulus.
Certainly it's hubris to believe that one can exercise "free will" to remain completely uninfluenced by one's environment. But what we can do is exercise a measure of intelligence and free will to anticipate the relationship between stimulus and response, and alter our environment accordingly.
I.e. if you're trying to lose weight, don't allow yourself to be exposed to fast food advertising.
Our brains may be heavily influenced by our environment in ways that we are not normally aware, but the existence of studies like these shows that we can begin to understand the dynamic of influence. Once we have understanding we can take appropriate measures.
As I see it, that's the true power of intelligence and human agency.
After all, as you point out, animals also have certain powers of inhibition. But none have the ability to comprehend their own minds and alter their environment accordingly.
When web applications are available on all devices, but work better on some devices than others, people have an incentive to switch -- and that puts pressure on Apple to keep their browser competitive.
Note the large number of people that make video game console purchasing choices based on how well their favorite cross-platform games perform on each of the respective consoles.
