samhh

I've just gone through this process over the last couple of years. To be honest, the most effective learning tool for me was dedicating my free time for a little while to learning Haskell. It's a higher upfront cost but a huge pay-off, not just in terms of understanding fp-ts but more broadly in how you'll be able to view programming through a new lens.

That said, I wrote this[1] a year and a half ago for some colleagues just as I was getting into it myself. I hope it helps, and if not let me know if there's anything more specific I could help with.

[1] https://samhh.com/blog/js-fp-jargon

I think fp-ts exists because TypeScript is entrenched with a strong job market. If that weren't the case most users would just use something like PureScript.

Libraries like io-ts and zod take care of this for you. For io-ts for example you just need to define a type guard function that asserts "x is Y" and away you go, you've got a runtime codec; it knows how to "decode" data, and it knows what that represents to the type system at compile-time. You'll generally only need to use the built-in combinators though e.g. `t.type({ prop: t.string })` produces a codec for `{ prop: string }`, and you can get that type at compile-time without effectively rewriting it using `t.TypeOf<typeof myCodec>`.

I struggled introducing fp-ts into my last team but io-ts was a much easier sell, as was fast-check.

It's a lot easier to get buy-in when you can demonstrate that it will reduce bugs thereby improving the customer experience and reducing development burden.

Something like io-ts or zod gives you confidence that the types in your application are correct, so you don't need to code or unit test defensively. This ties into the idea of pushing unsafety to the edges of your application. It can also be a quick way to discover that types don't align because of a backend API change; we had our io-ts decoding hooked up to Sentry.

Likewise with fast-check I argued its utility in its introduction PR and made clear that it's an opt-in method of testing, and it caught a bug we hadn't spotted within a few weeks. You can't really argue with results like that.

At a certain point though, if your team is unwilling or unable to recognise the limitations of TypeScript and therefore the necessity of constructs like `z.infer` or `t.TypeOf`, you might just have to accept it or move on. In my experience you can't move a team that far from where they'd already be heading without your presence. If you're surrounded by folks without experience in static typing, it's already a major win to have introduced TypeScript at all.

I think that was replaced by Rectangle.

Something this doesn't tell you is that summers in London for example are awful because our homes have historically been designed to trap heat.

The unread count in the notification doesn't update if you view your emails not in the mobile app.

If the issues with it aren't too obvious you can trade it into Apple claiming it's in good condition. That's ethical as far as I'm concerned given the issue is their own fault.

Oh damn, who laid off their PS team? First I've heard of that.

I've successfully looked at commits years old to understand the context around a feature/bug that was confusing myself and a product owner. This context is where small, well-detailed commits come in so handy beyond just the initial review.

One could argue that the effectiveness of propaganda that stems from this viewpoint proves its premise.

Whether that makes propaganda of any given form justifiable is another matter.

You have a container with `a` inside, let's call the container `m`. You have `m a`.

You can provide a function with the type signature `a -> b`. With this we run the function underneath `m` and map `m a -> m b`.

Concretely this might be with for example lists, where given a function `Int -> String` I can map `[Int] -> [String]`. What the functor abstraction gives you is a consistent, lawful way to define this phenomenon for virtually every type you'd ever want to "map". Likewise monads for "flat mapping".

This explanation was 90% accurate. What's missing is that not every functor or monad is a "container", for example Haskell's `IO`, which rather represents an action of sorts to impurely get a value. But the intuition will build all the same if you play with it a bit. It's all in the type signatures.

How can you say it's easier for humans to reason about when your test subjects almost all exclusively got started in programming with imperative programming? It's a slightly biased data set.

Function application pipelines and function composition are closely related. Here's a "pipe" in Haskell:

\x -> h $ g $ f x

At a certain point you realise that in many cases seeing the `x` is not just useless but needless visual noise. The following is identical and more readable once you've internalised composition:

h . g . f

And this extends to a cute trick in which, if you need to explicitly provide that data to begin with, you can do this:

h . g . f $ x

I'm now working with Haskell having previously come from PHP and JS/TS. Composition is more readable, it's just harder to get started with because it's different to what you're used to.

As for the "geek out" comment, of course, I enjoy programming for the intellectual sake of it. I'm not product-driven. Don't make the mistake of thinking everyone's the same as you, nor that of thinking there aren't benefits to being so intellectually-motivated. I don't know if it's intentional but your comment comes across as rather self-righteous.

I've had a great experience learning Haskell with Exercism. Also unaffiliated.

Vanced is also really good. Supports YT Music too.

Perhaps, but I think it can be argued that it encourages more consumerism. The market for second-hand selling may encourage those sellers to buy more new.

Fundamentally the idea of an everchanging fashion is problematic, not just environmentally but also otherwise.

I use offlineimap* which allows you to optionally sync in one direction.

I'm not sure what happens if the remote emails are overwritten though.

* https://github.com/samhh/dotfiles/blob/master/home/.config/o...

Hackage (Haskell) is down as well: http://hackage.haskell.org

All looks orange now, but "degraded performance" is a cheeky way to describe "everything is on fire".

The first R is reduce. The second is reuse. Our cultural obsession with fashion completely bypasses each of these.

PureScript's build system is very good (Spago), and the language is too, but it is tougher to learn than Elm veering much nearer Haskell.

This is definitely the best option in the TS ecosystem but it's not meaningfully implementing typeclasses from the perspective of the end user. There's no single `fmap` for example, instead you'll be using dedicated `Array.map`, `Option.map`, etc.

If you're willing to get your hands a little dirty you may like bangin: https://sr.ht/~samhh/bangin/

Logically they're the same, they're isomorphic. It's just about ergonomics, readability, etc.

There are many application states in which `null` could mean "not got the data yet" and/or "there is no data".

Just use an enum, it's much more expressive.

It can just as easily mean that nobody knows the solution to its novel problems yet. It potentially means nobody wants to touch it in a few years once the largest problems have revealed themselves en masse.

If something has hype it's worth investigating, absolutely. But it should also be treated with a great deal of scepticism; there's often a lot of money in it for businesses and individuals moving you onto the latest shiny tech.

You can do the same in TypeScript with newtype-ts. I'd recommend it for the same reasons you'd use them in Haskell et al.

Does anyone know of some public repositories which are good examples of good commit hygiene as described?

No statement in this arena taken to an extreme stands to reason, including "without the lure of money and its power, we wouldn't do anything".

I contribute to open source, as many others here do. Lots and lots of people contribute to society and the common good in other ways without the expectation of capitalistic reward.