This semester at Utah Valley University, I'm taking a class called "Analysis of Programming Languages" from Dr. Charles Knutson (check out his YouTube channel). He's by far the best professor I've had here so far while pursuing my CS degree. Part of what makes him so great for me is that he loves programming languages, which gave me more motivation to learn new things about Rust and report back after class to him about cool things I learned. Mostly because I finally had someone IRL who cares enough about programming languages to actually get the hype that I have for it.
He has also been really good at explaining paradigm concepts. I feel like I've known about these concepts to some degree, but in a way where I didn't think about it. These ideas were always just under the surface for me, like I'd heard of Object Oriented and Functional programming, but I didn't realize how deep those ideas ran. I also didn't know about how iterative programming is not directly a part of object oriented programming, but it's usually included. And, there were things I'd never heard about before, like logical programming (for example, with Prolog).
Because I've felt like he's so good at explaining things for me, I thought I'd share some of the things I've learned here.
Essentially what this means is that treating any language as the "one true religion" leads you to make poor decisions and be stuck in one way of doing things. It's like going into your toolbox and it only having dozens of flat-head screwdrivers because you figured out how to do everything you want to do with it, even when a hammer or wrench would be a significantly better choice.
This isn't to say that having a favorite language is bad. My favorite language to program in is Rust, but that doesn't mean I'm going to try and make everything in Rust when there is a language out there for the job that doesn't suck and is better suited to the use case.
One way Dr. K illustrated this is by showing the class a simple factorial program. In C, it works fine, it was a run of the mill factorial program. Then he showed us how to do it in SML, looked great, it was functional, and looked nice. Then he showed us how to calculate a factorial in Prolog. That language apparently isn't meant for that kind of program (at least the way he showed us). The takeaway for this was that just because you can do something in a language doesn't mean you should.
This was a really fun one that we talked about. Recursion is definitely a part of functional programming, and the best way I remember Dr. K explaining it is something like this:
Let's count the people in the class. Our function, which is me, goes to this desk and asks "How many people are in the class?" and they say, "Me plus everyone else" and then they turn around, and asks the next student the same question, and they get the same response. This will continue until the end, and then when the last person turns around, they'll see no one there.
everyone_elseevaluates to 0, so the last student comes back and answers "1 +
everyone_else= 0" which is 1. then it goes back up with each student replying to the next one up the line with "1 +
everyone_else" and we get the actual number of the students in the class.
Now, Functional programming isn't limited to this. It comes with other nice features, but it's more of a philosophy than it is a set of language features. It's more of the idea that everything is an expression. Pattern matching is usually an expression, recursion is a kind of expression. Basically, the things that go into your expression are things that need to be evaluated and solved more like a math problem than like an imperative program.
That's all I've got for now. Midterms are coming up soon, so I'll probably have more to share by the end of the semester. I definitely am not avoiding studying and homework by writing this.