Why should I attempt to write an entirely new Synastry engine from scratch? That is the question. Let me give you a set of answers, but let me give you the really big one up front.
The problem with Sirus and Janus is that they are conceptually wrong for this era. Both applications were designed explicitly to serve the needs of a professional astrologer providing information to one client. As such, you need knowledge level of a professional astrologer to really exploit the system.
More importantly, the design scope of the synastry engine is incredibly limited. It was designed to counsel one client about one or two prospective romantic entanglements. Beyond a couple of comparisons, comparison become incredibly difficult and convoluted.
Further, there is no such thing as a query engine in these software packages. It is not possible to go to a database and query the set of all Taurus sun-dates with romance score of 150 or higher versus a given chart. It not possible to write a query that says "give me all Capricorn birth dates where Mars conjuncts Venus in the Davison chart vs. this particular natal chart". Neither can you write a query that says give me the solution set of all Pisces birthdates where Mars conjuncts Venus and both the Ascendant and Sun fall into your 7th house.
Yet these are precisely the ways in which you identify prime candidates for love and marriage. So why didn't the software vendors build such an engine?
Because this just isn't the way professional astrologers work. The workflow of a professional astrologer is pretty simple. A woman walks in the door and says she is conflicted. Man X is good and Man Y is more exciting. She does not know which one is the right man for her. What should she do? In this situation, the professional astrologer types in three birth dates, prints a pair of reports, and then explains it to her.
Both Janus and Sirus are perfectly adapted to this workflow. There is nothing about the ordinary work-a-day astrologer's job that cannot be accomplished with these two apps. If I wanted to go into business right now, I could. I own legit licenses.
Unfortunately, this is not what I am interested in. The question that obsesses my mind is the calculation of the perfect birth date of the perfect mate. I already have a pretty good idea of what that is. For the record, the date is 3/12/1986.
However, I am not absolutely confident of their methodology. Further, I am fairly sure that a better methodology can be constructed. Understand that I hacked and bent and warped these applications to make them do what I wanted them to do. Programmer tricks, my friends.
I would rather design an engine that is entirely built around the idea of query investigation and detailed comparison of outstanding prospects. For this task, an entirely new database application would have to be devised. It would have to be based on a full SQL engine with some pivoting analytical powers. It would need to solve some really complex celestial mechanics problems.
Most important, it would have to be able to differentiate between positive and negative elements of sexual attraction. It would need to differentiate between an individual who be a great short term sexual affair, and someone who is a great long-term mate in life. Believe it or not, these distinctions are entirely possible. As I mentioned before, squares and oppositions are not good for long-term stability and copacetic life together. Sextiles and Trines are.
I am fairly certain I can build this engine. In fact, I already started. I started several weeks ago. I already have a very rudimentary scoring engine working. It is not very sophisticated. It does not yet do a Davison chart. It does not identify every possible aspect that produces attraction. It does not yet distinguish between positive and negative attraction types.
All of this will be addressed in good time.
The great advantage of this project is that I am writing a fully-object oriented engine, which is written in fully-modern managed code. This means it doesn't leak memory, and is safe for deployment to the web environment. It means that I can scale it out on a service backbone across hundreds of virtual servers in the cloud. This means that I can construct a Software as a Service (SAS) website that can make money. This also means that I can drive a nice smart phone app that will communicate with my SAS web services for processing information.
There are a lot of advantages to dumping C/C++ and Delphi in this day and age. Believe me, there was no greater lover of Borland's Delphi than I was. Still, the time has come to move on. Even Anders Hejlsberg moved on to .NET more than a decade ago.
