Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote -4 down vote favorite

Every one knows immutability is the way to go - everyone recommends making your classes as immutable as they can be... but are immutable types still objects? I have doubt - to me there are simply structures or to be more precise they are, like I like to call them, values. Values can't do any work, work is done on them.

For example, see this adding method in Scala's Int:

abstract def +(x: Int): Int

Is this really a method? Is this really something that Int does? To me it's convenient way to write something that's really a function: + : (Int, Int) -> Int where first argument is an Int the method is called on...

In other words, are objects (or maybe, more precisely classes definitions) becoming in reality mixes of namespaces and values and no longer are what in beginning was called an object?

share|improve this question
2  
The problem with this kind of question is that terms such as "object", "method", etc. are ill-defined, or rather have dozens of incompatible definitions depending on who you ask. Still, I don't see how your logic works for any of the common definitions I'm aware of. If immutable objects plus methods are just values plus functions, then mutable objects plus methods would be just values plus (impure) functions. – delnan Apr 28 at 10:34
1  
"Every one knows immutability is the way to go". Mutable objects can lead to improved modularity. Interestingly the most balances advice about mutability I have read are from sicp written in 1980. – Simon Apr 28 at 10:53
@delnan By function I mean only pure functions, and by method I understand a mix between a function and a procedure. A function - as it can return a value, and procedure - as a sequence that modifies one's or another's object state. – mrpyo Apr 28 at 11:25
Scala is OO and functional, I think that's the source of confusion. The referential transparency has proven to be very good specially when working on parallelizable programs. The evolution of processors and computing power focuses on increasing the number of cores, therefore I think we all could use some more functional programming, either with or without OOP. – Trylks Apr 28 at 13:25
Greenspun's tenth rule reads "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." - the idea there is that everything becomes functional programming eventually. – MichaelT Apr 28 at 14:03
show 2 more comments

closed as not constructive by Bryan Oakley, GlenH7, Jarrod Roberson, gnat, Caleb Apr 28 at 15:22

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

up vote 1 down vote

I think the question is biased. Consider it the other way around: is functional programming becoming OOP?

Let's make a small thought experiment. Let's consider a classical MVC architecture. The values are in the model, the functions that work on those values are in the controller, the view provides interactivity with the users, based on their actions (events) it calls the controller to operate on the model, either modify it, display some (possibly modified) values from it, or both.

If we implement the controller with something purely functional there are not going to be any mutable values in it whatsoever. All the values, mutable or not, are going to be in the model.

Now let's group those functions together into objects, and call them methods, and let's put some configuration values (like the database username and password) inside those objects (let's call them attributes), and let's keep those values as completely immutable. Anyway we didn't really need to add those values, they probably were constants in our functional source code, but it's still nice to have them as immutable attributes.

What you say is that now those objects in the controller, are no longer transformations (functions) on the data but values that "can't do any work, work is done on them", simply because we added some attributes and we made those values immutable. I think that's not fair and I think the question isn't well defined.

Also I think that as software grows larger it's normal to see big chunks of code (methods, files, modules, or even libraries) that only do some of the things software can do, either storing values, transforming them, displaying them, etc. This isn't necessarily a bad thing, if that allows (or that is needed for) building bigger and better software then I'd say it's a good thing.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.