In all this time there has been a huge change in the PHP world
TBH if a "developer" cringes their nose at a very capable tool, just because it is not the latest "cool" thing, It tells me a lot about them.
See, the thing is, PHP has gotten better. That's not in dispute. The problem is that, even after it "has gotten better", it's still far behind most other options that are commonly in use, and still highly inconsistent and upredictable. It is rather telling in and of itself when you have to use "well, it has gotten better" as a crutch to argue that, at least, it meets a minimum standard of viability.
Frameworks don't really solve this problem. Fundamentally, you're still working with a language that does some really weird things - things that are weird enough to cause near-untraceable bugs and completely unexpected vulnerabilities. You can slap a lot of abstraction onto it, and it does make it less unwieldy, but in the end you're still limited by what the language or platform has to offer you in terms of inherent consistency, predictability, and debuggability.
Just take, for example, PHP's CGI-like nature. Yes, it is theoretically possible to have a long-running process, and it's theoretically possible to implement real-time services with it, but it's going to be a major headache and incredibly hard to maintain. The tools are just not really there. Any solution you come up with will, in the end, be a giant hack.
Don't assume that somebody who cringes at PHP is just somebody who likes jumping on bandwagons. There are very real and rational reasons to dislike PHP, even (especially!) as an experienced PHP developer.
Not like the exemplary attitude of "awesome lets cut our wrists all day and open windows explorer to deploy"
What happens when you have existing code in Java or python that does something you do not wish to reinvent the wheel with is you simply interface/bridge with from you PHP code.
Right now I have 5 servers running python batch jobs processing some data (for a few months now) which is called by php with results being added to datastore for later access with php
In the past I worked on an asset tracking system where we collected data from RFID readers, whole system was done in PHP with some glue Java and C code for more "to the bone" edge cases
Everything I have done in PHP i could have done in C which I first learned and still use alot of, doesn't mean I want to spend my life wasting it on 90% of cases where a quick php script does the job within reasonable time
I never claimed PHP is "awesome" or whatever you think I did, but it is a very capable language at getting things done fast, especially if you know what you are doing
Yes there are armies of noobs giving PHP a bad name, but instead of turning your nose at them one is better helping them and showing them how to do things better
The horrid (and unfixable) nature of the language does not become apparent until after you use it for a while. (How long it takes may vary, but you ll hit it eventually, if you keep yourself in good company.). So if you list features of PHP, you might get a list of nice features. But every one of them will be subtly broken when put to real use...
mtgox? :)
>TBH if a "developer" cringes their nose at a very capable tool, just because it is not the latest "cool" thing, It tells me a lot about them.
This is called the straw man fallacy. You wrongly assume that the lack of coolness is why people dislike PHP and you dismiss the whole argument based on that.
Doing great stuff with PHP is like building a skyscraper using nothing but a hammer and a screwdriver and a few rotten planks. It's the builder who's amazing (albeit a bit crazy), not the hammer, the screwdriver or the planks. Imagine what he might've made with proper equipment?
Would you like to live in such a skyscraper?
What PHP is for me, is a paper cup. It's modest, utilitarian, not cool or elegant, but definitely efficient, useful and ubiquitous.
Talk about a backhanded compliment :)
ROFL :D (no tho in hindsight robbing half a billion and getting away with it doesnt seem like bad career path)
Stop being lazy and unprofessional and spend a month or two learning one of the many better commonly used web dev languages.
[1] http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
The purpose of a programming language is not to allow you to write beautiful code but to produce things. Everything else is a pseudo debate that is necessary at times but not as much as some would like.
http://www.reddit.com/r/lolphp/comments/2md8c0/new_safe_cast...
Such as?
- "(int)" being a single token in the language
- not being able to call "array()" as a function is bad, apparently (which is the equivalent of wanting to use "return" as a function in C)
- "Most error handling is in the form of printing a line to a server log nobody reads and carrying on." - Bullshit. We send errors to Sentry or via e-mail. In some projects we feed them to a database.
- "E_STRICT is a thing, but it doesn’t seem to actually prevent much and there’s no documentation on what it actually does." - Bullshit. It's a warning, not a magic fix, so what should it do except warn you?
- "Function arguments can have “type hints”, which are basically just static typing. But you can’t require that an argument be an int or string or object or other “core” type, even though every builtin function uses this kind of typing, probably because int is not a thing in PHP." - Yeah, read the RFCs concerning type hints to understand the issues why PHP does not have them [yet].
- "No named arguments to functions. Actually explicitly rejected by the devs because it “makes for messier code”." - "And so I list it as a fundamental flaw in the language because it's not Python."
- "new, private, public, protected, static, etc. Trying to win over Java developers?" - Oh sorry, PHP devs will stop adopting good coding pratices in the next releases. Back to var everyone!
- "Subclasses cannot override private methods." - Yeah, that's why they are called PRIVATE.
- "There are no constructors or destructors. __construct is an initializer, like Python’s __init__. There is no method you can call on a class to allocate memory and create an object." - Yeah, because IT'S FRICKIN' PHP and you should not fiddle with memory. Go write C if you want to deal with malloc.
- "Static variables inside instance methods are global; they share the same value across all instances of the class." - Yeah, that's why they are static. If you want instance-bound variables, use class members.
- "As namespaces are a recent feature, the standard library isn’t broken up at all. There are thousands of functions in the global namespace." - "How dare the PHP devs not break compat with every piece of code ever written when they introduced namespaces? They should have just converted everything to C#!"
- "How do you sort backwards? In PHP, there’s a separate function called rsort()." - Fuck, those PHP dev assholes. How dare they include a shortcut. It's almost as if they just wanted to make simple things simple. PHP should require the developer to implement 20 interfaces to compare two numbers!
- "preg_replace with the /e (eval) flag will do a string replace of the matches into the replacement string, then eval it." - Failure to mention that this behaviour is deprecated for ages now (dunno, has it been removed in 5.6?)
- mentioning classkit as a way to "actually be dynamic in PHP". Yeah sure, without classkit there is NO dynamic feature in PHP, none at all.
- "There is no exponentiation operator, only the pow function." - Wrong, there is now.
- "No Unicode support. Only ASCII will work reliably, really. There’s the mbstring extension, mentioned above, but it kinda blows." - Yeah, no website with Unicode support has ever been built with PHP. Sure. Don't ask me how I manage to handle Unicode with mbstring just fine, I must be a magician.
- "Similarly baffling, arrays stringify to Array with an E_NOTICE." - What else would you like? A JSON representation? A simple comma seperated list? I can guarantee you, whatever you choose, someone will find it bad for their purpose. That's why we consider plainly converting an array to a string a MISTAKE (aka bug).
- "var_dump(strstr) issues a warning and assumes you mean the literal string, "strstr"" - aka "PHP is not JavaScript, so it's bad."
- "There are no generators. (Fixed in 5.5. Wow. They basically cloned the entire Python generator API.)" - Dafuq do you want? For some things, Python is the best thing in the world and everyone should copy it, but when PHP does, it's also bad, because, ya know, PHP.
- "PHP is naturally tied to Apache. Running it separately, or with any other webserver, requires just as much mucking around (possibly more) as deploying any other language." - Welcome to 2014, dickhead. I never heard our admins complain about using PHP-FPM with nginx. And using PHP separately couldn't be simpler: ``php myscript.php``.
- "Similarly, there is no easy way to “insulate” a PHP application and its dependencies from the rest of a system." - This guy has seen too many PEAR-based projects.
- "Configuration files and other “partials” need C-like guards to prevent them from being loaded directly." - a) put the file somewhere outside the docroot; b) configure your webserver to not spew out static files; c) use plain PHP files for config files; d) deny access to config files via .htaccess
- "No XSS filter. No, “remember to use htmlspecialchars” is not an XSS filter." - I beg to differ.
- "No CSRF protection. You get to do it yourself." - Fuck, you have to implement application logic yourself. Damn.
- "No authentication or authorization." - sigh really?
- "No routing. Your website looks exactly like your filesystem. Many developers have been tricked into thinking mod_rewrite (and .htaccess in general) is an acceptable substitute." - And in fact, it is.
- No coherent deployment mechanism; only “copy all these files to the server” -- Yeah, this is truly the worst. Just uploading files is waaaaay not enterprisy enough. Without OpsWorks, Chef and fourteen admins, you can't even call a PHP deployment a "real deployment". Things should be complicated. When uploading new code, PHP should force you to pester the admin to restart Apache!
- "The original built-in MySQL bindings, still widely-used, have no way to create prepared statements." - Yeah, because that wasn't a thing back when ext-mysql was written. That's why we moved to mysqli/PDO YEARS ago.
-----
But hey, it's logical to not remove fixed issues from the list. The point of the list is not to detail the actual flaws, but to just shit on PHP. It's like me shitting on the first alpha of Python or how much Linux 0.0.1 sucked.
Also, you will note that I left out quite a few points that the author brought up. And that's because they are valid points of criticism about PHP. I'm not denying that. But if you shit on PHP, get your shit together first and don't assume all PHP is like a guestbook script from 2003.
I doubt you could convince a developer to condense their opinion of PHP to "PHP isn't the latest cool thing, so I don't like it." As such, I posit you're being as judgmental and dismissive as your supposed adversary.