A Conversation About OOP vs. FP Turns Constructive • Hacker News Board

Re: A Conversation About OOP vs. FP Turns Constructive

#41

Post by TheRealPomax » Sat, Sep 10, 2016, 5:24 PM UTC

ebbv wrote: post #23

TheRealPomax wrote: post #19

Earlier quoted context omitted.

the real world does not particularly line up with that statement. For a fast moving contract based world, sure, but there's also the other part of the programming landscape where codebases need to be maintained forever for institutions and large companies whose idea of stable is even stricter than OpenBSD. I know plenty of people who work on both, and the second category gets paid very good money indeed to be the sol…

I'm not sure how your response applies to my comment? I said that your particular job may not provide an opportunity for FP but you should still learn it for the sake of professional development. Even if you never need a job that uses FP, you should understand it so that you understand why you don't need it in your job. Even if you never leave your job, having those skills will help you push for a raise and move you…

And my response is still "why should they"?

Mind you, that's in part because of the ambiguity of the term "should": are you using the "should, as in nice to do but not required" or "should, as in required, and not doing it is wrong", because I'm on board with the first, but that is not how the original comment reads. That reads more like everyone should be familiar with multiple paradigms and not following that rule is bad. Which the real world heavily disputes.

Re: A Conversation About OOP vs. FP Turns Constructive

#42

Post by seagreen » Sat, Sep 10, 2016, 5:25 PM UTC

ebbv wrote: post #4

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.

  FP and OOP are both just tools, how you use them is
  way more important than which tool you choose.

I agree with this. I would note though that experienced developers don't always consider them equivalent tools, for instance Carmack suggests defaulting to FP when possible (from here: http://www.gamasutra.com/view/news/169296/Indepth_Functional...):

" No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient. "

Re: A Conversation About OOP vs. FP Turns Constructive

#43

Post by knucklesandwich » Sat, Sep 10, 2016, 5:26 PM UTC

jblow wrote: post #3

nitrix wrote: post #2

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 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 t…

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

Haskell definitely has problems. I'm a huge fan of the language, but I think its disingenuous to pretend like its flawless.

To name a few:

1. Poor debugging tools. Unfortunately this is sort of intrinsically tied with non-strict evaluation. Typical evaluation stepping debuggers would be sort of unpredictable in haskell. Along these lines, haskell doesn't have stack traces enabled by default, and reading them is sort of tricky.

2. Clumsy exceptions model. There are asynchronous and synchronous exceptions, with the later being further broken down into exceptions in pure code or exceptions thrown in IO. Only exceptions thrown in IO are catchable. You can think of exceptions in pure code as similar to "panic()" calls in other languages, except they're even tricker due to lazy evaluation, and aren't necessarily guaranteed to be triggered due to slipperiness with laziness. Also since exceptions are used for interrupting computations (timeouts, for instance) and there isn't a way (other than some type class conventions) to distinguish between interrupting exceptions that should be allowed to propagate and exceptions due to "exceptional circumstances", catching all exceptions safely is a tricky matter.

3. Record syntax leaves a lot to be desired. It's incredibly easy to run into situations where you would have conflicting functions due to record syntax. Lenses are a partial fix for this, but its sort of annoying that something like row polymorphism isn't just a part of the language.

4. Laziness can make reasoning about time and space complexity trickier. Generally this is a little overstated, but you'll occasionally run into space leaks.

There are definitely real problems with the language, and some of them (such as poor debugging capabilities) can be legitimate showstoppers to use in industry, but generally I find that its advantages far outweigh its negatives.

Re: A Conversation About OOP vs. FP Turns Constructive

#44

Post by mcphage » Sat, Sep 10, 2016, 5:26 PM UTC

fowlerpower wrote: post #6

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 maki…

> I also believe the crazy complexity of OO languages like Java is slowly being reigned in.

Java itself is a pretty simple language, and the complexity of programs written in Java is partially due to the spareness of the language.

Re: A Conversation About OOP vs. FP Turns Constructive

#45

Post by elmigranto » Sat, Sep 10, 2016, 5:27 PM UTC

gfunk911 wrote: post #37

Put it in a more readable format here: https://gist.github.com/mharris717/cb2111a4f74ea1ef7f3a5de90...

I'm not sure if right-aligned text is more readable.

Re: A Conversation About OOP vs. FP Turns Constructive

#46

Post by rjbwork » Sat, Sep 10, 2016, 5:29 PM UTC

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.

Re: A Conversation About OOP vs. FP Turns Constructive

#47

Post by lojack » Sat, Sep 10, 2016, 5:29 PM UTC

TheRealPomax wrote: post #9

wangchow wrote: post #7

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 acros…

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.

If you're a developer making six figures and aren't really interested in staying up to date with current trends or becoming a better developer, then it may be a waste of time. This attitude may come back to bite you in the ass in ten years when you're looking for a new job and find that your skills are no longer applicable to the modern workforce.

I will say that it's virtually impossible to be purely an OOP programmer without using ideas that originated with imperative or functional languages. It's also pretty difficult to be a really good OOP developer without writing at least some code that looks very functional. There's a lot of ideas and techniques that help you as a developer no matter what paradigm you choose.

Re: A Conversation About OOP vs. FP Turns Constructive

#48

Post by musesum » Sat, Sep 10, 2016, 5:36 PM UTC

From Bill Gathan: http://www.codenewbie.org/blogs/object-oriented-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/) 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.

Re: A Conversation About OOP vs. FP Turns Constructive

#49

Post by ebbv » Sat, Sep 10, 2016, 5:36 PM UTC

TheRealPomax wrote: post #41

ebbv wrote: post #23

Earlier quoted context omitted.

I'm not sure how your response applies to my comment? I said that your particular job may not provide an opportunity for FP but you should still learn it for the sake of professional development. Even if you never need a job that uses FP, you should understand it so that you understand why you don't need it in your job. Even if you never leave your job, having those skills will help you push for a raise and move you…

And my response is still "why should they"? Mind you, that's in part because of the ambiguity of the term "should": are you using the "should, as in nice to do but not required" or "should, as in required, and not doing it is wrong", because I'm on board with the first, but that is not how the original comment reads. That reads more like everyone should be familiar with multiple paradigms and not following that rule…

I think it's pretty clear from my comment that I'm saying should in the same sense as you should not smell like a dumpster on a hot day and you should be nice to work with.

Technically it's not required, but if you don't then you're lazy and probably not a great employee.

Re: A Conversation About OOP vs. FP Turns Constructive

#50

Post by johncolanduoni » Sat, Sep 10, 2016, 5:57 PM UTC

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?