Have you tried automated testing on a large complex web application? It's an insanely monumental task.

I actually mentioned Haskell in the post because coworkers have lamented not having its type system, which would immediately find problems at compile-time that we otherwise have a very very hard time thoroughly covering with tests.

Hi, Can you elaborate a little more on some use-cases or some examples from your troubles?. Am writing a web application(moderately complex) in python and find myself annoyed by the amount of unit test cases needed. My reaction so far has been to write them whenever i seem to test more than a couple of times. But, have a feeling dynamic typing is actually creating problems by enlarging the number of test cases. Don't know enough haskell to comment on it's type system, but curious to learn. P.S: Feel free to mail me, if you don't want it to be blog post.

There are plenty of cases where a data type doesn't sufficiently capture semantics, and without static typing, Python isn't very well built for checking that values have the right semantic type. A float could mean money or time or a percentage; a string could be plain text or HTML or JavaScript or a filename.

The really really hard part is still checking that a given page "isn't broken"—something that's easy for a human to spot but hard for a computer—for all possible combinations of state. But very strict typing would at least make the output less likely to break.

>Have you tried automated testing on a large complex web application? It's an insanely monumental task.

What's so insanely monumental about writing unit, functional (i.e. like these http://symfony.com/doc/current/book/testing.html#functional-...) and Selenium tests to cover everything before committing new changes? It's just like any other code - test the main condition and edge cases and everything will be running smoothly next time you come back to that feature.

This is quite the oversimplification of the value vs. costs of automated testing while also being completely orthogonal to the discussion. I'd never accept "automated testing" by itself as a strong argument to prefer PHP or anything for that matter.

I merely provided a rebuttal to the argument that PHP, or any other language, for that matter, is unreliable. I did not make the case that automated testing somehow makes PHP a preferred choice. How you test the code is what dictates reliability, not the language.

I'm not sure how you can possibly separate the concept of a rebuttal from that of making an argument. And as I've alluded, how you test code does not, in fact, dictate any form of quality or reliability in and of itself.

I suggest watching this: http://www.youtube.com/watch?v=9G77f9_tOSM

Also reading this https://plus.google.com/u/0/104920553571646483561/posts/fmyZ...