Functional Reactions

Currently reading The Three Body Problem by FIXME. Not a song, but an amazing sci-fi book I highly recommend! Definitely a “makes you think” book, but perhaps focused on science/engineering a bit heavily. If you have the background though, can't recommend enough!

Forced post numero dos! Hopefully soon we'll get to a point where I won't have to keep typing that, as instead I'll naturally just want to post. If you asked me a year ago, I would've said that point would never come. However, I've found out that it only took me 4 months or so of regular gym visits to enforce the habit. That was three times a week, here we're sitting lonely at twice a week. Linearly scaling, that implies I'll need six months to not make this feel so awkward? While it's a large number, it makes sense. I need enough content on this damned site such that adding one more little spec shouldn't matter.

Maybe I'll make a couple posts that I'm particularly proud of and sticky them to the front page. That would remove the current apprehension I have with updating the blog. I'm afraid I won't update it again for some time, which in return means that post which I did NAHT love will stick on the front page - scary! If I sticky a few and leave the rest behind a Read More link, that would isolate at least. I know that no one really clicks on anything besides /, /pdf/resume.pdf and whatever the first post is. Thanks Google Analytics… although I can't really complain. I have non-zero traffic without any real networking attempts (I never share these on social media). Most of the hits are almost certainly from career fairs or other applicants searching around I'm guessing¹. Maybe once Astranis picks up a few more people and a bigger website that'll die down.

Let's just talk about what I'm working on most recently. It's a work side-project, so I can't give too many details. It's just an internal tool to help with issue tracking things. There's nothing quite like it out there, so why not roll your own in your spare time²? I was curious about doing things the “right” or “modern” way with respect to front-end engineering, and it seemed like ReactJS is the popular thing, so there went nothing (that seems remarkably awkward in the past tense - will research after writing block).

Modern Javascript is super weird but also super cool now - I've only dabbled in plain JS and some jQuery, so seeing the crazy stuff that ES6 has going is super neat. It really does make the language feel more organized and usable compared to just stuffing a bunch of random vars inside a <script> tag. That's mostly just all syntax though - nothing too crazy. The thing I want to talk about is functional programming with React. I'm not going to claim to really understand this, and feel free to dispute all my points, but I really like it. The main idea, as I understand it, is to minimize interactions with the state of your program.

What does that really mean? More simply put, whenever you do_something(), you should get the same result, no matter what or where or why. There shouldn't be any external factors influencing what you're doing. There's lots of other stuff built into that (you end up using lots of maps and recursion to remove simple things like for loops) but that's all the base idea is. This is just a style of programming really, but there are definitely languages where the style is moreso the rule of law. React is a “soft” functional language, where you can edit the state whenever you want, but they make it kind of awkward and very deliberate. This really has changed the way I think about programming and sofware design. It's been a light corruption - only a couple of weeks now - but it's definitely growing. Why do I think this is so cool? Because practically always, relying on external state is a hack³ because I organized things poorly.

One thing I've worked on quite a bit at my various internships is bench test automation. You want to test some electronic design, be it an IC or a PCB or whatever, so you get a lab bench and fill it with all your good equipment. Oscilloscopes, multimeters, power supplies, you name it. In the past, you'd have to slowly tune all your inputs and carefully watch your outputs to make sure nothing went wrong. Nowadays, all that is scripted from some kind of [usually in-house, or worse, NI-based⁴] software program. The biggest pain point in my internships was learning how that software worked. Why? Because it had state! You'd do naive setup() procedure, and sometimes it would work, and sometimes it wouldn't! Why didn't it work? Oh, you forgot to call config() before setup(), except in RandomTestCasePhi, which needs a special call order of phi_config(); config; setup(); to make it work.

Avoiding this ordering hell is a personal goal of mine, and I think I'm doing an OK job at work. Of course, it's not purely functional (sorry to disappoint). Even I'm not sure how to get around the basic setup of

conn = connect(port)
conn.do_thing()
conn.close()

If I flip this program around to instead look like:

conn.close()
conn.do_thing()
conn = connect(port)

it pretty clearly makes no sense. Here, there's some implied internal state that keeps track of whether or not we're connected. Maybe a better way of rephrasing this would be to say I want to minimize the state size. I could very easily imagine passing not just port, but maybe instr_name, instr_type, output_cnt, speed, etc. There's some many little things that can add up really quickly, and then you have to carefully read through a few files⁵ to even figure out how it all works!

Enough ranting for now - it's just a job after all. Hopefully the next update will be about my DayN insights with the Rust language - that's next up on my plate.