Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#56 First returning guest Eric Normand explains how to Grok Simplicity
61 Plays6 years ago
Check out Eric's book in MEAP - https://www.manning.com/books/grokking-simplicity
Recommended
Transcript
Introduction with Eric, the First Repeat Guest
00:00:15
Speaker
So welcome to DeafN, I think the final episode of this year. And amazingly enough, we have a repeat guest on this episode, episode number 56, all the way from episode number 27. Eric, welcome back. Hello. I'm happy to be back. This is awesome. You're the first repeat guest. How does it feel? You know, this is like an achievement or achievement unlocked.
00:00:44
Speaker
Maybe like a broken record, I guess? No. No, it's really cool. I listen to the podcast, so it's cool to come back on. I mean, I meant achievement for a different podcast itself because we never thought we were going to be long enough to have somebody come back. It's not an achievement for you. It's just for us. We'd have you on every week.
00:01:09
Speaker
Yeah, thank you for having me on because I know there's a lot of great people to talk to. You didn't have to repeat. You're finding cool guests all the time. Yeah, but you're still cool, so that's good. And also, you've been doing a lot of stuff, so it's nice to catch up.
Eric's New Endeavors and Language Challenges
00:01:27
Speaker
Yeah, although you and I, Ray, we talk. We talk now and again. We talk now and again, yeah.
00:01:34
Speaker
Yes. So how is it going, by the way? I mean, I never pay attention to anything other than DeafN. Obviously, DeafN is there. It takes up all your time. We know. Exactly. We have practically 19 hours a day. Come on. VJ is actually going to another language podcast. You're doing a Rust language podcast. We had one episode. You've had two, haven't you?
00:01:56
Speaker
Yeah, too. I know more about his podcast than he does. You're learning Rust, Vijay?
00:02:06
Speaker
Yeah, I'm trying to. It's another one of those things. I'm trying to get to the non-GC languages from the history. I tried Visual C++, C++ a long time ago. CC++, that's how I started. So I forgot how cozy it is with the GC stuff. So I'm like, oh, let's try this shit. And then it's a different world completely. It's fun. It's kind of a functional but non-GC stuff.
00:02:33
Speaker
Yeah, so he has a Rust podcast, which like you say, it's done two episodes, maybe he'll do more next year. But uh, but yeah, me and Eric, we do something proper, you know, we do
00:02:46
Speaker
It has a prop in it.
Writing a Book on Functional Programming
00:02:48
Speaker
Well, actually, I mean, the nice thing about Apropos, which is the YouTube channel, is that we've been doing that, I don't know, actually, is that about a year now? Yeah, a little over a year. And that's really nice, you know, I think it's, we never have any guests on there. So we can
00:03:06
Speaker
please ourselves. I think we had a guest one time. Oh yeah, we had Stuart Holloway. We have Royalty on. They're not really guests, are they? That's a nice way to insult our guests. But luckily. Exactly. So Eric should know.
00:03:27
Speaker
So what have we been up to, I reckon, in the last two years, whatnot, eight months, nine months? Where do I begin? Well, the big thing I'm working on is my book. I started that maybe a year and a half ago. We're all rounded up to a year and a half. Yeah, it's a lot of work. And it's taking way longer than I thought.
00:03:55
Speaker
But it's coming along and it's going to be a really great book. It's all about functional programming and it's not enclosure. Everyone asks me that because I'm like a closure. Why do you hit closure, Eric? Can we ask you the first question on the Deaf Enclosure Podcast? Why do you hit closure? Come on.
00:04:17
Speaker
Where do I begin? Yeah, I know. I have a blog post ready. I mean, almost published about all the things that are wrong with closure. Bring the holiday cheer, yes. No, I mean, specifically, I think that the ideas, I mean, let's put it shortly. My goal for the book is to make functional programming accessible to a wide audience.
00:04:46
Speaker
And starting with closure and having to teach closure to people, you know, it's just not what it's not it wouldn't fulfill the goal. Plus, it would be kind of preaching to the choir like we already believe in immutable data and stuff like that. So there's no, you know, it would just be kind of
00:05:06
Speaker
I don't know, master, but don't worry. So just let's just talk about all the mental masturbation you mean? Yeah, like an intellectual. Yeah, yeah. Yeah. That's an interesting starting point, though, isn't it? Because if you're not gonna, I mean, obviously, what I'm interested in is like the precepts of functional programming.
00:05:26
Speaker
Listen to your podcast as well because I think that's a really interesting one because you talk about functional programming on your podcast, but you talk about Haskell and Clojure and JavaScript and all these various things, but you identify yourself in that podcast.
00:05:43
Speaker
as a closure programmer. So, but why is that something you do in the book, you identify yourself as a closure programmer, and that's your influence?
Exploring Functional Programming Across Languages
00:05:52
Speaker
Or is it like, is it like a hidden hand of functional programming? That's the big reveal.
00:06:03
Speaker
By the way, you just learned to close your throat. Exactly. Just put a few parentheses at the beginning. The parentheses are here and they're all still in the middle.
00:06:16
Speaker
Yeah, that's a really good question. I don't think I'd talk that much about closure in the book, except where it's like, oh, you know, this is how closure does it. This is how, you know, you're learning the real thing. You know, this is how other languages do it.
00:06:33
Speaker
including Haskell, but I don't ever say like, I'm a Clojure programmer and I'm teaching this stuff. I do think that Clojure gives a very useful perspective to functional programming. Let me just contrast it with another, I think, very well-designed language, Haskell.
00:07:01
Speaker
it focuses much more on the types. It's sort of like, let's get this language out of the way, have immutable data and pure functions and first-class functions. And now let's get to the types because that's where the interesting stuff is. And as closure programmers, I don't think we believe that so much. And so a lot of...
00:07:29
Speaker
A lot of what the book is doing is taking those closure approaches to functional programming and bringing them to a wider audience. I was going to say that just to give a little bit more context in the book about the book, I need to give code examples. I use JavaScript for that just to make it have as wide an appeal as possible.
00:07:59
Speaker
So you don't have to learn the language before you start doing the functional programming stuff. I chose JavaScript because, I mean, it is a very popular language, but it's also readable by people who know Java or C or, you know, you can, you can, and I mean, it's readable. Like it says function, you know, when you create a function, you don't have to use the ES7 syntax. I don't use any of the new stuff. It's all the old school. It's the OG JavaScript.
00:08:30
Speaker
I mean, I've had people in comments say like, oh, you should use some of those new features and use let instead of const. And I'm like, I don't want to get into a discussion about let versus const. That's not the point of the book. I'm just using var everywhere. I know that some people are going to be like, oh, but you got to teach new. It's not teaching JavaScript. That's not what I'm doing.
00:08:56
Speaker
I don't want a Java programmer to come in and be like, what is the difference between let and const? Sometimes you use let, sometimes you use const. I don't want that to be on their mind.
00:09:08
Speaker
But it is, if you see like teaching functional programming, what I felt is like these days, every type of programming methodology that you want to learn is attached to
Teaching Functional Programming Simply
00:09:23
Speaker
a language, right? It's very difficult to abstract it away and then explain, only I'm going to explain functional programming to you. And then you can implement that in any language you like. Some languages are more flexible to implement this. Some languages look horrible when you implement this.
00:09:36
Speaker
So I don't think it's an easy, I don't know the English word, like the teaching method called functional programming is tricky, but I understand your approach because you're not going to take, you're not teaching JavaScript. I think you said it, you know, very, very nay, in a very nice way that you're not teaching JavaScript, you're just teaching functional programming fundamentals. Right. And this is how you can write in version one of JavaScript and then whatever. And then later you can pick it up. Exactly.
00:10:05
Speaker
Yeah, I mean, what you said is really true. It is hard. And that was one of my complaints. And one of the reasons I started the book is because so many books about functional programming are either super academic, and they don't really start with the basics. You kind of have to be, I don't know, have a PhD advisor guide you into it.
00:10:30
Speaker
or they're just about a particular language and one language's approach to functional programming. But completely, I feel like doing a disservice to the beginner who just would benefit from just identifying pure functions. That is a huge thing and I think it's the
00:10:57
Speaker
It's the start and everyone like has a little footnote somewhere like one sentence like okay and these should be pure functions like what no that's. That's it like that's the meat of it that that's where you should start liking.
00:11:12
Speaker
Talk about pure functions, why they're better, how do you identify the impure functions, and how do you refactor it so that you have less code in your impure function, more code in your pure functions. And so my book spends the whole first seven chapters just on this idea.
00:11:34
Speaker
One thing that I find, I've said this many times, but I will say it again to you, and I'm interested in what your take on it is, is that I think as a branding exercise, functional programming has got an absolute huge problem because functional is a completely stupid name for a programming style. Object orientation, there's something behind that.
00:12:01
Speaker
you know, sort of imperative, there's something behind that. Functional is just so overloaded these days. And I also don't think it properly describes what FP really is. So I think what's your kind of manner that you your book title doesn't use functional programming uses you talk about simplicity. So what how do you feel about like the branding issues around functional programming?
00:12:27
Speaker
Right. So I'll say the book just for the audience. Grokking Simplicity is the name of the book. But that's a really good question. I didn't give you the questions beforehand, so sorry about that. No, no, no. But it's a really, it's a good question. And it's a problem that in one of my drafts, I like tackled it head on like, why am I,
00:12:57
Speaker
I kind of redefine everything, like give it everything new term because I feel like the terms are very confusing. Functional programming, it makes you think that it has something to do with functions. And a lot of the definitions, including the one on Wikipedia,
00:13:16
Speaker
make it all about functions. And they'll say it's programming with mathematical functions, otherwise known as pure functions. And I think that that just does such a disservice to what we do day to day. I mean, for instance, as closure programmers, we use side effects, we use a state, mutable state.
00:13:39
Speaker
But we're still doing functional programming and I feel like we have a lot to say about state inside of it. I'm kind of like going a bit higher level in that because I think the notion of something that is functional means that it's something that works in the English language.
00:13:55
Speaker
It's overloaded in that sense that of course, programs should be functional. It feels like it's kind of like a philosophical debate rather than a kind of pragmatic debate. That's why I mean. Haven't we already moved multiple levels from that by introducing things calling variables which are not actually actually variables?
00:14:18
Speaker
But we already overloaded them. We used so many mathematical terms in totally different ways. They are variables. Why are they not variables? Well, a variable in math doesn't change. Mathematics is wrong there. No, a variable in math doesn't change. It varies.
00:14:38
Speaker
If it's variable, then it must be subject to change. So, okay, this is a common confusion, especially among programmers. Like when you have a variable in a formula or something, a mathematical formula,
00:14:56
Speaker
It varies with each use of that formula. So in this time, we'll say x equals 1. Well, let's try it with x equals 10. But within the run, it doesn't change. And as we think of a variable as programmers, we think of a place to store a value that will take different values throughout the course of it. And so then we think, but how is it a constant variable?
00:15:25
Speaker
The original variables were constant for that run. But it's not the thing, no, it's not one of these, it's like where we are fighting these languages, you know, like you said.
00:15:36
Speaker
And then function, it's like, well, it's a function. It says function in JavaScript, that type function. So that's why I throw away all the terms. So I don't use, I mean, I explain the terms, but they're not what I use in the book. I use actions, calculations, and data. So distinguishing these three things is like what I consider the gateway, the first paradigm shift
00:16:02
Speaker
It requires being able to distinguish these things. I get data. Data is definitely different from actions and calculations. On first blush, I've listened to your podcast, I do know the difference. But when I first hear those two things, actions and calculations, I'm not exactly sure what the difference is. Maybe that could be worth going over.
00:16:29
Speaker
Isn't calculating an action?
00:16:35
Speaker
In this context, because it's closure people, I feel like we can go kind of deep on this. It's true. Calculations are actions. They're subsets. The set of calculations is a subset of actions. And data is a subset of calculations. Because we know that if you wanted to make a Turing machine, it would be actions.
00:17:02
Speaker
It'd be like moving the head, the read head, reading a mutable value from underneath wherever you are. So it's all actions. But you can simulate calculations using that Turing complete system. And then we know by lambda calculus that you can represent data using functions.
00:17:21
Speaker
using mathematical functions. So they are subsets. The thing is, you don't want to be working on that subset hierarchy all the time. You want to get the benefits of the calculations and the benefits of the data. So you just kind of stick. You use the compilers, features to stick within that domain, the calculations, the data, the actions.
00:17:47
Speaker
Does that explain it? I understand it. What you're doing now is you're saying that actions are side-affecting. That's a difference between calculations and actions in your vocabulary.
Using JavaScript for Teaching Functional Concepts
00:17:59
Speaker
Yeah, actions, actions are what you might call an impure function. Except function, the problem is function like sounds like a feature of a language, right? Like a JavaScript function. Because a lot of actions are not functions. The action might be an assignment statement.
00:18:20
Speaker
Right? Or the action might be, you know, it could be a method, which is kind of like a function, but it could be an operator. It could be the plus plus operator. So it's really, I'm trying to just like totally use new terms that are outside that don't have features attached to them. Yeah. So you're using JavaScript to explain this concept in the book. Yeah. Why JavaScript?
00:18:47
Speaker
because it is very positive. I think it goes back to the beginning question, like, why do you hate closure? I'm tired of all the parentheses. That's what it is. The parentheses' keys broke off of my keyboard, and now I'm just tired of it. Sorry. So why does that look good? Too many.
00:19:11
Speaker
Why JavaScript? I like semicolons. You don't need them, JavaScript. But you don't need them, but you can use them. I love the fact that JavaScript people get really upset. Some people really don't like semicolons either. I think it's like spicing up your pizza.
00:19:32
Speaker
they used in semicolons, because if you are, then you'll get a bunch of hate from people who like, you don't need them. And if you don't use them, then it'll be even worse. So what's your, well, I think you can, you can have two versions of the book, one with semicolons, one with the other one, so you can buy whatever you like, you know, and on that you can sell to both markets. Yeah, exactly. No, inclusivity. That's what's important.
00:19:55
Speaker
Well, I do insert unnecessary parentheses in my JavaScript as well. I just surround every value in parentheses just to get a feel. I don't want to lose my closure.
00:20:15
Speaker
I need my rainbow parens to get some rainbows. Exactly. We all have funny languages. Why JavaScript? It's really popular. There's an automatic reach there.
00:20:32
Speaker
And then, like I said before, the syntax is readable. Even if they don't know the ins and outs of JavaScript, they can read an if statement, they can read a for loop. It's just something that they don't have to spend too much energy on.
00:20:53
Speaker
Of course, where it is something that they wouldn't know if they weren't a JavaScript programmer, I do explain it, but it's still readable. They can still read it, and if you name the functions in clear names, they'll get it. Who's the target audience? Because if you explain all these concepts, actions, calculations, and data,
00:21:16
Speaker
And then eventually you need to use these techniques in whatever the language that you pick up, right? Yeah. So how do you drive that home to the people who are reading the book? And what is your plan? So the publisher has pegged it at two to three years of experience, programmers for two to three years who already know a language.
00:21:38
Speaker
They've gotten into some weeds, made a mess, and they need some techniques to help them through. The way to make it stick, to make it practical to them, is I have a lot of exercises, step through refactorings of the code to make some JavaScript function more
00:22:04
Speaker
I want to say functional, but you know, just separate out like these are the side effects. These are the not like you don't need you don't really need to use a global variable here. You could use a local and so that's kind of in the weeds a bit Eric. I mean, it's at a high level. What is your kind of pitch round like?
00:22:22
Speaker
like functional programming what are you trying to sell to these developers when they've got there i've got themselves like few few years experience and why should they bother with functional programming is your answer you must answer that question as well.
00:22:39
Speaker
Yeah. So I'm attacking it from three vectors. I'm saying it helps you do reuse, testing, and maintenance, maintainability.
Benefits of Functional Programming in Code Management
00:22:53
Speaker
So those are the like practical things I can sell about it. I think that there are
00:23:00
Speaker
There's also a group of people who want to do functional programming, but they can't find inroads into the current literature. There's a little bit of that too, but that's not something you can really sell.
00:23:17
Speaker
It's hard to find those people and target them. Really, I focus on those three. One of the reasons you're having a ton of bugs, it's hard to maintain, is you're just doing mutation everywhere. It's much more maintainable if you segregate that off into a little piece of code that you can spend extra time on, pay extra attention to,
00:23:42
Speaker
The other stuff is really testable. You just write test for it and you can leave it alone. This is going back to the closure stuff. It's like pulling things apart.
00:23:57
Speaker
We have a tendency to think that the bigger the thing is, the more it does, the more reusable it'll be. You think of some kitchen gadget that can do like 17 different things. You think, oh, it's so reusable. I can reuse it in 17 different ways.
00:24:13
Speaker
But really, the most reusable thing you have in your kitchen is the knife, the pan. Just the basics, the one-function tools are being used for almost everything. That's the approach I'm taking.
00:24:35
Speaker
make things more reusable by splitting them apart instead of having it do everything. At least you get to reuse a part because you might get part of it wrong. So if there's in two separate parts, you don't have to rewrite both.
00:24:50
Speaker
Yeah. So I think one of the long time ago, maybe two years ago or something, I read a blog post calling like programming has these three tribes. Like first tribe is programming as a mathematical thing, like applied mathematics. And then it's basically Haskell, even closure, lispy stuff into that one.
00:25:11
Speaker
And then the second one is programming is hacking the hardware to C, C++. I think that's the first time I read this mechanical sympathy. You need to know what the machine does or something. And then there is a... So C, C++ fall into that category, that tribe of programming. And the third tribe is, I just want to get shit done, so I'm going to hack something in Python and JavaScript and go home. It's like to make things work. So for me, I think those three seem to be valid.
00:25:41
Speaker
And do you agree with this kind of classification? And if so, then how do you see this functional things applying to three different areas? That is a really insightful triad there, and I'd love to read it. I'd pee, finally.
00:26:04
Speaker
I finally peaked by regurgitating some blog posts that I read like three years ago.
Functional Programming in Different Programming Tribes
00:26:10
Speaker
I'm thinking about it though. You need all three, right? You need all three. Sure, you need to get stuff done, but that kind of development is going to make a mess. Maybe it's what he's doing. The first one is kind of got already. Second one might be difficult to reach because of the kind of performance issues or whatever.
00:26:31
Speaker
And it's more like the third one maybe is the interesting target for your book. I don't know. They get things done? Yeah.
00:26:40
Speaker
Yeah, because this is, I mean, I really start from in the book, I really start from, and thanks for all these like challenging questions, by the way. We improved from compost and PHP. Is it gradually kind of, you know, improved? All the crowd that we have been collecting finally being useful after two years.
00:27:07
Speaker
rich human. It's a rich loamy soil in which your weeds can grow and flower. Come on. What was the question?
00:27:22
Speaker
What was the question again? Yeah, it was about... The getting things done people. Yeah, the getting things done people, I think they'll make a mess, right? So my book, I mean, if that's the only attitude you have, I think that that's clear. Yeah.
00:27:40
Speaker
The book approaches like the first code you see is here's an existing system and here's how we would just like simply get the next thing done.
00:27:55
Speaker
It starts to say, okay, but this is what we would do to clean it up using functional principles. And it's just a lot of refactoring. And like, I don't know, I code that way. I code something like, what's the easiest thing to get this thing working? And then I come back later and I'm like, oh, this is a mess. I don't even know what's going on. I clean it up.
00:28:17
Speaker
I don't know the mechanical sympathy only comes in if i need to optimize it or something yeah yeah i feel i think it's a this is something that i've been thinking a lot lately thinking about all the course in enclosure and python i do a lot of python day to day.
00:28:34
Speaker
working with the data related stuff and i see when i pay with somebody who is doing python we just do something i know let's let's just take it straight through happy path if it works well done let's go home and then on the other hand when i'm trying to use color arrest for example rascal there that you have to think about.
00:28:53
Speaker
how this is going to fail and capture that thing. The result types or the option types or whatnot. That's a different thing. Closure seems to be falling in between somewhere. It's super productive because of all the REPL and these kinds of things.
00:29:09
Speaker
somehow because of immutability and all these things being available, I think my life becomes slightly easier. So I could see moving between these three. But as you said, I can totally agree. If I'm writing something in Python, I'm always waiting for when it is going to fail at some point. And then try to fix that bug. And so especially dealing with data, it's a pretty tricky situation to deal with that. There's another problem, essentially.
00:29:37
Speaker
I know, I know, I agree with the JavaScript choice in the sense that it has got broad reach and it's got a kind of interesting, what should we say? It's got an interesting functional nature, you know, because, you know, there is an argument that he was going to write it as a kind of version scheme. But then he was like, yeah, you've got to put this, you've got to put these, make it look like C because we want to attract Java developers, blah, blah, blah. Who knows what that, you know,
00:30:06
Speaker
I don't think that that story is fully told yet, but certainly the concept of FP was in there from the beginning, that's for sure. But my question is, and this is one of the things that when I'm trying to motivate ClosureScript people towards ClosureScript rather than JavaScript is that I talk about kind of defaults rather than possibilities, because with JavaScript, like most Turing-complete languages, like you said earlier on, you can do everything.
00:30:35
Speaker
But the question is, what is idiomatic? What does the language help you to do? What does it make straightforward and simple? And that's why functional programming languages are functional programming languages. That's why object-oriented programming languages are all languages. You can do everything you want to do in C, knock yourself out. You can be FP, you can be O, you can be
00:30:59
Speaker
clarity. If you can do everything you want, you can do logic there. So the question is, assuming you're going with JavaScript, do you ever allude to the fact that there are other languages that could make this more idiomatic, make it more supportive?
00:31:19
Speaker
By the way, after 20 chapters, this is the only chapter you need, you know, close your move on. Right. Right. It's sort of like in that book about Java concurrency, the joke that Rich Hickey read it and wrote closure so that he wouldn't have to do all the stuff in the book. Exactly.
00:31:44
Speaker
Because it's really true. You read it and you're like, oh my God, I have to do that. It's so hard. Okay, so it's a really good question.
Immersive Learning in Functional Languages
00:31:54
Speaker
So I look at it like this. If you really want to learn functional programming, you need to do immersion. You need to get into a functional language and try to solve problems with the constraints it's putting on you.
00:32:07
Speaker
Because that's what functional languages do. They constrain you. They make you use immutable data. If it's typed language, they're making you use the type system. You're going to be forced to do it. And that is the best way to develop the thought patterns and the mindset that you need.
00:32:26
Speaker
However, as a pedagogical tool to teach the concepts, I actually think JavaScript is a good language for it. There might be better ones, I don't know, but JavaScript was good because, for instance, if I were to introduce immutability in Clojure,
00:32:48
Speaker
It would be like, okay, it's just a language feature. I don't need to know how it works. I'm just going to use it. Whereas in JavaScript, it's a discipline. You don't get it by default. You have to do it. So you get to see all the work that it takes to use immutable data. Basically, you do a copy on write or a copy on read.
00:33:10
Speaker
You have immutability. And so now you understand it, you understand the cost of the discipline and the difficulty of doing it. Okay, now you're going to appreciate when you go to closure and have to use it. Is that how it works? I mean, is that the feedback you're getting? Because I'm interested whether people, because like you say, if people are having to suffer pain, people don't like that, you know?
00:33:40
Speaker
But I guess what you're saying is you can, you can, you can see it from first principles maybe, you know, so yeah, there are libraries that help you out here and there are other languages that can help you out even more, but actually this is like the, like a first principles kind of model. It is a first principles model and it's also like.
00:34:04
Speaker
You know, I say it's like getting back to basics in functional programming. I would be happy if people just could identify mutation.
00:34:14
Speaker
Oh, this is unsafe to call because it's going to change the JavaScript array I pass it. If they could know that, or like, oh, I can't hold on to this thing because I don't trust that something else that doesn't have a reference that's going to mutate it. If they could do that, that would be a huge win. So if people start putting lines at the end of their function names, that's already a start basically.
00:34:41
Speaker
Yes, exactly. Just be careful. You can do it. Here's the rope. You want to hang yourself? Go ahead. But it's that kind of thing that I really think that other books don't talk about. They just do not spend any time. They don't spend enough time. Like I said, they might be a sentence, a paragraph, but they don't spend enough time for
00:35:07
Speaker
beginners to realize like, for instance, that the plus plus operator actually does three things. It reads the value out, it adds one to it and it stores it back. And so that's three things happening. One of them is a calculation, the adding, right?
00:35:25
Speaker
But the other two are actions and you can interleave another plus plus operator and another thread between those. And it, uh, you know, gives you weird mistakes that only happen sometimes. The funny thing is I remember, I remember reading that, um, swift does not allow plus plus. And they had a, they had a very long like discussion about this because they were saying, yeah,
00:35:51
Speaker
Exactly to your point, you know, is that it has all these magical properties that cause a lot of unknown bugs. And so, yes, it's convenient. Yes, it is sort of expressive. But actually, it's just too dangerous and too buggy. And the things are not what's going on is not obvious enough. So they actually disallow it, which
00:36:13
Speaker
I mean, you could disallow it or you could make it an atomic operation. You could say, well, if you're going to do it, we're going to put a transaction around this and nothing else can look at this variable in the meantime and it'll slow everything down because it does look like it's a single thing.
00:36:32
Speaker
Coming back to the, so the book is called Grocking Functional Programming. Grocking Simplicity. Simplicity. My brain already linked simplicity with functional programming. The interesting point about that actually is like, where does the simplicity come in? How do you, how do you, I know, sorry.
00:36:54
Speaker
I probably need to go through and just use the word simplicity a lot more in the book.
00:37:07
Speaker
It's kind of just like a historical accident that it's called grokking simplicity. It probably would have been called grokking functional programming, except they already have by that title. I think it's a good rebranding of functional programming because I think functional programming is terrible, like I said at the beginning. And I think simplicity is much better.
00:37:32
Speaker
because that's really what you're trying to aim for, clarity, simplicity.
00:37:38
Speaker
Yeah, and it's another aspect of the closure influence that I was talking about. Call back to closure, yeah. So yeah, the simplicity is all about pulling functions apart into more reusable pieces.
00:38:02
Speaker
It's about the complexity of having so many actions and they can interleave, right? And so the complexity is like, how many ways can they interleave? So it's a quantitative thing. If you have two actions in each thread, there's, I think, six ways they can interleave, something like that.
00:38:31
Speaker
But what about JavaScript single threading? Because that's what people will say about JavaScript as well. Don't worry about the threading because it's all fine.
00:38:39
Speaker
And they do say that, don't they? The problem is once you have Ajax, you have any kind of asynchronous call, then you're back to, I mean, they're not threads, but they're different timelines because you will chain an Ajax call after another one and after another one. And that's, there's multiple of these chains happening at the same time. And you don't know when each one is going to be called. The callbacks are going to be called.
00:39:05
Speaker
Then you also have this other problem of stuff is happening on the server. You read a value and you think it's current and you add 10 to it and send it back. Well, what if someone has already changed it? You need to be thinking about this in a distributed systems world.
00:39:27
Speaker
So functional programming has been sold as like, we're going to need it because of multiple cores on our machines, right? Yeah. And I mean, it certainly helps with multiple cores. That's not untrue. But we were also promised like thousands of cores by now.
00:39:47
Speaker
Like 10 years ago, it's going to double every year. And it hasn't. We have like, what, 16? 16, yeah. We are, though, facing all these distributed programming problems that we weren't facing or we weren't maybe aware that we were facing them 10 years ago. We didn't have so much Ajax. You would even have just like one database and like
00:40:13
Speaker
Now we realize, oh, we've got a client running on every browser and we've distributed our application to all these microservices and each one has its own database and they have to sync up somehow. And this is where functional programming and this why it's actually being used right now.
00:40:37
Speaker
It's not going to... The scope of functional programming is not going to go across these boundaries of systems, right? Right, no. But how do you see that then? Because within the system it makes sense. Yeah, functional programming does not give us a model for programming the cloud, right?
Functional Programming in Distributed Systems
00:40:55
Speaker
Yeah, exactly. What it does is it gets us to ask the right questions.
00:40:59
Speaker
It says, oh, this is an action, even though it seemed like I was just reading something from the database. That was actually a message that got passed to a different machine and the database interpreted it and sent back an answer. So it's actually two messages. Object-oriented programmers don't think about that.
00:41:23
Speaker
I mean, they do, they do. When they get to a certain maturity, they know this, but they're not thinking of it as part of their paradigm. They're having to learn it, but it's not part of the paradigm. And in fact, a lot of object-oriented programmers, if I could generalize, they try to bury it. So they'll take the ORM,
00:41:51
Speaker
and they'll wrap it around the database and then maybe add another layer on top and think that that's going to make the difficulties of dealing with mutable state go away. It's going to like, oh, it's going to give it a nice interface. But like, no, what you need is to pull it out.
00:42:09
Speaker
You need to not wrap it up. You need to separate out the stuff that is dangerous, you know, the mutation and, and you still have it. You need the database, but then separately you have like all the business logic and stuff to keep it, keep it pure. So just, I mean, I think you do talk about this in your podcast at least I'm guessing it's going to come up in your book, things like, um, idempotency, for example.
00:42:36
Speaker
That seems to me to be a kind of answer, if you like, to the distributed database problem, because you need to know that actions can be repeated, essentially, or in your case, calculations can be repeated.
00:42:55
Speaker
Actually, which do you think? Actions, you need to be able to, you know, I mean, the example I give is you want to send an email exactly once, right? You don't want it to zero times and you don't want to send it twice. And so if you don't get if you don't hear back, you make some HTTP post, and it gave you a 500 error.
00:43:19
Speaker
Like, did it send the email though? That's what I really care about. And you can't know, like maybe it timed out and you never received it, but maybe the server crashed after it sent the email, right? Or the network got moved down before the request came. Like, you don't know. And so the answer, you know, for robustness that you need in a distributed system is to be able to send it again. Send the same request again and assume that they will remember, oh, we already sent this one and we won't send it again.
00:43:48
Speaker
And so that means you need the action to be idempotent. So yes, that's an action being idempotent. What about transactionality? Where does that fit into your scheme?
00:44:01
Speaker
So in the book, we are going to develop transactional, sort of like a closure atom, but that works over asynchronous changes. So you might do a read and then do some AJAX request and then use the value from that to do a write back into it.
00:44:27
Speaker
And so it's got to be transactional across that whole thing. So basically, you have to queue them up. You just have to wait for everybody. We're going to do the regular atom, but that's easy.
00:44:44
Speaker
in JavaScript because there's no threads. So the ordering is straightforward because it's just single-threaded ordering, so you don't need to worry about the ordering problem. Yeah, exactly. The ordering happens automatically as long as you don't have any asynchrony. So you say if you pass a pure function to the atom, it's going to take the current value, run the function on it, the return value is going to be the new value.
00:45:13
Speaker
So is this, so grokking simplicity, is it now available as like a beta book or something? Before we get into that, let him pimp it out a bit later. Let's carry on with some of the technical discussions. Hold on a second. That's an insult to this podcast.
00:45:36
Speaker
No, I mean, the thing I was going to ask you about was another thing to do with functional programming, grokking simplicity, where maybe it's kind of at odds, but I'm interested in your thoughts about this is high order functions because
00:45:49
Speaker
me, higher functions. I don't know if they're undersold or oversold, to be honest. I do use them most days, my self-inclosure, but obviously with mapping and all kind of stuff. But also, I will write programs that take functions. But I rarely return functions, to be honest. But I'm just wondering what your take on the higher order of higher, because obviously, it's important when you're talking about functional programming.
00:46:18
Speaker
Or is that something that you lied or is you focus on this concept. Good question. So higher order functions I think are really important. They are the focus of the second part of the book. So the first part, the idea is just let's just identify actions, calculations and data.
00:46:42
Speaker
That's where it's sort of like, what's the biggest bang at the level that they're at? Biggest bang is like, know that that is unsafe. We can't do that willy-nilly. We have to put some boundaries around it. And then the second big bang is, well, you got these first-class functions. And so what can you do with them? And so that's an introduction to map filter and reduce.
00:47:08
Speaker
It's also an introduction to higher order actions. So this is stuff like being able to pass an action to a queue to make sure that only one gets run at a time in the right order, right? So you want to introduce the declarativeness of actions so you can declare and then execute them. Right, exactly.
00:47:34
Speaker
I think that's a hard concept for people to know that you don't have to send the email. You can have a function that will send the email and you can call it when you're ready. That is exactly the mindset shift that has to happen to get first order functions.
00:47:56
Speaker
But in day-to-day life, we are used to this one. If I make a list of things to do, like go to the market, buy milk, then go and get a tram, then it doesn't mean that immediately by reading the second one, I'm going to get the tram first. But you see, what happens is when you write the program,
00:48:13
Speaker
Yeah you are already at one level of running removed right so i'm writing the program to x do i do z that's my main right. People think that's it like i've already paid that and send everytime i run this program it's gonna run everything.
00:48:32
Speaker
What they don't realize is they can do it again inside the program and make it so that this thing is going to write the list and return it and this other thing is going to run the list. That's the shift that I think you need to, that people will need to make. It's going to be like a lot of people get map filter and reduce. They understand,
00:48:59
Speaker
how to use it practically or have a list and I want a different list. I'm just going to run a map over it.
00:49:06
Speaker
But what they don't understand is how much can be done as a total pipeline. All your work is done as chaining, map, map, filter, filter. You can do almost the whole program with that. And so we're going to focus a lot on that. We're going to focus a lot on the actions side. So that's just the calculation stuff.
00:49:33
Speaker
The action side, these chapters are actually mostly written. So this is a thing I have about functional programming. Everyone talks about pure functions and how great they are. But I think we have, as functional programmers, we have a lot more to say about actions.
00:49:53
Speaker
and mutable state and like you were talking about idempotence, Ray. I don't know of object-oriented people saying this, right? They're talking about stuff like that. We have a whole array of things that we know are important, transactionality. We
00:50:17
Speaker
We don't give ourselves enough credit that actions are a first-class part of our paradigm. Impure functions are part of the paradigm. It's not just pure functions. We're not just avoiding actions. No, we are treating them in a special way because they are so volatile, so dangerous, they're the source of bugs. And so we have all these things that we do to
00:50:45
Speaker
Maintain the order between two actions in different threads. At least make sure that they don't happen at the same time. One has to go first. We discredit ourselves. There's a lot of good stuff in functional programming languages that help you deal with actions.
00:51:06
Speaker
So one of the things that, I mean, this is like, let's say in the closure world, at least it's caused a bit of controversy recently with spec is this speech by Rich about speculative. I think maybe I don't remember the talk actually, but it's where he says that the optionality is a problem. And that's why we need spec too.
00:51:34
Speaker
We were joking earlier, by the way, that Speck started at the same time as Deafen. So it's kind of interesting with Speck about the same time that we're experimenting with podcasting. And they've got Speck too, and we've got Eric too. So maybe it's kind of... I'm out of alpha there. We've got him back.
00:52:00
Speaker
Right, yes. To make it better. We know what functioning is now. But what I meant was that, like, so is something like, because, you know, you say, you say it's like the optionality. How do you how do you know if things have worked or not? You know, that's the classic functional thing. There's like, you know, it's it's the option thing, the monad, you know, it's like it's something, it's nothing. So how do you how do you tackle that kind of thing in the book? Or is that a sort of
00:52:31
Speaker
version two or chapter three or whatever it is. So, um, I am going to get to that in part three, some, some form of data modeling. The problem is though, you know, to answer your question, the reason is hard to answer your question is that that is the furthest part of the book. That's the last part. And I haven't, it's optional.
00:52:54
Speaker
Yeah, it's maybe going to happen. No, I don't know what I'm going to say. Well, I don't know the specifics. To bring it back to simplicity, the thing about data modeling is that it makes your program simpler when you get the data model right.
00:53:17
Speaker
So if you have a correct data model, you have fewer if statements. And if statements are multiplicative of complexity. So if you have two if statements in a row, if you count the number of paths through those two if statements, it's two times two because it's two branches in the first if times two in the second if.
00:53:42
Speaker
And if you get your data model wrong, that means that you have to kind of reassemble, like figure out what you really have. So the example that you can give all the time is like, well, what if you have two Booleans?
00:54:04
Speaker
but you only have three possible states. Two Booleans can represent four states and you only have three. So here's an example. I used to work for a company and we had a workflow engine and something needed to be signed off by two people. So we would have a Boolean for the first person signed off and a Boolean for the second person signed off.
00:54:30
Speaker
But that doesn't really make sense because you could in your code with a bug put the second person has checked off and the first person hasn't checked off yet. That doesn't make sense. It shouldn't be representable. A better model would have been nobody has signed off or one person has signed off or two people have signed off.
00:54:57
Speaker
And that way, there was no fourth option that's not representable. Because if you have this, now you have to check. And so that's another statement, and it just multiplies your thing.
00:55:09
Speaker
I mean about I think Zach Telman's tweet or somebody retweeted Zach's tweet like every Boolean eventually becomes an enumeration. Right. Exactly. Yes. And they say the same thing in the Haskell world. You know, they say you're using a Boolean, but you might need
00:55:29
Speaker
And so what are you going to do, wrap it in a maybe? Yeah, it's one. And it's like, no, you need a new type. A common complaint in Haskell is everything you do requires a new type. About optionality, just for context, Racheke was talking about the maybe type.
00:55:54
Speaker
And how it didn't solve the problem that he wanted to solve, which was a program that will evolve over time. And if it evolves to where.
00:56:10
Speaker
An argument is not needed, but still acceptable. So it's optional now. In a language that would you, if you, if you use Haskell, you would need to now wrap that in a maybe, but that's a type change. And so that requires all the clients of your API to change.
00:56:33
Speaker
And there's various workarounds and I've talked to Haskell people and they say it's unfair. And I think that it's not unfair. He was complaining about this one type and that is a limitation of the type and we as an industry need to learn to accept
00:56:53
Speaker
limitations like that. It is a true statement. Whether there's workarounds in the language or not. He wasn't talking about Haskell is bad or anything like that. He was just saying, this one type has this limitation and we should recognize that.
00:57:08
Speaker
which I agree with completely. I don't know what else to say about it.
Data Modeling and Language Evolution
00:57:16
Speaker
I think that maybe is a good thing for modeling. If you do know what I want to say, you have a fixed domain that you're modeling and things don't evolve.
00:57:35
Speaker
but it has to be where the optionality is baked into the domain. Do you know what I'm saying? It's not where you're like discovering whether it's optional or this thing might evolve. And so you don't know whether you're gonna return it or not. It shouldn't be used for stuff like that. I think one of the problems, I think that maybe it's Haskell
00:58:02
Speaker
that people have got a point about is that a lot of closure programs are not monadic in this sort of Haskell-y sense. They're not optional. You've got these, like you were talking about earlier on about these data pipelines. And you can map this, filter that, do the other.
00:58:17
Speaker
And it's all great until suddenly you get an old pointer exception in the middle. And then you're fucked. Excuse my French. Might as well get a fuck out in the end. I know. It's been like over an hour. I don't know what happened. Usually it's like the first 30 seconds. Yeah, I think we were recording at that point when VJ got out. I told the magical words to open this podcast, yes.
00:58:48
Speaker
Yeah. So what I was going to say was that, you know, that's, that's kind of like that, you know, and I think people do get upset about that, you know, when they sometimes leave closure because of this evening, I get so upset that they get these no pointer exceptions and they're just like, they're going to fuck it more. Forget it. I just can't take it anymore. I can't take tracking down no pointer exceptions. Um,
00:59:11
Speaker
If I'm honest, I think closure is annoying in that respect as well, that it doesn't give you more context. I think this is a solvable problem by the compiler.
00:59:24
Speaker
But, you know, we always joke this about Apropos, you know, is that, you know, I think they once said that a closure is optimized for correct programs, but it's not optimized at all, in my opinion.
00:59:41
Speaker
I know the emails you're going to get. We don't listen to people's feedback at all. That's what we're trying to say actually. If we listen to people's feedback, we wouldn't still be doing this. Come on. Exactly. I think they told us after the first episode, what the fuck is this? Stop it.
01:00:03
Speaker
But now we are here after three years, 56 episodes. So, you know, we might as well get on with it. We will take guest requests, that's all. Anyway, so coming back to optionality, you know, I mean, you know, I think one of the nice things about this show is that we are able to just, you know, voice, you know, real talk, if you like, you know, then it's a problem with closure, in my opinion. It is.
01:00:31
Speaker
we might as well just put it on the table there. It's fixable, and I think they've acknowledged this, it's fixable with a development version of the compiler or some sub-optimal performance. You could fix this problem, but they don't do it for every, that's up to them. There are engineering efforts and costs and trade-offs and what gets first in the QS, et cetera, blah, blah, blah.
01:00:58
Speaker
But the point is it's not done, whereas in other programming languages, it is done. So you don't get this random null pointers in the middle of a pipeline. Sure. Or if it's in a language like Java where you still have a lot of null pointer exceptions, you're not doing some super high order operation.
01:01:18
Speaker
where you're looking at the stack trace, like, I don't know where my code is, and where the compilers, but the built-in map. You're doing a map except it's lazy, so null doesn't get you until later in your code. And the function that you pass is an anonymous function, so it doesn't have a name, it just has a number, and you're like, I don't know what function that is.
01:01:46
Speaker
But this is a problem in Haskell as well, right? The laziness adds additional complexity to this problem. Yeah, I mean, you don't have this exact problem because there's no null in the language. Yeah. And I think that that's another thing to tease apart. I had to do this myself. I was very confused. Haskell, it's not the type system.
01:02:08
Speaker
that is protecting you from null pointer exceptions. There just is no null. There's no value called null. Because they don't have a null, but they want to represent optionality, they have maybe and other stuff.
01:02:26
Speaker
So then the problem is the maybe brings back a lot of the issues with null. Like you might not have a null pointer exception, but if you have a nothing, you don't know where it came from. If they're chained together and you're using maybe as a monad, like somewhere in that chain,
01:02:50
Speaker
It became a nothing and then the rest was just skipped. And so it do have like these similar problems. You know, people will say, yeah, but at least you knew that that was a positive. Like I don't, I don't buy that. I knew every, every line of code I have could have no pointer exception. You know, I sympathize with closure programmers because like, especially new people, like I don't get them that much.
01:03:17
Speaker
And so it's one of these things like I've developed all these disciplines that I'm not even aware of anymore. It's always in the back of my mind, what happens if this returns null? Is it going to fall through? Is it going to do something? Is it going to do the right thing basically if a null happens?
01:03:40
Speaker
I find that the closure built-ins do the right thing. Sometimes they don't, right? So you can't always just check, the classic is I'm going to filter for identity, right? But what if there's Booleans in there and there's going to be some falses? So now you're mixing the nils and the falses, you're throwing them all out. So now you need to think, oh, no, I need to filter nils out. So nil question mark.
01:04:08
Speaker
or I guess you would remove nil question mark. So there's things like that, these little habits that I have that I don't even have them conscious enough to just list them. But I do have to say over time, you don't get them as much. You've got a nil sympathy.
01:04:28
Speaker
I mean, for me, it is not that much of a problem. I know you're just, but for me, it is not a problem that requires like, Oh, maybe I should go to another language. Like, it's just not that level. Yeah, yeah. It's a trade offs, right? Because the other advantages that you get with the mutability and the
01:04:52
Speaker
and the way that you can fluidly write code. I think it makes sense to have some, I mean, we are saying that Clojure has its flaws, but they're completely manageable. I think the difficulty with Eric's point of view though, and I agree with it, that you can develop certain habits. I think the difficulty of it is when you're in a team and you've got like five or six people all committing code and they haven't got those habits,
01:05:17
Speaker
And maybe you're not very disciplined in your PR process. Then you've got issues, you know, because then other people are like, they're not exactly breaking your code, but they're putting the possibility of nulls in there that you don't know about. And that's, you know, I mean, I know that you do a lot of work on your own, Eric, for books and for podcasts and stuff like that, but you also do consulting, so.
01:05:39
Speaker
I think a lot of us do work in teams of three, four, five people, and then it has to be named. You have to be able to do things in a certain way. That's true. I totally agree with that. And you want to be able to have, let's say, a junior new hire and fresh to closure contribute.
01:06:03
Speaker
And if you're just always worried that they're going to be introducing null pointer exceptions because it's so hard, they don't have all the disciplines yet. It's nice that our conclusion is that it's other people.
01:06:18
Speaker
I'm paraphrasing, of course, but you know, like, you know, what is the other people mostly? I'm fine. Fuck it, you know? Yeah, I mean, and who was it? It was, what's his name? The guy from id Software was giving that talk on functional programming for a while.
01:06:39
Speaker
He was learning Haskell and Scheme, and he said he really liked Scheme, but the reason he would do Haskell is John Carmack. Yeah, John Carmack, yeah, thanks. He was saying that with a sufficiently big team of developers, every bad habit is going to come out.
01:07:00
Speaker
Exactly. And so you want as much, you know, help, you know, this is the kind of company they're writing in C and C++, they buy those million dollar like bug finder packages, you know, that like do static analysis on your code and tell you, Oh, this for loop, like, it might, it has this one case where it might skip a, you know, and like go into an infinite loop, like, they, they,
01:07:27
Speaker
are investing in that. And so something like Haskell to them is much more like, well, let's give the programmers a little, let's put this closer to the programmers so they can solve their own problems, not catch it later. I have also heard really smart Haskellers say that the reason they like the type system is because they can be like,
01:07:56
Speaker
you know, a Kung Fu black belt level Haskell person and develop a type. So they invent a new type that's like a monad with stack. Like they make the type that they know is correct. And then at least they know that no one else can do harm.
01:08:21
Speaker
It's a way of multiplying their knowledge out because now it's in the code and the compiler is checking it. Even if they can't, they might not be able to figure out how to get their code to compile, at least they're not thinking they got something right and pushing it to production. I have to sympathize with that in the practical sense because I have been on teams like that where
01:08:52
Speaker
Most people were working at a very high level and then the juniors were not able to contribute because the stuff was just over their head. I mean, the stuff we were doing was like high level closure stuff. And every time they would contribute something and pull requests, the comments would be like, oh, this is going to crash in this case, in this case.
01:09:18
Speaker
And it was just too much. It was too much. We weren't getting anything good out of them. And, you know, it makes you think like, well, that's why everyone wants senior closure programmers. It's like... Yeah. Everybody, I think closure is seen in people's code or seen in people's programming language. And it almost sounds like, you know, you get to use after you're 65 and you get some discounts and shit.
01:09:44
Speaker
Even the stuff like an atom, a simple atom, the contract is pass swap a pure function and it'll be fine. That's it. It's not much to think about except what if you don't? I don't even know what happens if you don't. I always pass it a pure function. What if it does a def inside that function?
01:10:08
Speaker
Like what is going to happen is going to be called? I don't know. And that's, that's the kind of thing that people do when they're first learning closure. And that's, that's totally fine. It's just, you know, nothing's checking. But I think, I think that in this case, I think, you know, there are, there are sort of, uh, levels of, uh, checking that you can do, like, I think like the CLJ Condor stuff and the other bits and pieces that, you know, the, um, the linters.
01:10:35
Speaker
They're definitely pretty good. But like you say, there are certain interoperability things where nulls can creep in or certain use cases where a certain function will produce a null but other variants will not. They're very slippery. They're very difficult to encode necessarily because one isn't necessarily wrong. It's just wrong in a certain context. And people are used to languages that
01:11:07
Speaker
Um, well, okay. I have to say it's similar to JavaScript where there are parts of the language that are like no, no, don't use that. Um, and there's a lot of stuff that you kind of have to use cause it's, there's no other option. So you have to like become an expert at this, like what are all the ways that, you know, this can go wrong.
01:11:34
Speaker
What are all the ways that you can abuse the plus operator and get weird values out? You have to know this. You know, there's stuff like- Equals and equals equals and equals equals. Right, you have to use equals equals equals everywhere, not the double, double, double equals. I think that what we have and that I have internalized and don't,
01:12:00
Speaker
don't think it's that big a deal, but it probably is, is very similar to in JavaScript. Yeah. Yeah. So we still need discipline. Yes. Whereas in Haskell, um, I mean, you know, I guess you could say at least you don't have that. I would love to see though, a bridge between the, the untyped and the typed. I would love to see, um,
01:12:29
Speaker
I would love to see more experimentation in type systems. When Rachiki gave that talk, it was called Maybe Not if you want to look it up. One thing that I think got overlooked was he actually showed an example of a type system that did what he expected.
01:12:50
Speaker
So it was in Kotlin that in Kotlin you put a question mark after the type and it makes it an optional, which means it allows nulls. But it's checked by the compiler. So if you don't check for the null, then it'll complain to you. It won't compile. It won't break the clients. What's that? It won't break the clients. Right. If you add a question mark,
01:13:17
Speaker
It doesn't change the, uh, the, uh, the clients. They don't have to change any of their code because they were already passing it. It's, it's optional, but it's accepted. And so they're fine. And I think that, uh, what do I want to say? Like that kind of statement, even though he made it and it was very clear and there were slides about it.
01:13:40
Speaker
It just like people just totally overlook it, right? They want to focus on like, why are you bashing on Haskell? You know, Haskell is this and Haskell is that and it's good. It's like, I know the level of discourse we have is just so bad. And I want to see more of that. I want to see more.
01:14:00
Speaker
I guess developing type systems with practical use cases in mind. And I think that that Kotlin example is a great example of what I'm trying to say. It's like these people are writing a language for Java Interop. They know that there's going to be nulls everywhere.
01:14:19
Speaker
It's just the nature of Java and they need them. They need null sometimes. And so they developed a type system that had a very practical, like the type system itself has a notion of null. Whereas in Haskell, like I said, there's no null. And so they used, you could write maybe.
01:14:41
Speaker
You could write it yourself in Haskell. So it's not built in. Anyway, I'm rambling now, but I would like to see a bridge. I want Haskellers or type theorists to work in an untyped language and
01:15:04
Speaker
and see, Oh, I see it. It gives me this freedom that I didn't have in my type system that is actually really useful. How can I take this back? How can I make this safe? It's always a kind of, I mean, you know, we, we have like functional programming meetups and you know, we always, you know, we look at Haskell talks and Elm and stuff like this, but it always ends up boiling down to productivity versus correctness or like,
01:15:34
Speaker
You just want to be able to experiment with something. You want to be able to explore something. You can do that in Clojure very easily and JavaScript as well. But in other languages, more type languages like Scala and Haskell, there's a lot more formality around getting things right before you start programming, before you start playing with things or experimenting with things. And I think that's a very difficult
01:16:02
Speaker
what should we say, bridged across, you know? Yeah, I agree. I think that, so like Haskell, I mean, what if you had an unsafe Haskell? Like, what if you had an untyped Haskell? So you defined a semantics for what it's supposed to do.
01:16:28
Speaker
without the types. It just made it a dynamically typed language similar to Clojure. It's meant to be an experimental ground for compilers, so why not?
01:16:39
Speaker
Yeah, exactly. And so you just define, look, this is what it would do. Uh, and so now we don't have to, we could run it without checking the times. Now I know that the Haskell does have a thing where you can run it without checking. That's not what I'm talking about. I'm talking about like actually being at a REPL, being able to, to like construct Haskell, uh, you know, expressions, get some Jason from some random API that you know very little about.
01:17:08
Speaker
and start working with it. It's without knowing the types. You don't know the types yet. One thing that people bring up when I wrote an article a couple of years ago about how Haskell is difficult to work, it makes it hard to work with JSON because you need to fully type it before you can, and it's not,
01:17:34
Speaker
People say, well, how do you work with JSON where you don't know anything about it? And that's not the point. You do know a lot about it. It's just how difficult is that to express in the type system.
01:17:49
Speaker
I know that I work with say the WordPress API and it gives you JSON and it gives you sometimes like if there's what we might call a null, well sometimes it gives you false and sometimes it gives you an empty array. So it gives you null, false or empty array and these are all kind of equivalent. Well, how do you express that in Haskell?
01:18:14
Speaker
Like, this is the kind of thing that, you know, or it'll say, well, if we have this key, then this other thing is going to be of this type. But if we have this key, and it's a number, well, then this other thing is like, okay, we know a lot about it, we could express it in English, but how do we express that in the Haskell type system? That's the kind of thing that,
01:18:38
Speaker
that I think the bridge needs to happen on. I mean, I will say it like this. It's probably wrong. It's probably a generalization. But the people working on Haskell compiler extending the type system are academics.
Conclusion and Book Promotion
01:18:54
Speaker
They're probably not hitting WordPress API and stuff like that. So yeah.
01:19:02
Speaker
I think the solution is that don't use WordPress API. We can talk to you forever. You're going to have to come back in the third time. When the book is published, maybe. I hope not in two and a half years. Yeah, like one zero and it's out of alpha. We'll have you back. We can take that bet.
01:19:31
Speaker
I'm pretty sure you want me back next week, that's for sure. Yeah, for sure. So maybe I think it's a nice time to tell people where it can actually find the book. Now we finally get there, yes, okay. Yeah, so the book is called Grocking Simplicity. It's published at Manning. So if you're, you know, buying from, it's only available on manning.com right now.
01:19:57
Speaker
But if you go to lispcast.com slash GS for grokking simplicity, that'll take you right to the page. If you want 50% off, I have a code. It's TS simplicity. One word. Just when you check out, you can put that in. It'll give you 50% off.
01:20:18
Speaker
I think it'll also give you 50% off of everything. So if you want to buy a couple other books too. Is that a special definite offer? No, it's not a special offer. I mean, even if it was a special offer, like it would just be a different code. 50% off seems to be pretty common. So it is on the meet them. Yeah. So the first five chapters are out.
01:20:45
Speaker
I'm actually a little ahead. The Manning Early Access Program. Yeah, Manning Early Access Program. So if you buy it now, you'll get an email every time the new edition comes out. And so yeah, you'll get it all. And then you can even buy the print book now and you'll get the ebook
01:21:11
Speaker
So you'll get the updates as they come out. And then when it's finally printed, you know, just like, oh, look, I remember this. They're like, get it for Christmas for somebody, but you don't know when Christmas 2021. I think when you get the book, it's Christmas. Oh, there you go. I'm getting better at marketing.
01:21:37
Speaker
better sales person than me. Yeah. So go to lispcast.com slash G. Yes. For ghost art. Sorry. Rocking simplicity. Yeah. So that's where you can get the book. I think it's, wow, it's one and a half hour. I mean, time is just flying. I mean, we could, as Ray said, we could, we could talk for hours. I know Ray had all these topics built up, all these tough, tough questions.
01:22:03
Speaker
Yeah, I think that's what we ask here. Tough question. It's hard. Tough. Just a quick shout out to other things. So you do Apropo every now and then. So that's on Apropo YouTube channel. That's right.
01:22:25
Speaker
We'll put the link somewhere where you can see and, um, uh, where Ray tries to solve computer programs. Yeah, you can actually see it and then see how Eric and, um, Mike and who else is there already? Yeah, sorry. Yeah. So they can try to solve the problems. They try to solve the problems and then show you better closure code. And, uh, Erica, what is your podcast? Uh, lispcast.com slash podcast. It's called thoughts on functional programming.
01:22:55
Speaker
Yeah. So go and check out Thoughts on Functional Programming. I think eventually it'll be branded to Thoughts on Simplicity. So it's going to be there pretty soon. I hope.
01:23:10
Speaker
So that's it from us for this year. And it's been, I think, almost three years. And it's a nice, fantastic episode to wrap up our year with, with the repeat guest, Eric. Thank you for sharing all your time and all these amazing discussions. And hopefully somebody will pick up the idea of, you know, making Closure more Haskell-like or making Haskell more Closure-like. I've had that idea type system for Closure.
01:23:37
Speaker
But yeah, so who has the time? There is a time system for closure, but you know, yeah, these things are, these things have been trodden, the ground has been hoed before. So, you know, shout out to him.
01:23:57
Speaker
Yeah. Yeah. So that's it from us for episode number 56 and we'll be back in the new year 2020. You can have flying cars in Defin on 2020 for sure. Exactly. You can tune into it.
01:24:14
Speaker
Yes, I told him it's flying cars and flying cyber trucks and shit and whatnot. And yeah, and a big, big thank you for all our patrons and who have been helping us in covering the costs. And we look forward to your suggestions. If you have any complaints, just redirect to Dev Now and we'll be there to catch them. We'll definitely be hanging around in the void, yes.
01:24:44
Speaker
in an hour. Thank you. Thank you, Eric. You're welcome. Thank you. Merry Christmas and Happy New Year to everyone.
01:25:26
Speaker
Happy New Year and Merry Christmas!