My experience with Purescript so far
First off, the install and setup of the environment is straight forward. Pulp works like a charm! It is intuitive and it never went in my way. The incremental build is super fast on my machine so you can have a quick feedback on your test while you code with a simple
pulp --watch test.
The second thing purescript excels at is documentation browsing. If you look for the documentation of the
map function, just look up on pursuit. It’s a shame that the results are weidly ordered. I would have preferred to have the
Data.Functor (map) at the top, since it’s the most common. But this is only a detail, I’m sure maintainers are aware of these sort of things and are working towards a better browsing experience.
Another nice surprise is the Atom Ide. If you use Atom, it offers a nice ide that take care of autocomplete or source browsing. I need to restart the plugin from time to time to synchronise it with the current state of the build. Even with this minor problem, it’s impressive that such a young language has such a nice completion features. static types FTW!
Speaking of type system, Purescript is so pure that it won’t allow you to use partial functions without special treatments. This pushes you to a type driven development, which allowed me to learn a lot about the problems I was trying to solve.
Purescript does not come “batteries included”, you need to import every dependencies, even the
Purescript user experience
Let’s say you mistype the function
traversee. In Elixir, the compiler will warn you that there’s a more natural option: it will suggest methods in the context that look like your mistyping using the jaro distance. It’s a shame that the Purescript compiler does not do such things, even more because the type system would allow to suggest some very smart and elegant choices. No such explanation is given by purescript compiler.
As I mentioned earlier, forgetting to import Prelude at the start will award you some very weird messages like
(+) does not exist. I feel like it’s a pain for nothing for many reasons:
- I don’t see a case where a program won’t need to use operations like
- Even if they did not use
Prelude, the tree shaking would make sure their package is not impacted
- Finally, even if there would be a good reason not to import
Prelude, why not creating specific messages to help newcomers to follow steps to understand it.
Purescript leaves you alone in the jungle of its methods and functional gibberish. If you don’t know what a
Foldable or a
<$> is, you better learn the language with tutorial first! It feels like the language wasn’t build for programmers first, but for Haskell programmers with strong theorical background. Could you easily guess what’s the difference between a
Semi-groupoid and a
The most representative to me is the
purescript-assert library, when the assertion work, everything is fine. But once you get an error, here’s the result:
As you can see, there’s no comprehensible error message, not even the line of the error in the
.purs test file. If you have more than one assertion in your tests, which is quite the norm, you can’t know which assertion fails. Fortunately, other libraries allow to perform testing with better output. I deeply regret that basic libraries don’t go in a spirit of helping the programmers. As this tweet says:
Programming languages should help programmers becoming better
Purescript only provides half the tools for the statement to be true.
Purescript could change