231–240 of 346 posts
Funny. People criticize PHP the language and the PHP fanboys retort by praising PHP the platform. Jeff Atwood more or less said that we should provide the platform advantages of PHP in other languages in order to steer new developers there.
Earlier quoted context omitted.
What's so horrible about 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/
I am interested in hearing skrebbel's response to this question however (what makes cake so horrible).
Earlier quoted context omitted.
Agree it's not that hard, I also don't think it's in any way a bad thing to have to learn how to do it (in fact probably a good thing). Just that learning how to do that is no easier than learning to deploy a rails/ django/ etc app so I'm not sure PHP really 'just works' any more than any other popular language.
You're comparing it to frameworks. You don't need a framework to handle URL routing, input parsing, output headers, etc. You save a PHP file and it's a URL; no routing. The query string, POST body, request headers, uploaded files, etc. are already parsed and sitting in variables in your global namespace. Output will automatically go to the web server, with the appropriate headers already set. No downloading or config…
And a lot of what you are listing as "just works" are misfeatures which break things and make life unnecessarily hard down the road. They are time bombs, because everything will seem OK up front and the problems won't occur to you until they are already serious and chronic.
There IS routing, it is just implicit, magical routing performed by the server by inspecting a filesystem (e.g. the same filesystem where you have code, databases, password files, configs, etc.) Exposing my internal project organization publicly as a grody looking URL scheme that will become enshrined in all my links? Oh boy!
I don't WANT everything magically parsed by default, regardless of whether I need it for this request. This must happen when and how I specify or the tool is useless to me. Also: it is not a POST body, it is a request body. What do you call the body of a PUT? (And this kind of mis-education is another PHP misfeature)
I don't WANT random mistakes like leaving empty files to pass silently. I want bad code to fail early so I can easily detect the presence of a problem, and locate it. There is nothing worse than silent failure. If you think that silencing errors "just works" then you have your head in the sand. Don't think that users don't notice when a site is broken.
You can use a builtin framework which behaves inappropriately by default and then rewrite later, but why would you actively choose to do this? I think that most people do not choose to do it, because they just don't know. That is why this topic keeps coming up.
It is nice to nurse people along, but it is not nice to require them to nurse your tool along continuously because of all its broken behavior. Their time is better spent working on their own code rather than nursing yours. So perhaps other frameworks could somehow do an even better job of nursing users along, and those specifics are worth discussing. But that doesn't mean the right answer is to hook people on PHP's builtin framework.
And by the time you dress up PHP with a third party framework and other tools to make it fit for use, which you can certainly do, it is absolutely not easier than frameworks in other languages.
It's like he didn't actually read Jeff Atwood's article, or if he did, he entirely missed the point. It wasn't a rant about PHP; it was a rant about people ranting about PHP ! So much heat; so little light.
Earlier quoted context omitted.
> 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…
Earlier quoted context omitted.
When I first started looking for work here in Dublin, Ireland a few years ago, I saw tens of PHP web stack jobs, 1 RoR job and no Python jobs. While the tides have turned slightly, PHP web stack jobs here still far outnumber Ruby and Python equivalents, especially at the entry level. Some developers like PHP because they can get easily work doing it. Businesses likes PHP because they can more easily hire people. Argu…
Yeah - "shit" being the operative word there. The problem I've found is that there's a kind of anti Python paradox at work with PHP: 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, even though it costs them an arm and a leg maintaining their steaming legacy codebase. The 5% that you'd actually want to work for need to have a se…
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 technologies for practicality, which is a trait that goes great with PHP).
Yeah, PHP isn't perfect, we all know it has its quirks and oddities, but isn't that part of learning a language? What separates a hobbyist and professional PHP dev is experience, and knowing the correct method around such quirks. In the end, PHP gets the job done. I've yet to come across a problem in my 11 years that was due to a bug or a quirk that I couldn't overcome. Whether you defend PHP or rant about it, I stil…
To be honest I don't like PHP for exactly the reasons I don't like javascript. It's easy to write in a way which is stupid. You can write good php and you can write cool stuff with it. It is easy to non-technical folk to pickup and write a little bit of. It's also amazingly easy to: 1) Write code which is broken and stupid (woops, left error_reporting(E_ALL) on! silly me. dumped all the passwords out into the website…
1) Use a framework like Symfony2. 2) Yes, I agree, PHP encourages you to write esoteric code. Oh wait, what the fuck am I smoking? Better yet, what are you smoking? You can do this in every language I know. 3) Use unit and functional testing. You do use automated testing, don't you?
Earlier quoted context omitted.
He seems like he does. You might notice I never said no PHP apologist understands PHP, but rather contradicted your (frequently posted) lie that PHP detractors don't understand PHP. Of course, he doesn't offer an actual rebuttal to much, mainly just "well yeah it sucks, but I know it sucks so its ok".
In response your undefined edit: Can you point out my lies?
>PHP's most ardent critics have little hands-on experience with PHP, itself
Do PHP engineers even know what multithreading is? ps. I don't mean crontab