You don't need TypeScript
It means that the language has very strict typing rules,
meaning you will not have issues like buffer overflows, like in low leven programming languages such as C and C++
Dynamic typing also makes it harder to statically analyze the program before it is run, for example auto-completion in an editor/IDE.
Some TypeScript advocates will call this a "poor mans type checker". But TypeScript will however not help you here, you still have to explicitly check for NaN.
A sound type System can help you, but TypeScript is not
To make the function type safe, your would probably write it in TypeScript like this:
Only problem is that when the code above is executed, the head function will happily return a value that is not of type number!
When given an empty array, it will return undefined!
Instead of the TypeScript type system helping you find the error, you have to discover it yourself, and then manually add additional type annotations to help the type checker. It might look something like this:
How to find errors
In order to find errors in the code, you can study it hard, or manually test all possible states.
Some TypeScript advocates say you do not need to test your code if you write it in TypeScript...
Development usually goes something like this:
- You write code
- You manually test the code
- You upload the code to the production environment.
- Users start using the program, and finds errors.
- You fix the errors and upload the new code.
- Repeat step 4-5
The more users you have the more issues they will find,
and hopefully they get fixed. Developers call this "battle hardening".
A sixth step can however be added to make it more efficient: When you fix the error, you also write code that automatically checks for that error. That way you can be sure that the same bug do not come back to hunt you.
When making changes to a program, there is a chance you will introduce new problems.
This is why making changes can be very scary, especially if you are new to the code-base, or if the code is hard to understand.
Errors often occurs because of edge cases you did not think about earlier when designing the code, and fixing it might require some ugly "hacks". When these fixes accumulate, the code will probably get harder and harder to understand.
So when you update the code, also write code that automatically checks if your code still works!
That way, the next time you update the code, you do not have to worry about breaking earlier fixes.
"battle hardening" is very effecient! If you release the code to 1000 users
they will discover more bugs in one week -then you would discover in 10 years!
But you should not trust your users to report issues to you, only one in one thousands users will report errors, so when you get a bug report, is usually mean you have a "hidden iceberg" of users that have been hit by the bug and either worked around it or gave up. Instead you should make it so errors are detectable, and automatically reported.
Written by Johan Zetterberg December 4th, 2019.