Hacker News Reader

Comment by rob74 | Hacker News Reader

I don't agree with your comment in general, but I think I understand where you're coming from. Many formerly loosely typed languages (JS, PHP, Python etc.) have tried to introduce stronger typing - I have the most experience with PHP, so I'll talk about that: sometimes "stronger" typing can be a pain, especially if you try to introduce it to an existing weakly typed project, or if you're interfacing with some other weakly typed system (e.g. JSON files). One example: everything is working fine, then you declare a function parameter as `string`, and suddenly you get runtime errors because one of the many callers occasionally passes `null`, and you forgot the question mark before the `string`.

View on HN

So what you’re saying is that by introducing type checks, you’re actually uncovering bugs. Seems to me like proof of value right there.

What does surprise me is that adding types to your PHP code adds _runtime_ errors. With Python, type annotations are predominantly used by static typecheckers and are ignored at runtime (except from some libraries like FastAPI that use reflection to inspect the type annotations). I always assumed all dynamically typed languages that introduced explicit types worked the same way

> What does surprise me is that adding types to your PHP code adds _runtime_ errors

There are static analysers for PHP too, but yeah they’re also enforced at runtime.

I think I prefer that, if there’s going to be a non-zero risk of bad types landing in production code, I’d prefer that be an error than for it to just carry on and potentially fail later in strange ways.

That said, one of the reasons cited for PHP not having generics is the performance cost of runtime enforcement. So there are a few people out there now making the case for a generic syntax that is ignored at runtime, but that can be built into static tooling. Which I can get behind—PHPs type system is really not bad at this point, but generics would be really nice.

I would also prefer type checks to be done at runtime as well. The reason Python doesn’t do that is likely indeed the cost to performance

Well no, maybe there was a legitimate reason to pass null instead of a string (I mean, nullable types exist for a reason), and then you just introduced a bug because you didn't look hard enough at all the places your function is called (which can take some time).

If you have a null-aware type system, then you just can’t call your function with a null, so no bug?

Also, if you just annotated the same implementation that already didn’t handle nulls properly, how is it any different? Your code would just die at runtime a few lines later, with a less explicit errorz

Reply on news.ycombinator.com