4 ms·
OOP... where originally specified as a queued serializable messaging-based topology of reusable components, i.e. what we now know as a actor/agent based program
by nbevans 12y ago
OOP... where originally specified as a queued serializable messaging-based topology of reusable components, i.e. what we now know as a actor/agent based programming.
... But where CPU stack-based function calls (cutely named "method calls") was what was actually delivered. Presumably because in the 80's, what was specified, was too costly on the CPU and memory to deliver. Oops, indeed.
A lot of bad decisions were made in the 80s in the name of CPU and memory. Just look at RDBMS still in the 21st century being the default persistence layer for 99% of applications.
OOP is a pattern that became popular for GUI programming because everything is inherently messaging-based already, and because Xerox and Apple adopted it and for some reason people thought it could be reasonably applied across all types of programming.
- retox 12y agoThe problem with RDBMS being? No sarcastic, just curious.
- nbevans 12y agoThe problem being that to use RDBMS well with object-oriented software you need an ORM (object-relation mapping) layer, which adds complexity and cost and maintenance burden. RDBMS are a central point of failure and don't scale well. Relational data is typically overkill for the vast majority of applications which would be better suited to a document-based dataset at the expense of a little more memory cost. Etc etc... :)
- collyw 12y agoI disagree. Database code is generally a lot less buggy than application code, probably due the declarative nature. Plus with a properly normalized schema, you can answer most questions about your data. Document databases have basically forced you to denormalise at step 1. I would say we should forget about the OOP and stick with the RDBMS, as that part works well.
- nbevans 12y agoRDBMS has its uses, I didn't say otherwise. However I did say adopting it as a "default" persistence mechanism is wrong. RDBMS is something you adopt with your eyes wide open as it is large architectural decision and ultimately a burden to take on board. And even then you may only adopt it for one particular subsystem of your product; for polyglot persistence is the best. For application state, the big drawback of RDBMS is its lack of temporal and immutable persistence. This is where the temporal nature of event sourcing is a better fit for application state. Event sourcing can feasibly perform a superset of operations that SQL can do, and it can do all this without the the need for mutable state.
- CmonDev 12y agoJust wait a couple of years until the SQL for NoSQL will arrive or something else at least remotely looking like a standard. Then we will have ORMs for NoSQL.
- eru 12y agoRelations work well with functional programs. Some people even want to make relations the default data type. (We did something similar at Standard Chartered.) See eg http://lambda-the-ultimate.org/node/1446 http://lambda-the-ultimate.org/node/1446