Max is a life enhancer for tech & entrepreneurship. Which seeks to blend both to build innovative products or services for the world that solves hard problems.
I desire a library which will allow me to succinctly capture the business requirements in an executable manner. I'm tired of writing the same code again and again in 100 different ways and feeling this spiderweb of discomfort and boredom and not knowing how to improve my code, capture the common pieces. Some people call it 'accidental complexity'[2] vs 'essential complexity' i.e. business requirements.
What do executable business requirements look like? One approach is Datalog: a declarative(like SQL + recursion) logic language where you express business rules and let the engine figure out your solution. You can see an example here[1].
Datalog and it's derivative are already popular in the Clojure world(Datomic/Datahike/DataScript). It's used in production, so I'm not worried about it not working.
That's great but I want a language that can capture almost all "business" requirements: tax rules, distributed systems, analytics, machine learning algorithms.
For that, we need to explicitly capture time in our specifications :). Rajiv was hungry at time t, Rajiv ate strawberries at time t+1, Rajiv is not hungry at time t+2.
So, since you kindly asked, my project is Mercylog(github.com/RAbraham/mercylog), a Python library planning to unify three different projects which explicitly capture time.
Like I said, it's ambitious but if it wasn't, would I wake up early as I need all the time I can get ... if I get rejected in interviews for some coding puzzle, this thing is computer science heavy and I will do it :).
I'm an average guy but my projects don't need to be average ;)
Max is a life enhancer for tech & entrepreneurship. Which seeks to blend both to build innovative products or services for the world that solves hard problems.
It's not really the same code instead your using it in a different context, uses cases, constraints & organisation culture. As the saying goes "if you view the world as a hammer everything looks like a nail to you".
Which is why I think your approach might be shrew towards the computer science lens and might be neglecting different aspects of mental models associated in building software. My suggestion is looking at design systems as the basis for your project instead.
Great, what is it about then?
Thanks Max, for your interest :).
I desire a library which will allow me to succinctly capture the business requirements in an executable manner. I'm tired of writing the same code again and again in 100 different ways and feeling this spiderweb of discomfort and boredom and not knowing how to improve my code, capture the common pieces. Some people call it 'accidental complexity'[2] vs 'essential complexity' i.e. business requirements.
What do executable business requirements look like? One approach is Datalog: a declarative(like SQL + recursion) logic language where you express business rules and let the engine figure out your solution. You can see an example here[1].
Datalog and it's derivative are already popular in the Clojure world(Datomic/Datahike/DataScript). It's used in production, so I'm not worried about it not working.
That's great but I want a language that can capture almost all "business" requirements: tax rules, distributed systems, analytics, machine learning algorithms.
For that, we need to explicitly capture time in our specifications :). Rajiv was hungry at time t, Rajiv ate strawberries at time t+1, Rajiv is not hungry at time t+2.
So, since you kindly asked, my project is Mercylog(github.com/RAbraham/mercylog), a Python library planning to unify three different projects which explicitly capture time.
Like I said, it's ambitious but if it wasn't, would I wake up early as I need all the time I can get ... if I get rejected in interviews for some coding puzzle, this thing is computer science heavy and I will do it :).
I'm an average guy but my projects don't need to be average ;)
--
[1] - dev.to/rabraham/introduction-to-da...
[2] - curtclifton.net/papers/MoseleyMark...
It's not really the same code instead your using it in a different context, uses cases, constraints & organisation culture. As the saying goes "if you view the world as a hammer everything looks like a nail to you".
Which is why I think your approach might be shrew towards the computer science lens and might be neglecting different aspects of mental models associated in building software. My suggestion is looking at design systems as the basis for your project instead.
Thanks Max, will check it out :).