LitCal

This is just a super quick update to inform anybody following that, yes, I am still alive and working on litCal.  I’ve made some progress on filling out the API.  At the moment, I’ve only really started on what I call the secular API, which relates to non-religious calendar functions.

 I think the future direction that I plan on taking this is to create an ANSI C library that will act as a set of primitive calendar functions, such as basic computus and day of week calculations, and then use a C++ wrapper in a second library to provide a more integrated interface that has operator overloading, stores state (the date), produces output strings, etc..

Its been several months since I last worked on anything related to litCal, and I’m beginning to pick things back up again.  I’m currently going through all of the code that I’ve written and am trying to remember what problems I was last working on before I took my little hiatus.

I don’t have an ETA of when I expect to be finished with at least a usable amount of code, but I’m hoping it won’t take too long.

At the moment, I’m still chewing through some other technical details in my head before I start to move regarding working on the library.  The question of language is not so much in the forefront of my thoughts, but it is something that I’m as of yet undecided on.

So, I’m writing this blog post to put out my thoughts regarding which language to choose from.  If at all possible, I’d like comments, suggestions or any form of constructive criticism.

Firstly, though an easier and more powerful language (Python or Ruby perhaps) or a kewler language (Scheme comes to mind) would make the project a nicer one to work on, I want this library to be as generic and widely distributable as possible.  In my mind, sticking to strictly ANSI C or C++ is probably the way to go.

There are pros and cons to both languages in my mind.  The following summarizes what I perceive to be important.  Again, I’d like to reiterate that I’m open to others’ input:

ANSI C

Pros

• Easiest to make sure the code can compile in a wider variety of environments.
• Along with C++, C is the Lingua Franca of application programming languages.  And what’s more Catholic, than to use the Lingua Franca (think, Jerome’s Vulgate, the DRC…even the LXX for the early Christians.)
• Unless I’m mistaken, which I could easily be, language bindings are easier to make.
  

Cons

•  People don’t really like working in ‘plain old C.’  There are too many nice features that would be missing, such as operator overloading, virtual methods, etc…
• If I end up doing any sort of dynamic memory allocation for anything, does the end user really want to have to use functions to instantiate or clean up my mess?
  

C++

Pros

• Still fairly easy to make code that can compile in the odder corners of the world.
• Operator overloading means being able to do simple math with the objects such as adding or subtracting dates.
• Can write code to clean up any data structures that may end up being created.

• Complicated operations can more easily take place behind the scenes.

Cons

• Believe it or not, C++ is not as portable as one might think.  Of course, I’ve worked in quite a few strange computing environments in my professional career, most of which will probably never see this library.
• Though I don’t have much experience binding to other libraries, from what I can tell, C++ can be a bit of extra work when binding to languages such as Python or Free Pascal.