Click here to Skip to main content
15,881,248 members
Please Sign up or sign in to vote.
3.00/5 (1 vote)
See more:
F# supports mutable classes, however, I read that functional programming paradigm should not contain mutable classes/objects. If so, it will be imperative instead. I want to know why?
Posted
Updated 29-Apr-14 5:33am
v2
Comments
Sergey Alexandrovich Kryukov 29-Apr-14 12:12pm    
Mutable and imperative are not related. Yes, pure functional should work with immutable data — in is build on stack as the execution goes. But who told you it is not imperative? And would you really prefer the lack of mutable classes/structures? :-)
—SA

1 solution

First of all, you should not incorrectly compare paradigms, functional vs imperative. Functional can actually be considered as a kind of imperative. (It is not declarative, right? :-)) And the question "why" is not, strictly speaking, correct. Why? Because it was designed this way.

This is because very pure paradigms are very impractical. The programming paradigm with immutable class instances cannot be OOP. Try to develop an OOP application with purely immutable classes (it actually cannot mean that classes are immutable at all, it means that they are immutable from the moment of completion of their construction), or even imaging such development, and you will see.

F# is not really a functional language. This is a multi-paradigm language: object-oriented, functional, imperative, and so on:
http://en.wikipedia.org/wiki/F_Sharp_%28programming_language%29[^].

[EDIT]

With a multi-paradigm language, you can freely combine certain paradigm. What to use purely functional approach? Nothing prevents your from creation of immutable classes or structures (for example, System.String is 100% immutable, and you can create your own types like that.)

This way, part of your product can be purely functional. For some other part, you can find only some functional features useful. Some other part can be non-functional or OOP+functional. Language should promote good style, but enforce much less, only what is critically important to enforce, not limiting expressive power of the code.

Speaking of the compiler enforcement (which is still important) vs personal programming discipline: you should understand that even with strongest enforcement, it's always possible to screw up everything.

[END EDIT]

Why? Because it present a good practical feature set. Because it was designed this way.

—SA
 
Share this answer
 
v2
Comments
CPallini 29-Apr-14 15:51pm    
5. Good points.
Sergey Alexandrovich Kryukov 29-Apr-14 16:00pm    
Thank you, Carlo.
(I added some new paragraphs to it.)
—SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900