Hacker News Reader

Comment by vbezhenar | Hacker News Reader

TypeScript is a good example of perfectly "bolted on" type system.

But it is its own thing that compiles down to javascript, and is otherwise syntactically and semantically "very very similar" to javascript. It IS always statically typechecked and has good, or at least well defined, semantics for typing. Typescript does not change base javascript. It really is a well separated layer on top of javascript.

The way python does it is different. There's no "typethon". The python grammar was simply extended to allow any random expression as a "type".

In fact:

    x: print("hi") = 4

is valid python, and it does print "hi" without even so much as a warning. Personally, I don't think "print(hi)" should be a valid type.

This feels like splitting hairs -- python and typescript are equivalent, as they are both dynamically typed languages with type annotations.

The fact that the typescript implementation does not run typescript directly, and cPython does not type check before running the code, are both implementation details.

Typescript is just a better type system on top of javascript than python's type system is on top of untyped python, because typescript is a cohesive design rather than a collection or random stuff accumulated over time.

There's no reason that couldn't have happened for python, it just didn't.

> Personally, I don't think "print(hi)" should be a valid type.

And it isn't:

  a.py:1: error: Invalid type comment or annotation  [valid-type]
  a.py:1: note: Suggestion: use print[...] instead of print(...)
  Found 1 error in 1 file (checked 1 source file)

It is not. As the function `print("hi")` is executed, the argument type in this case becomes `Any`, as it would be for any other executed function.

As stated in the typing documentation [0]: "the only legal parameters for type are classes, Any, type variables, and unions of any of these types".

[0] https://docs.python.org/3/library/typing.html

That's fine and all. But it runs without errors or warnings.

I can put that in main.py and do `python3 main.py` and it will simply run fine.

What is the point of this whole system if it's not enforced?

Amen.

If you want type checking, run mypy.

If you don't want type checking, don't run mypy.

I don't see what's so difficult. If it was technically possible to run programs that have type errors in other languages, they would have the option to ignore type errors too, because it's convenient.

Typescript also ignores errors (generating js output for you to run) by default, so what's the point if it's not enforced?

Typescript does not ignore type errors by default. Type error = fail to compile

Try it, it produces output by default. You have to add a flag/option to change this https://www.typescriptlang.org/tsconfig/#noEmitOnError

Typescript "compilation" is just stripping out types, mostly. JavaScript is a subset of TypeScript (mostly). There was even a proposal to extend JavaScript comments syntax, so all typescript types would become comments (so you could just run typescript code with JS interpreter).

It’s a different language. Different enough to warrant a different name, at the very least.

PHP has been able to add in more typing over the same period of time and has seemed to avoid these Python problems.

I'm pretty sure that php has also explicitly broken backwards compatibility to achieve this. In general php has become far more strict over the years, which I think is a good thing. And they definitely at least sat down and thought about how to do types before adding grammar rules that allowed any random expression as the type, which is now the case in python.

The backwards compatibility has broken some - I think mostly visibly noticeable between 5.6 and 7.0. And every release there's some deprecations introduced that will eventually break in future. Many complex applications in 5.6 won't run 100% error free in 8.2, for sure. I'm working with a company to move from 5.6 to 7.4 and there's very little that doesn't work in the main code. Their earlier version of Doctrine was using a class called 'Null', and internally (unrelated to doctrine) they had a class named 'Null' - those had to be renamed. That took all of about 2 minutes. Upgrading Doctrine version got us to a version that removed the Null class name there too.

Python also broke backwards compatibility with their v3 release years ago. Unsure why breaking backward compatibility is being called out here(?).

But yeah, overall, it's struck me that PHP has introduced more and stricter typing rules with surprisingly little impact (compared to what could have been, of course).

I've had to work on a PHP project recently and it's horrible. Mypy has many pitfalls and it's not great, but at least it's entirely optional, so you can work around the issues or ignore some types until you can fix it or do some refactoring. Typescript might be a different language but it's the best implementation of adding types to a language I've seen so far.

> I've had to work on a PHP project recently and it's horrible. Mypy has many pitfalls and it's not great, but at least it's entirely optional...

Do you mean mypy is optional?

At the risk of opening a can of worms here, what's "horrible"?

In your own PHP code, you can get by without any typing at all. If/when you start to use 3rd party libraries, that may become a factor, though off the top of my head I can't think of a show stopper.

Reply on news.ycombinator.com