Comment by strictfp | Hacker News Reader

Comment by strictfp | Hacker News Reader

I think that the article uses a bad example. OO is actually really bad in db apps (DTO apps). OO shines when you are in one big continuous memory space, and don't have to worry about the data behind the objects. I see OO as a good way of abstracting the data away from the logic of your program.

This abstraction works well with classical desktop apps (lots of code, one big heap, pointers are always valid), but breaks down badly when your program is about communicating data and you start to cross memory address barriers.

A lot of modern apps are about data. You see a lot of networked apps, db apps and layered apps with different technologies in every layer, communicating with each other only through shared data formats. Such an app is primarily concerned with shuffling data around, and oo breaks down into a horrible mess. Each transition to a data representation requires a complete serialization of the object graph to a reasonable data representation and back again at the other side. This means that you essentially have twice the amount of work than if you would operate on the data directly as you would do with FP.

Once the amount of "internal juggling" with the data exceeds a certain limit, OO might be beneficial. But for data-centric apps, forget it.

This is a really interesting point. It does seem like a lot of OOP/patterns books seem to talk about desktop apps that are quite different to your typical web app, which could be characterised (perhaps uncharitably) as CRUD with a bit of extra stuff glued on.

In fact, most of my experience with large codebases has been in web development, in which you're basically providing a nice front end to a database.

If databases are just structured data, then it seems a bit redundant to wrap that in an object-metaphor (e.g., with an ORM) and then use even more objects to perform operations on the data by way of those ORM-objects.

Django is a good example of the kind of thing I'm talking about. I've been thinking a fair bit lately about the limitations of this style of framework, and I wonder if this idea of functions operating on structured data might be a better way to approach things.

It sounds like Scala might be a good language to experiment with this kind of approach, as others have suggested elsewhere in this thread.

> I see OO as a good way of abstracting the data away from the logic of your program.

Why would you want to do this?

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus

If your data structures don't exist outside of your functional code acting on them, it's hard to reason about the data structures themselves in a vacuum.

Isn't this an argument against hiding your data structures behind an opaque object structure?

To my mind, it's an argument for explicit definition of data structures (from me, not Linus).

It seems to me that structs and/or objects do that pretty well. I'm not sure what you're talking about with 'opaque object structure'. class MyClass { member1, member2 } seems pretty transparent to me.

Anyways, I was just explaining why many people prefer to have struct/object definitions separated from the code that operates on them. YMMV, you don't have to agree.

If you're just treating a object as a map of keys to values, then it can be fairly transparent, but unless you're using a language like Javascript, where maps and objects are synonymous, objects are much more difficult to work with. It's hard to transverse them, or to merge them, or often even to look up a list of keys.

I'd suggest that a better solution would be to just use maps, at least in languages with good support for raw data structures.

"It's hard to transverse them, or to merge them, or often even to look up a list of keys."

That's exactly what I'm arguing against in my comment on making your important structs/objects and their relationships explicit. Randomly mutating them together all over your program might seem more flexible but at a cost of making you worry about your code rather than your data definitions. And that's without even getting into performance implications.

If you actually need a Map, of course, that's a different situation than the ones I'm thinking.

Using a map doesn't necessarily mean random mutation, or giving up on your type system. In languages with immutable data structures and a sophisticated type system, you can type-check the keys and values in a map.

Late answer, but nevertheless... I don't particularly think that it's a good idea, but I believe that the original intention was to build "living" data.

So you would look at your object structure and could treat it as data, but internally some objects could be proxies to backend system and fetch data on-demand. Some data fields might also be calculated from other fields. This is the idea which Java promotes by having the JavaBean standard. You never know if your data element is backed by actual data or is the result of a computation.

This type of abstraction can simplify certain problems by giving the illusion of a simple data structure, whereas a lot of computations are taking place behind the scene when the data is traversed.

This abstraction is used in may ORM frameworks for instance. You can follow relations between entities and these will be lazily loaded behind the scene as you move around in the object graph.

The problem is that such a living object can only live in its own environment. For ORMs, you cannot move outside the current DB transaction, or else the objects "die". To see some of these problems in the Java world, google "LazyInitializationException".

Pure data, on the other hand, is "dead by definition" so to speak. It does not contain any own logic and can be moved between environments without any problem. The backside of pure data is the very fact that it is dead, that is that you often have to accompany it with logic to interpret it.

With live objects, the interpreting logic is intertwined with the data. This is both the advantage and flaw of OO.

With OO, you have data and logic close together, and have to pay the price if you try to pry them apart.

With FP, you have the data separately, and have to cope with the mental load of knowing which logic you need to apply where in your data structures in order to interpret them.

Reply on news.ycombinator.com