3 ms·

> I don't really see a place for it where another language wouldn't be an equally good or better fit. Parsers/interpreters/compilers/static analyzers. It's sol

by Zababa 5y ago

> I don't really see a place for it where another language wouldn't be an equally good or better fit. Parsers/interpreters/compilers/static analyzers. It's solidly established here. The Web Assembly reference implementation is written in OCaml for example. > "why not just use go/node/racket/haskell/fsharp/rust/zig/etc" I think Python, Java, C# or even PHP will come up before F#, Rust, Zig, Racket and Haskell. As for the answer, you can just use the same language pretty much everywhere. I think OCaml is probably the most versatile language of the lot. You can program in any way you want, target pretty much anything you want. How important is it, to be able to use the same language everywhere? I honestly don't know. > when you are on a timeline and you aren't Jane Street... I'm not sure what you mean exactly with "on a timeline", I guess it's a reference to the lack of libraries/documentation? If that's the case, I don't know how much it matters once you're experienced with the language. I'm not saying libraries don't matter at all, that would be silly. You don't want to do JSON parsing or a HTTP server yourself. But for small stuff, you can just write a bit more code that you would usually do. It's going to be way smaller than a full library, and it's going to be easier to use since you don't have to learn a new library. This is however just me thinking about it, I don't have any hard data on this, and would love to know if some exists.

dmbaturin 5y ago
For soupault, library availability was actually a key factor: lambdasoup [1] is one of the best HTML parsing libraries if you want to automatically edit element trees, not just extract data from them. The single case when I couldn't find a library that would really suit my needs is a TOML parser. The only TOML library for OCaml that existed when I started soupault (To.ml) has incompatibilities with the TOML spec and I categorically disagree with its design. My solution was to write a new TOML library [2] for my own use and for the benefit of the community. It uses OCaml functors to allow the user to plug their own bignum and calendar libraries if needed and I think it's much easier to use. Well, the topological sort library [4] also counts (sort of): there are generic graph libraries that already implement sorting, I wanted it to produce user-friendly error messages about cycles or non-existing dependencies, and to take a simple assoc list rather than a custom graph type, so I also made my own. It's used for sorting "widgets" (page processing steps) according to dependency lists that users can specify in the config (like `after = ["foo", "bar"]`). Other than that, one thing I really like about OCaml is that the compiler team and most library maintainers are considerate towards downstream users with respect to compatibility. The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions. [1] https://github.com/aantron/lambdasoup https://github.com/aantron/lambdasoup [2] https://github.com/dmbaturin/otoml https://github.com/dmbaturin/otoml [3] https://github.com/lindig/lua-ml https://github.com/lindig/lua-ml [4] https://github.com/dmbaturin/ocaml-tsort https://github.com/dmbaturin/ocaml-tsort
- Zababa 5y ago
  Thank you for sharing that, that was interesting! > The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions. That's one of the other strengths of OCaml that I didn't mention, especially compared to more recent languages. The language has been around for a long time, and is probably going to be around for a long time.

by Zababa 5y ago

dmbaturin 5y ago

For soupault, library availability was actually a key factor: lambdasoup [1] is one of the best HTML parsing libraries if you want to automatically edit element trees, not just extract data from them. The single case when I couldn't find a library that would really suit my needs is a TOML parser. The only TOML library for OCaml that existed when I started soupault (To.ml) has incompatibilities with the TOML spec and I categorically disagree with its design. My solution was to write a new TOML library [2] for my own use and for the benefit of the community. It uses OCaml functors to allow the user to plug their own bignum and calendar libraries if needed and I think it's much easier to use. Well, the topological sort library [4] also counts (sort of): there are generic graph libraries that already implement sorting, I wanted it to produce user-friendly error messages about cycles or non-existing dependencies, and to take a simple assoc list rather than a custom graph type, so I also made my own. It's used for sorting "widgets" (page processing steps) according to dependency lists that users can specify in the config (like `after = ["foo", "bar"]`). Other than that, one thing I really like about OCaml is that the compiler team and most library maintainers are considerate towards downstream users with respect to compatibility. The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions. [1] https://github.com/aantron/lambdasoup https://github.com/aantron/lambdasoup [2] https://github.com/dmbaturin/otoml https://github.com/dmbaturin/otoml [3] https://github.com/lindig/lua-ml https://github.com/lindig/lua-ml [4] https://github.com/dmbaturin/ocaml-tsort https://github.com/dmbaturin/ocaml-tsort

Zababa 5y ago
Thank you for sharing that, that was interesting! > The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions. That's one of the other strengths of OCaml that I didn't mention, especially compared to more recent languages. The language has been around for a long time, and is probably going to be around for a long time.