Inventing languages for the sake of it
Published by marco on
But the main problem that the article mentions can’t be solved 100% by any language. The main problem is at the boundaries of your application: inputs.
When you get data from an external source, you have to validate it somehow before passing it along to the rest of the application.
No language can remove this requirement. It doesn’t matter how functional, curryable, immutable or sexy it is; it just can’t do it. What you have instead is languages with more built-in mechanisms for defining types that allow the rest of the program to work safely with the data, once it’s been validated.
So if your language supports immutability and types, then you can validate that the data is OK before hydrating the object from the serialized source (e.g. JSON).
What we’re trying to avoid is unexpected runtime errors, no? Or, at the very least, we want a runtime error of a known type that precisely identifies the problem with the incoming data. That is, the data either conforms to the definition—and the definition is statically typed—or there is an error.
The desire is to push this gatekeeper/conversion to a single place so that the rest of the application works with the compiler to find errors rather than tyhe programmer defensively checking throughout the source.