I
Want to talk to you today about programming paradigms so with everybody here for David Nolan's kino last night
Very cool talk a little philosophical
I hope you like that because that's what we're going to be doing today again a little big picture
So a little bit about me. I'm Anjana. I am an engineer at Uber research
No affiliation with Taxis or cars with any kind we do
Data about scientific research funding and I work on developing a custom query language for that data
I'm an alumni of the recurse center which is an amazing programming retreat and community in New York City
I'm also an alum of the outreach II program which is another amazing initiative to get more women and underrepresented
Folks involved in open source at organizations like Mozilla, so Mozilla [Community] member of a moz tech speaker
And I'm more than happy to talk about any of those things
In the hallway come and grab me after if you're curious about any of that, but today
I'm here to talk about the paradigms of programming
The notion of a programming paradigm one of the first times that this kind of came to light in the the programming community was in
1978 when this guy Robert Floyd won the turing award and in his turing award lecture and subsequent paper
he decided to focus on this notion of
paradigms in programming
And I guess when you win a turing award you get to start your paper with a with a quote from the oxford dictionary
Which is something I've never been allowed to do
But he did and he said ok a paradigm is this notion of having an of a pattern or an exemplar an example?
I think pattern is the is the key word here and
he then says
thinking about paradigms more in
How they affect our [programming] so in this paper
He said I believe the best chance we have to improve the general record's programming is to
attent to our paradigm and that's really what I like to run through today
If you get nothing else out of [the] talk, I hope you just get the idea that
It's useful and can help us all become better
Programmers and individuals and [communities] for [us] focus on paradigms and how to [center] that and put our attention on that?
Think about how they affect our code
So this of course brings us to the question. What are we talking about? So what is a paradigm?
this is something that I probably a
Learned code and the cable programmer something that I kind of brought them within and more superficial ways at first and then as I learn
More [about] a different paradigm
I got [into] kind of a deeper dialogue with this question
But actually the first time that I came in contact with this question was not through code at all it was when I was studying
Philosophy as an undergraduate
I was a philosophy major and in our philosophy of science class we read this book called the structure of scientific revolutions
by a guy named Thomas Kuhn
[and] [this] book came out. I think the first edition was around 1960 and in this book
He is a historian of science, and he wants to help us understand kind of how
Science has [made] progress over the years how we have been able to advance the state of human understanding, so you know small questions
and he
sort of centers the whole dialogue around this notion of a paradigm and so he
Frames a paradigm kind of as a worldview a way of looking at the universe a way of understanding the universe
for example we had as a notion of a paradigm as an example of a paradigm the idea of the the
sceno systematic model of the Cosmos like the ptolematic model where we have this model of the universe [where] the
Earth we are like the bright shining center of the universe and all of the celestial bodies orbit us in these
celestial spheres
and so this is as I said kind of a model of the universe that we're in a
Paradigm can be looked at as [kind] of a way of understanding of conceptualizing that universe
and in that sense
It's something that's necessary for us to have scientific progress says [kuhn] that
Until we as a community can rally around a model that we can all agree upon. [it's] not possible for us to
Actually advance our understanding of the universe [he] talks about the pre paradigm
phase of its kind of like pre science where people are
just sort of stumbling around and [when] one person [is] over here doing that and other person is over here doing that but as a
Community we're not able to move forward until we all Rally behind a particular model a particular paradigm
but if a paradigm is [a] model then
It doesn't just contain the idea about what's in the universe. He says it
Tells us also the theory and methods and standards
together
in an inextricable
Mixture so what does he mean here the theory is kind of this this view of the universe what entities make up the universe how?
Do they behave and interact?
But it also tells us not just about the universe that we live in about but about how we do the science that helps us
Better understand that universe and so that's where the methods and standards come in a paradigm also tells us
Which problems are we're solving which questions it makes sense to ask
Which questions are worth exploring and it tells us which solutions are actually legitimate
Which answers are our good answers to those questions?
so this is all wrapped up in the notion of paradigm and
Kuhn talks about this in terms of Mostly you know the physical sciences things like chemistry physics
But these notions apply to programs as well, so if a paradigm tells us in science
What entities make up the universe if we're doing you know cosmology or astrophysics in programming it tells us
What makes up a program what conceptual units is a program made up of how do they interact and it also tells us?
Which problems we need to address as programmers it sort of defines the task of programming?
What do we need to do as programmers given this model of how programs are composed what they're comprised of and which
solutions which parts of you know which
Creations which programs that we write are good ones, so the theory methods and standards are all wrapped up in this
[Worldview] in this Model
But if it's a model, then we also have to remember this this phrase from George box
He's a statistician, and he's talking about statistical models. He says all models are wrong
Kind of a famous phrase none of them are an accurate picture of reality. They're all wrong and
This is where the the notion that kuhn is probably most famous for the notion of paradigm shift comes in
So kuhn says that you know
Finally the scientific community has emerged from the pre paradigm phase of darkness and we found a paradigm
It's a model like the pTolemaic model of the universe let's say and we can do science this way
But eventually we'll start to notice anomalies
So let's say observations that don't really fit [the] model that the model has difficulty explaining things that we have to kind of shoehorn
into the model using complex ideas like epicycles and all kinds of strange [contraptions] and
this happens in programming too right these are these are the types of programs where it just seems in Elegant and clunky and awkward and
It's hard to maintain and hard to read. It's hard to think about these are anomalies and
Once you know if you have one anomaly here one anomaly there you can even make an epicyclic
Trinomial model and you can account for it once in a while
But enough of them accumulate or perhaps some of them are so egregious that
Eventually the scientific community gets thrown into this kind of state of crisis where the model has broken down it
No, longer works. It's no longer helping us advance, and then there's you know
Arguments over which paradigm is right?
There's the adherents of the old model that refused to let it die there's people coming out with competing new models
It's kind of this chaotic period In which not much gets done
until
Finally the community decides to Rally around a new model
And that's where the notion of shift comes in and so then that new model becomes the dominant paradigm
But of course they're all models are wrong
they're going to be anomalies for that one and so we go through the loop again and
again and again
and it never really stops and so the
The example we had before of the [pTolemy] model that eventually was superseded by the copernican Model a heliocentric
World solar system in which the sun's at the center
you know the predicate is like hey wouldn't it be so [much] easier to explain all of these like anomalies like the retrograde motion of
Mars and stuff like that if we didn't have to posit all these crazy epicycles
And we just said well is the suns of the center then it all kind of works out
But these shifts don't happen overnight copernicus came up with this idea
But it was wasn't for you know another couple hundred years before the community had really fully shifted
They say that actually the copernican revolution didn't really
finish or didn't really conclude until Newton came along with his sort of unifying theories of
How everything works together what the universe is made up of and how those things interact?
But of course his model was also wrong
You know this guy came along einstein came along, but actually you know Newton had some good ideas
but that was also an incorrect model there are also anomalies that a different model like relativity can account for
So ok
This has all been you know nice scientific history exploration, but y'all aren't here to talk about
Newton and Einstein [you're] here to talk about programming paradigms, right?
So let's take a look then at the field of programming at kind of our
Scientific or pSeudo scientific evolution and see what kind of paradigm shifts we went through there
So in the beginning there was imperative programming
something kind of Miraculous happened, and we like as a as a species figured out how to
Electrify rocks and like make them do what we want
pretty amazing and in this kind of this first sort of dominant paradigm
we we [conceive] those programs as made up of things like statements and expressions and those combined to create commands that we
human overlords for now give to the computers and
so this is a kind of the to me the sort of the the
crucial
Entity that the imperative programming model turns around is the notion of the imperative statement which is a command?
Do this then do that then do that other thing, so?
Programming what we have to do as programmers in the imperative paradigm becomes saying things like hey
You computer follow my commands do what I say follow them in the order that I give them imperative programs read like top to bottom
Mostly there's a little jumping around, but in general. It's kind of a linear
way of thinking and
So time is important in the imperative paradigm
And so that's where state comes in state being you know remembering values over time how they change over time
This is all sort of central to the imperative programming worldview
so for me the the mental kind of
Visual analogy that I like to use for imperative programming is kind of that of a complex clock or sort of Clockwork machinery?
It's very intricate very precise very amazing sort of when we think [about] how all of these tiny pieces fit together
[but] it means that we have to be very very close attention to every little tooth on every little cog in that machine
Precision becomes extremely important and of course you know the clock is also kind of a good metaphor because time
State that also matters in this paradigm, so here's some imperative code
This is some C. Code C
Is sort of one of the the classic sort of archetypal imperative languages that people still write lots of useful code in
This has just pulled at [random] from the C python
Interpreter, this is a little function it just rounds [up] to
The next highest power of [two] over a number and it reads very much
And it's top to bottom you know do this do [that] kind of fashion?
It's like you to remember this number
Assert something about it something about the input enter a while loop in each iteration do this in this
Check a condition if you condition meet you know jump out [of] the while loop and then return the result do this do that
in that order
[so]
the metaphor of a clock this this sort of intricate
Machinery it's really great when it's working
But as soon as one little thing breaks down in there the whole thing freezes up and so some people found that this started to
Be sort of an anomaly for the paradigm [of] imperative programming that as programs get more complex
They become much harder to manage and one little thing can go wrong and bring down the whole the whole system. The whole eight, so
new ideas for a new paradigm starting to come about
Like for example in the late 70s and early 80s the idea of object-oriented programming with a paradigm that
Started a rather seismic shift towards that way of thinking
so
Object-Oriented programming is still sort of imperative
We're still telling the computer what to do but and we're still paying attention to state, but we're breaking it up into little chunks
So that now programs the universe of programs is no longer comprised of commands
It's comprised of these things called objects, whatever that means objects are kind of like these little units
That keep a little portion of state to themselves, so [we] say hey
you object remember your little portion of the world the state and
The other thing that that's important for a paradigm
We said is not just what entities are out there, but how they interact so these little chunks these little objects they interact
According to people like alan kay one of the founders of the paradigm by sending messages to each other and this is what happens when?
We call methods on each object basically sending a message like hey
Object you have some state that you do here's a here's a method that I want you to
Run on whatever state you have and then give me some response back do something in the world
Maybe change something in the state, but but do something
Based on my message respond as you see fit respond as your internals are telling you to respond
We'll take a look at a little bit later. How that works because this for me was kind of
Counterintuitive. I always thought object-oriented programming with all about classes and [inheritance] and whatnot but it's not really the central notion which we'll come back
to a little bit later
so the the visual metaphor that I like for
Object-Oriented programming is the one that alan kay talks about a lot when [he] talks about the kind of history of how we came up
with these ideas and he and other folks as well, which is
biological really in its metaphor
it's kind of the notion of cells in a body if we think about each object as kind of like a
cell in a larger tissue
I so has its own internal structure have its own
State has its own molecules inside has its own little organelles and things going on that that make it whatever type of cell it is
And it has a membrane that sort of protects
Whatever is inside it from the rest of the world and it received it on that membrane
It has receptors for molecules that are floating around in the system
and so all of the cells together pass these molecules back and forth and they do things with them with their receptors and
this makes a
larger system like a body or an organ function
So object-oriented code
we're probably all familiar with this is some python again pulled at [random] from C python from the from the python interpreter and
We have these things like classes. We have inheritance as I said [that's] [what's] there, but it's not necessarily crucial
We also have we have methods we have this notion of self
We see this Keyword self a lot in object-oriented programming we have this idea of identity of each little cell being sort of its own
beautiful snowflake
And they're all kind of have an idea of who am I and who is the rest of the world I keep everything to myself?
So these are some things typical of the [object-oriented] programming paradigm which we are likely familiar with
Meanwhile
the problem of
the rigidity [of]
imperative programming and the problems created by having to Maintain Complex States also sparked
Working towards another paradigm a different way of solving
basically that same problem, which is functional programming so the origins of [that] go back like even earlier to
Alonzo Church, and the Lambda Calculus in the 30s
but the
As this became kind of more a thing in [everyday] programmers life which now in the last you know 10 years or so we've seen
Like a huge interest in this because [we] found ways to make it efficient the idea that comes
Let's like do things a completely different way let's forget all [about] these
Commands and saying do this do that let's forget about time and state and things like that. Let's beautiful state is dangerous
It causes us a lot of problems
[we] have so many so many bugs and headaches and just like stress in our lives because of mutable state let's forget it instead
Let's conceive of the universe of programs as made up of pure functions
Where pure functions are really safe because all they do is take in some inputs whatever arguments you give them
They do whatever
Complicated computations, or maybe not so complicated computations. They need to do and then they spit out their output their return values
that's all they do all they look at is the arguments that they get in they don't look at anything else about the rest of
The world and all they do is return a value. They don't make any other changes
[they're] kind of like these these little transformers of Data Data goes in
Data comes out and
We can hook them all up together so that we sort of flow Data through our programs which are themselves
like giant pure functions, they just take input and give output and
So the visual metaphor that works for me for this is kind of like a factory
Where a factory gets in like the trucks come in with the raw?
materials and then at the end of the day the trucks go out with the assembled whatever cars in this case and
inside the Factory
We have like something like an assembly line where lots of little stations kind of do one
specialized task and the Data Sort of the raw materials flow through them and get to
Transformed in little ways bit by bit on that assembly line
so functional
languages probably familiar with lisp
This is some scheme
the dialect of lisp they do a lot of things like this like map function right it's very typical of the
Functional [paradigm] where we are taking in a list and we're kind of processing it little by little by applying a function
This f that we've gotten applying it to the first thing in the list
And then cleverly recursively calling myself my I find the map function on the rest of the list
Which then means I apply f [to] the first thing of the rest of the list
and then I
Recursively call myself on the rest of the rest of the list and so on and so forth until I process the whole list like
the whole Assembly line
You know the list has passed by me on the assembly line
So functional programming is actually a kind of sub paradigm or one type of paradigm that falls under the larger
[umbrella] of Declarative Programming and
Declarative programming is usually put in contrast with imperative programming
So if imperative programming concedes of the universe of being made up of commands that we give the computer
Declarative programming says it's made up of declarative statements. It's made up of
Instead of do this do that. It's made of statements like these are the facts this is what I know
This is what I want from you computer, and I don't care how you go about giving it to me
I'm not going to give you in split instructions do this than that
so
The the metaphor that I like to use for myself [for] this is kind of like a logic puzzle like sudoku, and you sudoku fans
Anyway, so it's the kind of thing where you have you have constraints you have like rules and facts about the world so for example
every
3x3 Square has to have the numbers 1 through 9 the digits 1 through 9
every row and every Column has to have those numbers these are like a
Just general facts about the universe it must be done this way and then you have these sort of
Constraints about what what you see like there's a 1 in the top left corner
And you have to work around that to complete the puzzle in this metaphor
You are the computer as you fill this out
and
So the point is that it doesn't matter what order you enter the numbers in all that matters is at the end of the day
You have a solved pSeudo [Ku] grid
And that's kind of what we're telling the computer when we use a declarative language like sequel for example
We just say ok I want some books. I want I care about their titles and their prices and ETc Etc
I only want books where the price is above a certain thing. I want them ordered in a certain way. This is what I want
Go get it for me. We don't tell any we don't say anything about how exactly it should
Retrieve that information from the database we don't say anything if we're asking for you know joins
And we don't say anything about how it should integrate other information
Or how it should perform the ordering process none of that just saying I want this
Please give it to me
[and] another
sub paradigm of declarative programming is like logic programming which makes the pSeudo [coos] metaphor even
Sort of more fitting so a language like prolog for example. I think makes this declarative style even more explicit
We're saying these are the facts about the world you know wanted
[Anna's] Parent Kim the Dennis parent Kim is my parent these are some things I know and then we're saying there are also some facts
About the world like you can you can make deductions in a certain way using certain rules of logic?
Like for [example] x and y [are] siblings if there's something [@z] who is both x's parent and y's parent?
and so then I can say
prolog I want to know is ana [my] sibling and
Prolog will tell me yes
But I haven't said anything about how I want it to make that deduction [all] I've said is this is the scenario
Tell me what I want
Okay, [so] there are a few more programming paradigms than these these are just a couple
This guy peter van roy took it upon himself to write down lots of them not even all of them
these are just the principal ones and
He categorizes them in terms of the concepts that make them up. He gives some you know languages that support them and
Interestingly you know he points out in some of his work on programming paradigms that sometimes paradigms that we think are
really different
[I] think things that we think of as being totally diametrically opposed paradigms really only differ in maybe one or two concepts
So this sort of got me thinking, and you don't have to read [all] this as so. There's links at the end. Don't worry
But this got me thinking, okay? Well, you know a lot of the time
I've been told I [feel] like as especially as kind of you know a
junior ish, Coder have been told a lot of things about these program these paradigms are super different, but
Are they all really that different?
do they have things in common that we're kind of not seeing if we're getting so fixed in our ideas of one paradigm and
I start especially wondering about
object-Oriented programming and functional programming which seem to be like placed in this epic rivalry in
Programming culture that like the die-hard functional programmers hate object-oriented
Methods and object-oriented programmers are like you have schools [grows]
Everybody's fighting each other and saying these are super different, but maybe they have [more] in common than we thought [so]
[be] again the problem that they were both trying to solve
[or] one of the problems were they were both trying to solve was kind of the rigidity and the and the
Complexity of the imperative paradigm [I] wasn't very good at managing
Complexity and the problem one of the problems [on] the main issues that they both take with it is
Shared mutable state so both Hopi and functional programming reject this notion that we should have shared mutable state
They just do it in different ways so functional programming says just forget mutating anything just make everything
Immutable just forget state forget time and then you can share as much as you want you can pass around Data as much as you
want to as long as nobody's changing anything and each function is just
churning out new Data that sort of replaces the old and
Olp also rejected it it just said okay. You know let's
Divide up the state into little chunks little cells that all keep to themselves
so that we're not sharing any of it, and in that way, we'll kind of avoid those problems, so
Going back to this idea about the central the core of the object-oriented paradigm
Alan Kay said in around 1998 that he's sorry that he coined the term objects for
Object-Oriented programming because it gets people to focus on the lesser idea the big idea
He says is messaging right so what we were saying before that these kind of these cells that make up the universe of a program
Send messages back and forth and that's how we get a larger system
So to understand that a little bit better. Let's take a look okay. This is some very very very complicated
object-Oriented code right here
but it usually looks something like that right we have like thing dot method and then some arguments and
in
The way that I 1k would like us to [think] about Okie what we're really saying when we say thing dot do some stuff is
we're sending a message to the object in this case thing and the content of that message is usually the method name and
then some arguments that some data that we want it to do something with
so
Some languages like for example in [Ruby]
Apparently you have the luxury of making that's actually explicit you can either say you know sing dot do some stuff or you can explicitly
Use this dot send
method which shows us that we're really like sending a message to the object where the first thing in that message is a
symbol representing the name of the method that we're trying to call and then the rest is the
Arguments of the Data that were passing along, so here's some also extremely useful [object-oriented] code
Let's say we had a type of object called a friend because we all like to be friends
we don't want to be arguing like the opie and the functional programming people [a]
friend all does is remember that it has a certain list of friends, and then it can tell you whether somebody is a
Friend of me, so if I have a buddy is an instance of friend who's friends with Allen and Alonzo
I can ask you know buddy. Are you?
[friends] with guy and of course the answer is false because I'm not [sure] guys buddy
But when we think about that is South park, yes, oh
When we think about that in the in the message notation that we were just looking at we could replace this call buddy that is
friend of guy with
buddy dot [send] and then
send the message where the the first part [of] the content is the name of the method that we're trying to call and
The rest is the data that we're passing to it
But we could just clean up the syntax there a little bit right like why do we really need that dot [send] [for] if we're?
always sending messages couldn't we just get rid of that and then it starts to look a lot [more] like a function and
so we could actually write our we could create our friend object a
Functional way by representing it at the closure
Because all a friend has to do is it has to when we create it it has to remember its list of friends
Allen and Alonzo
and then it has to be able to tell me for any given name whether it's friends with that person whose name it is so
Instead of having a class definition with you know constructor method and some some object methods on there
I could set this up as a closure where I'm kind of
Remembering by wrapping the context in which the object itself [dude] the the instance is created
I'm wrapping that up into this
Disclosure and then I can pass as an argument just the name of a method in this case
It's only set up to support one method. I can pass that in with whatever arguments and
Get basically the same
Behavior that I was having before so like this is functional
This is object oriented
This is functional. This is object oriented like they're really not that different
And so when we look at this code, this is this is functional right? I mean, it's not in haskell. That's okay
[but] it's all it's all pure function. That's using these very very functional ideas of you know higher order closures, Etc
but in a sense if I look at the bottom two lines, [I'm] a
Programmer I end up having [to] kind of interact with this code in a similar way to what I was using
Whatever used to doing in object-oriented
Programming so this is kind of one [of] those optical
Illusion things [note] that the old lady is that the young girl is at the dock is it the rabbit?
It's like it's sort of both depending on my frame of mind
and that's where we get back into the idea of a paradigm being just a
Worldview a mindset that you're using so this is we could actually like write
Object-Oriented code in the Lambda calculus if we wanted to you wouldn't probably do that
But you could because it's all about how we conceive [of] the universe of our program and what what makes it up?
And how those entities will talk to each other?
Okay, so but then everybody wants to know right especially with this [o] p versus [Sp]
Rivalry which paradigm is the best? Well you probably [guess]?
What answer is going to come up to this and I think David Nolan also did a bit of foreshadowing?
Yesterday, but let's go back to this quote from George box. He said all models are wrong
but that wasn't the end of the quote [these] of all models are wrong, but some are useful and
This is really the main idea paradigms are useful in different ways
So going back to [our] Newton versus einstein thing like there is a sense in which Newton was wrong about
The universe and his model
Maybe doesn't match the universe as closely as Einsteins model
But that doesn't mean that we need to throw out newton's mechanics entirely. It's still super useful for certain situations like
Dealing with things on the surface of the earth that aren't going very fast building bridges. You know sending [rockets] to
Places nearby we can do all of that stuff using the Newtonian model. It's still very useful and in some sense
[it's] probably more useful to think about cars, and you know a
Apple falling out of trees in the Newtonian paradigm
I'm then thinking about them as being able to be converted to energy and whatever and thinking in a kind of Einstein [ian's] way
depending on the problem
You're trying to solve the old model might still be very useful and so peter van roy the guy who made the paradigm diagram also
comes back to this idea
He says each paradigm supports a set of concepts that make it the best for a certain kind of problem
So these little bundles of concepts which are our paradigms
They are all particularly well matched or particularly poorly matched to certain problems
so it's really just a matter of matching up your problem that you have with the best paradigm for solving it [and]
George box says that you know then the question to ask of a given model, isn't whether it's true because you know it's not
But you can ask is the model illuminating does it tell us something new does it give us some
Some insight into the particular problem that makes it easier to solve and sometimes switching your paradigm
makes a problem that was impossible under your old paradigm super trivial under the new one, so
[then] this brings us to the question of what can a paradigm teach us as programmers
what can you teach us as a community of programmers and what kind of teach us as individuals and
Each paradigm kind of has something unique to contribute to the dialogue
so I think that imperative programming is a really great teacher of how to be explicit and how to focus on and understand the
Implementation as being crucial to the particular program, so that's why you still see
You know a lot of really really important especially like performance critical code written in this imperative paradigm because it
Forces you to think about those very very precise
small
Changes that need to be made for the implementation to work
So for example. This is [something] I ran into Hawaii. I gave a talk last year at Europe
I thought about a strange little thing I found out in python
did you know that in python if you have a for loop like on the left here for look that doesn't do anything useful but
It does it a lot of times if you put that inside a function
and you [call] the function that actually runs way faster than if you just
execute the for loop in the global context
So I thought this was sort of weird and as an object-oriented
Python programmer I was looking at these two pieces of code and was like I don't see the difference if anything there's like more lines
on the on the right side, so
Shouldn't it have more to do it has to like create a function object and yadda yadda
But if you think really imperative ly about this and you drill [down]
And you actually look at what the [C] python interpreter is seeing
If we look at the byte code that we disassembled for each of these these code objects you can actually see that
There's a difference
so
The the python code on the left is using some kind of action called store name and load name and on the right
It's using something called store fast and load fast which must be faster
It's in the name
but it turns out that this is because you know [python] has this the solution everything's an object and whatever and the
Objects that it's using to represent these
These values are different so on the left hand side just as a factoid about python in the global context we don't know how many
Variables are going to be declaring a program
So the global context has to be big it has to be this big [dictionary] that [it] kind of remembers anything we throw at it
But when we define a function on the right hand side
The function body already contains all of the variables that it's going to contain it's we know exactly how many values are going to have
to remember there so we can pre allocate a little array for all those values and then when I need to go retrieve one of
Them it's just a really quick. You know Index lookup into there, so the the
difference in these is not something that the high-level python sort of
Way of thinking this object-oriented way of thinking was able to help me understand
I had to go down into the details and if you're interested [in] this kind of thing and how like
Getting really nitty-Gritty into the details of the implementation can help you become a better programmer. I highly recommend that you check out
Julia Evans [works] because she gives lots of great talks and writes really cool blog articles and Dean's about all the amazing Wizard
Magic you can learn by doing this kind of imperative exploration
okay, what about
Declarative programming this is kind of the counterpart the yin to imperative programming the yang or vice versa
If imperative programming teaches us to be explicit and get nitty-Gritty into the implementation
Declarative programming teaches us to get really abstract and to really think more about the domain
And the big picture ideas that we're trying to represent in our program and not how they're implemented
so
Martin Fowler II spoke [yesterday] has a great book called domain-specific languages where he talks about this idea of having kind of a
Better domain model of what it is you're trying to do that that can sometimes make your life as a programmer and especially
Your your task of communicating to let's say your clients a lot easier when you have code that looks like this
So this is a Java code in which we have an embedded or when he calls an internal DSL domain-specific language?
Where we are focused on?
representing calendars and the things that they have like events which have dates and times and location and
[somewhere] we also have a bunch of Java code that's
telling the telling us exactly how
We're remembering those events and exactly how we're associating various bits of Data with them, and how it's all implemented
But that's not important when we're thinking declaratively what we want to be thinking about is like really the big picture
What am [I] trying to do here? I'm trying to represent a calendar
I'm trying to represent events and this can be sometimes a much easier way of thinking about certain problems when the
Implementation is [not] what's at Stake. We can change the implementation
But the the big picture stays the same
So really having both of those
mentalities both of those
worldviews they complement each other we can switch between them to do whatever is necessary for the particular problem at hand and
the same is true of object-oriented programming and functional programming so if
Object-oriented programming teaches us you know this idea of objects of kind of cells that I'll communicate with one another
Sometimes this can be a better fit for a particular problem then even an amazing program like functional programming
So this is from a cool article by Eric fellows whose name. I probably just very much mispronounced. Sorry
It's called y [oo] [p] matters in f sharp, so he's an f sharp
Co-direct Sharp is a really interesting language. It's like Ml inspired functional programming, but it also supports
Object-Oriented programming is kind of a generally secondary paradigm
and
So he's saying okay if we're trying to make an api which has to be kind of aware [of] some sort of context of Diff
and dependencies that I have typically as a
Functional F-Sharp programmer my first instinct would be to do what's on the top here?
Which is to have a module where we have a bunch of different function?
But each [of] those functions have to know about the dependencies that we pass them all [Anna's] arguments
This is sort of okay
If you have just a couple of things
but as you get more and more dependencies and more more functions as things get more complex this starts to get really ugly and
Inelegant and kind of hard to to keep track of and it stops being the best fit for that particular case whereas
Since object-oriented program is all about interfaces. It's all about kind of this like Molecule Membranes that
Take inputs and give outputs
Perhaps object-oriented programming is a better fit for this problem where we could just define an api that you know when you construct it you
Pass in the dependencies once and then all of its methods kind of know that from their internal encapsulated context
so this is just an example of how you know sometimes bringing in a little bit o p into your
Functional code can also sometimes be a good idea and of course it works the other way around as well
functional programming can teach us the mindset of
specializing of focusing on doing one particular transformation to the data like one little station on our assembly line and
Jessica, Kerr actually a couple years ago. I think 2014 [maybe] [I] go to Chicago talked about this
She was talking about how she had this she was white boarding a probably you know a program on her
that she needed to make that that had to deal with deposits and
Payments and kind of pair them up
And she found herself making this really convoluted diagram where she to like go back and forth and say okay
If that happens then we need to loop back over here
And it became really kind of hard to to reason about and also hard to
Understand how as a team they should go though out like putting this together
so she said that one she started when she switched into a functional Mindset it became it sort of
Fell into place, so it became a notion of an issue of transforming data
We have two kind of Data streams coming in they get filtered in certain ways
They they get merged together and then they go to a store and each of those things is like one little transformation
That we can make which we can then break up into chunks as the yellow boxes here, and then I can divvy it up
She says you know I can divvy it up to my team
[members] and everybody has you know [just] their one little chunks to work on and we put it all back together at the end and
It works great, and the [Whiteboard] is way cleaner like the whiteboard makes much more sense [so] sometimes the functional approach can make a convoluted
what am I trying to do here situation just almost trivial and
So this is this is kind of the take away like none of these paradigms are
Best all models are wrong
But each is best for something each is best at something like all of them are special snowflakes
And they all have their [unique] moments in the sun
Sounds a little hippie dippie, but I think it's actually true, and this is you know what what Peter van was talking [about]
They're kind of like a set of concepts. That's paired particularly well with a set of problem and
So that's why fluid says in his turing a word paper. He [said] that we actually need more
Paradigms he says the advancement of the general art of programming requires the continuing
invention and elaboration of paradigms
[I] think this is also
What David Nolan was touching on last night this idea that we?
We need to develop new models new worldviews new ways of thinking
So that we can add those to our kind of toolbox
We already have a bunch of you know pretty cool paradigms peter and roy like diagram them all out for us
There we have a lot, but we could always use core and advancing the state of the art of [programming] will involve
advancing our worldviews coming up with different ways of conceiving of the universe of programs and
So if the advancement of the general art means we need new paradigms then the advancement of the art of the individual programmer
Requires that they expand their repertory of paradigms so as individuals we need to get comfortable with all of the paradigms
We can we need to add as many of these tools to our personal tool boxes as possible
so the idea here [is] that
As individuals we should really not get set in our ways. Just like as a the community we should try to
Explore new things like what David Nolan was talking about last night
And one great way to do that is to work in multi-paradigm languages
So like we mentioned f sharps before is a language that lets you pull in a little bit of olp
sometimes even if most of the time you're [in] a functional Mindset and
Other [parrot] other languages like python for example is very
oriented but you can also write it as just scripts and imperative file or you can even do a little bit of functional programming it's
Maybe not the [best] fit, and there are other languages like like erlang for example where it's functional at core
but then the the notion of this kind of actor model all that starts you start thinking in a more kind of
Object-oriented more like cells communicating with each other sort of way
So working in languages that support multiple paradigms is a great way to be able to
Switch between those mindsets and that way you don't have to learn a whole new
Syntax when you want to learn a paradigm you can just try something new out and the language already comfortable with
[okay], so we're going to last on time. So what's the point then for this whole thing?
[basically] [I] point has been this
paradigms enable programming just like paradigms enable scientific progress according to kuhn
we need as a community to be able to agree on a certain model of
programs and a model of
programming and what it means to write programs what it means to write good programs in order for us to get anything done [and]
In that sense the paradigm you use also sort of defines
The task of Programming the the [worldview] that you're in
As we saw earlier it tells you not only what entities make up a program, but also
What type of problems it makes sense to solve and what type of solutions?
It makes sense to bring to those problems, so in that way it defines like what it means to do programming
So this is why it's really important that we
Not fight the paradigms that we work in that we understand them and we kind of embrace them for like their beautiful
Snowflake nests, and we we use them to solve the programs that they're best of the problems that they're best at
but we remain open to
Shift to a new paradigm as soon as those anomalies [start] accumulating and we realize that we're looking at a bunch of really combo
[would] code
That's super hard to understand super hard to [refactor] super hard to teach the new DEv on the team like what's going on in this
Codebase those are kind of moments where it's great to be open to shift to a new way of thinking about it and
The main point is just basically the point that had that [Floyd] made in
1979 which I think it's kind of interesting cuz we don't really have a whole ton of new paradigm since then
[which] is maybe a little bit what David no one was getting at last night, so this is something that we all together and individually
Should be doing is kind of focusing on
This this meta level of like what am I even doing here? What am I conceiving of a program is made up of and?
How am I?
Approaching the task of programming given that model that worldview, so if we can go out of this
Attending a little bit more to the paradigms we use
I'll be happy that's sort of what I want you all to take away
So that's all I had big thanks to the recurse Center community
Especially these folks who helped me put together the materials for this talk and big things to go to Chicago for having me
Thank you
Here are some references to anybody watch
Okay
anybody has questions, or you know just wants to engage in some philosophical, dialogue ah
Technology now we have about five minutes for questions. So if you can stick around
You might even have a chance to ask another one, so I have one here [that] says
Would you mix paradigms in the same system, or is it more a question of picking the right paradigm for this particular problem?
well, I think you know it depends on the
Granularity that we're looking at I personally think that there is absolutely nothing wrong with mixing
Paradigms at a system as long as you know you're working [in] the same in a language that supports them both
It becomes a little bit more complicated when you have to start mixing and matching different
Languages because then you know maybe different people on the team at different levels of comfort with those languages
But let's say you're working in a language like python so and my company for example. We have a lot [of] python and
Different parts of it are structured in different ways and sometimes you find that within a generally
object-Oriented part of the Codebase there are some chunks [that] are really like look functional that are that are very pure and
Isolated and so we can actually do that
We can have an object that does a lot of its computation in a pure functional style
But is nevertheless kind of a wrapped in this object
Interface, so yeah, you can mix them
[click] one here does assembly slash machine language belong to any of the paradigms. Well. I would say that it's imperative I
Suppose, it's possible to conceive of assembly foetid some other paradigm, but I've never really seen it. Maybe somebody else has but
generally assembly code is extremely explicit and has this very usually like when you read the human readable forms of it like the
Python bytecode that I just thought that I just showed it usually has these very command oriented
Phrases right like load this push this onto the stack. Do you know pop these things Etc?
So it has this kind of do this then that and we have to execute it in that particular order
So it's pretty I think it's a pretty good actually a pretty good representation of the imperative paradigm
It's also important to remember that our machines are like stuck in that paradise
They don't have the luxury that we have of being able to sit comfortably
Between different paradigms and different [worldviews] [their] like yet
Tell me what to do and what order. I need to do it in because I am stupid
I [don't] know yeah, so hope that answered that question
Our micro service is a paradigm
Ah-so, I personally think micro services have kind of
reinvented Allen [Kay's] ideal vision of Okey
That's sort of the personal conclusion that I've come [due] that this idea of breaking things up into little chunks
But then all pass messages back [and] Forth together and create a larger system. That's sort of more decentralized in a way
I think that actually kind of fits when you read when you read what Alan kay
writes about
Object-Oriented programming I don't know if I have the reference up there
But he talks it and there's a paper called the history an early history of small talk. Where he sort of
explains his ideas about this and it sounds a lot like what we're doing with micro services to me, so
But then again if you think about like I said you know functional programming and opie
They're kind of a duck rabbit
situation if you ask me and so we can also consider that if a micro service is just responsible for [getting] its input and
Getting its output you could also conceive of it as pure functions, and we're all just you know passing things from one into another
It's all a matter of perspective
That's what we have so far of anyone's has any any any last-minute questions. [now's] the time to [ask] them
No takers all right in that case give it up for Angela, please. Thanks very much
