3 ms·

Indeed, but modern frameworks get around this quickly. If you use Symfony, Laravel or Drupal, you will likely never use these functions, because they are packag

by aries1980 6y ago

Indeed, but modern frameworks get around this quickly. If you use Symfony, Laravel or Drupal, you will likely never use these functions, because they are packaged as a replaceable module with proper OOP interfaces and classes. Most people who pick PHP these days are doing that because these very mature frameworks. I see no alternative to Drupal with all its glory in any of the modern languages. I think PHP-s success was related to its relative low latency compared the early Ruby and Perl, especially when FCGI became supported. We could easily serve 200+ interactive websites on a single desktop PC, with five-nines SLO. Sure, there are much better, more fun languages these days, but to retire PHP we need to find better worthy FOSS alternatives to the PHP CMS-es.

kbenson 6y ago
I don't necessarily think PHP needs to be retired. It's obviously matured and has plenty of use. I was just pointing out the flip side to using similar functions to the underlying C libs. I've come to view languages as a set of competing trade-offs that optimize for specific points in it's life-cycle, whether purposefully or accidentally. For example, Python's "batteries included" feature was extremely useful early on. Now a lot of the included modules are superseded by a better external module that's the de-facto standard. For example, the Requests library for Python. Originally batteries included was a feature, but now certain modules in the standard library are mostly useful for backwards compatibility and do little otherwise except confuse new Python programmers. Perl went through the same with the CGI module, which was old, crufty, had an interface that made it hard to keep contained, and was almost universally considered a bad idea (except for when you needed it for backwards compatibility, or really actually needed a CGI). It was eventually excised from the standard library, and relegated to an external library, so the Perl core didn't have to worry about it and it wasn't considered the default method for created web pages in Perl. And that's just one axis. There's also optimizing for ease of use for amateurs (i.e. ease of learning) or ease of use for laymen/professionals. One makes it harder to get new users, the other often makes it harder to retain existing users (because what a layman wants is often not the same as what an amateur wants). You could consider APL to be at an extreme end of this spectrum. I imagine APL laymen are happy with the concise format and features because they've developed the skills to accurately read and interpret APL programs. As someone that doesn't know APL (as amateur as you can get), it's extremely daunting to see. Then there's verbosity vs conciseness. And any number of other aspects of a language. Each is usually imparting some specific aspect to the language, and isn't necessarily better or worse than the same aspect of different languages, but often just optimized for something different.

kbenson 6y ago

I don't necessarily think PHP needs to be retired. It's obviously matured and has plenty of use. I was just pointing out the flip side to using similar functions to the underlying C libs. I've come to view languages as a set of competing trade-offs that optimize for specific points in it's life-cycle, whether purposefully or accidentally. For example, Python's "batteries included" feature was extremely useful early on. Now a lot of the included modules are superseded by a better external module that's the de-facto standard. For example, the Requests library for Python. Originally batteries included was a feature, but now certain modules in the standard library are mostly useful for backwards compatibility and do little otherwise except confuse new Python programmers. Perl went through the same with the CGI module, which was old, crufty, had an interface that made it hard to keep contained, and was almost universally considered a bad idea (except for when you needed it for backwards compatibility, or really actually needed a CGI). It was eventually excised from the standard library, and relegated to an external library, so the Perl core didn't have to worry about it and it wasn't considered the default method for created web pages in Perl. And that's just one axis. There's also optimizing for ease of use for amateurs (i.e. ease of learning) or ease of use for laymen/professionals. One makes it harder to get new users, the other often makes it harder to retain existing users (because what a layman wants is often not the same as what an amateur wants). You could consider APL to be at an extreme end of this spectrum. I imagine APL laymen are happy with the concise format and features because they've developed the skills to accurately read and interpret APL programs. As someone that doesn't know APL (as amateur as you can get), it's extremely daunting to see. Then there's verbosity vs conciseness. And any number of other aspects of a language. Each is usually imparting some specific aspect to the language, and isn't necessarily better or worse than the same aspect of different languages, but often just optimized for something different.