10 ms·

What's the one-minute pitch for using this, over say Python or Julia? I couldn't figure this out from a quick skim.

asplake 7y ago
For me, as a Scipy/Flask/Postgres user it would be about completing the stack. Python’s great but for core things I’d love to have an ML-inspired alternative that’s even half as convenient. I watch this space with great interest.
- phrmoy 7y ago
  A great choice of companion language to your Python stack would be Nim: https://nim-lang.org/ https://nim-lang.org/ (not necessarily ML-inspired) but extremely productive and extremely fast. Bonus, v1.0 is right around the corner for Nim. If you're willing to venture out to a place with an evolving scientific ecosystem, Nim is a great choice to do scientific computing as part of a CPython stack (easy integration both ways since Nim compiles to both C/C++).
ernst_klim 7y ago
Static typing. I'm doing a image-related and ml-related research at the moment, and I'm a seasoned OCaml user. So I've tried python for a bit, it was such a pain so I've decided to stick with owl. Without static typing, the discoverability is so low so that you're literally feeling pain tinkering with python. REPL experience with static types is so much better. With numpy and scipy, I had to stick to documentation all the time even to do the most trivial things. What kinds of arguments could I pass to the plotting function? Read the docs. Does this work with dense or sparse matrix? Does it work with array? Read the docs. In OCaml you could derive most of the information from the type, for example a plotting api http://ocaml.xyz/apidoc/owl_plot.html http://ocaml.xyz/apidoc/owl_plot.html Much of this is simply obvious within a REPL session without looking at the doc. Simple calling a function name would show you its type.
- pjmlp 7y ago
  Although Julia is a dynamic language, the way it uses type inference and type annotations, you can also achieve a similar experience. Naturally OCaml benefits from almost 20 years existence.
  - seanmcdirmid 7y ago
    How does Julia’s dynamic typing augment discoverability? Does it magically tie into a code completion engine somehow?
    - pjmlp 7y ago
      JuliaPro IDE apparently has good completion, plus the language might be dynamic, but uses the same approach as Dylan regarding type inference, meaning although dynamic it infers possible types from context. Plus there are always type annotations as well.
    - o09rdk 7y ago
      My understanding/experience is that Julia has optional typing. Meaning it's dynamically typed, but supports type annotation that often improves performance and can be used to enforce types (I think). A lot of Julia code looks statically typed, but if you want to code "pure" dynamically (e.g., for prototyping or just because it's more convenient or better for whatever reason) in style you can. Type annotation is seen as increasing information for the compiler to use, and to increase clarity in specification, but not a necessity. This is different from other dynamic languages I'm familiar with where type specification and annotation isn't built in to the same extent, and different from static languages that require type specification all the time. To me, Julia's approach feels the best of the languages I've used. I've grown to like statically typed languages more over time, but there are some situations where it can create huge headaches (e.g., where the type structures of a library, etc. are poorly organized or unclear).
      - ddragon 7y ago
        Actually, type annotations in Julia do not improve performance (and in some pathological cases can even reduce performance). The Julia JIT compiler will always infer the type at compile-time regardless of annotation and will (almost) always produce the optimal code. The reason for type annotations are for the multiple dispatch (multimethods), documentation, to deliberately restrict the polymorphism of a function and for the rare times when the compiler will not be able to infer the best type.
alokrai 7y ago
The motivation section of the documentation covers this in detail [1]. From what I understand, the key points are: 1. The author claims that various libraries in Python (Scipy, Pandas, etc.) have a large amount of duplicated code and overlap, if you look deeply in the code. Having one library with a holistic design prevents this overlap and allows for easier optimisation. 2. He further claims that because "numerical computing is built atop of a small amount of abstract number types (e.g. real and complex), then derives a fat set of advanced numerical operations for various fields", unlike systems programming, holism, such as in OWL, is preferable to reductionism. [1]: http://ocaml.xyz/chapter/intro.html#motivation http://ocaml.xyz/chapter/intro.html#motivation
Cybiote 7y ago
I'm a fan of functional languages and believe their implementation choices induce a unique approach to problem solving. Not necessarily better but different, which is enough on its own to justify such projects. While I prefer the functional approach, I'm well aware that's a large part just personal preference. What's true however, is every language makes certain things easier and other things difficult as a result of what's prioritized. The locale of functional and typed languages is less visited and worth exploring.
deleted 7y ago
[deleted]
ryanrhymes 7y ago
A large part of benefits originate from OCaml language per se IMO. Owl inherits these advantages for free. E.g., taking advantage of various compiler backends so you can (almost) use the same code for both web backend and frontend if you are a full-stack developer. From numerical lib designers' perspective, a holistic design (note which does not necessarily mean a monolithic lib) leads to a more coherent and consistent design (e.g. APIs), which makes a large software system easier to optimise and maintain. As a young and experimental system, Owl seems doing a quite decent job so far IMO. However, from a (broad) users' perspective, being very honest, I never believe which one should replace which despite how much I love Owl myself. Each tool has own pros and cons deeply root in its internal design, depends on the language it uses, its design assumptions and goals. I think the choice of tools is really a matter of project requirements, coders' own skill, personal taste, management choice, as well as the context (i.e. what kind of apps you are going to build for whom and where). liang

For me, as a Scipy/Flask/Postgres user it would be about completing the stack. Python’s great but for core things I’d love to have an ML-inspired alternative that’s even half as convenient. I watch this space with great interest.

phrmoy 7y ago
A great choice of companion language to your Python stack would be Nim: https://nim-lang.org/ https://nim-lang.org/ (not necessarily ML-inspired) but extremely productive and extremely fast. Bonus, v1.0 is right around the corner for Nim. If you're willing to venture out to a place with an evolving scientific ecosystem, Nim is a great choice to do scientific computing as part of a CPython stack (easy integration both ways since Nim compiles to both C/C++).

ernst_klim 7y ago

Static typing. I'm doing a image-related and ml-related research at the moment, and I'm a seasoned OCaml user. So I've tried python for a bit, it was such a pain so I've decided to stick with owl. Without static typing, the discoverability is so low so that you're literally feeling pain tinkering with python. REPL experience with static types is so much better. With numpy and scipy, I had to stick to documentation all the time even to do the most trivial things. What kinds of arguments could I pass to the plotting function? Read the docs. Does this work with dense or sparse matrix? Does it work with array? Read the docs. In OCaml you could derive most of the information from the type, for example a plotting api http://ocaml.xyz/apidoc/owl_plot.html http://ocaml.xyz/apidoc/owl_plot.html Much of this is simply obvious within a REPL session without looking at the doc. Simple calling a function name would show you its type.

pjmlp 7y ago
Although Julia is a dynamic language, the way it uses type inference and type annotations, you can also achieve a similar experience. Naturally OCaml benefits from almost 20 years existence.
- seanmcdirmid 7y ago
  How does Julia’s dynamic typing augment discoverability? Does it magically tie into a code completion engine somehow?
  - pjmlp 7y ago
    JuliaPro IDE apparently has good completion, plus the language might be dynamic, but uses the same approach as Dylan regarding type inference, meaning although dynamic it infers possible types from context. Plus there are always type annotations as well.
  - o09rdk 7y ago
    My understanding/experience is that Julia has optional typing. Meaning it's dynamically typed, but supports type annotation that often improves performance and can be used to enforce types (I think). A lot of Julia code looks statically typed, but if you want to code "pure" dynamically (e.g., for prototyping or just because it's more convenient or better for whatever reason) in style you can. Type annotation is seen as increasing information for the compiler to use, and to increase clarity in specification, but not a necessity. This is different from other dynamic languages I'm familiar with where type specification and annotation isn't built in to the same extent, and different from static languages that require type specification all the time. To me, Julia's approach feels the best of the languages I've used. I've grown to like statically typed languages more over time, but there are some situations where it can create huge headaches (e.g., where the type structures of a library, etc. are poorly organized or unclear).
    - ddragon 7y ago
      Actually, type annotations in Julia do not improve performance (and in some pathological cases can even reduce performance). The Julia JIT compiler will always infer the type at compile-time regardless of annotation and will (almost) always produce the optimal code. The reason for type annotations are for the multiple dispatch (multimethods), documentation, to deliberately restrict the polymorphism of a function and for the rare times when the compiler will not be able to infer the best type.

alokrai 7y ago

The motivation section of the documentation covers this in detail [1]. From what I understand, the key points are: 1. The author claims that various libraries in Python (Scipy, Pandas, etc.) have a large amount of duplicated code and overlap, if you look deeply in the code. Having one library with a holistic design prevents this overlap and allows for easier optimisation. 2. He further claims that because "numerical computing is built atop of a small amount of abstract number types (e.g. real and complex), then derives a fat set of advanced numerical operations for various fields", unlike systems programming, holism, such as in OWL, is preferable to reductionism. [1]: http://ocaml.xyz/chapter/intro.html#motivation http://ocaml.xyz/chapter/intro.html#motivation

Cybiote 7y ago

I'm a fan of functional languages and believe their implementation choices induce a unique approach to problem solving. Not necessarily better but different, which is enough on its own to justify such projects. While I prefer the functional approach, I'm well aware that's a large part just personal preference. What's true however, is every language makes certain things easier and other things difficult as a result of what's prioritized. The locale of functional and typed languages is less visited and worth exploring.

deleted 7y ago

[deleted]

ryanrhymes 7y ago

A large part of benefits originate from OCaml language per se IMO. Owl inherits these advantages for free. E.g., taking advantage of various compiler backends so you can (almost) use the same code for both web backend and frontend if you are a full-stack developer. From numerical lib designers' perspective, a holistic design (note which does not necessarily mean a monolithic lib) leads to a more coherent and consistent design (e.g. APIs), which makes a large software system easier to optimise and maintain. As a young and experimental system, Owl seems doing a quite decent job so far IMO. However, from a (broad) users' perspective, being very honest, I never believe which one should replace which despite how much I love Owl myself. Each tool has own pros and cons deeply root in its internal design, depends on the language it uses, its design assumptions and goals. I think the choice of tools is really a matter of project requirements, coders' own skill, personal taste, management choice, as well as the context (i.e. what kind of apps you are going to build for whom and where). liang