HN Theater @HNTheaterMonth

Also a great talk from Richard Feldman about "Making Impossible States Impossible": https://www.youtube.com/watch?v=IcgmSRJHu_8

"Making Impossible States Impossible" by Richard Feldman (2016): https://www.youtube.com/watch?v=IcgmSRJHu_8

"Understanding style" by Matthew Griffith (2017): https://www.youtube.com/watch?v=NYb2GDWMIm0

A related mantra is to "Make impossible states impossible" https://www.youtube.com/watch?v=IcgmSRJHu_8

⬐ nathcd

I think the original formulation is "make illegal states unrepresentable" from Yaron Minsky: https://blog.janestreet.com/effective-ml/ and https://blog.janestreet.com/effective-ml-revisited/ (or maybe there are older sources than 2010?)

I've seen this way of state modelling pop up more and more recent year in me feeds. Make impossible states impossible. It's a great way to keep you sane!

https://www.youtube.com/watch?v=IcgmSRJHu_8 (Elm)

https://www.youtube.com/watch?v=uGMm3StjqLI (Kotlin)

There's a great talk from Richard Feldman that talks about this in the context of Elm. https://www.youtube.com/watch?v=IcgmSRJHu_8

A great talk on this subject is "Making Impossible States Impossible" by Richard Feldman from Elm Conf 2016

https://www.youtube.com/watch?v=IcgmSRJHu_8

Related video on this subject: https://www.youtube.com/watch?v=IcgmSRJHu_8

⬐ matsemann

I thought about that video today when integrating with an old SOAP API. I need to find the name+some property of some persons. Instead of having a list with [(name1, prop1), (name2, prop2),...], I get two distinct lists of [name1, name2,..] and [prop1, prop2,..]. In practice I think the lists will always match. But there is nothing stopping them from not being the same length, or even worse: one having a gap..

⬐ vbezhenar

Put an assertion. It's better to throw early rather than dealing with wrong data later.

* Learn to think about types first, and the algorithms as a natural consequence of the structure of your data. Richard Feldman: https://www.youtube.com/watch?v=IcgmSRJHu_8,

* Use a statically typed language that allows fast refactoring. Ideally a typed functional language like Elm, Reason, OCaml, or Haskell.

I recently shipped a complex Javascript project (without types) and it is one of the few instances of my decade-old professional career where I had that level of confidence in the robustness of a piece of code I wrote. It remained sturdy in production even in the presence of unforeseen conditions. This was thanks to the habits I picked up from typed FP: parsing and validating all data at the boundaries of the system, better design by modelling data to make inconsistent states impossible, and automatically handling all edge-cases at all times.

So even if you don't actively use such a language in your workplace, there really is a payoff to learning it in making you a better programmer overall.

⬐ smush

I agree with you 100% and will amplify your comment with one of my own.

I suspect this won't be immediately possible as I'm not certain what languages OP is allowed to use, but if OP has some wiggle room in what PL to use, then I would recommend that he look at the Domain Modelling Made Functional book by Scott W.

Like you say, the principles in the book apply to other languages as well, but it can be a faster feedback cycle to learn these lessons in a language that has first-class support for them. He will be able to use F# or its close syntax cousins OCaml, ML to model new features as domains and employ option types, pattern matching, railway-oriented-programming, and functions as interfaces to make his code more resilient, like you mention.

The bonus is that if OP uses the likes of F# or Scala, it can interop with C# or Java respectively within the same codebase.

⬐ julvo

Came here to say something similar: Learn a functional language.

Not because you'll be using functional languages afterwards for work, but it changes your coding style - even in imperative languages. More towards pure functions and a cleaner separation between data and logic

I just watched a good Elm conference talk about this same concept called "Making Impossible States Impossible" - https://www.youtube.com/watch?v=IcgmSRJHu_8

That'll be a great addition to the book.

Can I also recommend Yaron Minsky's talk on OCaml, specifically the part where he talks about "making invalid states impossible": https://youtu.be/-J8YyfrSwTk?t=1079

I've found this to be the single most valuable programming technique I've learnt.

Richard Feldman dives deeper into the topic with a lot more examples in https://youtu.be/IcgmSRJHu_8?t=73

Making impossible states impossible" by Richard Feldman: https://www.youtube.com/watch?v=IcgmSRJHu_8 has really changed the way I approach dealing with data in my code and was very insightful.

The type system is a lot more expressive than the ones found in Java/C#/C++, thanks to Algebraic Data Types.

Yaron Minsky (Jane Street, largest OCaml user) coined the term "make invalid states unrepresentable" to explain how ADTs help in enlisting the help of the compiler to help us express our intent correctly, and Richard Feldman (NoRedInk, largest Elm user) has given an absolute gem of a talk that dives into that idea with relatable, concrete examples.

It is titled "Making Impossible States Impossible" and should clarify this concept nicely. https://www.youtube.com/watch?v=IcgmSRJHu_8

"Making Impossible States Impossible" by Richard Feldman

https://www.youtube.com/watch?v=IcgmSRJHu_8

ReasonML is IMO quite ready for production work if you use it for building server-side applications with NodeJS or rich front-end applications with React (ReasonReact).

The target audience for Reason (at least for the moment) are web application developers who want to level up as programmers and want to build elegant, sturdy production systems.

Reason and Elm together are democratizing statically typed functional programming and I believe that the next 10 years are going to see a massive change in the programming language landscape, with the practice of typed FP finally finding adoption in mainstream commercial programming.

The allure of Reason is in its packaging of OCaml to the web browser (which is made possible by BuckleScript - the actual OCaml to JS compiler doing the heavy lifting), its syntax that is familiar to the vast majority of programmers today, and the large ecosystem of bindings, libraries, and documentation that the team has put out.

OCaml is a very pragmatic language; its main pull is its powerful static type system and immutable, functional programming, but the "O" in OCaml stands for "Objective" - it is an implementation of CAML with support for object-oriented programming. But you almost never need objects. OCaml's module system and its idioms allows you to write well-encapsulated code without mutation, and when you actually need to write honest to metal imperative code, you can do it with abandon because OCaml is not a "pure" functional language like Haskell.

The term static type system might put off programmers whose only exposure to types were with Java, C++, C# and similar languages. But this thing is very different. Types in OCaml are more like structs in C; you just say the shape of your data, and you write pure functions that operate on them, and that's pretty much it. The magic happens in how you define the shape of your data. "Making invalid states impossible" is the siren call for statically typed FP languages, and from that flows a lot of natural constraints that can teach us how to structure programs.

The following links illustrate the promise of Typed FP very nicely, do watch it so that you'll have some inkling of the fun you'll have when you start learning ReasonML:

Designing with Types: Making illegal states unrepresentable by Scott Wlaschin. https://fsharpforfunandprofit.com/posts/designing-with-types...

"Making Impossible States Impossible" by Richard Feldman. https://www.youtube.com/watch?v=IcgmSRJHu_8

Ideology by Gary Bernhardt. https://www.destroyallsoftware.com/talks/ideology

Effective ML Revisited by Yaron Minsky. https://blog.janestreet.com/effective-ml-revisited/

Programming Languages, Part A by Dan Grossman. https://www.coursera.org/learn/programming-languages

"Making Impossible States Impossible" by Richard Feldman

https://www.youtube.com/watch?v=IcgmSRJHu_8

Really changed how I think about programming.

There is no escaping the mapping. It doesn't matter if it is Reason or PureScript, Elm, or Fable - you have to parse the incoming data into a static type if you want to enjoy the benefits of types. The good thing is that you can build the rest of your system with a firm guarantee on the shape and structure of the data. No null checks, no missing keys. If you are careful with your parsing you can raise exceptions or return None if the incoming data is not well-formed (missing keys or even extra keys).

Reason/BuckleScript when run on a Javascript runtime also has a `Js.t` type which is basically the Javascript object. You do have to define the shape of it similar to how you'd define a record type, but you don't need to convert it into a native record. JS arrays are also natively supported - it maps 1:1 to BuckleScript's array. I like to convert arrays into lists since they are better suited for value-based programming (pattern-matching over [head, ...tail] inside recursive functions).

And if you create your types in a way that invalid states are impossible, you've just reduced the cognitive load needed to work on the system for the rest of its life by an order of magnitude. Here are some resources on this wonderful programming technique:

- https://fsharpforfunandprofit.com/posts/designing-with-types...

- https://www.youtube.com/watch?v=IcgmSRJHu_8

- https://www.destroyallsoftware.com/talks/ideology

- https://blog.janestreet.com/effective-ml-revisited/

Languages like F# give a nice sweet spot between static typing and dynamic typing. It has Type Providers that "generate" code on the fly as you are typing. You don't need to specify all the types, it will infer many types for you. So, you almost feel like you are writing in a dynamic language but you it tells you if you are writing something incorrectly.

I would not consider a language to be modern unless it has Type Providers I consider this to be such an essential feature. I believe Idris and F# are the only languages that have it. People are trying to push TypeScript to add it - who knows if it will happen.

Many are saying that if you have a dynamic language you just need to be disciplined and write many tests. With good static typed languages like F# you can't even write tests on certain business logic since the way you write your code you make "impossible states impossible", see https://www.youtube.com/watch?v=IcgmSRJHu_8

There's a great talk on this subject by Richard Feldman from Elm Conf. I haven't used typescript so I'm not sure if the techniques translate well. https://www.youtube.com/watch?v=IcgmSRJHu_8