I don't understand what the phrase "you either have it or you don't" means.

Not having something can cause significant departures in logic (or make some operations altogether impossible or meaningless). The ability to insist that a value is present is extremely valuable because it dramatically simplifies the specification of a unit and dramatically simplifies its implementation. More importantly, it dramatically simplifies the review and understanding of code, since types are the best source of trustworthy information about your code (Every day I curse the inability for me to ensure fields aren't null in Java, because I have to spend so much time manually determining whether or not they are, and most of the time I still don't end up very sure)

Further, as specifications change, types are a help, not a hindrance. If you change a business requirement which leads to many files needing to be changed because their types are now in conflict with the new business requirement... Then those files are wrong under the new business requirement. They would be wrong in a dynamically typed language too! It's just that in a dynamically typed language, you would never know! And, in the statically typed language, you have accurate refactoring tools which can safely manage large, multi file changes which have to be done manual in a dynamically typed language.

So, I have a round-about answer. I write in F# and in a simplified manner which mostly avoids the type puzzles created by Haskell. Instead the types are used more as validation (Option is very valuable to identify which fields are usable but not required when deserializing from JSON, for example) or to have assistance from tooling (exhaustive pattern match, autocompletion, etc). For writing business code, the clarity that types bring and the questions they force me to ask is very valuable.

However when writing infrastructure code, I sometimes think "this would be easier in Clojure". Because infrastructure code is often more general, so it needs more flexibility. I might not know exactly which settings I can pull from the environment vs a config file vs the command line. And then I may be able to run with modified functionality (or defaults) depending on which config values are present. The kind of typed code you have to write for this is very tedious. One of his statements to the effect of "if you used Maybes, then everything is a Maybe" fits really well in describing this scenario.

Another infrastructure example is the "context" object for APIs. It gives you the particulars about the request you are handling. It can be hard to create a single type that covers all the different resources or special situations you might have in your API.

And in both of these cases, things may get added or removed over time to support new features. And since they are infrastructure, structural type changes are breaking to everyone using it. In fact, many libraries for typed languages include a less-typed data structure for this kind of information. For example ASP.NET has a Configuration feature which keeps the data as a (string) key-value collection. Also in ASP.NET the HttpRequest type (a context object) is capable of storing arbitrary dynamic object values in its internal key-value collection. Both of which are to cover unforeseen cases that you may have in a non-breaking way. The difference here is that Clojure is designed to work with this kind of data. But in .NET it is not encouraged nor as well-supported. It can be a downright pain.

For us, using F# is well worth it since we mainly want to focus on the business use cases. And the types are, on average, a huge help there. But I definitely feel the other side of the trade-off in certain kinds of code.

Wow. Interesting!

I've never used clojure so correct me if I'm wrong, but clojure is a lisp and everything is a list in lisp? (hence the name) - so the "you either have it or you don't" just translates to either a list with one or more elements or an empty list?

Not sure if it helps, but this is how I use/think about types: when you're coding your program you are actually defining a computation graph. Using types (which like you say are only a compile time thing) are simply there to help you get the graph as correct as possible - it's a tool for the dev/compiler. And you can take that to the extreme in a language like Idris

It's unfortunate in some ways that Maybe is linked so closely with null/not null, because you can think of it another way - sometimes when we're building programs we need to do things which can fail or are outside of our control, like reading from a database or calling some http endpoint. How do you represent that in a computation graph? How do you represent it can fail as well as succeed? How do you say "don't do anything until you get this result"? Monads let us represent computations like this (interview tip: if someone asks you what a monad is, just say "it's a way of representing sequential computations") and Maybe has a monad.

For example, in our code we can say "go to the db and get this record. put the result into a Maybe". Now our compiler knows that there's a section of code which will either return Some blah or None and if it's Some blah everything went well, otherwise there was an error (and we threw away the error message)

Anyway, I can see what he's trying to say and if I'm right about the list thing it even makes some sense for clojure... but I don't think I agree overall :/

My take is that he is making the point that in many systems your data is much like documents that don’t have a schema and that is well modelled by nested associated arrays (aka maps) where a not present key is different from a present key with a null value.

I don't think what he is saying is particularly controversial its simply part of a larger point he is making. He is saying that Clojure works well where there is a lot of unstructured, incomplete or varying data. He is asserting that that is a common case where in a typed language you use Maybe<Any> for every document attribute.

His says that in Clojure you pass through what you were not looking for. I am not a Clojure programmer but what I think he is implying is that you can use the presence or absence of keys that are not erased at compile time as a way to pattern match whether a function operates on data. So I read “you have it or you don't” to mean ”run or don't run” without messing around with boilerplate type code that adds no real value in this case. Hopefully someone here can enlighten me.

If thats how Clojure works then I can believe that that is better than trying to deserialise something like a JSON document into a nested Maybe<Any> type to then pattern match and check every maybe is a particular something before doing an action.

So far so uncontroversial. Parsing JSON into types is easy if your JSON was created from structured types. It is very messy when the data structure isn't known. In typed languages we tend to side step that with libraries that reflect upon your types and then do the messy parsing without hand writing all the null checking code. When we want higher performance we use a code generator to create the parser and we don’t mind how ugly the generated code is. We think of it as a small price to pay to extract our typed objects.

What seems far more controversial are the statements that he makes that types are an anti-pattern to maintainability. That is the long running “types v. untyped” where he makes some very clear points. Here on dev.to there are many JavaScript vs TypeScript articles where people have experience of large code bases in both arguing on different sides. It is certainly food for thought...

when you focus on pure data.

what is the different between

{:name "mr. b" :age 12}
{:name "mr. b" :age nil}
{:name "mr. b"}
{:name nil :age nil}
{}
nil

what's the problem maybe could solve?

Looks like he followed up that brief remark with a full hourlong talk about Maybe, in case you want to really get into it.

That makes a lot of sense - from what I've read form him, Clojure seems like it was almost a knee-jerk reaction from a career Java engineer who was losing his mind, and wanted something that addresses his own perceived shortcomings.

I have not yet written enough of anything to lose my mind about it. Context is important.

I'll both like the Java Optional which you can use when at runtime there might not be anything. It has a nice API to work with it. But the Clojure way of returning nil when the argument is nil works also well in most cases, but can sometimes cause weird errors as it's not always fine to pass nil.

ah cool - thanks for clarifying. Then I guess I didn't really get his point!

about Either - yes, exactly - I was kind of deliberately over simplifying to make the point that there's other, sometimes nicer ways to think about Maybe

Right, I'm with you. Call it whatever you like, encode it at whatever level of your stack you like, reality will come knocking one way or another.