7 ms·
The reason I ran away from Julia and don't plan on ever using it again, and don't recommend anyone use it outside of academia, is that so much of the community
by tavert 8y ago
The reason I ran away from Julia and don't plan on ever using it again, and don't recommend anyone use it outside of academia, is that so much of the community is made up of grad students. So you get a lot of research code and people who have never been professional programmers maintaining most of the ecosystem. Julia Computing is largely made up of people they've hired from the community straight out of grad school.
- celrod 8y agoI hope that if/as Julia gets adopted in industry, more libraries get written and maintained by professionals. If the language is successful, that may change. Although AFAIK it hasn't really in the case of R, outside of tidyverse. As a grad student without a CS background, I don't think I'm qualified to say much more on this.
- baldfat 8y agoThe issue isn't "Professionals" it is domain specialist. In the past data specilist didn't have Computer Science specialty. They were awesome in stats and numbers but lacked strong programming skills. Hadley Wickham is special because he has both the stats, data science AND programming skills. data.table is also an amazing library. R to me is the most improved language in the history of programming languages over the past 5 years. Also R allows anyone with basic hackery R skills to create libraries easily and that is why so many of them are not optimal.
- Accipitriform 8y ago> Julia Computing is largely made up of people they've hired from the community straight out of grad school. Where do you think most companies get "professional programmers" from, exactly? Julia's been designed and implemented by some very bright people, and it shows.
- jhayward 8y agoIndustry gets professional programmers by hiring people who have been hammering out shipping code in paying products for years, and years, doing support, maintenance, and new product development and research. Grad students may be brilliant but that does not help give them any insight in to what makes a good ecosystem, toolchain, and feature set good.
- sampo 8y agoHow was it with the origin and design with Python, NumPy, Matplotlib, Pandas? Were the people who originated these projects in their time any more professional and seasoned than Julia people are currently?
- jhayward 8y agoWell, if they'd been as brilliant as the GP indicates there would be no need for Julia, would there?
- simonbyrne 8y agoWe would love to have more professional programmers contribute: unfortunately those 1-based indices put them off. More seriously: part of the problem does seem to be that Julia does have some significant differences from "traditional" languages (e.g. the concept of a "virtual method" is a bit fuzzy in Julia, what we call a JIT is probably better described as a JAOT, whether it has a "type system", homoiconicity, etc.). That said, this JuliaCon I have met a lot more people from and classical "programmer" backgrounds. So hopefully that is changing.
- ScottPJones 8y agoI've seen quite an evolution over the past 3.4 years I've been using Julia and the 4 JuliaCon's I've attended so far. Back at the 2015 JuliaCon, a number of us "older" professional programmers felt like we should stage a palace coup, because it did feel like the input of people who had "been around the block" a few times was not really valued. That's changed quite a lot (maybe because in the intervening years many of the core contributors have gotten their Ph.D.s and are having to live off their blood, sweat, and tears (plus lots of joy, to be sure) of producing things with Julia that people will actually pay money for). Yes, it was young and brash, but those awkward years seem to be past, and I feel the future of Julia is quite bright.
- deleted 8y ago[deleted]
- simonbyrne 8y agoAlso, I was actually a postdoc...
- chappi42 8y agoI don't see your point of academia and about hiring from the community? What I see on Github is as professional as it can get. Issues, discussions, triage, review, CI-tests for example. Maybe you started too early, before Julia was settled? And/or were too over-enthusiastic to begin with? I think Julia had to grow, find the 'correct' solution with e.g. NA/Missing/Nullable. Break things b/c it didn't work out as expected. Postpone things, debugger (maybe?), for more important areas or because base was not stable yet. Two years ago in a project I hoped that people would switch immediately from R to Julia. But in retrospect it was good they didn't. Julia was not ready for them and too much ecosystem stuff missing/unclear still. (This said, Julia would in principle have been much much better suited for that project).
- tavert 8y agoThings are decent on average, but there's a persistent carelessness and rush to do things without paying attention to the consequences. More in packages than base nowadays, but there's a lot of merging and releasing things immediately without waiting for code review that could have caught mistakes before breaking users.
- simonbyrne 8y agoOut of curiosity: what language has a package ecosystem that in your opinion does do this right?
- tavert 8y agoLarge Apache projects, notable widely-used c++ projects like boost, llvm, zmq, cmake, the c++ language standards committee itself, all take their time and rarely if ever release changes/bugfixes immediately. Things go through review, testing, release candidates, and people other than original authors of code provide input before normal users get their hands on anything. The core pydata projects take their time and are cautious about breaking things.
- ScottPJones 8y ago
- ChrisRackauckas 8y agoSciPy's ODE solver doesn't have a stable contributor who contributes more than than about once a year even though it has many long standing issues, and PyDSTool hasn't had a commit in 2 years and doesn't work on Python 3 (and most of pycont is incomplete...). R's deSolve isn't even in a repository you can track and still hasn't fixed their DDE solver issues even though they directly mention in the docs how it's incorrect. So it's not like other open source software has strong maintenance structures....
- marmaduke 8y agoSciPy solvers are mostly interfaces to existing established solvers, and I’ve not had any problems with them. We’ve also used PyDSTool without problem, and it appears to support Python 3, https://github.com/robclewley/pydstool/blob/master/README.rst https://github.com/robclewley/pydstool/blob/master/README.rs... If you think these are poorly maintained you should see XPPAUT, a tool still quite widely used.
- ChrisRackauckas 8y agoSciPy's solvers cannot handle events which are nearby, most return codes aren't documented, you cannot run the wrapped solvers in stepping control mode, you cannot give it a linear solver routine, etc. So it wraps established solvers but still only gives the very basic solving feature of it, and most of the details that made the methods famous are not actually available from SciPy's interface. And it wasn't Python 3 for pydstool. It's SciPy 1.0.0. Some of the recent maintenance for this stuff has actually come from the Julia devs though: https://github.com/robclewley/pydstool/pull/132 https://github.com/robclewley/pydstool/pull/132
- marmaduke 8y agoYou mentioned Python 3, not me. Btw, I did look through your DE packages, and they are definitely an amazing contribution not seen in Python; I've recommend to colleagues.
- 8y ago