Without having properly read the article, I can add my reason for not using TS: I value the flexibility of an untyped language more than the added safety that a type system offers.
I still maintain that dogmatic type-safety is a crutch to solve structural problems more than anything. I have never once thought "Well, this wouldn't have happened if this had type declarations". Not in PHP, not in Python, not in JavaScript. I've very much thought "Why did this API suddenly change?" and "Where's the goddamn documentation for this?", though.
That's not to say there aren't any benefits to an opinionated, strongly-typed language (as TypeScript would like to be). When the language is built from the ground up with the ingrained opinion that it must prevent developer error at any cost (Golang is an excellent example of this), it does have some charm. Golang in particular goes a lot further than TypeScript, though, and ironically makes you feel a lot less dirty for using interface{} than TypeScript does for any (or Java does for <? extends Object> :P )
The drive to make every language type-safe obscures the real issues of language design. PHP's often confusing APIs randomly swapping argument order, Python's indifference to type inferrence, JavaScript's habit of thinking everything is a float under the hood... These issues aren't solved by making the languages type-safe. And neither does it really solve developer errors.
If anything, TypeScript in particular (due to compiling down to JS) can give you a false sense of security. Type defs are maintained often independently of the actual code mapping to them, and handling external data still runs the risk of runtime errors due to bad assumptions or changes in APIs (browsers maintaining dozens of different engine levels also wreaks some havoc at times).
Yep I totally agree with this. I use Ruby at work, Lua at home and JavaScript both at work and at home; and the types of errors I deal with are almost always related to much more complicated things than a value having the wrong type.
Having worked with languages like C and Pascal before, I'd even say it's the opposite: not having to type your variables is one less thing to keep in your head making a bit more room for the actual logic you're trying to translate into program code, so it helps with reducing bugs caused by dumb oversights.
Just as a small anecdote to underline this: The last bug I found today was that a function to calculate the length of some text was being called before the applications fonts had been fetched, so it used some default font of the browser instead and the result was off by a few pixels. No amount of typing could have fixed this, and in the end the problem was fixed by reasoning about what's happening. Those sorts of high-level problems are the ones I find myself solving most of the time, whereas type mismatches are usually a matter of reading an error message and saying "Oh, of course, this has to be a number"
TypeScript has quite a flexible type system. However to express some more complicated types requires quite a lot of effort and knowledge.
Important things that I think are missing:
Type inference for arguments based on usage
A way to express intent (for example: the function expects a User) combined with actual usage (for example: the function expects something that has a name property). It would be great if any type system would combine this. Note that this is explained better here: youtube.com/watch?v=YR5WdGrpoug
I think you're attributing more features to a type system than it should actually have. When you start adding predicates like "having a name field" you're ending up back at set theory.
Without having properly read the article, I can add my reason for not using TS: I value the flexibility of an untyped language more than the added safety that a type system offers.
I still maintain that dogmatic type-safety is a crutch to solve structural problems more than anything. I have never once thought "Well, this wouldn't have happened if this had type declarations". Not in PHP, not in Python, not in JavaScript. I've very much thought "Why did this API suddenly change?" and "Where's the goddamn documentation for this?", though.
That's not to say there aren't any benefits to an opinionated, strongly-typed language (as TypeScript would like to be). When the language is built from the ground up with the ingrained opinion that it must prevent developer error at any cost (Golang is an excellent example of this), it does have some charm. Golang in particular goes a lot further than TypeScript, though, and ironically makes you feel a lot less dirty for using
interface{}than TypeScript does forany(or Java does for<? extends Object>:P )The drive to make every language type-safe obscures the real issues of language design. PHP's often confusing APIs randomly swapping argument order, Python's indifference to type inferrence, JavaScript's habit of thinking everything is a float under the hood... These issues aren't solved by making the languages type-safe. And neither does it really solve developer errors.
If anything, TypeScript in particular (due to compiling down to JS) can give you a false sense of security. Type defs are maintained often independently of the actual code mapping to them, and handling external data still runs the risk of runtime errors due to bad assumptions or changes in APIs (browsers maintaining dozens of different engine levels also wreaks some havoc at times).
Yep I totally agree with this. I use Ruby at work, Lua at home and JavaScript both at work and at home; and the types of errors I deal with are almost always related to much more complicated things than a value having the wrong type.
Having worked with languages like C and Pascal before, I'd even say it's the opposite: not having to type your variables is one less thing to keep in your head making a bit more room for the actual logic you're trying to translate into program code, so it helps with reducing bugs caused by dumb oversights.
Just as a small anecdote to underline this: The last bug I found today was that a function to calculate the length of some text was being called before the applications fonts had been fetched, so it used some default font of the browser instead and the result was off by a few pixels. No amount of typing could have fixed this, and in the end the problem was fixed by reasoning about what's happening. Those sorts of high-level problems are the ones I find myself solving most of the time, whereas type mismatches are usually a matter of reading an error message and saying "Oh, of course, this has to be a number"
TypeScript has quite a flexible type system. However to express some more complicated types requires quite a lot of effort and knowledge.
Important things that I think are missing:
User) combined with actual usage (for example: the function expects something that has anameproperty). It would be great if any type system would combine this. Note that this is explained better here: youtube.com/watch?v=YR5WdGrpougI think you're attributing more features to a type system than it should actually have. When you start adding predicates like "having a
namefield" you're ending up back at set theory.Might be. I was thinking more along the lines of Nominal typing vs Structural typing and in a sense a mix between the two.