It's more hilarious because his response to that (basically, "this is tax software so there will be a lot of QA when we make that change") is at least sort of legitimate, but only because his accounting software evidently only works due to undefined corner cases in the underlying platform, and that's just ... wow.

I was on the side of the person giving the - I think fairly legit., bug until I came to, "tax software in php" and then I realized there's nothing really black and white in this world.

Did you catch the part about "it makes you lose faith in the product"? ROFL

I caught the part about, "we have unitialized variables being passed everywhere which should be numbers" and that code, well, smells.

I think the PHP team changing the return value of a function without putting anything in a changelog is a Very Bad Idea and a dev. should be pretty upset about that. Saying that the main dev. is doing this work as a charitable thing is fairly misleading as well.

Buuuuut, I also think passing an unitialized value like that is already a bug in this context given the type of software being created. I'd rather see, "NULL" found wherever than know that it was magically changed to 0 (like they would prefer). I know the dev. said that this is just a formatting thing, but I'll wager they're using formatted numbers for some sort of calculation (inadvertently or not).

Whatever is going on, I hope there was a huge code review and a massive QA effort ( which I also doubt happened), because this is a textbook example of tech debt and the loan shark has come a-knockin'.

I agree with this as far as it goes, but I think @zaphar has the better answer: a tax app should never have been written in PHP to begin with.

There's a fundamental quandary in language design: accessibility to novice programmers and suitability for serious work are in opposition. Novices, being novices, are unable to appreciate this problem.

Oh dude: absolutely agreed on that.

One of the hidden costs when you elect to use a language like PHP in the early 00's is that as they fix the glaring issues in their language and stdlib you will be incurring a continuing maintenance cost.

It's a combination of your choice to pick PHP and their choice to fix the languages warts colliding.

It may even have been a reasonable choice for reasons of time to market, hiring, and other business related factors. But the conflict in this thread highlighted that whoever chose PHP in the beginning did not factor in this hidden cost when he made his choice. The results of that lack of information were predictable.

One of my PHP bug submissions is already in high school. The other is in kindergarten. Thankfully both of them won't see light of day in most applications.

But focusing on PHP is rubbish - you can look at any language and find questionable choices. The moment where we need frameworks to make the warts go away - that's worrying. Same thing with JS really

The underlying platform? WOuld that be Python or the tax law?