The main problem with REPL/notebook approach is that it has an "invisible state". E.g. running the cells in different order or running the same line in REPL twice can cause different behavior. This leads to major issues in e.g. reproducibility, easily introduces bugs that even leave no trace and generally it's very much against very core software development principles. Pluto.jl reportedly solves this, gotta try it out.
My scientific/plotting loop runs from Bash (something not solved by Pluto.jl). This allows me to interoperate with a lot of software that's not in Python. I can version the code with e.g. git and the analysis pipeline tends to get refactored into libraries and CLI tools in the process. With Julia this is in practice impossible.
I definitely don't think "impossible" seems like the right word. I do buy that it might be frustratingly slow to the point of not being worthwhile.
I do wonder if Pluto.jl might solve a lot of these issues for you though. I haven't really used it much, but it seems like it works with just plain .jl files, so you can non-jankily version them (unlike .ipynb), and extract libraries and refactor in all the normal ways.
My frustrations trying to do normal-software-development-principles with julia are actually more about the convention the community has around structuring files and modules, which just hasn't clicked for me at all and is a frequent source of confusion. (The testing framework / layout / something about it also hasn't clicked for me yet either, and I wonder if it just isn't great and that's why people don't seem to write many tests...)
But there's also just so much great stuff about the language that I'm not even really mad about any of this :)
> I definitely don't think "impossible" seems like the right word. I do buy that it might be frustratingly slow to the point of not being worthwhile.
That is more accurate.
> I do wonder if Pluto.jl might solve a lot of these issues for you though. I haven't really used it much, but it seems like it works with just plain .jl files, so you can non-jankily version them (unlike .ipynb), and extract libraries and refactor in all the normal ways.
It may solve enough issues at least for some cases. I'll check it out.
> My frustrations trying to do normal-software-development-principles with julia are actually more about the convention the community has around structuring files and modules, which just hasn't clicked for me at all and is a frequent source of confusion. (The testing framework / layout / something about it also hasn't clicked for me yet either, and I wonder if it just isn't great and that's why people don't seem to write many tests...)
From what I remember from the last time the module system was indeed quite a pain. The using/include/use seems like a total mess, and that IIRC Stefan Karpinski dismissed files-as-modules solely on the reason that Python does it that way did not really bring my hopes up.
I appreciate that the multiple dispatch design (which I find very much a pro for Julia) does bring about some additional challenges for a module system. But my hunch is that majority is because Julia was so strongly made by MATLABists to MATLABists (can replace MATLAB with e.g. R or Mathematica) that basic features required for a general purpose language were not much taken into account.
> But there's also just so much great stuff about the language that I'm not even really mad about any of this :)
This is exactly why I'm so mad about this! I would love to use all that great stuff AND follow good programming principles, but now I can't.
Yeah, maybe I'm just not jaded enough yet, but all the issues I've seen seem relatively superficial and solvable to me. It feels more like immaturity pains than fatal flaws to me. But it's not so young anymore, so maybe the immaturity is more insurmountable than it seems to me. I dunno!
My scientific/plotting loop runs from Bash (something not solved by Pluto.jl). This allows me to interoperate with a lot of software that's not in Python. I can version the code with e.g. git and the analysis pipeline tends to get refactored into libraries and CLI tools in the process. With Julia this is in practice impossible.