
Project:M36 Relational Algebra Engine - spariev
https://github.com/agentm/project-m36
======
elcritch
At a previous company I worked at, we built a relational algebra to do server
side data jobs and manipulation on NoSql style data calls. It was surprisingly
effective. I proposed it at first figuring "ah it's not SQL, the team won't
like it " but it was quickly adopted and proved very valuable for a couple of
years. That was despite the lack of flexible enough generics and before even
the Java 8 lambdas. The biggest downside was younger devs who didn't have the
experience to think in data first approaches (initially at least!). I kinda
regretted not making more effort to train them how to utilize relational
algebra and all the flexibility it brings, even in Java.

it'll be interesting to see if this project gains traction!

~~~
solidsnack9000
What are your thoughts about modeling polymorphism in the relational algebra?

~~~
agentm
If you are referring to object-oriented polymorphism, "Out of the Tarpit"
comments directly on this AT
[http://shaffner.us/cs/papers/tarpit.pdf](http://shaffner.us/cs/papers/tarpit.pdf)
page 12, the conclusion being that OO suffers from unnecessary state
complexity.

In addition, the glut of ORMs demonstrate the various approaches to solving
the impedance mismatch between the relational algebra and object-oriented
architecture with no clear winning strategy.

Instead, the proposal from the "Out of the Tarpit" paper is "functional
relational programming" which fuses relational algebra operations and
declarative functional programming.

I invite you to take a look at how Project:M36 handles these requirements at
[https://github.com/agentm/project-m36/blob/master/docs/reach...](https://github.com/agentm/project-m36/blob/master/docs/reaching_out_of_the_tarpit.markdown)

~~~
solidsnack9000
I am referring to traits and variant types.

~~~
elcritch
Primarily just that Java (7's) type system is categorically incapable of
expressing more sophisticated types. You can get some basic type testing using
abstract classes to define dataset column types. Java 8's type system might
have some extra features to allow it to do this without significant
boilerplate. E.g. To keep runtime generics in Java you can instantiate
subclass instances which don't have type erasure.

The references solidsnack9000 mentions seem to be promising. I'll have to look
into it! It seems like it'd apply to a system of using actors and data
modeling I'm working on currently... Intriguing at least.

