As a rule, I do not try to make it my business what tools other people are using to accomplish their goals. If you want to use Emacs, that's fine by me. IntelliJ's refactor tools a lifesaver? Have at it.
I am not, for example, opposed to the usage of tools like Github Copilot that have a strong element of human direction where users find them appropriate.
However, there is a line where I think things do require comment.
If we are to be engineers, and we ought, then that comes with an obligation to ensure that our work in producing software is undertaken in a socially responsible way.
Consequently, if a tool cannot be used in a socially responsible way, we have an obligation to point that out.
It's my suspicion that the current style of "vibe coding" and the tools that back them, in the current social context, are difficult to use responsibly.
Something I have left purposefully under-specified in my previous posts is that most of those abstractions obey laws.
Those laws are important features of those abstractions — they specify the conditions for validity of an implementation.
In general, we would like to be able to test for any of our implementations that the laws do hold. Doing so would give us confidence in the validity and relaibility of our implementations.
In order to do so, we'll have to implement several typeclasses, and I'll show you how that can be done in detail. In that respect, you can also see this post as a sequel to my post on cats imports and typeclass structure.
Sometimes I don't have a fully fleshed out design, or even really an idea, but just an intention to explore a space. I often find that writing is an okay way to start to think out those ideas, even if they don't obviously go to something shippable.
This is one of those. You shouldn't really expect everything here to be fully worked out or confirmed to be working, this is more a gesture in a direction and an attempt to connect some ideas together.
Eventually, I want to try and think about one way you might model a phenemonen using an abstraction called a comonad, but to do that we have to get to a place where we can talk about that concept.
You can find a summary of my experiences in the workplace below, going back all the way to my teens.
Feel free to disregard what doesn't interest you.
A common thing in software engineering is to fallback through a series of outcomes depending on a condition. This blog post aims to discuss some different ways to express this in Scala, and maybe suggest some forms of expression not all Scala programmers have thought about.
cats is, if you haven't heard of it, a popular library for providing various basic abstractions for typed functional programming in Scala. Many of these abstractions provide powerful primitives for expressing yourself in a more declarative and abstract way.
Unfortunately, new users often find it difficult to know how to gain access to the appropriate primitives for their situation, even after they begin to understand what typeclass provides those primitives.
I have a friend, an experienced Scala software engineer, who still to this day asks me how I know an incantation when I need something from cats. "How did I memorize all these?", he will say.
The answer, like most such tricks, is that I didn't. I am constitutionally incapable of internalizing raw, heterogeneous information like that.
What I did do is internalize a rule, a rule that lets me reliably find the import I need — a rule this blog post will try to explain to you.
If you see the rule and don't understand it then in the following section I'll provide a discussion of typeclasses and their components in the cats encoding in Scala. After that we'll revisit the rule with our new knowledge, hopefully making it even easier to internalize and apply freely.