First of all, I still think the commercials point out entirely valid comparisons, but I always stipulated that the were comparsions of the experiences of the majority of coders. There's a bit of a selection bias here because, since the commercials were made for RailsConf specifically, the audience was by definition already convinced that Rails solved problems endemic to real-world PHP programming. Yes, there are PHP frameworks out there, but they just aren't used that often. I kept coming back to the point that Rails was a response to a particular climate, not just a language or competing framework. We both agree that this response has merit, I thinkI never said a language that didn't enforce certain behavior was inferior. I said that you were pigeonholing Rails as a "structured" approach that forced you to do stuff you didn't want to do, which is flat out wrong. Part of the problem here is that Ruby is a very different language than either you or I are used to. The expressiveness it allows enables all sorts of things we'd never think to do or would think to difficult to do in other languages. I'm thinking specifically of modifying class definitions on the fly, the variety of ways to perform iteration, closures, etc. These are "next level" language features that make any design decisions of the Rails framework much less binding than in other language/framework packages. That would almost certainly apply to ANY framework built in Ruby.There will always be lazy programmers. Rails encourages laziness in the initial stages of writing an app, no doubt. But the need to understand how to write code is not, therefore, rendered moot, but rather deferred to such time a you can't CRUD your way to a youtube or twitter. Keep in mind that this is totally in line with Agile philosophy - you do the work when it becomes necessary, not ahead of time.It boggles my mind that a guy who uses so much open source code would not give more weight to the advantages of a consistently understood framework. It's not just for enterprises picking up projects from other firms; it's new team members. It's ad-hoc plugin development ecosystems. It's having a standard that can serve as a jumping off point for real, critical discussions (even ones that demonstrate Rails accomplishes a task poorly, such as performance problems - having a common framework provides a shared, no-need-to-explain context for the problems any Rails app will encounter at certain loads and scales). The communication advantages a community gets from adopting a common framework are ignored only at one's peril, because those are the guys PHP do-it-from-scratchers (which comprise the bulk of PHP programmers) will be competing with. If and when PHP develops a common framework everybody agrees to work with (which I don't see happening) they'll immediately run into the same pros and cons as Rails (which I know you agree with, which is why you think the comparison is bunk, but I'm simply saying that there's more to it than you give appear to give credit for). This:
If you think that enough development firms are going to pick up one language so that when acquiring projects from another development firm that it will be easier because it’s written in your language, you’re living in a dream world.
is flat out wrong - it IS easier, and I know because I've picked up the projects before.I'll concede that PHP has a long way to go before its a dinosaur; I simply meant that to ignore the trend that Rails exemplifies is perilous. You never disagreed with that, though; just clarifying. Honestly, I think if you ever get a chance to work professionally with Rails for a month or two, you'll see what I mean. Even if you used Ruby for scripting or something, you'll see why Ruby is such a "next level" thing. It's the expressiveness and language-like feel that makes things much less abstract and more intuitive.
Jeremy
· 2 years ago
What, you don't allow ol and li tags? Ugh.
matt
· 2 years ago
The quote you pulled and your response only really show that you didn't get my point (either through my lack of explaining it, or you not reading it closely enough). My point was that you're never going to get enough firms to pick up a single language and framework to make the task of taking over existing projects easier. It's the same for PHP or any other language. There will never be so many firms programming in PHP that it would be easy to move an app from one to another. So with Rails, there will never be enough firms doing Rails development for this to really get enough traction to be a worthwhile argument. You'll always be taking over a Java project or a .NET project or a PHP project. Sure you can possibly say, "We'll only work with Rails code" but the chances of that ever being a wise business decision are unlikely.
As for the last remarks, I think the link I gave you for Chris speaks well to that point.
"You need to be quite a bit more of an advanced programmer to get into Rails."
This type of argument always makes me raise an eyebrow. It can be restated as "Our technology is better, and if you were smart enough, you'd agree." If I have to be smarter to use your technology, then your technology sucks.
You may not have been saying I'm not as advanced of a programmer, but you were about as close to it as you can get without saying it.
matt
· 2 years ago
... I also kind of think whenever I make a well-founded counterpoint to you, you're saying, "Ok, well let's strip that part away." Comparing Rails to PHP w/ no framework is not a valid comparison. Saying you want to not compare based on the potential of a language is basically the same thing. If we're not going to deal with the fact that PHP has the potential to take advantage of frameworks, then we might as well rip activerecords or some other piece of RoR off. Sure Rails CAN do activerecords, but we're not talking about potential, right?
chrisranjana_com
· 2 years ago
Why not compare apples to apples and oranges to oranges? Cakephp vs rails and so on.
matt
· 2 years ago
That's somewhat my point. If we really want to compare Rails to something PHP, then it should be compared against a PHP framework.
Jim Van Fleet
· 2 years ago
I wrote a comment, but it was so long I made it a blog post instead.
All Comments
First of all, I still think the commercials point out entirely valid comparisons, but I always stipulated that the were comparsions of the experiences of the majority of coders. There's a bit of a selection bias here because, since the commercials were made for RailsConf specifically, the audience was by definition already convinced that Rails solved problems endemic to real-world PHP programming. Yes, there are PHP frameworks out there, but they just aren't used that often. I kept coming back to the point that Rails was a response to a particular climate, not just a language or competing framework. We both agree that this response has merit, I thinkI never said a language that didn't enforce certain behavior was inferior. I said that you were pigeonholing Rails as a "structured" approach that forced you to do stuff you didn't want to do, which is flat out wrong. Part of the problem here is that Ruby is a very different language than either you or I are used to. The expressiveness it allows enables all sorts of things we'd never think to do or would think to difficult to do in other languages. I'm thinking specifically of modifying class definitions on the fly, the variety of ways to perform iteration, closures, etc. These are "next level" language features that make any design decisions of the Rails framework much less binding than in other language/framework packages. That would almost certainly apply to ANY framework built in Ruby.There will always be lazy programmers. Rails encourages laziness in the initial stages of writing an app, no doubt. But the need to understand how to write code is not, therefore, rendered moot, but rather deferred to such time a you can't CRUD your way to a youtube or twitter. Keep in mind that this is totally in line with Agile philosophy - you do the work when it becomes necessary, not ahead of time.It boggles my mind that a guy who uses so much open source code would not give more weight to the advantages of a consistently understood framework. It's not just for enterprises picking up projects from other firms; it's new team members. It's ad-hoc plugin development ecosystems. It's having a standard that can serve as a jumping off point for real, critical discussions (even ones that demonstrate Rails accomplishes a task poorly, such as performance problems - having a common framework provides a shared, no-need-to-explain context for the problems any Rails app will encounter at certain loads and scales). The communication advantages a community gets from adopting a common framework are ignored only at one's peril, because those are the guys PHP do-it-from-scratchers (which comprise the bulk of PHP programmers) will be competing with. If and when PHP develops a common framework everybody agrees to work with (which I don't see happening) they'll immediately run into the same pros and cons as Rails (which I know you agree with, which is why you think the comparison is bunk, but I'm simply saying that there's more to it than you give appear to give credit for). This:is flat out wrong - it IS easier, and I know because I've picked up the projects before.I'll concede that PHP has a long way to go before its a dinosaur; I simply meant that to ignore the trend that Rails exemplifies is perilous. You never disagreed with that, though; just clarifying.
Honestly, I think if you ever get a chance to work professionally with Rails for a month or two, you'll see what I mean. Even if you used Ruby for scripting or something, you'll see why Ruby is such a "next level" thing. It's the expressiveness and language-like feel that makes things much less abstract and more intuitive.
The quote you pulled and your response only really show that you didn't get my point (either through my lack of explaining it, or you not reading it closely enough). My point was that you're never going to get enough firms to pick up a single language and framework to make the task of taking over existing projects easier. It's the same for PHP or any other language. There will never be so many firms programming in PHP that it would be easy to move an app from one to another. So with Rails, there will never be enough firms doing Rails development for this to really get enough traction to be a worthwhile argument. You'll always be taking over a Java project or a .NET project or a PHP project. Sure you can possibly say, "We'll only work with Rails code" but the chances of that ever being a wise business decision are unlikely.
As for the last remarks, I think the link I gave you for Chris speaks well to that point.
You may not have been saying I'm not as advanced of a programmer, but you were about as close to it as you can get without saying it.