The thread Discussion on “Why I no longer recommend Julia” by Yuri Vishnevsky seems to generate a huge amount of interest. What about having a panel discussion along these lines at the upcoming JuliaCon 2022? Moreover, inviting Yuri Vishnevsky to such an event would be a strong sign that the Julia community appreciates constructive criticism.
[I wanted to post this in the subcategory for this year, but it seems that it doesn’t exist yet.]
I think it really depends on the desired outcome of a talk like this. The extensive discussion around the post has already verified that the Julia community is interested in engaging on and solving the issues IMO.
What would the expected outcome for the panel talk be? Would it be better to just have a sprint and get the right people in the same room to resolve some issues?
I really like the idea of the sprint and also the general spirit of what @matthias314 is suggesting (which I think is to foster solutions around the problems/discussed in that discussion post).
If we could condense the biggest issues identified around this post into actionable points that could be addressed in a session like you said Logan where we have “the right people in the same room” alongside those willing to dive into addressing some issues, this could be a really productive time.
But I think it needs a bit of prior structuring to make sure it doesn’t devolve into a conversation about what should be done versus getting things done (where I am much more interested in the latter).
I agree with you that the post verified we all care and want to be engaged on solving these issues - I think getting right folks together could be a powerful move.
What do you think @logankilpatrick ?
P.S. Additionally, another discussion formed from Yuri’s post called, “How to know if a package is good?” which I think could be also good to tackle as it has other issues that are a bit less technical - thinking about how we could potentially get members of all skill levels involved.
But I am not sure if this is conflating what @matthias314 originally intended so I count this lower priority.
I don’t want to argue against sprints, but I can think of several topics that might lead to interesting discussions.
One, mentioned repeatedly in the original Discourse thread, is that of interfaces. Does Julia need formal interfaces as part of the language? Or should more detailed informal interface descriptions somehow become part of the Julia culture? Or do we need neither?
On a more general level, there is the question of quality versus quantity: How should the Julia community navigate between improving the quality of existing packages and creating new packages with new functionality? Ideally, we would do both with full energy, but our resources are limited.
To me at least these issues seem worth of the large audience provided by JuliaCon.
Seems a bit much to invite somebody just because they had some criticism, I imagine they didn’t seek the level of attention the thread got and wouldn’t be comfortable with more attention at a special event. I could be proven wrong, of course.
In any case, some prior organization is warranted. A LOT of topics came up there and it might be better to focus on a few big ones that is important for many eyes. As for me, I also second the “How to know if a package is good?” discussion, I’m sure many Julia users would appreciate pointers and brainstorming about making it easier.
I also think it might be worth talking about how generic code and interfaces enable Julia’s penchant for code composability, and the 1-based indexing assumptions in existing AbstractArray code can be an example of an effective interface deviating from the documented (ideal) interface. This is one of those concepts that are hard to pick up from the Julia-centric documentation and would be especially valuable to people coming form other languages (another example: using a script instead of the file system to organize your namespace hierarchy).
Well, to be fair, I feel that the Julia community engages a lot whenever there is negative feedback, regardless of the merits of said feedback.
Now, in this particular case I think it was constructive (someone with deep knowledge of the Julia ecosystem that had also contributed significantly). But I have seen similar levels of engagement in threads that were, being charitably, not constructive at all.
I think that by this point there is a general agreement / understanding of what could be improved within the Julia, but this is not really visible. Having a Roadmap / overview collecting these problems, where we are and where we could go would be really helpful. Specially to make easier for people to contribute.
I guess this could be splitted further into three categories. For example: language, runtime and ecosystem (the last one being more of a collaborative community effort with the first two just providing an overview of what’s to come in terms of features or compiler improvements).
Just my two cents.
EDIT: A last reflection about fdeedback: I feel like it’s taken much more constructively than it was a couple years ago. Maybe it’s correlated to having less criticism being “I’d take a look at Julia, but they ruined their chance when the did 1-indexing arrays!”
That doesn’t seem like a fair interpretation, though.
Having a proper critical view of Julia at the JuliaCon sounds like an interesting idea. Jeff Bezanson did a “What’s bad about Julia” in 2019. Might it not be time soon for something new, and maybe a bit less of an insider view?
The most salient desired outcome is doable consensus – the immediate, and less immediate commitments & sharing of introduced good-practices. In my experience, throwing an admixture of gripes – some of different stripes – to a group discussion, however well organized, has not proven helpful. Preselection of a single and well-defined issue along with a tear-sheet of the possible and reasonable provides the potential for some new traction. While there may be other parallel or closely interwoven considerations, progress that cements requires braiding them into a contextualized near present.
Are you saying that a critical assessment of a project is generally unlikely to be useful, unless it only produces directly actionable output (or doable consensus)? Can’t it be useful to be presented with a problem, even one without a clear solution?
Even when there isn’t any obvious fix, I think it could be useful to be made aware of the shortcomings of a language, even if it just means you have to be aware of them and work around them.
Anyway, I have no very strong opinion on whether this is necessary, but I’m certain that I would absolutely watch a talk like that.
Yes, I understand better now what you meant. I just don’t see why this is an argument against a ‘gripe session’. Having a fly buzzing around in the back of your mind can also be a good thing.
(I sometimes get the impression that this is a controversial opinion, and that only directly actionable points are valued, the rest being just a drain on resources and attention.)
I agree that well thought out criticism that is not directly actionable can be interesting in some cases.
The key question for me would be whether a panel at JuliaCon is likely to add much to the existing, rather extensive discussion. I don’t have a strong opinion either way.
I want to chime in here – Yuri is not just any other person who posts an opinion about Julia online. He was extensively involved in the community for many years and spoke to many Julia developers over that time. And his comments were extremely thoughtful and informative. I’d be very eager to see him present if he’s willing to.
It was watching Yuri’s JuliaCon presentation (2014) that first persuaded me to give Julia a try. (Although I remember being disappointed when I got as far as looking inside the built-in Graphics.jl package…)
I think the JuliaGraphics organization on github still bears one of his images as its icon…