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.

Simple languages like Go enforce simple usage. I admit to being frustrated for having found no library for functionally manipulating collections, or just doing some basic stuff I’d gotten accustomed to in Scala, Javascript or even in PHP. Go, or others like it, might bore you. Looping through a list with a for loop seems so, well, beginner. Some things are verbose and ugly.

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.

constraints #

Constrains are often positive. Too many options cause paralysis of choice. Too much time allows for needless polishing or second guessing.

Best practices, agreements and common sense are all soft constraints, of sorts. Most technologies come with common rules on how to utilise them, as they have been tried, tested and proven sensible. Still, there are some who think they know better. One might come up with a perfect ruleset of their own. Nonstandard rules and habits, whether those are new coding style guides or a revolutionary way of utilising the bad parts of javascript, that shit is bound to generate confusion and raise the learning curve.

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.