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…
A Conversation About OOP vs. FP Turns Constructive
31–40 of 81 posts
Re: A Conversation About OOP vs. FP Turns Constructive
#32At 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.
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
#33Earlier 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?
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
#34At 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…
Re: A Conversation About OOP vs. FP Turns Constructive
#35Earlier 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…
Now those guys are stuck with outdated skills that no one wants to hire.
Re: A Conversation About OOP vs. FP Turns Constructive
#36This 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.
Re: A Conversation About OOP vs. FP Turns Constructive
#37Re: A Conversation About OOP vs. FP Turns Constructive
#38Earlier 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…
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
#39I 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…
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
#40I 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…
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.