"PHP is the best web platform ever", because it (finally) has a decent package manager. And don't mind that far fetched statement, the author will surely delete any rude comments. Congrats, PHP has a package manager. This does nothing to shake my feeling that PHP's most ardent advocates have little hands-on experience with the more full-featured alternatives. You know, like the ones that also have decent package mana…
Malaria is everywhere. It's got to be awesome.
That PHP is so omni-present is not a good thing. It's an opportunity to disrupt web development. It's a lesson that we still haven't learned.
> "Better than 95% of the PHP jobs out there are horrible scut work for companies that don't give a shit about quality or decent development" Show me your data? You couldn't be more wrong about the companies using PHP. The last startup I worked at in San Francisco, well funded and very successful, used PHP. I was approached by many well known names all using PHP, most of them exciting new companies working with edge…
and for every startup company using php, there are 100 shitty local ad agencies knocking out brochure-ware wordpress sites.
Sounds like a big success for Wordpress and PHP to me
In what sense? I feel it's better than PHP's docs (tutorial, index, module list, everything.) Besides, you rarely ever need to look at the docs. `help(...)` works well enough 99% of the time. Method and module names are clear and easy to guess. If I remember PHP well enough, it was a sorry_mess_of_underscored_function_names (with no namespaces) and had $funky $dollar $signs before variables. Some of the functions wor…
It's better than PHP docs simply by virtue of being versioned and annotated with version information.
This link was right on the Python docs homepage.[0]
> I suspect that parent was referring to the python 2.x branch, which has been catching up with ruby 1.9, but on most benchmarks started at ~ 3x slower and are now ~ 2x slower. Citation needed again. Ruby 1.9 is slower than Python 3, and Python 3 is slower or as fast as Python 2 on Python official benchmarks. http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo... > Since benchmarks are completely worthless,…
Fib(36) Python 2.7.2 def fib(n): if n == 0 or n == 1: return n else: return fib(n-1) + fib(n-2) for i in range(36): print "n=%d => %d" % (i, fib(i))' python -c 20.69s user 0.06s system 99% cpu 20.807 total Ruby 1.9.3 def fib(n) if n == 0 || n == 1 n else fib(n-1) + fib(n-2) end end 36.times do |i| puts "n=#{i} => #{fib(i)}" end ruby 11.44s user 0.03s system 99% cpu 11.507 total I guess since benchmarks are not comple…
>>ubuntu doesn't keep up on ruby and uses 2-3 year old versionsHuh? Since 21 Apr 2012, the benchmarks game has shown - ruby 1.9.3p194 (2012-04-20 revision 35410).
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 languag…
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 I don't know how Bundler handles this and…
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.
PHP is easy to deploy on. That's it. That's why it's popular. It's braindead easy to go from text editor to web URL, it's braindead easy to unzip someone else's project and run it. It requires virtually zero sysops experience to be able to use. You don't even have to worry about setting those +x bits like you used to in the good old cgi-bin days. For those of us who aren't afraid of a little ops work, there are far b…
"PHP is easy to deploy on. That's it. That's why it's popular. It's braindead easy to go from text editor to web URL, it's braindead easy to unzip someone else's project and run it. It requires virtually zero sysops experience to be able to use. You don't even have to worry about setting those +x bits like you used to in the good old cgi-bin days." And that's exactly why PHP is the better choice for those of us who d…
Do PHP engineers even know what multithreading is? ps. I don't mean crontab
I would suggest that serving webpages falls into the set of embarrassingly parallel problems. The solution is to saturate your cpu running multiple instances.
For reference's sake, this article is written by Fabien Potencier, the creator of the symfony framework. This guy's probably single-handedly responsible for lifting the PHP community to a higher level, by making great software (which, when he started, was pretty unique, with horrible hacks-upon-hacks like CakePHP being the norm), and by showing people how to do so.
What's so horrible about CakePHP?
Admittedly, I used it a long time ago. Back then, it was obviously never really used by any of its developers for things beyond the trivial "Blog Tutorial". For example, you couldn't reasonably put model-related code in your model classes, because the model data (coming in from the ORM as nested associative arrays) were structured subtly different depending on how it came in (i.e. on which ModelPeer the query originated). This effectively forced you to make fat controllers and useless models.
Additionally, I know of no framework that reinvented more wheels than CakePHP.
Its legacy (who wants to still support PHP4?). AFAIK, it's no longer maintained; I believe all the core development is now taking place on the Lithium project: http://lithify.me/
None of these things are true, I don't know where anyone comes up with this stuff. Sounds like a smear job more than anything. CakePHP2 is PHP 5.2.8+[1]. It's still being maintained and 2.2 was released this week[2]. Lithium is not a real 'fork' from Cake - rather it is a project that two of the Cake devs were working on as a 'next gen CakePHP' but decided to make into a separate project - the two frameworks don't sh…
> Sounds like a smear job more than anything.
Not at all. I'm sorry you misunderstood. Cake has been quite good to me over the years. Ever since I switched to Lithium I haven't looked back.
Its legacy (who wants to still support PHP4?). AFAIK, it's no longer maintained; I believe all the core development is now taking place on the Lithium project: http://lithify.me/
Wrong wrong wrong wrong wrong. I can see you posted this without doing so much as a single google search pointing your browser to "cakephp.org". I am interested in hearing skrebbel's response to this question however (what makes cake so horrible).