What do you mean you don't have every disjointed combination of needle, haystack memorized? ;p

As someone who spent many years developing in (and defending) PHP, I agree with everything you just said.

Nowadays, I'd rather reach for Crystal, Go, or Rust for back-end application development, and Python or Typescript (!) for automation scripts.

> What do you mean you don't have every disjointed combination of needle, haystack memorized? ;p

This is one of the weakest, "not happening in reality" issue of PHP though. It's the most obvious, and the one who don't use php but glance at it point. But in the real world, any editor you use not only show it but also show a type error if you made a mistake, on top of that after a few hours you know which is which (yes strpos and in_array have an opposite haystack/needle, but each always use the same, once you use them more than 5 times you remember the same way you remember to check for 0 on strpos).

There are still flaws in the php world, but the one most commonly pointed out are always sounding funny to me because they're flaws if you show an exemple in a conversation but that you don't actually hit when coding.

I would rather get it right first time every time than get it wrong half the time and have my editor correct me.

Good languages don't make you memorize exceptions.

Which is why it stops being an issue after, what, 2 days ? And most editor also have an autoswap feature for when you have a brain fart because since the language now had proper type hint there is no possibility to misplace a scalar and an array.

But you see other people just 'get it right' the first time every time without even having to use the language. They just 'know' everything up front, or... read it in a forum 8 years ago and it's perfectly crystalized. It's only the lowly PHP plebes who need an editor to help them get things right the first time. Syntax, method naming, parameter order, return values - these are 100% completely solved problems that never cause anyone ANY problems ever in any other language - this is 1100% a PHP-only problem. Can't you understand? The entire rest of the programming world is excellent except for PHP.

Yes... it's a bit /s, and perhaps is a bit much, but... this "my language has no defects!" attitude from everyone crapping on PHP is tiresome. I've been programming as a hobbyist since the 80s, and professionally since the early 90s. Nothing is perfect, everything has warts, the holy wars suck. I've been with PHP since early 96, and have worked in ASP, .NET, Python, Ruby, Java/JVM, Node/JS, and a couple other stacks. They all suck in more than a few ways.

For those of you who only ever work in one tech for years without needing to touch anything else... and get to perfect your parameter-order-fu down to a reflex... great. I'm routinely having to switch between different SQL and various server-side languages, and even then ... 'obvious' things like array/string handling have different syntaxes I have to jump between in a single day. (postgresql arrays are 1-based, not 0-based, IIRC). You know what? I deal with it and move on. IDEs/tools help. Memory helps. Nothing is perfect.

> But in the real world, any editor you use not only show it but also show a type error if you made a mistake

Praytell, how does your editor show you a type error when both `needle` and `haystack` are strings?

Also you can just name your arguments now

Can you share precisely what "mishmash with a bunch of hidden landmines" is?

It's hard to trust a stranger from internet claiming something, but we are in IT so it should be relatively trivial to prove your claims, right?

One somewhat famous hidden landmine is in_array('0010e2', ['1e3']);

And that will return true, because you forgot the third "strict" parameter. This is really something strict_types could/should have fixed, but it doesn't.

You can have code reviews and static analysers and all of that to catch this, but it's definitely a landmine. I've seen some pretty serious CVEs that were fixed just by adding that last parameter to some in_array() call.

But I didn't forget the third strict parameter, because I'm diligent in reading documentation and at my job.

Was that everything? You basically state there's a problem because you didn't use the function correctly and language didn't fall head over heels to stop you from doing silly things due to slopiness?

P.I.C.N.I.C.

People forget this things all the time because people's brains don't work like Spock's brain. There are plenty of junior programmers around that will have to be taught this. It's a footgun. Is it manageable? Sure; I already said that. But that doesn't make it not a footgun. Anyone who says anything else is not serious.

Check this - if it's something important.. don't forget it and implement something called "function" that would pass the third parameter by default?

Anyone who is not capable of taking care of what you called footgun in a way where they automate - that person is not serious.

If there's a pretty huge problem - manage it. That's your job as programmer. If you're lazy, sloppy and prefer whining online over being proud of your work - there's no programming language that will take care of that for you.

If a function that causes security vulnerabilities if you fail to read the documentation diligently doesn't count as a landmine to you, what does?

Please provide examples in other languages (eg rust) so that I can answer your original question properly and to your satisfaction

No, it's not a function that causes it. It's the dev who is sloppy and causes issues. Would you blame the scalpel or brain surgeon for mishap while cutting important bits in the brain?

What kind of logic is this, to blame the tool because you have no clue how to use it?

That's a very good analogy because they had to stop using scalpels in brain surgery because the surgeons kept making mistakes.

Tools must be designed so that they're difficult to use incorrectly. That's why we have guards and interlocks on any tool more complicated than a shovel.

Function has 3 arguments. It's documented. Use cases are documented. You are trained. You ask for.. even more protection? From what? There's a limit to laziness, it takes more time to do this word-warrioring on HN than to learn how to use the function correctly and how to create a wrapper around it that serves as the protection you seek.

This really isn't that hard, we're not trying to travel to Mars.

Would you buy a car that explodes every time you start it unless you press the “don’t explode” button? And would you blame the people who get killed by this car for not reading the documentation?

So not knowing how to use a function in programming language is equivalent to a car exploding? Man, your logic is broken in ways that actually hurt.

No, a function that does a wrong and dangerous thing by default unless you tell it otherwise is equivalent to a car exploding.

That's why every serious PHP programmer is using a static code analysis tool nowadays.

It would easily catch this. https://phpstan.org/r/a827ff45-4ee2-4bee-8ae0-935832e627b3

You shouldn't trust him. He is sharing his experience with using the language.

I hate Rollercoasters, I hate surprises and strong emotions. So if you ask me how Disneyworld is, I'll tell you it sucked for me. But maybe you are onto that, so you shouldn't trust me.

Back yo PHP I've used it for super fast tiny dynamic websites, and it works wonders. I wouldn't do an online exchange with it though.