Sometimes this leads to a better standard as we saw with ES2015 when it adopted a variety of CoffeeScript inspired features. The cycle will likely repeat as we see more experimentation around the language.
I created the PureScript language and compiler a few years ago, and I continue to develop the language and its libraries. I write Haskell code for a living, and I'm interested in the problem of program correctness generally, so I tend to enjoy using statically typed functional programming languages where possible.
PureScript allows developers to identify errors at compile time, instead of at runtime, by using its expressive type system. At a simple level, this means no more
undefined is not a function or similar errors, but we can use the type system to validate more interesting things like
this function reads from (but does not write to) the filesystem.
One of the most popular tools is Pulp, which is a build (and general automation) tool for PureScript projects. Like many PureScript tools, Pulp is written in PureScript itself, and can be installed and run using NPM.
Another essential tool for PureScript development is Pursuit, which is our package database.
The three main features which distinguish PureScript from other similar transpilers are:
PureScript tries quite hard to assume as little as possible about your development workflow. The compiler itself ships with no libraries, although we do provide a comprehensive suite of core libraries which most larger projects will use. This means that users are free to build their own standard libraries if they like. With this approach, compiled PureScript code can be very small and fast.
Also, many things which would be implemented as language or compiler features in other programming languages are implemented in either external tools or PureScript libraries.
I think this sort of approach is essential if we want to continue to apply PureScript to projects of all sizes, from small single-module projects, to full-application development. If you choose to write a single application module in PureScript, you shouldn't have to pull in an array of tools or a large standard library of unrelated code.
Another important benefit of a minimalist approach is that it allows the community to try out several ideas at once. For example, PureScript isn't limited to only one approach to user interface development - instead, we have several libraries - all experimenting with novel applications of functional programming techniques to UI development.
In fact, pretty much every part of the PureScript library ecosystem can be replaced with some alternate implementation. That wouldn't be possible with a batteries-included compiler distribution.
A few years ago, I was writing TypeScript for a living, and for the most part I enjoyed it. Coming from a Java/C# background, the type system concepts were familiar. However, I had been reading about and practicing Haskell at the time, and the benefits of things like immutable data and the pure functional approach generally were becoming more obvious. So I knew I wanted a language which could enable pure, typed functional programming.
The Roy programming language was very close to what I wanted, but I had a few relatively minor concerns about that too, mostly around the treatment of side-effects in code.
So, these were all great options, but there was no language exactly like the one I wanted. I had some bits and pieces of code from my experiments with Haskell: parsers, simple type checkers, optimizer passes, these sorts of things. So I decided to put together a prototype of the language I wanted, and a few months later, I posted version 0.1 to Reddit.
It turned out that plenty of people were interested and wanted a language with similar features, so I quickly found contributors to help work on the project after that. Now, we have a great group of contributors working on the compiler and its libraries and tools.
In the short term, we have contributors actively working on different things - I'm working on some new type system enhancements, and others are working on a range of interesting things, such as pretty printing source code, new optimizer passes, new backends (Lua, Erlang, Python and C++ backends exist right now), and novel editor plugins.
PureScript has been adopted successfully and put into production at several companies now, and I'd like to see that trend continue. To make that possible, I'd like to work on lowering the barrier to adoption, so that PureScript becomes a more obvious choice of programming language for more people.
Other than that, I think the future for PureScript looks like more of the same - a group of contributors trying to build the programming language that they want to use. :)
Thanks for the interview Phil! Learning to use new languages is always a worthwhile idea. I've found it puts the ones you know well already into a perspective. You can try PureScript online. Phil has also written a free book, known as PureScript by Example, about the topic.