May 15, 2021

Choosing technologies

When considering technology a variety of input and contexts has to be taken into account. This list is by no means exhaustive, but it should capture the essential ones.

Reach

How far does the technology reach? Frontend, backend, industries, etc.

Popularity / acceptance

A dangerous criteria, but cannot be ignored. Popularity can be a fad. It can be technology that works really well and has a reputation for it. It can be old technology that used to be popular, but is on its way out.

In contrast unpopular technology can be unpopular because it’s bad, because it’s unfamiliar, because it’s not the current fad.

Power / expressiveness

Languages differ in capabilities. This is normally expressed as a quality called expressiveness. High expressiveness allows for very little code to handle a lot of complexity in the working domain in a clear and concise manner. In contrast low expressiveness makes it necessary to do more steps to calculate the same result as the more expressive language.

Both cases can be by design, as the more expressive a language is, the more dangerous it becomes in the hands of an unskilled user. Reversely a low expression language can put in a lot of guardrails to disallow certain features deemed dangerous to allow programmers to do.

Ecosystem

What does the ecosystem look like? Stability, availability, infrastructure, etc.

Ease/mastery

Languages differ in ease to learn and how difficult it is to master them. This is correlated with expressiveness. The more expressive, the more it tends to fall towards harder to learn, by virtue of that you can do more (sometimes much more) than a less expressive language.

Productivity

When mastery in a language has been achieved, how productive is a programmer in the language? How productive compared to another language?

Churn

How often do things change in the broader ecosystem? The higher the churn, the more breaks and backward incompatible changes.

Stewardship

Who is in control of the language? Do they make good decisions? Are they good architects? How do they treat backwards compatibility? How clean are the designs? What philosophy do they have?

Once a design has been shipped, it becomes extremely expensive to change it.

Design flaws

Not often considered, but one of high importance. Languages update over time, but certain design decisions cannot be reversed without serious peril. One example is the jump from python 2.x to 3.x which broke backwards compatibility in order to fix one fairly serious design flaw. It ended up being a 10+ year period with incompatible libraries as the community very slowly shifted from the 2.x branch to the 3.x branch.

What typically happens is that you live with the flaws, and learn to ignore them or work around them. It is now a cost you pay every time you use the technology.

Tags: programming