6 ms·

There is no future in a strict adherence to one programming paradigm. Any sufficiently large program will have parts that are expressed best in different parad

There is no future in a strict adherence to one programming paradigm. Any sufficiently large program will have parts that are expressed best in different paradigms. One part of a program wants to be functional, another imperative, another object-oriented, etc. We need less languages that make an opinionated statement about the one true way and the one true paradigm. A paradigm is a tool of expression, and we need to be able to use the right one when needed. We need general-purpose, extensible languages.

nbz118 10y ago
I completely agree with this. I've been doing professional Scala for about 7 years now and I have long moved past the phase of trying to make all my code "pure" and "functional". While I'd say my code always maintains a more functional feel than Java or C++, many problems are just more elegantly and efficiently solved with OOP and imperative/mutable designs.
preordained 10y ago
Yes. This is the software "engineer" answer. Nothing sacred, each choice is simply a trade off. Sometimes an FP lense is the best one to view and tackle the problem with, when it's not you use something else. You don't strain or try to unnaturaly shift the goal posts--you use something else.
- hermitdev 10y ago
  Wholeheartedly agree with this. Right tool for the problem at hand, and sometimes that means using multiple tools (or paradigms). Incidentally, one of the things I like about Python, in that is so easily lets you mix paradigms such as FP & OOP. Certain use cases just don't naturally fit w/ a pure FP style, nor a pure OOP style, but sometimes a healthy mix of both is in order. One of the areas FP really wins is in ease to introducing parallelism. If all of your parallel functions are pure, introducing parallelism should be a non-issue. Results of a function only depend on the (non-global, immutable arguments and, possibly, immutable global state). Shared mutable state is the bane of all parallel programming. Shared mutable state necessitates locking of some form, and even experts get it wrong (and non-experts get it wrong very frequently) - personal experience, no citations.
PaulAJ 10y ago
I disagree. Of course we need general-purpose, extensible languages. We also need motherhood and apple pie. But multi-paradigm languages are usually mistakes. They aim to give you the best of multiple worlds but frequently wind up giving you the worst. We saw this with C++, which was supposed to be a structured / OO hybrid. The trouble was, the mismatch between the strucutred world and the OO world created huge complexity, starting with functions that might or might not be virtual. Non-virtual destructors anyone? Not to mention the fact that structured programming doesn't use GC, but proper OO programming requires it. See http://www.ipipan.gda.pl/~marek/objects/faq/oo-faq-S-3.12.html http://www.ipipan.gda.pl/~marek/objects/faq/oo-faq-S-3.12.ht... for the reasons why. The problems get even bigger when you try to hybridise functional and OO paradigms: * In OO the core concept is the mutable object. An object has an identity that persists as it mutates, and you can distinguish between two otherwise identical objects because they have different identities. Hence the distinction in all OO languages between reference equality (two references pointing at the same object) and object equality (two distinct objects that are equal in all their fields). * In the functional paradigm, on the other hand, there are only values. Asking if two strings are the same object, or two employee records, is as meaningless as asking if two "3" values are the same object. Values are also immutable, so the idea of changing a string or employee value is as meaningless as changing "3" to be "4". So when you create a hybrid functional/OO language you must deal with this impedance mismatch. If objects are mutable then the order of execution matters, and you have to trust the programmer to get the data flow and control flow to agree, thereby losing the big advantages of the functional paradigm. If objects are not mutable then you don't have an OO programming language. Finally, I do not believe that "Any sufficiently large program will have parts that are expressed best in different paradigms". Claims that some domain is best expressed in one particular paradigm always seem to end up with statements of the form "Yes, but I want to do this my way, and your paradigm makes me do it your way". Sure, if you try to write Haskell in an OO way you are in for a world of pain, but that just means that when using a functional language you should architect your application in a functional way. And similarly for an OO language of course. I spent a long time in the OO world, and I've used the best OO language ever designed (Eiffel). I moved to Haskell, and have become convinced that for most general purpose programming the functional paradigm is superior to OO. (The exceptions are in hard real-time and resource-bound environments). And the reason is that Backus was right.

nbz118 10y ago

I completely agree with this. I've been doing professional Scala for about 7 years now and I have long moved past the phase of trying to make all my code "pure" and "functional". While I'd say my code always maintains a more functional feel than Java or C++, many problems are just more elegantly and efficiently solved with OOP and imperative/mutable designs.

preordained 10y ago

Yes. This is the software "engineer" answer. Nothing sacred, each choice is simply a trade off. Sometimes an FP lense is the best one to view and tackle the problem with, when it's not you use something else. You don't strain or try to unnaturaly shift the goal posts--you use something else.

hermitdev 10y ago
Wholeheartedly agree with this. Right tool for the problem at hand, and sometimes that means using multiple tools (or paradigms). Incidentally, one of the things I like about Python, in that is so easily lets you mix paradigms such as FP & OOP. Certain use cases just don't naturally fit w/ a pure FP style, nor a pure OOP style, but sometimes a healthy mix of both is in order. One of the areas FP really wins is in ease to introducing parallelism. If all of your parallel functions are pure, introducing parallelism should be a non-issue. Results of a function only depend on the (non-global, immutable arguments and, possibly, immutable global state). Shared mutable state is the bane of all parallel programming. Shared mutable state necessitates locking of some form, and even experts get it wrong (and non-experts get it wrong very frequently) - personal experience, no citations.

PaulAJ 10y ago

I disagree. Of course we need general-purpose, extensible languages. We also need motherhood and apple pie. But multi-paradigm languages are usually mistakes. They aim to give you the best of multiple worlds but frequently wind up giving you the worst. We saw this with C++, which was supposed to be a structured / OO hybrid. The trouble was, the mismatch between the strucutred world and the OO world created huge complexity, starting with functions that might or might not be virtual. Non-virtual destructors anyone? Not to mention the fact that structured programming doesn't use GC, but proper OO programming requires it. See http://www.ipipan.gda.pl/~marek/objects/faq/oo-faq-S-3.12.html http://www.ipipan.gda.pl/~marek/objects/faq/oo-faq-S-3.12.ht... for the reasons why. The problems get even bigger when you try to hybridise functional and OO paradigms: * In OO the core concept is the mutable object. An object has an identity that persists as it mutates, and you can distinguish between two otherwise identical objects because they have different identities. Hence the distinction in all OO languages between reference equality (two references pointing at the same object) and object equality (two distinct objects that are equal in all their fields). * In the functional paradigm, on the other hand, there are only values. Asking if two strings are the same object, or two employee records, is as meaningless as asking if two "3" values are the same object. Values are also immutable, so the idea of changing a string or employee value is as meaningless as changing "3" to be "4". So when you create a hybrid functional/OO language you must deal with this impedance mismatch. If objects are mutable then the order of execution matters, and you have to trust the programmer to get the data flow and control flow to agree, thereby losing the big advantages of the functional paradigm. If objects are not mutable then you don't have an OO programming language. Finally, I do not believe that "Any sufficiently large program will have parts that are expressed best in different paradigms". Claims that some domain is best expressed in one particular paradigm always seem to end up with statements of the form "Yes, but I want to do this my way, and your paradigm makes me do it your way". Sure, if you try to write Haskell in an OO way you are in for a world of pain, but that just means that when using a functional language you should architect your application in a functional way. And similarly for an OO language of course. I spent a long time in the OO world, and I've used the best OO language ever designed (Eiffel). I moved to Haskell, and have become convinced that for most general purpose programming the functional paradigm is superior to OO. (The exceptions are in hard real-time and resource-bound environments). And the reason is that Backus was right.