Rust + Machine Learning: 008
This is part of my participation in the #100DaysOfCode challenge. This round, I’m learning Rust and Machine Learning (ML) and developing violette: a portable ML system and JavaScript API in Rust.
In conversation with a fellow developer, we spent time catching each other up on the various projects we’re working on, and I described the arc I’m taking in this Rust + Machine Learning (ML) challenge. He asked an interesting question, paraphrased here: “how do you refrain from getting caught up in the underlying theory and still move forward with building?”
It was a great question, and one I’ve often considered when taking a deep dive into anything. There’s a curious balance that needs to be found between theory and practice in any discipline. In some cases, an absolutely solid foundation in the theory needs to be established prior to anything practical taking place. You obviously want your surgeon to know what they’re doing at a high level of knowledge before they operate on you. You want to understand good squat form before putting a weighted bar on your back.
Other things can take a more hands-on approach, taking in theory with practice. In basketball, learning to shoot from the free-throw line. In writing, learning to work from an outline.
In the case of ML, I think finding this balance between theory and practice is predicated on the end goal. If you’re using AI to draft an outline for an article or marketing plan, you don’t need to know anything about linear regression — it’s all practical knowledge you’ll need on how to use the tools. If, however, you want to design a system by which you’ll train ML models, you’ll need to have more than just a cursory understanding of the methods underlying the tooling to create that system. If you are unable to verify that the tools you use will not introduce bias, either the tooling is written poorly, or you lack the knowledge to recognize whether or not the tooling is written well.
Unfortunately, it isn’t enough to simply trust the tooling and hope for the best. While lots of software is developed in this fashion — a whole lot of trust on a whole lot of independently developed packages — this doesn’t mean that this is great way to develop software.
Can a million people be wrong about anything?
Yes.
If you don’t know what you’re introducing into your codebase/concept/software, it may not be a good idea to introduce it. This is one of the benefits of Open Source Software (OSS): the ability to review and verify what exists in OSS packages. And this is where the importance of having more than a cursory understanding of the underlying methods in use by a piece of software is important: if you can read and verify what’s in use, you can make better decisions about what to implement.
Knowledge is power. In the case of software development, knowledge can make the difference in the extended outcomes of a piece of software. Especially, I argue, in the case of ML and artificial intelligence. And so, with regard to the question posed by my colleague, my point of departure was recognizing that I needed to deepen my knowledge on linear algebra and probability in order to follow along with a text that would get me to my intended goal; my point of return will be when I recognize I have sufficient knowledge to comfortably follow along with said text.
Day eight was spent continuing through chapter one of Introduction to Probability. While the concepts are challenging, I’m able to follow along comfortably enough, and it is my expectation that I’ll be able to complete this text without too much trouble. Future work includes diving into linear algebra, and for that, I think I’ll be breaking out my Calculus and Differential Equations textbooks to brush up on the knowledge in order to continue moving forward.
008/100
Read day seven here.
