02:54 - John A. De Goes Introduction

06:34 - Phil Freeman Introduction

07:38 - What is PureScript?

09:11 - Features

12:24 - Overcoming the Vocabulary Problem in Functional Programming

20:07 - Prerequisites to PureScript

26:14 - PureScript vs Elm

40:37 - Similar Languages to PureScript

44:07 - PureScript Background

47:48 - The WebAssembly Effect

51:01 - Readability

53:42 - PureScript Learning Resources 

55:43 - Working with Abstractions

On YouTube
189 JSJ PureScript with John A. De Goes and Phil Freeman

Picks

Philip Robects: What the heck is the event loop anyways? @ JS Conf EU 2014 (Aimee)
loupe (Aimee)
The Man in the High Castle (Jamison)
Nickolas Means: How to Crash an Airplane @ RubyConf 2015 (Jamison) 
Lambda Lounge Utah (Jamison)
Michael Trotter: Intro to PureScript @ Utah Haskell Meetup (Jamison)
Utah Elm Users (Jamison)
Screeps (Joe)
Most Likely to Succeed: Preparing Our Kids for the Innovation Era by Tony Wagner (Joe)
Dark Matter (Joe)
LambdaConf (John)
@lambda_conf (John)
ramda (John)
Proper beef, ale & mushroom pie (John)
Tidal (Phil)
purescript-flare (Phil)
The Forward JS Conference (Phil)

Special Guests: John A. De Goes and Phil Freeman.

 

Hello everybody and welcome to episode 189 of the Jabba Script Jabber… JavaScript Jabber Podcast, not Jabba Script Jabber Podcast. [Chuckles]

I was watching Star Wars last night. I think that was a Freudian slip on my part. [Chuckles] Today we have on our panel the amazing Jamison Dance.

Hello friends.

And the slightly more amazing Aimee Knight.

Hello [chuckles].

And I'm Joe Eames.

I'm Joe Eames. I'll be your host for today. And we have two very awesome and special guests. We have John De Goes.

Howdy.

And Phil Freeman.

Hello.

So, today we're going to be talking about PureScript with you guys. But before we get into that, I think it'd be a great idea to have each of you introduce yourself, a short background, and then your involvement with PureScript and why anybody would want to listen to you talk about it. So John, if you don't mind going first?

Yeah, sure. So, I've been writing software for a long time, actually closing in on three decades now. So, back since the early days of Commodore 64 and I've seen a lot of languages and written code in a lot of languages. Recently, the past probably 10 years or so I've done the whole entrepreneur thing and I've been starting companies and being the CTO at these companies. And one of the things that does is it sort of gives me the freedom to choose technologies.

And for my most recent company which is a startup called SlamData based in Boulder, Colorado, I actually was one of the poor guys to choose SlamData [chuckles] to build a production quality frontend application to do visual analytics on top of modern databases on. And that's where I learned about PureScript. That's how I got involved in the ecosystem. But I'm actually quite a connoisseur of niche languages, having chosen them at previous positions and dabbled in them and written little toy programs in a bunch of different languages. And I also consider myself an amateur programming language theorist wannabe.

Awesome. I love it. Before we move over to Phil, there are just a couple of things I really got to ask. First off, SlamData?

SlamData, yes. [Chuckles]

Awesome. Who came up with that name? Was that you?

You know, it was actually a really frustrated system administrator at a previous job who, in a fit of frustration with infrastructure and architecture and Amazon Web Service and all the crazy stuff that was going on to support this 24/7 cloud system, said, “You know what? We should have called our company SlamData.”

And I thought, “Well, you know that's actually not a bad name for a company.” So, I went onto GoDaddy and I registered it. And then years later when I decided to do this company, I had that URL sitting there. And it sort of made sense, because SlamData is visual analytics for JSON-like data. So, it's data that's not necessarily tabular. It's like XML, JSON, semi-structured data is what they call it. And analytics on that type of data, it is not easy. Sometimes you're literally slamming the data into the analytics engine to get some useful business answers out of that. So, the name fit even though it was sort of an accident that I had it at the time. It actually fits pretty well.

I think frustration is the most abundant resource in software development. So, if you can find a way to make money off of that, then…

Just rake it in. [Chuckles]

That's what we're going to do.

That's awesome. And also, 30 years, that's way cool. As a guy who's approaching 20 years myself…

Oh, my.

And who is generally surrounded by people who are approaching five years… [Chuckles]

I appreciate…

It seems like most of the people in the industry have just entered in the past five years or so.

That's right.

And that's especially true in…

Some of those people on this call right now.

[Laughs] It's especially true in frontend and open source, too.

Yeah, yeah. That is so true.

And I know they're all sitting around there thinking, “Oh my gosh. These old guys who are so out of touch.”

I know that that's what they're thinking.

Some of us [inaudible].

No, I really don't think that. I honestly do not think that. I am in awe of you guys. And I'm not just saying that.

I hear words that Joe says and I just think, “I can't wait 'til he's out of this industry [inaudible].”

[Laughs] Can't wait 'til he's not mucking us up anymore.

Joe [inaudible].

Alright.

We have a few things to add. Age and wisdom and all that stuff.

I agree with that.

Oh yeah, I appreciate it.

And complaints about whippersnappers that are on my lawn and playing their music too loud.

That's right.

Alright. Phil, how about you?

Oh yeah. So, I'm Phil. My nickname on [inaudible] Twitter and GitHub, you might know me as paf31. Not a very good name, but there you go. I've been doing programming in a bunch of languages for a while, so mostly things like Java and C#. And over the last I guess three or four years I've been ramping up, learning Haskell. It started as a hobby project and I've been doing it professionally a little bit for the last year or so. And yeah, I started, my involvement with PureScript is that I started the PureScript compiler originally a couple of years ago. I started it as a hobby project and then lots of people got involved. And now I still work on features in the compiler and I maintain a bunch of the, some standard libraries and things like that.

Awesome. And I'm guessing by your accent that you're from Texas?

Yeah, Manchester by way of, yeah… London and California.

Texas [inaudible]. Ah, cool. Manchester and London. Awesome. And which team do you support?

Manchester City. Yeah, [inaudible].

[Chuckles] Cool. Well, let's talk a little bit about PureScript. First off, I think it would be awesome if we just sort of talked about, had you guys give us an introduction to what is PureScript and why people that do JavaScript should care about it.

Sure. Phil, you want to take that one since you invented that language?

Yeah, I can answer that. So, I started working at my current company, DICOM Grid, a couple of years ago. And I inherited a medium-sized TypeScript application. So, I was working in TypeScript and for the most part I can recommend TypeScript. I pretty much enjoy it. If you come from a Java/C# background like I did and you like static types and all these kinds of things, then it can be very good. But I had exposure to Haskell and there were some things in Haskell that I wanted to see in TypeScript. So, just basic things like sum types, new types, just basic type system ideas that weren't available. I had bits of pieces of programming languages type things lying around on my machine. So, I started trying to assemble them into something that, the natural functional [inaudible] as a programming language.

And like I said, I got something working. And it turned out that quite a few people had the same… they wanted to work in the same way to compile to JavaScript. Maybe they'd come from something like TypeScript and they wanted a little bit more of the strong typing. Or maybe they came from Haskell and they wanted something that had the semantics of JavaScript. So, that's how it got started. And I think, hopefully people will find PureScript useful for the same reason that I created it and why I find it useful, which is that you want something fairly close to JavaScript like TypeScript is, [inaudible] the nice syntax and type that you get from Haskell.

So, can you talk about, you mentioned it a little bit. Can you talk more about the features that PureScript has as a language?

Sure. So, most of the interesting features are sort of taken, stolen from Haskell I guess. So, there's things like, I can go into more details on these, but there are interesting type system features like I said. Sum types, or you might know them as algebraic data types or tagged unions or something like that, depending on languages you've used. And then type classes, which are, look a little bit like, if you're familiar with [inaudible] Java, look a little bit like [n spaces] in Java. So, they enable this ad-hoc form of abstraction. And then there's a couple of more esoteric type system features. Things like what we call Rank N type, just basically different ways of enabling interesting types of abstraction that you might want to capture in a type system [inaudible], at compile type.

And then we also have one sort of unique I guess feature which is called extensible effects. So, extensible effects are a way of capturing in the type system things like the types of effects your programs can have, right? So, in pure functional programming we like to usually restrict ourselves to pure programs, programs that don't have side effects. But in the real world, you need to actually be able to deal with side effects. But then, so the goal should be to capture the difference between pure computations and computations with side effects, right? And extensible effects allows to do that in a really nice, composable way. So that we can say for example, to the compiler, this piece of code uses Ajax and it also writes to the developer console. But those are the only things it does. Please statically check that that is the case.

So, those are, yeah, that's like a very high level overview of some of the interesting features. John, can you think of anything else that I've missed?

Well, I think you hit on it before, but just parametric polymorphism and higher kinded types and type classes, type instances. Obviously the record support which maps really well to JavaScript. They're both a lot of really powerful features that help you write a correct software by construction, but also really, really good first-class inter-op with JavaScript. Like records in PureScript are records in JavaScript, for example. And you can actually call JavaScript functions from PureScript and vice versa, because there's no runtime layer between them. So, I don't know if that's a feature so much as an architectural choice. But that synergy that it has with the JavaScript ecosystem is important in its own right, just beyond all the type level and syntactical features that make it super easy to write powerful, correct software in the language.

Yeah. I mean, I would definitely call the JavaScript inter-op a feature. One of the main design goals when I first started the project was that I was coming from TypeScript. And one of the nice things about TypeScript is that you can just get a definition file and start working against a library or you can compile to JavaScript. And the JavaScript looks a lot like the source code that you put into the compiler. So, those are both properties that I wanted. So, there are lots of Haskell, well there's a few Haskell to JavaScript compilers. But what I wanted was more like, I feel like a better JavaScript [inaudible] TypeScript with really seamless inter-op with JavaScript. Not a Haskell for the JavaScript runtime, if that makes sense.

That does make sense. I have a couple of questions and then kind of a meta question. John, you rattled off a bunch terms when you were talking about some of the features of PureScript. And my impression is PureScript is aimed partially at JavaScript developers. And you said that, too. It's just JavaScript developers that maybe want some more guarantees about their code. How do you overcome the vocabulary problem that functional programming suffers from, where there are all these new words? And then the kind of type system, that some purely functional languages have, that adds a new vocabulary problem, like higher kinded types, right? Some people hear that and then their brain just turns off. Like, I don't know how that's going to help me write this feature for our customer.

Yeah.

Does that question make sense?

It does make sense. And I think the fact is in a lot of styles of functional programming, there's a lot of vocabulary that's foreign and strange. And it  can seem intimidating. And the reason for that is just some of these concepts are basically names for patterns that occur a lot in functional programming. Like when people say functor for example. What does functor mean? Functor is this weird-sounding thing that makes people want to plug their ears and go running and screaming in the opposite direction. But it's not because it's actually a hard thing to grasp. It's just a different thing. It's a different kind of thing. It's a certain type of pattern that occurs a lot in functional code.

And there's no really great name to describe what that pattern is. Like if you're familiar with the old Java book, Gang of Four, Design Patterns and Visitor Pattern and Singleton Pattern and all these other types of things, well 'Singleton Pattern' can sound a little scary, too. But when you see it and you see examples of it and you can see, “Oh, this is just a way of codifying a common pattern and laws around that pattern,” then it can become a lot less intimidating. And I think that as functional programming has become a bit more mainstream, there's been a lot more emphasis on writing more beginner-friendly material that takes away some of the jargon and shows people examples of what these things are to make them less scary. And I think we need more of that.

And I do want to say thought that these patterns whether they're patterns like functors and monoids and stuff like that or whether they are features of the language like higher kinded types, they exist for a very good reason. And that is there are a lot of people out there who want to be able to push as much work in verifying the correctness of the software to the compiler, and let it do the heavy lifting. I can tell you as someone who's been writing software for 30 years, everything from Assembly to BASIC, Pascal, and C, C++, on and on, basically every language you can imagine I've written software in, in that language, and it is really hard to reason about complex applications with lots of state.

And the reason for that is the way we program in languages like JavaScript is it's basically 'do x, and then do y, and then do z. and then do w, and so forth'. It's this list of instructions that gets fed to the CPU, more or less verbatim. It's a recipe for getting a given result. And when we try to understand what that program does, we basically have to go through all the steps that the CPU does. So, we have to simulate in our mind, “Okay we've got this variable here and we're going to update it. We're going to change it. We're going to increment by two but only if this other condition is met. And then we're going to clobber the whole thing with some new results.”

And this sort of reasoning about programs by simulating the state of the program in your mind, it works okay for small programs if you've been doing it for a while. You can actually understand probably a thousand lines of JavaScript and know exactly what it does. But as you start scaling the size of these programs and adding more members to the team and your program goes from 1,000 lines of JavaScript to 50,000 or 100,000 or 300,000 lines of JavaScript, our ability to simulate the operation of the program by updating all these registers in our brain as we're looking through the code, it falls down to zero. And we lose our ability to reason about these programs.

And tests help. Tests help a ton. But what a lot of people who have discovered functional programming have found, and specifically statically typed functional programming, is there are features of modern type systems that let you force the compiler to do the heavy lifting. And they dramatically simplify the way that you reason about software, like this thing which itself sounds pretty scary, algebraic reasoning, is just a fancy name for an algebraic equation, 'a equals b'. In functional programs, you can reason about a lot of software by saying, “Okay, this thing is actually defined to be equal to that. A is defined to be equal to B. So, any time I see an A in my code, I can actually replace it with B.” And I can understand the program in this compositional rote method of substitution. And that holds in functional programming.

And when you build software around that and take advantage of these scary sounding things like higher kinded types or row types and so on and so forth, you're actually able to push a lot of what you would have to do internally, sort of in a different way, up in your brain. Push it off onto the compiler and just focus about these little, tiny little functions that accept some value and they return some value. And if you give them the same value, they always return the same value. And you never need to think at more than the level of a single function. And you can work your way up from the low levels of your application where you have small functions.

And if you think, “Yeah, I look at that and I could see it's right,” then I can sort of build upon that and look at the functions that are built using those. And I can verify that and say, “Oh yeah, that looks right to me.” And then so on and so forth. My reasoning becomes composable. And I'm able to, with the help of the compiler, verifying all the types and that I'm not making any typos and that I'm doing things in the correct way, I'm able to have a great degree of confidence before I even run the software that it's actually going to do what's intended.

Actually, a developer who works at my company, at SlamData, the other day he told me about PureScript Halogen which is one of the libraries in the PureScript ecosystem for building frontend web applications. He told me if the thing compiles, it works. [Chuckles] It's maybe not always easy to get it to compile. But if it actually does compile, it works. And that's a pretty large sort of testament to the power of static types and functional programming and even PureScript, because for those of us who've done a lot of JavaScript single-webpage applications, there's an awful lot of debugging that goes on. And you may be able to write a hundred lines of code and have that work right off the bat. But anything beyond that, all bets are off. It's a lot of time with the web inspector and printing out and alerting or logging to the console various expressions to figure out what's going wrong.

And with tools like PureScript, we have a better way. It doesn't totally eliminate the need for thinking about things deeply, but it simplifies it and lets you think about things in small, more digestible chunks, and push some of that heavy duty reasoning off into the compiler where machines really excel at that type of stuff.

I kind of had two questions based on Jamison's question, which I really liked. As someone who is newer to this, do you feel like there are certain prerequisites that someone should have before they start looking at it? And then second, because we've talked about Elm on the show before, I know you just talked about TypeScript, but how is PureScript different from Elm?

So, I'm happy to speak to both and then maybe Phil can chime in. On the first one, I think what I've seen is that one of two things will help you if you're coming to PureScript and that is either A, you know the JavaScript ecosystem well, so you know what tools like Bower are and npm and you know CSS, your way around CSS and HTML and all these other things. Or, for those of you who don't have that background, then coming into it with a knowledge of functional programming, whether it's Clojure or even in JavaScript, Ramda or one of the other libraries out there, or Haskell or OCaml, something like that, it can really help a lot.

It could be a bit overwhelming I think to people who are new to functional programming and new to frontend programming and the whole JavaScript ecosystem to tackle a language like PureScript. Because everything from how you build it to deploy it to how you do useful stuff is contained inside the whole JavaScript domain knowledge. And then how you write your programs, how you structure them, what these terms mean, that derives from functional programming. And if you don't have either, then it's going to be a long uphill battle.

[Inaudible] I guess my question was not someone who's totally new to programming but someone who has done JavaScript because, you can do some functional programming just in JavaScript itself. So, are there certain, just like functional programming concepts or starting with something before PureScript, or do you think it's okay to jump right into PureScript if you haven't done functional programming before but you've done regular, you're familiar with the JavaScript ecosystem already?

I think a lot of JavaScript developers already know a lot of the building blocks of functional programming. Things like, John you mentioned Ramda which I must admit I'm not that familiar with, but I've used Underscore and I think a lot of people use Underscore, right? And Underscore emphasizes things like maps and folds and reduces and these kinds of things. And they really are the building blocks, right? Like putting functions together, higher order functions, and assembling programs this way. And to a certain extent, after that everything else is, there are various techniques and whatnot, but everything else is building up abstractions and things on top of that.

So, absolutely. I think people should try and come to PureScript that way. As you build these abstractions, a good type system really helps a lot, I think. Because you can, you start assembling these pieces and as John mentioned, you want this local reasoning property where it's easy to reason about on map or one fold or a handful. But then as you start assembling this into a large program, you don't want to have to keep all that structure in your head, right? So, that's where I think something like PureScript comes in handy.

Can I offer another perspective on that question, Aimee?

Yeah, sure. [Chuckles]

So, well I guess it's different from the question you actually asked, which is like, if I know JavaScript what do I do to prepare myself to get into PureScript? But I think in some ways it can be easier to learn functional programming if you are still learning programming. I know for me I came to functional programming after I felt pretty comfortable doing I guess imperative programming. And I

was used to feeling like I knew what was going on and I understood everything. And I'd kind of forgotten the feeling of hearing a concept and not really understanding it well and not seeing what it was used for. And so, it took me a little bit of effort to get used to being confused again, I guess.

So, I think if you're learning programming for the first time, just programming in general, you're used to working to understand things and I had gotten lazy. So, I think it could almost be easier to learn functional programming if you're starting off at the beginning of your journey or career or whatever, because you're used to having to work to understand stuff. And there are all these new concepts that are new no matter what… or they're new if you've been programming for a while and doing imperative programming, or they're new if you haven't been programming at all. They're the same amount of newness. So, it's helpful to just chill out and say it's okay if I don't understand stuff.

I'm going to work to understand it.

I think that's the most important thing, is just having that attitude of saying, “Yeah, I don't understand this but I'm not going to be afraid.” And I can speak, again as someone who's been programming for a long time, the well is so enormously deep that I'm never going to know even a tiny fraction of all there is to know about computer programming. And in order to have skills that stay current, you just need to sort of give up the idea that you're ever going to be a master of programming. There's always going to be this continuous process of learning. And the only way that can happen is if we let go of some of that fear of not knowing and of being confused and really dedicate ourselves to working through it. It's okay to be confused. It's okay to not know what this means. Sometimes we just need to roll up our sleeves and dig in and have faith and confidence that we'll come out the other side. And in fact, we do in most cases come out the other side having leveled up as a software engineer.

Yeah, I think it's pretty interesting that recently, I think there's been even a greater focus on functional programming in JavaScript.

Yeah.

And so, seeing that hopefully makes people more interested in concepts like this. But there's also plenty of talk about the fact that, hey, if you go and learn a new paradigm like functional, it'll level up your programming. And it's a very widespread thought. And it is really cool, even when you have been doing something for a long time, to go in and do something new. We like that generally, which is a reason why a lot of people get into programming. And it's great. I think it's actually enjoyable to be in situation where I feel very lost and trying to learn something new. And I've had 20 years of it and it never stops.

Yeah.

So, part of me asking that question too, because I was curious about how it related to Elm, when we did the Elm episode and I looked around at Elm a little bit and I've still looked around even after we had the episode, and it's been very approachable for someone who's newer. So, that was part of why I had asked that question and was curious how you felt PureScript related to Elm.

So, I think originally the way I thought of this a couple of years ago when PureScript was first starting, I was using PureScript for work, obviously. I built it because I was using TypeScript and I wanted to do Haskell-y things in my compile to JavaScript language. So, I evaluated a bunch of different Haskell to JavaScript [inaudible] like languages. And Elm was one of them. And at the time I think Elm had a bit of, Elm was focused on things like UI development. And it had a runtime. And those were two features that excluded Elm for me. I wanted literally zero runtime. I wanted to build something just from foundations with no runtime whatsoever. And I wanted a general purpose language as well, right?

Can you talk about the no runtime thing and why that was important to you? It's interesting to me.

Sure. So, the sort of libraries that I was actually interested in writing initially, I mentioned maps and folds, right? That was my initial use case. I didn't envision a language that had Rank N types and type classes and all these things and writing general purpose applications. My original vision for PureScript was writing small [combinator] libraries and small data structure libraries and then dropping them into a larger TypeScript application. And having a runtime however small sitting in there when all I want is some data structure and functions on those data structures is unnecessary, right? So, at the time, that was the reason why I chose to work on PureScript instead of choosing Elm.

But now I think that the gap has closed somewhat. PureScript has nice UI libraries, some of which are influenced by Elm in fact. And Elm has become more general purpose at the same time. So, Elm has ways of dealing with side effects in the real world. So, I think the feature sets of the languages have gotten closer over time. And I think the difference now is more of sort of the philosophical one. It's like we both have approximately the same goal of, how do we bring pure functional programming to the JavaScript community? But the difference is how you do that and what's the best way to grow that language and its community, and how should such a language, how should it look and how should it work? And these sorts of things.

So, correct me if I'm wrong, but for example could you use PureScript to compile out JavaScript that you would run on Node rather than in the browser?

Yeah, exactly. So…

But you can't do that with Elm.

I think now there are some projects where Elm is running on Node. Elm is becoming more general purpose. I've seen it running on Node and I think I saw somebody who was working out of React Native recently. Same sort of things with PureScript, [same sort of] targets. Amazon, [inaudible], all these different types of targets. So, the difference now is more philosophical and more [one of] approach and how do you solve the problem rather than what the problem is.

The other thing that, you mentioned two things, differences or things that maybe, I don't know if turned you off is the right word, but one is general purpose and the other one was Elm was… or you also said that Elm was very UI-focused. Could you talk a little bit just about that? Like, I think, I guess this is just the other side of the coin, right? PureScript being very general purpose where Elm was really meant for UIs. So, PureScript doesn't… does PureScript, would you find it to be as suitable for writing UIs as you find Elm to be? And…

PureScript definitely has UI libraries. And you can choose to write rich UIs. SlamData as John was saying, its entire frontend is written in PureScript, right? I think the problem is like a general problem in a lot of domains. When you design a programming language, you have to make this trade-off between expressiveness and tooling I guess. So, if you had picked Elm at the time I was picking, choosing to work on PureScript, you might have chosen Elm. And Elm comes with best in [class] tooling because it is a language that was designed with UIs as a… its principal focus was UIs. So, it had great tooling. Or you might have picked PureScript and you buy yourself more general purpose language features. But because those ideas aren't core and built into the language, you lose some of the tooling. So, you have this trade-off of something like how much expressiveness do you have and how much generality versus what analysis and tooling can I buy myself?

And would you consider PureScript to be a functional reactive programming language?

No. I mean, you can certainly write reactive applications in PureScript but I wouldn't call it a reactive programming language. Definitely a pure functional language.

You also said earlier that one of the things that you wanted was, I can't remember exactly how you said it, but easy integration with JavaScript. So for example, if I had a jQuery plugin that I really wanted to use with my PureScript app, would I need to rewrite that? Or wrap it? Or does it plug in really easy?

So for most things, you can actually just, you can take existing JavaScript functions and data types and declare them as available to your PureScript program. So, in the case of types you just say, “This is a type.” You don't really talk types in JavaScript, but there's a type. You know, jQuery select is written as a type of jQuery event. So, you declare those types. And then you can give types to your functions as well. So, things like actually running, it's something like query selector. You can give that a type involving those ones you've just created.

There is a, there's some boilerplate that in some cases the types don't exactly match. So, there are some restrictions on the way PureScript uses JavaScript functions for example. So, in a lot of cases you have to do some wrapping in order to get it into the right shape. But it's entirely sort of boilerplate and you do it once. And it's a relatively small amount of code. And then you can just use that code, like jQuery plugins for example. You can use it from your PureScript code. And there's efforts going on as well to convert things like, the various IDLs for things like the DOM and WebGL to reduce the boilerplate code so that you don't have to write that by hand. You can actually just code generate that.

Okay.

John, I know you wanted to jump in and talk about your perspective on choosing PureScript over Elm.

Yeah, that's right. So, I actually looked at Elm and PureScript at the same time. And I was interested in UE development. That's in fact the only thing I was interested for. We had already settled on Scala for the backend. And so, we just needed that frontend piece which would be a single-page application, rich internet application, whatever you want to call it, that offers all the features of a desktop application. And pretty UE intense, too, not just simple forms and whatnot, but SlamData is a visual analytics application that lets you explore data and refine it and search it and create visualizations on it. So really, a hefty duty UE use case if ever there were one. And I looked at Elm. I looked at PureScript. I looked at TypeScript. I looked at lots of the alt JS languages.

And in the end, it actually did come down to Elm versus PureScript for me, because both of them were very clearly oriented around the functional programming paradigm. And some of the other ones were a mix and mash, like TypeScript. You can do functional programming in it but you can do JavaScript style imperative programming. You can do anything you want in the language. And I was looking for something that specifically made that very opinionated choice to say, “Okay, we're going to do this in a functional programming way.” And so, it came down to Elm versus PureScript. And here were the things that I noticed.

First off, like Phil says, PureScript is a much more powerful language, even though the gaps have closed somewhat. To this day, there's no way to express the concept of a generic container of things like a list of integers for example. There's no way to abstract over that in Elm. And there are lots of other examples where there's something that I'm familiar with, there's something that I'm used to, like abstracting over containers of objects of some type of value that I just was very reluctant to live without that power. Once you've tasted that power and you've seen how, “Oh, the compiler can actually make sure you don't put a string in a list of integers and stuff like that,” all those benefits that come from those types of abstractions, it's hard to go back on that and program in a simpler way. So for me, that was one key observation, is that PureScript was a much more powerful language and still is to this day.

The other thing is Elm was substantially easier to use and more tailored around the use case of UE development and that was super attractive to me. So, on the one end I had Elm saying, “Yes, we do UEs really well,” and I had PureScript saying, “Well, we can help you write code that is correct by construction and it can verify all these wonderful things about your software and lets you model things much more precisely than you can in Elm.” And it was a real trade-off.

But really, what ended up deciding it for me is that Elm makes the very opinionated choices to say functional reactive programming in this particular variant. There are lots of different styles of FRP. And Elm makes the decision that a particular variation of FRP is the correct choice for building UEs. And I totally understand why they do that. And it's not a bad choice. It gets people up to speed really fast. But at the end of the day, having worked in FRP libraries and written FRP libraries and having just spent more time than I wish developing UEs, I wasn't entirely convinced that that particular choice was the only choice or the best choice for the type of application that I was developing.

And so in a sense, Elm's ease of use and its very opinionated choice of how you should build a UE, it pushed me away. Because even though I don't like it when languages refuse to take stands on core features and they let you express the same concept in a hundred different ways, I like opinionated languages, I don't like it when a language takes a particular thing like a promise for example, or a particular variant of FRP, and says, “This is the way that we're going to do it in that language.” I like languages to be separated from libraries. And Elm blurs that distinction a bit, because it basically chose an FRP library and baked it into the language.

And as a result, we spent a lot more time early on in building our application, just trying to figure out what the UE side of things was going to look like. And we ended up with something that's not FRP, but that it fits our use case really very well. It's much more similar to React, which is not FRP. It's inspired by FRP but it's actually quite different. And it's working really well for us. And if I had chosen Elm even though there would have been a shorter ramp up curve because it provides all this stuff out of the box, we would have been stuck on their particular choices for all time, pretty much.

So, the reason I chose PureScript is because it is a general purpose programming language that's very powerful. And it doesn't have an opinion on the best way to build a UE. And I actually like that, because I've been building UEs for a long time. And I don't need any, I don't feel like I need extra help. I'm happy to choose a library that does it in the particular way I want to do it for a particular project.

So, correct me if I'm wrong here, but you're referring to the Elm architectural when you're talking about that, the particular way of building UEs?

Yes, as well as signals and channels.

Ah, okay.

I just want to point out that the shared delusion of calling UIs UEs has now spread to Joe.

Yeah. [Laughter]

I'm like, [reflecting] the way you call it. [Laughs]

I'm channeling you.

Yeah. That's what you mean when you… do you mean user interfaces when you say UEs?

[Laughs] You know what I mean.

Well no, I just want to make sure. [Laughter]

I'll call them GUIs. GUIs. I like that word better.

Yeah, GUI is okay. But UE apparently…

[Inaudible]. The first time I ever said if-e at work, I was the only one who knew what that meant.

Oh, really? That's funny. So, one other follow-up question, just for clarification. I know Elm a little bit. You were talking about containers, generic containers, right? And you said something to the effect of iterating over a list of integers. So, could you be, go a little bit more in-depth with that. Like my understanding of course here is that Elm, if you have a list of something, it's a typed list. You can't have a list that has an integer and a string next to each other.

So, that's right. But let's say we want to abstract one layer beyond that and say, well we don't want to force our code to only work with lists because it should be able to work with options that contain zero or one, or it should be able to work with tree-like things. It should even be able to work with things that represent effects in our program.

So, let's say we take that list of A's and we try to generalize it. Well, if you generalize that with respect to the operation of changing the value, so if you want to go from a list of strings and map that into a list of integers by parsing each string as an integer, so you want to do that mapping operation, when you try to generalize that mapping operation across any possible container, not just a list, you end up with this thing that is called a functor. A big scary name, but all it really means is you have a container of things that you can change the values. You can pass a function in and map over the internal structure of that container to change the contents of the container by modifying each value. And you can't express that abstraction called a functor or basically any of the other classic FP machinery. There's no way to express that because you need a higher kind of type there. And Elm doesn't support them.

Gotcha. One other thing that I thought as a follow-up question here is, we've talked a lot about Elm and PureScript. Are there other languages or similar technologies that you would put into the same realm? Obviously Elm and PureScript exist in a similar vein. So, is there anything else that we haven't talked about that's in this same realm?

I think there's sort of two classes of things that are relevant here, [inaudible] sort of Haskell to JavaScript things, because PureScript has a Haskell flavor. And then there's the typed better JavaScript, if you like, right? You actually have semantics of JavaScript like PureScript but adding features. And I would put Elm and PureScript, well, that's debatable, but I would put them in the better JavaScript's [class] group, right? Like, building on top of JavaScript. And in that category you've got things like, there's a language called Roy, which is by Brian McKenna, very similar to PureScript actually. Implemented in JavaScript, slightly different feature set, but pretty close. And then things like TypeScript. And then untyped things like CoffeeScript also, [inaudible].

But then on the other side you have the family of languages that are trying to take the entirety of Haskell or some subset of Haskell but with its semantics and bring that and compile it into JavaScript to run on the JavaScript runtime. So, those are things like Fay, Haste, and GHCJS. And they're very powerful if you want to do, you want to take arbitrary Haskell code that you might have running on the server for example and compile it then to JavaScript and have the exact same behavior in the browser. But again, you have these trade-offs. And the trade-off here is you lose readable code and maybe you lose nice inter-op with the JavaScript libraries and that kind of thing, right? So yeah, I think those are the two categories that I've considered anyway. John, [did I miss any]?

No, I do think that the one category is sort of a better JavaScript like TypeScript and whatnot. And then the other category is like, “Well, screw JavaScript. We just want a functional programming language that we can use in the browser.” And that's the category that Elm and PureScript fall into, as well as Roy and Fay and Haste, GHCJS. But I do think that in that bucket of functional programming languages that happen to or were designed to compile to JavaScript, you hit all the major players. And actually, in my mind, the two realistic choices are in fact Elm and PureScript. There are companies building production applications in both of them. They've got great communities. They're just really great projects. I don't think you can go wrong choosing either one of those if you want to do FP in the browser.

What about ClojureScript?

So that, [chuckles] I guess that falls into yet another category of dynamically typed functional programming. And I forget that exists from time to time because I've been statically typed for so long. But there is that category of dynamically typed functional programming in the browser projects. And ClojureScript, I've seen some presentations on it. It looks great. Some of the projects out there like Ohm look like they're very, very powerful. But that seems to be, it seems like it doesn't really overlap a lot with a lot of these other projects. That is, the people choosing that are doing so because they're using Clojure on the backend and they want to use the same language on the frontend so they end up with that as the default choice. It's almost more similar to the Scala.js for Scala, which people will choose as the default for their frontend development merely because they happen to know Scala. It doesn't really escape those niches.

Alright. Jamison, did you have a question?

I do. It's more about the background and history of PureScript. So, you said you were trying to choose between using Elm or writing your own compiler for a language. And that to me is like, so far out of a thing I would consider practically [chuckles] possible. Like, I can understand choosing between tools. But it's like, can I use this thing that's already there or should I invent my own compiler to do things? What is your background that led you to consider that as a thing that seemed practical? [Chuckles] Does that make sense?

Yeah, definitely.

Are you a genius? That's what I'm trying to ask.

[Chuckles] No, I'm definitely not like a PLT, a programming language theory educated person. You tend to pick up things like, you get exposure to things like parsing technologies in Haskell and type checking, type libraries, when you work in a language like Haskell. These are good applications for Haskell so you tend to see a lot of them. So, when you're immersed in the Haskell ecosystem, you tend to learn some of these ideas. It wasn't a frivolous decision, “Oh I'll just write a programming language to solve this problem I had.” I spent a very long time analyzing all the different alternatives. I mentioned all these, the GHCJS's and Haste and Fay on the Haskell side, and Roy and TypeScript and all these other languages, Elm included.

And I had some constraints. Like I said, the no runtime thing I wanted. I wanted a language with no runtime and something that was general purpose and all these constraints. And none of them… I would say Roy was actually the closest at the time to the language that I wanted. And I had some minor complaints about Roy's [inaudible] at the time. And I think it's changed since. But Roy was a really interesting project. And yeah, I was very close to using Roy.

So, I actually started out in parallel using TypeScript and developing PureScript on the side. And PureScript got to the point where I could write very small, the small combinator libraries and data structure libraries that I wanted. And the [inaudible] was simple enough and the code gen was simple enough that I could actually take the generated code and drop it in and use it alongside the TypeScript code. So, I worked that way for quite a long time.

So, it sounds like you had enough concerns with the existing technologies out there and you felt like you had picked up enough. Was it a daunting task to you to create your own language or did you feel like you could just fiddle with it enough to get something working that you liked and it grew organically?

So, I think it's relatively simple. I'm not going to say simple. But it's relatively simple to get a compiler that does something useful quite quickly, and especially say if you… in the Haskell ecosystem and you've seen things like parsec for parsing and examples of things like type checkers are fairly easy to come by. So, you learn these techniques. And I had bits and pieces of things like this sitting around. And things like code generation are relatively simple as well. And those are the main three components of the initial version of PureScript. So, I put something together.

And I posted the thing that I made on reddit, on reddit Haskell. And as I say, people started saying things like, “Well, you know I've got some critiques,” and people wondered why I did things a certain way. But a lot of people had said things like, “Oh, I was looking for a programming language like this or a way to compile to JavaScript like this.” And then from then it mostly, the community grew quickly and lots of people started contributing to the compiler.

And the goals shifted somewhat. But the initial goal of having this clean code gen and good interop with JavaScript has always been there. Yeah, we just added more interesting features as time's gone on. But yeah, I think bootstrapping something, I had the benefit of working in TypeScript and having this nice [inaudible] to drop myself build-outs into my TypeScript project and bootstrap the project that way. And I think that worked quite nicely.

So, what do you think the effect of WebAssembly is going to have on languages like PureScript?

Well personally, I'm not sure that it's going to have a huge effect. This is just my opinion which may be totally wrong. But WebAssembly, it requires you implement your own custom garbage collector among other things. So, you basically have to solve a whole host of problems that right now language designers like the people behind Elm and PureScript and so on and so forth don't have to solve. So, I think it's actually going to be more work to support those types of low level, assembly level technologies. Potentially, maybe, performance could improve if your compiler technology was really, really good. But it seems like it would take a certain amount of time before that technology is developed and matures to a point where it can be competitive with all this fancy optimizations that your browser is doing in JavaScript anyway.

And especially for a language like PureScript which in general, with one or two exceptions like [creating] functions and whatnot, the semantics map rather naturally and performantly to JavaScript, I don't see a huge benefit there. Certainly not in the short term. And I think it's just going to make the prospect of creating an alt JS language so daunting that many people don't even target WebAssembly. They just target ordinary JavaScript. But I could be wrong with that. Phil?

Can we get a definition of WebAssembly first? I don't think we've actually had a show about it.

Well, it's basically a lower level assembly language that you can build programs on top of.

It's like a target specifically for compile to JS languages basically, right?

Yeah.

I think emscripten is the main user right now. Is that right?

I have no idea. I actually don't know that much about it.

My understanding is that it's like, it's well suited to… so, I'm not an expert on this at all but I think it's better suited to things like compiling from C, C++ or maybe LLVM backend or something like that. So, in that sense, PureScript really leans heavily on the fact that JavaScript is in fact functional language, right? And you have first-class functions and scoping is the right sort of scoping. So I think, I don't really know enough details to say with certainty, but I think it would be very, very hard, very difficult to target WebAssembly by comparison.

Yeah, [inaudible] I'm not excited for that and I don't think it's going to revolutionize the alt JS ecosystem. I think very few compiler writers will choose to do that. I think, like others have said, it's probably a better fit for running C and C++ or Assembly language or low level languages. Because all these people are translating these binaries and other types of programs into JavaScript. And if they're old enough, like 15 years old, it actually runs quite performantly, surprisingly. And I think it will be a better fit for those sorts of applications than very high level functional programming languages.

So, there's a thing we kind of mentioned tangentially but we haven't talked about directly, which is my impression is that PureScript, the compiled JavaScript that PureScript generates is pretty readable. Is that an explicit design goal or did it just happen?

Yeah, so one of the nicest properties of TypeScript for me is the fact that it can take the compiled code. Obviously I write TypeScript quite a lot and I read and write TypeScript, but I have the option of taking the compiled JavaScript and handing that off to a JavaScript developer if I really want to and if they don't want to deal with the TypeScript tool chain or anything like that. And it's very readable. The source to compiled JavaScript translation is very shallow. It's really obvious what's going on. And that's a great property to have.

So, PureScript tries to do the same thing. But there's abstractions in PureScript where that doesn't always work. So, especially when you're using things like type classes, you end up having to maybe make up names for variables that you wouldn't write in the source code for example. And then you have some sort of, you have things that end up looking a lot like machine-generated code when you have type class heavy PureScript for example. When you use the fragmented PureScript that doesn't have type classes, it shares that property with TypeScript. It's very sort of shallow code transformation to the [inaudible] JavaScript, which I think is pretty useful. I'd be probably more reluctant to hand off compiled PureScript code to a JavaScript team as [build artifact] than I would be with TypeScript. But it's definitely possible. And it's an order of magnitude easier than it is with some languages where you're trying to preserve source language semantics for example.

Sure. That's another one of the benefits of not including a runtime, right? With Elm you end up…

Exactly.

With this compiled file that includes several thousand lines of just Elm stuff that isn't your code. It's just stuff needed to run Elm. That's cool.

Yeah. And practically speaking, with PureScript we have a standard library and a set of core libraries that you would in most projects probably end up including. So, that's going to be several thousand lines of JavaScript, too. But for the project like the ones I described I was initially working on were, you really have zero dependencies and you're just building your own small library of data structures and this kind of things. You have the option of literally having no dependencies, building everything yourself, which I think is nice to have that freedom.

And then there are projects where people are replacing the standard library, right? The PureScript compiler doesn't actually ship with any libraries at all. You pick and mix what you want, which means people can build their own, and people do that. So, it's nice to have that flexibility. And it goes with this idea of how opinionated you want your language to be. Do you want to choose one approach, one solution for a problem, and say that's going to be the [best] solution? Or do you want to give people the freedom to explore the solution space and pick one of a few options.

So, if you do want to learn PureScript, where do you go to learn it? Are there build-in resources on the web page? Are there books? Or what do you do to get started with it?

Yeah, so the website has, the website has some articles and tutorials and that kind of thing. And then it has a list of links to some community sites, so things like the IRC channel, the reddit, subreddit, Google Groups, this kind of thing. There's a PureScript book which I worked on last year, which is actually targeted at JavaScript developers. So, it starts from things like Underscore style maps and folds and then it moves onto slightly more advanced topics like type classes and algebraic data types, but with a focus all the way through on building real applications and using things that you would actually want to use on the web. So, maybe Canvas graphics or talking to DOM libraries or all these kinds of things. So, I think that's a good option. I've been told the difficulty level ramps up quickly with the chapter number. But yeah, I would… [Chuckles]

Say that…

It's got the whole, how to draw an L, draw a circle, draw [inaudible].

Right [chuckles]. Exactly. So, I would recommend taking a look at that. That's available for free, as epub and all these kinds of things. But I would say if you're just testing the water, definitely join PureScript IRC on freenode. We can explain more of benefits and trade-offs and all these kinds of things. Come to PureScript Conf 2016, too. [Chuckles]

Where's that at and when is that?

John, are we hosting that with WonderConf again? I'm not actually sure of the details [inaudible].

Yeah, that's [inaudible]. PureScript Conf will be co-located with LambdaConf. It should be May 25th. It's the date immediately before LambdaConf and that's in Colorado in [inaudible] University of Colorado. Spring time in Boulder. It's gorgeous. There'll be lots of fun stuff. Amazing line up of speakers at PureScript Conf. It's a chance to dig in and get some functional programming over the three days that is LambdaConf.

Awesome.

One of the posts I was reading about PureScript for people who haven't looked at it before, they really praised how, and I'm sure too with it just being a more functional language, it really helped in reading async code. Because the way you write it makes it look like synchronous code. So, that might be a little bit too much to talk now about, since we're at the end. But I didn't know if it was worth going into for a minute.

I think that'd be fair game. One of the libraries, actually the most popular library out there for doing that is purescript-aff which I wrote [chuckles]. So, it's actually a really great topic to discuss. And what it lets you do is write asynchronous code as if it were ordinary synchronous code. And it's, you don't have to worry about callbacks. You don't have to worry about error handling. All that stuff is baked in. And unlike the promises/A+ specification, this one is actually very simple and easy to reason about. And it doesn't have edge cases. It doesn't suffer from all the incidental complexity of those family of specifications around promises. So, it's actually super simple and it's an amazing example of just the clarity and precision and ease of comprehension that using a language like PureScript can bring to a topic as gnarly as asynchronous programming.

The semantics of Aff are super simple and there are lots of examples, great docs. And also, I should point out in PureScript's favor that no additional syntax was added to the language to make asynchronous operations so beautiful.

If there's anything that intrigued me to take a look, it was that post. So, that's the only reason I thought maybe it was worth asking about.

Yeah, I think that's like a common complaint in the JavaScript ecosystem at least. And I haven't written a lot of ES 6, but until things like ES 6 promises came along, handling callback hell is a common complaint. But yes, you get a solution. I'm not going to say for free because there's definitely some interesting problems around things like error handling. But once you, I think once you choose to work with some of these abstractions like functor and a couple of related abstractions, functor we were discussing earlier, and a couple of things like that, the way to structure these solutions is almost suggested for you. You're naturally led to the right solution. So, I think that's one of the nice benefits of working with this kind of more interesting abstractions.

And JavaScript's got, it's getting custom syntax for that one specific use case [chuckles]. And not just that, but generators and all these other things. Basically, PureScript is a language that's powerful enough you don't need to add new syntax to support every new use case. And I think the fact that you can use the same generic time-tested abstractions that people have been using in other functional programming languages like Haskell to solve everything from asynchronous programming to generators and much more is really a sign that it's on the right track. When you constantly, every few years, have to add additional syntax to cover new use cases in the language, that's a sign you're programming, in my opinion, in the wrong way. At least you're not programming in a way that's composable and modular and well-abstracted. And PureScript gives you the tools necessary to do that.

That's cool.

Awesome. Yeah. Well, I think it's about time to wrap up. So, let's move on into picks.

Alright, then. Before we get to the picks I want to acknowledge our silver sponsors.

Aimee, do you want to go first?

Sure. I have one this week. People may have already seen this but it's new to me and I wish I would have come across it much sooner. But it's a talk by Philip Roberts at JS Conf EU last year and it's called 'What the heck is the event loop anyways?'. So, if you are newer and you're not really familiar with how the event loop works in JavaScript, this is a great video to watch to get a firm understanding on that. And he also built after the conference a tool so that you can experiment with it. So, if you're a visual learner, even if you're not you probably should take a look. I just really, really, really thought the talk was great. And the tool that he built was awesome for learning. So, it's so good that's my only pick this week. [Chuckles]

Awesome. Jamison, how about you?

Boy do I have picks for you. I have, I guess I have three or four picks. I don't know. One pick is The Man in the High Castle. It's a show on Amazon Prime. And it's from a Philip K. Dick novel. It's an alternate history about if World War II had gone differently. But it's gorgeous. It's a little slow to start off. It's still well done. But it's just, they do a really good job of creating amazing looking scenery of what an alternate 1960's United States could look like. And it's entertaining, too. So, if you like TV you might check that out.

My next pick is a talk from RubyConf. I've been watching a few of the talks from that conference and they're all really awesome, all the ones I've seen so far. But this one was my favorite. It's called 'How to Crash an Airplane' by a guy named Nickolas Means. And he just tells this story of an airplane crash for about 35 minutes. And then the last five minutes are, and this is how this relates to teams. But he's a really good storyteller. And it's an enthralling story. I was on the edge of my seat wanting to find out what happened. And then the analogies he makes to being a better software team are cool, too. So, that was great.

My next picks are community things. So, I have some friends that run I guess it's a Haskell-ish meetup. It's like, so far it's been more than just Haskell. And they actually had a PureScript meet. One of the meetups was an intro to PureScript. So, if you live in or around Utah and you're interested in things like Haskell or PureScript, check out Lambda Lounge. And then also check out this video of one of my friends presenting on PureScript.

And then my last pick is Joe and I and someone else are actually, we're starting up an Elm meetup. That will be December 10th in Utah. So again, if you live in and around Utah, check it out and join us. Utah is a cool place for software stuff. And there's a lot of exciting things going on with functional programming here. Those are my picks.

Awesome. Alright, well I will go next. So, I recently discovered, because somebody posted it on the internet and I'm really upset at them because it's been trying to consume all of my free time, Screeps.com which is an acronym for Scriptable Creeps. So, if you're familiar with desktop tower defense games, they call the bad guys creeps. And it's basically a massively multi-player online game where you have to program everything in JavaScript. So, if you want to be involved at all and play, you have to completely program in JavaScript. If you want to spawn a new guy. It's like a realtime strategy game, is probably what I would compare it to. But it's really cool and extremely deep and complex. It's not one of these simple little short games. It's actually really big and in-depth. And they have a huge, well fairly well-documented API and it's been really cool to screw around with. So, I'm having a lot of fun with that. So check it out, Screeps.com.

And the other thing I want to pick is the book and corresponding film called 'Most Likely to Succeed'. I've been reading the book and I can't… the film was not, at least at this point online where you can stream it, it was a film that was shown in a bunch if indie film festivals. And it won a ton of awards and it's by these two guys that did a bunch of research looking at the American education system and other western education systems, and just talking about the problems and how our education system is 150 years old and is completely the wrong thing. And instead of revamping it, we've simply been trying to make small fixes to it and doubling down on doing the wrong thing. And I wish that I had read more of it when we had our episode about college degrees, because it's really changed a lot of my opinions about things. And I just find it absolutely fascinating. And for somebody who's pulled a daughter out of high school and has a son who's really struggling in public school, it's been very interesting for me to read this. So, I highly recommend this, 'Most Likely to Succeed'.

And last, I'll throw in a little TV show since you mentioned The Man in the High Castle. I was getting online to watch The Man in the High Castle and for some reason, one of the… I was looking at the recommendations and this TV show called Dark Matter spawned up. And usually, if it's a recommendation that I've never heard of, the rating is super low. But the rating was actually really high. It had over four and a half stars on Netflix. So, I checked it out and I've watched a few episodes. And it's actually really quite good. The premise is really interesting. It's a sci-fi show about these people who wake up on a ship and none of them have any memory of who they are and where they came from. And they're trying to figure out and they're being attacked. And it's really interesting. I've really enjoyed it. So, sort of a mix maybe between Firefly and Star Trek. [Heartily] enjoyed it So, Dark Matter.

And those are my picks. John, how about you?

Yeah. So, I'd say my picks are going to be, first off LambdaConf mostly because of the free PureScript conf that goes along with that. And the website doesn't have a 2016 version. It only has a 2015. So I just went ahead and used the Twitter account for LambdaConf. But if you want to go to the old website anyway, you can check out that link there. And again, that's happening in May in Boulder. A really great opportunity to meet some other PureScripters and probably hack on some PureScript projects.

My second link is going to be this JavaScript library that probably a lot of your listeners have heard about and/or used called Ramda. Its tag line is 'practical, functional JavaScript' and it tries to take some of the FP goodness and translate it into JavaScript. And I do recommend, for people who are curious with what functional programming is about and just the different ways in which it can simplify your program composition and simplify reasoning about your programs, I do recommend just playing with that. It can help inform you if it's worthwhile investing even more time in picking up a language like Elm or PureScript.

And then finally not because it's at all related to JavaScript, my final link is actually going be…

I feel like I should be doing a drum roll.

[Chuckles] Should be. [Drum roll] A link to a recipe on how to create a proper steak and ale pie. I actually made a Paleo version of this, almost Paleo. There's no such thing as Paleo ale, unfortunately. But I made this last week and it was so absolutely delicious that I've committed to making it again probably within the week, only I'm going to double or quadruple the batch because it was a big hit at home. Ever since I went to the Lake District in England earlier this year and had the opportunity to try authentic steak and ale pie, I've been looking for something that's comparable. And this recipe definitely fits the bill. Super easy. You can make it in 30 minutes of prep and two hours in the oven. And so, so delicious you're going to want to make it again and again and again.

Awesome. Well, and then we've got Phil.

Yeah. I have three picks. So, the first one is a Haskell library that I've been using recently called Tidal, which is a software synth I think, [we've] described it as. But it basically, it drives a synthesizer by this DSL, domain-specific language, that it defines. So yeah, it's really fun to try it out. And if you're new to Haskell, we tried it out with a local Haskell user group and it's a really good way to apply these ideas of functions and composition and all these kinds of functional programming ideas in a more interesting, different, to a different application. So yeah, check out Tidal. I think it's really neat.

My second pick is a UI library from PureScript actually that was just started earlier this week, I think. And it really captured my attention, so I think it is a really nice, simple PureScript UI library with a very specific purpose. So, I think it's a really nice example of some PureScript code. And the specific purpose is to take a spreadsheet model of programming where you have cells and formulas in those cells, and the formulas relate the different cells to each other, and then to turn that automatically into a UI application in the browser. So, a spreadsheet I think is an unappreciated declarative programming language, right? Excel is the world's most used declarative programming language, if you like. So, that's why I find it interesting and I think other people might find it an interesting introduction to PureScript.

And my final pick is the Forward JS Conference, ForwardJS4 which is on February 10th 2016, which I haven't been to before. I'm not sure if other people have been to that before. But I'm going to return this year and it looks really interesting. It focuses on things like trends in JavaScript and the web platform. So yeah, those are my picks.

Fantastic. Well, thank you guys so much for coming and being on the show. We really appreciate it and had a really good time getting educated about PureScript.

Yeah, this has been great. Thank you.

Thanks for inviting us. I had a really great time.

Thanks very much.

And we look forward to seeing everybody on the show, or having you listen to us because we don't actually see you. But we imagine you in our minds whenever we're recording. [Chuckles]

Thanks for listening and we'll catch you all next week.