Hey, everyone, welcome to the Unhandled Exception podcast. I'm Dan Clark, and this is episode
number 10. So we are now in double figures. Whilst 10 episodes doesn't sound too much,
it is nearly 10 hours of content already. And don't worry, it's not me babbling on
pour 10 heures, as that would be pretty boring. Most of it is the awesome guess we've had on,
and today is certainly no exception. In the last episode, we were joined by Simon Painter
talking about functional programming in C-Sharp. And whilst this podcast isn't language or
platform specific, it is perhaps slightly biased towards .NET, because that is the language I
develop on, and it's awesome too. So it would be a bit remiss of me to have an episode on functional
programming in C-Sharp, which is a .NET language, and not also have an episode on F-Sharp,
which is .NET's functional programming language. And I could be wrong, one of my guests will
correct me, but I assume functional is what the F in F-Sharp stands for. And this is going to be
the topic of today's episode. So I am really excited to have another group episode today,
because these are always great fun. And today, I am joined by three guests in Russell, Isaac,
Abiam, et Scott Vlaschian. So let's do the same as our last guest episode, and go around the virtual
table, and let everyone say hello, and give a quick introduction. So first up, we have Ian Russell,
software developer specialising in F-Sharp and domain driven design. When I first met Ian,
I was attending one of his talks on F-Sharp, one of the DDD conferences many years ago. DDD is in
developer-developer-developer, not domain driven design. Check out episode six, if you want to know
more about the DDD conferences. I remember watching Ian's talk, obviously, I learned some F-Sharp,
but I was also quite pleased seeing that he was using the link pad for one of his F-Sharp demos.
Anyone who knows me knows I'm a huge fan of link pad. So very cool that you can do F-Sharp with it.
So, massive welcome to the show here. Thank you, Dan. So yeah, I'm Ian. I've been developing for
25 years, something like that, .NET since 2003, and F-Sharp officially actually writing code
in production since about 2017. I work for a company called Software Park. We're a remote
first software house based in the beautiful city of Vienna in Austria. Sadly, I work in the not-so-
beautiful place of Coventry, but it's a nice enough place. I've been talking about F-Sharp since
about 2013, and I concentrate primarily on beginners, or new people to F-Sharp.
That's good, because I'm definitely a beginner. So, next up, we have Isaac Abraham, F-Sharp,
MVP, .NET, and Azure Consultant, and author of the Get Programming with F-Sharp book,
which we will link in the show notes. I will certainly touch more upon that in this episode.
So, welcome Isaac, great to have you on.
Hello, great to be here. Yeah, so just adding on to what you just said. So, yeah, I'm the founder
of Compositional IT. We're an F-Sharp, an Azure Consultancy, so we do training and coaching
in F-Sharp and Azure. We do outsourced development. We're also, especially now, given the whole COVID
thing, mostly remote organization, I would say that our office is mostly based in London,
although I'm based in Germany. I've been here for probably four, five years.
Been working in F-Sharp, on and off, for probably five or six years. Been in .NET almost all my career,
which, normally, when I say I've been doing it for nearly 20 years, now I feel
like the oldest in the room, but actually, I think in this case, I'm probably the more junior
one compared to Ian and Scott. Yeah, I think you're beating me with .NET. I think I've been
about 15 years, and the rest has been C++, and probably the youngest in that case. And last but
certainly not least, we have Scott Blaschen, author of the website, fsharpforfunandprofit.com,
which is a fantastic and free resource for learning F-Sharp on functional programming,
and also author of the book, Domain Modelling Made Functional. So, welcome, Scott, thank you for joining us.
Thanks very much. Thanks for having me. Yeah, I think I've probably been programming longer than
most people. I started programming in the late 1980s. I started doing .NET when it came out in
2002, 2003. But I've actually had a lot of experience with a lot of other languages,
and I think that gives you a kind of different perspective. I think a lot of people who've
grown up with only one language think that's the only way of doing things. So, that would be
something to talk about later on, actually, is the effect of learning small talk and prologue
and Python, all the ones have on how you approach standardly type languages.
Definitely. There's so many different languages, and I just wish I had more time to play with them
all, but I definitely need to find time. I think it's quite important. So, thank you, everyone,
for the introductions. For my part, I'm a C-Sharp developer. I've played a little bit with F-Sharp,
but haven't really built anything with it. So, I'm going to be that newbie asking dumb questions.
I'm guessing, though, that a lot of listeners are perhaps similar to me, used to using either C-Sharp
or similar language, but curious about F-Sharp. I'm personally finding that, as I've been writing
more functional code in C-Sharp, especially with the newer versions of the language, having more
functional syntax, that I'm feeling a vast quality improvement in my code by doing so.
So, this has made me even more interested in giving something like F-Sharp a go.
But before we talk about F-Sharp specifically, maybe for those that missed the last episode
on functional programming in C-Sharp, maybe we can start with what functional programming
actually means and what benefits it gives us. Start with the hard one. Isaac. Me.
Well-monté, Dazook. Yeah, thank you, Scott.
I guess, as controversial a question is if you ask someone what is OOP as well, you probably
get 10 different answers. I guess I can talk from what I think of it as...
I guess it's really two or three different attributes in the way you program. Probably
one of the things is the separation of data and behavior. So, one of the fundamental things in
OOP is that you tend to have classes with some sort of encapsulated state and some methods.
You call a method and it will do something to that internal state that you don't really see.
And one of the things we tend to do in F-Sharp is to move away from that
and say we've got data, which you can see, and you've got functions.
And you give these data to functions and these functions give you back
different versions of data. So, that's probably one of the first things.
And then sort of goes hand in hand with that, is this notion of immutable data.
So, the idea that once you've got some data, you can't change it. It's fixed for life,
but you can make copies of it with changes applied to those copies.
So, in an example, sort of I just said you might have something like an order
and then you might have a function which is complete order. What that wouldn't do is
take an order and then just change the flag of the status to complete.
But it will give you back a new version of that order with the status change to complete.
And there's all sorts of sort of effects of working in that way,
which I'm sure we'll talk about later on.
And I guess the third thing I'd say is this notion of expressions as opposed to statements.
And I think in C-Sharp, I didn't really ever have a good understanding of the distinction
between them because it blurs the lines, I think, between both expressions and statements.
But in F-Sharp, it's quite clear in that everything's an expression.
What that means is everything you do has a result.
You can't have really a void function or a void method. There's no real idea of that.
You call a function and you'll get something back.
Even if that's something, there's nothing of interest,
that will actually be a result as well that you can reason about and do something with.
And that applies all the way down the language.
So we don't have if-then statements, you have if-then expressions
where every branch returns a value, almost like switch expressions in newer versions of C-Sharp.
Everything works like that.
And those kind of two things, that immutability and expressions,
and the separation of data, to me, in my experience,
are the core things of functional programming.
And if you adhere to those two or three things,
everything else naturally just falls into line into functional programming, I think.
Yeah, you can definitely see in the later versions of C-Sharp,
where they're definitely veering towards expressions with expression body members,
as you mentioned, switch expressions.
And then I really like when you start putting them all together
and you start making your method more functional,
how suddenly, okay, I can turn this method into an expression body member
and get rid of the return, get rid of the braces.
It's just become so much cleaner.
It's really nice.
Yeah, so I have something to add, which is that a lot of people,
I think, think of features, like if you have a lambda,
or if you have a switch expression, or if you have immutable data.
I mean, these are the kind of building blocks,
but when you put them all together,
the hole is bigger than the sum of the parts,
which is you start thinking about coding in a different way.
And that's the stuff that's not at all obvious.
I mean, you say, you know, well, C-Sharp has these things,
or other languages have these things.
Does that, you know, they have these features,
but the way you put them together,
it starts changing the way you write codes.
And as you say, it starts creeping,
and all of a sudden you start writing code
in a very, very different way from object-oriented codes.
And that's not at all obvious,
because that's not a syntax thing.
You know, that's not something that kind of you can see.
But as you get more and more experience,
you start, it completely changes the way you write code.
And I think that's been,
that's an interesting thing that people kind of go through
as they get more and more into it.
Yeah, the hardest thing about going to a functional language
from a non-functional language is the thought process.
It's a completely different way of thinking about writing code.
And that's, if you've done OOP for a long time,
it's very hard to turn all that off.
Yeah, I guess from a C-Sharp developer,
I know they said .NET developer,
but obviously that covers all the languages.
But from a C-Sharp developer,
if you're used to using the link,
that initial mindset shift,
when you started moving to link,
I guess it's kind of like just taking that book much further.
And it feels very, very link-like
where you start chaining stuff together.
Plus, you've got to look at it as,
they're adding more functional features to C-Sharp,
but it's not fundamentally a functional language.
So often you don't get the full benefit of the features
as they're added to a non-functional language.
Whereas if you add them to a functional language,
you get the full benefit.
So some things like pattern matching,
they look quite nice and people think,
well, they're slightly better than switch statements, etc.
But they're actually far more powerful than that.
And if you move into a functional language like F-Sharp,
there are a whole load of things that you can do
that you just can't do in C-Sharp,
because it wasn't functional language to begin with.
And that reminds me of when object-oriented programming,
because I lived through object-oriented programming
going through the same hype cycle
that functional programming did.
Like in the mid-90s,
everyone object-oriented program was the trendy thing.
And so everyone,
people added object-oriented programming to everything.
So you had object-oriented COBOL,
and object-oriented FORTRAN.
It's like, because they're focusing on the features.
And object-oriented COBOL with object-oriented features
is not the same as an object-oriented language.
It's never going to be small talk,
no matter how many features you add to it.
And I think it's the same thing.
The features are nice,
but it's the sum of the parts.
It's the overall philosophy of how you write a program
is very, very different.
And that's, like I said, it's more than just the features.
Yeah, I just had on two more bits to that, I think.
Two ways that you might manifest itself
is both the defaults of the language.
So that's again going back to things like immutability,
whereas in F-sharp,
everything is immutable by default and in C-sharp.
At the moment,
the majority of things are kind of mutable by default
with some extensions now with things like records,
where you can sort of get immutable data structures.
But also, I think,
the other thing that is often overlooked,
and this sort of is the inverse almost of what Scott touched on,
it's the features that aren't in the language
that often tell you the most about it.
So if you look at, like, F-sharp,
it doesn't have protected
and it doesn't allow you to do void
and it makes it difficult to do mutation.
And a lot of things like that
are kind of almost push you down the road of
it's much, much easier to adopt a functional style in F-sharp
simply because that's what it's optimised for.
I think C-sharp have taken an interesting approach,
which is very different,
which is more of almost a scarlet style approach
with let's try and merge
and sort of blend the existing OO features
and these kind of functional features into one
and come with this nice blend
where you can pick and mix the bits
and use them interoperably.
Where I think in F-sharp,
it's a more cleaner separation.
You've got sort of the OO side on one half,
mostly for inter-up,
and then you've got the FP side on the other half,
which is what you spend probably 95% of the time in.
Part of it for me with all the new features in C-sharp
is what's the correct way to write code.
In F-sharp, it's clear.
It's functional first.
Whereas in C-sharp, it's very much
is it because it's a new feature
that's what you should use?
Or is it perfectly good to stay with OOP?
And to follow up on that,
I mean, people have been programming in C-sharp
for since it first came out.
I mean, Async is a good example.
There's four or five different ways of doing Async.
And as it's evolved,
there's all these different kinds of collection libraries and stuff.
And the problem is,
every time you add a new thing,
you still have to support the old thing.
So if you're supporting legacy C-sharp code,
you have to understand four or five different ways
of doing something.
And so as a language designer,
I think it's quite tricky to add new features
because it ends up making the language more complicated,
all the different interactions
between all the different possible ways
of doing something.
I think it does get tricky after all.
How have you found that, Dan,
given your blog post recently as well?
Well, it's funny.
I was actually just going to mention that,
like following on from what Ian said about
what's the right way of doing things.
And that blog post you mentioned
were basically,
it was, and I can include this in the show notes.
And I think I mentioned it in the last episode too.
It was about making C-sharp more succinct,
basically writing more functional code.
And in the replies,
but on Twitter,
in the blog itself,
and on Reddit,
there was definitely two camps.
There was the people
that were more interested in functional programming,
and they were saying,
yes, they completely agree.
And I know Isaac,
we had lots of conversations
on the back of this blog post.
But then there was a lot,
the more object-oriented developers
that were applying saying,
no, they found the,
even just,
like there was one reply
which was talking about
the very first example in the blog post,
which was just link.
And he was saying,
no, that's not readable at all.
And I found that really interesting
because that wasn't doing anything
new and shiny.
To be fair,
I've had situations
where I've written stuff
in a slightly imperative way.
And then you've reached,
resharp has come up and said,
I can rewrite that as link.
And it's,
and it's,
you've said, okay, do that.
It's rewritten as link.
And I've looked at it, I thought, what?
I thought, undo, undo.
But I've definitely had examples of that.
But the example at the top
of the blog post was just very,
it wasn't nested link
or all subqueras.
It was just very basic link.
Scala is a language
where it has a very strong dichotomy
between the,
because it supports both
paradigms, OO and FP.
There's a,
in the,
in the language community,
there's a very strong dichotomy
between the OO Scala people
who are basically using Scala
like a nicer version of Java.
And the functional Scala people
who use it as like a Haskell.
And, you know,
it causes a lot of problems
if you're trying to like
maintain other people's code.
And you're an OO person
and you're trying to maintain
this weird Scala code
that you can't understand
what you're doing,
you know, what people are doing.
And so it's interesting,
if I was writing,
for example,
if I was writing C sharp code,
I wouldn't use some of the weird
link things like aggregate,
for example,
which is quite a tricky thing
to understand in link.
And I don't,
I probably would not use that
in C sharp code.
I would try and make my C sharp code
understandable to people who are,
you know,
who have that kind of
certain level of experience.
On the hand,
if I was writing F sharp code,
the F sharp equivalent of aggregate
is called fold.
And I would totally use that
in F sharp code
because the F sharp community,
I would expect that an F sharp person
would understand what I was doing.
And so, you know,
I would,
if I was doing a C sharp code,
I would not write weird functional stuff
because I just don't think
that's idiomatic for C sharp,
you know,
it's very hard for other people to maintain.
I've been doing a bit more
JavaScript lately
and it's interesting how
actually that's quite functional
in the sense of
like using reduce quite a lot
while you mention
then obviously for a lot of languages
you've got like the RX extensions
which are on dotnet and JavaScript
and lots of other languages as well.
And it's interesting how
it's not just C sharp
that's trying to move towards
a more functional style.
Even front end languages like react,
which is a UI framework
is trying to be very functional.
Yeah, absolutely.
I was just going to say actually Scott,
it's funny you mentioned that aggregate
because that's,
I can actually attest to that
in the real world.
Probably the last full-time C sharp job
I had some years ago,
I was almost known as the guy
that wrote the weird C sharp
and I written kind of a link query
and ended with an aggregate
and the rest of the team were like,
this is not C sharp that we can understand.
It's interesting often when I see people say,
I'm kind of nervous about adopting F sharp
because people on the rest of the team
might not understand it.
That might be true,
but it's not about the syntax,
the syntax is one thing,
but to be honest,
you get over that within a day or two.
You know, the lack of curly braces
and forget about semicolons and stuff.
The real challenge is the way you write code
and if you were to write pure functional code
in C sharp,
I think it would be just as difficult
to understand for the average C sharp developer
if not more difficult,
than it would be to do it in an equivalent
sort of either an F sharp solution
or an O O sort of focus C sharp solution.
And the other point I touch on Scott
in terms of the sort of splitting community,
I would just that there is,
I would say within F sharp,
you've got probably a greater degree of uniformity.
Most people adopt a kind of a similar
way of designing solutions,
but I would say in the F sharp community,
there is a kind of a split.
I wouldn't say it's a big one,
but you do have on the fringes,
people that would like to see F sharp
become a bit more haskell,
like with certain features
like type classes and things
which F sharp doesn't have.
And I'd be surprised
if it does actually ever get them.
It's kind of a functional language,
but it doesn't go off the rails
with like crazy features
in the sense of type classes
or higher kinds or dependent types
and things like that.
It's actually,
I still think it's mostly a set
of simple fundamental rules
that once you get your head around them,
the rest sort of naturally just bleeds out.
At least that's my findings.
Yeah.
And I agree,
you were talking about
what F sharp doesn't have.
And I totally agree about things,
you know,
people always talk about features,
but things which you can't do
is just as important
as the things you can do
and not having
some of the Haskell features.
I actually think it's a really good thing
for F sharp
because F sharp is not Haskell.
If you want to do Haskell,
you know, buy Haskell,
but the fact that you can't do
certain weird things in F sharp,
I actually think it's a big plus
for the language
because it keeps,
it means that
I can pretty much understand
anybody's code in F sharp.
I don't have to like be an expert
in some weird category theory thing
to look at people's code
and understand it.
And I think that's a big plus.

Is it worth,
whilst we've been talking about syntax,
taking a step back a bit,
and if we assume that a lot of listeners
haven't even seen the F sharp syntax,
and for me as someone
that's new to F sharp,
things that jump out to me,
I think like,
there's no Kelly braces
or semicolons,
which Isaac mentioned before.
And to be honest,
like personally,
like we all indent our code
using whatever language.
So for me,
it kind of feels like
the Kelly braces
are kind of redundant,
even in C sharp.
I know it's hard in an audible podcast,
but what does F sharp look like
if you're used to using something like
C sharp or C plus,
or any of these C type languages?
Well, the most interesting thing
or the most difficult thing
that people find
is the fact that it's top down.
You write the smaller bits of code
at the top,
and then the most important part,
well, the bigger things
fit at the bottom.
So it's very different to C sharp
in how you structure it.
But it's also,
it works not just in the file,
but also within the project as well.
So you can't,
it's a bit like JavaScript,
you can't use it until you set it up.
Whereas in C sharp,
it's, well, the code can go anywhere.
So does that mean that
the order of files in the project
is going to be in a specific order
or does that not matter?
It is.
Yeah, the code's got to be,
you've got to create the code
before you use it.
I think Scott did a lengthy blog post
on sort of an analysis of this.
One of the things you get by this
is you can't do circular dependencies.
So you can't have spaghetti code
in the sense of A references B,
references C,
which references A.
You just can't have that in F sharp.
So the initial instinct of everyone
is always to recoil at this.
But actually the flip side of it is,
if ever you want to understand
how something works,
it's just look up file
or look up the project.
It's never you're going to be jumping
up and then down and then up and then down.
So we just follow it upwards
and then you get to where you end up.
You need to go sort of thing.
But I think Scott,
you did some huge sort of analysis
on what entity framework or something.
Yeah, yeah, I did.
And so, I mean, this is a,
like in C sharp,
you have a tool like N depend
to try and help you find dependencies.
And in C sharp code,
your files are organized alphabetically.
And so if you come to a new C sharp project,
it's not very clear
where you need to start.
But in F sharp project,
the top file is always the basic one
and the bottom one is always the main program.
So you literally cannot have
some low level code
call the main top level code
because they have to be in a certain order.
And so you can't,
this is again,
this is a thing that stops you doing something
you cannot have circular dependencies
or cyclic dependencies.
I actually did a comparison
of some F sharp code
and some C sharp code
and the C sharp code
has, is full of,
most C sharp code
is full of circular dependencies
because there's nothing stopping you doing it.
But when it comes time to refactor,
these following,
you know, following these dependencies around,
this class depends on this class,
which depends on this class,
which depends on this class,
which depends on the first class.
It makes it hard to do kind of refactoring,
you know,
extracting a method or something
because there's all these dependencies
and they're all connected.
So you basically end up
with not having any kind of layering.
And the classic
software design technique
is to have layers,
you know,
you have the one,
and each layer is decoupled
from the layer above it.
You don't know about
the people who call you, right?
And that's like a fundamental principle
and F sharp sort of enforces that
and C sharp doesn't,
which is a shame.
I probably only add on
that the C sharp,
you do have it at the kind of the component level.
So you can't do circular references
as a project,
but it doesn't go any further
than that downwards.
Yeah,
the assembly,
you can't have a circular thing
in assemblies.
One assembly,
two assemblies can't depend on each other.
And that's a good thing
because otherwise it would be a mess,
right?
Which assembly do you compile first?
And in fact,
in my blog post,
apparently there was a circular dependency
back in .NET 2.0
and it would cause nightmares for them.
So yeah,
I think it's something you don't realize,
you don't even realize
how important it is until
until
you see the benefits of it.
So one of the other benefits
is the fact that it compiles as you go.
Because of the way the compiler works,
it's you,
you don't have to physically go out and compile it,
it's doing it as you go along.
And it's just a case of
making sure your type's matched.
So you're looking all the time
at function signatures.
So if you're looking in a product,
if you're looking something like VS Code
or Rider,
you'll often see the function,
you'll also see the function signature as well.
We sort of concentrate on those things
and once they all match up,
the thing basically works.
It's odd,
you'll do a bit of refactoring
and as long as everything compiles,
you run it and it just works.
It obviously doesn't always,
but it's a nice thing a lot of the time.
So speaking of types,
I'm aware of this,
but I'm not going enough F sharp
to actually really appreciate the power of this.
But from what I've read initially,
it sounds like you don't need to specify types
and you're near as much as you would
in a language like C sharp
and it infers a lot for you.
But it's still strongly typed.
So it is in frame,
but it's still strongly typed.
It's not dynamic or anything like that.
That sounds insanely powerful
and also kind of not scary,
but from where I'm used to specifying types.
I think that would probably be one of the things
I would struggle with initially, I think,
just trusting it to get the right type.
The compiler's really good.
I mean, it basically works on usage.
So it works on how you use it
and it works backwards from there
to work out what the types are.
It's really clever.
Yeah, basically,
if you sort of think of like a record
and you want to access a field on a record,
that the compiler basically say, right,
you've tried to access the field name,
are there any types in scope
that have a field called name?
And if there's only one,
then it must be that one.
Therefore, this type must be customer, for example.
So it works surprisingly well.
Certainly from my,
there was a kind of skepticism
when I first started using F-Shark
with the type inference
because it just seemed almost too good to be true.
But it's like 99% of the time,
it just works.
And it really makes refactoring a huge amount easier
because you don't have this situation
where you change something at the bottom
and then you have to change
five functions, signatures,
or methods
to return the type you've changed to.
It's just naturally sort of
fingers it out basically.
And it's kind of scary when it works,
which is, like I said, nearly always.
And one other thing it does
on this type inference thing,
it will also,
if your functions can be generic
without you even sort of specifying it,
sometimes make sure you think a bit differently
about what your code actually does.
Another feature I really like
is I think they call it pipelining.
Is that right where you've got the
pipe and the greater than symbol?
That's a forward pipe.
Yeah, there's a backward pipe
and there are other forward pipes
and backward pipes as well
with multiple parameters.
Don't use them.
I didn't know there was backward pipes.
Yeah.
We don't talk about those.
Don Simon says don't use them.
But basically, yes, there's a pipeline.
So if I explain my basic understanding
of a forward pipe,
but so thinking about
PowerShell or Bash,
where you've got a script
and you've got one commander,
then you have a pipe symbol
and then you would chain
the output of one
into the input of the next.
From what I understand,
it's similar to that.
Yeah, that's exactly the same.
But rather than a pipe,
it's a pipeline a greater than.
And then am I right that it takes the output
and that's the last function parameter
of the next one?
Correct. Yes.
Yeah, so it's a bit like the opposite of Link.
So with Link,
you've got an extension method
and the first thing is the thing
that you pass along the line.
In with with pipelining,
it's the last thing
that gets passed along the line.
See,
I use ligatures in my font as well.
So it converts the pipe
and greater than sign
to almost like a triangle shape,
which is like an arrow,
which makes it look really nice as well.
But from a C-sharp developer,
it does feel very Link-like
where I can take a bunch of methods
and just chain them together
into a chain of functionality.
So Scott,
Scott does a lot of videos on this,
on this sort of thing,
not particularly forward piping,
but composition.
So this is one of the big things
that F-sharp has.
So being able to compose
bigger types and bigger functions
out of smaller types
and smaller functions.
Yeah, I was going to say,
it's like if you like how Link works,
imagine being able to do that
for anything in any part of your program
without having to add a whole bunch
of extension methods.
So I mean, you know,
people who like Link,
they like it a lot.
And it's like,
but that only works for collections.
So if you can use the link approach
where you dot in
and you just keep chaining methods
one after another,
in F-sharp,
you get that sort for free.
You don't have to do any extra work.
You don't have to write extension methods.
You don't have to do any of that.
Just that's the whole,
the language is kind of built
around that way of working.
So that's really appealing.
Once you get used to that way of working,
it's really, really nice.
Yeah.
This is something that last year,
some point,
I sent a tweet out basically saying,
I really wish you could do
like the link stuff
on a single object
rather than a collection.
And we actually spoke about this
in the last episode
with Simon Painter
and a few people replied and said,
well, why would you want to do that?
And then so I'll find out
that I'll find the tweet
and put it in the show notes.
But I put a reply
which was a code snippet.
And by not being able to do it,
I had to declare a local variable
because I was reusing that multiple times.
And in the code snippet,
by doing link on a single object,
I could turn the whole method
into an expression body member.
It suddenly became much smaller
and cleaner.
And I would argue easier to understand.
And unless I had come across that example,
I wouldn't have realized
that that would be useful
to be able to do link on a single object
until I actually saw it and thought,
oh, that's really powerful.
Exactly.
The way I try and describe
sort of this pipeline to C sharp devs
is just imagine that you didn't have to,
if you wanted to make an extension method,
you've got to make it static,
in a static class,
and you've got to put this keyword
in the first argument.
Imagine you didn't have to do that.
And it was just make a method
and it implicitly is sort of extensible
on another one, on another type.
And that's basically what it is.
That's really all pipeline is,
except instead of dot,
you have the arrows,
that vertical pipe in the arrow.
That's all it really is.
But it fits in the whole link sort of functional thing.
It wouldn't really work
with, if you had mutable data,
it's not quite as nice.
And so on and so forth.
Yeah, that's really all it is.
So I'm curious.
I know you said don't do this,
but what is backwards pipelining
and how does it fit in if you've got,
can you do forwards and backwards in the same?
Yes.
Yeah, so basically,
if you had something,
so if you had something that you forward pipe into a function,
that gets applied as the last one,
but then if you have a backwards pipe,
that gets applied as the last one at the end of it.
So it goes forward pipe first
and then the backwards pipe afterwards.
But don't do it.
It's confusing.
One of the great things about F-sharp
is most of the code that you read
is perfectly readable.
As soon as you start having
lots of funky characters in there,
it starts to get difficult.
So I look at C-sharp code now
and I see all these Elvis operators
and everything else.
I get really confused.
Well, as I look at F-sharp
and there are very few of those sorts of things,
but F-sharp was always the language
that had all these funky characters.
But there aren't any,
but there are very few.
Well, I guess with C-sharp
and the Elvis operators,
that probably leads on to another point
about nullability.
Up until recently,
most things can be null.
Am I right that F-sharp is by default not null?
For any types that you display yourself, yes.
But if you're interropping with like the BCL,
so strings and classes
from everywhere asked,
then it doesn't take part in that.
But if you play your own records
and things, then, yes,
everything will be non-nullable.
And then you have to put in extra keywords
saying this is actually nullable.
We try and avoid using null.
And null is considered,
and again,
this is a difference between C-sharp and F-sharp.
In C-sharp, null is perfectly fine.
In F-sharp, null is like a code smell.
And if you see null in a piece of code,
that's normally considered like,
why are you doing that?
Il must be very important reason,
like interrope or something,
where you're doing it.
But you really, really try and avoid null
in F-sharp code.
So the obvious next question
is what do we use instead?
So if you can't use null,
we have something called the option type.
And the option type is a,
well, we're covering discriminated unions
without covering discriminated unions here.
So an option type is either,
it's something with a value or it's none.
So it's a bit like a nullable type
in C-sharp,
but you can apply it to anything.
So not just nullable types.
Yeah, it works for ints and strings.
It doesn't have like nullable types,
only work for things like ints and...
In the last episode we were talking about,
where we spoke about the option type
and maybe's and either's,
and getting that into C-sharp.
And even like talking about
trying to describe what a monad is,
which sounds like pretty much this.
But you get this,
like obviously with C-sharp,
you need to write those extension methods
yourself to handle that,
or use a library.
I think he mentioned...
I can't remember the name, but now.
It's in the show notes from the last episode anyway.
But in F-sharp, this is just built in.
It is, yeah.
And further than being built in,
I would just say these,
in F-sharp, you don't have special cases so much.
Like in C-sharp,
you have a whole bunch of stuff,
especially for null,
like the Elvis on break.
It's like in F-sharp,
the way you handle chaining option types together
is not a special case
that's hard-coded into the compiler.
It's a feature that you can actually use
for anything, not just options.
So that the way you handle chaining options
is the same way you handle chaining asyncs
or the same way you handle chaining,
all sorts of other things.
It's the same technique
that's a generic technique
rather than a specific special case for null.
I think that's a good point you made there, Scott,
which is more about the difference approaches.
Like F-sharp has this notion
of let's try and find general solutions
that we can use everywhere.
They may not be highly optimized
for any specific case.
Like you're not going to have language extensions
with custom operators
to deal with options or results or something.
But it's a general pattern.
Once you know it in one place,
you can use it everywhere.
I think in C-sharp,
they've taken a different approach,
which is let's really optimize
around things like asynchro-weight.
You've got custom keywords for that.
Nullability now,
you've got Elvis and the null coalescent,
like three or four other ones,
designed specifically around nullability.
But I could imagine,
what will we do in C-sharp 10
or something if we got result type?
Are we going to need then similar operators for that
or will we not have anything
or something else, I don't know.
But I think that's kind of an interesting one
is that C-sharp has taken an approach
of let's put in extra sort of keywords
to really make it easy to do these specific cases.
But if you want to do something outside of that,
it may be as not as easy
or you have to figure out yourself
or do something else.
So Ian,
you mentioned something called
discriminated unions before.
I did, yes.
That's very well-voluntary.

Okay.
So discriminated unions,
describing them to a C-sharp dev
is difficult.
They're a choice type.
Say for instance you had a,
but we'll take the option.
It's either something,
it's either there,
there is data or there isn't data.
So it has to be one or the other.
It's a bit like an enum,
but it's not
because you can have data
against some of the case types
and not data against others.
And it can be different types
of data against different choices.
So it's not like an enum,
although it sort of looks like one.
But it's also not like a class hierarchy either.
If you compile a discriminated union in IL,
what you get is a class hierarchy.
But it's not a class hierarchy
because it's a closed set.
So if you add a new item to the list,
anyway, you do pattern matching
on that discriminated union,
it will tell you not covering all the cases.
Whereas if you've got an abstract type
and classes that you derive from it,
you can add one to your heart's content
and the compiler will never tell you
if there's a problem.
So it's like the opposite of object-oriented
programming in many ways
because you're interested in the data
that's not shared.
You're interested in the data
that belongs to each of the cases.
It's quite a difficult thing to explain.
It's much easier to see
once you see it.
It's like, oh, yeah,
that's fairly obvious.
But it's quite hard to explain
in terms that for people
that don't understand or have never seen it.
It sounds very similar to where
with type inforance,
how, as I mentioned before,
I understand it,
but then I probably want to
appreciate the power until I start using it.
I'm guessing this is very similar
where once you start using it,
you can't imagine not having it.
Yes.
Well, when you try and model something
in a non-functional language
that doesn't have them,
it's very hard
because you're always thinking,
well, that would be great
for a discriminated union.
A good example,
Mody Dan,
would be something like,
imagine you've got a customer
and a customer can be contacted
in one of three ways,
like email, telephone,
or post.
And you wanted to model the idea
that telephone's got a telephone number,
post has got an address
and email's got an email address.
How would you model that in C-Sharp
in an OO World today?
And there's sort of four or five
different ways that you see,
but none of them I found are really
satisfying
because you could,
the idea,
you'll end up with sort of
making all the fields nullable
on a single record
and just make sure
you never touch the wrong ones
when, you know,
if it's post,
then never touch the telephone number.
Or you end up using inheritance
in a class hierarchy,
which to be fair,
most people tend not to do
because it just feels too heavyweight.
And that's kind of that area
that discriminated unions kind of,
fit,
et so on.
So your first example there
where you've got things
that could be no
and then you might want to put that
into a database
and use something like
Entity Framework to map
a POCO object
to a database schema
which does support
nullable columns.
How would that then map into
using,
and this probably leads on
to another question
I was going to ask a bit later
about how well F-Sharp
plays with
frameworks like Entity Framework
or ASP.NET,
but maybe we can touch on that later.
But does it map quite well,
does a discriminate union
would unravel itself almost?
It would be the same issue
so you have with inheritance
in OO.
So you've got normally
two strategies
for dealing with that
in relational databases.
One is you put them all in one table
and you just make all the columns nullable.
And then you have a discriminator column
that says this subtype sort of thing.
Or you take a table per subtype approach
where you have like
the common fields in a table
and then each union case
would have their own table
with just their fields in them
and then you sort of link
the two together.
And that's the same way
that you do inheritance
in OO table.
I think EF actually supports
both approaches.
So it's actually not that different.
It's just more at the code level
how you reason about it.
That's actually a really good example
like visualising it in.
So I think one of the Entity Framework
options is how a hierarchy
gets mapped to the table.
And I've seen it before
you've actually had a column
which says what type it is.
Yeah, let's call it discriminator.
Yeah, that's really helped.
It click in my head, I think.
Hopefully it has for the listens as well.
Isaac, you mentioned at the very start
you were talking about things like immutability
and I think you were describing pure functions
as well without using the term pure.
I don't know, like C-Sharp9
has these new record types
which makes it a lot easier.
Is everything just naturally
10 tools being more pure functions?
So I guess like with code
you've always got to at some point
write to a database
or call another service
or have some form of state.
How do you actually manage that
in a world that's leading
towards pure functions?
It's probably worth mentioning.
F-Sharp9 doesn't force you to do purity
and it won't give you any sort of tight pins
to say this function is making a database call.
You're not allowed to do this.
It's not like Haskell
which sort of forces you to have this whole I.O. spiel.
So let's leave that aside.
It's more about I think
F-Sharp9 gives you some signals
to help you sort of know
if those functions might be doing something like that.
But generally what people tend to try and do
is write pure functions to do with their domain,
the data, their transformations
and then at the boundary of the app.
Just at the edges,
that's where you'll go outside
to your database call.
You'll do your writes, you'll do your reads.
You'll maybe make web service calls.
But then once you've got your data
from these impure parts of the universe
you then just go back into your internal sort of pure domain
and it's more like the ports and adapters style approach
there where you give it some data,
do some stuff inside
and then push it out into the outside world again.
Just to add to that,
this style of doing software architecture
is not specifically functional.
I mean the onion architecture
and the ports and adapters
and domain-driven design
has a concept of not caring about the database and so on.
Doing this approach to designing your code
makes your code,
your business logic much easier to test
because you have no external stuff in your pure code.
So your business logic is completely deterministic,
it's completely predictable,
it's super easy to unit test
because you don't have any kind of databases
mixed up in the middle of it.
And so this is just a good style of programming anyway.
It just happens that functional programming
fits this style really, really well
because that's how functions work as well.
Looking at a lot of in-coupers talks
about the ports and adapters
and this kind of thing from a C-sharp world.
If you're not used to doing that
it's quite a different way of thinking
whereas it sounds like if you're doing F-sharp
like a lot of the things we've spoken about so far
you almost force down that route
just not force down
but it's just a natural path you would take.
The easy path, yeah,
it's the same thing we're talking about.
As developers we tend to be very lazy, right?
And you're just going to do,
most of the time you're going to do what's easiest.
So if it's easy to use null, I'm going to use null.
But if it's hard to use null, I'm not going to use it.
And the same thing,
if it's easy to have impure functions
I'm just going to probably do that by default
and then I have to refactor them
when I want a unit test or something.
But if it's hard,
you tend to do the right thing.
If it makes it easy to do the right thing
and hard to do the wrong thing.
And I like a language that does that.
I mean, languages that encourage you to do the right thing
I think is a good idea.
Yeah, Don Sime's done a tremendous job with F-sharp.
And I think it's,
and obviously the guys that are working on the compilers and things.
Yeah, it's, it's one of those things.
If you feel that you're having to work really hard to solve something
you're probably doing it the wrong way.
So it tries to guide you along the correct route.
And if it gets difficult, it's telling you
you shouldn't really be doing this.
Yeah, it feels like,
what you mentioned before about the order of even the files
and the project matters.
I can picture that being initially frustrating.
But then, as the project grows,
it will save you lots of time.
And like, having maintenance nightmares later down the line.
I agree with that.
Yeah, exactly.
So I did mention before about things like Entity Framework and ASP.NET.
How well do those things play in the F-sharp world?
I know you there's something called Giraffe.
For like, which is, is that like ASP.NET?
But for F-sharp?
Yes. So Giraffe is a thin wrapper around ASP.NET Core.
And then there's another one called Saturn,
which is a thin wrapper around Giraffe.
So Giraffe is basically a functional wrapper.
So it takes away a lot of the,
the non-functional usage of ASP.NET Core.
It makes it much easier to use for us F-sharp developers.
And Saturn's just slightly more opinionated.
Well, I was going to say about libraries versus frameworks.
I think there's a big difference between libraries and frameworks.
A library is something that you're in control of how you call it.
And a framework is something that you are forced to adapt to its way of working.
And OO design tends to be very framework oriented.
You basically have some classes and you're
and supposed to inherit from these classes in order to get the functionality done.
And functional programs really hate frameworks.
And they much prefer libraries where you build,
you have these tools and you build bigger things from the smaller components.
But you are personally always in charge.
And I think that's why libraries,
we tend to take libraries like ASP.NET,
which is a framework and try and convert it into
something like Giraffe,
which is turns it into a library
where you can build things from the smaller things.
It's just, again, it's a subtle way of thinking about how you build programs.
To put that in context maybe for the listeners
that are thinking what does that actually mean in reality?
If you think of the old sort of web API world,
where you make a class that inherits from either controller
or something like that,
and then you make methods on the class
and decorate it with things like,
this is for this route,
and then this is the handler sort of thing.
In Giraffe, it's a very different way
where you basically say,
given this route,
and don't even bother with classes or anything,
just say given this route,
which is maybe it's the raw string,
pipe it into this function.
And this function is going to give me back some data
and I'm going to pipe it into another one.
And then at the very end of this chain,
I'm going to then wrap it into an HTTP response.
And it's almost like,
if you look at ASP.NET with the pipelines,
it's almost like everything works like that.
Not just the sort of the cross-cutting concerns,
but everything you do.
It's just a chain of,
giving some message,
do something with it,
give back an async response,
and then wrap it in HTTP sort of thing.
It sounds very similar to,
I don't know, this is not supported anymore,
but the Nancy framework,
I don't know if anyone's used that.
Yeah, yeah.
But you literally just,
it'd be like a lambda expression
into the function you want to call
or the endpoint.
Yeah, exactly.
It's a shame that's not being supported anymore.
Carter exists.
That's quite an interesting one.
So I have the pleasure of working with Jonathan Shannon.
And he's still working on that.
It looks really good.
So what's that call for that one?
Carter.
Oh, I have heard of that.
I've not looked into it though.
Yeah, so it's like a slightly updated Nancy.
Or it's a Nancy for.NET call.
Oh, I'll have to have a look.
I'll find that and include a link to that in the show notes.
So going back to the link analogy again,
imagine you could write your ASP.NET stuff
in the same way that you write link.
Right, the same idea.
The request comes in and you feed it to the next thing,
we feed it to the next thing,
and it comes out as a response at the bottom.
So it's exactly the same thing as using link,
but with HTTP.
So that's how a functional library would work.
And that's how Joao works, for example.
The funny thing is,
if you think about HTTP and web apps,
really what they are is functions.
You give it some request and you get a response back.
There is no real state.
The whole thing of HTTP is stateless anyway.
So in that sense, F-Sharp and functional programming
in general fits really nicely with that paradigm.
You get an HTTP request,
you give back a response with a code and some payload.
There is just data.
So it actually fits really nicely.
But I guess as part of that,
most API endpoints would,
as part of that call into a database or another service.
So it's not quite that pure.
But I get your point though,
it's from just looking at that bit of code.
Your point about it being almost like a link statement.
That's kind of even in ASP.NET and C-Sharp,
that's kind of how a lot of my endpoints
are now starting to look with expression body members,
where it is just an expression,
which might be a bit of link as well,
but then that calls into something else.
But it's all abstract to the way.
So it looks nice and clean
from just looking at the controller point of view.
If you even look at the stuff like David Fowler is doing,
or Ben Adams,
a lot of what they've been looking at recently
is things like how can we get a really pared down
ASP.NET called pipeline.
This is my route, map it to this handler sort of thing.
In effect, that's almost what Giraffe does in a sense.
Just imagine there are no controllers.
If there are no controllers,
then you're on the way,
because controllers are still class-based.
There is no spoon.
Right, you don't need a controller.
Yes, I think quite often,
like some of the projects I've worked on,
I've used mediator,
which there's your handler and your business logic,
which quite often the controller
is literally just calling straight
into that mediator handler,
or the mediator pipeline.
Giraffe is effectively that.
But instead of calling out to mediator,
mediator is a routing system.
Nice, nice.
So you throw away all the rest of it.
Another's the new...
Is it AP...
Who wrote it?
Adalis, Steve Smith,
I recently written API endpoints,
which I think tries to clean that up in C-sharp.
But that's maybe one for another episode,
not being a sharp.
We've spoken a lot about things,
so we've covered the type system,
pipelining, pattern matching,
discriminated unions,
null handling and mutability,
expressions over statements.
Are there any other key things
that F-sharp brings to the table
that we've not really touched on?
Scripts, maybe?
Do you want to talk about that, maybe?
Scott, or then if you...
Yeah, I mean, well, just one simple thing
about the low noise in the syntax.
Again, it's not particularly...
You know, the fact that there's no curly braces and stuff.
I mean, what I like about it
is you actually get just a lot more code on the screen.
That's something very simple.
Like, if you're used to using language
like Python or something,
it's a very compact language.
And F-sharp feels to me like Python,
but statically typed.
And it's just nice
that you don't have all this noise
on the screen all the time.
You can focus on the lodge.
I mean, that's a trivial...
I know it's not the most important thing,
but it's kind of a nice little benefit.
How do you decide how to separate out
your different files?
So, for example, in C-sharp,
quite often, people would have a file per class.
And now with C-sharp 9,
introducing record types,
where I'm trying to use record types more,
which is pretty much a one-liner.
I'm finding...
Actually, I don't want one file
with one line in there.
So, it sounds similar with F-sharp,
where you've got lots and lots of functions
which aren't encapsulated in a class.
How do you decide how to break up
those into files or modules
or the different elements?
Well, most people tend to put things...
Well, obviously put things into modules
to begin with.
But most people tend to split it into two files per...
I'm going to say bounded context,
but business area.
So, you'd have a file for types
and a file for functions.
Right, OK.
And then, obviously, you have a load of common stuff
as well that gets moved up to the top.
So, you'd have a load of common types
and common functions.
But basically, it's modules.
There's namespaces as well,
but that's really tied into working together
with interropping the C-sharp.
I mean, in general,
just like you organise any code,
functions that do the same thing
live together
and functions that you group them by what they do.
But one particularly nice thing
is unlike classes,
it's quite hard sometimes
to extract a method for refactoring.
Extracting a method can be quite tricky.
But the nice thing about pure functions
is they don't have any dependencies
other than the parameters that are passed in.
So, if you want to...
If you decide that you actually don't think
this function should live here
and it should live somewhere else instead,
you literally just copy and paste it.
You don't need to do a complicated extract method
or anything like that.
It's a lot easier to move things around
in F-sharp codes.
I mean, typically, if I was starting,
I'd probably put everything in one file
and then as it gets bigger and bigger,
I start moving,
okay, this thing should be over here.
Let me organise it a bit better.
And I can refactor very easily
without worrying that I'm going to break things.
That's a really good point
because in C-sharp,
when doing refactoring,
I'm very dependent on using tooling
like resharper
to adjust the namespaces,
to just move stuff around.
And that works well,
but it sounds like in F-sharp,
you don't need that.
You can literally just move it.
Yeah, yeah, carried on from that as well.
There isn't a resharper for F-sharp.
You just don't need it.
We don't tend to debug that often either.
So, one thing we haven't mentioned
so far is the REPL.
And the REPL is really interesting.
So, the ability...
Parce que beaucoup de ce que vous avez écrit
sont des fonctions pure.
La capacité est de faire un code
et de le faire dans un temps local
dans la REPL,
le repos de réévaluer
le print-loup.
Vous pouvez juste essayer de la faire.
Et puis,
donc, vous n'avez pas de faire un programme
ou quelque chose comme ça.
Vous n'avez pas de faire un test.
Vous pouvez juste essayer de le faire,
si c'est un code script
ou un file de F-sharp.
Vous pouvez juste dégager le code
et le faire.
Donc, pour les listeners
qui n'ont pas entendu le code repos,
c'est juste comme
utiliser une ligne de commande
effectivement,
donc, vous pouvez juste
mettre un commande,
mettre un enter
et il est évalué.
Oui, ou juste dégager le code
dans votre base de code.
Donc, le code en fait,
vous pouvez juste dégager le code
dans la REPL.
Nous avons mentionné le code link
au début de la période
où vous pouvez, même en C-sharp,
dégager un peu
et presser le F5.
Mais vous ne pouvez pas le faire dans votre IDE.
Donc, avec F-sharp,
vous pouvez juste dégager un peu
de code F5
et...
Boom.
Oui.
Ou alors, dégager.
Mais oui.
C'est beau.
C'est un vrai changement de jeu.
Si vous ne pouvez pas le faire.
Je vais dire que, en quelque sorte,
c'est plus fort que le code link.
Alors, si c'est le cas,
quand j'ai utilisé le code link,
vous devez mettre votre code
dans le code F5
et il serait le code de la description.
Et vous donnerz les résultats.
Alors, avec F-sharp,
vous pouvez juste penser
que vous devez
garder le state
après que vous exécuter un code.
Donc, vous pouvez avoir une fonction
qui fait quelque chose
et puis juste répétir
ce fonction
avec différentes valeurs
et puis dégager ça
quelque part.
Et puis,
aller faire un autre code
et essayer quelque chose.
Donc, c'est un peu plus
sorti interactive
et dynamique
en ce regard
que vous pouvez juste créer un code
et essayer de les faire
dans cet environnement.
Et quand vous êtes heureux avec ça,
oui, ça ressemble bien.
Je trouve que la façon
que cette fonction est en train de s'exprimer
ou le type a l'air correcte,
vous pouvez le copier
dans vos principales files F-sharp
et puis c'est partie de votre base de code.
Donc, c'est un element explorateur
aussi.
Non, c'est vraiment beau.
Vous avez écrit un code link
sur le code F5.
C'est un seul bon.
Il ne persiste pas de variables
ou quelque chose.
Il y a un dropdown
où vous pouvez choisir
si vous avez mis un seul statement,
qui va juste vous placer
l'outlet de l'expression.
Donc, je n'ai pas dit
un statement,
un expérience mentale
ou un liste de statements
qui sont comme un script
ou vous pouvez aller dans le mode programme
et avoir des classes
et des fonctions
et tout ça.
Je l'ai réalisé
depuis que je suis en train de chat
avec des F-sharp.
Je devrais vraiment
être careful
de dire la expression de la parole
sur les statements.
Je ne me le vend pas.
Je sais que Isaac m'a
mis en place
quelques fois sur Twitter.
Donc, le autre
très bon chose
que j'aime beaucoup
sur F-sharp
est les collections.
Donc, on fait
un grand nombre de données.
On transforme
beaucoup de données.
On fait
beaucoup de transformations
sur le données
que nous avons
dans différents formats
et choses.
Et
souvent, on pense
que c'est ce que je veux
faire.
Et la plupart du temps,
il y a une fonction
déjà là-bas
dans les collections
pour les utiliser.
On est construit
dans le système pipeline
que nous avons déjà obtenu.
Donc, vous n'avez pas
à apprendre tout de suite.
C'est assez magique, vraiment.
Est-ce qu'il y a des issues de performance ?
Parce que si les collections
sont mutables,
je sais que vous pouvez avoir
des collections mutables
dans F-sharp aussi.
Mais
plutôt que juste
appender
à une collection,
régenerer la whole collection.
Oui.
Oui, il peut y avoir des issues de performance
mais il faut
faire de l'argent.
Mais vous pouvez
décider
pour des choses comme
je n'ai pas compris
ce qui s'appelle maintenant
le
F-sharp list.

le récise.
C'est
le récise.
Oui.
Le récise de rayon.
Oui.
Oui.
Si vous voulez une performance,
vous pouvez utiliser
les classes F-sharp.
Mais en général,
la performance est
très bonne
si vous
travaillez
avec les collections mutables
de certaine manière.
En général,
si vous travaillez
dans une certaine manière,
ça fonctionne vraiment bien.
Et si vous
en essayez de
faire des fourloupes,
ce n'est pas particulièrement
efficace.
Mais si vous utilisez
la fonction de map,
qui est la même
que la fonction de link,
la fonction de sélection,
ça est
très
performant.

vous voyez,
vous avez
de l'esprit
de travailler
avec votre code
dans un certain nombre de temps.
Mais
en général,
ce n'est pas vraiment
une grande question de performance.
Nous avons un parlement de
des 1000 items
que nous avons
déterminés
à la fois.
On peut avoir
5000
GPS
des signals
à faire.
Vous n'aurez pas de différence
en utilisant
n'importe quel
qu'il utilise, vraiment.
Je vais juste
mettre ça.
Il y a des choses
que F-Shark
peut faire aussi
en essayant de
faire ces collections
comme performance possible
parce que
si tout votre data
est immutable
et que vous voulez
mettre un item
sur une liste,
ce que vous pouvez vraiment
faire
c'est de dire
que c'est la même liste
que la première
qu'on avait
juste avec un autre item
ajouté à la front de ça.
Parce que rien ne peut changer
sous-least.
Donc c'est en fait
parfaitement
safe
pour
tenir la liste ou
ne pas
couper le data
par-dessus
juste de référer
la liste existante.
Donc il y a des trucs
que ça peut faire
pour essayer de
optimiser les choses
comme ça.
Mais si vous avez
un type de loop
où vous faites
des modifications

et que vous avez besoin
de être
comme performance possible,
alors
fine,
vous savez,
dans une fonction
juste dans ce scope
utilise un collecteur mutable
ou un data mutable
ne laisse pas
le bleu
à l'autre de l'app.
C'est un peu
juste de l'inverse
et on dit
oui, vous pouvez
utiliser
si vous avez besoin
de
mais ça devrait être
l'exception de la rule
en tant que
d'autre de l'autre.
Oui, la autre option
aussi est
est
si vous avez beaucoup de cause
vous pouvez utiliser
les collections parallèles
parce que tout le data
est mutable
vous pouvez
vous pouvez
vous pouvez

vous pouvez
utiliser
les versions parallèles
de les collections.
C'est drôle
comme
juste avant que vous avez
dit ça
ici
et comme
vous l'avez mentionné
sur le « être safe »
ça m'a fait
me penser
à
le parler
de la mutabilité
et
concurrence
je suis sûr
que nous avons
été développés
pour quite un temps
donc nous avons
expérimé
les médecins
que vous pouvez obtenir
avec
concurrence
cote
présumément
comme
en écrit un style
plus fonctionnel
où vous utilisez
les méthodes pure
et les données mutables
qui
font
que les fonctions
font beaucoup
Oh, j'ai dit méthodes
Oh, je suis désolé
Pure fonction
Sorry, c'est bon
c'est bon
Un peu de ce qui s'en va
oui
Vous savez,
ce n'est pas un bon voyage
vous avez toujours
à penser
sur ces choses
mais au moins
au niveau de la code
vous n'avez pas à
vous inquiéter
sur
vous avez
eu ce logement
en travaillant sur
la base de la code global
de la base de la code global
Oui, la plupart
quand ils regardent
les choses comme F-sharp
et c'est un data mutable
ils pensent
mais comment ça fonctionne
vous savez,
ça ne peut pas être efficace
ça ne peut pas travailler
En fait,
les bénéfices que vous avez
de la code
ne font pas de la même manière
que les autres
Oui, je peux imaginer
même le C-sharp
nous utilitons les strings
qui sont mutables
c'est juste de la prochaine
exactement
Oui
Imaginez,
imaginez si les strings
et les dates sont mutables
comment plus de pain
avec cette cause
ça serait vraiment malin
donc oui
je veux dire
le fait que vous ne pouvez pas
changer
vous pouvez juste croire
si je passe le string
dans une fonction
je peux croire
que ce string ne va pas être changé
par un
quelqu'un
dans cette fonction
en faisant quelque chose de stupide
c'est juste
c'est vraiment
sympa de pouvoir
relier sur ça
et vous
vous juste
vous juste croyez sur la code
et imaginez
que tout était comme ça
Donc,
est-ce qu'il y a des scenarios
où vous ne vous utilisez pas
F-sharp
sur quelque chose de C-sharp
Je pense que ça va
en fait
à votre point
avant de faire
des choses comme
les frameworks d'entité
donc il y a des libraries
qui sont inévitables
et basées
ou reliant
sur des choses comme
la mutabilité
et je dirais
si vous
vous reliez sur
ces types de libraries
EF est un bon exemple
parce que
si vous utilisez
la tracé
le moyen que ça fonctionne
c'est que vous hydrate
une entité
vous modifiez la entité
et puis vous vous justez
l'update sur le contexte
et ça
vous fait des choses pour vous
ce genre de choses
ne se dévouent pas
bien avec
le moyen que F-sharp
vous aille
pour travailler avec
des données mutables
par exemple
et des fonctions

c'est un exemple
je dirais
si vous vous trouvez
et ça va en fait
à l'endroit de Ian
où vous sortez
en battant
contre le monde
en utilisant
des opératrices mutables
et des keywords
partout en F-sharp
c'est à dire
un signe
que
vous n'êtes pas
utilisant F-sharp
le moyen que c'est designé
ou les libraries
que vous utilisez
ne les rendent
bien pour F-sharp
il y a des exemples
comme ASP.net
où il y a des rappeurs
autour de ça
mais il y a des gens
qui ne jouent pas
bien
mais en termes de
domaines
je pense que
quelque chose qui a aidé
F-sharp
dans les derniers jours
mais pas beaucoup aujourd'hui
qui parle de
comme
F-sharp est une
science et math
qui est une chose
c'est juste
la langue de programme
de la genere
vous pouvez faire
des appels web
avec ça
on le fait tout le temps
vous pouvez
faire
vous savez
il n'y a pas de
quelque chose qui
fait F-sharp
mieux ou plus
en termes de
vous savez
quel type
de
business domain
vous êtes en train de travailler
vous pouvez
faire des apps end-to-end
vous pouvez faire des apps console
vous pouvez faire des apps web
vous pouvez faire des
analytiques
ça a travaillé
relativement bien
pour tous les
des areas
il y a des areas
où les gens
tendent
je pense
à descendre
le path F-sharp
parce que c'est des areas
où peut-être
le C-sharp n'a pas
eu un fort
histoire dans le passé
comme le côté analytique
mais ça ne veut pas
que F-sharp
soit moins
dans les autres areas
c'est pas le jeu
de 0 sum
dans ce regard
tout ce que nous avons
découvert aujourd'hui
ça me fait
vraiment
vraiment
aller
faire plus de choses
avec ça
mais l'un des problèmes
que je trouve
est que
chaque company que je travaille
fait un C-sharp
donc vous trouvez
que
parce que le C-sharp
la popularité
et surtout je pense
avec le C-sharp
se termine plus fonctionnel
aussi
est-ce que le C-sharp
la communauté est
en train de se faire
ou
je pense que
à la very start
j'ai hinté
le fact que
je faisais plus
un programme fonctionnel
C-sharp
m'a fait me
faire apprendre
le C-sharp
encore plus
donc peut-être
c'est assez commun
peut-être
c'est pas un peu
pas sûr
c'est pas ça
c'est pas ça













c'est pas ça
c'est pas ça
c'est pas ça

c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça


c'est pas ça

c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça


c'est pas ça
c'est pas ça


c'est pas ça



c'est pas ça












c'est pas ça
c'est pas ça


c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça



















c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça


c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça


c'est pas ça
c'est pas ça
c'est pas ça








c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça



c'est pas ça


c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça


c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça

c'est pas ça

c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça


c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça
c'est pas ça

c'est pas ça
c'est pas ça
c'est pas ça

c'est pas ça
c'est pas ça
c'est pas ça
Juste avoir un type de choix, un type de succession ou un type de choice avec oui ou non,
peut-être, et de ne pas en faire, et tout ça.
Et un Async, vous pouvez avoir un Async data structure qui contient une fonction de callback
et tout ça.
Ce n'est pas un monad, et les gens s'appliquent ce genre de choses.
C'est juste un data structure avec des trucs dans le monde.
C'est pourquoi les gens font ça complémentairement.
Donc monad a un sens mathématique, et je ne vais pas le faire,
mais c'est juste une façon de changer ces choses ensemble.
C'est un problème très common.
Vous avez un peu d'options, vous voulez changer les choses ensemble.
Vous avez un peu d'async types, et vous voulez changer les choses ensemble.
Vous avez un peu d'expressions, des types de pars,
ou quelque chose d'autre, et vous voulez changer les choses ensemble.
Il y a une technique pour changer les choses ensemble,
qui est où les monads sont utiles.
C'est tout ce que je vais dire.
Dan, pensez-vous du operator Elvis dans C-Sharp et de Async en C-Sharp.
Ce sont les deux les deux spécialistes de la décision avec un effet.
Je dois faire des choses avec Async.
Je ne veux pas faire des choses à chaque fois,
ou je veux faire des choses avec une nulle capacité.
Je ne veux pas faire des choses à chaque fois.
Si vous pouvez dériver la commonance entre ces deux problèmes,
c'est comme les cruces de ce que je pense que monad a.
Oui, c'est ça.
Je ne vais pas me faire embarrasser,
en essayant d'expliquer.
Je n'ai pas fait une sorte d'usage,
et je pense que les gens l'ont compris.
Mais c'est pas nécessaire.
C'est pas nécessaire.
Pour le programme, vous ne devez pas comprendre les monads.
Absolument.
Cool.
Je me dis que je vais me faire rassembler,
mais je n'ai pas fait des dev-tips.
Je pense que tous les gens ici ont dit qu'ils ont fait un dev-tip.
Non.
Non, mais me demandez de quoi me faire.
C'est probablement au final.
On a eu le temps de penser à quoi.
Je ne vais pas faire mon dev-tip.
Je ne vais pas faire mon dev-tip.
Je suis assez similaire à celui que nous avons déjà eu
avec Stuart Leeks,
où il a dit de me demander tout.
Je vais vraiment essayer de comprendre
pourquoi une change de code a été faite.
Je lui ai dit un call en zoom avec un ami de l'autre jour,
et il m'a demandé de m'aider avec la base de code
et il était né de cette base de code.
Et comme nous regardons les changements,
il a rapidement été apparent
qu'il avait changé, très bien,
et qu'il n'a pas eu de la base de code.
Il était né de la base de code.
Il avait changé tout le temps
et n'a pas vraiment compris la picture de base de code.
Ce n'est pas pour lui
parce que c'est quelque chose que je vois beaucoup.
C'est quelque chose que j'ai été méchant
pour le passé,
pour le faire sans prendre un step-back.
Je pense que beaucoup de nos listeners
peuvent relayer parce que c'est humain.
Mais ça peut être un code frustré.
Donc mon tip est de
prendre un step-ac
et prendre un temps d'understand
le code avant de le dégager.
Qu'est-ce que les patterns de design existant ?
Qu'est-ce que l'intention que les développeurs
de l'an dernier ont eu
en construisant et en architecturant.
Et prendre ce temps en avant
peut vraiment faire travailler avec la base de code
et être plus enjoyable, moins frustré.
Ok, donc je n'ai pas un code relative,
qui est
le meilleur code
qui n'est pas l'important.
Donc mon tip est
qu'il y a une différence
d'être efficace et
d'être efficace.
L'efficacité est
comme une balle de l'air, c'est 5%
ou 10% plus efficace que ce que vous faites.
L'efficacité est en train de faire le bon travail.
Il n'y a pas de point de être super efficace
si vous allez dans la direction de la même direction.
C'est comme avoir un très rapide car
vers un bicyclicien.
Si vous êtes dans un rapide car,
vous allez dans la direction de la même direction.
Le bicyclicien va encore vous faire plus vite
parce que c'est en train de faire la même direction.
On a eu beaucoup de temps de parler
d'efficacité et de la
vitesse et de
points de histoire, et de la façon dont
on peut faire ça rapidement.
Ce n'est pas un mauvais truc, mais
on doit penser que nous sommes dans la même direction.
Et c'est
beaucoup pour moi, de la entendre des gens,
de la entendre des gens qui ne sont pas développeurs,
de la entendre et de ne pas
penser que vous avez toutes les solutions.
C'est mon tip de la dév.
C'est un bon tip.
C'est un bon point.
Mon tip de la dév, je vais le faire rapidement,
c'est de s'en prendre plein de sleep.
C'est un bon point, très important, absolument.
C'est un bon point. Je me souviens d'ailleurs,
il y a des années, je l'ai lu un livre
d'hommes, pourquoi nous sommes sleep
par Matt Walker, je pense,
et c'est un livre
qui change de vie.
Vous pensez que vous êtes clé à ne pas
dormir très bien, mais en fait
vous êtes
pas
affectifs.
Un point qu'il parle de c'est
que quand vous soyez, votre cerveau
est en fait processant ce que vous avez appris.
Donc, par ne pas dormir,
vous n'êtes pas appris à ce que vous soyez
si vous n'avez pas de sleep.
C'est un bon point, et je vais
l'inclure dans les notes de la dév.
C'est un bon tip.
Je vous recommande beaucoup.
Mon tip, je pense, serait de serrer
avec un vain similaire, pour ce que les autres gens ont dit,
mais ne vous dévouez pas
pour tenter de solider toute l'éventualité
qui peut peut-être
arriver en mois ou
des années sur la ligne.
Il y a toujours un point de la slide
entre solider les problèmes de aujourd'hui
et peut-être solider les problèmes de demain.
Focusser sur les problèmes de demain
et peut-être pour demain,
plutôt que aujourd'hui,
demain et 5 ans sur la ligne.
L'amount de temps que j'ai réveillé
les solutions, où c'était un très
fort et architecturé plan solution, mais
on n'a pas besoin
de 75% de ce que nous avons fait.
C'est quelque chose que j'ai
essayé de apprendre et de le faire maintenant.
Vous ne pouvez pas dévouer pour toute l'éventualité.
Vous allez toujours faire quelque chose
qu'il faut finalement changer dans le futur.
C'est juste la nature du software
et des requirements de changement.
Je pense que c'est le point de la
aquanome, la Jagny, vous ne vous en avez pas besoin.
Je pense
que Sandy Matts,
un programme de
Ruby World, a dit
ne pas faire le code qui s'envole le futur,
faire le code qui adapte le futur quand il arrive.
Bien.
C'est un code mentinable.
C'est un de plus de 6e façon de dire
ce que je dis.
C'est pourquoi elle est un
développeur.
Une façon non fonctionnelle.
Cool.
Avant de nous rappelons,
est-ce que quelqu'un a d'autre qu'il veut mentionner?
Je dirais
qu'il y a un grand nombre
de matériels f-sharp
pour les gens qui...
Il y a beaucoup de matériels beginner,
donc ne vous inquiétez pas.
Et parfois, vous devez lire
des blogs différents.
Il y a un peu de façon
d'expliquer.
Mais il y a beaucoup de blogs
comme Ian a dit.
Il y a beaucoup de vidéos
de la vidéo.
Il y a des livres de la vidéo.
Et il y a le f-sharp

Ne vous inquiétez pas.
C'est un peu de fun de faire le f-sharp.
C'est probablement la plus belle communauté
que j'ai eu partie.
Je vais aller rejoindre
ce canal après cette vidéo.
Merci beaucoup
à tous les gens d'Ian, Isaac et Scott.
Merci à tous les gens d'avoir écouté.
Je vous remercie que ce podcast est
sponsorisé par Everstack,
qui est mon propre company,
qui donne des services de développement de software et de consultation.
Pour plus d'informations, visitez Everstack.com.
Et si vous aimez ce podcast,
s'il vous plait, vous pouvez me séparer
sur le nom de la social.
Je utilise le hashtag
UnhandledException.
Je peux être trouvé sur Twitter
et mon blog
d'Anclock.com a des liens
sur tout le monde.
Nous allons inclure les liens
pour toutes les choses qu'on a mentionnées
aujourd'hui dans les notes de la show,
qui peuvent être trouvées sur
unhandledexceptionpodcast.com
Sous-titres réalisés par la communauté d'Amara.org