Your browser may have trouble rendering this page. See supported browsers for more information.

|<<>>|91 of 273 Show listMobile Mode

Inventing languages for the sake of it

Published by marco on

The article Fear, trust and JavaScript: When types and functional programming fail presents issues in JavaScript and a solution: use another language. The list several newer ones that are completely untested.

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.

However, suggesting that PureScript or Elm or ClojureScript are somehow better at doing this the JavaScript is incorrect. Where they are better is in providing language mechanisms that allow you to precisely define the shape of the data.

Despite the author’s suggestions, they are not that much different than TypeScript. The only difference being that TypeScript chose to stay much closer to JavaScript for compatibility reasons. At the time that TypeScript came out, this was a reasonable requirement, since almost no-one wanted to move completely away from JavaScript.

Five years later and the development world is ready for other languages. With WASM (Web Assembly) as a target (instead of just JavaScript), there are more possibilities than ever.

JavaScript as a compile target is still open to runtime errors. When you use a higher-level language, you’re restricting the range of functionality that you can use in the target bytecode/machine code. That is, when you write an if-statement in C, you’re using the JMP statement, but you’re only able to JMP to certain address locations instead of anywhere in addressable memory.

It’s the same with JavaScript as a compile target. It doesn’t really matter that JavaScript allows too much—what matters is what the higher-level language allows. TypeScript may still allow too much, but it’s worlds better than JavaScript.

It’s true that PureScript or Elm or ClojureScript can close some loopholes that TypeScript leaves open. That’s fine. But if you’re going to just use JavaScript (or WASM) as a compile target, then why not choose a more-established language like C# or F#?