5 ms·

> 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'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
      Friction in general, or friction specific to Julia? My view is that Julia (and R and Matlab etc) ecosystem's view is a "fancy calculator". It's hard to integrate to anything else, it almost actively tries to make e.g. unix-type workflow difficult (not much CLI, everything done in REPL, e.g. package management). Not as bad as e.g. R where its almost impossible to just run a file of code instead of doing a "workflow session". Perhaps there is some disconnect in how different parties of the discussion see the whole thing. For me this sounds a lot like "you're holding it wrong". What background are you coming from and what languages/programming environments you are familiar with? I get the impression that you don't have much general purpose programming background and somehow tend to assume that people are using "wrong workflows" due to being just stupid or something. But this is how it comes off to me, I think you mean something else, but I don't know what that is. My approach is: I want files with code and I want to run some of those with some kind of entry point. And preferably organize it to files or something like that. This is the usual setup for general purpose programming languages. In general purpose programming you rarely tend to stick solely to one language, any larger project is usually a mishmash of different stuff, e.g. glue code in python, tight loops in C, maybe some bash thrown around to do some more trivial chores. This is the overall structure of practically all general purpose programming languages. This requires interfacing with these languages (often done in bash or something in unixy systems at least) and tools that work regardless of language (e.g. version control, grepping, Make etc). Julia (and R and Matlab etc) just plain refuse to even consider this as a valid approach. If you mention it somewhere, you tend to get some bizarre instant putdowns that provide no real rationale, i.e. "you're just holding it wrong". In programming I tend to think the whole computer and its OS and so on as the programming tool. My impression is that for Julia folks Julia is something totally separate from anything else in the computer. But I don't understand why. Is it that its felt that changing syntax on the fly is too cognitively demanding or something? This is something that one gets used to very fast. And also tends to ease the IMHO weird hung-ups on syntax. In fact, I think Julia has made some (IMHO misguided) syntactic decisions because they just want to do something differently from Python just for the sake of being different. I find this totally senseless. Us CLI folks are not even asking for much. Just a way to call a program with arguments and so that you don't have to do compile identical code every time you do something. That's it. Is that unreasonable? It wouldn't take anything away from people using REPLs and Notebooks. We don't want to change the language, the language is fine and that's why we'd like to use it but just cant because these paper cuts! I've expanded on my rationale for my workflow and how Julia makes it really difficult e.g. here, where I admittedly started with too strong wordings out of frustration: https://news.ycombinator.com/item?id=26134970 https://news.ycombinator.com/item?id=26134970
ChrisRackauckas 5y ago
>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". You're really reading this wrong. The issue is moreso about personal knowledge. I see this on the Discourse sometimes where someone comes blazing in saying "I want to use PyCharm for Julia and I run into ...", "Special Lisp-only IDE has a Julia plugin and it fails because ...", or "I have this special terminal setup and I no 0 latency and ...". The answer of course is, if you need help, use VS Code or Juno/Atom. Those have a larger userbase which that has fixed exactly those issues and has a helpful dev community on those site which will get you up and running. That's not "you're holding it wrong", that's people trying to help you into an area where they know how to help you. You can shrug it all off and blame it on them, but at the end of the day, people are sharing what they know works, a reliable solution they built for exactly this problem, and then are getting flamed on the internet for having "NIH syndrome" for not fixing some random IDE plugin they've never used. I just don't see how you can expect every person to be an expert on every possible workflow you can imagine and start throwing flame when someone tries to lead you to water. In the Julia community in particular you tend to have people who are more experts in their scientific domains. I am in that category: I can help you in anything ML, high performance computing, differential equations, etc. but I use Windows and the Juno IDE. If you open an issue about something weird happening on emacs, I wouldn't even know how to get it installed, sorry, that's not my expertise. The Julia community has a lot more people in probabilistic programming than it has Javascript devs, and so people share how they know how to fix your problem "can you run it in VS Code and show the profile?", not "here's how to run some daemon server thing" etc. And that's perfectly fine, it has its advantages and disadvantages.

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
    Friction in general, or friction specific to Julia? My view is that Julia (and R and Matlab etc) ecosystem's view is a "fancy calculator". It's hard to integrate to anything else, it almost actively tries to make e.g. unix-type workflow difficult (not much CLI, everything done in REPL, e.g. package management). Not as bad as e.g. R where its almost impossible to just run a file of code instead of doing a "workflow session". Perhaps there is some disconnect in how different parties of the discussion see the whole thing. For me this sounds a lot like "you're holding it wrong". What background are you coming from and what languages/programming environments you are familiar with? I get the impression that you don't have much general purpose programming background and somehow tend to assume that people are using "wrong workflows" due to being just stupid or something. But this is how it comes off to me, I think you mean something else, but I don't know what that is. My approach is: I want files with code and I want to run some of those with some kind of entry point. And preferably organize it to files or something like that. This is the usual setup for general purpose programming languages. In general purpose programming you rarely tend to stick solely to one language, any larger project is usually a mishmash of different stuff, e.g. glue code in python, tight loops in C, maybe some bash thrown around to do some more trivial chores. This is the overall structure of practically all general purpose programming languages. This requires interfacing with these languages (often done in bash or something in unixy systems at least) and tools that work regardless of language (e.g. version control, grepping, Make etc). Julia (and R and Matlab etc) just plain refuse to even consider this as a valid approach. If you mention it somewhere, you tend to get some bizarre instant putdowns that provide no real rationale, i.e. "you're just holding it wrong". In programming I tend to think the whole computer and its OS and so on as the programming tool. My impression is that for Julia folks Julia is something totally separate from anything else in the computer. But I don't understand why. Is it that its felt that changing syntax on the fly is too cognitively demanding or something? This is something that one gets used to very fast. And also tends to ease the IMHO weird hung-ups on syntax. In fact, I think Julia has made some (IMHO misguided) syntactic decisions because they just want to do something differently from Python just for the sake of being different. I find this totally senseless. Us CLI folks are not even asking for much. Just a way to call a program with arguments and so that you don't have to do compile identical code every time you do something. That's it. Is that unreasonable? It wouldn't take anything away from people using REPLs and Notebooks. We don't want to change the language, the language is fine and that's why we'd like to use it but just cant because these paper cuts! I've expanded on my rationale for my workflow and how Julia makes it really difficult e.g. here, where I admittedly started with too strong wordings out of frustration: https://news.ycombinator.com/item?id=26134970 https://news.ycombinator.com/item?id=26134970

ChrisRackauckas 5y ago

>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". You're really reading this wrong. The issue is moreso about personal knowledge. I see this on the Discourse sometimes where someone comes blazing in saying "I want to use PyCharm for Julia and I run into ...", "Special Lisp-only IDE has a Julia plugin and it fails because ...", or "I have this special terminal setup and I no 0 latency and ...". The answer of course is, if you need help, use VS Code or Juno/Atom. Those have a larger userbase which that has fixed exactly those issues and has a helpful dev community on those site which will get you up and running. That's not "you're holding it wrong", that's people trying to help you into an area where they know how to help you. You can shrug it all off and blame it on them, but at the end of the day, people are sharing what they know works, a reliable solution they built for exactly this problem, and then are getting flamed on the internet for having "NIH syndrome" for not fixing some random IDE plugin they've never used. I just don't see how you can expect every person to be an expert on every possible workflow you can imagine and start throwing flame when someone tries to lead you to water. In the Julia community in particular you tend to have people who are more experts in their scientific domains. I am in that category: I can help you in anything ML, high performance computing, differential equations, etc. but I use Windows and the Juno IDE. If you open an issue about something weird happening on emacs, I wouldn't even know how to get it installed, sorry, that's not my expertise. The Julia community has a lot more people in probabilistic programming than it has Javascript devs, and so people share how they know how to fix your problem "can you run it in VS Code and show the profile?", not "here's how to run some daemon server thing" etc. And that's perfectly fine, it has its advantages and disadvantages.