Sounds good. I didn’t want to discourage you, only highlight that licensing was an important consideration.
Actually the data representation framework (used in statistcal analysis) is one area where the julia API is not yet solid and stable. There has been attempts with various models for dataframes (i.e. tables where columns may be different types and missing values may occur) and there are lots of discussions here on discourse if you are interested in learning more of this discussion.
A good package for betaregression would probably import and build on the GLM.jl package, and would possibly use the formula framework being developed here: https://github.com/kleinschmidt/StreamModels.jl . If you open an issue on the GLM package I am sure the people there would be happy to help you get started. This would also help you make your functionality as compatible as possible with existing statistical analyses packages.
Good luck! I would definitely use BetaReg.jl when it’s implemented
Since you are talking about writing your own packages, to implement some of the functionality that you use in R (which would be a great thing to have more of in Julia, done natively, in a Julian fashion), then I wouldn’t wait for v1.0.
I don’t expect there to be any more breaking syntax changes after v0.6 (although new syntax that is now invalid may be added before v1.0), so I think now might actually be a very good time to get started.
Be careful with that. Expect breaking changes to happen years from now. Everything always updates. However, v1.0 is made for long-term compatibility, which means there’s much less change to worry about than the current situation. But there will be breaking changes going to v2.0, but likely not even close to what we see now since what’s happening now is essentially “now or never” changes.
I expect that there will be many changes after v1.0, I just hope that they are not breaking syntax changes.
Of course, I’m used to languages like C and CachéObjectScript, that haven’t really had any breaking syntax changes in decades, even with major new syntax being added.
I think there will be more likely to be breaking changes in some of the APIs in the future, than with the syntax itself, although hopefully @compat will be able to handle any future syntax changes, if any should occur in v2.0.
I don’t think you can do that - I’ve been cautioned by lawyers to not even read GPLed source code, as then if I implement something similar in the future, it might be taken to be a derivative work.
This is what a Chinese firewall is for: have a friend read the code, and answer any questions you have.
Just beware that while it should neither be patented, it seems like it’s possible in practice. Arithmetic coding is math right, and patented (but I believe ran out; still even now not used by browsers, even with it as an option in JPEG).
