Live data from Hacker News

A Conversation About OOP vs. FP Turns Constructive

github.com

51–60 of 81 posts

Re: A Conversation About OOP vs. FP Turns Constructive

#51
post #24

Earlier quoted context omitted.

> At this day and age people should be familiar with multiple paradigms. Whether procedural, functional, or Object-Oriented they are all useful. Why assume that "all are useful"? I'd say that most of them developed ad-hoc, and whether they are useful or not is subject to actual research on their effectiveness in the field, with controlled studies etc. Usually PL researchers go the other way around, toy with some thin…

They are all useful. Functional: reducing side-effects improves potential for concurrency; Object-Oriented: create a new type and overload operators to make it feel like the abstract mathematical idea it represents; Procedural: subroutines are pretty much indispensable.

Explain why FP doesn't do 'create a new type and overload operators to make it feel like the abstract mathematical idea it represents' better with say, parametric polymorphism?

Re: A Conversation About OOP vs. FP Turns Constructive

#52
post #51

Earlier quoted context omitted.

They are all useful. Functional: reducing side-effects improves potential for concurrency; Object-Oriented: create a new type and overload operators to make it feel like the abstract mathematical idea it represents; Procedural: subroutines are pretty much indispensable.

Explain why FP doesn't do 'create a new type and overload operators to make it feel like the abstract mathematical idea it represents' better with say, parametric polymorphism?

Just my two cents, but regardless of whether it is a more pure representation, I'd say it is empirically more difficult for the average, object-oriented human to wrap their brain around.

At least on that measure, the object oriented paradigm has demonstrated some success.

Re: A Conversation About OOP vs. FP Turns Constructive

#53

Earlier quoted context omitted.

Indeed, for example I think that the so-called "reliability" offered by FP is can be attributed to comparable simple tasks these developers work on. It's typically some form of parsing data.

Come on frozenport, do you really think that applies to Standard Chartered, Jane Street, or FB?

While the motivation for their models might be complex or esoteric, calculating out the parameters might as well be done in Excel. Typically, the data flow is linear, and well suited for FP.

But it ain't hard either.

The kind of complexity I'm referring to is the need to synchronize and coordinate concurrency in a time efficient manner, along with the user interaction that is found in desktop applications - or in my case that controls hardware instruments.

Re: A Conversation About OOP vs. FP Turns Constructive

#54
post #12

Earlier quoted context omitted.

If you are a professional developer you should always be learning and growing your skill set. You don't have to learn about functional programming, but choosing to remain ignorant does not reflect well on you. There's a difference between learning about it and using it at work. Your job may not have any good opportunities to apply FP, but you should be learning about it in your spare time given how many great use cas…

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…

Even in those jobs, there are always tangential tasks, one-offs, and side projects that could potentially be done much more easily/efficiently using different tools than the primary codebase. Even when using the same tools, different ways of thinking (patterns, paradigms) can make a huge difference.

The tools used to build GUI CRUD apps may be very well suited to that, but sooner or later all that data collected by the CRUD GUI will need to be processed, analyzed, and/or migrated. Although that might be doable with your CRUD GUI building knowledge, other tools or approaches, more well-suited to data processing, could make that task far easier, better, faster, and more reliable.

A legacy system from pre-networked days may be optimized well within the environment that it was created for, but when the day comes to make it connectable with an API, different skills may be useful. If you refuse to learn them, then either you have to hire someone else or you are likely to end up with a mess.

Re: A Conversation About OOP vs. FP Turns Constructive

#55
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…

I'd love if you can point out the incorrect points, but I understand that's not your responsibility. Thanks for the feedback!

Re: A Conversation About OOP vs. FP Turns Constructive

#56
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.

I would love some constructive feedback on how to do better, thanks.

Re: A Conversation About OOP vs. FP Turns Constructive

#57
post #21
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.

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.

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

Re: A Conversation About OOP vs. FP Turns Constructive

#58

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

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.

Re: A Conversation About OOP vs. FP Turns Constructive

#59

Earlier quoted context omitted.

For now maybe. But I think it is short sighted to think that trend is guaranteed to continue. Down the road, as other developers pick up different paradigms and can potentially implement the same features you are writing, with a fraction of the bugs and in a fraction of the time, why would companies keep paying you six figures?

why would you believe companies would pay multiple people lower salaries, totalling more than a single six figure salary when benefits and taxes are factored in? It's easy to ignore large corporations and both government and private institutions, but they are not interested in efficient quick fire best solutions, they mostly care about things simply not breaking, and veeeery slowly moving towards what 5 years ago was…

The history of employment is littered with the misfortunes of those who expected that one narrow and not particularly deep skill would set them for life, and the trend is accelerating.

Beyond that, there is the issue of whether you would prefer to work on something interesting, all else being equal. Of course, for that to be an issue, one first must be interested in something.

Re: A Conversation About OOP vs. FP Turns Constructive

#60
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…

If this discussion is about the use of the word "should", then it has been a waste of time.
Post reply on HN