PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
I’ve always wondered why the more respectable dynamic languages, like Ruby and Python, don’t have a web framework with the PHP deployment model of “just upload this file to the server and refresh your browser to see changes.”
I still love PHP and JavaScript
331–340 of 402 posts
Re: I still love PHP and JavaScript
#332Earlier quoted context omitted.
I’ve been using PHP since 2003 and it’s my full time job and this doesn’t ring true. Very, very rarely is a gotcha not in the docs comment section.
That’s just it. I have to code with the PHP docs open like some kind of arcane recipe book.
All the above said, do enough real work in any language and you'll find cases where the idioms of the language don't map to your work.
Re: I still love PHP and JavaScript
#333PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
> it's stateless by design (much easier to scale) I noticed being stateless made it difficult to scale for any complex app. It’s been 7-10 years since I used it but Drupal used 60-128MB+ plus per request. As it was stateless it had to do a full bootstrap for every request coming in, set up a new database connection, module discovery etc, all which was heavy to do for every request. Most people scaled Drupal by puttin…
In Laravel it's not too hard to avoid this problem but a lot of noobs don't get the lazy / eager loading thing and then you end up like this.
Drupal seems to add hundreds of queries for every module you add.
Re: I still love PHP and JavaScript
#334Earlier quoted context omitted.
I've used Python, C#, Java, JavaScript and PHP, and in my experience Python is the most unpredictable of these languages. Just to name a few: - mutable default arguments - late binding closures - typings that are purely documentation instead of being enforced Labeling these things as "gotchas" doesn't make them predictable imo.
Python less predictable than PHP? In what world? In PHP standard library functions silently take a null instead of a string, even though they are string handling functions, hiding that mistake for the user of the language, until a later point in time, when the context has been lost and one needs to do silly debugging, until one finds the place where the null first was handled, while it should have raised an error. Su…
https://wiki.php.net/rfc/engine_warnings
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_a...
Re: I still love PHP and JavaScript
#335Re: I still love PHP and JavaScript
#336PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
The issue I have with php, having started building websites in the early 2000s with it, is that it is a language that doesn’t push you to write better code and progress. I am much more of a fan of static langages where the IDE guides you a lot more, gives you live feedback so that being curious is cheap, you don’t have to dive into some documentation to know what the other methods, parameters and overloads are, you c…
One of the things I do like about PHP is that while most legacy codebases out there are lousy (even when good developers are involved), and often lousy for totally legitimate reasons, PHP with its "don't even try to do clever" approach makes many things easier.
Of course, I only dealt with so many legacy applications. My worst experiences have always been with python legacy code because there were strata of conflicting "better code" approaches piled on top of each other.
Once you start abstracting into patterns, and you don't have the experience needed to get a sense of good architecture, it's easy to make a real tangled mess.
Re: I still love PHP and JavaScript
#337Earlier quoted context omitted.
I’ve been using PHP since 2003 and it’s my full time job and this doesn’t ring true. Very, very rarely is a gotcha not in the docs comment section.
That’s just it. I have to code with the PHP docs open like some kind of arcane recipe book.
Re: I still love PHP and JavaScript
#338Earlier quoted context omitted.
I’ve been using PHP since 2003 and it’s my full time job and this doesn’t ring true. Very, very rarely is a gotcha not in the docs comment section.
> in the docs comment section. A classic boiled frog statement. __It's not undocumented, someone posted a comment about that bug...__ I will quietly place my face in my hands and weep to the memory of php coding I did 20 years ago. Seems the same nonsensical masochism is still going strong.
Need to do something new in Node? Sift through a bunch of search engine spam, read a few dissenting answers on stackoverflow that refer to a previous version, eventually find a library that does what you want, written by skullM4ster2004, plug one's nose and install it.
Re: I still love PHP and JavaScript
#339PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
I think it's the best documentation out there, and that part of the reason it's easy to document, is because the language uses a standard library, and functions, as opposed to the structure of the language, itself, to provide most of the utility. Functions are easy to document.
They do a good job of "cleaning out the cruft," as well, so that there isn't much in the way of "no longer applies" stuff.
Part of it, too, is that the language probably supports stuff all the way back to 4. They tend not to deprecate, and accrete, instead (not always a good thing). That means that examples and discussions maintain relevance, even years later.
One of the biggest issues that people tend to have with PHP, is that it allows you to write bad code.
I came from a C++ shop (another language that people love to hate). If you think you can write bad code in PHP, C++ says "Hold my beer."
I am a big believer in Discipline. With Discipline, we can write excellent, maintainable, code in any language. I have written stuff in Assembly, FORTRAN, Pascal, PL/1, Perl, Bash, BASIC, C, C++, ObjC, and Swift, that is quite well-structured, maintainable, and well-documented.
Re: I still love PHP and JavaScript
#340Earlier quoted context omitted.
> it's stateless by design (much easier to scale) I noticed being stateless made it difficult to scale for any complex app. It’s been 7-10 years since I used it but Drupal used 60-128MB+ plus per request. As it was stateless it had to do a full bootstrap for every request coming in, set up a new database connection, module discovery etc, all which was heavy to do for every request. Most people scaled Drupal by puttin…
With both Drupal and Laravel it's very easy to overload the database. It's shocking when you start using some tool that gives you insights in to this and it tells you you're running 6000+ queries every time your homepage loads. In Laravel it's not too hard to avoid this problem but a lot of noobs don't get the lazy / eager loading thing and then you end up like this. Drupal seems to add hundreds of queries for every…
I do think very hard up front what the product will require in terms of: - static content - dynamic content that is cacheable and which keys can be used to cache it
Static content can use ORM as much as it wants, cloudfront will take care of it. dynamic content that is rarely hit doesn't really need much help either if there are no UX latency requirements. dynamic content that is hit very often (usually only a couple of endpoints) can be rewritten into manual SQL.
If you think about it, most page hits with dynamic content can be rendered basically by the DB + templating engine, and no other logic should be involved.