A Couple Tidbits From My New Favorite College Professor

Michael Harding — Tue, 01 Oct 2019 22:30:08 +0000

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.

"Language Partisans are Generally Bad"

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.

"Functional Programming is More Than Just Recursion"

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_else evaluates 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.

Conclusion

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.

How should I go about setting myself up for my "dream job" at Mozilla?

Michael Harding — Thu, 20 Jun 2019 17:46:02 +0000

Background/Lead Up

I've got about 1.5 years left at university, so I wouldn't be applying for a position for a bit anyways, but I figure it'd be better to prepare for my dream job now rather than when I graduate.

I've been doing some research about working at Mozilla, I've come across some hacker news and quora threads about it, that seems to confirm that working there could likely be a dream job of mine.

What I'm not sure about is how I need to go about planning for and getting the kind of job that I want. I'd love to work with either Firefox, Servo, or Rust directly, but I'm not sure which location to look for on the listings page or if it doesn't matter too much? It also seems that they're really good with remote work.

I'm working on getting my bachelor's degree in computer science right now, and have been considering going for my masters as well, especially if it'd help me get a foot in the door.

I'm trying to learn Rust in my free time, and so far it's my favorite language, which is one of the things that got me looking into Mozilla (and yes, I know there's other places that use Rust, but I really like the feeling of altruism that Mozilla puts off).

I've been chipping away at the Rust track on exercism.io, reading the documentation, and the book published by O'Reilly, as well as trying out a few personal projects with it.

Once I feel confident with the language, I've got some open source projects that I am keen on contributing to, like Smithay (see below), that look fun and would also give some stuff I can show my abilities with. I could probably also start trying to contribute to Firefox, Servo, and Rust to get more familiar with the projects and improve my skills.

Smithay / smithay

A smithy for rusty wayland compositors

Smithay

A smithy for rusty wayland compositors

Goals

Smithay aims to provide building blocks to create wayland compositors in Rust. While not being a full-blown compositor, it'll provide objects and interfaces implementing common functionalities that pretty much any compositor will need, in a generic fashion.

It supports the core Wayland protocols, the official protocol extensions, and some external extensions, such as those made by and for wlroots and KDE

Also:

Documented: Smithay strives to maintain a clear and detailed documentation of its API and its functionalities. Compiled documentations are available on docs.rs for released versions, and here for the master branch.
Safety: Smithay will target to be safe to use, because Rust.
Modularity: Smithay is not a framework, and will not be constraining. If there is a part you don't want to use, you should not be forced to use it.
High-level: You should be able to not…

View on GitHub

TL;DR

Working at Mozilla might be my "Dream Job" from what I've read on internet comments
Want to work on Firefox, Servo, or Rust itself (could probably start now since they're open source?)
I'm getting my bachelor's in CS soon, and maybe masters if it'd help, plus the classes look pretty fun
Learning Rust in free time and trying to get into contributing to OSS as well

Actual Questions

Do only certain offices work on the projects I want to do? (Like, is San Fransisco the main place for the projects I want to work on, or would it be likely that I could get in fresh out of college for a remote job on one of those projects?)
Is everything I'm doing/planning to do necessary for getting a job at Mozilla?
What else do I need to be doing?

DEV Community: Michael Harding

A Couple Tidbits From My New Favorite College Professor

"Language Partisans are Generally Bad"

"Functional Programming is More Than Just Recursion"

Conclusion

How should I go about setting myself up for my "dream job" at Mozilla?

Background/Lead Up

Smithay / smithay

A smithy for rusty wayland compositors

Smithay

Goals

TL;DR

Actual Questions