
A Conversation About OOP vs. FP Turns Constructive - svanderbleek
https://github.com/svanderbleek/haskellandchill.com/blob/master/a-conversation-about-oop-vs-fp-turns-constructive.md
======
wangchow
At this day and age people should be familiar with multiple paradigms. Whether
procedural, functional, or Object-Oriented they are all useful. This is why
you see languages like C++, Java, and C# adding support for them all.

It is useful to express a particular problem domain in a way that is efficient
and makes sense.

I would be more interested in a discussion about concurrency because it
becomes more relevant across the programming-language or paradigm barrier.
Because at the end of the day we are confined by how the hardware operates and
concurrency is very much a modern way of thinking as developers.

~~~
TheRealPomax
realist contrarian question: why? If you didn't receive a formal education but
you got good at OOP js or php, your expected salary gets pretty close to six
figures. No understanding or even theoretical appreciation of other paradigms
required. And I say that as someone with a formal education in programming and
decent understanding of most programming paradigms.

~~~
wangchow
Because for those who don't understand or explore other paradigms their
skillset is limited. There is a lot to be learned in concurrency domain from
functional paradigms. Take a look at intel threading-building-blocks which is
a modern way to look at concurrency and it is very much using functional
concepts. For instance, parallel_for, parallel_reduce, parallel_scan. Reducing
side-effects improves potential for parallelism.

[https://en.wikipedia.org/wiki/Threading_Building_Blocks](https://en.wikipedia.org/wiki/Threading_Building_Blocks)

~~~
TheRealPomax
That has never been a problem in a large part of the programming job market.
If your skill set fills the job opening a big coorporation or institution has,
and that job sets you up for life (instead of the frantic contract based work
for startups or small companies) then exploration is a luxury, but in no way a
necessity.

Note that logic applies here: I'm questioning the "you should know" claim, not
claiming "you should not know" because that would be ridiculous. Learn all you
like if you feel that gives you a leg up, or an enriched quality of
professional life, but it is absolutely not a requirement in a well-paying
part of the real world's programming landscape, so claiming "one should" is a
little rich.

~~~
wangchow
Well, this is true if all one is interested in is getting a job _today_.

However, the best developers aren't primarily concerned about getting a job or
not, they are genuinely interested in programming as both an art and a
science. Money and jobs is secondary (and readily available because such
individuals are more skilled than those that limit their pursuits).

~~~
sbov
Anyone who stereotypes the practices of the best developers is kidding
themselves. Some of the best developers I know only know C.

In reality there are roughly two types of tech: staples and new ones. Staples
are around for a long time, but HN tends to focus on new ones. The thing is,
even our modern staples came from a much larger set of new pieces of tech.

What this means is, that if you're using a piece of tech that has been popular
for at least 20 years, you're probably good for at least the next 20. If you
keep switching to the new hotness, you will have to keep doing that because
you are most likely learning stuff that won't stay around.

~~~
wangchow
Not stereotyping the best developers but saying that one who keeps an open
mind to new ideas will be a better at what they do. Now, obviously there are
limits to what people can do but more exposure is generally better.

C is all well and good (anything can be implemented in C) but one must
recognize that higher level languages serve one purpose: to help express
certain ideas in a _more concise_ and _easier-to-understand_ way than a lower-
level language. It can be very helpful to look at why a particular functional
language (just for example) achieves a result, and then implement the same
concept in C or even assembly if necessary. But by abstracting the problem
into a more simpler one, more complex ideas can be express.

Just look at integrals and derivatives in Math. One could compute derivatives
using the difference-quotient but that would make more complex ideas almost
impossible to understand. We create rules to help us derive common patterns,
then use those to build more powerful ideas in a simpler way.

~~~
ArkyBeagle
You don't (usually) solve a problem _directly_ in 'C' \- you build furniture
in 'C' that you arrange to then solve the problem.

Using a "higher level" toolset just means (possibly) buying rather than
building. Which is "better" is an economic decision, until people's self-
identity starts to get in the way.

I just remember a J2EE class, where every day we'd spend thirty minutes
updating all the bizarre tools, which would frequently break things. I'm
insufficiently venal to put up with that.

------
johncolanduoni
I think the OOP vs FP debate misses the real asset that functional programming
offers us, and it's not writing everything in [your favorite functional
language]'s typical style. Look at a language like Idris; a formal definition
of its unsugared semantics would fit on half a page easily. However it still
manages to give us all kinds of goodies, like effect tracking, compile-time
checking for virtually any condition you can write a decision procedure for,
and design-by-contract on steroids.

These features are useful whether the code you're writing is pure, stateful,
object-oriented, functional, and/or whatever paradigm you write up tomorrow.
Forget aesthetic arguments about elegance; where else can you build so much
without ad-hoc concessions to individual language features? As far as I know,
there's no other method that lets you treat powerful language features as
libraries without either (a) making a mish-mash when they're used together
like compiler plugins do (b) making debugging your compile process a full time
job like various strongly-typed macro systems tend to.

Why not use FP to form the fundamentals of our languages, something where as
of yet it has no equal, and build up the structures we need (regardless of
programming tradition of origin) on top of that?

~~~
svanderbleek
I like your points, but I'm not sure of the Idris on half a page. How much
tacit knowledge does that rely on? We do need to focus on the fundamentals of
education, the spectrum of logics with quantifiers, lambda calculus, and
natural deduction style presentations of language semantics (not sure what to
actually call this?).

~~~
delish
> How much tacit knowledge does that rely on?

It looks like you're criticizing the GP's praise of Idris' concise formal
definition of its unsugared semantics. I wouldn't use such a formal definition
for educating novices (like I think you're implying in your next sentence);
I'd use it professionally to show that many desirable things--effect tracking,
compile-time checking, and design-by-contract--derive from the same thing. Ken
Iverson in his notes on mathematical notation says that one criterion for a
good notation is "suggestibility"\--the notation should suggest that other
problems similar to those you found just now could be solved as well.

Whether formality is useful for novices, it is certainly useful for experts.

~~~
svanderbleek
I was just trying to tease out what you need to know so that Idris fits in
half a page. I'd actually like to know those things!

------
ebbv
This conversation is awful. This seems like a bunch of armchair developers
with really strong opinions and no real world experience.

No experienced developer I want to work with has the kind of dogmatic views
that most of the people in this chat log have. FP and OOP are both just tools,
how you use them is way more important than which tool you choose.

~~~
Bahamut
In addition, the discussion in that chat looks far from constructive...there
are legitimate uses of OOP, but they are ignored completely in lieu of
sweeping statements.

~~~
svanderbleek
I meant it turns into a constructive discussion of Haskell, I should have made
that clearer. Thanks!

------
fowlerpower
I really believe the future is a mixed OOP and FP world. I think we will see
industry use languages like Scala and F# more and more.

In mission critical portions of systems people will use a functional style and
try to isolate state, while most things in an OO style will be just fine.

I also believe the crazy complexity of OO languages like Java is slowly being
reigned in. With other languages like Go explicitly making trade offs towards
simplicity.

~~~
jjnoakes
I have no stake in pro-Go or anti-Go statements here, but I do want to say
that a simple language does not always lead to simple code in that language.

For example, if one has to copy and paste because a language is too simple to
provide a needed abstraction, then the code is needlessly complicated (through
duplication) because the language is too simple.

~~~
DubiousPusher
Exactly. C is a vastly smaller language than C++ but OO C is very complex with
factories booking up function pointers, lots of macros, etc.

Creating an object with runtime polymorphism in C++ is much simpler.

------
musesum
From Bill Gathan: [http://www.codenewbie.org/blogs/object-oriented-
programming-...](http://www.codenewbie.org/blogs/object-oriented-programming-
vs-functional-programming)

Michael Fogus, author of “Functional JavaScript”, suggests in his blog post
“FP vs OO, from the trenches” ([http://blog.fogus.me/2013/07/22/fp-vs-oo-from-
the-trenches/](http://blog.fogus.me/2013/07/22/fp-vs-oo-from-the-trenches/))
that when he deals with data about people, FP works well, but when he tries to
simulate people, OOP works well.

I wonder about shape of the data as it moves from domain -> range? How would
they map to machine and biological models for learning? First guess is the
that ML maps well onto FP; for CNNs, the data progresses synchronously from
one layer to the next. For Bio, state is asynchronous; neurons, after firing
have an efficacy period. Maybe super-fine-grain objects? Petri nets are
interesting in that they can feedforward state asynchronously.

------
nitrix
A few incorrect points during the discussion as well as poorly approached. The
only thing beneficial that I see from it is people trying to better their
skills and Haskell gaining traction.

I personally would recommend #haskell-beginners on freenode IRC as well as
[http://haskellbook.com](http://haskellbook.com) for the ones interested.

For everybody else, well I'm not a sale person and my job isn't to convince
you. If it takes you 30 years to (re)discover Haskell, so be it.

~~~
jblow
Haskell has been around for over 20 years. If it hasn't set the programming
world on fire yet, there are probably reasons.

~~~
embwbam
Like we only now see how bad large OO systems can be? :D.

Seriously though I think that people are becoming interested in FP because
they see the limitations of their current tools. That's what happened for me
anyway.

Also I don't know that Haskell will become mainstream, but something that
looks way more like Haskell than Java will.

------
rjbwork
Most statically typed programs/systems these days (Java, C#, even C++ if you
wish) these days, use DI via IoC containers as the mechanism for constructing
objects and choosing which code to run. You can even do it with dynamic
languages like JS/Python if you wish, though many argue it being dynamic means
you don't need to use a container - which is pretty true.

This approach is equivalent to a family of functions (with side effects), one
family per class, each with N(c) + N(m) arguments, where N(c) is the number of
constructor arguments, and N(m) is the number of method arguments. Upon object
construction, these families are partially applied to construct a new family
of functions that contain only N(m) arguments. You can think of a constructor
as a functor, that returns a number partially applied functions - the methods
on the classes.

This is how I actually think of my OO programs these days. I also make liberal
use of the actual functional tools made available to me. For instance, my
bread and butter is C#, and LINQ heavily promotes a purely functional style
when manipulating collections of data, though side effects are possible.

At a system level, I also tend to think of my data pipelines as functional
transformations as well - their being written as an OO program is of little
actual consequence.

~~~
edem
This is how I also work. You can use rudimentary languages like java to do FP
if you have the proper mindset.

------
gfunk911
Put it in a more readable format here:
[https://gist.github.com/mharris717/cb2111a4f74ea1ef7f3a5de90...](https://gist.github.com/mharris717/cb2111a4f74ea1ef7f3a5de90ae4a468)

~~~
svanderbleek
Cool, but I find that hard to read. I'm going to do a custom stylesheet, I was
just waiting to see if there was any interest in the conversational format
form my Slack conversations. Really appreciate your effort.

