4 ms·

One major problem I see in this article is that the stats that are cited as "proof" that PHP is the most widespread language are skewed. * The sample is not re

One major problem I see in this article is that the stats that are cited as "proof" that PHP is the most widespread language are skewed. * The sample is not representative. It's the top 1 million according to alexa. * The percentage cited is "x percent of all pages that we can determine are..." which skews heavily in favor of PHP since PHP exposes it's version by default at least in older versions while other languages such as ruby don't. The percentage of pages that turned up as "unknown" is not listed. * They don't give an error margin for their stats. * Same is true for the Content-Management Sites. It skews heavily in favor of wordpress because lots of sites do have a wordpress blog installed somewhere. I do acknowledge that PHP is probably leading by market share, but I'm not convinced that it's as pronounced as Fabien wants us to believe. Composer is a nice step forward, but it's still behind of what bundler can do. One of it's main problems is that it created a completely new package format, so you need a new package repo - now they're at a respectable 1900 packages. Bundler uses the regular rubygems packages and has the full list of over 40.000 gems available. All tools that used to work with gems still work. There's also a couple of features that it's missing (local overrides for development, binstubs, etc.) but I guess that's just catch-up work. That the commandline interface looks plain ugly is probably just personal preference (heck, why do I need to call 'php composer.phar' instead of 'composer'?) Last but least, it's pretty much a feature-wise copy of bundler - that's maybe "on par" but not "the most awesome and best thing in existence". So yes, PHP has taken huge steps forward but it's still ugly. You can get shit done if you know your way around and you can write amazing and elegant software in it - it's just harder than it needs to be.

jasonlotito 14y ago
> (heck, why do I need to call 'php composer.phar' instead of 'composer'?) You can. http://getcomposer.org/doc/00-intro.md#globally http://getcomposer.org/doc/00-intro.md#globally $ curl -s http://getcomposer.org/installer | php $ sudo mv composer.phar /usr/local/bin/composer $ composer --version Composer version 6573fd3
- Xylakant 14y ago
  right. I could write a short shell wrapper as well - but why do I have to? I don't have to with pip or bundler.
  - jasonlotito 14y ago
    Uh, no. See, those instructions are from the getting started page. Why do you have to? Because, you can install composer just by downloading it and running it. You dont need to "install" it. This is handy on shared hosting environments where you won't have root. How can I install bundler on a shared hosting environment like composer?
    - Xylakant 14y ago
      Well, yes. I can install bundler on a shared hosting environment where I don't have root. In fact, pretty much all my installations are non-root installations. Still, I don't have to manually move it around, symlink or shell-wrap it. It's not a deal-breaker or a major nuisance that I have to do it, it just fits in what I'm used from php: it gets the job done, but feels unpolished.
      - jasonlotito 14y ago
        > Well, yes. I can install bundler on a shared hosting environment where I don't have root. So what command do you run to get that installed like that? > it gets the job done, but feels unpolished. Unpolished like make && make install.
        Xylakant 14y ago
        > So what command do you run to get that installed like that? "gem install --user-install bundler".
soulclap 14y ago
While Composer introduced a new package format, it can be used to retrieve PEAR packages, 'plain' zip files and even git, svn and hg repositories - and these can be integrated even if they don't contain a composer.json file, needing just a little extra configuration in your project. This is a huge step forward and very convenient. http://getcomposer.org/doc/05-repositories.md http://getcomposer.org/doc/05-repositories.md I don't know how Bundler handles this and it probably isn't even needed, as gems are just the standard in Ruby but PHP didn't really have a standard besides PEAR and Composer brings everything together.
- Xylakant 14y ago
  Well, it's not needed - that's my point. Bundler just uses the one well-established format for packaging libraries and declaring dependencies. Even git repositories and local code uses the same depency-declaring format: A standard gemspec. Otherwise bundler just stays out of the way to do it's main job - dependency resolution. There is no such thing as two package formats in the ruby world. There is now in the PHP world - PEAR and Composer (and zip and tarfiles). PEAR has always been severely lacking - no way to install two versions of the same PEAR package, improper dependency-tracking - so I guess that's required. It's probably a huge step forward, but it's still not "better" to be able to track two package formats "with just a little extra configuration" instead of "it works just fine without extra work with the default package format." And that's exactly what the article claims: "Yes, PHP has a better dependency manager than any other languages.
  - soulclap 14y ago
    I didn't mean to say it is better than all other dependency managers and basically didn't want to argue at all. My point is just that I am happy that Composer is around now, as it lets me include all dependencies from various sources in a convenient and reliable way. So no matter which dependency manager for which language is 'the best', Composer definitely means better times for all PHP developers. Seems that Ruby had one good standard solution with gems for a long time, let's hope that Composer has a similar bright future. From my perspective, it's already the standard and including a composer.json file is a 'best practice' for all 'well-connected' PHP developers releasing a library these days.

jasonlotito 14y ago

> (heck, why do I need to call 'php composer.phar' instead of 'composer'?) You can. http://getcomposer.org/doc/00-intro.md#globally http://getcomposer.org/doc/00-intro.md#globally $ curl -s http://getcomposer.org/installer | php $ sudo mv composer.phar /usr/local/bin/composer $ composer --version Composer version 6573fd3

Xylakant 14y ago
right. I could write a short shell wrapper as well - but why do I have to? I don't have to with pip or bundler.
- jasonlotito 14y ago
  Uh, no. See, those instructions are from the getting started page. Why do you have to? Because, you can install composer just by downloading it and running it. You dont need to "install" it. This is handy on shared hosting environments where you won't have root. How can I install bundler on a shared hosting environment like composer?
  - Xylakant 14y ago
    Well, yes. I can install bundler on a shared hosting environment where I don't have root. In fact, pretty much all my installations are non-root installations. Still, I don't have to manually move it around, symlink or shell-wrap it. It's not a deal-breaker or a major nuisance that I have to do it, it just fits in what I'm used from php: it gets the job done, but feels unpolished.
    - jasonlotito 14y ago
      > Well, yes. I can install bundler on a shared hosting environment where I don't have root. So what command do you run to get that installed like that? > it gets the job done, but feels unpolished. Unpolished like make && make install.
      - Xylakant 14y ago
        > So what command do you run to get that installed like that? "gem install --user-install bundler".

soulclap 14y ago

While Composer introduced a new package format, it can be used to retrieve PEAR packages, 'plain' zip files and even git, svn and hg repositories - and these can be integrated even if they don't contain a composer.json file, needing just a little extra configuration in your project. This is a huge step forward and very convenient. http://getcomposer.org/doc/05-repositories.md http://getcomposer.org/doc/05-repositories.md I don't know how Bundler handles this and it probably isn't even needed, as gems are just the standard in Ruby but PHP didn't really have a standard besides PEAR and Composer brings everything together.

Xylakant 14y ago
Well, it's not needed - that's my point. Bundler just uses the one well-established format for packaging libraries and declaring dependencies. Even git repositories and local code uses the same depency-declaring format: A standard gemspec. Otherwise bundler just stays out of the way to do it's main job - dependency resolution. There is no such thing as two package formats in the ruby world. There is now in the PHP world - PEAR and Composer (and zip and tarfiles). PEAR has always been severely lacking - no way to install two versions of the same PEAR package, improper dependency-tracking - so I guess that's required. It's probably a huge step forward, but it's still not "better" to be able to track two package formats "with just a little extra configuration" instead of "it works just fine without extra work with the default package format." And that's exactly what the article claims: "Yes, PHP has a better dependency manager than any other languages.
- soulclap 14y ago
  I didn't mean to say it is better than all other dependency managers and basically didn't want to argue at all. My point is just that I am happy that Composer is around now, as it lets me include all dependencies from various sources in a convenient and reliable way. So no matter which dependency manager for which language is 'the best', Composer definitely means better times for all PHP developers. Seems that Ruby had one good standard solution with gems for a long time, let's hope that Composer has a similar bright future. From my perspective, it's already the standard and including a composer.json file is a 'best practice' for all 'well-connected' PHP developers releasing a library these days.