Mastodon Icon GitHub Icon LinkedIn Icon RSS Icon

The most promising languages of 2015 - Part 1

UPDATE: There is a new version of this article for 2016!

At the very beginning of a new year, it is customary to try to predict what will happen in the future. That is the selling point of each big astrology book which pollute bookstores and newsstands in this part of the year.

Personally I’m not a fortune teller, but I think that can be interesting to try to set the route of the new year on the basis of the one just past. Obviously, I do not pretend to talk on every possible kind of events, but for the one I’m interested in, I think I can say something interesting or, at least, start a discussion.

So, let’s try to spend some words on the trends regarding programming languages and software development.

Trends

Before to talk about the emerging and promising programming languages you have to take a look in the next year, let's talk about the underlying changes in the programming community. First, you have to keep in mind that I'm talking about the programming enthusiast community, not the real world industry. In fact, the industry has other target than the yearly trends and so business solid languages such as Java, C and C++ will be on the top of the chart still for several years. Therefore, if your only goal is to get a job, you can stick on those languages, but if you want to enlarge your programming experience, well, you really have to take a look in these new languages. :)

The falling of Object Oriented Programming

The falling of OOP is not new. The first cracks on the walls of the industrial-standard solution-of-every-problem paradigm date back to 2009. There are several articles that criticize the OOP paradigm that we can summarize in the following points:
  • Inheritance vs. Composition. The first flaw is the inheritance. Critics say that real world problems are usually best suited for composition rather than inheritance. This is not true in general but there is no doubt that several developers can feel the inheritance chains around their neck for large, complex and mutable softwares (such as games). However, inheritance is not so easy to understand, can lead to overly complex and hard to refactor hierarchies. This is why many architecture are focused on composition. But then why we have to rely on languages based on hierarchy?
  • Bad modeling. This can seem strange for a paradigm born to be the definitive modeling tool. However is common to find developer asses that the OO paradigm provide an overly simplistic models of the real world. In particular, OO is not able to model time properly, a features that is increasingly important for multi-threading and parallel softwares.
  • Ambiguous Responsibility. In many cases is not clear who has to be responsible for a method. For instance , the method join (that joins a list with a string, e.g., [1,2,3].join(",") returns "1,2,3") have to belong to the string object or the list object?
  • Bad Modularity. Yes. Another paradox. But many developers say that OOP is not good in modularity as OOP claims. In other word, it is "intrinsically less efficient" both in modularity than in compiling time (source).
And more critics can be found searching on the web.

The raising of functional programming

Functional programming is old as the computer science itself. It cyclically rise from the academic world into production and back to hell. Nowadays, it is rising again. In fact, functional programming seems to be the solution to all the previous issues.
  • Immutable as default. In functional programming every data structures and variables are immutable. This means that cannot be changed during the software life. Once we have created a person with a certain age, we cannot increase the person age, rather we have to create a new person with the new age. Also if this seems as an catastrophic performance flaw, functional programming compiler are very good in optimizing the final code. Moreover, immutability has enormous benefits in multi-threading and parallel programming. Also non pure functional programming languages are starting to add new tools to work with immutable variables or with compile time evaluation. Side-effect can be very bad, and we want to avoid them as much as possible
  • No objects, only types. In functional programming languages, and functional inspired languages, there are no objects. Only types (also known as traits or interfaces or dataclasses). Types works conceptually as composition: a single data collection can belong to more than one type and we can invoke on that every function that is designed to accept a particular type.
There are many other benefits for functional programming but, in my opinion, the real advantages over OOP is that functional programming works way much better on concurrency and they are way more easy to maintain.

Static Compiled Languages

Another big trend is the comeback of statically typed compiled languages. We have (finally) passed the years in which every new language was a python-inspired dynamic language. There are one big reason for this: compile time analysis is good. Dynamic languages are good for quick prototyping and small softwares but, with increasing complexity, the inability to catch bugs without extensively testing every line of code is a big big drawback.

Statically typed languages instead allows very precise and powerful compile time analysis and inference. We can find a very large amount of bugs at compile time. And this is good.

Statically typed and compiled languages are more safe, more scalable, faster and with more powerful tools. And in fact, all the new important and promising languages of the last years are statically typed compiled languages.

So Now?

These are the main trends of the last year(s). As we will see, this have had a big impact on the development of new languages that one day, could be the new main industry standard language.

Unfortunately I’ve already consumed an huge amount of space. We leave the rest of the story for another time.

comments powered by Disqus