[enriquto]

> Why use Octave instead of R, Python, or Julia?

I use Octave daily, for many numerical tasks (and also python and julia). It has some advantages with respect to Python:

1. The sparse linear solvers in octave are considerably more performant than those available in a default scipy install.

2. No need to import external libraries written in other languages just to multiply two matrices.

3. Translating a formula from the blackboard to octave is really straightforward. This is often not the case for numpy.

As for julia, the base language is even better than octave. However, it is not as useful for one-off scripts due to the slow startup time. You can use octave as a calculator for your shell scripts. For instance, one day I had to warp a collection of images by a collection of affine maps; the affine maps were the product of two matrices stored in individual files. Thus I wrote a three-line shell loop that called octave for each file and did the deed. The loop processed 200 files in five seconds (even without parallelism). In julia this would take a few minutes.

[nwvg_7257]

I would encourage you to try this again on Julia 1.8. Startup time has improved a lot. A few minutes seems way too long to process some images. Even plotting should happen within 20-30s now.

[doodlesdev]

Possibly related recent discussion: https://news.ycombinator.com/item?id=35106488

[enriquto]

Will try! The image warping was done by an external program. Julia was used just to multiply two matrices of size 3x3 for each image in the collection. Launching the interpreter took almost a whole second, the rest of the computation was instantaneous.

[dunefox]

Did you launch Julia for each image separately?

[enriquto]

Yes. I was using julia as a shell calculator to multiply small matrices. Octave happens to be much faster for this (admittedly niche) use case.

[bluenose69]

Working this way is pretty common for small tasks. As has been suggested, Julia 1.9 is a lot faster than it was before. I find it's more like 4 seconds than 0.5 seconds, though.

With plot.jl as

    $ cat plot.jl
    using Plots
    x = range(0, 10, length=100)
    y = sin.(x)
    plot(x, y)

I find that

    $ time julia plot.jl

yields

    4.19s user 0.50s system 106% cpu 4.409 total

[enriquto]

Plotting is a complicated beast. If you just want to multiply matrices, there's no "using" statement and you get sub-second running times. Still geologically slow, but at least somewhat manageable.

[ViralBShah]

Startup time for plots is down to <0.5s with Julia 1.9 (in beta).

[Nanana909]

For one off Julia scripts consider using

https://github.com/dmolina/DaemonMode.jl

[mort96]

> 2. No need to import external libraries written in other languages just to multiply two matrices.

I suppose I maybe get the "no need to import external libraries" thing, 'pip3 install numpy' is technically an extra step that wouldn't have been necessary if the standard library contained a decent matrix module.

But why do you care about the "written in other languages" part? That has literally never caused issues for me with Python. Especially something as popular as numpy just works across all platforms I've tried (x86_64 Windows, Linux and macOS, aarch64 Linux and macOS). Do you frequently encounter issues which are caused by the Fortran portion of Numpy's source code?

[enriquto]

> Do you frequently encounter issues which are caused by the Fortran portion of Numpy's source code?

No practical issues at all. The problem is not the pip install numpy that only happens once, but the import numpy that must appear on every single one of your programs. I interpret it as a permanent reminder that numerical computation is not natively supported in the language, and that we will always be foreigners in there.