> This ontology evolves over time as the software, understanding of the domain, & the domain itself changes.
So what does this have to do with Go or type systems?
> I usually use guard clauses to protect against nulls. I rely on my tests & production monitoring systems to prove that the implementation is incorrect.
And that's a bad thing. There are better tools for this job. What's the downside of encoding nullability into the types?
> That mostly sounds good. I would want invariants to be optional, which sounds like is the case.
Every good type system lets you "opt out".
Therefore, it is a bit silly to look at dynamic typing, where you cannot "opt in", as more flexible.
> This ontology evolves over time as the software, understanding of the domain, & the domain itself changes.
> So what does this have to do with Go or type systems?
I've found that type systems, that aren't utilizing Duck Typing, as being restrictive & causing incidental complexity when evolving the design. I don't really care if something is a categorization of something else. I usually (> 98% of the time) only care if that something adheres to an interface.
I don't like to label people in life either :-)
> I usually use guard clauses to protect against nulls. I rely on my tests & production monitoring systems to prove that the implementation is incorrect.
>And that's a bad thing. There are better tools for this job. What's the downside of encoding nullability into the types?
For the web, it's not that bad. The design is constantly evolving, so most of the development period is spent completing something that is not finished.
There's no downside in encoding nullability, unless extra syntax & incidental complexity is added. It's not a big problem for me so I'd rather not have to do extra work for this feature.
> That mostly sounds good. I would want invariants to be optional, which sounds like is the case.
> Every good type system lets you "opt out".
Explicitly or implicitly? I'd rather be opted out by default and opt in when I want to. Again, I don't want to do extra work or have incidental complexity.
> I usually (> 98% of the time) only care if that something adheres to an interface.
Well, whether something is "nil" or not definitely matters to whether it adheres to the interface, doesn't it?
> There's no downside in encoding nullability, unless extra syntax & incidental complexity is added
You just need sum types and pattern-matching, which are a straight-forward addition to the language -- and very fundamental to computation, so not quite "incidental complexity".
> I'd rather be opted out by default and opt in when I want to
Then why do you use Go and not a fully dynamically typed language? In Go you opt out explicitly with "interface {}".
Why would you rather opt in? Opt out makes sense because types are so cheap 99% of the time.
> I usually (> 98% of the time) only care if that something adheres to an interface.
>Well, whether something is "nil" or not definitely matters to whether it adheres to the interface, doesn't it?
True. Though we are discussing nil/null as being a potential state of data. I actually like & utilize Javascript's notion of falsy (false, "", undefined, null, 0). It's not precise, but most of the time, precision is not needed. Just the general notion that there is a value to operate on or not. Optimizing toward brevity supersedes precision in many cases.
> I'd rather be opted out by default and opt in when I want to
> Then why do you use Go and not a fully dynamically typed language? In Go you opt out explicitly with "interface {}".
I mostly do use dynamic languages. Though, the notion of the Go interface makes the api explicit, yet remains decoupled from the rest of the type system, which seems ok. I've seen proponents use these interfaces to later "discover" types.
> Why would you rather opt in? Opt out makes sense because types are so cheap 99% of the time.
I would rather opt in if I would otherwise have to think about it every time the situation comes up.
Take a collection as an example. Most of the time, I really just want to put a bunch of objects (data) into the collection. I don't want to be a bookkeeper of what type of data is going into the collection. I trust that the data "works" with the rest of the program and will utilize other mechanisms to prove that it doesn't work. I don't want to have to fight compile errors and have to craft a type system just to put an object into a collection.
---
As a general notion, I like to evolve the design from a simple understanding to a more precise & intricate understanding. My ideal programming language would be forgiving of my initial simplistic domain understanding and facilitate the growth of precision as time goes onward.
So what does this have to do with Go or type systems?
> I usually use guard clauses to protect against nulls. I rely on my tests & production monitoring systems to prove that the implementation is incorrect.
And that's a bad thing. There are better tools for this job. What's the downside of encoding nullability into the types?
> That mostly sounds good. I would want invariants to be optional, which sounds like is the case.
Every good type system lets you "opt out".
Therefore, it is a bit silly to look at dynamic typing, where you cannot "opt in", as more flexible.