Maybe Not - Rich Hickey

While we're talking about this conference, rich hickey just changed how I think about domain modelling forever with this talk, released about an hour ago: [VIDEO] Strongly recommend a watch particularly if you're modelling something in a typed language

Conj always makes me so envious. So many good talks. This one, the Rich Hickey one on Maybe, the Stuart Halloway one on REBL. Any other must watches? Hickey: [VIDEO] Halloway: [LINK]

Yet `Maybe<T> | Option<T> | ...` is not an option (pun intended), as Rich Hickey explains here: [VIDEO] . In effect, his argument is: 1) You have `public X Do(Y y)` changed into `public X Do(Option<Y> y)`. This will break your API. 2) You have `public X Do(Y y)` changed into `Option<X> Do(Y y)`. This will break your API. Thus, do not use Option<T> or equivalent in your API's. Only use a language-supported construct such as C#8's upcoming `string?` and `string`.

Since it's so close to this topic, I recommend Rich Hickey's talk from about a week ago, called "Maybe Not". It's mostly about the issue of how to specify the shape of data a function requires (takes as input) and provides (emits as output), but it also contains a really nice discussion of problems with Option/Maybe types. Anyway, my feeling is that I don't understand what people expect to happen here. Due to a misunderstanding, bad assumption, or other error, you expected to have something when you actually don't have the thing. A null-reference exception (or equivalent) is just the symptom. Null isn't the problem, our dumb brains that constantly make dumb mistakes are the problem. Option/Maybe does force you to deal with the case that you didn't get anything when you asked for something. But as Hickey points out in his talk, it isn't all benefit, there is a cost, and nobody ever talks about the cost. When I provide you an id and ask for a Book object in return, I want a Book back, not a `Maybe Book`. This concept does not map to anything in the real world, and it has problems in practical usage as well. (e.g. My function changes from maybe giving you a Book or maybe not, to definitely providing you a Book. So I change its return type from `Maybe Book` to `Book`. Except, oops, I just broke every single caller of my function, even though I strengthened the guarantee of the data my function will provide. That shouldn't break anyone.) [VIDEO] (Discussion of Option/Maybe starts

Rich Hickey's "Maybe Not" should be watched by anyone who thinks nulls/nils/undefineds are okay. It should also be watched by anyone who think that Optional/Maybe/Nullable and good enough: [VIDEO]

"Maybe Not" by Rich Hickey: [VIDEO] Another excellent talk by the creator of Clojure, and like the previous ones, relevant for all programmers.

I bounce back and forth between TypeScript and Clojure. I've been keeping a close eye on Clojure's upcoming spec as it seems to be a nice opt-in, run-time type-checking solution. I like the flexibility and quickness with which dynamic languages let me iterate, but I want the safety. I want at least some of the benefits of both. So yes, they (dynamically typed languages) have some advantages. Sometimes when I'm iterating quickly, especially on new projects, I don't want to fight with the compiler. BUT, I vastly prefer TypeScript to JavaScript because JS has a lot of foot-guns. I think when we get the existential operator, it will have less foot-guns, but I will probably never again write a new project for work in JS from scratch. I really love the ideas Rich Hickey put forth in his most recent Clojure conj talk: [VIDEO] The ability to spec out the shape of an object, and then in the different contexts in which you need some of that data, specify what you need, is an awesome solution to optionality (Watch the talk!). I absolutely love how much thought RH has put into the design of Clojure, and I think the final release of spec will be a close to perfect balance of dynamism and opt-in safety. Of course, TS is a superset of JS, so adopting it little by little sorta gets me that balance I want.

I would say Clojure more than substantial returns of invested time. Not just the language itself, but also the wider approach to software composition, feature accretion vs backward compatibility, schema'd dynamic typing seem benefictial no matter what your development tools you use. Maybe check out the talks below and see if they don't enRich you as software engineer. [LINK] The Language of the System [LINK] Design, Composition, and Performance [LINK] Spec-ulation [VIDEO] Maybe Not

Because you mentioned Result specifically: I've recently seen a talk by Rich Hickey that (for me) made a pretty strong case against Result/Maybe/etc. and for union types instead. Maybe you'll find it interesting: [VIDEO]

Please please please don't perpetuate the use of either or maybe types :( They make software very hard to maintain and end up breaking anyone who depends on a library that uses them. Rich Hickey (author of Clojure) has a great discussion of Either and Maybe here: [VIDEO] that dives into their unsoundness.

Fair enough, I thought it was snark so I responded with snark. I think you should try both. Lisp as a language gives you a lot more freedom than Clojure, but Clojure has a more consistent and elegant language design. Clojure focuses on mostly-pure functional programming with immutable data structures, while Lisp lets you do pretty much anything anywhere, including hacking deep into the runtime itself (Clojure lets you do this to some extent too, but not as much as Lisp). Some videos that are worth viewing, which together I think provide a good sense of how the languages differ: - "Common Lisp for the Curious Clojurian" by Alan Diepert. A very lucid side-by-side comparison of Clojure and Common Lisp; assumes some but doesn't really require much knowledge of Clojure. [LINK] - "Maybe Not" by Rich Hickey. An unusual but thoughtful take on "types" in programming, which I think cuts to the heart of what Clojure is all about. [VIDEO] - "Immutable Conversations - Common Lisp" interview with Alejandro Serrano and Michał "phoe" Herda. Demonstrates the deep programmability and flexibility of the Common Lisp runtime, including its unique "condition system". [LINK]

[VIDEO] Static typing is not "obviously good" The comparison is flawed. There are no advantages to driving without a seatbelt, but there are pros and cons to dynamic typing.

You are wrong. [VIDEO] Static typing only leads to devs trying to press the real world in stupid arbitrary categories.

> Putting “here’s the fields I’m borrowing in the body” into the signature, in order to conform with the Golden Rule, looks very odd. I think this would be an amazing feature, but it would require something like typescripts partial types, where essentially every object/struct consists as a collection type of atomic fieldname:field-type types.[1] Rich hickey[2] has a great talk on how existing type systems break in scenarios where they shouldn't break, e.g. relaxing what you accept as arguments should be a forward compatible change, and similarly increasing the guarantees that you provide on returned values should also be forward compatible. Currently they are not, but partial types are one piece to that puzzle imho. 1: [LINK] 2: [VIDEO]

Rich Hickey (creator of the Clojure language) has a good talk "Maybe Not" that touches on these issues, with a nice way of explaining it [VIDEO] The capnproto link explains it concretely in terms of a message bus example, which is useful. But more abstractly you can think of the shape of data (aka schema, names and types) and field presence (optional/required) as separate things [LINK] First, being valid or invalid with respect to a static type system is a GLOBAL property of program -- writing a type checker will convince you of that. And big distributed systems don't have such global properties: [LINK] If they did, they'd be small :) Namely you could just reboot the whole thing at once. You can't reboot say the entire Internet at once, and this also holds for smaller systems, like the ones at say Google (and I'm sure Cloudflare, etc.). So the idea is that the shape/schema is a GLOBAL property -- you never want two messages called foo.RequestX or two fields called "num_bar" with different types, ever. But optional/required is LOCAL property. It depends on what version of a schema is deployed in a particular binary. Inherently, you need to be able to handle a mix of inconsistent versions running simultaneously. --- To be pedantic, I woulds say "making illegal states unrepresentable" DOES apply, but you can't do it in a STATIC type system. Your Maybe<T> type is not useful for data that crosses process boundaries. A distributed system isn't a state machine. 1. Lamport showed us

Maybe Not is an excellent video in some ways, but I just watched it a few years later and it reminded me that as much as I love almost every Rich video, I do wish he'd spend some time reading a little deeper on type systems and theory. For example his note about "Categorical descriptions" and then the explanation about maps/and spec at 25:00[1] seems to indicate he's unfamiliar with the difference between extensional and intensional type theory. The core difference between the two is extensional type systems decide equality on the observable behavior of the output. For example if two functions take the same input, and produce the same output extensional type systems/theories say they are the same. The problem with this is type equality is then undecidable. Extensional type systems also struggle because there are more than one way things might be equal! For example two string might be equal if you ignore case, but unequal if you don't. So if we want our type system to check if two functions are equal under case insensitivity an extensional type system will struggle with this.[2][3] Now in fairness to Rich, these concepts come more from the math community, especially the notion of types being equal under different paths, and in the case of Homotopy type theory are burred in unapproachable language and concepts... even by mathematicians standards. He also talks about select from spec, and it not preventing you from passing types broader types, and the necessity of specifying dee

Consider reading/watching Rich Hickey's talk Effective Programs [0][1] and Maybe Not [2][3] In [0] in particular there're slides 22/23, here is part of the transcript but makes more sense with the slides on: > And you can call them problems, and I'm going to call them the problems of programming. And I've ordered them here [...] I've ordered them here in terms of severity. And severity manifests itself in a couple of ways. Most important, cost. What's the cost of getting this wrong? At the very top you have the domain complexity, about which you could do nothing. This is just the world. It's as complex as it is. > > But the very next level is the where we start programming, right? We look at the world and say, "I've got an idea about how this is and how it's supposed to be and how, you know, my program can be effective about addressing it". And the problem is, if you don't have a good idea about how the world is, or you can't map that well to a solution, everything downstream from that is going to fail. There's no surviving this misconception problem. And the cost of dealing with misconceptions is incredibly high. > >So this is 10x, a full order of magnitude reduction in (?) severity before we get to the set of problems I think are more in the domain of what programming languages can help with, right? And because you can read these they'll all going to come up in a second as I go through each one on some slide so I'm not going to read them all out right now. But importantly t

My mind blown experience was listening to a Rich Hickey talk (maybe not [1]) that flipped upside down my accepted method of thinking about types and type system paradigms. I still love writing Haskell and Rust, but I see the warts that he is so concisely pointing out. The either type really sticks out to me now, and I see the problems with overtyping what are essentially maps, and how rigid that makes every aspect of your programs. Currently I deal with a fairly large go monolith that had some clean code practices in it, and changing a single field that is going to make it into the public API ends up being hundreds or thousands of lines of changes. Such a waste of time to CRUD what is a map of strings. 1. [VIDEO]

Rich’s point is the type signature actually tells you little about what the function does. You need the name, docs, tribal knowledge, your own understanding of the math… etc. to actually understand what it does. Type signature alone is a very incomplete understanding. But come on, do you think I learned how to write Haskell and don’t understand what a type signature’s value is? Give me a little credit. Here is Rich’s work on the subject: [VIDEO] I’m biased, but I think he’s got a point.

What’s your take on Hickey’s talk titled “Maybe Not” which fundamentally criticizes static types? Is there a middle ground where some form of static typing makes sense in a Clojure-esque world? [VIDEO]