3 ms·

PHP is, and always has been a practical language. 7.4 has been especially exciting with the introduction of FFI. Few other languages even have runtime FFI, and

PHP is, and always has been a practical language. 7.4 has been especially exciting with the introduction of FFI. Few other languages even have runtime FFI, and in most cases you have to do the binding stuff in C. I even ported a terminal-mode text editor (which uses FFI somewhat) from C to PHP: https://git.timshomepage.net/timw4mail/php-kilo https://git.timshomepage.net/timw4mail/php-kilo I would guess most of the PHP haters got stuck working on Wordpress, or someone's old business app, or they just hate PHP because it's popular to do so.

Snelius 7y ago
PHP is, and always has been a "Personal Home Page"
- Piskvorrr 7y ago
  Hasn't been since about version 3, which went obsolete in the previous millennium;) Not even technically correct: I mean, Windows for IoT doesn't even need to have any windows, therefore it's not actually Windows, eh? (No. That was a joke.) In other words, PHP is still "PHP hypertext preprocessor", even though it is used far more generally.
int_19h 7y ago
What mainstream languages are you thinking of that don't have runtime FFI? (that have runtimes making it necessary in the first place)
wahern 7y ago
This new FFI support intrigued me. But looking at the source, it's just a wrapper around libffi. I don't know of any language that doesn't provide a wrapper around libffi, though not all provide it as a default-installed module. PHP's bindings also provide a simple YACC-based parser for automatically extracting simple size and layout information from C header files, though this is easy enough to write in-language (heck, there's a full C99-compliant LPeg parser). Notably, PHP's parser, like LuaJIT's, doesn't handle the preprocessor, so its useless without resorting to a separate program (e.g. cpp(1)) if you want automagic bindings.[1] So, kudos for PHP for doing this. Not exactly a game changer, though. The performance cargo cult dislikes libffi as it can be relatively slow compared to an inline binding (static or dynamic) due to the need to copy input parameters (by reference, not by value) to an intermediate data structure on every invocation, and due to the fact that some JIT'd languages can JIT through the external function invocation (LuaJIT can do this, IIRC). It's ridiculous, but it is what it is; libffi effectively "taints" FFI support as non-native, which is a death sentence these days. I think PHP is a horrible, cobbled together language. If the core maintainers had a strong grounding in language theory, design, and practice, they do an impeccable job filtering it out of the final product. It's been this way from the very beginning, and by everything I see today, remains so. That said, it's the first thing I turn to when I need to put up a simple web page with server-side logic! I have absolutely no desire or tolerance to fsck around with CGI, modules, packages, or anything else, and the PHP ecosystem Just Works out-of-the-box on every system (Linux, BSD, Windows) I've ever tried it on. [1] Such parsers are kind of useless. Better to provide built-in sizes for core system data types like time_t and then, optionally, provide a simple, quasi-C grammar for expressing redundant definitions that you parse inline. Which is presumably how such parsers are used in practice, notwithstanding the pretense. Plus, I run all my web applications in jails (chroot, pledge, seccomp, etc). If system and library headers are visible at runtime, something is broken. If someone really wanted to go the extra hundred miles for proper automagic bindings, one could use ELF symbol information, for example debug symbols (e.g. DWARF) or simpler symbol info (e.g. BTF on Linux, derivative of Solaris' ABI metadata, which was directly supported by OpenBSD before the Linux project got started).
- rawoke083600 7y ago
  >I think PHP is a horrible, cobbled together language. If the core maintainers had a strong grounding in language theory, design, and practice, they do an impeccable job filtering it out of the final product. urg and then ?? We will have just another Python, C, .Net or Go, which are all good for some ppl and some things.. Sometimes you just need some outside the box thinking...
  - wahern 7y ago
    None of PHPs warts benefit the language. At best they benefit the implementation, which is presumably why it happens. (Various inconsistencies and warts in Python and JavaScript can be readily traced back to implementation barriers, as well.) But languages like Lua show that PHP could have implemented all its features wart-free without undue implementation complexity or any runtime cost as almost no language element in PHP was added and implemented until long after it was added in other languages, including Lua, which is a fraction of the size of every major comparable language out there and generally faster to boot.[1] PHP is great despite itself. But great it is. You can say that about many popular software tools, but PHP is unique in effectively going unchallenged in its domain, iteration after iteration, decade after decade, quirk after quirk. ColdFusion was the only real competitor, but it died when they tried to replace CFML with CFScript. (Well, also because ColdFusion was proprietary.) People believe languages become popular because of their design features, but if that were true we'd all be writing in Haskell and Scheme with shims for C-family, imperative-style syntax. In truth language features, including syntax, are usually driven by implementation barriers that arise early in a language's evolution, starting with the choice of GC or no GC. The language succeeds despite itself. Lua is a uniquely elegant language precisely because the Lua authors eschew backwards compatibility between every significant release. Every major release of Lua (which looks like a minor release if you expect SemVar) involves a wholesale refactor of the implementation, and syntax breaks are judiciously allowed (i.e. more weight is given to implementation complexity than to compatibility convenience, relative to other languages). It drives people nuts, but the product of this process is the only reason one comes to use Lua in the first place. Functional language families have a leg up in this regard, but ultimately it still plays out the same way, which is why not all functional languages are the same. PHP stands out for having no legitimate excuse for its quirks beyond, "we don't need to bother because we're unchallenged [for myriad accidental reasons]." [1] For example, JavaScript's lexical scoping quirk derives from its original half-baked implementation. But the Lua authors published a paper many years before PHP got closures (possibly more than a decade before?) that explained their technique for implementing proper, quirk-free lexical closures in just a handful of lines of C-like example code. And Lua's compiler compiles to bytecode as it parses, much like early C compilers, so it doesn't have the benefit of arbitrary lookahead or multiple passes. Someone elsethread asked why PHP (and some other languages) require explicit variable bindings for closures. People like to say that they prefer this syntax, but regardless of whether it's preferable, the fact of the matter is that in practice it happens because it's easier to do it that way, especially for statically typed languages. (Except it's not necessarily easier, as Lua shows.)
sleavey 7y ago
For anyone wondering like I was, it's "Foreign function interface" [1]. [1] https://en.wikipedia.org/wiki/Foreign_function_interface https://en.wikipedia.org/wiki/Foreign_function_interface
tyingq 7y ago
"Few other languages even have runtime FFI, and in most cases you have to do the binding stuff in C." The most often cited siblings to PHP have ffi implementations. Built into python now. Ruby, Perl, and Node.js all have popular extensions for it. Libffi opened this up for a lot of languages.
- timw4mail 7y ago
  Fair enough, but it still looks like most of those require an extension that isn't usually bundled with the language.

Snelius 7y ago

PHP is, and always has been a "Personal Home Page"

Piskvorrr 7y ago
Hasn't been since about version 3, which went obsolete in the previous millennium;) Not even technically correct: I mean, Windows for IoT doesn't even need to have any windows, therefore it's not actually Windows, eh? (No. That was a joke.) In other words, PHP is still "PHP hypertext preprocessor", even though it is used far more generally.

int_19h 7y ago

What mainstream languages are you thinking of that don't have runtime FFI? (that have runtimes making it necessary in the first place)

wahern 7y ago

This new FFI support intrigued me. But looking at the source, it's just a wrapper around libffi. I don't know of any language that doesn't provide a wrapper around libffi, though not all provide it as a default-installed module. PHP's bindings also provide a simple YACC-based parser for automatically extracting simple size and layout information from C header files, though this is easy enough to write in-language (heck, there's a full C99-compliant LPeg parser). Notably, PHP's parser, like LuaJIT's, doesn't handle the preprocessor, so its useless without resorting to a separate program (e.g. cpp(1)) if you want automagic bindings.[1] So, kudos for PHP for doing this. Not exactly a game changer, though. The performance cargo cult dislikes libffi as it can be relatively slow compared to an inline binding (static or dynamic) due to the need to copy input parameters (by reference, not by value) to an intermediate data structure on every invocation, and due to the fact that some JIT'd languages can JIT through the external function invocation (LuaJIT can do this, IIRC). It's ridiculous, but it is what it is; libffi effectively "taints" FFI support as non-native, which is a death sentence these days. I think PHP is a horrible, cobbled together language. If the core maintainers had a strong grounding in language theory, design, and practice, they do an impeccable job filtering it out of the final product. It's been this way from the very beginning, and by everything I see today, remains so. That said, it's the first thing I turn to when I need to put up a simple web page with server-side logic! I have absolutely no desire or tolerance to fsck around with CGI, modules, packages, or anything else, and the PHP ecosystem Just Works out-of-the-box on every system (Linux, BSD, Windows) I've ever tried it on. [1] Such parsers are kind of useless. Better to provide built-in sizes for core system data types like time_t and then, optionally, provide a simple, quasi-C grammar for expressing redundant definitions that you parse inline. Which is presumably how such parsers are used in practice, notwithstanding the pretense. Plus, I run all my web applications in jails (chroot, pledge, seccomp, etc). If system and library headers are visible at runtime, something is broken. If someone really wanted to go the extra hundred miles for proper automagic bindings, one could use ELF symbol information, for example debug symbols (e.g. DWARF) or simpler symbol info (e.g. BTF on Linux, derivative of Solaris' ABI metadata, which was directly supported by OpenBSD before the Linux project got started).

rawoke083600 7y ago
>I think PHP is a horrible, cobbled together language. If the core maintainers had a strong grounding in language theory, design, and practice, they do an impeccable job filtering it out of the final product. urg and then ?? We will have just another Python, C, .Net or Go, which are all good for some ppl and some things.. Sometimes you just need some outside the box thinking...
- wahern 7y ago
  None of PHPs warts benefit the language. At best they benefit the implementation, which is presumably why it happens. (Various inconsistencies and warts in Python and JavaScript can be readily traced back to implementation barriers, as well.) But languages like Lua show that PHP could have implemented all its features wart-free without undue implementation complexity or any runtime cost as almost no language element in PHP was added and implemented until long after it was added in other languages, including Lua, which is a fraction of the size of every major comparable language out there and generally faster to boot.[1] PHP is great despite itself. But great it is. You can say that about many popular software tools, but PHP is unique in effectively going unchallenged in its domain, iteration after iteration, decade after decade, quirk after quirk. ColdFusion was the only real competitor, but it died when they tried to replace CFML with CFScript. (Well, also because ColdFusion was proprietary.) People believe languages become popular because of their design features, but if that were true we'd all be writing in Haskell and Scheme with shims for C-family, imperative-style syntax. In truth language features, including syntax, are usually driven by implementation barriers that arise early in a language's evolution, starting with the choice of GC or no GC. The language succeeds despite itself. Lua is a uniquely elegant language precisely because the Lua authors eschew backwards compatibility between every significant release. Every major release of Lua (which looks like a minor release if you expect SemVar) involves a wholesale refactor of the implementation, and syntax breaks are judiciously allowed (i.e. more weight is given to implementation complexity than to compatibility convenience, relative to other languages). It drives people nuts, but the product of this process is the only reason one comes to use Lua in the first place. Functional language families have a leg up in this regard, but ultimately it still plays out the same way, which is why not all functional languages are the same. PHP stands out for having no legitimate excuse for its quirks beyond, "we don't need to bother because we're unchallenged [for myriad accidental reasons]." [1] For example, JavaScript's lexical scoping quirk derives from its original half-baked implementation. But the Lua authors published a paper many years before PHP got closures (possibly more than a decade before?) that explained their technique for implementing proper, quirk-free lexical closures in just a handful of lines of C-like example code. And Lua's compiler compiles to bytecode as it parses, much like early C compilers, so it doesn't have the benefit of arbitrary lookahead or multiple passes. Someone elsethread asked why PHP (and some other languages) require explicit variable bindings for closures. People like to say that they prefer this syntax, but regardless of whether it's preferable, the fact of the matter is that in practice it happens because it's easier to do it that way, especially for statically typed languages. (Except it's not necessarily easier, as Lua shows.)

sleavey 7y ago

For anyone wondering like I was, it's "Foreign function interface" [1]. [1] https://en.wikipedia.org/wiki/Foreign_function_interface https://en.wikipedia.org/wiki/Foreign_function_interface

tyingq 7y ago

"Few other languages even have runtime FFI, and in most cases you have to do the binding stuff in C." The most often cited siblings to PHP have ffi implementations. Built into python now. Ruby, Perl, and Node.js all have popular extensions for it. Libffi opened this up for a lot of languages.

timw4mail 7y ago
Fair enough, but it still looks like most of those require an extension that isn't usually bundled with the language.