Andrew Carver

@ChShersh @ScottWlaschin Awesome book. @ScottWlaschin has a gift for simplifying complex FP concepts into practical business terms. His blog fsharpforfunandprofit.com is also great.

You can now find me in London Underground reading “Domain Modelling Made Functional” by @ScottWlaschin. It’s in F# but F# is basically OCaml, so shouldn’t be a problem to understand. I introduced DDD in our OCaml team at Bloomberg and I’m excited to learn best practices! Once I finish the book, I’ll post a brief review here.

@xypress0 @savov @prajdabre1 I don’t understand this argument. If you are deploying critical code that has the potential to cause losses of that magnitude, why were preemptive steps not taken for failover contingencies and such? This seems like a “how did we get here” question rather than a job requirement.

What is the Reader Pattern in Functional Programming and Why is it Useful? The strategy pattern is a staple in modern programming. In functional programming, we don't have the luxury of side effects. So how exactly do we decouple services from their dependencies? To start with, we can simply put our dependencies in the list of arguments to keep our functions pure: We've achieved full type safety and we have the ability to change our implementation of UserRepo for different contexts (e.g. refactoring, unit testing). However, the downside to this approach is all of the noise that this brings. We are now forced to explicitly pass UserRepo and OrderRepo all the way down, and if we ever need additional dependencies or add functionality in between getOrdersForUser and main, we have a lot of places to update. This is where Reader can help. As you can see, Reader allows us to define a return computation that depends on some dependency of type R. We can simply shift our dependency to the return value instead. By returning a function that accepts a dependency, we can similarly defer the construction of our dependencies to main and gain the benefit of not having to deal with all of the updates.

@kettanaito I personally love ReScript's solution to routing. With pattern matching it's so intuitive! rescript-lang.org/docs/react/lat…

Looking forward to the day we as a community realized file system-based routing was a mistake. Once you glimpse over the initial appeal, you see there's a flaw on a flaw. - File names aren't a format dynamic enough to support the extremely dynamic nature of routes; - Concern separation is a mess (page.ts, layout.ts, foo.ts); - Constant dance around include/exclude files; usually hard to collocate with non-route resources; - Directory nesting only multiples the mess; - It's the opposite of predictable; - Searching for routes is a mess. I wish we got back to a single "routes.ts" that declaratively lists all the application's routes. Why? Because for small (most) apps, it will have no experience degradation (even if you disregard all the improvements you gain). And for large apps, it will make the routes discoverable and easy to understand. I can hardly justify file system-based routing for web applications.

Higher-Kinded Types Demystified Have you ever heard the words "Monad" or "Functor" thrown around and wondered what they were, only to look it up and be frightened by cryptic and intimidating category theory proofs that resembled hieroglyphs? Fear not, these ideas sound daunting but you're likely using them every day without even realizing it! Let's begin with some familiar method and function signatures. In JavaScript promises are the de-facto way to represent and compose asynchronous code. In TypeScript, the type signature of ".then(...)" would look like this: Now let's take a look at a seemingly unrelated type in C#, IEnumerable. The type signature on ".Select(...)" looks like this: Rewritten in a different type signature format, these functions read: Select :: IEnumerable A -> (A -> B) -> Enumerable B then :: Promise A -> (A -> B) -> Promise B Notice the only thing that varies in these functions is the "containing" type. Naturally since we love abstraction as programmers, wouldn't it be nice to formalize this pattern? This is where higher-kinded types come in! Think of higher-kinded types as generics that operate over other types, giving us the ability to formalize a pattern like the one we observed above. Let's replace "IEnumerable" and "Promise" in the above signature with a generic called "F": map :: F a -> (a -> b) -> F b Voila! We just defined a higher-kinded type. This definition here is known as a functor and in laymen's terms describes anything that can be mapped. Promises, lists, arrays, maybes, and eithers are all examples of functors. Now that we have functors, why should we use them? One of the most compelling reasons in my experience is that your method and function signatures become honest. Instead of throwing exceptions or relying on null checks, we can wrap our values with contexts that give us additional information about the problem being solved. In this way, you don't have to wait for runtime only to find out that a certain field can be null or that you forgot a try/catch. You can then "map" the happy path and pattern match the sad path at the appropriate point in your application, with the compiler working with you the entire time to ensure you've handled all of these cases. Hopefully this helped!

Walked in to discover this on my desk this morning. I must be forwarding too many Primeagen videos to my coworkers… @ThePrimeagen

@ThePrimeagen You should invite @tsoding on the stream for the Haskell portion.

real talk i don't want to learn haskell, but i want to complete CHADstack but the end is in sight! cgi's will be invoked and we will officially file based routing in the greatest stack ever C obol H askell A lpineJS D ocker and of course RUST for the build tool

I've completed "Rucksack Reorganization" - Day 3 - Advent of Code 2022 adventofcode.com/2022/day/3 #AdventOfCode github.com/drewcarver/AOC…

I've completed "Rock Paper Scissors" - Day 2 - Advent of Code 2022 adventofcode.com/2022/day/2 #AdventOfCode github.com/drewcarver/AOC…

I've completed "Calorie Counting" - Day 1 - Advent of Code 2022 adventofcode.com/2022/day/1 #AdventOfCode github.com/drewcarver/AOC…

@MaslowJax @CodeOnTheBeach Yep, one of the really cool features of TypeScript known as parameter properties! It's shorthand for creating class properties and assigning in the constructor. #parameter-properties" target="_blank" rel="nofollow noopener">typescriptlang.org/docs/handbook/…

@drewcarver @CodeOnTheBeach Slide 15, a constructor param has accessibility modifiers?

Thank you @CodeOnTheBeach for another amazing conference and the opportunity to speak! If anyone is looking for the slides or code referenced in my talk, they can be found here: #slide=id.g58c5c79f0b_0_10" target="_blank" rel="nofollow noopener">docs.google.com/presentation/d… github.com/drewcarver/typ…

@StarsUponTharz have you seen this? Heard about it and it looks really interesting angularjs.org

@drewacarver sorry man, I'm Drew Carver too :)