That's just not true. Just one example: PHP will throw runtime errors when (1) an argument type being passed to a function does not match its corresponding declared parameter type and (2) a value being returned from a function does not match the declared function return type. In pure Javascript you can't restrict the types of objects being passed to or returned from a function.
try{
$exceptionType = rand(1,10) > 5?
BadMethodCallException::class
: LogicException::class;
throw new $exceptionType("smartass");
}
catch(BadMethodCallException $typed_1){
file_put_contents('php://stderr', "Bad method, ".$typed_1->getMessage());
}
catch(LogicException $typed_2){
file_put_contents('php://stderr', "Bad logic, ".$typed_2->getMessage());
}
or this: function lieToMe(PHPMailer\PHPMailer\PHPMailer $mailer){
}
or this: $mailStrategy = new MailStrategy();
$mailStrategy("[email protected]","Subject","Body");
Or any of the other actually cool things you get with PHP if you can cope with the language.It's sad to see people who probably can't program a microwave diss an entire language they haven't ever actually used.
1) Rapid iteration: Edit a file, hit refresh, see your results.
2) Ease of deployment: SFTP your changes, done (obviously you wouldn't work this way for a serious project...)
3) Simple execution model: each request gets its own thread (or process), each request starts from scratch.
What was the alternative to using php from 1996 to 2000 if you were running a small mom and pop isp and your customer base was requesting shopping carts, photo galleries, and blog like web capabilities?
In that era, the servers were pentiums of 75MHz.
Back then you primarily went one of two ways, Perl & PHP. PHP was by far the lowest barrier to development. Easy to enable PHP support in webservers, easy to incrementally increase usage in your platform alongside any static HTML.
PHP + mod_php moved away from needing to know what was happening on the server side.
Perl and the other cgi-bin integrations could be complicated, involved, requiring more specific configuration on the server side. Sure, it's not _that_ hard to do, but it does present a barrier to entry that PHP / mod_php handily solved.
More than two possible ways.
As if everything else wasn't worth mentioning.
Back on my little bubble, the options listed by me were much more relevant.
PHP 7's type system is worse than Javascript's type system? I can't imagine any developer who has worked with both those languages agreeing with you. It sounds like you haven't done any serious PHP work for the last ten years or so, and your opinions haven't kept pace with reality.
For people new to development especially who may have started with some simple static HTML, just being able to rename a .html file to .php on a dirt cheap web host and have it "just work" is such a low barrier to entry that it is a tremendous learning tool.
People also like to forget that PHP scales down better than any language out there, making it a no-brainer decision for cheap hosting of small and simple sites.
When you start increasing traffic and throughput or building software to run an serious business, of course there are other great options.
Just remember that every language has a purpose even if it's not yours, otherwise it wouldn't exist.
> "To them, we say “think again.” We believe that the only limit PHP has is the limit you set."
You shouldn't be writing PHP in the first place, and should slowly work to (incrementally, slowly) shift your codebase into any other programming language in existence if it is already written in PHP.
The core language is terribly designed. PHP 7 did not fix this. Even JavaScript is miles better (PHP has a type system equally as bad, if not worse).
Of course, this sentiment is unpopular, because you're never supposed to rewrite anything even incrementally, and Popular Means Quality, and saying otherwise is heresy.
I propose the more radical solution of killing PHP entirely (again, incrementally, slowly), and replace it entirely with the language of your choosing (maybe that's Go).