The Problem with Popular Programming Languages

The Problem with Popular Programming Languages

Every year, technology publications make their annual list of the most popular programming. And we programmers jump into those articles in the hope that we have chosen the right language.

If our favorite language is in the top 2 or 3, then we feel proven and valid and feel that we are somewhat superior to those farmer developers who have clearly chosen the wrong language.

And Team Java or Team JavaScript or Python or whatever it is their own fault. We treat programming languages ​​like other sports teams. When your team wins, you win.

The problem is that popularity is a terrible measure of quality or efficiency. You are only making choices based on what everyone else is doing. Now take a minute to think about what the average person does in life.

The average person does not exercise as much as they should. The average person is ignorant of many things. The average person eats poorly.

The list goes on and on. And yet no one thinks they are below average. Why? Because the average is not good enough and the average below is even worse.

Now, imagine that you want to improve your fitness. How do you go about it? Would you consult a list of the most popular fitness activities to determine what level of fitness you should strive for?

Sitting on the sofa every day (48%)

Walks by car (23%)

Dog walks once a week (17%)

Lifting groceries (11%)

And then you ignore the items at the bottom of the list as not worth considering?

High-Intensity Interval Training (0.3%)

Running 3-4 or more times a week (0.2%)

Weight lifting (0.2%)

Yoga (0.2%)

Obviously, this strategy will be sub-optimal if your goal is to improve your fitness. So why should we take this approach when choosing a programming language?

You have to go where the job is

Unfortunately, most are slaves to the job market. First and foremost, we must eat programmers. So we learn the language where there is the most work. And a few of these top-programming lists can help us see which languages ​​will be needed for most tasks.

But let's not fool ourselves into thinking we've chosen the "best" language. We are not. For most of my career, I have chosen what will be the demand for a few years from now. I wanted to make sure I was going to be marketable in a few years.

And it certainly helped to put food on the table, but it wasn't the best. I've had a lot of trouble in my career writing code in object-oriented languages ​​before I decided to stop using legacy and ultimately object-oriented languages ​​together.

See my middle article Goodbye Object Oriented Programming to learn more about the problem of OO.

These languages ​​were all rage and what everyone else was doing made sense to work in these languages ​​so I could still get work.

This strategy works if all you want is to work. But I must admit that, in many ways, this is a terrible strategy. That strategy did not alleviate the pain and suffering of working in the flawed paradigm. But, unfortunately, for most of my career, I was not in a position to make decisions.

Someone else made this decision long before I was hired to work on their codebase. But what criteria did they use to make the decision? Most likely, it was the same as I was using - popularity.

Making Better Choice

Very few of us can decide which technology to use for the rest. Those of us who hold this important position has a heavy responsibility to choose wisely.

But we don't. Popularity is often the number one criterion we use. But why? There are many reasons, one of which is the old adage that no one was ever fired for choosing "<insert popular choice here>". It was originally coined by IBM and then Microsoft.

Another reason is that as a company, you want to be able to hire programmers who do not need training. Depending on the technology, programmers may need to train for 1 to 6 months.

Choosing to avoid this is a short-term thought because your company will probably survive for decades with your codebase. Making a bad choice today to avoid training people can cost your company unexpectedly year after year and in some cases decades.

See how many programs are still running that were written in COBOL. I suspect that anyone has guessed that this code will still be in production after 40 or 50 years.

Avoiding the cost of short-term training can turn into long-term costs that dwarf short-term costs. I have personally experienced the likes of others before me and the choices I have made.

At the moment, the decision seems right. You have a company full of X programmers and we can't choose the Y language because no one understands it. There will always be some developers among the staff who will learn it quickly. But what about the rest of the staff?

Also, when your code needs to be completed quickly, you do not have time to research the new language so that you can choose the right one, that is, the most productive and most suitable for the problem. And you don't have time for developers to train in this new language before you start coding.

You want to start coding them immediately. And sometimes it's a perfectly reasonable business decision, like when you have to go to market quickly and you plan to drop all the code from version 1, but it almost never happens.

Many times "temporary" code or a prototype is quickly converted into the final product. And now we curse the short-term decisions of the past and perpetuate that mess forever.

To make better decisions, we need to expand our standards. We can't just think here and now. We need to remember that every time we write a line of code, it becomes both an asset and a liability for the company.

We need to learn how to make the most of our resources so that we can maximize our resources and reduce our liabilities.

How to choose

Whatever you choose in life is based on your values. It is important to understand what you value to be able to make good choices in life and business.

Different businesses value different things. Hopefully, you've found an organization whose values ​​align with your own.

Many companies value short-term profits. There are stockholders and board members to meet them and future profits are a problem for another day and perhaps a concern for another person.

If you work for such companies - and I have - you will see that they quickly take out technical loans when they are shaking up to maximize profits and market value.

Typically, CEOs will push their top management to hell or high water to meet some trusted goals. The hell they're insulting you is the technical debt, a mountain of code that was hacked into the Red Bull-fuel competition for an artificial period of time.

Although this method can deliver products quickly, that code is not going away tomorrow. It will now go to the most expensive stage of life, maintenance. Don't be afraid, however, that the CEO's bonus was appropriate.

And long before the interest payments on those technical loans begin to reduce their quarterly profits, the CEO and his top dogs will use their stock options and either retire early or go somewhere else and create a similar mess in a whole new set. Developers

But as developers, we get no stock options or gold parachutes. We are stuck with the burden of messing up and keeping the software working. This is why it is so important to find companies that have the right value for long-term growth and survival.

Once you find such a company, the choice of technology and especially the languages ​​we use can make a huge difference. Although the language is not the only choice. Proper development methods must also be employed.

The best language on the planet can be derailed by poor development practices. As software developers, we also need to know the value.

But what is the correct value? If you work in software for any length, I doubt you can answer this question quite well.

  1. Here is a list of some of the key values ​​for programming languages ​​that we should keep sacred:
  2. The language must reduce the boilerplate
  3. There must be a strong abstraction of language to reduce the effort of the programmer
  4. Language should be strong at runtime
  5. Language should have a mature ecosystem

The compiler will help developers catch errors as quickly as possible

This list is just the tip of the iceberg, but it's useful to help us think about what features we value when choosing a language to program.

Notice how "programs in what we know" are not on this list. Because it is not so important and since the industry is still in its infancy and we are still learning what works and what doesn't, there is no specific language choice for a particular problem set.

Not too long ago, we had a go-to in the codebase, which was not as frowning as it is today. And in most modern languages, it's not even supported. This is not to say that compilers are not creating code that uses go-to's, it's just that we humans don't trust them.

And that's a good thing. Removing dangerous features from a language always makes and will make better software

If you're only interested in the languages ​​you know, you're going to miss out on the new things we've learned from millions of programming man-hours each year.

Think about what we've learned since we first wrote those COBOL programs. None of the companies that rely on them have yet benefited from the technological advances we have seen in language development over the last 30 to 40 years.

Language lessons

  • What have we learned over the decades?
  • Here is a short list:
  • Makes Go-tos code understandable (spaghetti code)
  • Code should be modular (separation concern)
  • Boilerplate code bad (dry and refactoring)
  • Makes global variable code fragile, especially multi-threaded code
  • Higher than automatic memory management manual (garbage collection)
  • Unchanging data and pure function make programs rational and powerful
  • Static typing builds more powerful production software (fails quickly and quickly)
  • Nulls are a burden and a feature of a fragile language
  • Safe than recursive function for the loop
  • Function composition is the ultimate recycling (reuse)

While it is true that any language you choose can work, since they are all Turing Complete, the language programmer you choose determines the cost of hours. It determines the firmness and quality of the final product.

I have worked in companies where the software has never been used. There are two reasons for this. One is that we always add new features and to some extent, it is not bad if it is done well. Another reason is that software is as fragile as hell and a team of developers is needed to keep it alive.

I've worked in both situations and I can tell you that constantly trying to fix brittle software is like trying to draw a house of cards. No matter how careful you are, it is only a matter of time before the whole structure collapses.

So far, all of these lists have not been honored as a single language winner, and for good reason. There are lots of really good winners out there who are designed to include many, if not all, of what the industry has learned over the last 20 to 30 years.

But there is a big aspect of language that we have not yet considered and that is the parable.

Not all instances are created equal

How we think is important not only in programming but also in life. Once we are given a new perspective, it can completely change our thinking and, therefore, how we interpret our world.

Many programmers learn a single instance and then immediately stop looking for others, defending them religiously. It just destroys them to get stuck in the past.

New ways of thinking are not always panned out. The best way, however, is to do. But how do you know the difference? Usually, only time can tell. Then how do we make the best decision when we are faced with a new paradigm?

An example is a model and all the models we encounter in math and science, we judge them by how well they map the problems they are trying to solve.

The Object-Oriented Paradigm has tried to model the real world and it is my opinion that it is this approach that fails miserably for programming.

We model much more programming than real-world objects. This is a fraction of what we do but it is so widespread in OO that it does it at a higher price than everything else.

All we need is a model of calculation and reasoning. And with that model, we should be able to model the original world. And we need a model that is time practical.

The instance that ticks all the boxes in our value list and time is tested is effective programming. Contrary to past examples, it is at the core of mathematics that has been around for decades and hundreds of years.

The biggest problem with this illustration is the four-letter word (or five-letter depending on the country you live in), Math.

Many people hate math and many programmers think they are not good at math. I would argue that if you're a programmer and you think you're not good at math, then you don't know what math is.

What we do all day is math. We don't think of it as math. But mathematical thinking is exactly the same. Unfortunately, most of us remember our struggles in the "math" class and mistakenly assume that we are bad at math.

It is true that the kind of "math" we did in math class was done by most people for terrible and reasonable reasons, we are not calculators. I can't speak for another country, but here in A's good USA, we still teach "math" as if we were going to build a bunch of human computers ready for the 1960's job market.

Many years are wasted in math class to do worldly calculations and very little time is spent on mathematical thinking. But if you are a programmer, you have somehow acquired this skill and this is what you need.

Sure the roots of functional programming lie in math and if you like math you can definitely dive deeper into those areas. But a deep dive is not a necessity.

If you've made it so far in the article, you might think that the necessary programming languages ​​have become as complete as functional languages, and you're right. But they have vastly different perspectives.

The skeptical reader may be wary of this new intricate parable, but the truth is that this parable goes far beyond what we use today. You may be wondering if this is so great then why we are all still using the necessary illustrations and not the effective ones.

Okay, I suspect there are a few reasons for that. First, the necessary thinking is more normal for people. Survival in the African plains did not require much mathematical thinking, but much needed thinking skills.

It allows us to simply perform complex tasks and solve complex problems. And by complex, I mean a multi-step process for obtaining food, such as finding a long, straight stick, removing the leaf, sharpening the end, throw the food.

This step-by-step process is both easy to learn and teach. This is our normal thinking. But as our world has grown more complex, sophisticated ways of thinking have become much more useful. But evolution is much slower than technology so we must learn what is unnatural for most of us.

Another big reason is that functional programming took so long to get started that the math was done long before it could keep up with the hardware. LISP was one of the earliest working languages ​​(although it had the necessary features). In the early days, the hardware could not hold on and so they had to make special hardware to run efficiently.

But as hardware has become more powerful and software maintenance more complex and expensive, the adoption of effective programming is growing faster and faster.

In fact, you can find functional features in almost all popular languages. Structural programming was a new paradigm (which we now accept) very similar to what we saw years ago.

All non-structural languages ​​began to take on structural programming features. This happened with Object-Oriented. Remember C with the class?

This is a time when a new paradigm is about to change

Post a Comment

Thanks for your comment

Previous Post Next Post