3 ms·
PHP's worst problem is an exacerbated form of what strangled Perl for many years (and still does, though they're actively fighting it): lots and lots of existin
by eevee 13y ago
PHP's worst problem is an exacerbated form of what strangled Perl for many years (and still does, though they're actively fighting it): lots and lots of existing code that's really, really bad.
Adding new features doesn't help that. Only gradually deprecating old ones (or waiting a few decades) does, and that doesn't seem to be in PHP's blood.
- stephenr 13y agoDeprecating unsafe/"bad" features is not "in PHP's blood" ? Have you even read a PHP changelog recently?
- eevee 13y agoPHP has deprecated obviously insecure behaviors that are largely Web-related, yes. I'm coming from a Perl perspective, where deprecating bad language features means things like "radically overhauling how variables work" or "putting major community effort into eliminating an entire kind of variable". I'm not aware of many similarly-radical changes in PHP, except perhaps whatever happened with PHP 4's short-lived classes.
- stephenr 13y agoRadically overhaul how variables work? Im not sure i even understand what that is supposed to achieve? Make them not variable any more? You're suggesting self-proclaimed radical changes but not giving any information about the actual advantages?
- eevee 13y agoAh, sorry, some actual context might be helpful. In Perl, variable declaration was originally even worse than it is in PHP: any variable, anywhere, required no declaration and was assumed to be a global. (This was inherited from... some combination of awk and shell, I guess.) Obvious problems aside, a practical implication was that recursion was pretty awkward, since the callee and the caller were sharing the same namespace for the same code. Perl 5.000 introduced the `my` function, which would declare a variable as lexically scoped. This solved the practical issues, but it left the problem of error-checking: a typo in a variable name would still create an implicit global with no warning. The solution was the opt-in `use strict;` declaration, which disabled the implicit-global behavior and made unrecognized variable names a compile-time error. Code could be fixed and then opt into the stricter semantics on a per-file (or even per-block!) basis, and nowadays most Perl devs will jump on you like a pack of hyenas if your code doesn't start with `use strict;` or some equivalent. Over time other features with too-sharp edges have been culled, still supported by the interpreter (Perl is more or less compatible going back decades) but made illegal in strict mode. JavaScript's weird "use strict" opt-in is a spiritual port of Perl's approach, stuffed into a string literal to fit into the existing syntax. One of its effects is even the same: assigning to an unrecognized name is now illegal, rather than creating an implicit global. I'm not aware of anything so fundamental being changed in such a heavy-handed way in PHP. From the outside looking in, I'm not even sure the PHP community has a strong consensus on what PHP-specific features to avoid. I'd be happy to learn that I'm wrong on either count.
- stephenr 13y agothanks for the info - it makes sense now. its a similar issue to non-declared vars in js as you mentioned, but even then that was not a language fault per-se, it's just a lack of knowledge about the language. i can't think of things that actually come up like that in php these days - things like register globals and magic quotes are long gone..
- eevee 13y agoI disagree that it wasn't a language fault; it provided very little benefit and directly caused hard-to-diagnose bugs. Being told where the mines are doesn't make walking across a minefield any more palatable. If it were a good idea it wouldn't still be around. Undeclared variables in PHP produce an E_NOTICE, right? Better than Perl 4, at least. :)
- stephenr 13y agoyes reading from undeclared php variables causes an error, assuming you haven't silenced using @ or set php to ignore notices.
- rbanffy 13y agoPHP's worst feature is programmers who only learn PHP. Even worse when they become the most vocal members of the community. This creates an echo-chamber-like environment that's not favorable to the evolution of a rich programming language. Since they never got to learn other languages (at least not enough) its evolution is guided by partial impressions of what other languages offer. It then becomes a collage of partial implementation of concepts similar to what other languages are based on. Try explaining recursion to someone who only knows 8-bit BASIC (where all variables are global and functions are implemented as subroutines with known input and output variables). It won't work.
- eevee 13y agoIt is rather telling that PHP's design is based on whatever was popular at the time. The original design was based on Perl, further additions and the stdlib were designed like C++, the class system is a lot like Java, and recent features have been clearly inspired by Python. I've met more than enough PHP programmers who genuinely tout "it's free" and "you don't have to declare types" as unique advantages, or are unaware that you can even build a website in anything else.