Can you always find a layer of meaning in which your problem is easier?
This is an episode of Thoughts on Functional Programming, a podcast by Eric Normand.
I've always found switching languages to be educational. I learn a lot. It always makes me wonder what I might learn from a non-existing language that I would bring back to my favorite languages.
Eric Normand: Can you always find a layer of meaning in which your problem is easier? In this episode, I want to talk about my experience with learning different languages. Not going to be really defining a term in this one. This is mostly going to be like a personal experience report, but it should be universal.
I feel like a lot of people would have this experience. Hi, my name is Eric Normand, and I help people thrive with functional programming. I've had and I think we've all had this experience of learning a new language where a problem we were trying to solve is way easier in that new language than the language we were using before.
Maybe that was just our side project, you're just experimenting, learning something new. You go back to your normal everyday language. You can actually take stuff back with you. You've learned this new thing and you learn, oh, if I only had this function that was in the standard library, I could do this work way easier.
That was really something that the language was giving me. A lot of it was just that Clojure has a great standard library. I could implement those things that I wanted. I did this a couple times, I now run my site is on WordPress. That's PHP. I often find that I can just think about what I want to do and I get this idea, oh, in Clojure, I would do this and it would be so easy.
Then I realized I could write that function myself in PHP and then I just always have access to it. I don't have to rely on what the language gives me, I can build on top of it. I have my own utility layer between what PHP gives me and what I use. It's pretty nice. It's not Clojure.
Some coding enclosure, I spend the weekend learning this new language. Maybe more than a weekend, I learned this new thing. Then on Monday I go back to Clojure. What pain would I feel? What would I want to bring back?
What functions can I implement that I always needed but I never realized it and will eliminate tons of code and bugs and stuff because this is a better abstraction for that thing that I'm doing. I do believe that there's always some better way of expressing the problem of solving or expressing the problem or expressing the solution.
There's a lot of people who haven't done that, who would probably have the same experience like "Where has this been my whole life?", "Why haven't I known about this?" because it could have saved me so much agony. I always think about this. I've had this experience so many times that there always must be something else out there.
Often, I think that it might be some new general-purpose thing. If you took some new constraint, the Clojure, a lot of what it's done is it said OK, if we only have immutable values and we're going to do a data-oriented language, what are the functions that we seem to keep running into that we need?
A lot of them are just borrowed from other languages, let's be honest. What if you took some other constraint, we're dealing a lot with strings and string manipulation? Let's say we have to do a lot of string munging. What do you get? You get something like Pearl, maybe a better language.
I don't know what your feelings at Pearl are but it has a lot of great operations for dealing with strings. Maybe that's something to pull back in. We don't need to be dealing with strings. It's just some basic operations, which I feel like we do in Clojure, we're just dealing with like, oh, we'll do concatenating strings and Regex matches and stuff.
That's about it. Not much more than that. But, man, there's some other cool stuff we could be doing that we haven't really looked into. I wonder about that. Where could we explore, to bring stuff back in so that our code is that much better, that we're able to work at the right level for the problem that we're solving.
There's always more out there. Even if we looked at every existing language and pulled all the good stuff in, there would still be some magical unicorn language out there that doesn't exist yet, that we could learn from. I think that's great. It's beautiful. That's one way to do it. The other way is to build it up, to build up the layers towards your problem.
You start solving your problem and you realize, oh, this is turning into a mess. Why is this so hard to do? You start refactoring and breaking things down to smaller bits and finding the layers where the things seem to not depend on each other, they only depending on stuff down below. It starts to stratify into these little layers.
Those layers become things you can build on top off and express your problem in a better way. I would love to hear your experiences with this. Whether you've learned a new language and brought stuff back to your main language, what kinds of stuff you brought back? What were the things that you really appreciated that you managed to write yourself or find some suitable replacement for?
I'd love to hear that. Then I'd also love to hear what you've done building up to your problem. You didn't look elsewhere and bring it back, but you built up and then took what you built and made it something really nice and useful. Love to hear both of those. If you want to share that with me, please email me. I'm firstname.lastname@example.org.
You can also find me on Twitter @EricNormand or find me on LinkedIn. If you liked this episode, or if you want to hear, I'll share some of the stories. Just to be clear, if you share it with me, I might share it on the podcast unless you tell me not to, obviously.
If you send me an email about this, I might share it. I might talk about it, I might say your name, so please tell me if you don't want me to. You should subscribe because then you will get to hear all these great stories. Awesome. I'm Eric Normand, thank you very much, I'll see you next time.