Motivation – Keli Language

Elm lacks typeclasses, yet I've found this lack is what keeps a lot of libraries at bay that would have otherwise turned out overly abstract (see any mainstream Haskell library, really). It's the same reasoning behind Go: With great power comes great responsibility. At large, programmers shoot their own feet with powerful languages. Therefore, take away their guns, ie make languages less powerful. I still wish there was something like Elm, but tailored for backend/network programming: https://news.ycombinator.com/item?id=21909087

> Keli is created to overcome a problem that is almost undeniable in every functional programming languages: the lack of proper IDE incorporation (perhaps except F#). In short, Keli can be viewed as an attempt to assimilate the Smalltalk's syntactic model into a functional programming environment.

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