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

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.

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]

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]

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

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