…and stickers OCaml Stickers via 🐌 … going on!
3 Likes
There are alot of communalities. If you know one you know the other.
One small difference on syntax are:
-Ocaml uses keyword “in” and “;” operator , whereas F# uses indentation and spaces.
-F# uses <> around type types.
1 Like
ocaml has a nice binding to the tk library to make a gui.
F# has not.
F# history is perfectly captured in The Early History of F# and how it relates to ML family of languages. There are missing / added language features on both sides, I missed the module system the most in F#.
On the practical side, I found developing F# to be quite foreign as a life long Unix person. The libraries from .NET really expect you to know C# and the build/package tooling had a distinct Windows feel to it. We used VS Code or Visual Studio for development, it worked ok, the .NET devs I worked with really liked it and the IDE experience. My preference is for Emacs as an editor, which I did manage to get working but it wasn’t that well integrated (it could have improved via lsp-mode in the last few years). The practicalities of using .NET libraries meant you had a library for almost anything, if you were ok wrapping it in F#, often the libraries had C# documentation and APIs, which felt very non-FP. Null pointers and mutablity from C# caused us problems at various times. F# is a decent choice if you already know and use Windows/.NET.
3 Likes
I might oversimplify but you convert a null-pointer to an option type and back ?
completely subjective and quite frankly useless opinion from my time playing with F#:
F# tooling has MS smell to it, OCaml tooling feels more UNIX-y. Also less ceremony and whatnot to produce e.g. an executable from a single file.
I like that OCaml is insensitive to indentation.
F# feels more pragmatic, but less satisfying. OCaml gives me more power while feeling leaner to work with
I envy some strides F# made, but I don’t like the idea of replicating them. I like that OCaml adds features in principled ways.
OCaml feels more coherent, things interact with each other more nicely.
F# has even worse value restriction rules than SML, let alone OCaml.
Nothing Ever Beats OCaml’s Compilation Speed™
5 Likes
It’s notable that OCaml has the benefits you list while being a bigger language (feature-wise).
2 Likes
yes you should do this especially when working with Option.ofObj or .ofNullable.
Very basically yes, it gets more complicated with larger structures that might contain nulls. Think of it as a validation boundary within the overall system, things from C# get checked and transformed to be safe for F# to use. I think of it similar to validating json data into domain types.
After spending some time with F# , i find the (F#/C#) libraries&API’s much better documented then the corresponding Ocaml libraries. Eg explicit examples are given.
I think I agree with most of this, but I kind of miss the need to manually arrange source files in compilation order just because it serves as documentation for newcomers starting to learn a codebase (with the first file not being dependent on any after it). Maybe there is something similar that can be automatically generated in OCaml and manual documentation is an option too.
Do you actually arrange source files? I never had to do that except in the project file itself.
The only arrangement is like this example. Some IDEs like Visual Studio and plugins like Ionide for VS Code give an easier way to arrange it than typing XML.
1 Like