Let's stick to correct usage. Untyped means there are no types or what is the same, there is only one type. For example, assembly is untyped language it has only one type - bit strings, Lambda calculus is untyped language it has only lambdas.
It's impossible to do completely strict types in TypeScript / JavaScript, and there's always going to be that one case that cannot be fixed with this
In general it should be possible. The other question if you want or not. Don't mix up two argument.
typed language such as C++, C#, Java, etc.
You realise that all those languages are not type safe?
It means it is totally possible to write program in all of those language which will crash at runtime because of type error.
Don't confuse static types with type system soundness.
Plus, importing a function makeSureItIsAString seems like overkill just to make TypeScript support complete.
You don't need them everywhere you need them only to validate io e.g. user input, server response etc. There are libraries like, io-ts which helps to simplify this process.
In general it should be possible. The other question if you want or not. Don't mix up two argument.
I wouldn't say "in general", I would say "in theory" - however, in practice it is commonly the case that you don't write 100% of the code you use; and as such, you cannot confirm the validity and "typeability" of the code you are given.
You realise that all those languages are not type safe?
That was not my point, and I overstepped when I said "true type safety". Obviously TypeScript does not provide sound type safety and neither do the languages I've listed; however, they do have much stronger, native checks for static typing that are built into the languages, as opposed to TypeScript which still transpiles down before then being interpreted - quite a few layers there where errors can occur.
You don't need them everywhere you need them only to validate io e.g. user input, server response etc. There are libraries like, io-ts which helps to simplify this process.
Could you give an example of when you would need to validate and when you wouldn't? Seems weird to have to validate whether user input is a string, for example.
Could you give an example of when you would need to validate and when you wouldn't?
If you expect string and you read from the html input you will get string. But if you, for example, read state from URL and decode it and expect some arguments to be numbers, things can go wrong here. Or if you, for example, use JSON.decode to get response from the server, you need to make sure that response is in correct format.
I would validate all user input, I meant to say, that reading IO is typically not that big compared to other logic of application.
however, they do have much stronger, native checks for static typing that are built into the languages, as opposed to TypeScript
Why do you think so? Typescript is quite advanced type system it is based on latest research (and written by the same people who wrote C#, Anders Hejlsberg for example). So this claim needs a bit more evidence.
The fact that it compiled to JavaScript doesn't make it unsafer. All checks happen before compilation. The same for native programs, check happens before compilation, one of the compilation steps is type erasure (unless you use something like Reflections or io validation or pattern matching on boxed values). After type erasure you deal with untyped assembly code. Do you think assembly is more safe than JS? (rhetorical question)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
JSX is typed as well - it's just
React.createElement()
and you can attach dynamic type checking with PropTypes. Or in typescriptOr you can use them both like described here.
Let's stick to correct usage. Untyped means there are no types or what is the same, there is only one type. For example, assembly is untyped language it has only one type - bit strings, Lambda calculus is untyped language it has only lambdas.
In general it should be possible. The other question if you want or not. Don't mix up two argument.
You realise that all those languages are not type safe?
Java unsound, C unsound
C# unsound
It means it is totally possible to write program in all of those language which will crash at runtime because of type error.
Don't confuse static types with type system soundness.
You don't need them everywhere you need them only to validate io e.g. user input, server response etc. There are libraries like, io-ts which helps to simplify this process.
I wouldn't say "in general", I would say "in theory" - however, in practice it is commonly the case that you don't write 100% of the code you use; and as such, you cannot confirm the validity and "typeability" of the code you are given.
That was not my point, and I overstepped when I said "true type safety". Obviously TypeScript does not provide sound type safety and neither do the languages I've listed; however, they do have much stronger, native checks for static typing that are built into the languages, as opposed to TypeScript which still transpiles down before then being interpreted - quite a few layers there where errors can occur.
Could you give an example of when you would need to validate and when you wouldn't? Seems weird to have to validate whether user input is a string, for example.
If you expect string and you read from the html input you will get string. But if you, for example, read state from URL and decode it and expect some arguments to be numbers, things can go wrong here. Or if you, for example, use
JSON.decode
to get response from the server, you need to make sure that response is in correct format.I would validate all user input, I meant to say, that reading IO is typically not that big compared to other logic of application.
Why do you think so? Typescript is quite advanced type system it is based on latest research (and written by the same people who wrote C#, Anders Hejlsberg for example). So this claim needs a bit more evidence.
The fact that it compiled to JavaScript doesn't make it unsafer. All checks happen before compilation. The same for native programs, check happens before compilation, one of the compilation steps is type erasure (unless you use something like Reflections or io validation or pattern matching on boxed values). After type erasure you deal with untyped assembly code. Do you think assembly is more safe than JS? (rhetorical question)