Tony Hoare, the creator of NULL, now refers to NULL as The Billion Dollar Mistake. Even though NULL Reference Exceptions continue to haunt our co...
For further actions, you may consider blocking this person and/or reporting abuse
Great write-up! The languages whose implementations of
MaybeI've tried don't seem have anything quite as handy as that decorator pattern. I think you've got a MojiScript convert.The decorator pattern is nice for sure. It would be cool JavaScript let you write it like this:
You can do that for methods on a class, but not standalone functions.
Hop over to the Discord chat and say hi!
Do you currently write functional JavaScript? What do you currently use?
I do not - all of the frontend projects I have worked on have been either ReasonML, ClojureScript, or Elm. I'm transitioning to TypeScript now and am on the prowl for best practices - this post was the first I'd ever heard of MojiScript.
MojiScript is new new new. Just created the "initial commit" on Aug 29!
I'm fascinated by ELM but have never used it. What are your thoughts on it?
Whoa - no kidding! Congratulations. I'm definitely excited to play with it.
I wanted to like Elm a lot more than I actually did. The language feels like a pared-down Haskell - PureScript is more interesting to me from a language perspective.
The Elm Architecture resonates with me, and I'm excited by the adaptations I'm seeing pop up for F# and Reason and PureScript.
It's got a bus factor of exactly 1, and 0.19 broke all my stuff. Breaking changes are to be expected with a a young project, but I'm just not quite sold on the ecosystem as a whole.
People do some really cool things with it, but I'm banking on the Architecture to bleed into other more widely used tools as opposed to Elm itself taking over the world.
Your feedback would be very beneficial in helping me drive the direction of MojiScript!
Man, that game boy emulator is insane...
Ahhh ya that was my fear. I love reading about ELM. It seems like everything I want. But then there's the issues with having to deal with JavaScript libraries. Because, let's face it, npm is what makes JavaScript great. Without libraries, I could use any language.
So interop with JavaScript was important to me.
That was a key decision to keeping MojiScript as JavaScript. There's just so much JavaScript already has, package management, build tools, community, browsers, node, etc.
Keeping the JavaScript comes with some limitations but it provides soooo much more that it becomes worth it.
Next up is to create an awesome development and debugging experience. I just merged some (what I think are) revolutionary debugging tools. More on that when I get time ;)
I'm very much a novice, but I'll absolutely be proactive about interacting with the project as I explore the tool. Looking forward to your next post!
Here's a sneak peek:
The
//?is a command from Quokka that evaluates the code live. So to the right of the//?code is a live evaluation of the value on the left.But look at that stack trace...
This is a WIP so it'll only get better... :D
...ok, whoa. That's some seriously cool stuff.
I think so... but you know, I am biased ;)
Thanks for the post!
Very minor pedantic point about .NET Nullable. The current version of
Nullable<T>can only be used with value types. Specifyingstring?will not compile. It basically lets value types (int, float, etc.) be null. Without this, they just map to byte values on the stack, not memory locations, so they can be zero but not null. This would not map very well to database columns such asint null.However, nowadays a lot of devs have seen the value in assuming types are not null unless they are explicitly marked as having null as a valid value. So there is an effort underway to bring nullable reference types to C#. Another .NET language is F#. Since it was based on OCaml, it has had the
Optiontype to represent any kind of object as explicitly "nullable" for a while.Cheers!
That's a lot of great info. It would be nice to have Option as an Option!
When we talk about
null, we should also talk about Kotlin and its null-safety.First of all, all types (
Int,String, ...) are non-null by default. If you want to allownullfor a certain variable, you use the nullable type (Int?,String?, ...).When dealing with nullable variables, one can use the Elvis operator:
namewill be either a String or null ifcustomerorcustomer.nameisnull. It won't throw ifcustomeris null.Non-null by default is the way it should be. I have never used Kotlin, but it sounds like they are doing things right.
I also love the term Elvis Operator!
Interesting article on the various ways to deal with this classic problem.
I've worked with a few people who were big proponents of the functional decorator pattern but I've always found it awkward to read/use. I just find the Nullable/Optional wrapper approach more natural.
Another method that works with Typescript is to add compile time checks by enforcing the explicit null rule. That way for something to be null there needs to be an explicit "| null" added to the type definition if the value could be null. It's a softer enforcement from all these other methods but at least it gets the developer thinking about null.
The decorator pattern is not as clean as it could be. I still use it but sparingly. Type checking is also a great option when available.
I get it that using Maybe prevents a null reference from crashing the program, but now you get a Nothing that's also unexpected. Is the philosophy then that you need to guard for Nothing or that it is just considered a lesser bug that needs to be fixed but at least doesn't kill the app. Or?
It changes from null being expected to. A Maybe being expected. So Nothing is a valid input.
When you use
map, it will work on both aJustand aNothing.So you can stop guards completely!
This is a good example of what I am talking about:
You don't have to worry about if the value is a
Justor aNothing. You just accept aMaybe.You article is great. I stole^H^H^H^H was inspired by some of your ideas to write this article
codeburst.io/null-the-billion-doll...