> > The fast speed and short development time were the deciding factors here, > but the biggest drawback was the risk that the language might die in 5 > years. Any material that I could use if that argument comes up again?
The argument I would make is that Julia already has a fairly substantial core of user-developers (overlapped, by design) who are passionate and invested in the language. For example, based on Jiahao's "World of Julia" notebook -- http://nbviewer.ipython.org/github/jiahao/ijulia-notebooks/blob/master/2014-06-30-world-of-julia.ipynb -- we can see that across the Julia ecosystem there are ~30 users who have more than 500 commits, and ~100 who have more than 100 commits. (this is also under-counted because there are projects with >100 commits that are not registered in METADATA for various reasons). As a very rough point of comparison, consider the number of contributors who built up the core of scientific Python. There were less than 50 total contributors over the first ~8 years of NumPy and SciPy development: http://arokem.github.io/2014/09/05/python-is-still/ The comparison is rough (for a litany of reasons), but the point is that a solid core of several dozens of users can go a very long way in a project like this. Julia has (by design) the advantage that knowledge of C is not required to make substantive contributions to performance-sensitive code, so the potential contributor base is also much broader. In this sense the heartbeat for the foreseeable future will hopefully be driven by factors more similar to early Ruby or Python/NumPy than to closed-source languages that languished under fickle or dying paymasters (e.g. Dylan with Apple and Harlequin, or Fortress with Sun). The Ruby and Python "platforms" were largely built by passionate users and/or procrastinating grad students (NumPy specifically). <soapbox>As such, Julia is arguably a safer bet than a mostly-corporate-backed language unless the backer is Microsoft/Apple/Google ;)</soapbox> On Thu, Mar 12, 2015 at 11:16 AM, Ken B <[email protected]> wrote: > Back on topic, I just convinced a client to use Julia with my current > project. It will be an online image processing tool. The other choices were > Matlab and Python with C#. > > The fast speed and short development time were the deciding factors here, > but the biggest drawback was the risk that the language might die in 5 > years. Any material that I could use if that argument comes up again? > > Ken > > On Sunday, 8 March 2015 11:41:12 UTC+1, Joachim Dahl wrote: >> >> The package is very similiar to Gloptipoly or SparsePOP, and it can be >> found here: >> https://github.com/joachimdahl/Polyopt.jl >> >> It was a design decision to keep the API close to the formulation of the >> Lasserre hierarchy, so that there is a close correspondence between the >> problem you specify and the actual semidefinite problem you solve. Yalmip >> and SOSTOOL have much more flexible modeling capabilities, but it becomes >> less transparent what the resulting SDP is. >> >> There is no documentation yet, but the tests show how to use it. There >> are some SOS examples, but actually the toolbox started as tool for forming >> the Lasserre hierarchy while exploiting chordal sparisty structure. I >> don't think many things will change, except for perhaps different ways to >> exploit sparsity in SOS certficates; if you want to solve polynomial >> problems using the Lasserre hierarchy it's probably useful already now, but >> not as an alternative to Yalmip or SOSTOOL. >> >> The plan is to have it finished by summer and present it at a software >> session at ISMP. >> >> On Sun, Mar 8, 2015 at 10:45 AM, Davide Lasagna <[email protected]> >> wrote: >> >>> Joachim, would you share this toolbox for polynomial optimisation? Is it >>> on GitHub? >>> I guess you wrote something's equivalent to yalmip or sostools. Did you >>> compare performances? >>> Davide >> >> >>
