What the hell is type-safe language?
Visakh Vijayan
Nov 14 '18
Updated on Nov 16, 2018
γ»1 min read
Consider you are a compiler. Now suppose you are a person who doesn't care about your fellow programmers who are writing code and using you to get them compiled. Like for example:
Someone is assigning an integer(4 bytes) into a char(1 byte) variable.
If you are not careful, that assignment will take away the adjacent 3 bytes away. Poof!.
This is type-unsafe. That is the compiler or YOU are not taking care of such validations before compiling them.
Again this can be at two levels:
- Static typing - one which is done at compilation time.
- Dynamic typing - one which is done at run-time. This is when you get all those run-time exceptions.
Be type-Safe!
56
16
More from @vjnvisakh
Syntax vs Semantics
#programming
Trending on 
Clean up your code with these tips!
What's your goto motivational quote?
Uncaught RangeError: Maximum Call Stack In JavaScript
It's Important To Test Your Code
If/else or just if?
Tools for writing better code
Unraveling Classes, Instances and Metaclasses in Ruby
How do you refer to the reader?
Auth With Twitter
Auth With GitHub
What does dynamic typing have to do with "Divide by zero"? Zero is a value, not a type. Statically typed languages won't prevent division by zero.
True ... that was a mistake. Thank you for pointing it out.
True, unless you have refinement typing!
Why should I care about making a compiler happy in the first place? Static typing requires a huge boilerplate. No, thanks.
Well, you could have the compiler verify the types for you or write unit tests instead..
How else do you make sure the function expecting a User doesn't get a Monkey instead?
This is the biggest deception raised in the last ten years and I have no idea where is comes from. Strong static typing does not obsolete unit tests.
Please note, I even added strong to your original static which gives you even more freedom to argue.
A dozillion time strong and static as hell type would not help to catch
"foo"instead of"bar". 99% of bugs exist not because somebody sent a monkey to the represent the user. Developers are not that stupid.While pattern matching would. And restriction to create own types would. And even despite that we in erlang/elixir do indeed write unit tests. Because the vast majority of things that require an explicit check are like βthe currency rate cannot be less than one if the currency pair is normalized.β Welcome to protect this with your vaunted types.
I never said you would write 0 unit tests. You would write no tests for types.
Kotlin has nullability built into the language, so I don't have to write a test what happens when the variable I am passing is null.
I also don't have to do defensive programming and check if the variable is null.
I never check the variable I pass is null, mostly because I am sober enough to not pass nulls where they donβt belong. In CS variables do not become null all of a sudden.