PureScript has type classes, and we use them to create very reusable code. Write less code by using a language which allows you to reuse more.
How many times have you written
traverse in a language without type classes? Entire NPM libraries exist just to implement
traverse once. All of these things can be accomplished with the same
- Waiting for a list of AJAX requests to complete
- Validating a list of form fields
- Ensuring a list of nullable values are all non-null
- Finding a list of values which maximizes the value of some function
If I change the word "list" in each of these examples for the word "stream" or "array" or "tree", I can continue to use
traverse, because all of these structures implement the same type class!
In languages without higher kinded polymorphism and type classes, you have to write
traverse once for each container/
Applicative pair - that's a lot of functions! Instead, just write
traverse once for each container and treat them uniformly using a type class.
Better abstractions also let you express more general ideas, and to talk about concepts abstractly.
Pursuit hosts documentation for hundreds of PureScript libraries, supporting all sorts of different types of development:
- Single page applications
- Web services
- Server-side rendering
- Database applications
- Mobile development
- Testing and benchmarking
- Graphics and audio
- Game development
- Data structures and algorithms
- Our data is even in the right format
- A value is never
- We handled exceptions in the right places
- We removed a piece of debugging code before deploying to production
- We handled all possible cases in a complex pattern match
- We didn't leak a reference to a mutable data structure
- We took the right steps to avoid possible SQL injection attacks
- Our application doesn't accidentally launch any missiles.
PureScript's type system provides a way to prevent all of these bugs, and many more.
In PureScript, we can express many common patterns such as mapping over and traversing the properties of a record, merging and zipping records and more, all in a type-safe way.
You can even abstract over the labels in a record. Never write another lens again, when you can derive a lens for any record property automatically using the type system.
PureScript supports instant rebuilds, so that you can see errors in your editor immediately. Editor plugins will even fix warnings and minimize imports for you.
Put types to work! Type-directed search will use type information to automatically find the programs which fit into the gaps in your code.
Let the compiler write your code for you. PureScript will derive instances of many common type classes. For those it doesn't support, you can often use generic deriving to fill in the implementation.
PureScript supports many of the development paradigms pioneered in Haskell. For example:
- Datatype-generic programming
- Type-level programming with functional dependencies
- Property-based testing
- Denotational design
PureScript is also a great language for implementing the latest techniques.
A Great Community
Find like-minded individuals on Slack, Reddit and IRC who are enthusiastic about bringing pure typed functional programming to the web browser.
"Sharing code is difficult"
This used to be true, but now there are great options like
Datatype-generic programming makes it very easy to derive most of the code you'll need for any shared types, including the most important one, JSON serialization.
"Strictness not a good default"
This is an interesting complaint. I use Haskell every day, and I make use of laziness extensively. There are great blog posts on the internet (for example) about the pitfalls of dropping laziness in a Haskell-like language.
I think it is a mistake to use PureScript as if it were a lazy language, just like it is a mistake to use Haskell as if it were strict (space leaks are a good example of this common mistake).
This means you cannot naively port Haskell code to PureScript and expect it to work. It might work, but be slow, or it might crash due to a loop, or just not even compile.
But we have great tools to support pure FP in a strict language, some new, and others inspired by techniques pioneered in other strict FP languages like Scala.
Ultimately, if you really want all the benefits of laziness-by-default, you should use GHCJS, but be aware that for many use cases, opt-in laziness in a strict-by-default language turns out to be a perfectly practical option.
"Hiring is hard"
The Haskell community has proven this to be false - hire remote PureScript developers (and be willing to train them if necessary) and you will have no shortage of qualified candidates.
"Training is hard"
Learning PureScript is not easy, but it is very possible. It can take a while.
Training others is another tricky problem, and it also takes time.
I'd recommend working through the Haskell book first if you are not familiar with Haskell or pure functional programming. Then work through the PureScript book and read through the documentation of the core libraries on Pursuit to get an idea of the way PureScript code works.
"Too much category theory"
You don't need to know category theory to be proficient in PureScript, although it certainly helps with some of the more esoteric core libraries. Learning category theory is a long term investment.
If you are interested in learning the basics, I would recommend working through the first chapters of one of the standard category theory texts, some of which are aimed at computer scientists.
"Not enough support"
At the end of the day, nobody is paid to work on the PureScript compiler. This might change one day, but for now, it is a mistake to expect long term support. I recommend treating PureScript like any other open source library.
That said, if you do need better support, that can probably be arranged in exchange for hard currency.
"Documentation is lacking"
We try our best to provide high-quality documentation, but it is a hard problem to communicate complex ideas clearly.
PRs are welcome! If you have ideas for how to improve documentation, please let us know, but please don't be upset if we tell you that we're not going to rename
"PureScript changes too quickly"
PureScript will continue to see breaking changes until we hit 1.0, but that milestone is getting closer. Things are stabilizing, and we don't expect many breaking changes between 0.12.0 and 1.0.
"I don't like Bower"
But you don't have to use Bower. Alternative package managers such as
psc-package and Purify already exist.
Some users use PureScript with Nix. Others use Git directly. PureScript assumes nothing about the package manager you use.
"I don't want to use Node"
psc-package and Purify in particular do not depend on Node.
For the REPL, you can use the
--port option to evaluate code in the browser, instead of using Node.