5 ms·

I agree. The Julia community is defensive. When you criticize Julia, often their first reaction is to say you are doing something wrong or to convince you Julia

by acmj 5y ago

I agree. The Julia community is defensive. When you criticize Julia, often their first reaction is to say you are doing something wrong or to convince you Julia is perfect for everything. I was enthusiastic about Julia but not anymore.

Tainnor 5y ago
It's not the first community with that attitude that I've witnessed. I've first seen this with Ember.JS (the Javascript framework everybody has forgotten about), then later with the Swift programming language. It could be interesting to investigate why things like this happen and how a community needs to be managed in order not to run into the same problem.
- mbauman 5y ago
  I'm a moderator at Julia's discourse site. We've seen this happen and we're working on improving this, but I'm also (biased and) sympathetic to the "Julia community" writ large. Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just aren't optimal in Julia. So when someone comes in "hot" and rants about how their workflow isn't working out how they expect, others jump in and — yes, defensively at times — point out alternatives that work for them. I think some of this tension comes from an expectation mismatch. Some of the changes noted in these comments about how Julia is presented on julialang.org were made specifically due to this sort of expectation mismatch. This doesn't mean that nobody in the community cares about improving workflows — in fact I know that's not true. But if you want to use Julia today, there are definitely some happy paths that we should guide folks towards.
  - Tainnor 5y ago
    > Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just aren't optimal in Julia. So when someone comes in "hot" and rants about how their workflow isn't working out how they expect, others jump in and — yes, defensively at times — point out alternatives that work for them. And that's exactly what I've seen over and over again, in different communities, such as the ones I've mentioned, this attitude of "you're holding it wrong". No language or tool can be everything to everybody, that's perfectly reasonable. If the goal of Julia is different from that of people that want to run applications in production—or at least those concerns aren't the most important ones—fair enough. But all too often (and I'm not necessarily talking about Julia here; I haven't spent enough time on the Julia forums, I'm mostly referring to some of the other examples I've cited) real concerns are just dismissed out of hand. I also don't believe that enforcing certain very specific workflows at the exclusion of any others is necessarily a great way to become a language that lots of people want to use. People come from different backgrounds and have different preferences and needs (sometimes for very good reasons), successful languages like Python recognise this and let you work with a wide range of tools. Finally, I'm just very skeptical about a certain kind of NIH syndrome that I've seen in some of these communities, something like "encapsulation? well, all these other languages might need it, but we actually don't, because XYZ" or similar things.
    - mbauman 5y ago
      I mean, you're totally free to blaze your own development workflow trail. Even better if you can help in the ongoing clearing and paving of the less-used trails. But when someone complains that a less-used trail is rocky, it's gonna be hard for everyone on the golden brick road to avoid suggesting taking their route... especially if it's leading to the same destination. And yes, that destination does include production.
      - jampekka 5y ago
        Yes you are, but then you have to wait a minute or so after any single change to any file if you do a script workflow. If you do a Revise workflow you end up doing mostly the same because it just breaks all the time and you have to reload the session. Or you can use some bizarre hack like DaemonMode.jl that also just breaks all the time. Julia is hard to debug as is (and this is fully acceptable to me due to the architecture) and these hacks on hacks make it just impossible. Julia suffers from the same "fancy calculator" approach than e.g. R and Matlab, and like those, they refuse to take note of the decades of experience in software development that this just leads to a total mess if you have anything more complicated than a one-off analysis. It's like insisting on editing files with ed because that's how it's always been done.
        mbauman 5y ago
        And this is precisely why this dynamic exists — because there are workflows with far less friction than what you've experienced. I and others successfully use them every day for things far more complicated than one-off analyses. I think your view of Julia as a "fancy calculator" may be part and parcel to the difficulty. I do use it as a fancy calculator, but I also use local packages all the time — and that's where you'll find the best success in both tooling and code structure for sustainable (and modern) development. We need to do a better job of helping folks more effectively develop and work with Julia before it becomes frustrating.
        jampekka 5y ago

by acmj 5y ago

Tainnor 5y ago

It's not the first community with that attitude that I've witnessed. I've first seen this with Ember.JS (the Javascript framework everybody has forgotten about), then later with the Swift programming language. It could be interesting to investigate why things like this happen and how a community needs to be managed in order not to run into the same problem.

mbauman 5y ago
I'm a moderator at Julia's discourse site. We've seen this happen and we're working on improving this, but I'm also (biased and) sympathetic to the "Julia community" writ large. Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just aren't optimal in Julia. So when someone comes in "hot" and rants about how their workflow isn't working out how they expect, others jump in and — yes, defensively at times — point out alternatives that work for them. I think some of this tension comes from an expectation mismatch. Some of the changes noted in these comments about how Julia is presented on julialang.org were made specifically due to this sort of expectation mismatch. This doesn't mean that nobody in the community cares about improving workflows — in fact I know that's not true. But if you want to use Julia today, there are definitely some happy paths that we should guide folks towards.
- Tainnor 5y ago
  > Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just aren't optimal in Julia. So when someone comes in "hot" and rants about how their workflow isn't working out how they expect, others jump in and — yes, defensively at times — point out alternatives that work for them. And that's exactly what I've seen over and over again, in different communities, such as the ones I've mentioned, this attitude of "you're holding it wrong". No language or tool can be everything to everybody, that's perfectly reasonable. If the goal of Julia is different from that of people that want to run applications in production—or at least those concerns aren't the most important ones—fair enough. But all too often (and I'm not necessarily talking about Julia here; I haven't spent enough time on the Julia forums, I'm mostly referring to some of the other examples I've cited) real concerns are just dismissed out of hand. I also don't believe that enforcing certain very specific workflows at the exclusion of any others is necessarily a great way to become a language that lots of people want to use. People come from different backgrounds and have different preferences and needs (sometimes for very good reasons), successful languages like Python recognise this and let you work with a wide range of tools. Finally, I'm just very skeptical about a certain kind of NIH syndrome that I've seen in some of these communities, something like "encapsulation? well, all these other languages might need it, but we actually don't, because XYZ" or similar things.
  - mbauman 5y ago
    I mean, you're totally free to blaze your own development workflow trail. Even better if you can help in the ongoing clearing and paving of the less-used trails. But when someone complains that a less-used trail is rocky, it's gonna be hard for everyone on the golden brick road to avoid suggesting taking their route... especially if it's leading to the same destination. And yes, that destination does include production.
    - jampekka 5y ago
      Yes you are, but then you have to wait a minute or so after any single change to any file if you do a script workflow. If you do a Revise workflow you end up doing mostly the same because it just breaks all the time and you have to reload the session. Or you can use some bizarre hack like DaemonMode.jl that also just breaks all the time. Julia is hard to debug as is (and this is fully acceptable to me due to the architecture) and these hacks on hacks make it just impossible. Julia suffers from the same "fancy calculator" approach than e.g. R and Matlab, and like those, they refuse to take note of the decades of experience in software development that this just leads to a total mess if you have anything more complicated than a one-off analysis. It's like insisting on editing files with ed because that's how it's always been done.
      - mbauman 5y ago
        And this is precisely why this dynamic exists — because there are workflows with far less friction than what you've experienced. I and others successfully use them every day for things far more complicated than one-off analyses. I think your view of Julia as a "fancy calculator" may be part and parcel to the difficulty. I do use it as a fancy calculator, but I also use local packages all the time — and that's where you'll find the best success in both tooling and code structure for sustainable (and modern) development. We need to do a better job of helping folks more effectively develop and work with Julia before it becomes frustrating.
        jampekka 5y ago