Pranam, I've read your proposal and I think it's lacking a motivation section. Let's suppose I'm comfortable with C++. From the topics you've chosen it seems that your library is an astrometry library rather than an astronomy one. This is _very_ specific, I would even say too specific for Boost, but suppose for now that I am interested in these topics. You plan to plot curves. My question is then how are you going to implement that? There is currently no GUI library in Boost (there was a discussion not too long ago, but AFAIK it resulted in "nothing"). Are you going to depend on external libraries? I'm afraid a pretty big part of Boost community will be against that. Moving on to FITS... there are a few libraries out there which provide the functionality you describe, so what are the advantages of using your implementation? And finally, coordinate systems. Do you really need a new library for that? I mean we have Boost.Geometry, why can't celestial coordinate system just be added to it? Don't get me wrong though, I'm not trying to discourage you. I'm just a concerned physicist :) Tom

2018-03-18 11:02 GMT-03:00 Pranam Lashkari via Boost <boost@lists.boost.org> :

I was in constant contact with Vinícius dos Santos Oliveira talking about this project.

Not a lot as I was unexpectedly too busy at work lately. Some members of the Boost community suggested that the library might be of limited use because researchers (a common target for astronomy libraries) tend to focus more on exploratory analysis on a closed dataset and once the paper is published (based on the used dataset), there is no need to maintain the software (or fix bugs in the coded software if bugs are found when used against new datasets[1]), so productivity is more important than static typing and other C++ subtleties (and Python is a winner here). Also was pointed out that scripting languages like Python are important for other reasons (easier to use and quick to get a new member into the proper mindset). I then suggested to Pranam that he could do as Niall and do some little effort to also allow the library to be usable under C[2] so bindings for other languages such as lua, Python and more scripting languages can be easily added and it'd be of value even to Python and lua programmers (especially lua programmers and scripting languages that don't have much attention or batteries included if you will). But it's also possible to extend scripting languages just using C++ and this “C usable” suggestion can be skipped. Hope you go through the proposal. I will appreciate your feedback to

improve proposal and the betterment of the project.

Proposal: https://drive.google.com/open?id=1ZdS__MZr6cSJggkK0P_w2jXQQeRWubPk

I'd like to also ask to Pranam what difficulties he would foresee in using Boost.Units[3] as his library could be a good test case for other Boost fundamental libraries. [1] do not confuse software bugs with errors in researched algorithms [2] https://ned14.github.io/outcome/tutorial/c-api/ [3] http://www.boost.org/doc/libs/1_66_0/doc/html/boost_units.html -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/