Hey, a quick message. For those of you who are
listening to this episode on Spotify.
I have a small favor to ask Spotify.
Now allows mobile users to rate podcasts.
I would really appreciate it. If you can take a quick, pause
to go to the technique Journal podcast page, and leave your
favorite show. Your best rating on Spotify.
It will help me a lot to get this podcast to reach more
people on the platform. Thanks a lot.
You're good examples. If you have someone in a really
fast car like a Ferrari and you have someone else in a Bicycle,
the Ferrari is faster. But if you go in the wrong
direction, the bicycle is better.
If you're trying to get to the right place, a bicycle might be
better. So, I see a lot of people in
programming we talk about velocities.
We're talking about how fast can we do things and there's nothing
wrong with that. I mean, it's good to improve
your processes to make them faster and more efficient is
good. But sometimes people lose track
of was even more important is doing the right thing in the
first place. Hey everyone.
My name is Henry Surya with Robin.
And you're listening to the technology, you know, podcast
the show where I'll be bringing you the greatest technical
leaders practitioners and thought leaders in the industry
to discuss about their Journey ideas and practices that we all
can learn and apply to build a highly performing technical team
and to make an impact in your personal work.
So let's dive into our Journal. Hello again, to all of you, my
friends and listeners. Welcome to a new episode of the
fact that Janelle podcast. I am your host Henry Surya Vera
Wang. Thank you for tuning in
listening to this episode. If this is your first time
listening to technology, you know, subscribe and follow the
show on your favorite podcast app and social media on
LinkedIn, Twitter, and Instagram.
And if you are a regular listener and enjoy listening to
the episodes, subscribe, as a patron at Tech, did you know
that laughs? As Patron and support my journey
to continue producing great technology, new episodes every
week. Many of us may think that
implementing domain driven design means using
object-oriented programming and paradigms, especially when
looking at some of the DD technical design patterns and
some of us, especially the functional programming
practitioners, May wonder whether functional programming
can also be used to implement domain-driven design.
And if so how we can do that properly.
This episode tries to provide you some answers to that
particular question. My guest for today's episode is
Scott Russian. He is the author of domain
modeling made functional and the popular F sharp sight.
F sharp for Fun and Profit.com in this episode Scott began by
sharing his view of the need for developers today.
To become more polyglot developers and learn multiple
programming languages as someone who learns a lot of programming
languages and even being really good at five to six different
languages, Scott provided some great insights on why we should
try to at least learn and practice more than one language.
Scott then shared about functional programming
fundamentals and how functional programming differs from
object-oriented programming, as well, as sharing some cases when
one is better suited than the other Scott, then explained how
we can use functional programming.
When implementing domain driven design, including how to model
some of the DD technical designs and Transaction boundary
throughout the conversation. Scott shared why F sharp has
become his favorite and go to programming language and why he
thinks it may be better from the other available.
Functional programming languages, towards the end of
our conversation. Scott touch on important advice
about Effectiveness versus efficiency.
And what leaders need to be aware of regarding doing the
right thing versus doing the thing fast.
I really enjoyed my conversation with With Scott learning about
functional programming, how to apply it in domain driven
design, and a good reminder about the importance of
Effectiveness rather than efficiency, and I wasn't really
aware that F sharp is actually now available outside of windows
platform. If you also enjoy and find this
episode useful, please share it with someone, you know, either
your friends, or your colleagues, who would also
benefit from listening to this episode.
Also leave a rating and review on your podcast app or share
about this. Out on your social media
platform. It is my ultimate mission to
make this podcast and the knowledge available to more
people. And you can play a part towards
fulfilling my mission. Before we continue to the
episode. Let's hear some words from our
sponsor. Today's episode is proudly
sponsored by skills matter. The global community and events
platform with more than 100,000 software professionals here
members, can organize their learning experiences around the
technology topics that Care about most you get on-demand
access to their latest content thought, leadership insights, as
well as the exciting schedule of tech events running across all
time zones. So where the devops our data
science is your bus or you are fan of functional programming or
all things Cloud. You can make real connections
with people who share your interests head on over to skills
method or Cam to become part of the tech community that matters
most to you. It's free to join and you will
find it. Z to keep up with the latest
tech Trends. Hello everyone, welcome back to
another new episode of the packaging of podcast today.
I'm very excited to have someone with me, is name is Scott
Russian and he is actually the famous author of the book domain
modeling made functional. So if you are into domain-driven
design and also into the functional programming, I'm
sure. Maybe you have heard about this
book. He's also the creator of popular
F-sharp website called f sharp for fun.
And Profit.com, the name itself? Sounds really fun.
So got really looking forward to have you in the show today and
looking forward also to learn more about functional
programming and maybe also domain-driven design at the same
time. Well, thanks for having me
Henry. It's nice to be here.
So Scott, maybe in the beginning.
I'd like to always ask my guest to introduce themselves and also
to tell us more about your highlights or turning points in
your career. So I'm quite old, I've been
around since the dinosaurs. So I first started programming
back. The 1980s that so old I am,
that's when everything was still in black and white.
The very first computer I ever used, was actually a CPM machine
before dose, even it was a kaypro and it had two floppy
disks and now hard drive, very exciting.
But, you know, it's amazing. What you can actually, learn
given how nowadays, we consider these machines really tell, but
you can learn a lot mean. I learned all my programming on
this machine and the first program I actually used was
debase to, which was The Microsoft Access of its day or
the fox probe its day. It was like everybody used it
for doing database. Programming ahead of a
programming language, you're scripting language built in.
So I started programming database and I actually end up
writing some really quite complicated things and it will
fit on one floppy disk or two floppy disk.
And then, of course, this is pre-internet.
I used to be a big subscriber of all those computer magazines
like B magazine. Dr. Dobbs journal.
And my favorite one is actually called computer language, which
is all about computer. Languages you get introduced to
all these interesting. Things that you would know
about. So, I learned prologue and I
learned small talk and I learned a language called icon, which is
sort of a predecessor of python. I played around with all these.
You could basically get floppy disks with all these programming
errors on it and a funny sort of way because there wasn't any
standard language really people would experiment.
There's a lot of experimenting people try all sorts of stuff
and I think nowadays people actually do less
experimentation. There's so much to learn.
You can spend your whole career just doing JavaScript or Java or
c. Shot.
So you'd end up not experimenting with all these
different other things. So, there's actually great for
me because I learned all these interesting things.
So I actually got a job doing Small Talk programming back in
the early 90s. This is pre Java.
So, small talk was actually used by Banks and insurance companies
and these big corporate businesses.
They thought the small talk was gonna be their Enterprise
language. So for a couple of years, it was
and then the internet came along and Java came along and small
talk basically died. So then I switch to using
python. Python program for a while.
And then I switched it C sharp when dotnet came out in 2001 or
2002 study, using C sharp. Then back 2010.
I started using F sharp and so F sharp.
I've really loved ever since that's been my kind of main
programming language ever since, although I still do bit of C
sharp and I still do Python and if I have a contract that's
going to pay me a lot of money that we use whichever language
they're paying me to use, I would say back in the early
days. There's a lot of creativity
around learning programming languages.
The The big thing I did and this is what I would recommend
everybody is again back about 10 years ago.
I started doing my blog but if shop for Fun and Profit and I
did that originally, as a way of teaching myself, F sharp.
The idea is, I would try to explain it to somebody else, you
know, there's a static thing. If you try to explain it to
somebody else, it forces you to learn it really well by
something. I already knew.
And so I thought I'd do that and every weekend, I would write a
blog post about something in a shop and it turned out a lot of
people found. It really useful, not just me
and It turned out to be really quite popular blog.
It still is quite popular blog. And so that's nice.
I would recommend anyone if you're looking for career advice
is to do blogging or something, to make yourself, stand out from
the crowd, having a Blog, a big, an expert in something doing
conferences. These are all good.
Career moves as well as being fun.
I really enjoyed writing the blog and it was very good for my
career as well. Right now.
I'm just doing a mixture of writing books and doing
contracts with people, and that's how I make my living.
Thanks for sharing your story. It's since a long time ago, even
I Unborn their tithe. It is a long time ago.
Yeah, it's really interesting to hear that last time, there was
not even a hard disk, and you mentioned that you have learned
so many different languages, right?
So maybe if you can count 10 20, like Chennai, will probably say
this five or six languages that I'm extremely good at including
sequel. I did also act as a SQL DBA for
a while. So I'm pretty understanding of
how SQL in relational databases work, which I also think is a
useful skill for any developer. Yeah, I would say it's probably
five or six languages are very Open the apps and a couple other
ones I could probably do. If I have to, I'm not really a
JavaScript expert but I can hack it if necessary.
First. I don't identify Myself by a
language. There's some people say I'm a
Java developer. I'm a c-sharp developer.
I think of myself as a developer.
I've solved problems the language that you use to solve
the problems. It's not that important.
It does actually make a difference.
Different languages do make a difference in how you think
about the problem, but I'm not particularly bothered by having
a language debates about which is the best language and all the
stuff is just going. Trivial really one of the topics
these days that is very hot. Right?
Whether you should be a polyglot developers or not.
So coming from your background learning so many different
languages and even expert, five to six different languages that
you say. You can be really good at all.
Why do you think developers should think about being a
polyglot developers? I think the first of all,
there's a couple of different reasons.
The first one is that the more different languages, you know,
it makes makes your toolkit bigger.
So if you think about, if you're a carpenter, you have a hammer
for you. Also have a Driver.
And you also have a wrench and you also have a drill and you
have all these different tools and you use the right tool for
the job. A carpenter only ever used a
hammer and never use a screwdriver would be a very bad
confident. And so, it's the same thing with
programming. I think different programming
languages are different tools, and they have different ways of
working with the tool. So if you sequel, It's a
completely different way of thinking.
Then if you're using an imperative language, like C
sharp or something, it basically changes the way you think about
programming, so it expands your mind.
So for my purposes, Personal point of view.
It's very good. And then just from a practical
point of view, the more languages, you know, the more
job opportunities you have that's another thing.
But also when you do work on a job as a contractor, you can
just walk onto job and do not going to be complaining that you
don't like the syntax or you don't like the style or you
don't like them do this way, some programmers like to rewrite
everything, using the best way, when I come into a job, what I
call a Brownfield project where the codes already written it, as
a legacy project, leave the code use the same.
Style that the people they're already using do within reason.
Obviously, if it's horrible, you can refactor it.
But basically don't try and impose your perfect Style on
existing code, just adapt to the stylus or do that.
If you've done many different languages, you tend to be much
more open to that. If you had limited experience,
you tend to be much more picky and you say, well, has to be
this way, is the only way I know and this is the way it has to
be. That's not very good as a
professional. I don't think you should work
that way. Yeah, a lot of cases these days,
especially developers who just came into a project.
Maybe they started a new career new company or their consultant.
They join a project. So yeah, definitely one of the
most common remarks made by those new joiners, of course,
the code base is probably not so well done.
We should refactor this, we should rewrite.
And I think you brought a good point that if you have so many
different paradigms and you are familiar with them, and maybe
also good at that. Maybe you can adapt yourself to
different code bases, right? That's right.
The good example. Is I just did a python contract
M4 experience in functional programming and also very
experienced in object-oriented programming.
But for python, I think the right thing is just basically,
at a Chic kind of procedural programming.
And so when I was writing this code, I didn't use a lot of
weird functional stuff. I didn't use monads and all this
stuff, and I didn't use super nested class hierarchies with
lots of inheritance because I think python has a certain style
of working. Yeah.
I have seen people do JavaScript or Python and they ringing
monads or they bring in some wood functional stuff.
There's not fair to the person is going to have to maintain it.
I would say that's not being a professional programmer.
You have to think about other people.
It's not all about what you want to do.
It's what makes life easier for other people.
I would never use Advanced functional programming
techniques in a project where people didn't care about that
stuff. That's not the right way to do
it. Yeah, and also, I saw one of the
most popular tweet that you. Did you mentioned that by being
a polygon developers? You start treating syntax as it
is, it stops being a big deal that you don't being nitpick
about certain writings. Yeah.
The Test example, is Curly braces.
So F sharp doesn't have curly. Braces python doesn't have curly
braces. Sequel doesn't have curly
braces, a lot of programming language do not have curly
braces. And yet I have seen some
developers say, well, if it doesn't have a curly brace, I
can't understand it. Then I just think that's silly.
That's just very limiting. The curly brace does not make a
big difference in the syntax of which that what the keywords are
and stuff. That's not the important thing.
It's about expressing yourself. So, anyone who says that kind of
stick, I just think they need to get out more.
They need to try more different languages and learning.
In a bit, get out of their bubble and try some more things.
So, let's move to the main topic of today, which is aligned your
book dumb in modeling made functional these days.
A lot of crazy about domain driven design, functional
programming as well. A lot of people swear by it.
That's like the ultimate programming language.
I myself come from more object-oriented, programming
background. So, maybe in the first place,
right? Maybe if you can share with us,
what is the functional programming, why people should
maybe try to understand it? And why is it probably much
better in some respects to all people.
So first of all, there's no official definition of
functional programming. My definition is, it's a
programming style where you use functions to do everything in
object-oriented programming. The basic unit is a class and in
functional programming. The basic unit is a function in
function program. If you want to change the
behavior of something, like the strategy pattern you pass in a
function, if you want to compose a bigger set of functionality,
you combine two functions together, basically everything
you do is functions, you take these functions and you Chain
them together, typically into some sort of pipeline.
You might even have a function where the input is a function
and the output is a function. And so you might call that a
function Transformer. So you basically have some kind
of function and it doesn't do what you want.
So you want it to this function Transformer and it turns into a
different kind of function, which does do what you want.
So it's just a different way of thinking about how you build
software. Another part of functional
programming is also, immutability is typically the
default Behavior because in a classic mathematical function
things don't change. When you say two plus two, the
number two doesn't change when you add something to it.
You've got a new number back. You don't change the original
numbers and the same thing with dates when you add time to a
date, you don't modify the original date.
So if you apply that logic to everything, that nothing changes
and you always create new things.
It makes understanding the program a lot easier because you
always know that the things that you've worked on, haven't been
touched, and you've always got new things to work on.
So, the combination of work using functions everywhere and
having immutability. It's a very hard thing to get
your head around when you first start learning.
Programming. It's really, it's weird.
I mean, when I first started learning I've shot by was
thinking, how can you write any code?
When everything is the musical? That's just not possible.
And then, yeah, if she turns out, you can and turns out
that's not too hard. And then how can you do things
without using classes? How many wider program with you?
You see classes and methods? Well, it turns out you can, so
it's definitely another way of expanding your mind.
So why is functional program? Now?
Like I said, I love of Georgia programming.
As I said, I used to do a lot of small talk, then I love small
talk, but I think from Modern. Enterprise programming,
specially, functional programming because of this
immutability and because the composition, there's no
inheritance and so, everything tends to be very explicit.
Every parameter is passed in explicitly with class based
programming. There's a lot of implicit code.
I mean, you could have a methods with no parameters.
It returns void and has no parameters behind the scenes.
It's doing things because it's using instance variables or
something, but you can't really see what it's doing.
And that's the whole point of all going to probe.
The whole point of object when it is encapsulation.
You're supposed to I doubt it's working, but I think functional
programming is the opposite, the ideas.
Everything's transparent. Everything is exposed.
There's no hidden data, and you might think well, that's a bad
thing. There's no hidden data.
But again, if everything is immutable exposing it tends not
to be that bad because you can't change it.
Obviously, things like apis as a different thing in general, when
you're coding, if everything's immutable, it doesn't really
matter. If people can see the internals
of an object because they can't change.
And one aspect of immutability that I understand as well.
Right? So if everywhere it's immutable,
it also supports For concurrency really?
Well, so you don't have side effects and you don't have to
worry about multiple processes, accessing the same instance.
Yes. Exactly.
Although I have to say it's a little bit overblown.
But I mean, that was one of the things they hyped up about
functional programming, is it to concurrency really?
Well, they did processing really well which it does but even if
it didn't I don't think that's the main reason to use it.
I think the main reason is because the programs that you
write with functional programs. I think they're just going to be
a lot clearer and easier to understand sometimes with
objects. To get what I call object soup
where an object is talking to another object which is talking
to another object which is talking to the first object.
All these objects are talking to each other and it's really hard
to disentangle. Them should ever debug something
like that. It's really painful.
There's nothing in object-oriented program that
stops you doing that. There's no pressure.
It's always easy. Just to add another method.
Functional programming is somehow.
It doesn't quite do that because the pressure is to keep things.
Simple, when every single parameter is passed in, it's
really hard to have 100 parameters.
There's a natural pressure to keep things simple and make
small components that are glued together.
Heather. So, again, about concurrency
stuff. I just think function program is
a really nice technique. That's not the only technique.
One of the things I like about our shop is it actually has an
object-oriented component as well?
So you can actually choose, which ever is the best Paradigm.
Sometimes I'll get audited, is actually the right Paradigm for
certain things. And so it's nice to be able to
have a language which supports both and you can just switch
between them. But typically I would call
myself a functional first program in, which is I start by
doing functional and if that doesn't work properly or it
doesn't feel right then, I switch to When do you see this?
As the Tipping Point when you started as a functional first,
but then what made you switch to the ob Paradigm?
What do you think are some of the good problems with to solve
my old pee? Well, if you really talk about
Behavior, if you really do want to encapsulate, if I have a
bunch of things and I don't care about the data.
I only care about the behavior, then that's what LLP is really
good for. If you think about agent BAE
Systems, agents are basically oop just very similar model,
especially if you're doing a user.
Face or something of your origin.
Interfaces is so nice thing because, you know, they're
button class and a listbox floss and I think they all have
basically the same behavior you want to click on them.
So that of your origin program is wait for that.
Graphical, programming objects are great for agent, based
programming the goods. Sometimes I say where you have a
kind of plug-in model and you don't actually care how its
implemented. So it is useful.
In those cases. I do mix and match between the
same piece of code. And sometimes you really do want
it. Sometimes it's really nice to
have inheritance occasionally not massive deep in her in the
street. They sometimes nice a base class
with a couple of sub classes that inherit from it.
Sometimes it's just nice to have that.
So in domain-driven design most of the literature that I read
actually they used the or Ps. Ml sample reference, you and
came out with a book domain modeling meet functional, which
is kind of unique in a sense. So what made you think that the
domain modeling can also be solved by functional programming
Paradigm? This is very interesting because
you're quite right, that domain driven design is not attached to
any particular programming. In Paradigm, it really shouldn't
be domain-driven design. The idea is that you focus on
the domain instead of the technology.
So you try and focus up, use the words from the domain.
You try and model The Domain in the code.
And you try not to contaminate your domain with all sorts of
technical stuff, which is not relevant to people.
So the got nothing to do with which programming Paradigm use.
But one of the nice things about functional programming is
because in object order program, it's very easy to have a lot of
extra complexity or what people ceremony, extra stuff like that.
Sauces and all this stuff, and it's quite easy to end up with
code, which has a lot of stuff in it, which isn't really part
of the domain. So, you have a base class.
We're in the real world. You don't have base classes.
You don't have proxy classes. You don't have manager classes.
You don't have interfaces The Real World objects do not have
that in functional programming. It tends to be a lot simpler
because ocean foam doesn't have classes.
So then that stuff happens, it basically has data and it has
actions on the data. I think also lot of people, when
they do domain with a focus on the data side of things, And you
often have database driven design where you start with the
database tables and you work back from there.
I think what's happened is people have realized in what
businesses care about analyzing a real system.
It's the events. It's the actions.
It's the workflows the activities.
These are the things that are actually important and the data
is just a way of transferring stuff.
But the activities you want to model an activity.
You can model is something with an input, you send me this
letter and I do this action. You send me an e-mail or you
create this event and I do something.
A function is Jackie, that's an input and output.
So functions are actually very good for the main model.
Now, there's another thing which applies to certain functional.
Programming languages namely the statically typed ones.
So not things like closure, the things like F sharp a camel Elm.
They have a type system, which is very different from an object
oriented type system in the functional.
Programming type system. This is called an algebraic type
system or a composable type system.
You can actually build bigger types from smaller types in a
couple of different ways. But one of the ways you can do
it is you can do it as a choice. So you could say this thing is,
a choice between this thing or this other thing.
Think of it, kind of like an enum.
The glorified enum. I mean most audio two languages
do not have this. It turns out this Choice
modeling is super important for most of Maine's.
If I say, I'll send you an e-mail or I will send you a
letter that's a choice. I want a model that choice and
it's actually surprisingly hard then obviously to language and
you can have two different subclasses, but it's kind of
painful in a functional language with an algebraic type system is
actually really. See, so a lot of my book is
actually talking about modeling things with the type system,
just modeling things as choices, and then as record types, which
is very common and then these functions with inputs and
outputs. So I think there's a very good
match for functional. Programming, one aspect of the
domain driven design is actually what they call tactical design.
So, these are things like design patterns commonly used in DD
things, like entity aggregate value object service repository.
And there's so many others and normally they kind of like being
modeled as Opie. That was also the Paradigm that
stick to it my head. So when you implement those kind
of tactical design in functional programming, maybe you can give
some examples. How can you really design at the
d-class of an aggregate class in f p?
So a lot of those things I think do, apply only the very object
oriented these low level domain driven design things like
entities language value objects in DD is an object where if you
have a different object with the same data in it, it's the same
thing. So if you have to address, Data
structures and they have the exactly the same address data in
them. They're the same address.
And what's interesting in functional programming.
That's the default in object-oriented programming.
That is not the default in object-oriented programming,
every object is a different reference.
So if you want to make two things equal, you have to
override the equals method and the get hashcode method and all
this other stuff and in functional, programming
languages, that's the exact opposite.
So that's nice. And then in object-oriented
programming entities are considered to be mutable objects
in functional programming. They're not.
Immutable obviously. So really, they just objects
where there's an ID. They have something ID field so
that as you change them they have the same identity.
I don't like having all this. Jargon.
I think it takes away from making people understand these
things, but you can totally do the same things.
Things like the concept of service, which provides a
service. That's not special to any
particular programming language. One thing I should point out
though. Is this repository pattern,
which is used in domain-driven design is actually used outside
of domain driven design, people almost never use that in
function. Going so it's very common in
object-oriented programming to mix up database, access and code
and business logic. You might have an object that
saves itself. You might have a save method on
an object which saves itself to the database.
That's a very common style. This used in C sharp with Entity
framework and with python with Django.
And so on in functional programs that we can be considered an
anti-pattern that would be considered a really bad thing to
do. Because in functional program,
we tend to separate predictable stuff from unpredictable stuff.
Of deterministic code from non-deterministic code.
What we called Pure function is a function that always gives the
same result with the same input. It always give the same result.
So adding two numbers together, always gives the same result.
Now, reading something from a database is not like that.
If I read from the database again, I might get a completely
different set of data. So, in a functional program, we
hate that we hate having unpredictable data.
So what we tend to do in Fontana program is separate anything to
do with databases or file system or network, which And move it
outside the Core Business. Logic.
So we have this Core Business logic in the middle.
And anything to do with the outside world is on the edges of
the application typical examples, you might load up some
data from the database. And then you do all this
business logic and then you save some data back to the database
of the end. So the database stuff is on the
outside and then the Core Business logic is in the middle.
So it's completely opposite from the classic interior
architecture where you have the database layer at the bottom.
In the function program, the databases on the outside, not on
the inside. This is not necessarily a
functional, programming thing. People have been talking about
this in other architectures. There's the ports and depth
architecture. There is the onion architecture
that clean architecture. The hexagonal architecture.
All these things is to try and keep the domain logic in the
middle and keep the rest of the world on the outside.
There's another way of saying which is an imperative shell and
a functional called as taught by Gary Bernhardt on that topic.
So what's interesting is in object oriented.
People have to be encouraged to do this, but in functional
programming, it happens automatically, it's the default
Behavior. So you don't really have to try
and persuade people to do it this because this is really the
only way of doing it. So I think one of the reasons
going back to why I think functional programming is quite
nice, is that there are some languages where you can do
something, but it doesn't really encourage you to do the right
thing. The language can let you get
away with all sorts of terrible things.
So for example, let's talk about C.
So C you can be very cautious with your memory management and
your bounds checking stuff, but the language doesn't work,
doesn't really encourage you to do bounds checking.
There's nothing in it, which forces you to do.
So. It's very easy to make mistakes.
So I like a language where you're really kind of forced to
do the right thing. So a language which is immutable
and doesn't let you do database stuff.
It kind of forces you to keep the database stuff separate from
that Core Business logic. And so that's what I like about
functional languages. They really encourage you to
write code in a certain way. Nothing that you couldn't do and
I'll be Odin language, but somehow it just seems easier
when you're using functional style.
I don't know why that is so I'll be bubble half wrap their head
around these paradigms. I think it makes it intuitive
another aspect that I want to ask.
Because it seems very interesting topic and
domain-driven design is the concept of transactional
boundary in dddd. Advocate aggregate should be the
scope of the transaction. So how do you actually do this
in FP with just now, when you mentioned predictable, pictures
and predictable? Where is that layer for the
transaction part? Well, let me just about to
boundaries of their all into my rooms on the first boundary
this, what they call a bounded context.
The idea of about a contest is you break your program into
subsystems, but each subsystem does one thing.
Well, Well, it's kind of like a giant object everything in the
sub system uses the same terminology works in the same
way. Again, it sounds really obvious.
But it's very easy to write systems.
I have seen lots of big systems where everything's kind of
Tangled together and you have pieces of codes that they all
interact in a big mess, big ball of mugs.
And so that's the first thing is to have these bad a context and
then within a band of context do want to guarantee that certain
constraints or Integrity the met.
So if you have an order, something you want to make sure
that the price Charging is the sum of the prices of the items.
Are you want to make sure that an email address always has
intact sign or something that's various rules about things.
You can just enforce that with a function.
And again, if you have an input and output, you can just say,
well the only way you can change this thing is through this one
function. I think this is because it's
very common with a mutable object because you can mutate
any of the fields. It's very easy to mutate one
field and then forget to mutate one of the other fields, and
that might be wrong. There might be some sort of a
strange. Ain't that if you do this thing,
this other thing also has to happen.
So if you have immutable data, you can't have that problem.
If you can't mutate values, then once it's correct, then it can
never ever change. Very simple example.
If I have an email object. When I create this email object,
I validate that it has an at sign or whatever.
Once I've created it. It's immutable I never ever have
to check it ever again. There's nobody can mess it up.
So I don't ever have to worry about revalidating it or
double-checking it or so on. This immutable, it can never
ever be changed. So he actually ends up with a
lot less defensive programming. If you have immutable data, you
typically validate things at the very beginning that the edges of
your program. And then once you're inside your
program, you basically trusted. It's all valid because it can't
possibly be changed so that even applies to bigger things.
But if you have a thing where if you change this field, this
other field has to change at the same time in an object-oriented
thing where they're two separate fields that would be card to
enforce but if the only way to change it is through this
special. The function and the function
changes both things at the same time and spits out a new one
which is valid. And if the things aren't
correct, it returns nothing. You've always got a valid piece
of data. So, a lot of these things about
integrity, constraints and stuff.
It's really easy to do. It's not even that big a deal.
It's not something you have to make an extra effort to work on
because that's just the kind of way.
It works. Naturally.
Again. This is where the program
Paradigm encourages you to write stuff in a certain way.
Okay, then I'll join the program.
You can have a class where you can only set things.
Instructor a none of the fields are mutable.
And if you want to change any of the fields, you have to create a
user Factory method or something, which validates,
everything you can totally write code that way in 0 as well, but
it just kind of feels it's hard. It's like you're going against
the way the language works. The language doesn't make it
easy for you to do that. It's not specific to functional
programming but I do think it's the way that functional
programmers. Think about these problems Maps,
very nicely onto this kind of issue in the book that you're
chose F sharp as the Language to express your thoughts.
You also create your website, F-sharp for Fun and Profit.
Maybe you can tell us why F sharp.
Why people should use F sharp instead of closure and all the
other functional programming. Well, I think F sharp is a very
nice multi-paradigm language. Educated depends on the
environment. You're working a bit of time.
Talking about typical business applications for Enterprise
stuff. First of all, I would say it's
nice to have a statically typed language and if you're working
by yourself, that's fine, but I think statically.
Typed languages are definitely the way to go if you A team of
people, so that eliminates closure and so on.
And then, in terms of the statically, typed functional
languages, you have Haskell. You have, oh camel you have Elm.
They have F sharp what I like about their shop.
Is, it's on a big platform. It's on the.net platform.
For people who don't know, dotnet actually runs on Linux
really? Well, it's no longer a Windows
only thing and because it's only on.net, any kind of thing you
want to interface with, there's a dotnet API for it probably or
donut library and you can just plug that into a shop and go so
you don't have to Write your own libraries all the time.
So, just in terms of productivity.
I just think it's my favorite language would being productive.
It's also got extremely good tooling.
Most of the function languages do not have as good to link.
The obturator languages don't have much better Tooling in
general, but I would say of the function languages have shot,
probably has the best Tooling in terms of refactoring and then
the editor hints. And so on.
There's a very nice plug in 4 vs code called iron, I'd Visual
Studio supports F sharp out of the box and jetbrains Rider
supports shot out of the box. So it's just a very nice
experience a language. Like Haskell is a very, very
powerful language, but it really does hurt your brain, because
it's so strict about immutability and strict about
doing I owe. So if you want to learn
functional programming, that's actually a very good language to
learn because it will force you to learn this stuff.
But in terms of actually being productive, I think F sharp is a
little bit easier to be productive in one of the
problems are with languages. Like Haskell is some people like
to get really advanced in some of the stuff.
They do men have to go, sort of encourages that a lot of people.
To write weird car stuff in Haskell.
It makes it very hard for other people to come along and
maintain it because it's just crazy.
So you can't get too weird enough shopping at some people
think well, that's bad. But I think that's nice.
You can't go overboard with advanced stuff.
You can never get too much that way.
So again this very practical very pragmatic language that
way. So looking at the other thing
that you are big, about you mention about productivity.
Just now you mentioned that programmers need to be more
effective versus being more efficient.
So I think you have topic is a big thing in Productivity world,
right? So effective as insufficient.
Maybe you can give us your thoughts as well.
What do you mean by programmers? Should be aspiring to be more
effective versus efficient. So, efficient is doing something
better. Like, an LED light bulb is more
efficient than incandescent light bulb.
It uses less power and Global doing a task with less energy
and with less money, that's being efficient, but we do tend
to focus on efficiency instead of Effectiveness.
Now. Effectiveness.
Is doing the right thing, so it's not about how efficiently
you do it. It's about.
Are you even doing the right thing in the first place?
The good example is, if you have someone in a really fast car
like a Ferrari and you have someone else in a bicycle, the
Ferrari is faster, but if you go in the wrong direction, the
bicycle is better. If you're trying to get to the
right place, a bicycle might be better.
So, I see a lot of people in programming.
We talk about velocities when it's all about Sprints, and
velocity, and story points and all Stuff we talked about how
fast can we do things and can we take off features fast and all
the stuff and there's nothing wrong with that.
I mean, it's good to improve your processes to make them
faster and more efficient is good.
But sometimes people lose track of was even more.
Important is doing the right thing in the first place.
I've had a bad experience where I spent a long time building a
product. We had a really good team.
We had really expert programmers.
We had really good. Processes is very agile, all
this stuff. But after we finish building the
product nobody wanted it. It was a failure because we
didn't actually build what people want it.
We were so obsessed with our own efficiency.
We didn't actually talk to anybody.
We don't actually talk to the end users ever since then.
I've been very concerned about doing user experience, testing,
getting feedback from the customer, getting feedback from
other programs, thinking about other people and listening to
other people. Not just doing what you think.
You again, techie people tend to be very concerned about
technology that this is a technology solution for every
problem. Sometimes it isn't a technology
problem. So people button and so you have
to improve your people skills, your listening skills.
And like I said, try to understand what is the right
thing to do, not just how fast you do it.
Well, I had a tweet, a funny tweets about this.
A few weeks ago, which is there's a famous detective
series in America in the 1990s called Murder.
She Wrote, it was set in this very small town in America.
Every episode, some personal get murdered this woman.
She was really good at being a detective every week.
She solved the murder. Eager.
And so she was very efficient at solving murders.
So she sold hundreds and hundreds of murders, but that's
being a very efficient. But really, if you want to be
effective, you should be saying, why are there so many murders in
this small town. And why don't you stop these
murders from happening in the first place.
That would be effective, not just being efficient.
It's very hard to think about Effectiveness as no metrics for
it. Effectiveness is very hard to
joke. It's a judgment call.
Are you doing the right thing? We sometimes do the same thing.
We focus on solving the problems quickly.
Well, then actually trying to figure out.
What's the point of solving this problem.
If it's not even the right problem to solve, there's a
social component which is if you are seen as a very efficient
person, you get a lot of credit. If you solve all these murders,
you consider the great detective and everyone thinks you're
fantastic. If you stop, the murders from
happening in the first place, nobody cares.
Because you never even happened, and therefore, people don't
think you're doing anything. So, unfortunately, we don't get
rewarded for being effective. We only get rewarded for being
efficient. So that's something just to be
aware of if you're ever, Were in a management position, don't
just watch people for being efficient and productive reward,
people for doing the right thing.
So yeah, I was about to say that people probably don't associate
high-performance with Effectiveness unless the
management has actually already realized about this.
So they tend to see people who can work as many times as
possible within a short amount of period of time or probably
the person is just busy all the time, but always get things
done, but there are people who tend to maybe perceive as lazy
but they are actually doing the right thing that solve the
problem at the root, cause probably tend to be less visible
unless they can mention about the impact and all that.
So what do you think will be your Advice to managers or
leaders to always have this mindset to be looking at the
effectiveness versus the efficiency.
There is a tough one. The problem is, it's very hard.
It's just hard to measure and now we're not even in the realm
of Technology. The person I would recommend is
a guy called Peter Drucker. He wrote books on management
Theory, back in the 1950s and 1960s.
He is the person who she came up, this idea of the difference
between Effectiveness and efficiency.
It's not an easy thing to do. It's so easy to get sucked into
the whole efficiency thing one way.
To listen to the outside world. So again, rather than working on
something and thinking that, you know, the right way to do it,
listen to users, listen to the feedback from people and change
direction. If you're going in the wrong
direction, you want to know as soon as possible.
So I guess would be having feedback loops as many feedback
loops as possible, so that you can change direction.
If you realize that people aren't happy with what you're
doing. And he comes back again to the
direction, Vector speed. You may send the beginning if
you have a Ferrari, but if you go to the wrong direction, it's
even worse. Exactly, exactly.
Really? Yeah, and unfortunately, I've
seen a lot of tech companies to exert.
They build a product that nobody wants.
It's nothing to do with a little quality of the team.
It's just literally you're building the wrong thing and you
haven't actually listen to your customers.
So, it's sad. And that affects this day.
I mean, social media and all that people also wants to Crave
instant gratification or instant achievements.
Sometimes you also need to think about.
Are you going into the right direction with that speed or
actually something that matters to you.
So that's a food for thought for everyone here.
So Scott is In a pleasant conversation learning about
functional programming. I myself get intrigued by all
these nice things about functional programming, and
maybe I'll give it a try as well in my day to day job.
But before we wrap up our conversation, I always like to
ask my guests to share. Three technical leadership is
done. So, this is something like a
message. You want to share to the
audience here for them to actually also reflect and maybe
learn from your experience. So, would you be able to share
your tree? Technically, the ship is
tomatoes? Yes.
So the first thing I would say is to read more about
nonsensical, things in particular, a lot of the stuff.
I've learned this come from reading about architecture, or
reading about systems thinking or reading about other
engineering books, right? Mechanical, engineering or
something. It gives you insight into your
problems again, getting out of your bubble and getting
feedback. One of my favorite books is the
Design of Everyday Things by Don Norman.
None of my favorite books is how buildings learn by Stuart
Willie. Some books.
They're not about programming at all.
But you can see, they really do apply to program.
Another piece of leadership. Wisdom is literally what we just
talked about. Yes, to be careful about
focusing, only on efficiency of focusing on metrics.
Make sure you're building. The right thing.
Another thing is, getting out of the house, talking to people
listening to people, and don't think the, you know, all the
answers something which has been very useful to me in this area
is actually reading about anthropology of all things.
So, anthropologists, their whole job is to listen to people.
And to learn things in a non-judgmental way again recent
popular and apology and I think it will help you be a better
programmer, just gonna interesting.
And the third one I would say is again in the whole Spirit of
getting outside. Your bubble is being a poly got
programmer and learning different paradigms.
It just expanding your mind in any way possible.
It's so easy to focus on one thing and just do one thing all
the time. The other ways of doing that is
to stop burnout. I did have a big problem with
burnout and I think other people have problems with Not.
And one way to stop burnout is to have fun.
Fun is really important. It's not all about work.
And so do things that are fun for you.
And if that's learning a new programming language or
expanding your horizons and other areas.
I just think that's a really important by this.
The whole thing is not just about your job.
It's about your whole life. So that's my last bit of wisdom
for you. Thanks for plugging in the
burnout message. So, I think you have many people
probably also experience burnout with the insurmountable amount
of work as video. Is this internet?
Is everyone can reach everyone very easily.
So Scott for people who want to continue the conversation with
you any place. They can find you online.
I'm only pretty much on Twitter. Not trying to avoid social
media, but I am on Twitter and my Twitter handle is stop
lotion. That's another piece of my study
of social media. If you want to be protective.
That's actually a very good thing about Effectiveness versus
efficiency. They measure stuff by
engagements. They want to get you angry, the
more Angry, you get them all clicks again.
I do think it's very unhealthy spend a lot of time.
Social media. I just don't think it's good.
So yeah, stay off social media and focus on the real world.
There are. Yeah.
Yeah.
Thanks for that message. So Scott.
Hope you enjoyed this conversation.
Thanks again for sharing your knowledge.
Thank you so much. Thank you for listening to this
episode and for staying, right until the end if you highly
enjoyed it, I would appreciate if you share it with your
friends and colleagues who you think would also benefit from
listening to this episode. And if you are new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It helps me a lot.
In order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page at technology Arnold death website, including
the full transcript enter. Resting courts and links to the
resources mention from the conversation.
And lastly, make sure to subscribe to the shows mailing
list on pack leader. No dot f to get notified for any
future episodes. Stay tuned for the next
technology. No episode.
And until then. Goodbye.