 |
||
 |
 |
 |
 |
 |
| Sit down. Class is now in session by Entropy Stew 08/06/2015, 6:45pm PDT | ||||
 |
 |
|||
Commander Tansin A. Darcos wrote: I've written thousands upon thousands of lines of Perl, and maintained hundreds of thousands of lines of it. Perl sucks. PHP is a Perl knockoff that's EVEN WORSE. The api is fucking goddamn mess, with naming conventions of "haha fuck you". Don't even get me started on namespaces. The language itself is a fucking abortion. People are writing backends in JAVASCRIPT of all things to avoid PHP. Fuck PHP. First, whether I like it or not it's a dialect of C with some extra syntactic sugar to help the interpreter out (like prefixing variables with $) Perl-style type sigils are sugar? Bleh. They don't even make any fucking sense in PHP since they aren't even actual type sigils like in perl. and some improvements to reduce error (making all variables local to a function unless declared global, which reduces the potential for accidental side effects.) What. That's lexical scoping, you stupid motherfucker. C has had that since BEFORE I WAS BORN. And PHP doesn't even get scoping right because you have to manually bind values into anonymous functions. They don't have proper closures. EVEN JAVASCRIPT HAS FUCKING CLOSURES. This means anyone who knows C basically knows PHP which gives it a big pool of talent. This is retarded. I'd win your "prove TDARCOS is insane" contest by quoting it, if I hadn't already been beaten by the first response to that thread. Second, it's memory resident in the web server, so Apache can pass PHP code directly to the interpreter much faster than spawning a CGI interpreter process. When you're doing large on-line systems reducing overhead increases the response time. CGI passed away in the early aughts. You are beating a dead straw horse. Third, PHP has a huge, rich function library of literally thousands of routines, and because the language has lots more string functions, it does offer a good choice for string processing. I already covered their fucked API. Let's move on to strings: To be good at strings you need to be good at unicode. PHP is not good at unicode, therefore PHP is bad at strings. PHP is so bad at strings that they aborted the unicode-native version 6 because it was such a clusterfuck. Fourth, it's interpreted which allows for fast testing of applications, eliminating the "compile, test, bomb, edit, recompile" cycle. You can get quick feedback on changes. This is the only sane thing you've said so far. That said, even compiled language have continuous and/or incremental deployment options. Hit save in editor, website is updated automatically. Easy. And if performance is supercritical, there are PHP->C translators so a tested application can be compiled and statically linked, either as a CGI application or possibly as an extension to Apache, I'm not really sure how the web server accepts plugins. You stupid motherfucker. Nobody compiles PHP to C. Once, back in 2010, Facebook was compiling PHP to C++ because they ran into scalability walls. That ended in 2011 when they released HHVM, a JITed PHP vm. And who in the unholy fuck would compile PHP to run it as a FUCKING CGI APP? A goddamn fucking lunatic is who. Nobody compiles PHP to C. Fifth, it's a vendor-neutral language, you're not locked in to Microsoft's IIS as you would be if you use ASP; nor are you subject to what Oracle decides the language can or should do if you use Java. .NET was open-sourced (in addition to Mono already existing) and Java has free, open source implementations. I guess by vendor-neutral you mean it's controlled by that one company, Zend? What is even I don't what And it's more-or-less standard across platforms, if you run an AMP (Apache, Mysql,PHP) stack you can put it on a Windows box (WAMP), a Linux Box (LAMP), BSD/Apple, or even on a mainframe. This is generally true for pretty much any web dev language. Sixth, you can change out the database from MySql to Postgres, Oracle, SQLServer, DB2, NOSQL or possibly other options like Hadoop (I'm not really familiar with it, I've never had to work with humongous sets of data in the 100GB and above range.) So you have options to choose if you think a different database or data management system is a better choice for your application. Yeah, just like every other web dev language. Now, let me tell you what PHP is: PHP is a big pile of shit that is the shortest path to getting a dynamic web page up on the net. The language itself is a PILE OF SHIT, but it has decent performance depending on what you're deploying it on (and PHP 7 is getting a huge performance boost, up to near-HHVM levels), and there have been incremental improvements over the years to make it a smaller pile (OF SHIT). It's also trivial to get it running on shared hosting, which cannot be said of practically everything else. Maybe python? There are some decent frameworks that can take a great deal of the pain away, and composer is decent at handling dependency management and fetching third party libs. -/ES/- |
||||
 |
 |
|||
|
