4 ms·
>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 impec
by 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 agoNone 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.)
- scq 7y ago> 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 That sounds interesting, do you have a link to that paper? (I couldn't find it with a quick Google.)
- earthboundkid 7y agoFWIW, JavaScript fixed its scope problems with modules, which default to strict mode.