Application-specific Improvements to the Ecosystem

[EmileTrotignon]

I have used the matplotlib bindings for a simple project and they were quite usable. They where also very incomplete, but it is very easy to add the missing stuff, it took me like 20 min to add the function I wanted, and this include the time needed to understand the way the codebase worked in the first place.

[n4323]

I just tried these, and they look promising. Is there a way to have a window open with graphics being displayed along a utop session? So far I was able to do savefig but no interactive work.

Update: Mpl.show () does show the plot in a window, but that has to be closed again for the utop session to continue.

[nico_toll]

@n4323

In an ideal world, most of the numerical / data science ecosystem around python would have bindings for OCaml, but that’s not going to happen – the next best thing really is painless python interoperability.

To emphasize what has been said earlier, I find the OCaml/Python bindings found in ppx_python and pyml to be extremely convenient. You can seamlessly derive python bindings from type definition both ways. I would be curious to see which kinds of improvements you’d like to have over this.

[n4323]

Indeed ppx_python looks pretty sweet. When I did some cursory testing around py.ml, I got the following setup working:

• Define an OCaml module containing some computational code
• Using py.ml define a Python module that contains python wrapper functions around the OCaml code
• Start a Python interpreter with Py.run.interactive and use the wrappers.
• Once the interpreter is started, there is no going back to the OCaml side.

What I would have liked in addition would be to have a way to have two interactive loops concurrently: One (utop) where I can inject new OCaml-side functions and new python wrapper definitions, and another (ipython) that calls the (current versions of the) wrappers. This would allow a nice iterative development cycle.
Maybe there is a reason why this cannot work? Or I missed something obvious? In any case I wasn’t able to achieve it.

[Chet_Murthy]

@jrfondren

This is slightly annoying as ocamlscript requires camlp4 requires ocaml <= 4.14.0, and my In_channels use requires 4.14.0, so you practically need a whole opam switch just for this one script.

I have never heard of ocamlscript. Is this something that would be useful to bring up-to-date? I’m sure updating it to use camlp5 should be straightforward, and I’d be happy to do that, if it would be useful.

[bluddy]

@n4323

I disagree with the notion put forward elsewhere that static typing makes OCaml unsuitable for exploratory numerical/data science work. Once a scientific program evolves over more than a week or so, being forced to structure the code sensibly by the type system already pays off IME.

I put forward the notion, and I left out the other part of it, which is that I agree with your statement here. Once code grows, it benefits from a strong type system. The core of data science, however, cannot benefit much from OCaml’s type system (unfortunately). There are also some design decisions in Owl which I think hurt the library’s usability somewhat in terms of data science.

[dbuenzli]

@bluddy

There are also some design decisions in Owl which I think hurt the library’s usability somewhat in terms of data science.

I never got to use it so I cannot judge, but I’m interested in that comment. Could you please elaborate ?

[kkirstein]

Personally, I often use the monadic Result type together with a polymorphic variant for the actual errors. This makes dealing with errors from different “levels” of my software (library, command-line tool, and GUI) quite comfortable (and type-safe!).
@keleshev has written a nice blog post on this: Composable Error Handling in OCaml with a recent follow up: Advanced Error Handling in OCaml

[dangdennis]

This is a great piece for beginners like myself. I’ve only ever done the variant error method, and it certainly isn’t as pretty as using polymorphic variants.

These are the type of writing I’d appreciate seeing more often surfaced on ocamlverse, the awesome-ocaml GitHub, or ocaml blog. I get that there’s a wide spectrum of ocaml users (apparently skewed more on experienced based on the active users here), but maybe a tag to categorize skill level can work to find the right audience.

[aij]

@Chet_Murthy

What’s missing is language support to make using those bindings as effortless as they are in Perl.

I don’t think OCaml should try to be Perl. Other languages seem to do just fine with no regex support other than bindings. Features like raw strings or even special regex syntax do make them much more ergonomic in some languages. Does ppx_regex count ?

Perhaps the Python comparisons would be better, if we don’t focus on OCaml’s lack of dynamic typing or support for monkey patching.

[fccm]

@Chet_Murthy

I have this crazy idea of starting a long-running post, wherein people would append examples of small programs they wrote in Python or Perl, and others could respond with OCaml versions. And we could discuss whether the OCaml versions were sufficiently easy-to-write, and if not, why not.

You can do that on www.rosettacode.org.
It’s also visible there that some tasks / algorythms fit better sometimes written with a functional style, and sometimes are better written with an imperative style.
You can propose new tasks, if it’s not already there.

[Chet_Murthy]

@aij

if we don’t focus on OCaml’s lack of dynamic typing

I would put it differently: “OCaml’s verbosity and apparent requirement for the programmer to know vast numbers of module-names”

Viewed that way, there are things that could be done.

–chet–

[spop]

Regarding Perl vs OCaml:
An (impressive) implementation of all the solutions of the Perl Cookbook
in the Objective CAML language (used at the time) is available here:
PLEAC-Objective CAML

Re-writing these examples with “modern” code/libraries could be very interesting.