Introduction

I have to give credit to my like-minded colleagues, who have been the spur and stimulus for various posts during the brief shindig we have over tea breaks. Working from home has doused that constant kindle, which has been the breeding ground for a gamut of blogging ideas. But, in spite of that, here we are with a new post. This post deep dives into typing in programming languages, a much underappreciated, overlooked, and underrated area. Also, the need for type soundness/safety. This post is more theoretical, parched, and conceptual content.

What is Type System in language?

We solve problems through programming languages. Every problem has terms or parameters or dimensions or inputs or variables that describe the problem domain we work against. These sets of variables are defined or constrained by data types or type systems. Data types can be a number or string or vector of floats or functions etc. The original notion of the type system is to give a clear definition of variables, avoid runtime errors while data computation or manipulation, and allowed operations that can be performed on the variable points.

Type Safety

Each language is intended for a certain exclusive problem domain. We cannot use JavaScript for high-end precise computation that guides a missile. We will shortly see why? Type safety is all about the extent to which a certain programming language discourages or encourages and allows or disallows runtime errors.

Need for Type Soundness

MarsOrbiter– NASA lost 125 million (MARS Orbiter Satellite) due to metric error mismatch/confusion. Read more about this here CNN. An incorrect metric/English conversion was the “root cause” for the crash of the Mars Climate Orbiter. [1] [2] [3].

Here is a cooked-up close to the real-world Mars Orbiter problem, purely for understanding purpose-Just imagine a function taking input as English metric system as:

Let’s assume that we pass in record distance_In_Centimeter of type DistanceInCentimeters as a parameter into the function: adjustTrajectoryOfSatelliteByFeedbackError. Ideally, in nominative languages like C#/JAVA, it’s going to disallow, since, they are semantically unequal. But in duck or structural type languages like JavaScript, both record:DistanceInCentimeters and record:DistanceInInches are both structurally equivalent but, semantically different. The purported reasoning behind the mars orbital fiasco was, the function: adjustTrajectoryOfSatelliteByFeedbackError- which adjusts the trajectory of MARS orbital satellite based on inches (in reality) and we erroneously happen to pass into the given function, a record of distance object that is measured in centimeters and that threw the satellite astray.

 excerpt from the WIKI: post-failure calculations showed that the spacecraft’s trajectory would have taken it within 57 km (35 miles) of the surface. At this altitude, the spacecraft would likely have skipped violently off the denser-than-expected atmosphere, and it was either destroyed in the atmosphere, or re-entered heliocentric space. [2]

Conclusion

This doesn’t mean dynamically typed JavaScript is by any means inferior to nominative statically typed languages like C#/JAVA, which by the way is going to spew out compile-time type errors for the above code. JavaScript and all its kith and kin have deferred type checking (during runtime) and are tolerant of errors. The purpose behind that is, it gives low development cost and flexibility in coding and hence is suited for web-related development. Contrary to the popular belief, recently dynamically typed javascript is gaining a reputation in critical real-time problems too (like Node.JS solving IoT).  One has to realize that you cannot purely judge a fish by its expert tree-climbing abilities, similarly, each language has a different purpose for solving problems from exclusive domains.