JOE: 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.
JAMISON: Hello friends.
JOE: And the slightly more amazing Aimee Knight.
AIMEE: Hello [chuckles].
JOE: And I’m Joe Eames.
JOE: 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.
JOE: And Phil Freeman.
JOE: 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?
JOHN: 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.
JOE: 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?
JOHN: SlamData, yes.
JOE: Awesome. Who came up with that name? Was that you?
JOHN: 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.”
JOHN: 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.
JAMISON: 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…
JAMISON: Just rake it in.
JOHN: That’s what we’re going to do.
JOE: That’s awesome. And also, 30 years, that’s way cool. As a guy who’s approaching 20 years myself…
JOHN: Oh, my.
JOE: And who is generally surrounded by people who are approaching five years…
JOE: I appreciate…
JOHN: It seems like most of the people in the industry have just entered in the past five years or so.
JOE: That’s right.
JOE: And that’s especially true in…
JAMISON: Some of those people on this call right now.
JOE: [Laughs] It’s especially true in frontend and open source, too.
JOHN: Yeah, yeah. That is so true.
JOE: And I know they’re all sitting around there thinking, “Oh my gosh. These old guys who are so out of touch.”
JOE: I know that that’s what they’re thinking.
JOHN: Some of us [inaudible].
AIMEE: 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.
JAMISON: I hear words that Joe says and I just think, “I can’t wait ’til he’s out of this industry [inaudible].”
JOE: [Laughs] Can’t wait ’til he’s not mucking us up anymore.
JAMISON: Joe [inaudible].
JOHN: We have a few things to add. Age and wisdom and all that stuff.
AIMEE: I agree with that.
JAMISON: Oh yeah, I appreciate it.
JOE: And complaints about whippersnappers that are on my lawn and playing their music too loud.
JOHN: That’s right.
JOE: Alright. Phil, how about you?
PHIL: 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.
JOE: Awesome. And I’m guessing by your accent that you’re from Texas?
PHIL: Yeah, Manchester by way of, yeah… London and California.
JOE: Texas [inaudible]. Ah, cool. Manchester and London. Awesome. And which team do you support?
PHIL: Manchester City. Yeah, [inaudible].
JOHN: Sure. Phil, you want to take that one since you invented that language?
PHIL: 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.
JAMISON: So, can you talk about, you mentioned it a little bit. Can you talk more about the features that PureScript has as a language?
PHIL: 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?
JAMISON: Does that question make sense?
JOHN: 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 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.
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.
AIMEE: 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, 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.
JAMISON: Can I offer another perspective on that question, Aimee?
AIMEE: Yeah, sure. [Chuckles]
JAMISON: 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.
JOHN: 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.
JOE: 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.
AIMEE: 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.
JAMISON: Can you talk about the no runtime thing and why that was important to you? It’s interesting to me.
PHIL: 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.
PHIL: Yeah, exactly. So…
JOE: But you can’t do that with Elm.
PHIL: 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.
JOE: 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…
PHIL: 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?
JOE: And would you consider PureScript to be a functional reactive programming language?
PHIL: 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.
JAMISON: John, I know you wanted to jump in and talk about your perspective on choosing PureScript over Elm.
JOHN: 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.
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.
JOE: 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?
JOHN: Yes, as well as signals and channels.
JOE: Ah, okay.
JAMISON: I just want to point out that the shared delusion of calling UIs UEs has now spread to Joe.
JOE: I’m like, [reflecting] the way you call it. [Laughs]
JOE: I’m channeling you.
JAMISON: Yeah. That’s what you mean when you… do you mean user interfaces when you say UEs?
JOE: [Laughs] You know what I mean.
JAMISON: Well no, I just want to make sure.
JOHN: I’ll call them GUIs. GUIs. I like that word better.
JOE: Yeah, GUI is okay. But UE apparently…
AIMEE: [Inaudible]. The first time I ever said if-e at work, I was the only one who knew what that meant.
JOE: 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.
JOHN: 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.
JOE: 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?
JOE: What about ClojureScript?
JOHN: 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.
JOE: Alright. Jamison, did you have a question?
JAMISON: 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?
PHIL: Yeah, definitely.
JAMISON: Are you a genius? That’s what I’m trying to ask.
PHIL: [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.
JAMISON: 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?
PHIL: 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.
JOE: So, what do you think the effect of WebAssembly is going to have on languages like PureScript?
JAMISON: Can we get a definition of WebAssembly first? I don’t think we’ve actually had a show about it.
JOHN: Well, it’s basically a lower level assembly language that you can build programs on top of.
JAMISON: It’s like a target specifically for compile to JS languages basically, right?
PHIL: I think emscripten is the main user right now. Is that right?
JAMISON: I have no idea. I actually don’t know that much about it.
JAMISON: Sure. That’s another one of the benefits of not including a runtime, right? With Elm you end up…
JAMISON: 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.
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.
JAMISON: 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?
PHIL: Say that…
JAMISON: It’s got the whole, how to draw an L, draw a circle, draw [inaudible].
PHIL: 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]
JOE: Where’s that at and when is that?
PHIL: John, are we hosting that with WonderConf again? I’m not actually sure of the details [inaudible].
JOHN: 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.
AIMEE: 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.
JOHN: 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.
AIMEE: 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.
JAMISON: That’s cool.
JOE: Awesome. Yeah. Well, I think it’s about time to wrap up. So, let’s move on into picks.
CHUCK: Alright, then. Before we get to the picks I want to acknowledge our silver sponsors.
[This episode is sponsored by Thinkful.com. Thinkful.com is the largest community of students and mentors. They offer one-on-one mentoring, live workshops, and expert career advice. If you’re looking to build a career in frontend, backend, or full-stack development, then go check them out at Thinkful.com.]
JOE: Aimee, do you want to go first?
JOE: Awesome. Jamison, how about you?
JAMISON: 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.
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?
JOHN: 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.
JAMISON: I feel like I should be doing a drum roll.
JOHN: [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.
JOE: Awesome. Well, and then we’ve got Phil.
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.
JOE: 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.
JAMISON: Yeah, this has been great. Thank you.
JOHN: Thanks for inviting us. I had a really great time.
PHIL: Thanks very much.
JOE: 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.
JOE: Thanks for listening and we’ll catch you all next week.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]