Bridging the Temporal Chasm
So, it's clearly been awhile since I've written anything here. There are multiple reasons why this is the case. One of the main reasons is trying to determine in what direction this blog should go. Its primary goal was to serve as a portfolio, but honestly, I haven’t been coding that much in my spare time. This makes sense, given how much I code for work, and also, I’m sure both my eyes and joints are thankful for the fact that I try to limit my time in front of a screen. (I’d love to share what I’ve been working on at Kebotix, but that’s quite confidential…) Instead of being a “portfolio”, several articles, like the Wild Python series, served as both an excuse to get me to read more source code and as small tutorials into various programming topics. However, these articles, as well as many other programming tutorials, textbook and otherwise, have the issue that they go stale. This doesn’t matter as much for the Wild Python articles, but it very much matters for articles like the functional programming and image classification ones. Since this blog is fully static, and served on GitHub, there may be a way to build a CI/CD pipeline to fix this, but that would certainly be its own post. Also, there’s the question of whether a blog is even worth pursuing, or could I accomplish the same things in 360 characters or less?
I’m going to start out with a TL;DR of some of my favorite pieces of tech and new principles that I’ve been working with for the last year.
First things first: this article
In all of the journal articles, preprints, and blog posts I’ve read over the last year, this one certainly had the biggest influence on me. It’s called The Law of Leaky Abstractions. One of the most impressive things about this article is the way it applies to both computer science and chemistry (and any other field in which abstractions are used, which is basically everything). The other absolutely mind blowing thing, for those who don’t plan on clicking on the link, is when the article was written. I thought it had been written last year, until he started talking about Visual Basic and Internet Explorer internals. He makes some rather prophetic claims about the future of software, which have certainly come true. This has spurred me on to learn a language closer to Machine Code, which brings me to:
Go
I’m a big fan of the Unix Philosophy which can be approximated to
“Don’t let your feature scope creep up on you.” Go very much adopts this
principle, not trying to be everything to everyone, but fantastic for a
subset of applications for a subset of developers. This also makes the
language restrictive, which isn’t a bad thing, given that there’s
effectively only one way to write something out. No, there isn’t room
for brilliant & creative one-liners (or the BEAUTIFUL syntax and semantics offered by Scala, but it provides the monumental
benefit of the language easy to read (and thus, maintain). Though the
syntax is strange to me at times, its typing system isn’t as robust
as I would like it to be, and it’s a very WET language,
I’ve found myself reaching for it quite a bit. This is due in part
because it has an incredible build system that as a Python dev,
I’m quite jealous of. The process for deploying a CLI in Python was
lengthy enough to warrant its own blog post, but in Go, this
would have been as simple as go build . Spending a lot of time on
Linux does make me appreciate the value of simple installers that
don’t require SHA checking, cmake builds with lengthy log files and not
obtuse error messages, or having to deal with dependency management.
Tying this in with the last point, one of the major reasons I like Go so much is how “close to the metal” it is. Speed is a nice side effect of this, but it also means less leaky abstractions. The only thing that’s really abstracted away is the details of the compiler itself, as the central code base is so small. Python is nearly as fast as Go when Numpy or CUDA are used. but the internals and dependencies are so convoluted that you really can’t expect to know all the calls in your PyTorch stack. Outside of its major use case, networking, Go is particularly good at CLIs, installers, TUIs, and REST APIs. For smaller CLIs, I might instead reach for tiangolo’s Typer, for the following reason:
Choosing Tech
There are so many new libraries/languages/tools out there, that I used to be (and, to be honest, sometimes still are) prone to option paralysis. The way I’ve chosen tech has certainly changed over the years. Though I’m certainly an Innovator/Early Adopter in Chemistry, I tend to adopt new tech slightly later. This unsurprisingly also also correlates with my level of education in chemistry vs. computer science. But, my tendency to adopt near the end of a hype cycle is for the very practical reason of wanting more users to find the sharp edges of technologies before I choose to solve my own problems with them. But thankfully, programming isn't just a popularity contest, and isn't even the most important factor to me, which is DOCUMENTATION. Two years ago, when I decided I wanted to work with a tiling window manager, the most popular 'ricing' window manager was BSPWM which is...rather lacking in documentation, with seemingly half of it talking about the theory behind binary space partitioning. Compare this to the tried-and-true standby of i3, which has exceptionally clear and detailed documentation. I truly can't overstate the value of clear and detailed communication in software (and hell, in life!)
Closing thoughts
So I still don't have a clear direction for this website to go, so let's just settle on calling it a platform for self-expression, doubling as a mind-map of sorts. I've got several projects coming down the pipeline, so that should probably be expected before any other blog posts. One certainty is that the delay definitely won't be as long.
Until next time, & happy hacking!