WHERE DOES FUNCTIONAL PROGRAMMING COME FROM?
The first thing I want to get out of the way is that despite what some
people might think, Functional Programming is old. Really old - by
computing standards at least. My point being - it isn’t like the latest
trendy JavaScript framework, here this year, so much old news next
year. It predates all modern programming languages, and even
computing itself to some extent.
Functional has been around for longer than any of us, and it’s likely
to be around long after we’re all happily retired. My slightly
belabored point is that it’s worth investing your time and energy to
learn and understand it. Even if one day you find yourself no longer
working in C#, most other languages support Functional concepts to
a greater or lesser degree (JavaScript does to an extent that most
languages can only dream of), so these skills will remain relevant
throughout the rest of your career.
A quick caveat before I continue with this section - I’m not a
mathematician. I love mathematics, it was one of my favourite
subjects at school, college & university, but there eventually comes
a level of higher, theoretical mathematics that leaves even me with
glazed-over eyes and a mild headache. That said, I’ll do my best to
talk briefly about where exactly it was Functional Progamming
came from. Which was, indeed, that very world of theoretical
mathematics.
The first figure in the history of Functional Programming most
people can name is usually Haskell Brooks Curry (1900-1982), an
American mathematician that now has no fewer than three
programming languages named after him, as well as the Functional
concept of “Currying” (of which, more later). His work was on
something called “Combinatory Logic” - a mathematical concept
that involves writing out functions in the form of lambda (or arrow)
expressions, and then combining them to create more complex logic.
This is the fundamental basis of Functional Programming.
Curry wasn’t the first to work on this though, he was following on
from papers and books written by his mathematical predecessors,
people like:
Alonzo Church (1903-1955, American) - It’s Church that coined
the term “Lambda Expression” that we use in C#, and other
languages, to this day.
Moses Schönfinkel (1888-1942, Russian) - Schönfinkel wrote
papers on
Combinatory logic that were one of the bases for Haskell Curry’s
work
Friedrich Frege (1848-1925, German) - Arguably the first person to
describe the concept we now know as Currying. As important as it is
to credit the correct people with discoveries, Freging doesn’t quite
have the same ring.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
What about F#? Should I be learning F#?
This is probably the most common question I get asked. What about
F#? It’s not a pure Functional language, but the needle is far closer
to being a proper
implementation of the paradigm than C#. It has all sorts of
Functional tricks and toys available straight out-of-the-box, why not
use that?
I always like to check the available exits in the room before I answer
this question. F# has a passionate userbase, and they are probably all
much smarter folks than me9. But…
…no, I don’t think it’s worth learning F# before giving Functional
C# a try. It’s not because F# isn’t awesome. I don’t know F#, but
everything I’ve seen of it looks great, and something I’d love to play
with.
It’s not because F# isn’t easy to learn. It is, from what I’ve seen, and
most likely it’s easier to learn than C# if you’re entirely new to
programming.
It’s not that F# won’t bring business benefits, because I honestly
believe it will.
It’s not that F# can’t do absolutely everything any other language
can do. It most certainly can. I’ve seen some impressive talks on
how to make full- stack F# web applications.
It’s a professional decision. It isn’t hard to find C# developers, at
least in any country I’ve ever visited. If I were to put the names of
every attendee of a big developers’ conference in a hat and draw one
at random, there’s a better than even chance it would be someone
that can write C# professionally. If a team decides to invest in a C#
codebase, it’s not going to be much of a struggle to keep the team
populated with engineers that will be able to keep the code well
maintained, and the business relatively content.
Developers that know F# on the other hand are relatively rare. I
don’t know many. By adding F# into your codebase you may be
putting a dependency on the team to ensure you always have enough
people available that know it, or else take a risk that some areas of
the code will be hard to maintain, because few people know how.
I should note that the risk isn’t as high as introducing an entirely
new technology, like, say, Node.JS. F# is still a .NET language and
compiles to the same Intermediate Language. It would still be an
entirely unfamiliar syntax to the majority of .NET developers,
however.
It’s my firm wish that this changes as time goes on. I’ve liked very
much what I’ve seen of F#, and I’d love to do more of it. If my boss
told me that a business decision had been made to adopt F#, I’d be
the first to cheer.
Fact is though, it’s not really a very likely scenario at present. Who
knows what the future will bring. Maybe a future edition of this
book will have to be heavily re-written to accomodate all the love
for F# that’s suddenly sprung up, but for now I can’t see that on the
near horizon.
My recommendation would be to try this book first. If you like what
you see, maybe F# might be the next place you go on your
Functional journey.
Multi-Paradigm Languages
It can probably be argued that all languages besides the Pure
Functional languages are some form of hybrid. In other words, that
at least some aspects of the functional paradigm can be
implemented. That’s likely true, but I’m just going to look briefly at
a few where it can be implemented entirely, or mostly, and as a
feature provided explicitly by the team behind it.
JavaScript
JavaScript is of course almost the wild-west of programming
languages in the way that nearly anything can be done with it, and it
does Functional very, very well. Arguably better than it does Object
Orientation. Have a look for Javascript: The Good Parts by Douglas
Crockford and some of his online lectures (for example
https://www.youtube.com/watch? v=_DKkVvOt6dk) if you want an
insight into how to do JS Functionally and properly.
Python
Python has rapidly become a favourite programming language for
the open source community, just over the last few years. It surprised
me to find out it’s been around since the late 80s! Python supports
higher-order functions and has a few libraries available: itertools
and functools to allow further functional features to be implemented.
Java
The Java platform has the same level of support for Functional
features as
.NET. Further to that, there are spin-off projects such as Scala,
Clojure and Kotlin that offer far more Functional features than the
Java language itself does.
F#
I’ve already discussed this at length in a previous section, so I won’t
go into it much more now. This is .NET’s more purely Functional
style language. It’s also possible to have interoperability between C#
and F# libraries, so you can have projects that utilize all the best
features of both.
C#
Microsoft has slowly been adding in support for Functional
Programming ever since somewhere near the beginning. Arguably
the introduction of Delegate Covariance and Anonymous Methods
in C# 2.0 all the way back in 2005 could be considered the very first
item to support the Functional paradigm. Things didn’t really get
going properly until the following year when C# 3.0 introduced
what I consider one of the most transformative features ever added
to C#- LINQ.
I’ll talk more about it later, but LINQ is deeply rooted in the
Functional paradigm, and one of our best tools for getting started
writing Functional- style code in C#. In fact, it’s a stated goal of the
C# team that each version of C# that is released should contain
further support for Functional Programming than the one before it.
There are a number of factors driving this decision, but amongst
them is F#, which often requests new functional features from
the .NET runtime folks that C# ends up benefiting from too.
The Benefits of Functional Programming
I hope that you picked this book up because you’re already sold on
Functional Programming and want to get started right away. This
section might be useful for team discussions about whether or not to
use it at work.
Concise
While not a feature of Functional Programming, my favourite of the
many benefits is just how concise and elegant it looks, compared to
Object- orientated or Imperative code.
Other styles of code are much more concerned with the low-level
details of how to do something, to the point that sometimes it can
take an awful lot of code-staring just to work out what that
something even is. Functional programming is orientated more
towards describing what is needed. The details of precisely which
variables are updated how and when to achieve that goal are less of
our concern.
Some developers I’ve spoken to about this have disliked the idea of
being less involved with the lower levels of data processing, but I’m
personally happier to let the execution environment take care of that,
then it’s one thing fewer that I need to be concerned with.
It feels like a minor thing, but I honestly love how concise
Functional code is compared to the Imperative alternatives. The job
of a developer is a hard one10, and we often inherit complex
codebases that we need to get to grips with quickly. The longer and
harder it is to work out what a function is actually doing, the more
money the business is losing. Functional code often reads in a way
that describes in something approaching natural language, what it is
that’s being accomplished. It also makes it easier to find bugs,
which again saves time and money for the business.
Testable
One thing a lot of people describe as their favourite feature of
functional programming is how incredibly testable it is. It really is,
as well. If your codebase isn’t testable to something close to 100%,
then there’s a chance you didn’t follow the paradigm correctly.
Test-Driven Development (TDD) and Behavior-Driven
Devleopment (BDD) are important professional practices now.
These are programming techniques that involve writing automated
unit tests for the production code first, then writing the real code
required to allow the test to pass. It tends to result in better-
designed, more robust code. Functional Programming enables these
practices neatly. This in turn results in better codebase and fewer
bugs in production.
Robust
It’s also not just the testability that results in a more robust
codebase. Functional Programming has structures within it that
actively prevent errors either from occurring in the first place, or
else if they do, then preventing any unexpected behaviour further
on, and make it easier to report the issue accurately. There is no
concept of NULL in Functional Programming. That alone saves an
incredible number of possible errors.
Predictable
Functional code starts at the beginning of the code block and works
its way to the end. Exclusively in order. That’s something you can’t
say of Procedural Code, with its Loops and branching If statements.
There is only a single, easy to follow flow of code.
When done properly there aren’t even any Try/Catch blocks, which
I’ve often found to be some of the worst offenders when it comes to
code with an unpredictable order of operations. If the Try isn’t small
in scope and tightly coupled to the Catch, then sometimes it can be
the code equivalent of throwing a rock blindly up into the air. Who
knows where it’ll land and who or what might catch it. Who can say
what unexpected behavior might arise from such a break in the flow
of the program.
Improperly designed Try/Catch blocks have been at the back of
many instances of unexpected behavior in production that I’ve
observed over my career, and it’s a problem that simply doesn’t
exist in the Functional paradigm.
Improper error handling is still possible in Functional code, but the
very nature of Functional Programming discourages it.
Better Support for Concurrency
There are two recent developments in the world of software
devleopment that have become very important in the last few years:
Containerization
This is provided by products such as Docker and Kubernetes,
amongst others. This is the idea that instead of running on a
traditional server11 the application runs instead on something sort of
like a mini-Virtual Machine (VM) which is generated by a script at
deploy time. It isn’t quite the same, there’s no hardware emulation,
but from a user perspective the result is roughly the same. It solves
the “it worked on my machine” problem that is sadly all-too familiar
to many developers. Many companies have software infrastructure
that involves stacking up many instances of the same appliation in
an array of containers, all processing the same source of input.
Whether that be a queue, user requests, or whatever. The
environment that hosts them can even be configured to scale up or
down the number of active containers depending on demand.
Serverless
This might be familiar to .NET devleopers as Azure Functions or
AWS Lambdas. This is code that isn’t deployed to a traditional web
server, such as IIS, but rather as a single function that exists in
isolation out on a cloud hosting environment. This allows both the
same sorts of automatic scaling as is possible with containers, but
also micro-level optimizations, where more money can be spent on
more critical functions and less money on functions where the
output can take longer to complete.
In both of these technologies, there is a great deal of utilization of
concurrent processing; i.e. multiple instances of the same
functionality working at the same time on the same input source. It’s
like .NET’s Async features, but applied to a much larger scope.
The problem with any sort of asyncronous operations tends to occur
with shared resources, whether that’s in-memory state or a literal
shared physical or software-based external resource.
Functional Programming operates without state, so there can be no
shared state between threads, containers or serverless functions.
When implemented correctly, following the Functional paradigm
makes it much easier to implement these much-in-demand
technological features, but without giving rise to any unexpected
behavior in production.
Reduce Code Noise
In audio processing they have a concept called the Signal-to-Noise
Ratio. This is a measure of how clear a recording is, based on the
ratio of the volume level of the signal (the thing you want to listen
to) to the noise (hiss, crackle, rumble or whatever in the
background).
In coding, the signal is the business logic of a block of code - the
thing it is actually trying to accomplish. The what of the code.
The noise is all of the boilerplate code that must be written in order
to accomplish the goal. The For-loop definition, If statements, that
sort of thing.
Compared to Procedural code, neat, concise Functional
programming has significantly less boilerplate, and so has a much
better Signal-to-noise ratio.
This isn’t just a benefit to developers. Robust, easier to maintain
codebases means the business needs to spend less money on
maintainance and enhancements.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
The first Functional programming languages were:
IPL (Information Processing Language), developed in 1956 by
Allen Newell (1927-1992, American), Cliff Shaw (1922-1991,
American) and Herbert Simon (1916-2001, American)
LISP (LISt Processor), developed in 1958 by John McCarthy
(1927- 2011, American). I hear tell that LISP still has its fans to this
day, and is still in production use in some businesses. I’ve never
seen any direct evidence of this myself, however.
Interestingly, neither of these languages are what you would call
“pure” functional. Like C#, Java, and numerous other languages,
they adopted something of a hybrid approach, unlike the modern
“pure” functional languages, like Haskell and Elm.
I don’t want to dwell too long on the (admittedly, fascinating)
history of Functional Programming, but it’s hopefully obvious from
what I have shown, that it has a long and illustrious pedigree.
Who Else Does Functional Programming?
As I’ve already said, Functional Programming has been around for a
while, and it’s not just .NET developers that are showing an interest.
Quite the opposite, many other languages have been offering
Functional Paradigm support for a lot longer than .NET.
What do I mean by support? I mean that it offers the ability to
implement code in the Functional Paradigm. This comes in roughly
two flavours:
Pure Functional Languages
Intended for the developer to write exclusively Functional code. All
variables are immutable, offers Currying, Higher-order Functions,
etc. out-of-the-box. Some features of Object-Orientation might be
possible in these languages, but it’s very much a secondary concern
to the team behind them.
Hybrid or Multi-Paradigm Languages
These two terms can be used entirely interchangably. They describe
programming languages that offer the features to allow code to be
written in two or more paradigms. Often two or more at the same
time. Supported paradigms are typically Functional and Object-
orientated. There may not be a perfect implementation available of
any supported paradigms. It’s not unusual for Object Orientation to
be fully supported, but not all of the features of Functional to be
available to use.
Pure Functional Languages
There are also well over a dozen pure functional languages around,
here is a brief look at the most popular three in use today:
Haskell
Haskell is used extensively in the banking industry. It’s often
recommended as a great starting place for anyone wanting to really,
really get to grips with Functional Programming. This may well be
the case, but honestly, I don’t have the time or headspace free to
learn an entire programming language I never intend to use in my
day job.
If you’re really interested in becoming an expert in the Functional
Paradigm before working with it in C#, then by all means go ahead
and seek out Haskell content. A frequent recommendation for that is
“Learn You a Haskell For Great Good” by Miran Lipovača7. I have
never read this book myself, but friends of mine have and say it’s
great.
Elm
Elm seems to be gaining some traction these days, if for no other
reason that the Elm system for performing updates in the UI has
been picked up and implemented in quite a few other projects,
including ReactJS. This “Elm Architecture” is something I want to
save for a later chapter.
Elixir
A general-purpose programming language based on the same
Virtual Machine that Erlang runs on. It’s very popular in industry
and even has its own conferences annually.
PureScript
PureScript compiles to JavaScript, so it can be used to create
functional front-end code, as well as server-side code and desktop
applications in isometric programming environments - i.e. those like
Node.JS that allow the same language to be used client and server
side.
Is It Worth Learning a Pure Functional Language First?
For the time being at least, OO is the dominent paradigm for the vast
majority of the software development world, and the Functional
Paradigm something that has to be learned afterwards. I don’t rule
out that changing in future, but for now at least, this is the situation
we’re in.
I have heard people argue the point that, coming from OO, it would
be best to learn Functional Programming in its pure form first then
come back to apply that learning in C#.
If that’s what you want to do, go for it. Have fun. I have no doubt
that it’s a worthwhile endeavor.
To me, this perspective puts me in mind of those teachers we used to
have here, in the UK that insisted that children should learn Latin,
because as the root of many European languages, knowledge of
Latin can easily be transferred to French, Italian, Spanish, etc.
I disagree with this somewhat 8. Unlike Latin, Pure Functional
languages aren’t necessarily hard, though they are very unlike
Object-Orientated development. Those that have spent their careers
heavily involved in OO development will likely find it harder to
adjust.
Where Latin and pure functional languages are similar though is that
they represent a purer, ancestral form. They are both of only limited
value outside of a small number of specialist interests.
Learning Latin is also almost entirely useless unless you’re
interested in Law, classical literature, Ancient History, etc. It’s far
more useful to learn modern French or Italian. They’re easier
languages to learn by far, and you can use them now to visit lovely
places and talk to the nice people that live there.
There are some great French-language comics from Belgium too.
Check ‘em out. I’ll wait.
In the same way, very few places will ever actually use Pure
Functional languages in production. You’d be spending a lot of time
having to make a complete shift in the way you work, and end up
learning a language you’ll probably never use outside of your own
hobby code. I’ve been doing this job for a long time, and I’ve never
yet encountered a company using anything more progressive in
actual production than C#.
The lovely thing about C# is that is supports OO and Functional
almost equally, so you can shift between them as you please. Use as
many features from one paradigm or the other as you like without
any penalty. The paradigms can sit fairly comfortably alongside
each other in the same codebase, so it’s an easy environment to
transition from pure OO to Functional at a pace that suits you, or
vice-versa.
That isn’t possible in a pure Functional language, even if there are a
lot of Functional features that aren’t possible in C#.
