I wonder if the forum could do something to improve the popularity of lesser known Julia Github organizations, like Wikipedia does with Asian Month. I imagine those groups have fewer contributors and it might be harder for them to find new ones. However, most of the time, those groups have some of the coolest packages in the Julia ecosystem and it’s a shame they aren’t better known.
What is the general idea to implement this? As an explicit example something like Bumper.jl or more implicit ideas?
Related to this: Julia suffers from The Lisp Curse. How many packages are there that are near-clones of each other but differ in some small respect? Chain.jl’s readme compares it to Base Julia, Pipe.jl, and Lazy.jl. There shouldn’t be three third-party packages that are similar enough to warrant a comparison as the very first thing in a readme. Someone else mentioned a million static analysis tools that each cover only 80% of analysis. How many autodiff packages are there?
Ideally developers would come together to make one package per use-case a real gem rather try to reinvent the wheel each time.
3 Likes
There’s some truth to what you’re saying about the Lisp Curse and Julia, but this is a poor example of what you’re trying to illustrate. Those three packages (I believe there’s a fourth but I can’t recall the name) handle a complex problem in slightly different ways, I think of them as exploring a missing language feature. Which is great, if one of the approaches ends up favored by the community, Julia can add it. Conversely, so long as there isn’t a clear crowd favorite, chaining should stay at the package-and-macro level.
Traits are similar in that respect. They deserve to be a core language feature, but there are a lot of unsolved questions about what they should even be, and how that would integrate with the rest of the language. There are several packages for implementing traits, it’s unclear to what degree they work with each other’s approach, and from what I’ve been able to gather, most people just hand roll them in the original Tim Holy style.
I’m content with the state-of-the-art in method chaining macros, and somewhat frustrated where traits are concerned. I have an intuition that when the concept fully matures, and becomes a core part of the language, that will be a beautiful thing. But by the same token, I’m glad that core isn’t rushing to ship a half-baked version, instead they’re taking the time to see what people are doing with the concept, and working out the consequences of adding them as a core feature.
I have seen some areas where there are three 40% solutions where there could be one 100% solution, but I’m not in the mood to bellyache about it, just to state that I don’t consider the method chaining libraries to be a good example of that.
10 Likes
Writing the basic Chain.jl took me like a day, so it’s not complex enough a thing to suffer from the lisp curse 
The network dynamics are interesting, though. For some reason Chain.jl really took off and seems to be used most widely out of these. Another package that I wrote, DataFrameMacros.jl was also a slightly different solution to the problem DataFramesMeta.jl had already solved. But in this case not many people picked it up, so even though it was better for me, it didn’t change the ecosystem dynamics much. So now I don’t have much more reason to put energy into it. If I was gonna do anything more in that space, I’d probably contribute to DataFramesMeta.jl again instead, because it would have more impact. I think this dynamic can somewhat counteract the lisp curse, there’s only a finite user base to serve.
12 Likes
Good documentation AND EXAMPLES for packages, especially for packages the Julia community favors. Many people are aware of how difficult this is due to Julia’s paradigms, but ever since (pre-)compilation times have been mitigated, this has easily been the biggest annoyance.
6 Likes
This topic was automatically closed after 3 days. New replies are no longer allowed.