Comments (7)
I think that after moving Owl, it needs to be split up more cleanly into multiple packages. The python model is a good one to follow. We need a very easy to use numpy-equivalent that is top-notch. The current hierarchy still confuses people and dissuades them from using Owl_base. We then need an added library for linear algebra and numerical methods like scipy. And finally, we need a separate library for machine learning, with the understanding that the machine learning world is the fastest moving field nowadays and anything we do will be purely experimental. It's virtually impossible to keep up with the leading libraries in this domain.
from owl.
There is a section of documentation entitled Reductionism vs. Holism, which argues against the Python ecosystem of scientific libraries. Very much worth a read before considering any kind of changes.
from owl.
I apologize but I don't find these arguments too convincing. For one thing, it's very hard to make a strong argument when python is going strong and the Owl ecosystem barely took off. But there are other counter-arguments as well:
- An ecosystem consists of parts, and having one good part (like numpy) allows many other components to build on top of it. On the other hand, when everything is bound up together, it's much harder to connect to the lower-level component. You can observe this over and over again even in the OCaml ecosystem: Dream was adopted because it executes its job very well. Lwt as well. The Ocsigen framework, on the other hand, is a complete solution, much like Owl, and very few people use it or make components that connect to it.
- A new user wants the easiest possible path towards finding what he needs. Owl's experience is unfortunately quite the opposite of that. Most users want only numpy-level functionality to manipulate BigArrays, and I direct them to Owl_base exactly for this purpose, but inevitably they lose their way and are put off by the complexity and inability to find what they need.
- Breaking up libraries into components allows libraries to do what they do really well and specialize in that. Owl is a "little bit of everything", possibly not excelling in any one area. This means the developers' attention is spread out over a large surface area, and critical things slip through. For example, the API documentation for Owl is broken and has never been fixed.
from owl.
I agree wholly with the view of bluddy that modularity is king. Owl can still form a coherent family of type-compatible libraries, which invites other authors to connect. I could volunteer some time to work the docs of the numpy-equivalent sublibrary when it materializes.
Now that @jzstark has taken over maintenance, are there any plans for the future available? As I read the announcement, he still has limited time available which suggests that any refactoring efforts would have to be carried forward by others?
from owl.
I don't know enough about machine learning, but if it is moved to ocaml-community I'd be happy to help maintaining the linear algebra and numerical methods part.
from owl.
I agree as well. If we have enough freedom of operation, I'd be happy to join the effort of making it more modular and having a shared more uniform api across owl base and owl
from owl.
Thank you all so much for the constructive feedback! Modularity is indeed very important. Like I mentioned in the announcement, currently the plan is to keep the holistic design of owl and have good modularity within it, instead of making big structural change. If you have any idea about contribution, please feel free to make PR. Thx!
from owl.
Related Issues (20)
- How do I use gaussian_pdf in Owl.Arr? HOT 2
- The setter function for matrices in Owl_algodiff.D.Mat does not work HOT 2
- Cannot install owl-1.1 through opam because of `unmet availability conditions` HOT 2
- `libgfortran.so` not linked and causing compilation error HOT 8
- Cephes build warnings on Arch Linux
- Incorrect `Owl_const.min_float64` value? HOT 1
- Owl_dataframe shouldn' t use 'string_of_float' HOT 1
- Documentation is not in sync with current way plots are working
- OCaml cannot fins owl package HOT 1
- ssqr_diff' modifies inputs in place HOT 2
- Failure to load datasets for neural nets HOT 1
- Broken link to Algodiff module. HOT 2
- Exponential regression -- incorrect case HOT 1
- Test fails with GCC 13
- `Dataframe.to_cols` returns columns of incorrect size HOT 1
- OCaml 5.2 support HOT 2
- Reintroduce owl-plplot HOT 6
- Dead link to TODO list HOT 1
- Random.float bounds are inclusive, be careful with logarithms
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from owl.