7 ms·

PHP became such a huge success for a few reasons. It's easy to deploy. You just have .php files that execute code in <? ?> tags. It has a bunch of framework-

by mdasen 17y ago

PHP became such a huge success for a few reasons. It's easy to deploy. You just have .php files that execute code in <? ?> tags. It has a bunch of framework-type things built in such as all the database connector functions, session handling, and it returns HTTP responses easily. What really bothers me about this article is that the author goes after Rails without knowing anything. He says that Rails is slow. That simply isn't true when compared to PHP frameworks. Rails is many times faster than CakePHP. And Rails has a ton more features. It's all well and good to just spout off that Rails is slow, but actual investigation proves that in the real world it isn't true. See: http://video.merbcamp.com/public/katz3.mp4 http://video.merbcamp.com/public/katz3.mp4 http://avnetlabs.com/php/php-framework-comparison-benchmarks http://avnetlabs.com/php/php-framework-comparison-benchmarks Lerdorf doesn't even seem to know that scaffolding really isn't Rails. He just comes off as someone who doesn't actually know or get the technological landscape.

cesare 17y ago
I don't think that Lerdorf (btw, not Lerforf) doesn't know what he's talking about. He's just saying that frameworks like Rails are inherently slower, and all the magic (like scaffolding etc.) isn't really worth it. He also says: > Ruby as a language is great, I think it's a really clean and nice language. There just aren't that many people who know it well.
- benatkin 17y ago
  Here's what he said: "But there are performance issues with the scaffolding and stuff, and they recognise that, which is why the new build will be better." Any rails dev could tell you that scaffolding is irrelevant to the performance of a typical rails app. Yet he mentions "scaffolding and stuff". Also, DHH has said numerous times that scaffolding is mostly just a development tool. I think people who still trot it out as one of the problems with Rails are deliberately ignoring what he said.
  - jonknee 17y ago
    I think it's a fair knock because it is so prevalent in the screencast (which he mentioned). If it's in the sales pitch, it's fair to knock.
    - davidw 17y ago
      It's a bit like saying Ford cars are crap because they don't fly well. It's knocking the wrong thing.
      - jonknee 17y ago
        I don't follow... Ford doesn't sell their cars by showing how easy it is to make them fly.
        davidw 17y ago
        Scaffolding does not make Rails fast or slow. It's code generation that happens prior to run time.
    - jamesbritt 17y ago
      "The" screencast? Maybe in 2004 there was The One Rails Screencast, but their numbers are now legion. Referring to a screencast that's four or more years old so as to knock something today is dopey. It would be like complaining today about PHP3 speed and syntax. Seems pretty clear Mr. Lerdorf has very little knowledge of Rails, and likely very little interest in changing that. "But when they needed to do something real, they thought, 'Oh crap, I don't know Ruby very well!'" Pretty sure that's true for people who hear good things about any [Perl|PHP|Python] framework and decide to pick it up. Usually people then just learn the language. PHP might have a brighter future if its BDFL wasn't so myopic about other languages.
      - jonknee 17y ago
        > "The" screencast? Maybe in 2004 there was The One Rails Screencast, but their numbers are now legion. Referring to a screencast that's four or more years old so as to knock something today is dopey. It would be like complaining today about PHP3 speed and syntax. Visit Ruby On Rails' homepage (http://rubyonrails.org/ http://rubyonrails.org/) and click "Screencasts" on the top menu bar. Click the first one, "Creating a weblog in 15 minutes with Rails 2". Watch. That's what I'm referring to, but it's not much different than the original screencast you're referring to.
- andrewvc 17y ago
  I hope he sees the hypocrisy in being the creator of a slow (relative to Java/C) language which had a selling point of being productive and easy to use criticizing the next generation of web programming (frameworks) for having these exact same attributes compared to what he made. Also, the PHP framework world blows, I tried Zend's Framework, Cake, and Symfony when I had a boss that refused to use anything non-PHP, and they just don't have feature parity with Rails (though this was a year ago). They also don't have as many mature plugins available as Rails (and a web programming language lives and dies by its libraries).
  - NathanKP 17y ago
    Comparing an interpreted langauge like PHP with C speedwise doesn't make any sense. Even Java is semi-compiled to an intermediate form unlike the strictly interpreted PHP. Also, in my experience there are plenty of libraries available for PHP. It comes with a lot more built in functionality than other languages. What I like about PHP over Ruby is that it has a more comfortable C-like syntax. In comparison Ruby is more like Basic than C. When I use Ruby I miss the simple curly braces of C or PHP. In my humble opinion that is a much better way of defining blocks of code.
    - benatkin 17y ago
      It makes sense in the context of PHP's creation. When PHP was created, web apps were still commonly written in C/C++. PHP is much older than Rails, even if you don't count PHP 1 or 2.
    - eru 17y ago
      > In my humble opinion that is a much better way of defining blocks of code. I also don't like Ruby's syntax in this regard. However I long for the simple ways of Haskell, Clean and Python here, using indentation.
    - andrewvc 17y ago
      Comparing a language like PHP to a framework like rails makes no sense either. That was my point.
deleted 17y ago
[deleted]
qeorge 17y ago
I think you've missed his point a bit. He doesn't like code generation in general, which would mean he wouldn't like CakePHP's scaffolding either. If you read other interviews with him I think you'll find he's surprisingly modest about the whole thing. I've never heard him hold PHP up as particularly better than any other language, and he's the first to admit that it can be messy. FWIW, I'm a huge fan of CakePHP and I use it daily (although I don't have much use for scaffolding). Its plenty fast if used correctly, which is a common feature of any good framework.
idlewords 17y ago
The link you yourself cite shows a fourfold speed advantage for procedural PHP over ROR. Not mentioned is the large memory footprint of a Rails process compared to a procedural PHP page. It's the usual phenomenon of trading off development time and complexity for performance. I'm sure if you wrote a web app in C, it would run even faster. Rasmus's point in the article is that as soon as you move away from simple apps under light load into real applications, it is no longer enough just to rely on Rails magic. You find yourself needing to understand the innards of what is a very complex environment, and dealing with an idiosyncratic development community that considers monkey-patching a neat programming techinique, and likes to publish its documentation in video format. He doesn't seem to me to be saying 'don't use Rails'. He's just pointing out you should be fully aware of what you're getting into. Caveat scriptor.
- dasil003 17y ago
  Rasmus's point in the article is that as soon as you move away from simple apps under light load into real applications, it is no longer enough just to rely on Rails magic. This seems backwards to me. I consider PHP to be ideal for simple apps. Rails comes with a certain amount of overhead (memory being the most important as far as cost is concerned), therefore I think it's only really useful for applications of a certain complexity. What makes Rails useful are some basic architectural assumptions (MVC + a bunch of low level assumptions / web helpers) that are surprisingly applicable to a large chunk of web apps. The magic is just some Ruby tricks to streamline things, but you don't "rely on it". Where Rails tends to fall down are limitations of the Ruby runtimes, or applications where the web front-end is not a significant enough part of the problem to warrant the Rails approach. PHP is similar in some ways--it includes many web-based assmptions, but it doesn't make any architectural assumptions, which means there is no way to benefit from common conventions (eg. knowing where to look for a certain file or class definition, what a variable or database table should be named, where is the default place to put certain types of logic, etc). As such, PHP is better than any other raw language for web work, but it doesn't really allow you to easily utilize best practices that we've collectively learned over the last 15 years of web development. That's not to say Rails is just plain better... to the contrary, I think PHP is a better templating language. The difference is that with PHP you are better off moving to a real language for your back-end on any moderately complex application fairly quickly. Rails, on the other hand, will let a significant portion of web apps (if not a majority) go quite far without any separate back-end.
garnet7 17y ago
> It's easy to deploy. Yup. This is the reason PHP is trouncing Python. Python should be where PHP is, right? But it isn't. If you ask the Python folks for easy deployment, they'll go into a lecture about how it's ugly, or a hack, or not general enough. And then they'll start telling you about how you should be using WSGI. You: "I like vanilla." Python: "What? Vanilla? There are better flavors than that. C'mon. Let's get you some nice strawberry." You: "But I don't like strawberry. Python: "Well, you should! It's a great flavor! How many scoops would you like?" You: "[Sigh]. 2. Sugar cone, please." Python: "Here you go!" You: "Hey, this is a wafer cone. And it's only one scoop. And it's sherbet!" Also, learning to make a scripting language spit out some html is easy. Learning how to get various apache modules built, configured, and installed -- or convincing an inexpensive ISP to do so -- is a whole nother ball of wax. AFAICT, PHP did deployment right, and is still making "better" languages look like they can't get their act together. I should be able to drop a .py file into my docroot and a persistent apache-managed python should execute it (when it's requested) and spit the results back to my browser. It's astonishing that we don't have that. You: "I like vanilla." PHP: "Here you go. Vanilla. Also take these napkins -- it's a little drippy."
- dasil003 17y ago
  Passionate software developers need to accept the fact that web programming has hit the mainstream. There are tons of amateurs doing it, and the number is growing explosively thanks to platforms like Facebook. It's pretty much a given that these type of people coming in with a passion for the end result are going to be different from the geeks for past generations who were just as obsessed with the process of programming. PHP is ideal for seeing a quick result. HTML + PHP is the most rewarding platform ever invented in that regard. Naturally, many of these individuals will evolve and outgrow PHP, but it's also powerful enough to keep a lot of talent around just due to inertia. Ease of deployment is just one piece of this perfect storm.
- gaius 17y ago
  Websites are a small corner of the Python world, but all of the PHP world.
  - 17y ago

by mdasen 17y ago

cesare 17y ago

I don't think that Lerdorf (btw, not Lerforf) doesn't know what he's talking about. He's just saying that frameworks like Rails are inherently slower, and all the magic (like scaffolding etc.) isn't really worth it. He also says: > Ruby as a language is great, I think it's a really clean and nice language. There just aren't that many people who know it well.

benatkin 17y ago
Here's what he said: "But there are performance issues with the scaffolding and stuff, and they recognise that, which is why the new build will be better." Any rails dev could tell you that scaffolding is irrelevant to the performance of a typical rails app. Yet he mentions "scaffolding and stuff". Also, DHH has said numerous times that scaffolding is mostly just a development tool. I think people who still trot it out as one of the problems with Rails are deliberately ignoring what he said.
- jonknee 17y ago
  I think it's a fair knock because it is so prevalent in the screencast (which he mentioned). If it's in the sales pitch, it's fair to knock.
  - davidw 17y ago
    It's a bit like saying Ford cars are crap because they don't fly well. It's knocking the wrong thing.
    - jonknee 17y ago
      I don't follow... Ford doesn't sell their cars by showing how easy it is to make them fly.
      - davidw 17y ago
        Scaffolding does not make Rails fast or slow. It's code generation that happens prior to run time.
  - jamesbritt 17y ago
    "The" screencast? Maybe in 2004 there was The One Rails Screencast, but their numbers are now legion. Referring to a screencast that's four or more years old so as to knock something today is dopey. It would be like complaining today about PHP3 speed and syntax. Seems pretty clear Mr. Lerdorf has very little knowledge of Rails, and likely very little interest in changing that. "But when they needed to do something real, they thought, 'Oh crap, I don't know Ruby very well!'" Pretty sure that's true for people who hear good things about any [Perl|PHP|Python] framework and decide to pick it up. Usually people then just learn the language. PHP might have a brighter future if its BDFL wasn't so myopic about other languages.
    - jonknee 17y ago
      > "The" screencast? Maybe in 2004 there was The One Rails Screencast, but their numbers are now legion. Referring to a screencast that's four or more years old so as to knock something today is dopey. It would be like complaining today about PHP3 speed and syntax. Visit Ruby On Rails' homepage (http://rubyonrails.org/ http://rubyonrails.org/) and click "Screencasts" on the top menu bar. Click the first one, "Creating a weblog in 15 minutes with Rails 2". Watch. That's what I'm referring to, but it's not much different than the original screencast you're referring to.
andrewvc 17y ago
I hope he sees the hypocrisy in being the creator of a slow (relative to Java/C) language which had a selling point of being productive and easy to use criticizing the next generation of web programming (frameworks) for having these exact same attributes compared to what he made. Also, the PHP framework world blows, I tried Zend's Framework, Cake, and Symfony when I had a boss that refused to use anything non-PHP, and they just don't have feature parity with Rails (though this was a year ago). They also don't have as many mature plugins available as Rails (and a web programming language lives and dies by its libraries).
- NathanKP 17y ago
  Comparing an interpreted langauge like PHP with C speedwise doesn't make any sense. Even Java is semi-compiled to an intermediate form unlike the strictly interpreted PHP. Also, in my experience there are plenty of libraries available for PHP. It comes with a lot more built in functionality than other languages. What I like about PHP over Ruby is that it has a more comfortable C-like syntax. In comparison Ruby is more like Basic than C. When I use Ruby I miss the simple curly braces of C or PHP. In my humble opinion that is a much better way of defining blocks of code.
  - benatkin 17y ago
    It makes sense in the context of PHP's creation. When PHP was created, web apps were still commonly written in C/C++. PHP is much older than Rails, even if you don't count PHP 1 or 2.
  - eru 17y ago
    > In my humble opinion that is a much better way of defining blocks of code. I also don't like Ruby's syntax in this regard. However I long for the simple ways of Haskell, Clean and Python here, using indentation.
  - andrewvc 17y ago
    Comparing a language like PHP to a framework like rails makes no sense either. That was my point.

deleted 17y ago

[deleted]

qeorge 17y ago

I think you've missed his point a bit. He doesn't like code generation in general, which would mean he wouldn't like CakePHP's scaffolding either. If you read other interviews with him I think you'll find he's surprisingly modest about the whole thing. I've never heard him hold PHP up as particularly better than any other language, and he's the first to admit that it can be messy. FWIW, I'm a huge fan of CakePHP and I use it daily (although I don't have much use for scaffolding). Its plenty fast if used correctly, which is a common feature of any good framework.

idlewords 17y ago

The link you yourself cite shows a fourfold speed advantage for procedural PHP over ROR. Not mentioned is the large memory footprint of a Rails process compared to a procedural PHP page. It's the usual phenomenon of trading off development time and complexity for performance. I'm sure if you wrote a web app in C, it would run even faster. Rasmus's point in the article is that as soon as you move away from simple apps under light load into real applications, it is no longer enough just to rely on Rails magic. You find yourself needing to understand the innards of what is a very complex environment, and dealing with an idiosyncratic development community that considers monkey-patching a neat programming techinique, and likes to publish its documentation in video format. He doesn't seem to me to be saying 'don't use Rails'. He's just pointing out you should be fully aware of what you're getting into. Caveat scriptor.

dasil003 17y ago
Rasmus's point in the article is that as soon as you move away from simple apps under light load into real applications, it is no longer enough just to rely on Rails magic. This seems backwards to me. I consider PHP to be ideal for simple apps. Rails comes with a certain amount of overhead (memory being the most important as far as cost is concerned), therefore I think it's only really useful for applications of a certain complexity. What makes Rails useful are some basic architectural assumptions (MVC + a bunch of low level assumptions / web helpers) that are surprisingly applicable to a large chunk of web apps. The magic is just some Ruby tricks to streamline things, but you don't "rely on it". Where Rails tends to fall down are limitations of the Ruby runtimes, or applications where the web front-end is not a significant enough part of the problem to warrant the Rails approach. PHP is similar in some ways--it includes many web-based assmptions, but it doesn't make any architectural assumptions, which means there is no way to benefit from common conventions (eg. knowing where to look for a certain file or class definition, what a variable or database table should be named, where is the default place to put certain types of logic, etc). As such, PHP is better than any other raw language for web work, but it doesn't really allow you to easily utilize best practices that we've collectively learned over the last 15 years of web development. That's not to say Rails is just plain better... to the contrary, I think PHP is a better templating language. The difference is that with PHP you are better off moving to a real language for your back-end on any moderately complex application fairly quickly. Rails, on the other hand, will let a significant portion of web apps (if not a majority) go quite far without any separate back-end.

garnet7 17y ago

> It's easy to deploy. Yup. This is the reason PHP is trouncing Python. Python should be where PHP is, right? But it isn't. If you ask the Python folks for easy deployment, they'll go into a lecture about how it's ugly, or a hack, or not general enough. And then they'll start telling you about how you should be using WSGI. You: "I like vanilla." Python: "What? Vanilla? There are better flavors than that. C'mon. Let's get you some nice strawberry." You: "But I don't like strawberry. Python: "Well, you should! It's a great flavor! How many scoops would you like?" You: "[Sigh]. 2. Sugar cone, please." Python: "Here you go!" You: "Hey, this is a wafer cone. And it's only one scoop. And it's sherbet!" Also, learning to make a scripting language spit out some html is easy. Learning how to get various apache modules built, configured, and installed -- or convincing an inexpensive ISP to do so -- is a whole nother ball of wax. AFAICT, PHP did deployment right, and is still making "better" languages look like they can't get their act together. I should be able to drop a .py file into my docroot and a persistent apache-managed python should execute it (when it's requested) and spit the results back to my browser. It's astonishing that we don't have that. You: "I like vanilla." PHP: "Here you go. Vanilla. Also take these napkins -- it's a little drippy."

dasil003 17y ago
Passionate software developers need to accept the fact that web programming has hit the mainstream. There are tons of amateurs doing it, and the number is growing explosively thanks to platforms like Facebook. It's pretty much a given that these type of people coming in with a passion for the end result are going to be different from the geeks for past generations who were just as obsessed with the process of programming. PHP is ideal for seeing a quick result. HTML + PHP is the most rewarding platform ever invented in that regard. Naturally, many of these individuals will evolve and outgrow PHP, but it's also powerful enough to keep a lot of talent around just due to inertia. Ease of deployment is just one piece of this perfect storm.
gaius 17y ago
Websites are a small corner of the Python world, but all of the PHP world.
- 17y ago