A point touched upon in my Interfaces and Nil in Go, or, Don’t Lie to Computers that deserves full expansion is, what exactly does it mean for a value to be valid?
It is something that I think many would consider obvious at first, but if you dig into it… and programming generally does make us dig into things like this… it becomes less obvious.
But if you are one who thinks it’s obvious, riddle me this. I have a
string containing the six characters “here's”.
Is it valid?
Sum types are useful, but they are also an attractive nuisance in object oriented languages. There's a certain type of programmer who gets a taste of functional programming and has a good time, but misinterprets that good time to mean that sum types are always better, because they are FP, and FP is Better.
But sum types are not generally better, they are specifically better. Using sum types, or even forcing sum types into languages that don't really have them like C, is a valid solution for certain problems, but in most cases they are not the best choice.
To understand when sum types are best, you must understand something called...
Title is literally true. This may not be the best place to learn about these concepts for the first time, because I'm going to focus on knocking down the misconceptions about them.
Then again, it may not be the worst place, for the same reason.
I had promised myself I would not add to the pile of functor or monad "tutorials", but I've been worn down. I gave up when I saw a reddit comment complaining about how Functor was "too hard to understand", which made me sad, because the correct response to the Functor interface is, "That's it?". And while Monad is legitimately a bit more interesting and complex, the correct response to that is not that different.
I am aware of the notorious effect that people "get" monads and then post their own idiosyncratic takes on them. In my defense, this isn't something I write just after my "ah ha!" moment, I've understood them in Haskell's context for many years now, and actually... this isn't even about that "ah ha!" moment at all. This is only about what they are. Even if you completely understand everything I write in this post, the real "ah ha!" where you realize just how useful the libraries built up around the monad interface are, the first time you search for a type on Hoogle where you're like this should exist and it turns out it does in fact exist already, that's still in your future. In fact I'm quite deliberately not trying to convey that feeling in the interests of getting at simply what the monad interface is. Which isn't, strictly speaking, a pre-requisite to that experience, but it does help.
It is commonly held up as a wart in Go that interfaces have "two different nils"; one is when the interface value is nil:
var something interface{}
fmt.Println(something == nil) // prints true
and one is when the interface contains a nil:
var i *int // initializes to nil
var something interface{} = i
fmt.Println(something == nil) // prints false
This is not a wart in Go. It is a result of a programmer misconception combining with a software engineering bug which results in an attribution error.
After years of overly-acrimonious online discussion, Go is continuing down the chute towards getting generics. I'm already seeing the inevitable "functional" libraries (plural) coming out. I'm going to explain why none of these libraries are going to materially impact what the community considers good style.
They may see some use. I may even use some of them myself on small scales. Some iconoclasts will program with them extensively, and their code will work, in the sense that it will do what it was designed to do regardless of how the code reads. But they are not going to change what generally-good style is considered to be.
Edit: May 2021 - Update for the latest generics syntax.
For the last 20 years I've been programming almost exclusively in languages with either duck typing or structural typing. These are languages where you can have objects that either conform to an informal interface without that conformance being declared (dynamically-typed languages), or where conformance is simply a matter of matching the interface (Go). This is as opposed to languages where conformance must be explicitly declared somehow, either with a formal subclass relationship (the class-based portion of C++) or by explicitly declaring conformance to an interface (Java).
Not needing to formally declare conformance is powerful because you can take some pre-existing object, declare a new interface that it conforms to, and then use it with your interface. This reduces the endless paperwork around re-wrapping things to make existing objects conform to new interfaces.
I have seen a lot of programmers over the years express concerns; what if something accidentally conforms to an interface and causes some horrible bug? What if I have an interface for Shoot() for a video game and some object wanders in that Shoot()s a real gun by accident? Isn't it safer to formally declare conformance?
I've said several times that XML Namespaces are simple, but I don't have a good proof document. So here it is.