Application Development Meanderings

null was not the billion dollar mistake There is always much buzz about programming language and features. One claim is that “null” was a billion dollar mistake. I think that’s not actually true. I think the billion dollar mistake was using null in a programming language that has too few tools to manage null as a value. The issue is actually not about “null” but about “worlds.” Let me explain. My perspective is informed from ployglot programming. For example, you can do polyglot programming with the same “value” on Oracle’s graal platform. You can use both dynamically typed and statically languages on the same value since the same values can be accessed from different languages. Once you start switching between languages operating on the same value, you realize that issues for managing “values” is usually influenced by programming language limitations. Some languages are better at others at handling different concerns around values than others. Take a value “a”

There are many state solutions for react including mobx and redux. In scala world, there is diode and a few others. In plain react, you can use hooks and context to help manage state. Hooks and context can take you pretty far, but at some point you want something more sophisticated. In a true reactive application we want a dependency graph that updates itself, potentially asynchronously, as dependencies change. The graph should then influence specific parts of the UI to render. In scala world, you can create a reactive graph pretty easily, however, on the browser side, there have been very few “graphy” solutions until recoil ( blog ) came along. Recoil was just open sourced by facebook. It has on decent API–although not scala friendly. But that’s Ok. If it can help simplify UIs, it could be a good play. Though still in experimental status, reactjs supports Suspense and other “concurrent” features that allow a component to “signal” its dependencies are not yet available. When the s