3 ms·
I posted a very closely related article about this last year (http://mattdavey.logdown.com/posts/259807-avoiding-the-billion-dollar-mistake http://mattdavey.log
by SuddsMcDuff 10y ago
I posted a very closely related article about this last year (http://mattdavey.logdown.com/posts/259807-avoiding-the-billion-dollar-mistake http://mattdavey.logdown.com/posts/259807-avoiding-the-billi...) - it's C# focused but the idea should carry over to similar languages. It summarizes 5 strategies for dealing with nulls, rather than just jumping straight into monads.
- deleted 10y ago[deleted]
- ppcsf 10y agoI think the section dealing with the Optional monad sort of glosses over their composability, which is one of the primary reasons we use monads. Multiple functions that all return an optional can be composed; for instance, if we had Optional<WidgetFriend> GetWidgetFriend(Widget widget) and WidgetFriend had an Optional<FriendName> property, we could simply write [1] from widget in _widgetRepository.FindById(widgetId) from friend in _widgetRepository.GetWidgetFriend(widget) from name in friend.Name select name; and get an Optional<FriendName>, without having to repeat all the tedious pattern matching of Some or None for every call. If any of those calls returns a None, the entire evaluation short-circuits and we get a None result at the end. Of course, we can still write Optional<Widget> widget = null; which is the problem with not fixing this issue on a language level. [1] You'd have to implement Select and SelectMany, instead of Map and Bind, to get query syntax like this.
- achr2 10y agoI think you'd like C#'s linq syntax and null coalesce operator. While obviously they don't get away from null, they go a long way to making this type of syntax and null safety much easier to implement.
- deleted 10y ago[deleted]