Press "Enter" to skip to content

Debating the observable pattern – Q&A P1 – Fun Fun Function


hello everyone and welcome to another

episode of funfunfunfun funds angular

node based JavaScript development with

me Matias you handsome today we’re gonna

talk about it’s gonna be great

let’s get started and I have a special

guest with me today

Eric Ryman my Swedish friend hello who

likes I don’t know what you like making

far less serious things back fun little

games and stuff like that indie stuffs

all right so this is kind of like a semi

my vacation episode like thank you it’s

it’s Christmas and stuff so let’s not

make four episodes like just make some

have some fun some questions and answers

that’s right yeah so this is Eric you

like you might have watched the previous

episode where we pair program on Eric’s

game clothes drone and the danger so and

Eric is from Sweden as well as I so it’s

home over Christmas and we’ve spent the

New Year’s together and we’re basically

just bit hangout hungover I guess oh my

god I’m gonna make an episode and like

continue like can’t we just answer some

questions and answers together and it’s

I will answer all your questions about

what the best angularjs nodes are yes

all the notes the notes and whatnots I

love your work Happy New Year Happy New

Year to you too yes but that’s not a

question

that’s not a question but thank you Mike

what do you think of a frumpy I have no

idea what that is functional reactive

programming oh that’s very cool

I could explain it to me as if I was a

child who has never programmed

functional reactive programming like

it’s functional reactive programming is

basically the observable pattern and

then a lot of marketing oh yeah yeah

that’s a good pattern yeah it’s like

yeah yeah yeah you dispatch an events

yeah people listen to it yep and but you

know yeah exactly yes bad sure does not

know who is listening to it yeah

creating a nice sort of flow of

information yeah oh the observer will be

like it’s uh so you know the observable

part there is a thingy that you can

subscribe to I think I can observe it

yeah and functional reactive programming

is that you stuff like a chain of

functions after the observable like for

instance like at the upper part it might

be like a function that points down to

an observable and it’s just a chain that

observes each other so the interface

constantly reacts so basically it’s

interesting that you how you describe it

so basically it sounds like there is

something being observed and I’m

guessing so what so one of the patterns

that come up all the time it’s like

model-view-controller yeah I hate this

pattern but it is usually should talk

about well in game programming yeah but

but it’s a useful pattern I think just

for talking about you know clarifying

what you’re talking about like even if

you don’t use it yeah

for example the thing that’s often be

observed in it is the model right yeah

that’s the thing where you know that’s

where your data is that’s where the

truth of what is happening you know is

based and like a value changes or

something like that and then like it

cascades to yeah you know the system

reacting to it right yes so so it sounds

like what functional reacting are the

reactive programming is all about this

foot is like is part of the key kind of

cool thing

as is it that you sort of data drive or

specify in some sort of high-level way

how are you gonna react to this

observable change or is that just it’s

kind of like the promise of it is that

you can program a lot more Detlef it

declaratively like there is state and

you just depending on what the state

looks like I have rendered this IC so I

think that I have this I have a

colleague that Philippe that meant

yesterday he talks a lot about how

people don’t understand that the

observable pattern is an optimization

it’s not an architecture like because in

you know in getting programming where

you have in game programming the way I

understand it and we’ll put like it’s

very much and much focus around the run

loop like the necessarily true and I

think I think beginning programmers or

like beginning game programmers it’s

like yeah you have a run loop and you

imagine it’s just being like one big

loop yeah but that’s not how you write a

game though Oh interesting I mean it’s

like you have you know the same concept

of oh you know there’s like an object it

starts there’s an update function like

that’s the that’s the loop part of it

yes I see it has the update function

that runs all the time oh right yeah but

it’s like there’s a million objects and

they each have their own update yes I’m

sure worst they are executed after life

yeah but that’s my that’s what you man

yeah yeah I understand that it’s not

just one big rendering function in the

in like the main but like in in

JavaScript there’s a dome right yes it’s

like an object that you mutate so it’s

not like you have an update you often

don’t have an update function that does

not access but it’s kind of like oh this

happens then I change this yeah yeah

like so I see so so the reactive part

here is that you change something and it

cascades in like yet stuff reacts to it

and other things happen as a result

exactly on the

is the functional part of it is that

it’s just pure functions right it’s just

it gets in the state-mandated renders

renders and output all the time so it

doesn’t really it doesn’t really mutate

anything it always like given a saying

what the state changes and this is like

just how we’re presenting to change

exactly

so sort of like the way this or like an

update function so so in your reactive

functions though can those functions

make changes to the underlying state or

is that frowned upon

yeah that’s frowned upon Oh like that

that will break the entire point of the

pattern but got it but you the thing is

like the observable at the end like the

point of an observable is that the only

dispatches like unchanged right away

need actually has changed right and it

doesn’t know about the rest of the

system yet mech for me I use the

observable observer observable pattern

all the time in that game programming as

well yeah but I mean a lot of the time

the main benefit is that you can have

the observable not know about like say

you have a health bar for a sample yeah

you have a player and the player has

helped I’m going to help changes to

health bar goes down a bad thing to say

would be to say in the player code oh

you know health changed find a health

bar oh yeah that would be terrible it’s

better to be like hey everyone my health

changed I’m a character and I like the

health bar is like Oh someone’s helped

changed it was to player I’m gonna

update myself yeah but the health bar

doesn’t have to be there if it’s not

there just like there’s no

nullpointerexception I’m sure

like that yeah it’s a broadcast right

exactly instead of telling things yeah

and I you know that way you can you know

everything is separated and you can

write really this nice but now that

events like I get that that is awesome

but I don’t think that that is a trait

of the observer per se it’s like that is

that is just you creating a like broad

cost so what I mean like the observer

like the point of the observer

is that it only dispatcher’s changes

when like when it’s actually changed

it’s like for instance looks like you

could implement that pattern by just

updating the state like say like the

health like I got just update the house

here and then anybody who is interested

can just look at that health right it

doesn’t know the you could then have

just this update function that runs

every frame well I’m not sure and then

just looking at that and updating right

problem is that that is extremely

expensive yes you do that sometimes and

then you add the observable in order to

get that to only be rendered when the

state has actually been changed right

and this is this is very popular in in

JavaScript and a web application

specifically because mutating the dome

is experience is expensive like right a

lot more expensive than just pushing

things to OpenGL and programming but I

think that there’s a misconception among

programmers that the observable is an

architectural pattern well what not I

mean maybe this is getting into

semantics but what do you mean by an

architectural pattern what is what is

the difference between a pattern this is

an architectural pattern and a pattern

that is just I don’t know sort of like a

hobo pattern I know you’re like I think

that a lot of people have the

misconception that the observable

pattern

structures your code like but it’s it’s

not like the structure is like that’s

separate from the observable the

observable is it’s there in order to

optimize your code and make it faster so

that you don’t run code unnecessarily

it’s interesting I think that maybe it’s

fair to say that it being faster is one

benefit of using this pattern but I

imagine that you know like as I

mentioned earlier another benefit is

that you’re essentially decoupling the

observer from the observable like or

rather your decoupling the observable

the observer sure like yes it is wrong

to say that either of those things are

true yeah

but as if any programming pattern if you

think that using it will automatically

make your code you yeah well then you

are a beginner and you have to think

more about suffer architecture yeah sure

like the point is like yeah the observer

pattern might might lead to you

decoupling your code we’re like

decoupling the yeah the knowledge about

the rendering and that is great but I

think that the primary that you can

achieve that without the observable

pattern absolutely has its this

specificity about it being oops

like that you can observe and get the

change whenever that is changed right

that exists only for performance reasons

that specific part so this is really

interesting because I don’t do much

JavaScript but I still know this pattern

the observer observable pata sucia and

it sounds like in the realm of

JavaScript the main benefits that

overwhelming benefit is performance but

I think if you bring up like the Gang of

Four kind of patterns in software

architecture I think the opponent is

from going on again right I think so

like it’s this a component of

model-view-controller it’s like a sub

pattern off that pattern so it’s like a

very well-known pattern yeah yeah like

it’s this far you know the view observes

the model yeah okay pretty much that’s

how I was taught it anyway yeah and you

can argue

oh that’s I think but yeah one of the

main kind of things I find interesting

about software development is that these

patterns that you have have you know

they have advantages and disadvantages

and it sounds like in the realm of

JavaScript the main benefit is

performance in the interim of game

programming I mean yeah it’s a small

performance game sure but it’s not that

expensive on update just look at the

model you have a you know you have like

a pointer to the model it’s like an

integer or something you can just look

at it it’s not that expensive to read it

and

an if statement it says if it is

something right or you know yeah it’s

not that bad

um it’s more like benefiting game

programming is more about decoupling the

code but I can mention there’s a

probably another realm of software

development

I don’t know medical robot programming

or something where the observer

observable pattern is maybe it has some

other benefits or drawback that makes

them use it or not like you know a

heartbeat monitor might use it for

example I have no idea what that would

look like because I don’t do that but my

overall whole point is that it is always

a risky move to declare that a pattern

is like primarily not centered around

one benefit because they might be like

depending on the cone yes like pencil

here is the one benefit might overshadow

another but yeah and the focus might lie

elsewhere yeah and I mean I’m not gonna

go into our rant right now but some of

the worst code bases that I’ve seen

professionally in the game industry

they’re you know they’re really over

architected ones they tend to come into

existence because people focus on the

benefits of some pattern but then they

fail to consider the context or the

knock-on effects of like of like using

this pattern and deriving this benefit

model-view-controller is a good example

it is often you know it has benefits

separates concerns change to logic maybe

is good for performance but it also

makes it harder to write you know small

simple primarily like graphics or

physics interactive classes in a

beautiful sort of straightforward way so

it ends up being slower to do that and

ultimately probably not the best idea

but again it depends on the context

sometimes it is the best idea sometimes

it’s not I want to make a tangent to the

fact that this is a generic patterns

even though we are completely different

programmers we can still reason about

the

like we have all different dialects and

viewpoints of the time but I still both

know the pattern we still both use the

pattern yeah and there was this other question about

Please follow and like us: