Ian Schwartz is a professional software developer. He joins the show to talk about Functional Programming. He begins by defining functional programming as well as some of the key terms they use. Additionally, they dive into the different Algebraic Data Types and React.

Dan_Shappir:

Yeah, Paul's mind, as soon as it touched.

 

Charles_Wood:

Okay, hell, there we go.

 

Dan_Shappir:

Uh,

 

Charles_Wood:

Pause up load. Yeah, funny story, but we actually had to turn this on on another show for another guest. I think it was on Ruby Rogues,

 

Ian_Schwartz:

M.

 

Dan_Shappir:

I

 

Charles_Wood:

So

 

Dan_Shappir:

actually spoke to the Riverside people. I met them at a conference here because they're in Isralli company, and I asked them.

 

Charles_Wood:

Hm,

 

Dan_Shappir:

Why don't you just give some sort of an option to you know, Limit the upstream bandit, and he said, Hey, that's a good idea. So

 

Charles_Wood:

Yeah,

 

Dan_Shappir:

so hopefully

 

Steve:

So,

 

Charles_Wood:

Yep.

 

Dan_Shappir:

they actually do it

 

Charles_Wood:

Yeah, we're trouble shooting Riverside for Riverside. All right. Well, here we go. Hey, welcome back to Java Script jabber This week. On our panel we have Steve Edwards,

 

Steve:

Hello from a cold and snowy Portland.

 

Charles_Wood:

A J. O Neil

 

AJ:

Yo yo yo, coming at you live from a nice cold one.

 

Charles_Wood:

Dan caper.

 

Dan_Shappir:

High from a warm and sunny tellevive where the weather is great and the politicians are terrible.

 

Charles_Wood:

Oh, wow, I'm sure I don't know how to follow that. I'm Charles_Wood Max Wood from Top End. Eves, also cold and snowy. Here we have a special guest this week. that's en shwarts. e. N. Do you want to introduce yourself? Remind people who you are. It's been a while.

 

Ian_Schwartz:

Hi guys, even Schwartz. I'm a principal job script engineer at Cargoruse and I live in unseasonably warm right now, Boston, Massachusetts. Uh,

 

Charles_Wood:

Oh nice, warm sounds so nice.

 

Ian_Schwartz:

I mean, you know forty five degrees, which is a beach day

 

Charles_Wood:

Right

 

Ian_Schwartz:

at this time of area.

 

Dan_Shappir:

Yeah, just just so you know, it's evening here and it's sixty three.

 

Charles_Wood:

All right. I'm gonna start talking to Dan now.

 

Dan_Shappir:

Uh,

 

Charles_Wood:

But and you gave a talk a couple of weeks ago At Developer Week. You were talking about domain modeling and functional programming. It had a really long title and I don't remember all the words.

 

Ian_Schwartz:

It's okay.

 

Charles_Wood:

but yeah, effectively, Yeah, you were talking about how to put your domain logic into. I guess functional enclosed. I'm probably

 

Ian_Schwartz:

Yeah,

 

Charles_Wood:

going to mess up the way that you talked about it. Ways of dealing with that domain knowledge. And what's interesting is. yeah, um, I think you were focused on react, but I'm finding that in a lot of the stuff that I'm building, you can kind of make you can kind of make use of some kind of strategy like that. no

 

Ian_Schwartz:

Yeah,

 

Charles_Wood:

matter what you're in, Right, because your framework logic can call into those things and you can keep them all mostly self contained. There are always exceptions. But did I mess it up enough? or do you want to add something to that?

 

Ian_Schwartz:

No. I think well, hopefully we have something to add to hat. We have another hour of show to go, But yeah, I think that was great. Yeah, so I mainly have worked in React since I guess two thousand, and I want to say two thousand seventeen, two thousand eighteen. And you know I, I'm not. I guess I'm not sort of what I think of is the typical functional programming. You know, Person in that I didn't come know a lot of people who got into React with functional programming. People Excited that react was like a way they could express their logic functionally, Whereas I sort of came to functional programming. Um, you know through React, Um, and yeah, I guess what. I kind of realized that a certain point was that you know the more of a vocabulary you have for describing your data functionally, Uh, the easier react sort of becomes to work with M. You know, even in the early days of react, least for me when I first got into React, they always said You know you want to express as much of your apple Jack as a pure function is possible. And so you know, taking something you've defined in line and you know, writing a function that says Get food, And you know it's at least a pure function right. That's a start, but you can take it a lot further, and the more you're able to apply this, the less need for overhead you have. Like you know, you can still use state management libraries. But maybe if your state is simple enough to reason about, you know you don't need to reach for something like that. And so that's That's something that I in my Ole as an educator and as a you know, train a lot of people and work with more junior developers that haven't worked to react. And it's something that I found really pays off. you know, exponentially as you're as you're learning the framework. And yeah, I agree. ith, you. It applies. view solid. Any of them can benefit from some, some portion of this.

 

Dan_Shappir:

It definitely applies to essentially any

 

Ian_Schwartz:

M

 

Dan_Shappir:

framework on the one hand. On the other hand, it's also the true. I. I think that React kind of encourages this approach because of the let's call it functional foundations of React itself. The fact that React wants to construct or kind of promote the model of construction, which is which revolves around the composition of functions or

 

Ian_Schwartz:

Right,

 

Dan_Shappir:

functions are come Ponents. you compose components. Therefore you compose functions, and ideally functions are as pure as possible, with props or state coming in and coming out.

 

Ian_Schwartz:

Right.

 

Dan_Shappir:

so so

 

Ian_Schwartz:

Well

 

Dan_Shappir:

I

 

Ian_Schwartz:

and

 

Dan_Shappir:

guess

 

Ian_Schwartz:

actually,

 

Dan_Shappir:

this kind of approach works

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

well both ways.

 

Ian_Schwartz:

to build on that, I actually think that we lost something a little bit when we lost the class based component syntax. In

 

Dan_Shappir:

Oh

 

Ian_Schwartz:

that

 

Dan_Shappir:

yeah,

 

Ian_Schwartz:

you know

 

Dan_Shappir:

interesting

 

Ian_Schwartz:

well what we lost was that in when I first learn and react, we had class components that were state flan effectful, Right and then you had pure functional components that were very easier to write, but couldn't do much, and having those two sin taxes and having the pure functional version be so much easier to write than the class base Version kind of steered at least the code I was writing towards being mostly pure functional components. Um. the ability to just make any component stateful or effectful is great when you need it. but you know all of a sudden now we don't have this clear vocabulary for saying Well, here's one kind of component for situations. You know that if we can, if we can write it without any state or side effects, we can test every single possible outcome of it right and know it's going to always be one hundred And no mocking needed. No, you know complicated set ups and you know, the more those components you write, the easier it is to get us this widespread coverage test coverage. At least you know, some small, some portion of your app, right, Um, When everything is stateful and everything is effectful, Uh, it can be much more difficult to have that level of certainty about your code.

 

Dan_Shappir:

For sure, although it is worth pointing out that at least one of the main motivations that react moved from using class base components for state full components to using hooks instead is the fact that you can so easily move between

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

stateful and stateless components. You want to make your stateless component stateful Just at U. state. You want to make it state less again. Just remove the U. state. So so In that

 

Ian_Schwartz:

No, I don't

 

Dan_Shappir:

that

 

Ian_Schwartz:

love

 

Dan_Shappir:

was

 

Ian_Schwartz:

the

 

Dan_Shappir:

like

 

Ian_Schwartz:

class

 

Dan_Shappir:

one of the

 

Ian_Schwartz:

components,

 

Dan_Shappir:

main motivations,

 

Ian_Schwartz:

but yeah, I don't love the class components. But again, I just think that you know mentally, you know when you're working with people that Okay, So anybody who has worked with somebody who has been really into functional programming has seen a section of the code based that nobody can read. And

 

Charles_Wood:

Uh,

 

Ian_Schwartz:

and nobody knows what to do with Right, And you know you can go

 

Charles_Wood:

I mean,

 

Ian_Schwartz:

down

 

Charles_Wood:

not me. I've never seen that.

 

Ian_Schwartz:

right exactly, You can go down that road. Um, you know, I think the most important thing right is to make sure that you know I work. I work at enterprise companies. Other other people are reading my code. Besides me, I'm reading other people's codes. The most important thing is is that code accessible right? It can't just be that we want to have it be functional, but it has to be accessible and usable And so I think it's great to be able to make a component you know stateful just with dropping in a line of code. but at the same time you know The the, the need for those two kinds like I don't know to me having the easier one. You know. it sort of forces you into to doing it into doing it that way. Sorry,

 

Dan_Shappir:

I

 

Ian_Schwartz:

I'm

 

Dan_Shappir:

totally

 

Ian_Schwartz:

kind of losing

 

Dan_Shappir:

agree.

 

Ian_Schwartz:

my time with us

 

Dan_Shappir:

I mean, Yeah, for sure, I mean, if nothing else, the minute you put a use state or use effect into a function to a component and react, you made it exponentially more difficult to test. For example.

 

Ian_Schwartz:

Right

 

Dan_Shappir:

so yeah, for sure,

 

Ian_Schwartz:

Now. Then the key? though, right, So if we're talking about writing code that's functional that that people who are not experts in functional code are able to use right then, the key in my mind at least is to model that code on. You know. Really the only two data types that people use in job, a script which are raised and promises. Okay, the reason we throw a lot of reactivelopers You. now you can throw state into an array. All of a sudden it become. It's very easy to reason about because when you need to transform that state into something, you have map on the on the array you have reduced on the array. You have filter. working with that data in a functional way is very intuitive and very easy. For you know anybody who's learned E s six flavor job script. And so what I have started advocating for is you know, modeling your data in a way that matches that, where I'll actually model any. any data that's going to be used in my Apple. Have a map method on it, for example, So that you know and defining that custom map method to allow me to write you know data transformations just as easily as I would if that array. if that was in array. Um,

 

Dan_Shappir:

Remind me, what's the official functional term for something that that is mappable in this way

 

Ian_Schwartz:

Well, Okay, So technically so there's There's sort of two terms I'll introduce. Okay. The first one is called Functor. Functor is anything that has a Mat method, basically um, and the second one which is sort of a dirty word, is monad Um. And you know it's very

 

AJ:

They're

 

Ian_Schwartz:

simple.

 

AJ:

both dirty words in my opinion.

 

Ian_Schwartz:

You know they're not. though, If you, if you, they're they're only hard to explain because most of the explanations that people have of them come from a category theory background which is very hard to understand. But if you use promises and job of script and you use a raise, then you understand how monads work Already? Basically

 

AJ:

So I want you to finish your thought and I want to come back around to this and I want you to be the first person ever to explain to me what a monad is in a way that I can understand. But

 

Ian_Schwartz:

Okay,

 

AJ:

finish your thought here.

 

Ian_Schwartz:

No, No, I mean that's that's where I was going anyway. So a monad Okay is essentially a data structure. It's not instartly a container, but you can think of it as as having some sort of inner thing that it's holding okay in the

 

AJ:

So

 

Ian_Schwartz:

case

 

AJ:

container,

 

Ian_Schwartz:

of an array.

 

AJ:

like an array as a container and like an object as a container or

 

Ian_Schwartz:

Well,

 

AJ:

more appropriately

 

Ian_Schwartz:

not not

 

AJ:

a

 

Ian_Schwartz:

literally

 

AJ:

map.

 

Ian_Schwartz:

a container, but you know in array. When we, when we think about an array, we know that an array has within it. You know a sequentially numbered list of things right. that's what it represents.

 

AJ:

We also know that a function has a scope inside of it, so it's a container of a sort.

 

Ian_Schwartz:

Sure. Sure. okay,

 

AJ:

Does that fit in with this broad definition?

 

Ian_Schwartz:

Yeah, yeah,

 

AJ:

That's

 

Ian_Schwartz:

monads

 

AJ:

what I'm trying to

 

Ian_Schwartz:

are

 

AJ:

get

 

Ian_Schwartz:

functions.

 

AJ:

at.

 

Ian_Schwartz:

for sure. Absolutely monads have functions and that's exactly the right.

 

AJ:

Wait

 

Ian_Schwartz:

The

 

AJ:

are

 

Ian_Schwartz:

thing

 

AJ:

functions

 

Ian_Schwartz:

that they,

 

AJ:

or have functions?

 

Ian_Schwartz:

they are functions

 

AJ:

They are functions and they have functions.

 

Ian_Schwartz:

And they have functions. Yeah, welcome

 

AJ:

Okay.

 

Ian_Schwartz:

to functional programming. A J.

 

Charles_Wood:

Yeah,

 

Ian_Schwartz:

H,

 

AJ:

I don't know if I feel welcome yet. Continue.

 

Ian_Schwartz:

So you know, I mean promises are right when you. when you create a promise, a promise is a function. And and anyway, so the point is, it's a data type Okay that has at its core a something that it's holding within it, conceptually not necessarily literally. In the case of an array, it's a sequential list of things. In the case of a promise, it's in a synqrenous task that is either in a completed or yet to be completed, or State of some kind. Okay, and rather than examining you know with an array, you can directly use indexes to to just grab things from that array. but you know in a pure functional language you probably wouldn't do that very much. Instead you would prefer to use you know the map. Reduce, for each methods, Those those those methods that take those call back functions like map Right, those are the things that put us in the cab Or a functional programming. and map is what makes a functer. If you can take something and supply a map method that has a call back that exposes the inner value and then you know you return it and you get another instance of the thing, just like you get a new array back when you map over, You know in a ray that that's a functor. What makes it a monad is that it's flattened automatically with a rays. You have you know, Ma, and you, So, a flat map that automatically flattens it. Flat map is the method that makes an array and job a script on At In promises. there's no concept of a promise of a promise, So that he then method automatically flattens it right. If you return a promise and a dot, then Method, You don't get a promise of a promise of a promise. You can only have you understand what I'm saying.

 

Dan_Shappir:

Just

 

AJ:

Um

 

Dan_Shappir:

to just to make a quick comment here in

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

case our listeners are not familiar with it. Flat map is a method on Ares, kind of like map, with the added functionality that if you've got an area of areas, it flattens it into an area,

 

Ian_Schwartz:

Right,

 

Dan_Shappir:

so think about like an area which, where every element in that area is an area and you know You want to, let's say, just have all the values all like flattened into just one longer. Are that that is something that flat map can do.

 

AJ:

So

 

Ian_Schwartz:

Right,

 

AJ:

two things on that one, it would be better named concat map, right? Because that's what it's

 

Ian_Schwartz:

Okay,

 

AJ:

doing. You're taking each thing and whatever you return, you're concatenating to the result.

 

Ian_Schwartz:

Um, I mean, I think they probably called it flat map because it's basically like calling dot map and then dot flat.

 

AJ:

Or is it recursive? Is it one layer or

 

Dan_Shappir:

It

 

AJ:

is it

 

Dan_Shappir:

can

 

AJ:

recursive?

 

Dan_Shappir:

be. it can be recursive, but you know, so it can be one level. It can be recursive.

 

Ian_Schwartz:

Yeah, it can be recursive,

 

Dan_Shappir:

Let

 

Ian_Schwartz:

but it's

 

Dan_Shappir:

me

 

Ian_Schwartz:

not necessary.

 

Dan_Shappir:

quickly

 

Ian_Schwartz:

Stuff

 

Dan_Shappir:

pull up the m. d. N. It's

 

AJ:

And

 

Dan_Shappir:

actually it's literally

 

AJ:

to you.

 

Dan_Shappir:

called Flat map in my inn, you know, in the

 

AJ:

Yeah.

 

Dan_Shappir:

job,

 

Ian_Schwartz:

Right

 

Dan_Shappir:

the job script language.

 

Ian_Schwartz:

And promises

 

AJ:

Yeah, I'm just...

 

Ian_Schwartz:

worked the same way. If you return a promise inside of a dot, then of a promise. You know you don't get a promise of a promise right. It's automatically flattened, so those are the same method.

 

AJ:

Well, so you don't get a promise that promises another promise. You

 

Dan_Shappir:

Oh,

 

AJ:

get

 

Dan_Shappir:

by

 

AJ:

a

 

Dan_Shappir:

the

 

AJ:

promise

 

Dan_Shappir:

way,

 

AJ:

that,

 

Dan_Shappir:

just just

 

AJ:

in essence,

 

Dan_Shappir:

as a comment.

 

AJ:

contains the promise.

 

Dan_Shappir:

Just

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

just one thing. I just quickly scan the the M d N. You know that excellent job script documentation there, and in the m d N. it just go. It just shows that flap map in Java script is just goes one level deep, so

 

AJ:

Okay,

 

Dan_Shappir:

it's

 

AJ:

so

 

Dan_Shappir:

not

 

AJ:

it's not recursive.

 

Dan_Shappir:

Yep.

 

AJ:

So to finish the thought, so

 

Ian_Schwartz:

Yeah,

 

AJ:

with the Monad version, does it require it to be recursive? And could it handle an array that there's one element is not nested, another element has a nested array, another element has a nested array that has a nested array. So do the layers have to be at the same level? Or can they be at different levels? And does it have to be recursive?

 

Ian_Schwartz:

Uh, I'm going to say it doesn't have to be recursive like that, but I'm not sure I've got a little wisted up here, so no, I don't think. I don't think that it has to, you're saying, doesn't have to fully flatten it every time. Or can you still have some sort of nested rays?

 

AJ:

Yeah,

 

Ian_Schwartz:

I believe that you can. Yeah,

 

AJ:

I'm just trying

 

Ian_Schwartz:

um,

 

AJ:

to understand the nature of, you know, you're

 

Ian_Schwartz:

Right.

 

AJ:

saying that that map is not an array with a map is not no a map is not a functor, but flat map is a functor.

 

Ian_Schwartz:

Well, No, neither one is a functor. Right When when a data type implements that that method that's called map, or in functional programming, turns more often called Bind, right. It then become like we would say that that data type is now a functor. I guess is a better way of putting it.

 

AJ:

So

 

Ian_Schwartz:

the method

 

AJ:

an array.

 

Ian_Schwartz:

itself. You know, a dog is a thing that implements wolf, wolf, and eating kibble, and walking on a leash. Right, it's not. and so anything that that can do those things we would now say. Is it Dog right? And maybe that's kind of a broad definition of

 

Dan_Shappir:

So

 

Ian_Schwartz:

dog. But

 

Dan_Shappir:

so you

 

Ian_Schwartz:

yeah,

 

Dan_Shappir:

just but to clarify over something that said, So defining

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

map, or or bind, as you said is enough to specify you as being a functor. And if you specify flat map versus just map, that starts pushing you into monad land.

 

Ian_Schwartz:

Right. exactly. And so the dot then method of a promise is also an implementation of that flat map. Okay, so the reason I bring these up is not because, Um, I need anyone to be an expert in monads, but understanding that this is, this is a pattern, Right that the job of script that the Echmoscript language designers incorporated based on functional prorgamninto, the language and most people, Um, working and react. At least you know if you're working on an enterprise enterprise company Like I do, you know, Fetching data from a P is your modeling state. Often as it raise, you know, it's very easy to work with those two data types in that react J, s environment, and I assume an other frame works as well. Um. And so when we're modeling data and we're taking the logic of our Ap, you know the state of our Ap, and how to work with it, and what methods to define on it. Right, modeling that data in a way that is just as familiar. throwing a dot map method on something and making it so that you can now map Over it. At least in my mind, makes it very intuitive to work with, because that's it mirrors the most commonly used data type in the language. Does that make sense?

 

Dan_Shappir:

Yes, so I just wanted to add or to make one observation from my perspective

 

Ian_Schwartz:

Yes,

 

Dan_Shappir:

It. I totally agree that working with maps with eras, sorry, or literally anything that has a map method on it. because that's one of the great

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

things about Java script. You know, Duck typing. You can throw the method over anything. It will work. Um. That comes really naturally when you're working in React, because you

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

know anybody use iterated over anything In reacting. J. Sex has used map. promises. On the other hand, that's for my, For my experience a bit more challenging. working and react, because

 

AJ:

Yeah.

 

Dan_Shappir:

react like to be synchronous. Uh, you know, it's kind of. it's starting to change now with service components and what? not? But so far

 

AJ:

And that's something else I wanted to bring up from a few minutes back. You said callback, but I don't think you meant callback. You said the map function. I think you said the map function takes a callback, which is not true. And JavaScript

 

Dan_Shappir:

Why

 

AJ:

map cannot take a callback.

 

Dan_Shappir:

No, it does. It takes

 

AJ:

No, it

 

Dan_Shappir:

a

 

AJ:

doesn't.

 

Dan_Shappir:

function. Well,

 

AJ:

No, it takes an anonymous function, which is not a callback.

 

Dan_Shappir:

What's the difference?

 

AJ:

So a callback is when something happens asynchronously and you're going to call back after the asynchronous operation has happened.

 

Dan_Shappir:

Yeah, I think a lot of

 

AJ:

A

 

Dan_Shappir:

people

 

AJ:

map.

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

when when they, when, when they pass a function into something they call it. call back.

 

AJ:

Which

 

Dan_Shappir:

I don't

 

AJ:

is

 

Dan_Shappir:

know.

 

AJ:

which is incorrect, but

 

Ian_Schwartz:

Yeah,

 

AJ:

I agree with you and that's why I wanted to bring it up because it's

 

Dan_Shappir:

Okay.

 

AJ:

very confusing

 

Ian_Schwartz:

Let

 

AJ:

to

 

Ian_Schwartz:

us

 

AJ:

talk

 

Ian_Schwartz:

for the

 

AJ:

about

 

Ian_Schwartz:

sake

 

AJ:

this

 

Ian_Schwartz:

of moving

 

AJ:

stuff.

 

Ian_Schwartz:

it forward, say I won't call a call back again. I'm striking it from

 

Charles_Wood:

Yeah,

 

Ian_Schwartz:

my book. Anywhere

 

AJ:

Well, no, it's just it's just if you're talking about something that's a synchronous right because we it JavaScript can be confusing because we've got promises. And promises don't work with maps for example right we we don't have any native methods that will do what map does for a promise and so

 

Ian_Schwartz:

We do,

 

AJ:

it's.

 

Ian_Schwartz:

it's called dot ven, that's what it's called.

 

AJ:

Well, but you have to write a container around that, right? Or you have to put it, so yes, you can emulate the behavior, but we do not have something, we do not have a single method that you can call that will do it. You can chain.thens together, and that gives you the same benefit, but it's not, intuitively, I see this with new developers all the time, and imagine you do too. They use.map thinking that it's a callback, thinking that they can put something asynchronous in there, that they've got,

 

Dan_Shappir:

Oh,

 

AJ:

you

 

Dan_Shappir:

you're

 

AJ:

know, what

 

Dan_Shappir:

talking.

 

Ian_Schwartz:

Oh,

 

AJ:

are

 

Ian_Schwartz:

yeah,

 

AJ:

old.

 

Dan_Shappir:

You're talking about the fact that you can't use in a sink function as as the function for duration. Well, you can't technically, but

 

Ian_Schwartz:

You'll get back

 

AJ:

It doesn't

 

Ian_Schwartz:

a ray

 

AJ:

work

 

Ian_Schwartz:

of promises.

 

AJ:

as expected.

 

Dan_Shappir:

it

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

won't. Yeah,

 

AJ:

Yeah.

 

Dan_Shappir:

you'll get back an array of promises that probably that aren't resolved. Uh, yeah, and and you can, Yeah, it gets funny that way.

 

Ian_Schwartz:

But these are these. Are you know? The complexity of mixing these two data types, I think is is sort of a secondary thing to the fact that they, they both present a language that you know you don't have to check with a promise whether or not it's been resolved. right. You can write your promise code and your dot Then and all that's kind of extracted away from you and the same with an array. You know. one of the reasons that that for each is so much better than than writing. like, Uh, you know, then direct Access right is that

 

AJ:

Well,

 

Ian_Schwartz:

it

 

AJ:

for

 

Ian_Schwartz:

works

 

AJ:

each

 

Ian_Schwartz:

just as

 

AJ:

is

 

Ian_Schwartz:

well.

 

AJ:

direct

 

Ian_Schwartz:

if it's

 

AJ:

access.

 

Ian_Schwartz:

empty. Well, I mean, then like you know, bracket,

 

AJ:

Map and filter.

 

Ian_Schwartz:

bracket access is what I'm

 

AJ:

Oh,

 

Ian_Schwartz:

talking

 

AJ:

okay.

 

Ian_Schwartz:

about, Right that iterating using those functional methods works so well. Is that it works just as well whether the array has anything in it or not. right. You don't have to make those checks in your code. If the array has any members to it, then do something to it. So one of the things that I've done is I've worked on this, this no j, S module that I All state S, C, h, t t E, which is a weird name. but I name all my projects as C. H. Just how I do it. Um, and basically this came from the idea. Well, if I wanted to write a data type that does that same thing right, I want to. I want to not. I want to not have to check in the same way. I don't have to check with a promise whether it's been resolved or not. I can just write my dot then and it's taken care. What if I could abstract away F l statements from my code. Right, Model my data in a way where you know it's in this box and I can just write methods that work against it. just like the dot. Then methods work and not have to check Um things. so in the case

 

AJ:

Now,

 

Ian_Schwartz:

of yeah,

 

AJ:

is that the maybe monad? Because I've heard this talked about before, and this is interesting.

 

Ian_Schwartz:

Right,

 

AJ:

You can compose. Have you heard about call bags?

 

Ian_Schwartz:

Call bags.

 

AJ:

Call bags. Yeah.

 

Ian_Schwartz:

No.

 

AJ:

Okay, then I won't go into it, but it's kind of in this

 

Dan_Shappir:

Yeah,

 

AJ:

vein, event-oriented,

 

Ian_Schwartz:

Yeah,

 

AJ:

functional

 

Dan_Shappir:

Yeah,

 

Ian_Schwartz:

so

 

AJ:

something-something.

 

Dan_Shappir:

I saw. I saw that talk that you gave. But yeah, but let's not go there for now.

 

Ian_Schwartz:

So the maybe monad is exactly when I started writing the library. That was the first one I wrote. Um, and the maybe monad. You know, I had played with rust a little bit in the past, and Rust, has they call it an option type, which is essentially also a maybe monad. And that's exactly right. The idea behind this was that you know in React, it's a tree like structure, Right you? you make your, your, You fetch your data somewhere near the top of the page, or it comes pre loaded from server components Or whatever other method, And it's pass down the tree. and you know, in practice we end up writing throughout the body of a J of a react, Ap, a lot of little. If checks. You know, if it's there, then do the thing to it, and if it's not there, then give me this other thing and I, the earlier in the tree, you make that decision the better right. So if I could wrap my data in a mad monad and then pass it down the tree, then I can you know, extract things from it and write transformations against it without Or having to write An If statement was kind of the goal of it.

 

Dan_Shappir:

Um, and you know one of the benefits of this approach in Re, but is the fact that because of J sex, we end up doing a lot of things as expressions. You

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

know. One of the problems in Java Script is that statement, when you try to use Jobscript as a functional programming language, Is that in Javascript instructions or statements are not expressions. You can Really use that saying, If as in an expression you have to use How S called the The The question mark,

 

Ian_Schwartz:

Oh, the nullible

 

Dan_Shappir:

No,

 

Ian_Schwartz:

changing or whatever.

 

Dan_Shappir:

the the Trenor

 

Charles_Wood:

Luturnery operator,

 

Dan_Shappir:

Ternary operator.

 

Ian_Schwartz:

Oh, the turner.

 

Steve:

Hm.

 

Dan_Shappir:

Yeah, and you end up with really complicated and hard to read stuff in your in your J sex. Because of that, because again you need to deal. you handle all of J sex as you know, this one big expression, So anything that you can do as part of an expression And that's one of the benefits of functional programming. that everything becomes an expression Really lends. it lends itself to this kind of an approach. But

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

I think it might be beneficial to expand a little bit about what what may be actually is.

 

Ian_Schwartz:

Sure, so maybe essentially at its core, right in the same way that you know we said a promise is conceptually holds. you know, some effect that hazard hasn't finished firing. Right, Maybe holds a thing that might be there or might not be there. Um, And you know non existence is a problem in Job script because you know we already have two types for defining non existence. Things can be undefined. That can be null, Um. but you know with a maybe You basically, uh, you wrap some value or the output of a function and uh, you can write. It has a Dot Mat method, so you can write not a call back, but a function supply to that Dot Mat method that will operate on the data only in the event that it's present. and if the maybe has nothing in it, then it will be ignored in the same way that writing adopt map against an empty array is also essentially Ignored.

 

Dan_Shappir:

So it's

 

AJ:

So.

 

Dan_Shappir:

like it's to make things simple simple. It's like an area with a single element versus and are with zero elements. So having the value

 

Ian_Schwartz:

Right.

 

Dan_Shappir:

means that you're like

 

Ian_Schwartz:

That's

 

Dan_Shappir:

an

 

Ian_Schwartz:

a good

 

Dan_Shappir:

area

 

Ian_Schwartz:

way to

 

Dan_Shappir:

with

 

Ian_Schwartz:

put

 

Dan_Shappir:

a single element, and having no value means that you're like an area with zero elements.

 

Ian_Schwartz:

And, and being able to write methods that call that can either map over it if it's something or you know, can fire if there's nothing there. I have methods for that as well, you know, mirrors the way we can write Dot, then and dot, catch with promises. For example, where you know, we know that the promise is just going to call which side of the code it has to call Um, at the time that it needs to be called, So this allows you to to not make a decision about what to do with this data, whether it's there or not, as you pass it down the tree. Then eventually you get to a point where you do have to make that decision. Eventually get to a point where you know you need to either return one piece of U. if if something is there, and something else. if there's nothing there, right. Um, and when you so in functional programming languages, they would do this using the feature called pattern matching, which doesn't exist in Job of script M. If you look at like Rust, you know, you basically write code that says if the case is something, Return this. if the case is nothing, And this, Um. And so I've written a method that you know. I wrote a method that kind of hacks it pattern matching using job script syntax, and lets you from that point you're no longer in. Maybe land right when you need to know. Okay, Well, if there is a user, I want to show this, and if there isn't a user, I want to show the Logan page right. That's where you're making that decision. So uh, after writing the, maybe, I sort of realized that there were other data types that I could apply this to. Um. And so I wrote a few other types in the library. The first thing I wrote was a type called State, which is a simpler version. The maybe, and that it doesn't. It just holds a thing right. It doesn't hold a thing that could be. not. There just has a thing in. It offers dot map and some other easy methods for working with the data in that thing. And then I wrote Either, which is another one that comes from Rust. Either is a data container that has a left side and a right side, So this is either a string on the left or a number on the right. M, and the either type offers dot, left and dot right methods for mapping over either side. And then I went and I rewrote maybe because I realized that maybe is essentially on either of something or nothing. Um, so I rewrote it to use either under the hood. Um, And you know it's one of these things that as you're talking about, as I'm talking about it, I know it sounds complex, but um, you know, the idea is that a lot of The confusing parts about modeling code modeling data are abstracted away. so there is some complexity, but it's not complex to use. Right, My phone is a complex machine, but ideally you know it shouldn't be hard for me to interact with it. And so you know when when writing when modeling data on an app, Especially it's going to be used by a lot of other developers, especially more junior developers. The most important thing is the being able to take that data and log it to the console or D Bucket, and poket it, and have well defined methods for working with it and have it be straightforward. So a lot of care and thought has gone into the design of the a. P. I, I guess,

 

Dan_Shappir:

And like I said before, I think that using these functional constructs in the context of React is really powerful because the fact that like I said with J sex, you want to have as much as possible of the logic is part of the J sex expression itself and not in various ifs and what nots, that you used to construct like Part, portions of char sex, and then kind of put them together and and then you really end up in a mess. Um, so so

 

Ian_Schwartz:

And sorry, please.

 

Dan_Shappir:

no, and being also able to pass these functional constructs as prams from a parent component into its child components is also as part of the props, is also doable and really powerful,

 

Ian_Schwartz:

Now, the other the other side of it too, And the thing that I, I emphasize a lot when I talk to people is when I talk about this is testing because you know I really believe in having well tested user interfaces, and you know I have in my mind sort of a higher archy of how hard wear in the code things can be versus how hard they are to test like an If statement or a etornary inside of the J, s. X and a return statement of a component is really annoying to test Right, and it's slightly less annoying if that logic is defined in the body of the component, and slightly less hard to test if it's defined in a hook. But if you can define it as a pure function in some way, then it becomes very easy to test Um, because pure functions can be called. You know, I love React Testing library, but you know setting up a component with React Testing library often involves boiler plate. If you can test a piece of functionality without having to have that boiler plate. Um, you know, the test will run faster and Less less. you know, difficult to read and write. So that's a big part of why I really push for this.

 

Dan_Shappir:

And by boiler plate, I guess you mean things that set up marks and stuff like that.

 

Ian_Schwartz:

Yeah, or even just you know? Um, Yeah, things that set up Max, You know, sometimes even you know if you're if you're modeling your data in a functional way right, creating an instance that function to pass as a prop in the Render function of React Testing library is not that hard. but you know sometimes you're you're passing things that are deeply nested job of script objects, And you know, maybe maybe there's five lines of code. ten lines of code at the top of the test file, just creating props to pass down. Um, you know, Yeah, and often it involves. It often involves mocking Apis off it. it involves Um. you know having having your our route for your test that I don't know. I mean, you know, there's a difference between testing a whole component to test this line of code versus just being able to test this line of code itself in some way,

 

Dan_Shappir:

So at the end of the day, when you construct when you implement some functionality and react, what you're saying is that you house all your state in these functional construct Is that is that what you're saying effectively?

 

Ian_Schwartz:

You know, in something resembling them right like the state library is not like. I'm not using that in production at work by any means, but you know it's meant to represent kind of the way that I think about code, and I use it as an educational tool more than anything else right now Because you can, you can implement a dot map method on on anything on any data type that you build right. It doesn't Ou, don't have to use mine. You can you know it's It's a couple lines of code to create dot map, and once you know how to do it, You know doing it again and again is very easy. Um, but having this mental model in place. Yeah, I always write code you know, and it may be over killed. For some applications, Don't get me wrong. There's plenty of apps that are not data driven, but when you're working with with deeply nested data, Um, you know, there's this one of one of the other things that I I teach people about when I do. This is a concept called lenses, which is another functional programming term And this is to me is really cool because an object oriented Programming right, You have you know your your model and it has getter and setter methods for mutating the value of it right. But lenses are our functional, a functional approach to the same thing, so your setter methods will always return a new instance of the thing that you're working with

 

Charles_Wood:

Hm,

 

Ian_Schwartz:

Right, And so a lot of the data types I build will have dot map, and then dot map will be used within Thee, Functional set are methods so that when a more junior person, or even just somebody who hasn't worked with this piece of the code base before looks at it, they have a very clear place to look to see all the different types of transformations were doing on the data throughout the app. Right because we're we're specifying them in one place and a very clear place to add more logic That goes with that And you know you can, they can copy and you can see how it's been tested in the past. It's all about me. It's easy for that next person to jump on board, Which you know, I admit that talking about it doesn't always sound that easy. but uh,

 

Dan_Shappir:

So her?

 

Ian_Schwartz:

you know,

 

Dan_Shappir:

So here's a question you know. Obviously,

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

Java Script is not a pure functional language.

 

Ian_Schwartz:

Correct.

 

Dan_Shappir:

Currently it doesn't have. let's say, for example, immutable data structures. It might gain

 

Ian_Schwartz:

Sure.

 

Dan_Shappir:

some. if and when the records and couples proposal becomes officially part of Java Script or Ecmoscript, But currently it doesn't so effectively your simulating an immutable data structure on top Of data structures that aren't intrinsically or inherently immutable Um.

 

Ian_Schwartz:

Sure,

 

Dan_Shappir:

and that creates a certain amount of overhead, both practical and conceptual. How do you deal

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

with that?

 

Ian_Schwartz:

well, first of all, type script makes it much easier because with type script you know we can. Um, You know very easily. First of all, you can't. really. you're right. We don't have a mutable data structures, but with type script we can you know. kind of get the Type script compiler to tell us that it's immutable

 

Dan_Shappir:

M.

 

Ian_Schwartz:

Um. And you know the other. the other thing, I guess, and the other with type script is return types on functions. You know all those all those setter lens methods. Right should all be returning a new instance of the thing you're working with, And so in the code review process it should be very easy to see if somebody is accidentally mutating the data by the fact that they're That will now be returning void versus returning a new instance. Uh, you're right in that you know there's like with a monad and Hascol, For example, you can't directly examine the inner value. You can only get at it through using the Mind function, and in Java script, you're right. You can directly inspect it, but in some cases that's a plus too, because it means that you know when you're looking at it in your, in your in your brows, or console. Um, it's probably more transparent for D In purposes than it would. You know what I'm saying, Like you still write the code that way, but you do have access to more data then Then you probably should,

 

Dan_Shappir:

Yeah,

 

Ian_Schwartz:

Which, which you know,

 

Dan_Shappir:

With

 

Ian_Schwartz:

if

 

Dan_Shappir:

great

 

Ian_Schwartz:

it's in a

 

Dan_Shappir:

power

 

Ian_Schwartz:

read.

 

Dan_Shappir:

comes great responsibility.

 

Ian_Schwartz:

Yeah, you know. Look, it's the Wild Western Job script. Right at the end of the day, you can do what you want. Type script for me has really been. I was. I did not like typescript. At first, I have come around on it, and in part, it's due to leaning into functional programming because they play so very well together.

 

Dan_Shappir:

I think if I can digress a little bit,

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

I think that really a key aspect of why Type script was really disliked by many including myself initially, and is now grown on so many of us, including me to a great extent.

 

Ian_Schwartz:

No.

 

Dan_Shappir:

And the reason is that initially, when Typescript came out, it was position, while given its C sharp influences Sounds surprising, but it was really positioned as this kind of statically typed object oriented layer on top of Java script. Uh, you know, classes and interfaces and extends and and stuff like that, and a lot of us were looking at it and thinking this is like a poor man's job, And we didn't like Java, were using Java script and other, trying to stick Java or see sharp Down our throat using Type script, and I think that type script you to frameworks or libraries like React, and the way that Jovscriptdevelopers prefer to use it as really evolved a lot to be to have a more functional approach itself. I'm seeing a lot of people use type script without ever using classes or even interfaces. They're just using types And functions and you know, generic and stuff like that, and that makes

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

for really powerful utility in this context like you just said

 

Ian_Schwartz:

That said that said, I love jovascriptclasses I know I'm in the minority. Um. I think

 

Charles_Wood:

Uh,

 

Ian_Schwartz:

they actually play really well with functional programming.

 

Charles_Wood:

uh,

 

Ian_Schwartz:

As long as as I said, all your set are methods returned to new instance. Um. but to me there's something very intuitive about and maybe it's because I kind of started with Ruby and then came to Jove script. I'm not sure

 

Charles_Wood:

Hm,

 

Ian_Schwartz:

there's something about you know. The fact that the type of the thing

 

Charles_Wood:

Oh,

 

Ian_Schwartz:

is the same as the. You know. the class name is The type, and being able to introspect things that way that for me, at least just makes a lot of sense. Although I don't think you know, and you know they aren't really classes. they are just a job script Class is just a function with closures on it. So you

 

Dan_Shappir:

And

 

Ian_Schwartz:

know

 

Dan_Shappir:

the prototype.

 

Ian_Schwartz:

that's but that's the preference. Sure, but yeah, that's true, but you can model. You know. you can model the data the same way and create the same a P. I, whether or not you're using classes or or you know regular Function declarations. That sort of you know. that's that's I call that your accent. How you? how you code in your accent right? Is it Ruby flavor job script, or is it you know a script flavor chuff,

 

Charles_Wood:

I'm guilty

 

Dan_Shappir:

Yeah,

 

Charles_Wood:

of that.

 

Dan_Shappir:

I'm kind of forced to use classes at work because we have a lot of angular code and also

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

some nest J S base services, and both of them are big on classes, so I can't get away with

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

it whether I like it or not. But, but going back to your point, I mean

 

Ian_Schwartz:

Yes, please.

 

Dan_Shappir:

the original topic. let's say not your point,

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

M. So you know, I assume that even now a lot of React developers Hearing you talk about immutable data are thinking reducts. So how is everything you're talking about? How is it different from reducts? Especially given that reductis kind of on the decline.

 

Ian_Schwartz:

Um, you know, I think what I'm talking about is sort of agnostic to your particular state management solution. Um, you know what I'm talking about is you know, as the data is passed down through the Igetwelli Guess depends on how you're using reduct. You're right if you're if you're using reducts in a way where you know every component in your app has access to it and can read and write to the store. Then then maybe maybe this won't work with Style. I don't know. I don't really write code that way. I'm kind of elergic to reduct myself. Um, you know, I kind of like the built in state management to react, and I think that if you can keep your state simple enough, you don't have to reach for tools like reducts. M.

 

Dan_Shappir:

Like I said, Redux is definitely

 

Ian_Schwartz:

But

 

Dan_Shappir:

on the decline.

 

Ian_Schwartz:

yeah,

 

Dan_Shappir:

Yeah,

 

Ian_Schwartz:

but but yeah, I mean, you know who's to say you know what you keep in your reduct store could be an instance of a more feature filled model, just as easily as it could be a plain job. The object to my knowledge, I don't know why you wouldn't be able to apply more techniques to

 

Dan_Shappir:

So basically, if

 

Ian_Schwartz:

that.

 

Dan_Shappir:

I'm understanding what you're saying, you're saying reducts is more of uh, let's call it a holistic view or unified representation of your entire state, Whereas

 

Ian_Schwartz:

Sure,

 

Dan_Shappir:

what you're talking about is how to incapsulate specific small parts of the state and represent them in a functional and then use them in a functional way, So regardless

 

Ian_Schwartz:

Right.

 

Dan_Shappir:

of how your containing your state as a whole, when components pass state or data to each other, they do it in a functional manner. Am I understanding

 

Ian_Schwartz:

That's right.

 

Dan_Shappir:

it correctly?

 

Ian_Schwartz:

Yeah, I think so, and you know, even within the context, like when you go to set some state in your redux store, in your redux store, you know at some point you have to describe those changes that you're making to the state, whether it's within your reducer or you know, wherever else that code live, you're making a change to that data in some way, and yeah, uh, you know, the simpler it is to describe that change, and More easy it is to to to look at the various pieces of logic that make up that change. the easier your life is going to be. Um, you know, sometimes when you set data again, I don't really work with reducts very much. I try to keep it out of my projects, but it's not hard to see you know deeply nested spreads. You know an object with a spread, and then that another object with a spread, and then another object with the spread. You know. I want to be able to describe things using methods that you know, lenses. That the method named me Sense, and I know just from the method what product I'm setting, Hat property, I'm setting. And even if I'm then storing that in reducts or in native react state, or you know, in some other construct is almost that. That's almost secondary to me. I'm talking about how you describe your logic

 

Dan_Shappir:

So

 

Ian_Schwartz:

exactly.

 

Dan_Shappir:

if I can, If I'm trying to think of a concrete example, let's say I have

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

a React application, and within that React application I have the name of the currently log in user, which might be null if the user is not locked in, which would result in different in different components, rendering their content in a different way based on whether or not the user name is available or is, not. Instead of passing a string around and then doing a lot of existence checks all over the place, I would wrap that value as a maybe,

 

Ian_Schwartz:

As a, maybe

 

Dan_Shappir:

and then pass it that way around. and then I just you know, render, let's say the stuff that it is dependent on the name either gets rendered

 

Ian_Schwartz:

Right.

 

Dan_Shappir:

or not, and I don't have to use all these if statements in my code. Is that

 

Ian_Schwartz:

But when

 

Dan_Shappir:

The

 

Ian_Schwartz:

you,

 

Dan_Shappir:

gist

 

Ian_Schwartz:

when

 

Dan_Shappir:

of it?

 

Ian_Schwartz:

you, that is the gist of it exactly. you know if you were just storing it as a string or knoll, and then you write in the component, you'd probably write something like. You know. you'd have your angle brackets in your j. s. X, and you'd write. You know. Uh, you know, you put name in it. And if that name was null and you don't handle the null case, then react, I guess won't show anything right. Um, But the advantage of using a maybe is that when you go to eventually unwrap the value and get that value out to put it, And you react, you're going to have to handle both cases. You can't. Um, you know you can't. you. don't you don't want to be in a situation where you could have a null and not have handled the null, and so in languages that are pure, functional, like Elm, or like Um, like Haskell, or even with Rust, you know when you go to unwrap that you're forced to handle both cases, and so with with my maybes, and with most implementations of maybe it's that way as well. Um, so you can't. You can't just ignore the fact that it could be All, which is a big part of the upside of it. If that makes sense,

 

Dan_Shappir:

Yes, it does. Although to, for better or worse type script kind of forces you to

 

Ian_Schwartz:

M,

 

Dan_Shappir:

handle this

 

Ian_Schwartz:

m,

 

Dan_Shappir:

as well. I mean, if you've got a value that you know, string, question mark rather than string, then you kind of need to take care of the undefined scenario. You can't just treat it as a string

 

Ian_Schwartz:

Um, If you're gonna, Yeah, you're going to do something to it. But if you're going to stick it into your S. X, you certainly

 

Dan_Shappir:

M.

 

Ian_Schwartz:

can. It'll take undefined just as well as anything else. You know U. I development. One of one of the hard things about U. development is accounting for all the different states that are available, And so the more prescriptive you can be, I think in the domain modeling, you know, the the less mental. Just like with any other tool with using type script at all, with using linters, with using Um, You know any tool that that takes the power off of your brain and puts it into the code you know. And that's that's kind of what. I'm what I'm advocating for.

 

Dan_Shappir:

I'm totally with you that. if the type system can force me to account for all the different scenarios, that's big advantage. I mean when you know it, type script kind of goes part way part of the way you know.

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

language that are more functionally strict, go a longer way. Also using Colinet work, for example, and it's in it And it's more strict in this regard, and you, you're less likely to have these kind of null errors where you're not properly handling a null or knowledge value. And like you said

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

in React, you can you know, Just pass the undefined on as if it was the strength value. And you, and you know all of us have seen you use where it says, Use your name. Call on undefined Uh, uh,

 

Ian_Schwartz:

Right or high comma. Nothing you know.

 

Charles_Wood:

Yeah,

 

Ian_Schwartz:

Yeah, So I mean, you know, I don't mean for any of this to be prescriptive, or to me, you know to be. but for me this is just a way of thinking about things. You know that it feels a little bit more like putting the square peg into the square hole. Um, and you know, within the context of React, you don't have to write code this quay, but I think it's harder if you know, even look even in pure functional language, you can write imperative code and has Cal. It's just it's a headache to do it and You know that headache exists and react as well, because, because like I said, most of us you know you don't. Most people don't learn functional programming as a pre requisite to learning React, but you know, like I just watched the React documentary the other day and every single one of the people they interviewed who as an early adoptor said, Oh, react at last the way to model my functionally, So you know, there's sort of disconnect because I don't know, I guess, cause it's because it's taken over the world of development and we're all scrambling to Learn at Um, that you know you have these tools as part of it. And and this this paradym that fits so well with it that most of the people working with it have had you know. at best the cursory introduction to

 

Dan_Shappir:

So when you code in, react to

 

Ian_Schwartz:

Yes,

 

Dan_Shappir:

the paramo, Instead of passing simple values around as parameters, your code mostly uses parameters that are effectively either functors or monads And maybes.

 

Ian_Schwartz:

Well,

 

Dan_Shappir:

All right,

 

Ian_Schwartz:

uh, yeah, functors, Mona. absolutely, yeah, almost basically any, any data. So one of the things that helped with developing this is that on my team we have found ourselves in a situation numerous times of developing U. S, where the back end wasn't ready yet. It's just the way it worked organizationally. It's you know. it's fine. but one of the ways that we decided to be robust about that is that every a p I call, rather than storing the data directly and passing Down, we turn it into an instance of some sort of functional wrapper, and this way when the actual api is available, if if our expectations about how it was going to work are different than we thought they were going to be, which has happened right then. The only place that really needs to change is that initial transformation function that wraps it and turns it into this monatic Data type Um. Because that's a thing that's feature field right. So the constructor method migh change dot create static, dot Create Method might change, but we were able to build us without having to think about how the a P. I data was going to look. Um, and that led me to sort of this realization that you know the needs of the a P. I. You decide for communicating. your data doesn't usually match what you actually need to render your turning into something a little smarter. More, uh, feature filled, right, and this is, I mean Ruby. You know when I was doing Ruby on Rails, Right, you know, they have a substraction over the data base called Active Record, where you create a model

 

Charles_Wood:

Hm,

 

Ian_Schwartz:

right that describes your data based schema, but also you know, explains how you know how to work with that data Defines methods. for you know, uh, for for transforming or modeling that data right, turns it into something rich in feature fill. You're not just getting your your Rad. You know, data based out, but you're getting this this thing that knows how to work with itself and that power in a Ruby on Rails, Ap is so comfortable to have, And I want that same power and joboscriptland, right. I want everywhere except for the place where I get the data to have a thing that just knows knows how to work with itself and knows how to describe its own logic, and has it all uncapsolated And this is you know. This is something that comes from object oriented programming. Right, they're not at odds with each other, Fpanopthe, They're two sides of the same coin, And really the only downside about O P is mutability, but the incapsolation and the intelligence of the of the data types is is absolutely worth. Yeah, I try to do that in as much of my code as I can. Dan. You're mute. Are you asking something? Sorry?

 

Dan_Shappir:

Yeah, it's better to ask when you're unmuted. So

 

Charles_Wood:

Uh, uh,

 

Dan_Shappir:

so the question that I have is this? So you said you created

 

Ian_Schwartz:

Yeah,

 

Dan_Shappir:

a library, But you're not really using it in production yet, So what are you using in production? Are you just you know, making sure to add these methods to your objects as as the best practice, or you actually using some sort of library that implement it for you, Or some other tooling that enforces this convention, Or what are you doing?

 

Ian_Schwartz:

The former, We're just doing it as a as a convention on the team. You know, it's a big company and the teams have a fair amount of autonomy, so we're able to write the code in a way that makes sense for us, And so it has been. by convention, I do feel somewhat validated that when people have come on to the project, you know, they tend to get moving very fast, and people Have then asked me for more resource. You know, are then interested in more resources about functional programming Because they found in De bugging something that they knew exactly where to look and exactly where to make the change. Um, so yeah, it's just by convention at the moment. Um, but I, you know, I would love to use shot at work, but I, I don't really think it's there yet. There's a couple of features that I would need to hammer out before I would put it on something I was being paid to work on. I've used it on a bunch of you know, a little personal projects, and experimented with it, and the code that the test coverage on it is close to a hundred percent So M. you know, the tests are also a place where I have. I did a lot of t. d D on it And got a chance to really get a field for the a P. I of it at the time. But yeah, as I said, it's mostly a learning tool. You know, I show it to people with the intention of having them. You know, he was an example I saw in somebody else's talking. I wish I could remember who it was, but they were talking about how how functional programmers think, and you know you can have an array of things and you can write a four loop to log each item, whether you're right, right, or you can write a function that takes an array and then cabpsolate the four loop in that, and then a functional programmer says, Well, What if I didn't want to log those things? What if I want to pass a function as a second argument? Right? And now I have a four each? And Um, You know, I just got to thinking that What if we could take? you know? the four loop was a construct in the language that everybody used, and we figured out how not to use it any more

 

Dan_Shappir:

Yeah,

 

Ian_Schwartz:

by wrapping it in functional programming patterns and including it in the language Right. And what if we could do that for other things like you know, like non existence, Like if something is there, And what if that's a function? we could abstract that. And once you kind of get that mental model and get the power of it, Um, you know it. An, there's a lot Different ways to apply it to data, and there's a lot of you know. you can build a lot of monad type interfaces that you know specific to your domain. It's not, Doesn't have to be a general thing. You apply to everything. It's okay to build up a high level language for describing your logic. Some

 

Dan_Shappir:

M.

 

Ian_Schwartz:

languages pushed you to do this automatically job of script doesn't, but you know I wanted to be just as easy as working with with any other building data types of the language, So Yeah, we try to. We try to keep that in mind at all times.

 

Dan_Shappir:

You could introduce lend rules, for example that enforce this this convention in certain ways.

 

Ian_Schwartz:

That's true. I could. I think that that would be a tougher sell for the team. To be honest, but you know if I ruled, If there's ever a point where I am in a position to do that, I would totally do that. And yeah, how would you? I've never written a leecellent rule. How hard would you say it is to do something like that? Is it pretty?

 

Dan_Shappir:

To be honest, I've not really done it either.

 

Ian_Schwartz:

Uh,

 

Dan_Shappir:

I've

 

Ian_Schwartz:

uh,

 

Dan_Shappir:

I've configureda lint, but I've not actually implemented my own rules. I assume it's not that bad, though I mean a lot of people

 

AJ:

It

 

Dan_Shappir:

are

 

AJ:

is.

 

Dan_Shappir:

doing it.

 

Ian_Schwartz:

Uh,

 

AJ:

It is.

 

Dan_Shappir:

It is.

 

AJ:

It depends.

 

Ian_Schwartz:

uh,

 

AJ:

It depends. So it's bad for someone like me, right? I don't like to have 600 dependencies to do something simple. And the, it's probably better now than when I did it, which was about two years ago at this point. But it has to, because of the nature of the JavaScript community where actually, you know, is in draft, we'll call it JavaScript and we'll call TypeScript and we'll call JSX JavaScript. At the time, it didn't actually support the language of JavaScript. It just supported a bunch of transpilers, some of which were JavaScript, some of which were drafts, some of which have already been abandoned. And so in order to get all of the piping configured that it could be understood. It's like, have you ever looked at the difference? You've seen source map errors, right?

 

Dan_Shappir:

Hm.

 

AJ:

It was like that kind of process where you're trying to get a bunch of plugins to load, to run on some text, and hope that the text is in the right state by the time your plugin runs, so that I didn't understand it, it was hard. But for most people doing simple things is probably easy enough. I was trying to put a rule in place for something about promises or something about, something about some feature that happened to not be at the time required some sort of plugin. And then, you know, and then it was just, yeah, it was, I can't do it.

 

Ian_Schwartz:

I think

 

AJ:

I can

 

Ian_Schwartz:

it'd

 

AJ:

only

 

Ian_Schwartz:

be

 

AJ:

do

 

Ian_Schwartz:

hard.

 

AJ:

simple things.

 

Ian_Schwartz:

I think it'd be hard to model this as a as a linter rule. To you know, I don't have to do a lot of things about how. because you're still going to have react components, they're going to take a string or a number or an object as a prop. Right, Even if you're using this in your code, Um, it's not gonna. Not everything is going to be wrapped in something like this, And so you know, would be hard to do it in a universal way. in my opinion, Um, but it doesn't mean it's not possible. It would just be Very, very, very opinionated code based, Um, maybe more opinion than I want to go for personally.

 

Charles_Wood:

All right Well, I think we're kind of getting toward that time where we need to do picks and start wrapping up. Um, Anything else? you want to just drop in before we're done

 

Ian_Schwartz:

Uh, No, I think I think I think I made some good points. Hopefully, hopefully it wasn't too boring. Steve.

 

AJ:

So

 

Ian_Schwartz:

Yeah,

 

AJ:

I still have the question. What is a monad? What is a functor? And I. What I want to know is if I was looking at 10 lines of code

 

Ian_Schwartz:

Yeah,

 

AJ:

and someone says, ah, you're using monads and I would say, I agree, people tell me that all the time. Which line of this code

 

Dan_Shappir:

Oh,

 

AJ:

is the monad, please? That's that's where no one has been able to answer me that question and I feel like that's

 

Ian_Schwartz:

A

 

AJ:

I

 

Ian_Schwartz:

data

 

AJ:

get conceptually,

 

Ian_Schwartz:

type

 

AJ:

point and say line seven, column five, the variable named X,

 

Ian_Schwartz:

Right

 

AJ:

this is the the monad or

 

Ian_Schwartz:

if it's if it's a data type that has a method on it that implements what they call the mind method, Okay, which, as we said is flat map for a raise, Then for promises, If if you can implement that mind method, Uh, then your data type can be considered to be in the category of mona.

 

AJ:

So a promise in JavaScript as it's natively implemented. So if I just do

 

Ian_Schwartz:

Hm,

 

AJ:

async function return the string hello

 

Ian_Schwartz:

Sure,

 

AJ:

and I run and I call this function greet.

 

Ian_Schwartz:

Okay,

 

AJ:

So if I call the function greet and I do let greeting equals greet invoked, the variable greeting is a monad.

 

Ian_Schwartz:

No, the great function I think would be the monad. I think

 

AJ:

the greet

 

Ian_Schwartz:

like

 

AJ:

function

 

Ian_Schwartz:

you're You're the function that is being assigned to that. Yeah, the function is the monad

 

AJ:

So every async function is a monad because it returns an object that implements the

 

Ian_Schwartz:

Top. Then yeah,

 

AJ:

interface that will have a.then and.then itself is not what a monad is, but

 

Dan_Shappir:

Oh,

 

AJ:

the concept of binding is what makes

 

Ian_Schwartz:

Right,

 

Dan_Shappir:

Oh

 

AJ:

a container, an object, a thing

 

Dan_Shappir:

H.

 

AJ:

binding

 

Ian_Schwartz:

Yeah,

 

AJ:

and the binding must accept a function whether it's synchronous or

 

Ian_Schwartz:

Correct.

 

AJ:

asynchronous

 

Ian_Schwartz:

That

 

AJ:

the binding

 

Ian_Schwartz:

exposes

 

AJ:

must

 

Ian_Schwartz:

the

 

AJ:

accept

 

Ian_Schwartz:

inner value of that data type in some way and lets you operate on it and then returning a new instance of the thing,

 

AJ:

Okay, so

 

Ian_Schwartz:

Right, dot.

 

AJ:

and

 

Ian_Schwartz:

Then you're always going to get a promise out of a dot. Then you're never going to get anything but a promise out of a dot. Then

 

AJ:

Okay, so you you have a type guarantee that it's of the same type so you're not transforming the type

 

Ian_Schwartz:

Right

 

AJ:

But with a map you often are transforming the type so is

 

Dan_Shappir:

We.

 

AJ:

is

 

Ian_Schwartz:

Well, you're always getting in array, though I, you're rit your geting a different array of a different thing.

 

AJ:

Okay, so the the container type is the same type

 

Ian_Schwartz:

Yeah,

 

AJ:

or at least the same interface It doesn't necessarily have to be the same strict type, but it has to expose the same interface

 

Ian_Schwartz:

Brace yourself for angry emails from functional

 

Charles_Wood:

Okay

 

Ian_Schwartz:

programming. nods to

 

Charles_Wood:

right?

 

Ian_Schwartz:

say how wrong I am. I know

 

Charles_Wood:

Well

 

Ian_Schwartz:

you want

 

Charles_Wood:

and

 

Steve:

Eight.

 

Ian_Schwartz:

to get

 

Charles_Wood:

we,

 

Ian_Schwartz:

into Prex.

 

Charles_Wood:

we are definitely at time. What I propose is that we come back and we just dive into what functional programming is. And what a lot of these ideas are.

 

Ian_Schwartz:

Yeah,

 

Charles_Wood:

It'd

 

Ian_Schwartz:

sure,

 

Charles_Wood:

be fun to get into some of the combinators, and you know some of the other things that go into this that people use to explain and explore functional programming, because it gets rather abstract and then breaking it down into because I don't know if I could explain it to a J. You

 

Ian_Schwartz:

It's

 

Charles_Wood:

know

 

Ian_Schwartz:

hard.

 

Charles_Wood:

any better than

 

Ian_Schwartz:

A

 

Charles_Wood:

you're

 

Ian_Schwartz:

hard thing

 

Charles_Wood:

doing

 

Ian_Schwartz:

to explain

 

Charles_Wood:

right, and I'm not sure I understand it completely either,

 

Dan_Shappir:

Wow.

 

Ian_Schwartz:

You

 

Charles_Wood:

So

 

Ian_Schwartz:

using

 

Charles_Wood:

it'd be cool

 

Ian_Schwartz:

is

 

Charles_Wood:

to

 

Ian_Schwartz:

easier

 

Charles_Wood:

just

 

Ian_Schwartz:

than

 

Charles_Wood:

dive

 

Ian_Schwartz:

explaining

 

Charles_Wood:

in.

 

Ian_Schwartz:

it. Using it is

 

Charles_Wood:

Yeah,

 

Ian_Schwartz:

easier than explaining it And I know you want to get on to picks. Can I give my pick Because it will actually help with us two.

 

Charles_Wood:

Yeah, do it.

 

Ian_Schwartz:

All right, So there's a podcast that they're no longer making episodes of Called The Lamb Do cast. There's like twenty three episodes of it

 

Charles_Wood:

I think

 

Ian_Schwartz:

and

 

Charles_Wood:

I've heard of that one.

 

Ian_Schwartz:

it's like for me, it's like required reading for functional program because it's a panel style show. The host is, I think a hahscal developer, If remember correctly, your F sharp one of the two, but he's basically Plaining and talking about functional programming concepts with a few other people, none of whom are functional programming people, and all of whom have different language background. So it's language agnostic and there's twenty three episodes. And if you listen all twenty three, By the end you will know what Mona is.

 

Charles_Wood:

Cool.

 

AJ:

Oh, just... Sam's 24 hour guide to Monads.

 

Dan_Shappir:

Well,

 

Ian_Schwartz:

Put it on. one point seven, five X, and you'll be good to

 

Dan_Shappir:

if

 

Ian_Schwartz:

go.

 

Dan_Shappir:

you're looking, if you're looking

 

Charles_Wood:

There

 

Dan_Shappir:

for

 

Charles_Wood:

you

 

Dan_Shappir:

an

 

Charles_Wood:

go.

 

Dan_Shappir:

interest,

 

Charles_Wood:

Now, it's a twelve hours a knowing monet.

 

Dan_Shappir:

if you're looking for an interesting alternative, there is also on O. They have. Professor Frisby introduces composable function, functional Java script, which I recall is pretty out there, pretty amusing and highly instructive.

 

Charles_Wood:

Awesome. All right Well, I'm going to push us into picks. Actually, self promo. You just raise your hand. If you want to just put somethin out there. You're working on. the people should know about. We'll do it this way.

 

Dan_Shappir:

All I say, I'll raise my hand, and just say that after a very long hits, I contributed something to open source. I've you know, I've been. You know, I've doubled here and there, but I've never been. Unfortunately, a huge open source contributor, but I just had an interesting opportunity, so we're using Promethea at work. I don't know if you're familiar with it. It's a kind of mechanism for Collecting performance related information and then being able to graph it out using too zygrophana. And there's a connector for variety of programming languages and environments, And I looked at the implement, the Just in Javascript implementation, which is called, You know surprisingly from client, and I made it much more efficient. So and then I gave That that little bit of code and you know they accepted it. So here's my contribution to open source. After a long while, The funny thing is I actually have an additional contribution that I'm thinking of handing to them, which is much more complicated. It have a rewrite of everything they've done. I just wanted to see that they accepted the small one before I try to voice the huge one on them. I'm like like here's here's a P. R. I'm only changing All your code Anyway, so that's something I've been doing.

 

Charles_Wood:

Um, sounds good. All right. Well, I am working on actually launching a few of these premium video series. One is going to be on careers. I'm putting one together on Ruby and one on Rails. One's going to be on De Tools, and then I'm working on one related to Java Script, and there is the off chance that I might actually transition to front and development for a full time gig, instead of doing rails on the back end,

 

Ian_Schwartz:

Welcome

 

Charles_Wood:

which

 

Ian_Schwartz:

to

 

Charles_Wood:

I've

 

Ian_Schwartz:

the dark

 

Charles_Wood:

done for

 

Ian_Schwartz:

side.

 

Charles_Wood:

like sixteen years, And so, if if that be Comes a thing that is probably going to be focused on react, since that looks like the direction things are going to go. But anyway, just putting that out there. Um, and yeah, so keep an eye out for that because it might turn into a React series instead of a job script series. Um, all right, let's do picks, Steve. Do you have some picks?

 

Steve:

Yes, considering how much I contributed to this episode, I actually do have some picks. Uh, and I found this one little quote. I was googling looking for descriptions of monads, and found a quote that's used by, apparently used by Douglas Crockford, As once you understand monad, you immediately become incapable of explaining them to anyone else,

 

Ian_Schwartz:

Yeah, that's

 

Charles_Wood:

I love Douglas,

 

Ian_Schwartz:

it's just a monoing. the category

 

Steve:

M.

 

Ian_Schwartz:

of endofunctors. What's the big deal?

 

Steve:

H, And that's my other non joke picker the week. To the high point of all my podcast episode, My Dad jokes of the week. You know, some of my favorite jokes have to do with grammar and the importance of them, such as the importance of a comma, when you say let's eat Grandpa versus let's eat Grandpa H. Another variety of vashon is, Colin can completely change the meaning of a sentence. For example, Jane ate her friends sandwich, Vers Jane at her friends, Colin, Right, A little cannibalistic there, M. I've often also talked about jobs and how I've got fired from them. In this case I didn't get fired. It was just an interesting job because it was making plastic draculas. There were only two of us on the production line, so we had to make every second count.

 

Dan_Shappir:

H. Oh, man,

 

Steve:

I count Dracula

 

Dan_Shappir:

um,

 

Steve:

Right,

 

Dan_Shappir:

Steve, Do you know why the

 

Steve:

and

 

Dan_Shappir:

bicycle

 

Steve:

then

 

Dan_Shappir:

was lying by the side of the road

 

Steve:

No, I

 

Dan_Shappir:

Because

 

Steve:

don't.

 

Dan_Shappir:

it was too tired.

 

Steve:

Yes. Now I do remember the one. Now that you say I thank you for contributing, Dan. That's awesome. Finally, If rubber comes from rubber trees and sugar comes from sugar canes. Where does chicken come from pul trees?

 

Dan_Shappir:

Okay, okay,

 

Steve:

Right? those are my dad jokes of the week.

 

Charles_Wood:

All right, Dan. What are your picks?

 

Dan_Shappir:

Okay, let's see. So my pick for this week is the fact that another first for me. Well contributing to open source wasn't the first, but it was after a long time, but this was actually a real first. I participated in Twitter space. Actually, I've participated before, but this time I was actually like the speaker on the Twitter space. I was invited to speak On the Javascript jam space. It's a. It's a really good one. They have this whole series of spaces where they invite you know people in the Javascript community to talk about stuff, And they brought me over to talk about, you know frameworks and performance, which is not surprising because you know, Hey, I talk about the the stuff a lot. Um, and it was really a lot of fun because we had as like surprise guests on on this space. We also had the mico, and we had the Theo. So we had you know really interesting conversations about the stuff. It should be available as a recording on the Jovascript Jam website. By the time this podcast comes out, I have to say like that, I real Enjoy the experience of participating in a Twitter space, but the actual interface or our usage Twitter spaces is pretty horrendous. I don't know.

 

Charles_Wood:

I've heard that

 

Dan_Shappir:

I don't know if you've ever actually tried it. It's pretty terrible. You know. just the fact that you have to use your phone. If you want to be able to, you know, record what you say to speak in now, just listen. That seems incredible To me. Um, also, you know, when I tried to play back, it gets stuck all the time. It's pretty terrible. The A P. I, S. the U. I, S, like Total ship. That's all I can say, But the actual experience of participating in one was was great and I really enjoyed it, so that would be my my pick and my second pick. Well, it's the same pick that I picichen, every time. It's the ongoing war in Ukraine, which is still on going, And likely to get worse once you know, as we're moving into summer, and you know the Russians throw much more soldiers and and fire power into this conflict. it's likely to get a whole lot worse. So yeah, whatever our listeners can do for the people of Ukraine, I urge them to do it, and those are my picks for today.

 

Charles_Wood:

Awesome. All right, J. What are your picks?

 

AJ:

Well, I've got some goodies for you. So first, earlier I mentioned callbacks. This is not a presentation I gave. This was a presentation that I was co-hosting. But Travis Barney gives a talk on a specification that I think comes from the RXJS guys. I'm not, it comes, some library that has to do with some sort of signaling or whatever you wanna call it. It's really interesting. It's basically a specification that is similar to promises, but oriented around events, composable events, rather than single instances. So with a promise, the event happens one and you're done. So you wouldn't use a promise for something like on click, because on click is gonna happen multiple times and you want, you know, you use callbacks for that. And with call bags, like a shopping bag, call bags, the idea is that you just in the same way that promises make callbacks composable? callbags make events composable, recurring events composable. And so once I understood that it was at its core, it's something that's very simple that you could put on a slide that's, you know, 15 lines long or so, just like you can with a promise. You can do a full promise implementation in about 15 lines. And callbags is similar, but it works for events. I think it's a pattern that you can at least learn from. And it's not a library, it's not a framework, in the same way that promises are not a library or a framework. There are libraries that implement promises, but if you just put a dot then method on something, if it doesn't fail, then you've got a promise. And callbacks are similar. I also, I was trying to find the tweet where I said, apparently what Douglas Crockford said, that that's where it came from. But while I was looking for that, a while ago, last time we talked about monads with somebody, I afterwards had posted a link to, or a screenshot of Wikipedia where it says, this article is too technical for most readers. And so I just thought it was kind of funny because no one on planet Earth has been able to explain monads in a way that Wikipedia can accept it without a flag. I also am going to pick three books, The Lost Medal. It's the last book of Mistborn Era II. It's got a satisfying ending. It really, things are starting to feel like Avengers and the Cosmere. You remember the Marvel movies where every movie has an epilogue that then ties into another movie and then characters from the different systems within the universe start to come together. metal has got that going on. And so it's really interesting to see the Avengers style crossover, you know, the comic book style crossover happening in a book series where each book is, you know, between 500 and 1500 pages. But Brandon Sanderson is doing it well. So we just, my wife and I, well, we actually, we haven't finished the epilogue yet, but we finished the main story. The epilogue got, we finished that and I thought that was good. I also just finished the knife of never letting go. That's the one that I've been using to fall asleep at night and then I'll rewind it the next night and I've been doing that for a month or two and so I finally 30 minutes at a time have gotten through the whole book and this is, there was a movie called Chaos Walking and it got really bad reviews and I watched a review on it that said basically if they had followed the book it could have been in the trailer was interesting, which is based, well, I won't go into it, you'll have to look it up because it's difficult to explain, but anyway, and so the first book, The Knife of Never Letting Go did not disappoint, it was very satisfied with it. I guess it's too bad that the movie didn't follow the book. And then the last thing is the ballad of songbirds and snakes is the prequel to The Hunger Games and President Snow is an extremely likable character. But I'm very interested to see where this goes because I'm on team snow right now. Who could have thought that? If you're familiar with Hunger Games, he's the bad guy.

 

Charles_Wood:

Cool? Very cool. Yeah, I'm rereading the Brandon Sanderson series. Uh, heading into the Lost Metal. So I'm on Shadows of Self, which is the second and anyway, An, what are your picks?

 

Ian_Schwartz:

Uh, yeah, the land cast. as I said before twenty three episodes really easy to listen to. It's not a boring topic, even though it probably sounds like it should be. And then the other one I picked this last time. Im going to pick it again is his see Pap machines. If anybody out there, If you feel groggy during the day, tired, you snore, you wake up to P at night. You know they say ninety per cent of cases are undiagnosed and sleep apneis an epidemic epidemic, And It's pretty hard to imagine once you get used to not sleeping that way that you ever lived that way before, so I'm just going to pick that again.

 

AJ:

You

 

Ian_Schwartz:

Get checked

 

AJ:

just

 

Steve:

Yeah,

 

AJ:

described

 

Ian_Schwartz:

if you

 

Steve:

my

 

Ian_Schwartz:

feel.

 

Steve:

dad.

 

AJ:

my

 

Steve:

my

 

AJ:

life.

 

Steve:

dad has one. He had issues where he was so tired that he would be at client meetings and literally falling asleep because

 

Ian_Schwartz:

Yeah, I believe

 

Steve:

he

 

Ian_Schwartz:

it.

 

Steve:

didn't get any sleep and once he got diagnosed and got to see Pap, he slept like a log and hasn't had that, hasn't had that problem since then.

 

Ian_Schwartz:

Well, there you go.

 

Charles_Wood:

Cool? I'm going to throw in my picks real quick. Obeys pick a board game. This one I'm gonna pick. it's called The Quacks of Quedlinburg, and you're basically making a potion trying to make sure it doesn't blow up. And the way it blows up, as if you get too many white ingredients, All the ingredients have colors, then it'll blow up. And so you know, the other ones have different effects. The the further you get on your potion, the more points you get, the more money you get to spend. Um. Board game geek ranks it at. Um. I think it was a one point nine nine, trying to look it up, but I spelled it wrong. Um, so here we go. It is one point nine five. So it's It's easy to pick up casual gamer lots of pieces, But it's a fun game, so I'm going to pick that and then M our book club This month, we're reading pragmatic program By Dave Thomas and Andy Hunt, and everybody as been enjoying it, So I'm going to pick that next month. We're actually doing a non code book, but it's very much in line with leveling yourself up on a regular basis. We're gonna read the Compound Effect by Darin Hardy, and then we're going to get back into code books, so keep an eye out for that. I think we might do seven languages seven weeks, and I'll see if I can get Bruce to show up, But yeah, anyway, good stuff. I read Compound Effect and I just loved it and I thought this is a book that everybody needs to read, So we're doing it for the book club. Um, but yeah, I'm going to pick that and then we're moving all of our calendering and automation and everything else to a new system called Pipeline, pro, Um. And you can get a lifetime license for not terribly expensive. I did pick up some of the Adon because it gave me some of the features that I want. Um, but I'm really liking it, so I'm going to pick Pipeline Pro as well, And with that I think we're done, so we'll go ahead and wrap up, and until next time folks max out.