11–20 of 147 posts
There are other problems with Object-Orientation. For example, it tends to scatter allocation which has performance impact. ( see this nice presentation: http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... )
If performance is not an issue, I'd guess the price you pay for OO is that you eschew parallelism and concurrency.
Earlier quoted context omitted.
OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time. In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next. Immutable state isn't just a formal exercise--it's a more authentic model of the world.
I'm sorry, are you arguing that immutability models the world more well than OO because no object in the real world ever stays the same ?
The thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, per…
OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time. In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next. Immutable state isn't just a formal exercise--it's a more authentic model of the world.
mutable state is not a problem per se. _Shared_ mutable state however, is a recipe for disaster. There are other problems with Object-Orientation. For example, it tends to scatter allocation which has performance impact. ( see this nice presentation: http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... ) If performance is not an issue, I'd guess the price you pay for OO is that you eschew parallelism and c…
Also, as soon as state escapes a function, it becomes shared, so should be immutable (except when explicitly made mutable).
The thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, per…
Many times I've heard this argument from someone who only knows the one or two tools they learned in college or in their first job, and they try to dress up their ignorance as wisdom for "not wasting time on the wrong tools".
I recommend http://norvig.com/21-days.html as a great place to start (I have only learned, at best, 3/6 of his suggested language categories, and I am on the 4th).
In case you don't know ML, you should. Also note that though OCaml is the most popular ML dialect right now, Standard ML is where it all started (PolyML is a good Standard ML implementation: http://www.polyml.org/ )
mutable state is not a problem per se. _Shared_ mutable state however, is a recipe for disaster. There are other problems with Object-Orientation. For example, it tends to scatter allocation which has performance impact. ( see this nice presentation: http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... ) If performance is not an issue, I'd guess the price you pay for OO is that you eschew parallelism and c…
Functional paradigms scatter allocation even more (though maybe more predictably, so the Generational Hypothesis is of more value in a functional programming language). Also, as soon as state escapes a function, it becomes shared, so should be immutable (except when explicitly made mutable).
Earlier quoted context omitted.
Functional paradigms scatter allocation even more (though maybe more predictably, so the Generational Hypothesis is of more value in a functional programming language). Also, as soon as state escapes a function, it becomes shared, so should be immutable (except when explicitly made mutable).
any evidence for the 'even more' statement ?
The thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, per…
To me, it makes much more sense to try to create programming languages that are able to express human thought. People think in terms of things that are, to a first approximation immutable, memories are a good example.