4 ms·

> there's little consistency between types and orders of arguments in the base functions of the language This is an inheritance from C. Most of these function

by aries1980 6y ago

> there's little consistency between types and orders of arguments in the base functions of the language This is an inheritance from C. Most of these functions are present in libc and the bound libraries (e.g. libcurl), with the same arguments. 20something years ago, this was a big selling point to me, because I didn't have to re-learn the functions, just use the function and forget about malloc()/free()...

kbenson 6y ago
This clearly shows PHP's origin as a set of loosely related libraries and utilities ties together with a thin veneer of a language. When used as an actual language it's less than ideal. Who's to say curl will still be the default way it makes some requests in the core language later? What if the library changes it's API after deprecating the version that was originally used? Coupling things like that is a poor design choice (unless the thing you're matching is a standard, that's less likely to change in backwards incompatible ways, at least without plans for how to deal with it). It was a benefit to those that knew C and worked with the same libs there, and it was easier for early PHP developers to include stuff (since they didn't have to develop a separate API and abstract usage), but it definitely contributed to PHP's reputation of being hard to intuit how a function expected to be used. You can compare and contrast this to Perl, where for the most part they didn't include C libraries in the core (generally they were done as modules, and there are modules that emulate C's calling methods exactly, and those that provide an extrapolated API, sometimes from the base library, sometimes building on the other module), but they did include a lot of the C standard library functions in familiar usage patters, but still altered to fit the design goals and ideas Perl was being developed with (Perl is a highly designed language, it's just that its design goals often make it look haphazard to those that haven't internalized them). Both approaches have their strengths and weaknesses. I would say PHP's approach was useful very early on, but quickly became detrimental for most users (it was useful longer for devs I imagine), but PHP's other strengths helped mitigate that (IMO, being able to be built into Apache in a manner other languages couldn't imitate well was a killer feature for a long time).
- 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

This clearly shows PHP's origin as a set of loosely related libraries and utilities ties together with a thin veneer of a language. When used as an actual language it's less than ideal. Who's to say curl will still be the default way it makes some requests in the core language later? What if the library changes it's API after deprecating the version that was originally used? Coupling things like that is a poor design choice (unless the thing you're matching is a standard, that's less likely to change in backwards incompatible ways, at least without plans for how to deal with it). It was a benefit to those that knew C and worked with the same libs there, and it was easier for early PHP developers to include stuff (since they didn't have to develop a separate API and abstract usage), but it definitely contributed to PHP's reputation of being hard to intuit how a function expected to be used. You can compare and contrast this to Perl, where for the most part they didn't include C libraries in the core (generally they were done as modules, and there are modules that emulate C's calling methods exactly, and those that provide an extrapolated API, sometimes from the base library, sometimes building on the other module), but they did include a lot of the C standard library functions in familiar usage patters, but still altered to fit the design goals and ideas Perl was being developed with (Perl is a highly designed language, it's just that its design goals often make it look haphazard to those that haven't internalized them). Both approaches have their strengths and weaknesses. I would say PHP's approach was useful very early on, but quickly became detrimental for most users (it was useful longer for devs I imagine), but PHP's other strengths helped mitigate that (IMO, being able to be built into Apache in a manner other languages couldn't imitate well was a killer feature for a long time).

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.