Sorry … I didn’t realize that flickr, facebook, digg, wikipedia, etc were quick and dirty applications.

I didn’t mean to imply that there aren’t some very good PHP apps out there… obviously WordPress gets a very high approval rating from me, and my favorite Web 2.0 site, Etsy, is a great PHP example.

I just meant to say that a lot of the bad apps out there are in PHP, to say nothing of the custom sites.

I mean, if you, or Jim, or anyone, were to say RoR is better then PHP. I would step in to defend PHP. But not for personal reasons, but because I think you’d be wrong. I don’t think either language is really better then the other, so neither should be placed above the other.

The fact remains, I believe the end-user experience is what really matters. Clients desires, when the client isn’t the end-user/visitor, are another facet of an already complex discussion. One that I feel we don’t really need to enter into in order to finish, or have, the discussion we’re having.

And just because it continues to glare at me even after I’ve basically finished this comment …

“PHP is usually used to do quick, dirty applications.”

Sorry … I didn’t realize that flickr, facebook, digg, wikipedia, etc were quick and dirty applications.

Sorry … I didn’t realize that flickr, facebook, digg, wikipedia, etc were quick and dirty applications.

I didn’t mean to imply that there aren’t some very good PHP apps out there… obviously WordPress gets a very high approval rating from me, and my favorite Web 2.0 site, Etsy, is a great PHP example.

I just meant to say that a lot of the bad apps out there are in PHP, to say nothing of the custom sites.

I mean, if you, or Jim, or anyone, were to say RoR is better then PHP. I would step in to defend PHP. But not for personal reasons, but because I think you’d be wrong. I don’t think either language is really better then the other, so neither should be placed above the other.

The fact remains, I believe the end-user experience is what really matters. Clients desires, when the client isn’t the end-user/visitor, are another facet of an already complex discussion. One that I feel we don’t really need to enter into in order to finish, or have, the discussion we’re having.

And just because it continues to glare at me even after I’ve basically finished this comment …

“PHP is usually used to do quick, dirty applications.”

Sorry … I didn’t realize that flickr, facebook, digg, wikipedia, etc were quick and dirty applications.

The only thing I really think we’re not seeing eye-to-eye on is this developer experience vs. end user experience thing. Because Rails is so well suited to Agile / XP development methodlogies, it’s important to stress that Rails gives developers tools to better satisfy the ***client*** - who may or may not be the end user. The framework does a lot of the heavy lifting in ensuring that functionality can be rolled out quickly, and the language gives programmers the expressiveness to represent ideas succinctly and legibly.

Now, if you’re a startup trying to launch a web app product and gain customers / users, then yes - end user experience matters most, and however you get to end user satisfaction is legitimate (though we can talk about time to market issues). However, if your success is not going to be determined by end users, but rather by a third party paying for the work, then the ability to deliver value quickly and flexibly matters. Rails reduces the effort involved in iteratively rolling out features that elicit feedback from stakeholders.

Now, there’s no doubt that frameworks exist in which one can do very similar stuff in PHP. But the fact remains that PHP is not usually the tool chosen to engage in this type of development methodology. Why is that? It may not be something innate in the language, but it appears to be something innate in the way programmers approach the language.

You may be an exception to this rule, but that’s no basis for not generalizing about how a language is used in the real world. Since languages and frameworks are developed for more than one programmer, it’s important to look not only at what these tools are capable of, but how they’re usually used. And PHP is usually used to do quick, dirty applications. Rails, on the other hand, is used to create much better structured applications - not because the programmers are better, but because the tools are better suited to the typical job.

We talk about better or worse individual programmers, but languages and frameworks are developed with real life programmers in mind. They should be judged by how they’re usually used, not what they’re capable of. That Ruby and Rails are realizing some awesome features and building a community that understands them speaks to the viability of the tool. It’s at least worth investigating.

Of course, you personally are welcome to use whatever tool you want. And part of the problem we’re having here, I think, is that you are taking it VERY personally, with us saying that because we think a tool is generally better suited to its intended application than your tool of choice, that that reflects on you somehow.

No. It reflects on the general state of the developer community and which tools, over the aggregate, best suit programmers in general to web application development projects in general. Of course, the particulars of the situation apply, and comparisons can be made on the basis of a certain application or project, but that’s beyond the scope of the conversation were currently having.

The only thing I really think we’re not seeing eye-to-eye on is this developer experience vs. end user experience thing. Because Rails is so well suited to Agile / XP development methodlogies, it’s important to stress that Rails gives developers tools to better satisfy the ***client*** - who may or may not be the end user. The framework does a lot of the heavy lifting in ensuring that functionality can be rolled out quickly, and the language gives programmers the expressiveness to represent ideas succinctly and legibly.

Now, if you’re a startup trying to launch a web app product and gain customers / users, then yes - end user experience matters most, and however you get to end user satisfaction is legitimate (though we can talk about time to market issues). However, if your success is not going to be determined by end users, but rather by a third party paying for the work, then the ability to deliver value quickly and flexibly matters. Rails reduces the effort involved in iteratively rolling out features that elicit feedback from stakeholders.

Now, there’s no doubt that frameworks exist in which one can do very similar stuff in PHP. But the fact remains that PHP is not usually the tool chosen to engage in this type of development methodology. Why is that? It may not be something innate in the language, but it appears to be something innate in the way programmers approach the language.

You may be an exception to this rule, but that’s no basis for not generalizing about how a language is used in the real world. Since languages and frameworks are developed for more than one programmer, it’s important to look not only at what these tools are capable of, but how they’re usually used. And PHP is usually used to do quick, dirty applications. Rails, on the other hand, is used to create much better structured applications - not because the programmers are better, but because the tools are better suited to the typical job.

We talk about better or worse individual programmers, but languages and frameworks are developed with real life programmers in mind. They should be judged by how they’re usually used, not what they’re capable of. That Ruby and Rails are realizing some awesome features and building a community that understands them speaks to the viability of the tool. It’s at least worth investigating.

Of course, you personally are welcome to use whatever tool you want. And part of the problem we’re having here, I think, is that you are taking it VERY personally, with us saying that because we think a tool is generally better suited to its intended application than your tool of choice, that that reflects on you somehow.

No. It reflects on the general state of the developer community and which tools, over the aggregate, best suit programmers in general to web application development projects in general. Of course, the particulars of the situation apply, and comparisons can be made on the basis of a certain application or project, but that’s beyond the scope of the conversation were currently having.