3 ms·

Of course! Once I realize that after a few seconds only a dozen images have been processed I cut the loop, remember that the julia repl is dog slow, and then, r

Of course! Once I realize that after a few seconds only a dozen images have been processed I cut the loop, remember that the julia repl is dog slow, and then, rewrite the task in a different way. But I would prefer not to have to do that. Moreover, for more complicated examples, there may be data dependencies that make the loop commutation non trivial. The slow startup time may be a minor inconvenience, I agree. But nonetheless it seems to be a case of sloppy engineering, as other scripting languages do not have this egregious problem. It sets a bad tone, and makes me wonder if there are other hidden monsters inside the interpreter, that may be solved by "you are holding it wrong" like this one.

xiphias2 8y ago
You have to use it inside a REPL, like R or Matlab. Julia using LLVM and compiling on-the-fly is not sloppy design, it's a design tradeoff (and a great one, if you really need speed). Julia is not a scripting language, it's a language for mathematical analysis. Also going back to your example the solution would be to use ImageMagick.jl from Julia, and extend the library (4 extra lines with ccall) if it's not available, and send a pull request to help the community.
- enriquto 8y ago
  > Julia is not a scripting language, it's a language for mathematical analysis. Ok, this clarifies the matter a lot. So julia is not intended to be a general-purpose programming language. Are you involved in julia development? (Besides, I strongly dislike the design tradeoff of not being a good unix citizen.)
  - agumonkey 8y ago
    Not Scripting != Not general purpose
  - ddragon 8y ago
    Julia is a general-purpose programming language. The language itself is actually really good as a scripting language, including integrating well with shell, C, Fortran, R and Python, for example: https://docs.julialang.org/en/latest/manual/running-external-programs/#Pipelines-1 https://docs.julialang.org/en/latest/manual/running-external... The only trade-off here is the restricted resources the Julia devs can afford. Focusing on the scientific computation niche, the Julia compiler was built to compile code just ahead of time, since this way it can create code as fast as compiled languages while still being dynamic like any interpreted language (such as Matlab and Python). But there is nothing in the language that prevents it from being fully interpreted (and therefore having minimal compile time overhead, but generating poorly optimized code for long running processes), or alternatively pre-compiling and caching to have both (which is being worked on: https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl )
  - xiphias2 8y ago
    I'm not a Julia developer, but the great thing with Julia is that the libraries are exceptionally easy to read and extend, because the core developers make a strong effort to write clean code. Just look at ImageMagick.jl and you'll see, but I have the same experience with other libraries as well. Also the language itself supports extending code (multiple dispatch really helps it to stay clean).
agumonkey 8y ago
Yeah I get it, it's inconvenient. But I taking the jvm thing again, I think julia's value is outside of this way of doing things. Out of curiosity I timed ocaml $ time echo 'let x = "1" in print_endline(x)' | ocaml -stdin - 1 real 0m0.045s user 0m0.039s sys 0m0.007s I thought julia init time was due to type checking phase but ocaml seems to have no issue, even with non zero code: $ time echo 'let l = [1;2;3;4] in let m = List.map (fun x -> x*x) l in print_int(List.length(m))' | ocaml -stdin - 4 real 0m0.050s user 0m0.040s sys 0m0.011s Sad, I liked a lot of Julia features.. ps: this hints at the init time being constant recompilation of its core https://www.reddit.com/r/Julia/comments/4c09m1/julia_045_startup_time_on_windows/ https://www.reddit.com/r/Julia/comments/4c09m1/julia_045_sta... and they were thinking (2 years ago) of caching..
- dnautics 8y ago
  What were you planning to use Julia for where its init time matters?
  - agumonkey 8y ago
    Nothing, i'm just curious [1] about Julia. I never used it. [1]It's just because i find the science python stack a bit absurd.
    - krull10 8y ago
      Right now, using is as a “quick” command line utility for solving small problems is probably not a good Julia work flow (unless the overhead you mention doesn’t matter to your application). Where it shines is for longer-running or repeated computations where the initial compilation cost of starting a new REPL doesn’t matter.
      - agumonkey 8y ago
        Preaching the convinced

xiphias2 8y ago

You have to use it inside a REPL, like R or Matlab. Julia using LLVM and compiling on-the-fly is not sloppy design, it's a design tradeoff (and a great one, if you really need speed). Julia is not a scripting language, it's a language for mathematical analysis. Also going back to your example the solution would be to use ImageMagick.jl from Julia, and extend the library (4 extra lines with ccall) if it's not available, and send a pull request to help the community.

enriquto 8y ago
> Julia is not a scripting language, it's a language for mathematical analysis. Ok, this clarifies the matter a lot. So julia is not intended to be a general-purpose programming language. Are you involved in julia development? (Besides, I strongly dislike the design tradeoff of not being a good unix citizen.)
- agumonkey 8y ago
  Not Scripting != Not general purpose
- ddragon 8y ago
  Julia is a general-purpose programming language. The language itself is actually really good as a scripting language, including integrating well with shell, C, Fortran, R and Python, for example: https://docs.julialang.org/en/latest/manual/running-external-programs/#Pipelines-1 https://docs.julialang.org/en/latest/manual/running-external... The only trade-off here is the restricted resources the Julia devs can afford. Focusing on the scientific computation niche, the Julia compiler was built to compile code just ahead of time, since this way it can create code as fast as compiled languages while still being dynamic like any interpreted language (such as Matlab and Python). But there is nothing in the language that prevents it from being fully interpreted (and therefore having minimal compile time overhead, but generating poorly optimized code for long running processes), or alternatively pre-compiling and caching to have both (which is being worked on: https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl )
- xiphias2 8y ago
  I'm not a Julia developer, but the great thing with Julia is that the libraries are exceptionally easy to read and extend, because the core developers make a strong effort to write clean code. Just look at ImageMagick.jl and you'll see, but I have the same experience with other libraries as well. Also the language itself supports extending code (multiple dispatch really helps it to stay clean).

agumonkey 8y ago

Yeah I get it, it's inconvenient. But I taking the jvm thing again, I think julia's value is outside of this way of doing things. Out of curiosity I timed ocaml $ time echo 'let x = "1" in print_endline(x)' | ocaml -stdin - 1 real 0m0.045s user 0m0.039s sys 0m0.007s I thought julia init time was due to type checking phase but ocaml seems to have no issue, even with non zero code: $ time echo 'let l = [1;2;3;4] in let m = List.map (fun x -> x*x) l in print_int(List.length(m))' | ocaml -stdin - 4 real 0m0.050s user 0m0.040s sys 0m0.011s Sad, I liked a lot of Julia features.. ps: this hints at the init time being constant recompilation of its core https://www.reddit.com/r/Julia/comments/4c09m1/julia_045_startup_time_on_windows/ https://www.reddit.com/r/Julia/comments/4c09m1/julia_045_sta... and they were thinking (2 years ago) of caching..

dnautics 8y ago
What were you planning to use Julia for where its init time matters?
- agumonkey 8y ago
  Nothing, i'm just curious [1] about Julia. I never used it. [1]It's just because i find the science python stack a bit absurd.
  - krull10 8y ago
    Right now, using is as a “quick” command line utility for solving small problems is probably not a good Julia work flow (unless the overhead you mention doesn’t matter to your application). Where it shines is for longer-running or repeated computations where the initial compilation cost of starting a new REPL doesn’t matter.
    - agumonkey 8y ago
      Preaching the convinced