Better to Ignore Me

So I ruffled some feathers recently by making a post about a specific language, but the points being made could really be applied to any programming language, team or contractor even. It’s important to separate our own bias, and knowledge, or lack thereof, from a given task or project at hand. I think that is what drove me to write the prior article about a dead language.

It wasn’t purely because I never formed some type of fondness for the specific language, although that would be true. It came from reading an article from a programmer that attributed his ability to provide a cheaper quote to one of his clients because of a specific language and specific features in it instead of the programmer simply being more familiar with the specific language. We can all fall into that trap, but we shouldn’t attribute that as being the primary reason for a quote’s price.

I’d rather see a contractor or IT person talk a little about a healthy community surrounding a language, as a reason for keeping costs low, than them talking about all the great and wonderful features that are built-in. A client doesn’t, and shouldn’t, care about the minutia of a language, specific features can easily be built into just about any language. The real question is can you easily, or reasonably, hire people that know, write and maintain code in that language already, it’s never a good idea to rely sole on one person, not me or anyone else. Nor is it a good idea to carelessly add another language to an already growing technology stack of languages.

Otherwise you may be looking at a constant cycle of always training your new hires to learn an esoteric langauge with limited reuse & if the client can’t afford a pair or team of devs then they’re shooting themselves in the foot even further by using an obscure language. Best way to avoid that is to not use an esoteric, dying or dead language in the first place. Reminds me of a famous quote from Steve Jobs that goes something like this.

The best line of code you’ll ever write is the line of code that you never had to.

In the same vein I’d say the best programming language(s) you could use are the ones people already, or generally, know. (Granted it’s always good to learn more languages, but at work you should want people focused on writing solutions rather than dealing with the additional complexities of learning a new language, writing a framework, library or lacking a large community.)

Another question would be would a person or persons you hire or work with be motivated to continue to write in that language for other clients, their own personal projects or business and hobbyist projects?

And there is absolutely nothing wrong with a programmer having a language preference, but clients should be made aware of opinionated choices over ones that consider and think more about the future of the client and not simply selling a solution without much thought about the sustainability of that solution. Sustainability comes from the ability of other people to read that language, modify it, modularly add new features into it with ease, good documentation, code that self documents even or even remove unneeded components as the application changes. Maybe by having a more stripped down language, that isn’t bloated or requiring a lot of overhead, you can even increase performance in multiple ways, and even create development environments easier to test code before it goes into production as well.

Perhaps the language itself, and the shrinking community surrounding it, did not deserve to have an article written about it. It really isn’t a blip on most websites that are dedicated to programmers either and I feel like I may have given it more action than it has seen in many months.

Another point to be made is that something relatively useless, or redundant, in the present isn’t an indictment against something as having never been useful or without purpose in the past. The idiom of hindsight is 20/20 isn’t applicable here, because at a language’s inception it is often times very useful and it fulfills a purpose for the author and those that use it and shape it. Reality is that most of the top fortune 100 companies are going to use multiple languages within their company, it’s not a particular endorsement of any given language even if 75% of them use a given language in some way some where.

Times do change and old waves die down and new waves form, you can be a surfer that likes to talk about his glory days of riding a once great wave, a tsunami even, but it is probably better to start riding new waves, of all sizes, and keep learning how to surf better than to become stagnate or to be pulled under by an undercurrent.

The best languages, & projects are the ones that are kept alive by an adequate number of people in relation to the scope & complexities of the language or project. Leaders can, or should, be able to come & go, but the general number of contributors don’t — they sustain it. Contributors also share the responsibilities & at times the burdens of maintaining & eliminating technical debt as well, whether it’s their own or someone else’s.

And I don’t really want to tell anyone to stop doing something just because of something being old or unpopular, that’s not a real measurement of something being useful or having value and it would even go against the points I have made. There are much older languages than the one I wrote about.. that also have more usefulness, value and possibly greater readability — it’s also not a simple a matter of popularity. Old or unpopular is not a measure of any of that, and whether you’re young, old, popular or not yourself you don’t want to be in the way of others coming onboard, collaborating, or being able to take over a project in the future. You need to treat others with the same level of respect that you hope that they will show to you, and that can be seen in how someone writes their code, and works with others. It can even extend to the language(s) & design patterns they may decide to use for a new project.

The only measures I’d use for whether a language is good, healthy and useful is based on accessibility, openness, and indications of mindfulness by the author(s) and those that shape it. It is these traits that attract developers and the kinds of people that will make a language strong and effective. Strong communities form around more than just abstract concepts written in computer code or clever programmers.

If you really want to be unique & to stand out then there are better ways to do it than purposely isolating yourself. On the upside though, if none of these arguments persuade you to think about languages any differently then you will have to learn to be creative. Limitations tend to force creativity & uncertainty whether you want it to or not.

This will probably be my last entry on this topic, otherwise I’d feel like I’d be beating a dead horse. I will likely write an article about Tribalism next though, & I’ll probably break it up in 2 or 3 parts (especially if I cover more than just programming).

If you have any thoughts, suggestions, think I went off the rails somewhere or feel like I simply rambled on too much then please let me know.