Live data from Hacker News

A Conversation About OOP vs. FP Turns Constructive

github.com

31–40 of 81 posts

Re: A Conversation About OOP vs. FP Turns Constructive

#31
post #24
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…

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

Re: A Conversation About OOP vs. FP Turns Constructive

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

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

Because it's about the knowledge, and about doing what you do better, not merely about how much you earn.

"Give him threepence, since he must always make gain out of what he learns" -- Euclid said to his servant when a student asked what he would get out of studying geometry.

Re: A Conversation About OOP vs. FP Turns Constructive

#33

Earlier quoted context omitted.

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.

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 future, just incase the actualy 5 years from now prognosis doesn't pan out.

Learn all you like, it's a great idea and makes you a versatile developer ("for some, X is great"), but don't ignore a very real part of the world where versatility is literally a non-issue, and being able to maintain an aging codebase without suggesting changes is what gets you set for life. Claiming that "everyone should X" ignores the real world.

Re: A Conversation About OOP vs. FP Turns Constructive

#34
post #24
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…

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

The flip side of the lack of scientific evidence is that you have no reason to believe that any paradigm you happen to know well is any better than the others. So if you can't trust other people's opinions (which when they are in the form of popularity surveys and shiny blog posts I absolutely agree with), how else are you going to find such evidence than to try using ideas you're unfamiliar with?

Re: A Conversation About OOP vs. FP Turns Constructive

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

Then the company decides to outsource the IT doing the maintenance of that complex codebase to an Indian off-shoring company and fire 80% of the team, leaving just the ones needed to work as technical leads for the off-shoring team.

Now those guys are stuck with outdated skills that no one wants to hire.

Re: A Conversation About OOP vs. FP Turns Constructive

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

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?

Re: A Conversation About OOP vs. FP Turns Constructive

#38

Earlier quoted context omitted.

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

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

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).

Re: A Conversation About OOP vs. FP Turns Constructive

#39

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…

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

What makes you think that programmers who are used to writing in FP style for mission critical components would step away from FP for OOP for less important code? In my experience, most of the time functional code is often more succinct and easier to write. I don't think it would benefit anyone to write the majority of an application in the more verbose style.

>languages like Go explicitly making trade offs towards simplicity

I think Go is a counterargument to your point here. It's simplicity makes it much less suited for multi-paradigm programming than a complex language like C++ or Scala.

Re: A Conversation About OOP vs. FP Turns Constructive

#40

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…

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

What makes you think that programmers who are used to writing in FP style for mission critical components would step away from FP for OOP for less important code? In my experience, most of the time functional code is often more succinct and easier to write. I don't think it would benefit anyone to write the majority of an application in the more verbose style.

>languages like Go explicitly making trade offs towards simplicity

I think Go is a counterargument to your point here. It's simplicity makes it much less suited for multi-paradigm programming than a complex language like C++ or Scala.

Post reply on HN