Tom MacWright

Restrictive programming

Often opinionated code is really restrictive code, and that can be a good thing. ‘Restrictive’ has a negative connotation in English, which is unfortunate - ‘constrained’ also works.

I think this is true in languages and frameworks. The gist being:

A few examples:

React allows for both local state modified by imperative calls (setState), and global state (props). Cycle.js and Deku ban local state, requiring all state to be global. You can use React without local state, using tools like Redux, but aren’t required to do it. Removing even the possibility makes certain corner cases much more difficult to handle, but also removes an ambiguity that requires design patterns and can make component use more uncertain.

Rust removes the concept of null, often called a billion dollar mistake by its creator but an idea that spread to nearly every other language.

React also includes forceUpdate(), a function that the documentation advises:

Normally you should try to avoid all uses of forceUpdate() and only read from this.props and this.state in render(). This makes your component “pure” and your application much simpler and more efficient.

But novice developers often use forceUpdate to write code similar to non-Reactive code, where changes in rendering aren’t derived from changes in data. Once this pattern is discovered by their coworkers, they start using something like eslint-plugin-react to ban features from React that can be appropriate in corner cases but are usually wrong.

Haskell, a famous functional language, is purely functional. Most languages are multi-paradigm, like Python or JavaScript: you can use for loops to iterate over data, or you can use recursion. The latter is mathematically beautiful and, in some sense, simpler, but the former is, in many cases, faster and more understandable to a larger set of programmers. Haskell only allows functional code.

August 21, 2016 @tmcw