Quote (HighschoolTurd @ Mar 3 2014 02:10am)
That sounds like a personal coding problem. PHP can be just fine if the person knows how to secure it.
The problem is that instead of having security baked in by default you need to go out of your way to make sure everything is secure. This is bad design and only shitty programmers and/or idiots want features to be more obscure and harder to configure.
Quote (HighschoolTurd @ Mar 3 2014 02:06am)
Like? Example?
This guy nails it:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/He cites these points as hallmarks of a well-designed language:
Quote (veekun)
A language must be predictable. It’s a medium for expressing human ideas and having a computer execute them, so it’s critical that a human’s understanding of a program actually be correct.
A language must be consistent. Similar things should look similar, different things different. Knowing part of the language should aid in learning and understanding the rest.
A language must be concise. New languages exist to reduce the boilerplate inherent in old languages. (We could all write machine code.) A language must thus strive to avoid introducing new boilerplate of its own.
A language must be reliable. Languages are tools for solving problems; they should minimize any new problems they introduce. Any “gotchas” are massive distractions.
A language must be debuggable. When something goes wrong, the programmer has to fix it, and we need all the help we can get.
PHP in some major way on all five points. Some examples of really mind-bendingly stupid design:
Quote (veekun)
Weak typing (i.e., silent automatic conversion between strings/numbers/et al) is so complex that whatever minor programmer effort is saved is by no means worth it.
...
For the same reason, "6" == " 6", "4.2" == "4.20", and "133" == "0133". But note that 133 != 0133, because 0133 is octal. But "0x10" == "16" and "1e3" == "1000"!
...
0x0+2 produces 4. The parser considers the 2 as both part of the hex literal and a separate decimal literal, treating this as 0x002 + 2. 0x0+0x2 displays the same problem. Strangely, 0x0 +2 is still 4, but 0x0+ 2 is correctly 2. (This is fixed in PHP 5.4. But it’s also re-broken in PHP 5.4, with the new 0b literal prefix: 0b0+1 produces 2.)
Weak typing is good in many ways. Weak typing with simple implicit conversion *can* be ok. Weak typing with incredibly complicated implicit conversion that may or may not work because the PHP developers love to regress bugs? That's really bad design and encourages programming mistakes.
Since a language should be predictable, this shouldn't be there:
Quote (veekun)
There is a whole lot of action at a distance. Consider this code, taken from the PHP docs somewhere.
@fopen('http://example.com/not-existing-file', 'r');
What will it do?
If PHP was compiled with --disable-url-fopen-wrapper, it won’t work. (Docs don’t say what “won’t work” means; returns null, throws exception?) Note that this flag was removed in PHP 5.2.5.
If allow_url_fopen is disabled in php.ini, this still won’t work. (How? No idea.)
Because of the @, the warning about the non-existent file won’t be printed.
But it will be printed if scream.enabled is set in php.ini.
Or if scream.enabled is set manually with ini_set.
But not if the right error_reporting level isn’t set.
If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.
I can’t tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. And this is all built in behavior.
The fuck? Also '@' is a PHP operator (stolen from DOS, which isn't the first place I would take programming hints from) and that will silence thrown errors. Oh, but if you don't use that and get an error you may not ever see unless you set up a global handler for it. That's incredibly stupid and the only thing it would do is waste my time setting something up that should just be the default.
On to operators! Those should just work, right? I mean how could anyone fuck up equality?
Quote (veekun)
== is useless.
It’s not transitive. "foo" == TRUE, and "foo" == 0… but, of course, TRUE != 0.
== converts to numbers when possible (123 == "123foo"… although "123" != "123foo"), which means it converts to floats when possible. So large hex strings (like, say, password hashes) may occasionally compare true when they’re not. Even JavaScript doesn’t do this.
For the same reason, "6" == " 6", "4.2" == "4.20", and "133" == "0133". But note that 133 != 0133, because 0133 is octal. But "0x10" == "16" and "1e3" == "1000"!
=== compares values and type… except with objects, where === is only true if both operands are actually the same object! For objects, == compares both value (of every attribute) and type, which is what === does for every other type
That is atrocious. Object/primitive equality being transitive is like language design 101. How could you possibly fuck that up? Oh wait, it's incredibly easy because of the insane weak typing system and bad developers.
Here's another gem:
Quote (veekun)
Unlike (literally!) every other language with a similar operator, ?: is left associative. So this:
$arg = 'T';
$vehicle = ( ( $arg == 'B' ) ? 'bus' :
( $arg == 'A' ) ? 'airplane' :
( $arg == 'T' ) ? 'train' :
( $arg == 'C' ) ? 'car' :
( $arg == 'H' ) ? 'horse' :
'feet' );
echo $vehicle;
prints horse.
Some bitching about functions:
Quote (veekun)
Function calls are apparently rather expensive.
Some built-in functions interact with reference-returning functions in, er, a strange way.
As mentioned elsewhere, a lot of things that look like functions or look like they should be functions are actually language constructs, so nothing that works with functions will work with them.
Function arguments can have “type hints”, which are basically just static typing. But you can’t require that an argument be an int or string or object or other “core” type, even though every builtin function uses this kind of typing, probably because int is not a thing in PHP. (See above about (int).) You also can’t use the special pseudo-type decorations used heavily by builtin functions: mixed, number, or callback. (callable is allowed as of PHP 5.4.)
As a result, this:
function foo(string $s) {}
foo("hello world");
produces the error:
PHP Catchable fatal error: Argument 1 passed to foo() must be an instance of string, string given, called in...
You may notice that the “type hint” given doesn’t actually have to exist; there is no string class in this program. If you try to use ReflectionParameter::getClass() to examine the type hint dynamically, then it will balk that the class doesn’t exist, making it impossible to actually retrieve the class name.
A function’s return value can’t be hinted.
Seriously. Read the whole article. It's painful. Just because you can get things done with PHP doesn't mean that you should use it. Cutting down on development time and testing time is how real software engineers get things done.
This post was edited by rockonkenshin on Mar 3 2014 07:27am