But, ho hum. Oh yeah, dynamic languages are great, you can modify classes at runtime, yeah, yeah. Blah blah closures blah blah.
People, we need to get past the object oriented paradigm, or model, or whatever it is. I'm groping for the one true programming model. Short of that, I'm hoping for one where I never have to do the stupid object-relational mapping again. Hibernate's popularity is emblematic of our decline. If you've got a ton of O/R mapping in your program, you've got a ton of dead code that does nothing for you. Every web app on the planet does this:
- Make some queries to the db;
- Build some objects possibly having object references;
- Iterate over the objects and flatten to tabular HTML.
It's a failure of the languages we use, that we need application code to map the tables in which we store data, to some in-memory constructs called objects. And it's a failure of the architectures we use, that we end up flattening those objects into HTML representations.
I want a language for table programming. I think you can write programs in this language that do everything we expect of an application programming language -- building GUIs, reacting to mouse events, listening to sockets -- everything. Don't model your domain as objects. Model it as relations.
We need to explore how we can construct soup to nuts programs using the language of data. I haven't yet looked at Rel. But I wanted it to exist -- I wanted some implementation of Tutorial D to exist. Using that as a starting point, I can imagine programs that have a relvar (Date's term for a relational variable: essentially a table or a view) for MouseState. Whenever the mouse moves, the system adds a new row to MouseState. Yes, a lot of rows! We don't really need to persist them all. When a row gets added to a table or a view the system should invoke some code -- a trigger. The trigger code modifies other relvars in the system. And from that trigger code other events flow.
A programming language built around locating the right bit of code to invoke in response to some state transition -- that would be a useful evolution of OO polymorphism, which locates the right code to invoke based only on the shape of an object. Let's get off of this rutted OO cartpath. We're not inventing anything new here.