golang and positive constraints
I wrote a smallish program in Go around a year ago. Today, a colleague shared this article, and inspired by it, I went back and had a look at my now old project. The simplicity of it was surprising.
an argument for any language
One can write good or bad software on any available language. Some languages are easier to adopt and master, some more performant, some academic, others like a double clawed hammer. Though the argument is valid, having no constraints might provoke showing off, or what we’ve come to call technological masturbation. Tinkering with some arcane and awesome features of a language rarely produce much value for the customer or the users.
But then again, it gets the job done, is fast, understandable and thus easier to debug. Go doesn’t compile with unused variables or imports, and in general prohibits bad practices. I’ve merely tried it out, an am unaware of most of it’s pros and cons, just as I’m oblivious with similar features on other languages. The more complex languages have their use cases, and finding the best fit is obviously important.
Constrains are often positive. Too many options cause paralysis of choice. Too much time allows for needless polishing or second guessing.
Forced constraints, those that one cannot dismiss or overrule, are a blessing against laziness, tiredness and boredom. The less possibilities for embarking on that badly written software, the better. The more features enforcing good practices, the better.
The desire to learn often drive a developer into uncharted territories. Those territories are ridiculous in their vastness and often contain unfinished or broken solutions. While they are great for learning and personal development, the constraints in there are unknown or hard to define, and the best practices non-existent.
The benefits of constraints are numerous outside the realm of technical choices. When working on anything, concentrating on one thing at a time achieves the best results. On a wider scale, the number of interests we have at a time, affects our ability to apply focus and restraint. The less stuff, the less mental scatter. I’s a balancing act between single purpose obsession and multi-purpose dilution.
Constraints form habits, and habits create routines and predictability. When maintaining a software, surprises are unwelcome. When reading software code, familiarity is encouraging.