4 ms·
I personally don’t think keli is fixing the right problems: I’m personally an ocaml user, and I don’t see what keli adds to ocaml. They cite positional parame
by nephanth 6y ago
I personally don’t think keli is fixing the right problems:
I’m personally an ocaml user, and I don’t see what keli adds to ocaml.
They cite positional parameters (that they call "prefix notation"… i wonder why ?) but ocaml already has support for named parameters (you can write things like
split ~on:"," "a, b, c"
for example)
Moreover, guessing the order of parameters is generally not that hard :
— If you have good intellisense your IDE will tell you which parameter is which (how they are called in doc)
— If you have good intellisense, your ide will tell you the type of function, which, with strict typing is sufficient in a lot of cases (think "send : Unix.socket -> string -> unit", the type tells you the order of arguments)
— with named parameters, you don’t have to look up the order of parameters… but you have to look up their names, same problem
— This last one is pretty subjective, but in a lot of cases you can guess the order of parameters by thinking "on which argument does it make sense to do partial application ?" `splitBy ","` makes sense, `splitBy "a, b, c"` doesn’t really… so "," is the first argument (but that is subjective)
For IDE support, with the right tools, in my experience it is pretty good (ocaml-lsp or merlin do the job pretty well, and strict typing often allow for better intellisense than on non-functional languages)
Though there we arrive at the real problem I’ve experienced : the tooling.
It’s not actually that bad. more like it’s badly explained.
how do you know that you are supposed to install
— opam for package management (and reinstall ocaml via opam)
— dune for building
— utop as a REPL, because the basic REPL sucks
— batteries or janestreet-core for "standard library" because the standard library sucks (and which one anyway ?)
Plus these tools are hard to use at beginning / have a learning curve. (why can’t creating a project be as simple as
- type "cargo new project"
-> now you automatically have a project dir with a local opam switch, an opam file, a dune file, an example program, and basic utilities installed in that switch ? )
Personally, I think that’s what fp lacks the most right now (though I’m probably influenced a lot by ocaml) : easy to use and flat-learning curve tooling
- marmaduke 6y agoThis is impressively compréhensive and covers everything I thought of while reading the post. I also agree that OCaml needs a one click to opam+dune+utop+batteries+Merlin+editor experience, but new tools like https://www.gitpod.io/ https://www.gitpod.io/ help since your project can just describe everything declaratively and spin up a working environment. I expect this sort of tooling will help with a lot of languages which are not really integrated by default
- ducaale 6y agoThere is https://github.com/avsm/opam-tools https://github.com/avsm/opam-tools which aims to simplify the process of setting up a local opam project with all the tooling required. On the topic of and janestreet-core/base and named parameters, I don't like how it basically forces you to name your arguments whenever you need to compose functions. I much prefer Containers library which is lighter and stdlib friendly. * Base/Core: List.range 0 20 |> List.map ~f:(fun x -> x * 2) |> (fun l -> List.take l 5) * Containers: List.range 0 20 |> List.map (fun x -> x * 2) |> List.take 5
- chalst 6y agoFor writing code with IDE support, your comments about named vs positional parameters are spot on. But when it comes to reading code, an IDE should not be assumed and there is no problem with looking up well-named parameters. For something Keli has that Ocaml doesn't: it is interesting to see a statically typed FP with multiple dispatch built in from the beginning.