At about 54:20+, Crockford ends up saying that types cause bugs. What are examples of those kinds of bugs?
I think he's saying that having to bend your thoughts to suit or evade the type system causes the really tricky bugs because your natural train of thought or expectations have been disrupted.
I would have to go away and ponder good examples, but it'll be something around edge cases where a strict type doesn't capture the domain type
I agree. EEs use (or used to use when I learned how to design electronics) a concept more powerful than "types". It was called "design rules". You could specify - on a per project basis (instead of generalizing) - some rules / invariants that had to be upheld. For example "don't let parallel lines on a printed circuit board be longer than XX inches, (since long lines in parallel can cause noticeable cross-talk and this circuit is designed to tolerate only YYmicro-volts of cross-talk)", or, "this project uses ECL chips, ensure that lines on the PC are equal in length (since the speed of light begins to matter and some signals might arrive before others)", etc. It seems to me that "dependent types" are a step in the direction of writing more-flexible programs about types (rather than writing programs about values in memory), which basically admits that most general purpose programming languages aren't really all that general (you get what the language designer thought was important, instead of what your project says is important)
I fail to remember any situation in which I had a bug caused by a type system... The only way I can interpret his statement is that a type system might give you a false sense of safety (I never agreed to the Haskell mantra that if it compiles, then it must be correct, although it can and does happen), so you can then neglect test coverage.
More often than not the adamancy of a type system to accept my code forced me to become aware of intricacies in the domain model. Is it perfect? Nope, nothing is, but it's more helpful for me to use a tool with a type system.
I think Crockford sometimes makes some unwarranted assertions. He used to say that parsing JSON was the only acceptable use of eval in JavaScript, which I never understood, since one should absolutely not use eval on external input.
He seems to be in favor of duck typing, and if the type system prevents you from making a solution that relies on duck typing, he assumes that your alternative solution will be more complicated and have a higher risk of defects, which is an unproven assumption just like all his other opinions. He could equally well have made the opposite claim, that the type system forces you to make a cleaner solution that other programmers can understand without finding surprises, but what opinion he chooses to go with on each question seems to be a roll of dice.
If more of us loose/dynamic typing advocates rock up this could turn into a vim/emacs bunfight!
That's what the JS community loves to do, and Douglas opens with a bunch of slides making strawmen arguments telling that anyone who disagrees with him is stupid and has no facts to come with. In fact, both Vim and Emacs are severely outdated, and I'd rather have the future of editors and programming than influencers provocing flamewars about binary choices of features from the past, as if these features are the ultimate and one of them must be the winner.
Been usin' vi(m) 44 years, man-n-boy, an' I ain't stoppin' now. Pfwah! You young 'uns!
It's not strictly an example of a bug but Crockford wrote a bit about his thinking in How JavaScript Works:
Types are not blamed for the bugs they fail to find, the expensive bugs. And types do not get blamed for the problems they cause by requiring circumvention. Types can induce us to embrace cryptic, intricate, and dubious coding practices.
An example he gives elsewhere of such circumvention:
The Java language encourages misuse of exceptions as a way to get around problems in its type system. A Java method can only return a single type of result, so exceptions are used as an alternate channel to return the ordinary results that the type system does not allow.
The paper Well-Typed Programs Can Go Wrong: A Study of Typing-Related Bugs in JVM Compilers has some concrete bugs caused by types:
In statically-typed programming languages with rich and expressive type systems and modern features, such as type inference or a mix of object-oriented with functional programming features, the process of static typing in compiler front-ends is complicated by a high-density of bugs. Such bugs can lead to the acceptance of incorrect programs (breaking code portability or the type system’s soundness), the rejection of correct (e.g. well-typed) programs, and the reporting of misleading errors and warnings.
😂 Typical Crockford:
The word for 1 is misspelled. I use the corrected spelling wun . The pronunciation of one does not conform to any of the standard or special rules of English pronunciation. And having the word for 1 start with the letter that looks like 0 is a bug.
That actually kinda puts in perspective all the other stuff, honestly.
The Java language encourages misuse of exceptions
That makes sense. I'm getting the feeling Douglas makes a sweeping generalization based on his knowledge of Java, which does not have a helpful type system. It shows ignorance to Typescript, which the question was actually about, and even more ignorance to more advanced type systems, such as that of Rust that prevents bugs by having a good way to handle errors instead of relying on exceptions, and also unlike Typescript prevent mixing up two different things that happen to have the same shape.
I find it contradictory to claim that type systems are not helpful and in the same presentation preach the use of Eslint. Eslint can't do its job well, because it doesn't know the intended type of values, so it mostly does low value remarks that don't help prevent bugs. I consider objects to be one of the bad parts of JS, because Eslint can't detect invalid property accesses, so I don't do objects, and instead pass everything through closure variables that Eslint can check.
That actually kinda puts in perspective all the other stuff
Jes, é pörspektiv ov kaming ap with wan naív ajdía withaut síing the kontext énd thinking hí's rajt abaut it énd evrywan els is wrong. Ingliš has no konsistent speling, énd the wörd wan is nou eksepšön. Wí kud sí the big piktšör énd rífórm the houl lénggwitš, énd thät stil dásn't wörk, becós íngliš hes tú méni démn homofouns.
I find it contradictory to claim that type systems are not helpful and in the same presentation preach the use of Eslint.
Does JSLint (which he recommends at 5:35) incur the same costs of type systems (circumvention, cryptic or complex code patterns) which bother Crockford? To me it seems not, thus no contradiction. He uses the tool to block off parts of the language he considers foot-guns, and to "increase the visual distance between a good program and a bad one". These goals seem distant to those of type systems.
@Dave Liepmann I guess he's bothered by completely different things than other programmers then.
[offtopic: For a split second, @Fredrik, my brain wanted to put that through Google Translate because it looked like Czech or Slovak or Polish, something in that linguistic area 😅]
@Fredrik it's funny that Chat does a good job normalizing your funny message's spelling. (Only added "one is now no exception.") Homophones are one reason why Pinyin was not adopted during twentieth century attempts to simply Chinese characters.
