5 ms·
Most of the criticism of php seems to contrast it with a language plus a framework. If you really want to compare, compare php with ruby or python, not Django o
by badclient 13y ago
Most of the criticism of php seems to contrast it with a language plus a framework. If you really want to compare, compare php with ruby or python, not Django or RoR.
As for php encouraging shitty programming, a good bit of that is that so many more people program in php because its easier to get started with. This does not mean that just because php attracts shitty programmers that it doesn't have more or many awesome programmers than languages such as python.
- jdjb 13y agoThe linked article explicitly states that the author has found (albeit anecdotally) that good engineers are very very productive in PHP. I've found this myself as long as you don't go writing code that sits in PHP's "hmm, what'll happen if I do this..." area.
- jronkone 13y agoAFAICT, "good engineers are productive in X" doesn't imply that they wouldn't be yet more productive in Y.
- byroot 13y agoAlso the Facebook mantra being "move fast and break things" (that anyone working with their API appreciate), it's easy to have a high productivity in most languages.
- bowlofpetunias 13y agoMethinks the argument that PHP encourages shitty programming has been effectively countered by the amount of crap legacy Ruby code that has appeared several years since Rails became "hip". It should be quite obvious to anyone by now that when it comes to shitty programming, language is negligible factor once a language has hit the mainstream. But I'm pretty sure 5 to 10 years from now someone manages to argue that Ruby is crap, Rails is to blame for encouraging a generation of developers to write bloated controllers full of spaghetti code, and that this attracts shitty programmers incapable of understanding software architecture.
- pgeorgi 13y agoI already start arguing along these lines now - starting with the refusal to define even semi-stable interfaces across versions of a library. Instead of relying on actual reusable building blocks, you're expected to build specific versions of ruby interpreter and libraries for every project. Imagine having to cope with just ever so slightly different (but certainly incompatible) philips screws whenever you want to affix one physical thing to another.
- lotyrin 13y agoIf I'm a least-common-denominator web developer and I copy and paste some PHP code into a project from a google search, and I copy and paste some Ruby code of similar origin, what are the odds that each has a inobvious flaw? Or much worse what are the odds that if I'm an average developer and am picking a random feature from each language's standard library, making care to read the docs before using it in my application that I've still introduced a bug? (Consider that maybe I'm dealing with things that were considered strange and new when most of PHP is still from - like character encodings - particularly character encodings that differ from the system I'm running in). Most languages can be CGI-style executed by an httpd with shared-nothing, but can also start up and be a long-lived stateful daemon. I don't have to decide between putting a square peg in a round hole or throwing my code away to learn something entirely new if I realize I need the latter part way through a project. PHP comes with a excessively large (but strangely CGI/HTTP/HTML/SQL-obsessed) standard library littered with footguns, and for most of its life has not had a common pattern for reusable modules, and has not had a good bundler for shipping reusable modules or making working with C extensions easy - and as such few people bother reimplementing functionality from core outside of what's been provided there (which is all set in hard clay), and when they are forced to tend to do so in (plain-ole-interpreted) PHP and don't generally package it up for reuse outside their own projects - a practice much more common outside PHP-land. Case in point (goddamn strlen, even): https://api.drupal.org/api/drupal/includes%21unicode.inc/function/drupal_strlen/7 https://api.drupal.org/api/drupal/includes%21unicode.inc/fun... Some of that is changing in recent history (as in well after other languages figured these problems out) with PSR (design for reuse) and Composer (bundler) but it's slow moving and the latter still won't compile C extensions yet: https://github.com/composer/composer/pull/498 https://github.com/composer/composer/pull/498 Plenty of this could be solved in PHP, some of it already is if you have the luxury to work with a tiny subset of PHP projects, but the practice in PHP seems to still mostly be to have it piss in your face and believe that it's raining. People are in a rut of tradition or simply don't expect their tools or libraries to be good - and I've spent the last 6 years working with PHP (several products, several teams) and wondering where I can get some of the Koolaid that my colleagues are drinking.
- deleted 13y ago[deleted]
- lmm 13y ago> Most of the criticism of php seems to contrast it with a language plus a framework. If you really want to compare, compare php with ruby or python, not Django or RoR. Why? What difference does that make as a programmer using it? If another language is more modular, and lets libraries handle things that are baked into php, isn't that a good thing? > As for php encouraging shitty programming, a good bit of that is that so many more people program in php because its easier to get started with. This does not mean that just because php attracts shitty programmers that it doesn't have more or many awesome programmers than languages such as python. Maybe not, but it makes it harder to hire the good ones.
- Corrado 13y agoI think it is fair to contrast PHP with RoR or Django, because it was built specifically for generating HTML. Ruby and Python are general purpose languages that do many more things than generate web pages. No one writes iOS apps in PHP but they do in RubyMotion. No one writes high performance Math routines in PHP but they do in Python.
- dham 13y agoThis is my biggest gripe. PHP just does one thing. You can't really use it for much more then building web pages. Yes, you can use it for scripting but Ruby and Python are much better at this. You have things like Rubymotion(to build iOS and Mac apps), which I'm really liking. Opal which translates Ruby to Javascript. You can build Android apps with Ruboto. You can run Ruby the JVM and call Java libraries. You can run Ruby on the .NET runtime(Iron Ruby). You have a really good Web framework called Rails. Most other PHP frameworks just copy Rails, so why not just use the source. You can build games for iOS using Joybox(library for Rubymotion). So from a business prospective we chose Ruby because we can do pretty much everything in Ruby. We rarely have to use anything else. From command line applications, to web, to iOS, to Android, to reporting, etc. PHP, well, you can output HTML, or JSON.
- Killswitch 13y ago> Most other PHP frameworks just copy Rails, so why not just use the source. I can't speak for anyone else but for myself regarding this but here we go. I have 12 years experience with PHP, it's my primary language, I know it's got pros and cons, I accept it for what it is and work around it. I know Python is better in terms of standards in languages. I know PHP started out as just a few tools and morphed into a language. But here's what's keeping me from switching to Python or Ruby, or heck even Node.js.. Experience... Yes I can learn a new language basics pretty easily, but am I gonna be able to write a complete app in say RoR with very few google searches or even looking at the manual as fast as I can in PHP? No... I have been playing around with node.js for 2 years now, long enough to know it pretty well, and yet I can still code circles around node.js with PHP.. 12 years using this language as a primary, it'd take me at LEAST 4 years to even get close to the scale of how well I can code in PHP. It's just not feasible for me to just up and leave PHP for something "better" based on a few cons and other peoples opinions.