51–60 of 147 posts
> You may even have to inherit a base class or implement an interface. Subtype polymorphism is a very poor substitute for closures. This is why C++ algorithm library is unusable. Does anybody understand what the author means by this? STL's algorithm library does not use class hierarchies for anything. And they often take functions (be they free functions, lambdas, or functors) as arguments.
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…
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…
It absolutely reduces cognitive overload. Having "containers" of functionality that allow me to easily know at a glance what I'm working with is invaluable. I'm not knocking functional programming, since I haven't built a few projects in a purely functional language yet, but trying to do some things with the functional paradigm (or at least, my understanding of it) left me recognizing class-based programming as a powerful tool when used correctly.
Earlier quoted context omitted.
As an aside, my final year project for my CS degree included benchmarking different sets of SK combinators for efficiency as well as looking at different reduction algorithms. What I found out pretty quickly is that, especially as I was running my code on a mid 80s mini computer, I had to spend as much time on allocation and garbage collection strategies as anything else. Indeed, my only really "difficult" bug was ca…
> I was stumped for days and then I had a flash of insight from nowhere while sitting on a bus that fixed the problem We're on tenterhooks here...
What I always remember is that the idea as to what was causing the problem came as a complete bolt from the blue when I was thinking about something else - perhaps the first time that something like that happened to me, but certainly not the last!
Best (and most humorous) argument against Java's object oriented obession that I've ever read is: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
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…
He then proceeds to launch his piece of chalk across the room! (good stuff). And proposes that instead of the chalk having changing state (position, velocity, etc), instead, its better to thing of the chalk as a collection of immutable values; each value existing at a moment in time. And this of course aligns more to functional programming; and you see the same notion (immutable values over time) with descriptions of Datomic.
[1] http://ocw.mit.edu/courses/electrical-engineering-and-comput...
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…
Mutable state can be a huge pain in the ass. A common mistake OOP beginners, and even "experienced" developers, make is the creation of this complex jungle of entangled objects that all directly or indirectly manipulate each other's internal states. If you've ever had to work with such a code base for a prolonged amount of time you are pretty quickly ripe for a year-long sabbatical. There is simply no way to reason a…
I'd argue that the problem with software quality is not so much in the (ab)use of mutable state, but the fact that (especially in enterprises) software often reflects the organizational structure of the people who worked on it.
Exhibit A: the software solution where every tiny part of the system is developed by some (semi) random group of people that often changes, doesn't directly communicate with any of the other groups, doesn't bother to much with the 'architecture' of the complete system (a big ball of mud), and has no interest improving either the overall architecture of the system, or any of the components outside their scope. Add pervasive mutable state into this mix, and you have a recipe for disaster.
That's not to say the mantra 'eliminate (almost) all forms of mutable state' will improve this problem much.
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…
Mutable state can be a huge pain in the ass. A common mistake OOP beginners, and even "experienced" developers, make is the creation of this complex jungle of entangled objects that all directly or indirectly manipulate each other's internal states. If you've ever had to work with such a code base for a prolonged amount of time you are pretty quickly ripe for a year-long sabbatical. There is simply no way to reason a…
See what I did there.
1. Dynamically Typed Languages (LISP, Erlang, Smalltalk, Python, Ruby, and Javascript) are all easier than Haskell, JAVA, C++ or any other typed language for working with ADTs. Whether the language is OO or not isn't really relevant. On the other hand, you loose type-safety/efficient representations. But life is filled with choices, different tools are good for different things at different times.
2. You can have closures in a class based language. Here's some rather exotic Python code that uses both for measuring the performance of iterators: https://github.com/wearpants/measure_it/blob/master/measure_...
Smalltalk and Scala also have closures. It's not an either/or for classes vs. closures in programming language land.
3. There's more to concurrency than shared memory, so immutability is again a weapon that is good for some battles. If you have an app which you've factored into workers, unless they are on the same machine they'll need to communicate. Having your data be serializable is more important than having things be immutable in this context. What a worker does with data while it is handling it can involve lots of mutation.
So everyone should take a big breath, and remember that there's no one way to think about software and there's no universal rules, other than probably P != NP and stuff like that.
Earlier quoted context omitted.
Yes. Due to Special Relativity, different observers perceive events (changes to object state) at different moments, the state of the whole universe is not consistent. Therefore, we model the universe using a sequence of immutable universe snapshots, with different computational agents independently moving through the (branching) timeline of snapshots, so that each and every one of them views the universe consistently…
Most events humans care about happen in plain old classical physics, and no computer is moving at some large fraction of light-speed relative to any other computer. If you maintain synchronized clocks, everyone can agree on the exact same order of events (which would not be true in a relativistic situation). Now it turns out to be difficult to maintain synchronized clocks, and Lamport timestamps and vector clocks are…
In practice, replace Special Relativity with Network Problems.