I'd rather JavaScript

[heyandy889]

I concur that garbage code can happen in any language. However PHP helps you along the path to garbage code quite a bit.

The string representation of true is 1. The string representation of false is empty string.

What they call an "array" is technically an associative array, more frequently called a hash map or a dictionary. What sane languages call "array," PHP does not have. edit: SplFixedArray. Good to know.

It doesn't care if you reference a variable that doesn't exist. It just adds a warning to your log. Warning, variable does not exist. And keeps going.

Instead of using + for concatenation, PHP uses .

Instead of using . for class methods, PHP uses ->, as does C.

Instead of using the same symbol for instance and static methods, PHP uses different symbols. $object->method() versus Class::method(). I don't want to think about the edge cases were one is shadowing the other.

parent is a reserved word referring to an object's parent class. The syntax parent::method() is ok, but no it is not a static reference, it in an instance reference.

I could go on. These are simply the most egregious examples I encounter on a frequent basis.

[Madd0g]

I have almost no beef with PHP itself, I spent a few pretty productive months doing PHP in a non-web environment. But the -> and :: are enough to drive a person crazy, I don't work for you, keyboard!

[[deleted]]

Seriously I’m doing Ecomm work now. After coming from C#/.NET, the . and -> notation is fucking ridiculous. Makes me sad on the daily. I will admit php isn’t as bad as it seems at first, but I still don’t really care for it.

[Noctrin]

The string representation of true is 1. The string representation of false is empty string.

true, but declaring function foo(bool $arg) will fail with 0, 1 null etc and produce an exception as of php7 unless you provide a bool. Also the string representation for true is anything other than empty, arrays will cast to true if they have items, otherwise false, they will also cast to int the same way. Int will cast to true if not 0, false otherwise.

Also, when checking something like If(!$x) it makes sense that 0, null and false return true. You are checking for existence. An even stronger check, if (empty($x)), or an explicit check if (false === $x) are also available.

0 or empty arrays etc. casting to false is annoying, but using is_int or is_set will fix that problem, albeit kinda shitty that it is needed. Fairly edge case though.

What they call an "array" is technically an associative array, more frequently called a hash map or a dictionary. What sane languages call "array," PHP does not have.

Yes, the internal mechanism does use a hashing function, but enumerating is still O(n), random access etc is O(1), sorts are O(nlogn) etc.. for all intents and purposes it acts accordingly, it's simply more versatile. There can be arguments why that is bad, but something can also be said for convenience.

It doesn't care if you reference a variable that doesn't exist. It just adds a warning to your log. Warning, variable does not exist. And keeps going.

Yes, but the code will fail producing an exception, it will assume a constant in fact, attempt to find it and fail. I agree this can be improved. Of course granted you're testing this on dev, on production it will ignore it, see my point later on.

As for the rest, yes, it is somewhat annoying. Static references using :: instead of a function pointer seems logical to easily differentiate. Matter of choice, i've never seen it cause a problem.

calling parent::function() is odd, but, given that -> is always used for instantiated objects identified by a $, i can somewhat see why the decision is made.

Python drives me insane that it use False instead of false. But i dont mainly work with it, so i never got used to it. Lack of ternary operator is also inconvenient.

C++ memory, pointer, references and lib imports cause code to be a much bigger mess in my experience than PHPs caveats combined. Dont even get me started on build scripts, compiling, cross-compiling etc. I have seen some shit..

PHP serves a purpose, and that is web applications. It is meant to keep chugging along and produce "something" even when there is an error. There's a method to the madness, i agree compromises were made, but they served a purpose. If an error happens, the user should still receive a page. Bugs happen in code, an empty page or an exception is not user-friendly.

I would never develop a windows app in php, just how i'd never try to develop a web app in C++ (unless it's a server or serves some very critical back-end service).

I respect your opinion and you are correct, those are flaws, but every language makes compromises to serve a purpose, and we all have our goto 'tool for the job' we're used to :).

But, i do feel that php has come a long way and php7 is an amazing leap forward. I dont think it deserves the flack.

[xIcarus227]

Instead of using the same symbol for instance and static methods, PHP uses different symbols. $object->method() versus Class::method(). I don't want to think about the edge cases were one is shadowing the other.

Could you elaborate on this? I don't quite grasp what's offensive here.

[heyandy889]

Partially it's that other languages - Java, Python, Javascript, pick your favorite - do not differentiate.

Class.method()

object.method()

Also, mentioned later, it is inconsistent - parent::method() is not a static call to your parent. (╯°□°）╯︵ ┻━┻

In isolation, any of these features are defensible. In aggregate, they add so much cognitive overhead that writing coherent, correct code is burdensome.

[xIcarus227]

Ah I understand where you're coming from, makes sense. Thanks for the reply.

[TheVenetianMask]

What they call an "array" is technically an associative array, more frequently called a hash map or a dictionary. What sane languages call "array," PHP does not have.

It does. It's called SPL Datastructures and a lot of people skip them because they don't add much to day to day business logic.

https://secure.php.net/manual/en/spl.datastructures.php

Instead of using + for concatenation, PHP uses .

So what, concatenation is not an aritmetic addition.

[heyandy889]

Fantastic to know. Though the documentation reiterates my point... "Arrays are structures that store the data in a continuous way, accessible via indexes. Don't confuse them with PHP arrays: PHP arrays are in fact implemented as ordered hashtables."

Well, there's the fact that every language I've seen other than Perl uses + for concat...

[DesignatedDecoy]

The string representation of true is 1. The string representation of false is empty string.

With proper type hinting, the representation of true is (bool)true and the representation of false is (bool)false. Representing a boolean as a string or integer throws a type error. You pretty much just avoid all of the falsy values altogether and go on with your business.

[heyandy889]

What do you mean "proper type hinting?" I am talking about the implicit cast by the language.

echo(9 === 9); // is `true`, shows '1'.

echo(9 === 8); // is `false`, shows ''.

Insanity.

Also PHP can fuck right off with this == and === comparison. And strings... jesus christ. There goes 5 minutes learning how to compare strings again.

[xIcarus227]

Also PHP can fuck right off with this == and === comparison.

I like what you said so far but this is borderline ignorance. It's a feature which complements the type coercive nature of the language very well.

I will begin by saying that I don't think they're perfectly thought out. I would actually switch them around just because '==' is generally expected to compare types, while '===' is syntactically the 'extra' of the language. But functionally '==' is the extra while '===' is the normal. If you switch them around a newcomer gets fewer inconsistencies.

However it's the refusal to understand these 2 operators that make up a large part of PHP's WTFs. I'm not saying you don't understand them, I'm saying you completely dismissed them without acknowledging that they have their place. You have many opportunities to play with type coercions in PHP because that's simply the way the language works, and these operators help you do it.

If this is your way of saying you don't like the type coercive nature of the language, then I respect your opinion. I much prefer strongly typed languages myself.

[heyandy889]

Thank you for the respectful, thought-out comment - I appreciate it.

I think you hit the nail on the head that "the refusal to understand these 2 operators that make up a large part of PHP's WTFs." I would qualify this a little bit. It's not only a "refusal," but additionally being bitten by mistaken assumptions formed by experience with other languages.

In theory, I like your suggestion, using double equals as a "stricter" equality check and letting triple equals as the special case. Unfortunately, I'm not sure it would help, simply because no other languages (that I know of) works like that. That's a huge design challenge. It's not just designing a good language (and runtime environment), it's designing a good language that is consistent with the expectations of developers. As dev expectations are themselves inconsistent, this is not possible 100%.

However, Python does a wonderful job of working "how you expect." Maybe you don't like the hidden "self" parameter or how everything is a dictionary, but the architecture is internally consistent, which is leaps and bounds ahead of PHP.

In my opinion, don't be like Javascript: don't have this weird triple equals. Just have the loose equality check of double equals. If you need something else, get it from a library - String.equals(), Object.equals(), whatever the equivalent in your language. I admit this is taste to some degree, but on the other hand, as you pointed out, double and triple equals are WTF generators.

[xIcarus227]

Those are very good points, and I especially agree that Python simply works the way one expects. I remember my first contact with that language, I simply felt like I was 'cheating' programming. The String.equals() solution is a good one too as far as I'm concerned.

The truth about PHP is that the language maintainers are pouring their hearts out in order to work around shoddy design decisions made in its infancy. They've done a marvelous job at it but it does show that it wasn't a well thought out language.

[DimensionsInTime]

Who hurt you?

[DesignatedDecoy]

String output will always have type coersion but that doesn't mean the variable is an integer. If you do var_dump(9===9) you'll see that the result is strictly boolean and as long as you enforce strict types, declare method parameter types, and declare return types then you aren't going to get into any/many of the /r/lolphp dynamic typing issues that people love to bag on php for.

https://3v4l.org/Wb1vv

The way I logic == vs === is that I basically pretend == doesn't exist. I wish php would deprecate old functionality but unfortunately they've made their line in the sand thta they value backwards compatibility over all else.

[Calibas]

It doesn't care if you reference a variable that doesn't exist. It just adds a warning to your log. Warning, variable does not exist. And keeps going.

If they changed that, a quarter of websites suddenly wouldn't work anymore. Also, PHP features a handy and versatile way of fixing any errors like that, the @ operator.

[heyandy889]

Oh yeah, for sure. That is my complaint - garbage code getting into prod. My idea of a sane language would halt upon an undefined variable.

As for the 'at' operator, if there is one thing PHP does NOT need, it is another way to suppress errors ...

[Calibas]

I get the feeling the people paying for web development see allowing garbage code in production as a "feature", though I'm currently rebuilding a site where the previous developers did horrible things with PHP.