4 ms·

What do you mean by TTFP? Is this like "time to first byte"? If so, what is the "P"? In any case, if the complaint is startup time, I do agree that this has be

What do you mean by TTFP? Is this like "time to first byte"? If so, what is the "P"? In any case, if the complaint is startup time, I do agree that this has been a bit of a thorn in the side. It also interacts poorly with a (in my view) pretty immature ecosystem for running services (for instance, the grpc library doesn't seem to be widely used or heavily maintained) or interacting with it via IPC. So it's great if you can spin up a notebook or repl and leave it running all day doing your work, or if you have a long-running batch process, but I agree that I've found it a bit tricky to interact with it from the outside world in the "usual" ways. Having said that, it does work - for instance, a system I work on spins up a long-lived julia thread from within a python service using the very nice shared library, and calls into julia functionality through that thread - I've just found it to be tricky; but IMO still very much worth it.

jampekka 3y ago
Time to first plot (this is the time you have to wait for any plot if you don't do REPL/notebook in analyses). It's a commonly used term in Julia discussions. Nowadays also called TTFX where X can refer to variety of things.
- sanderjd 3y ago
  Ah thanks! I'm relatively new to Julia and don't frequent discussion forums (yet?) and didn't have much luck searching for it. I figured out that it was an X in TTFX, but thought maybe, "print"? In any case, yep, makes sense, thanks! I guess for the typical scientific experimentation with plotting use case, why not just use the repl / notebook approach that (I think?) doesn't really suffer from this issue, as it's already up and running? My experience with startup time being problematic is when trying to "productionize" things that are not within a scientific / plotting loop. But my impression has been that it works well when doing things that are. Am I missing it?
  - jampekka 3y ago
    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.
    - sanderjd 3y ago
      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 :)
      - jampekka 3y ago
        > 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.
cyber_kinetist 3y ago
> What do you mean by TTFP? Time To First Plot. It was a meme back then that you needed to wait several minutes to draw just a simple line plot after starting up a Julia REPL/notebook because of compilation times (whereas in Python you're done in seconds with matplotlib.) Seems this has been reduced in Julia 1.9 with automatic pre-compilation of packages, but plotting still isn't "instant" as you would expect in scripting languages like Python.
- sgt101 3y ago
  It seems instant to me - the package compile on first invocation is rather like installing with pip or conda, and then after that I see the plot in about 1/20th second.
  - leephillips 3y ago
    The REPL starts up instantly and the first plot is < 1s. People seem to be repeating complaints (valid at the time) that they overheard from three years ago.
    - jampekka 3y ago
      This is not the complaint. The complaint is that running "$ julia someplotting.jl" takes a long time (actually with 1.9.0 it's reasonable at < 3s, but adding other libraries makes it easily tens of seconds or even minutes). Everybody doesn't use the REPL. In my, I think quite well founded, opinion nobody should use the REPL for more than one or two lines.
      - sanderjd 3y ago
        For what it's worth, as someone who shares a sense that "scientific" programmers have a tendency to over-use notebooks and REPLs, I find your perspective on it to be too extreme in the other direction! It's perfectly possible to incorporate interactive tools into a good software development process.

jampekka 3y ago

Time to first plot (this is the time you have to wait for any plot if you don't do REPL/notebook in analyses). It's a commonly used term in Julia discussions. Nowadays also called TTFX where X can refer to variety of things.

sanderjd 3y ago
Ah thanks! I'm relatively new to Julia and don't frequent discussion forums (yet?) and didn't have much luck searching for it. I figured out that it was an X in TTFX, but thought maybe, "print"? In any case, yep, makes sense, thanks! I guess for the typical scientific experimentation with plotting use case, why not just use the repl / notebook approach that (I think?) doesn't really suffer from this issue, as it's already up and running? My experience with startup time being problematic is when trying to "productionize" things that are not within a scientific / plotting loop. But my impression has been that it works well when doing things that are. Am I missing it?
- jampekka 3y ago
  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.
  - sanderjd 3y ago
    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 :)
    - jampekka 3y ago
      > 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.

cyber_kinetist 3y ago

> What do you mean by TTFP? Time To First Plot. It was a meme back then that you needed to wait several minutes to draw just a simple line plot after starting up a Julia REPL/notebook because of compilation times (whereas in Python you're done in seconds with matplotlib.) Seems this has been reduced in Julia 1.9 with automatic pre-compilation of packages, but plotting still isn't "instant" as you would expect in scripting languages like Python.

sgt101 3y ago
It seems instant to me - the package compile on first invocation is rather like installing with pip or conda, and then after that I see the plot in about 1/20th second.
- leephillips 3y ago
  The REPL starts up instantly and the first plot is < 1s. People seem to be repeating complaints (valid at the time) that they overheard from three years ago.
  - jampekka 3y ago
    This is not the complaint. The complaint is that running "$ julia someplotting.jl" takes a long time (actually with 1.9.0 it's reasonable at < 3s, but adding other libraries makes it easily tens of seconds or even minutes). Everybody doesn't use the REPL. In my, I think quite well founded, opinion nobody should use the REPL for more than one or two lines.
    - sanderjd 3y ago
      For what it's worth, as someone who shares a sense that "scientific" programmers have a tendency to over-use notebooks and REPLs, I find your perspective on it to be too extreme in the other direction! It's perfectly possible to incorporate interactive tools into a good software development process.