One approach is: “This tool has a lot of problems, but we’ll show you how to avoid them.” That can demotivate the learner: “Why am I learning this thing if it has so many problems?”
I don’t know a single tool in information technology that professionals use that doesn’t have downsides. Everyone who claims their most beloved programming language is perfect and doesn’t have flaws (or at least isn’t suited to at least half the problems) either hasn’t used it enough or is in such a deluded state of mind that I wouldn’t trust their judgement anyway.
This is the reality, and if the learner is looking for the perfect solution to all problems… well, good luck, might as well confront them with reality at the start. I’m not saying everyone needs to be a curmudgeon and paint everything black, but let’s stay realistic.
Because not all of it always unfortunate, in a global sense. Maybe unfortunate for the student, but not all languages (or implementations) are equal and often there are indeed good reasons (or at least non-bad ones) for a thing.
What’s the difference between “this tool has a lot of problems, but we’ll show you how to avoid them” and “where problems exist, we describe them flatly and directly”?
I think the main difference is the context in which the problems are addressed. Less “abandon all hope ye who enter here” and more targeted warnings as the sharp edges come close.
I know when I started to learn programming if a tutorial front-loaded all the problems/shortcomings of a language/library, I would have left it to find a tutorial for something that wasn’t “flawed”.
I guess the Typescript one would need to be solved by restricting array types to have no implicit casting and give the programmer enough rope to do explicit casting if they wish to.
That particular soundness bug runs deeper than the array type: Typescript lets generics on property types (even mutable ones!) and function parameters be covariant. This is a pretty big soundness hole, but it apparently is very useful for typing typical JavaScript code. You could fix the soundness issue (ex. with variance annotations), but that would run counter to Typescript’s main goal of being a compile-time layer over top of existing idiomatic JavaScript.
I vehemently disagree with this part:
I don’t know a single tool in information technology that professionals use that doesn’t have downsides. Everyone who claims their most beloved programming language is perfect and doesn’t have flaws (or at least isn’t suited to at least half the problems) either hasn’t used it enough or is in such a deluded state of mind that I wouldn’t trust their judgement anyway.
This is the reality, and if the learner is looking for the perfect solution to all problems… well, good luck, might as well confront them with reality at the start. I’m not saying everyone needs to be a curmudgeon and paint everything black, but let’s stay realistic.
Who are you disagreeing with though? The snippet you’re quoting is not what is being proposed in the end.
Because not all of it always unfortunate, in a global sense. Maybe unfortunate for the student, but not all languages (or implementations) are equal and often there are indeed good reasons (or at least non-bad ones) for a thing.
What’s the difference between “this tool has a lot of problems, but we’ll show you how to avoid them” and “where problems exist, we describe them flatly and directly”?
I think the main difference is the context in which the problems are addressed. Less “abandon all hope ye who enter here” and more targeted warnings as the sharp edges come close.
I know when I started to learn programming if a tutorial front-loaded all the problems/shortcomings of a language/library, I would have left it to find a tutorial for something that wasn’t “flawed”.
I guess the Typescript one would need to be solved by restricting array types to have no implicit casting and give the programmer enough rope to do explicit casting if they wish to.
That particular soundness bug runs deeper than the array type: Typescript lets generics on property types (even mutable ones!) and function parameters be covariant. This is a pretty big soundness hole, but it apparently is very useful for typing typical JavaScript code. You could fix the soundness issue (ex. with variance annotations), but that would run counter to Typescript’s main goal of being a compile-time layer over top of existing idiomatic JavaScript.