6 ms·

That book is ancient, but probably still pretty relevant. John Harrop himself posted on reddit awhile back that he hadn't personally used OCaml in a long time w

That book is ancient, but probably still pretty relevant. John Harrop himself posted on reddit awhile back that he hadn't personally used OCaml in a long time when someone asked about the book on the OCaml sub reddit. His username starts with jdh I think. Honestly though, scientific computing seems to be going Julia. Really good numeric, optimization, charting, linear algebra, parallel & distributed computing...etc. It's all free and open source. Julia Computing was founded to provide enterprise support and services including auditing and affordable cloud computing. This is the direction I'm moving towards. You should check out the case studies on Julia Computing.

philipov 8y ago
What kind of case studies? The number one thing I care about in a scientific computing platform is library support: how does Julia perform on that? Do they have ML libraries to compete with PyTorch and Tensorflow? How about geometric calculations such as Voronoi and Convex Hull? Can it handle noneuclidean geometry? Is there a good library for network analysis? GIS? Do they have a symbolic computation library to stand up to SymPy? If Julia can answer Yes to all of the above, then maybe it's worth checking out.
- acangiano 8y ago
  It would seem to me that a priority of the project should be built-in integration with Python or R. A high-level FFI of the sort.
  - ChrisRackauckas 8y ago
    Like RCall.jl and PyCall.jl? These have been around for awhile and are pretty simple to use. Just `@pyimport Package` and now `Package.function()` works, along with other things.
    - acangiano 8y ago
      Excellent.
- ChrisRackauckas 8y ago
  Yes, yes, yes, yes? Flux.jl and KNet.jl. LightGraphs.jl. Etc. You can find these packages on JuliaObserver.com. Some of them are handled by PyCall interfaces: SymPy.jl, SymEngine.jl, QHull.jl, etc.
  - philipov 8y ago
    Sweet, PyCall looks awesome and exactly what I was hoping for. Full interop with no copying; I look forward to learning how it was implemented. Thanks! Is there a mature option for calling Julia from Python?
    - ChrisRackauckas 8y ago
      There's pyjulia. We used it to build the diffeqpy package. It's not too mature yet.
gaius 8y ago
John Harrop himself posted on reddit awhile back that he hadn't personally used OCaml in a long time when someone asked about the book on the OCaml sub reddit. His username starts with jdh I think. Honestly though, scientific computing seems to be going Julia He’s mainly converted to F# if I remember correctly. He was often in flamewars on OCaml mailing lists about multicore support. There is a bit of hype around Julia but it’s use in the real world is a rounding error compared to Python, R, MATLAB, FORTRAN etc etc. I might look at it again in 5 years or so. OCaml never gained any significant traction in scientific or numerical computing. You can try F# on https://notebooks.azure.com https://notebooks.azure.com for free
- xfer 8y ago
  He uses F# because windows and teaching, i have seen him advocate to use Ocaml on unix systems.
  - 3rdAccount 8y ago
    I'd imagine having the full .NET framework is the main draw in addition to all the F# visualization and data analysis libraries and type providers.
bachmeier 8y ago
> Honestly though, scientific computing seems to be going Julia. I think that the days where one language gets momentum and becomes "the" language for some scientific computing task are gone. No doubt Julia does have momentum. However, these days interoperability is rapidly improving, and we are rapidly moving to an equilibrium where you can more or less choose your own language and not worry too much about it being the "right" language, because you can call libraries written in numerous other languages. I certainly hope that's where we're going.
kxyvr 8y ago
I work professionally as an applied mathematician and I've struggled to understand where Julia fits into the tools already available. In terms of prototyping algorithms, MATLAB/Octave still seems to be the best choice. We have access to an enormous number of builtin routines that help diagnose what's going on when an algorithm breaks. That's not to say other language don't, but the ability to set a single dbstop command and then run some kind of diagnostic like plotting the distribution of eigenvalues with d=eig(A); plot(real(d),imag(d),'x') is amazing and saves time. There's also a very straightforward workflow to run the debugger and then drop into gdb in case the case we need to interact with external libraries. Now, certainly, MATLAB/Octave is weak, in my opinion, for generating larger software projects that need to interact with the rest of the world. This includes things like network connections, GUIs, database access, etc. Alternatively, sometimes a new low level driver needs to be written, which needs to be very fast. All that same, that ecosystem seems to be much better in languages like C++ and Python. Though, I've been experimenting with Rust as an alternative to C++ for this use case. At this point, if I have trouble with the algorithms, I can run it in parallel with the MATLAB/Octave to diagnose how things differ. Coming back to Julia, where is it supposed to fit in? To me, there's a better prototyping language, production language, and bare metal fast language. I will make one last quip and that's the licensing. Frankly, the big advantage of MATLAB is that it provides license cover. Mathworks has obtained the appropriate licenses for your expensive factorizations and sparse matrix methodology. Julia has not and they remain largely under GPL: https://github.com/JuliaLang/julia/blob/master/LICENSE.md https://github.com/JuliaLang/julia/blob/master/LICENSE.md Look at things like SUITESPARSE. Practically, what that means is that I can deliver MATLAB code to my clients and I don't have to disclose the source externally due to GPL requirements. Now, maybe they choose to run Octave. That's fine and then they can assume the responsibility for GPL code. However, for me, I maintain a MATLAB license and that gives me coverage for a whole host of other licenses in the context of MATLAB code and that makes my life vastly easier than if I were to develop and deliver code in another language.
- ChrisRackauckas 8y ago
  MATLAB, Python, and R don't have the metaprogramming tools for code generation. Tools like FFTW relied heavily on code generation, and people who wrote those kinds of tools are now using Julia for generic programming. Generic programming is difficult to handle with any AOT compilation system since you get a combinatoric explosion of possibilities leading to large compile times. Generic programming works great in Julia so there's a lot of examples of utilizing types for "free features" that would be difficult to do (interactively) in any other language. Of course, most programmers don't know what generic programming even is. However, a lot of libraries these days utilize it in order to get different precision and all of that, which is why I think Julia will at least become a language of libraries since not too many people can invest so much time in C++.

philipov 8y ago

What kind of case studies? The number one thing I care about in a scientific computing platform is library support: how does Julia perform on that? Do they have ML libraries to compete with PyTorch and Tensorflow? How about geometric calculations such as Voronoi and Convex Hull? Can it handle noneuclidean geometry? Is there a good library for network analysis? GIS? Do they have a symbolic computation library to stand up to SymPy? If Julia can answer Yes to all of the above, then maybe it's worth checking out.

acangiano 8y ago
It would seem to me that a priority of the project should be built-in integration with Python or R. A high-level FFI of the sort.
- ChrisRackauckas 8y ago
  Like RCall.jl and PyCall.jl? These have been around for awhile and are pretty simple to use. Just `@pyimport Package` and now `Package.function()` works, along with other things.
  - acangiano 8y ago
    Excellent.
ChrisRackauckas 8y ago
Yes, yes, yes, yes? Flux.jl and KNet.jl. LightGraphs.jl. Etc. You can find these packages on JuliaObserver.com. Some of them are handled by PyCall interfaces: SymPy.jl, SymEngine.jl, QHull.jl, etc.
- philipov 8y ago
  Sweet, PyCall looks awesome and exactly what I was hoping for. Full interop with no copying; I look forward to learning how it was implemented. Thanks! Is there a mature option for calling Julia from Python?
  - ChrisRackauckas 8y ago
    There's pyjulia. We used it to build the diffeqpy package. It's not too mature yet.

gaius 8y ago

John Harrop himself posted on reddit awhile back that he hadn't personally used OCaml in a long time when someone asked about the book on the OCaml sub reddit. His username starts with jdh I think. Honestly though, scientific computing seems to be going Julia He’s mainly converted to F# if I remember correctly. He was often in flamewars on OCaml mailing lists about multicore support. There is a bit of hype around Julia but it’s use in the real world is a rounding error compared to Python, R, MATLAB, FORTRAN etc etc. I might look at it again in 5 years or so. OCaml never gained any significant traction in scientific or numerical computing. You can try F# on https://notebooks.azure.com https://notebooks.azure.com for free

xfer 8y ago
He uses F# because windows and teaching, i have seen him advocate to use Ocaml on unix systems.
- 3rdAccount 8y ago
  I'd imagine having the full .NET framework is the main draw in addition to all the F# visualization and data analysis libraries and type providers.

bachmeier 8y ago

> Honestly though, scientific computing seems to be going Julia. I think that the days where one language gets momentum and becomes "the" language for some scientific computing task are gone. No doubt Julia does have momentum. However, these days interoperability is rapidly improving, and we are rapidly moving to an equilibrium where you can more or less choose your own language and not worry too much about it being the "right" language, because you can call libraries written in numerous other languages. I certainly hope that's where we're going.

kxyvr 8y ago

I work professionally as an applied mathematician and I've struggled to understand where Julia fits into the tools already available. In terms of prototyping algorithms, MATLAB/Octave still seems to be the best choice. We have access to an enormous number of builtin routines that help diagnose what's going on when an algorithm breaks. That's not to say other language don't, but the ability to set a single dbstop command and then run some kind of diagnostic like plotting the distribution of eigenvalues with d=eig(A); plot(real(d),imag(d),'x') is amazing and saves time. There's also a very straightforward workflow to run the debugger and then drop into gdb in case the case we need to interact with external libraries. Now, certainly, MATLAB/Octave is weak, in my opinion, for generating larger software projects that need to interact with the rest of the world. This includes things like network connections, GUIs, database access, etc. Alternatively, sometimes a new low level driver needs to be written, which needs to be very fast. All that same, that ecosystem seems to be much better in languages like C++ and Python. Though, I've been experimenting with Rust as an alternative to C++ for this use case. At this point, if I have trouble with the algorithms, I can run it in parallel with the MATLAB/Octave to diagnose how things differ. Coming back to Julia, where is it supposed to fit in? To me, there's a better prototyping language, production language, and bare metal fast language. I will make one last quip and that's the licensing. Frankly, the big advantage of MATLAB is that it provides license cover. Mathworks has obtained the appropriate licenses for your expensive factorizations and sparse matrix methodology. Julia has not and they remain largely under GPL: https://github.com/JuliaLang/julia/blob/master/LICENSE.md https://github.com/JuliaLang/julia/blob/master/LICENSE.md Look at things like SUITESPARSE. Practically, what that means is that I can deliver MATLAB code to my clients and I don't have to disclose the source externally due to GPL requirements. Now, maybe they choose to run Octave. That's fine and then they can assume the responsibility for GPL code. However, for me, I maintain a MATLAB license and that gives me coverage for a whole host of other licenses in the context of MATLAB code and that makes my life vastly easier than if I were to develop and deliver code in another language.

ChrisRackauckas 8y ago
MATLAB, Python, and R don't have the metaprogramming tools for code generation. Tools like FFTW relied heavily on code generation, and people who wrote those kinds of tools are now using Julia for generic programming. Generic programming is difficult to handle with any AOT compilation system since you get a combinatoric explosion of possibilities leading to large compile times. Generic programming works great in Julia so there's a lot of examples of utilizing types for "free features" that would be difficult to do (interactively) in any other language. Of course, most programmers don't know what generic programming even is. However, a lot of libraries these days utilize it in order to get different precision and all of that, which is why I think Julia will at least become a language of libraries since not too many people can invest so much time in C++.