Every field of human activity has its unique characteristics, and programming is no exception.
One of the unique aspects of software is how it spans such a large number of orders of magnitude. A software engineer may be slicing and dicing nanoseconds, or they may be trying to accelerate a computation that will run across thousands of cores for a month… and they may even be doing both at the same time!
This is a lengthy post explaining my reasoning for certain decisions we’re making in the Go subreddit. It is posted primarily to share with other moderators of all sorts of content as we all struggle through the implications of AI. If anyone else gets any benefit from this, that’s a bonus. For anyone else uninterested in that, you know where the back button is.
When I agreed to be a moderator on the Go subreddit a couple of years back, I didn’t expect to be on the frontlines of dealing with AI’s impact on human online communities. My brain doesn’t do chronologies very well, so I don’t recall if it was entirely before ChatGPT was a thing, but if it was a thing, it was back when its programming abilities were laughable. There was a time not so long ago when one could ask ChatGPT to code something, and you could see that there was some promise there, but at the same time, it tended to have difficulty putting out so much as a single line of syntactically-correct code, let alone code that did what you wanted.
As it stands today, consciousness is a black box of mystery. We don’t know how to define it, we don’t know how to measure it, we don’t have any terminology for it, we comprehensively lack any framework for dealing with it. We operate on “we know it when we see it” standards, and if you go down the P-zombie line of thinking, you may be reduced to “we know it when we experience it”.
In my previous post, Layered Design in Go, I discussed a procedure that can be used in any Go module to order the packages in an order of what depends on what, starting with the modules on the bottom that have no internal dependencies, then the modules that only depend on those, and then so on.
Conceptually it’s a useful way to think about Go modules, and any other system that similarly forbids circular imports.
This post will describe how I design my programs in Go. I needed this for work, and while I searched for a link, nothing quite fits my coding practices out there. The word “Layered” can pull up some fairly close descriptions, but I want to lay out what I do.
Go has a rule that I believe is underappreciated in its utility and whose implications are often not fully grasped, which is: Packages may not circularly reference each other. It is strictly forbidden. A compile error.
As many others observe as well, one of the major reasons to write is to firm up ideas in one’s own head. Serializing an idea out into English words is still no guarantee one understands it deeply, but it is great progress over a very fuzzy idea that has never been fleshed out at all.
I’ve known for a long time I wanted to sit down and write this out. But I had no idea how many principles I’ve either drawn out from my times with functional languages, or had sharpened by them forcing me on to certain paths that perhaps I would have walked eventually, in bits and pieces, but functional programming forced upon me in toto.
I am reliably informed by many people that the core essense of
functional programming is the extensive use of map, filter, and
reduce, that these functions are superior to for loops in every
way, to a degree that they should be jammed in to every possible
language with no need to analyze the cost/benefits of such an approach
because the benefits are just so incomparably amazing that the costs
couldn’t possibly be relevant, and even wondering about the costs
just proves I Don’t Get It.
Up to this point I have not followed through on my promise to offend everyone in general, and in particular, functional-programming-in-imperative-languages advocates. Everything’s been pretty positive about functional programming.
This is where the tide is going to start to turn, but I’m going to lead into it a bit before getting really offensive.
Let’s talk about monads, and in particular, monads in their capacity as “programmable semi-colons”.
If you understand why monads are “programmable semicolons” it’s a reasonably good sign you have a good understanding of them. I don’t think it’s the best way to understand them from the beginning, but it’s a good development of an initial understanding. I am not jamming a full monad tutorial in here when I’ve already got one (see prior link), so I’m just going to assume that you’ve read that and conclude with why this makes sense.
Functional programming languages see types not just as buckets of things that can contain values, but as assertions, e.g., this is not just a string that I vaguely hope is a Username, but this is a validated, certain-to-exist Username for a user, and anything that receives an input parameter to some function that is a Username need not run its own validation code on the Username to ensure it is valid, and thus also doesn’t need an error path for invalid Usernames..
At the beginning of this series, I said I was going to annoy every programmer in the world in some way or other. So hang on, here comes one of those super hot takes that I was promising:
Global variables… are bad.
Alright, for those of you who were not so offended that you instantly snapped your browser window shut, obviously I am aware that this is not news. The higher-skill end of the programming world was well aware that global variables are dangerous since before functional programming1 was even conceived of. Therefore, clearly, it is completely possible to figure out even in a purely-imperative world that they are a bad idea.