How I Found the Best Programming Language in the World. Part 2

Disclaimer: this article is a translation. Original post was published in June, 2015.

The first part is here. Let’s go on.

For seven f*cking years, I’ve been waiting for a programming language that would meet my requirements. During this time, I’ve tested everything. Everything means all the general-purpose crap and all the not-quite-general-purpose crap. You can’t feel a language only by reading about it and writing “Hello, World!”. To understand the language, you should write at least something with it. During all this time, in a moment of despair, I downloaded yet another “amazing language” and tried to write something. Some of those things still run in my company (or used to run).

Clojure

I did some small things like a REST server of licenses in Clojure. My verdict is that Clojure is a functional PHP. I had the same feelings (emotions) as when writing in PHP. Just like lots of dynamically typed languages, Clojure gave some positive emotions (especially at the beginning) – you’re in production before you count to three. Everything looks nice. Code is quite elegant if we train our eyes to recognize parentheses. In general, I thought of it the way I thought of PHP. When I need to make a page showing something to my colleagues from the database, I will use PHP. There’s nothing better than solving this task in a fast and reliable way. But if we need something more complex, it won’t work. Bigger processes require a bigger head, as well as some culture of production, tools/processes and so on and so forth. Then it will get even worse.

I’m not trying to say that Clojure is bad. Rich Hickey (the creator of Clojure) is a smart guy. Concepts in Clojure (PDS, STM) are absolutely great but they have little to do with the language and can be implemented everywhere. Discarding the concepts, it is Lisp. Fortunately, I have no guts to write in Lisp in 2015. Some programmers write really big and complex things in Clojure, as well as in PHP. Datomic is worth something, but again, I’m not interested in dynamic typing. Such things are for people with a large memory module in their heads. Anyway, a new Volkswagen Beetle is not bad to go to a club but it’s useless for Camel Trophy.

Scala

I have returned to Scala several times and then dropped it again and again. I totally get it why Scala attracts inexperienced young people (they are usually the ones who use Scala). It attracts them by the following things:

• The air of exclusiveness. Really, the progress in Scala is made by the smartest guys. Fools don’t write in Scala, so those writing in Scala are a sort of smart. But guys, programming is not like studying at the university. Your “smartness” does not depend on how difficult the task you solve is.
• Complexity. I guess lots of Scala fans don’t know, and do not even try to sum up what attracts them in complexity. Subconsciously, someone may think that complexity == power. The more complex, the more powerful the program is. It is natural for newcomers (and I am writing mainly about novice programmers). For those who haven’t actually developed anything in their life (and have nothing to show). It’s a natural reaction to take an alien rifle with a hundred of levers and buttons like in a movie. Such thing should kill everyone around, with their primitive weapons. The problem is that nobody told the newcomer that this a-sort-of-a-weapon has not been created to kill everyone around but to let everything inside it move smoothly and elegantly, in a scientific way. Generally, this line of thought is right: any mathematician knows that the absolute task complexity does not change, but the solution can be both simple and complex. A simple solution of a complex task (one line) is possible when we pass the task complexity to the already solved things (theorems). That is, we can solve a very complex task by reusing complex solutions. In our case, the compiler should take care of as much complexity as possible, which will simplify the solution. The Scala compiler is certainly complex but there’s a problem: the language that expresses this complexity. It’s extremely difficult to use such language (I am not talking about the case when Scala is used as an “improved” version of Java. This part can go to the air of exclusiveness).

The last time I returned to Scala was a week ago. I had to choose a language long ago, so I decided that Scala was the least of two evils. ScalaJS and relatively rich options of metaprogramming (read macros) gave me hope that everything would be fine. Besides, some hipster from EPFL has decided to solve for me some problems with off-heap data structures mentioned in the first part of the article.

Anyway, I took a deep breath and told my friend:

_Seems like we’ll write our Next Big Thing in Scala. Guys will be shocked — I’ve railed against Scala for years, and now, out of a sudden, the concept has changed…

Setting up on positive, I began trying to develop something. I have to say that I had almost zero knowledge and experience in Scala and that I compensated it with my life experience. It was obvious that I needed Type Classes, and I started to google. The first thing I saw was shapeless library by Miles Sabin.

Anyway, I googled shapeless (and I need type classes). It did not have documentation, and the first paragraph had links to four scientific articles. Then, they tell you how you can help them, the way to contribute and how to compile. That’s it. So I went on searching and found videos by Miles, in which he tells about his miracle. It takes him up to 45 minutes to tell us that the basis of shapeless is his magical invention called HList. It’s a sort of a main feature he has worked on during the last years, and it was almost working when Scala added macros. That’s why he changed his feature and now a new HList is even better than the old one. He has actually worked on it for a long time with lots of code that basically looks like this:

object IsHCons1 {
    type Aux[L[_], FH[_[_]], FT[_[_]], H0[_], T0[_] <: hlist ishcons1 fh ft type h h0 t t0 def apply tc: aux tc.h tc.t tc implicit mkishcons1 macro ishcons1macros.mkishcons1impl>

Con you tell me, what the fuck is this? Who is it meant for? For people or maybe not? Are you suggesting me to write like this every day using hundreds of lines and stay sane? Or maybe it’s meant for some exclusive public while we, down-to-earth doers, will use your thing?

What to do next, after the listener comes to know HList? He sends us to his workshops, videos, and courses that are not for free. I don’t mind paying for knowledge but:

This dude has spent years on the product so that people kill months and, for f*ck’s sake, be able to refer to a type and know the type of a value during the runtime, and maybe do something else during the compilation time (e.g. get the size of a collection). To do this, we should f*ck our own brain really hard and write something like the code above. I didn’t go into details, and maybe the time-consuming shapeless (I guess it’s not the best Scala library in the world) can do something useful but I’m speechless. People talk about this stuff at conferences, make various workshops and 56-page presentations like Demystifying Shapeless. Why do all this? To get the type of a value during the compilation, man…

Come on, I developed in Delphi in 1995 and had everything I needed. I knew nothing about Polymorphic typed λ-calculus, and I know nothing now, but the thing is that any student can write such HList in Delphi during 10 minutes. He will know the type in the runtime and will be able to reference it, and also compare it, and God knows what else. He won’t need to think much when doing all of this. If Delphi had macros and generics, I’m sure students would write the same libraries as all the exclusive gang writes in Scala. Moreover, they will do it much faster than the adult guys, and they wouldn’t even need structural refinement types and other stuff (are they really so necessary?). Life gave me some proof on the matter but let’s talk about it later. By the way, the code by students would work much faster, the old school Borland could do stuff.

Anyway, my summary on Scala is the following: these guys have decided to hide the complexity of the tasks solved in tools, changing it with the complexity of using tools. As a result, this turned out to be more difficult. If you ask me, the difficulty of programming in Scala is much higher than benefits from using it. Drawing analogy with cars, it’s the first version of Google self-driving car. You should set all the wires and cameras, as well as patch everything and all that. Well, you can sometimes let go of the steering wheel, but(!) keep an eye on the dashboard. If something’s broken, it will take you a day to keep going. And yes, it dies at seeing the red ball. Screw it.

Goodbye the JVM World, I didn’t Find What I was Looking For

So I have looked through JVM-based stories, and Fantom did not satisfy my needsfor several reasons. I also looked into Ceylon and Kotlin from time to time. I also rejected all stories with dynamic typing (please don’t advise core.typed). In despair, I thought of looking into TeaVM, which would expand the list of candidates, but I didn’t as I saw no candidates. Anyway, all of them belong to the same class, a sort of a Ford Focus of programming languages. Not bad for traffic jams but you’ll never say “Wow” about it.

Having found nothing in the JVM world, I tried all possible languages, and even the ones you might haven’t heard of. One of the ones I liked was Clay. I guess it had potential. It’s a sort of a statically typed version of Julia. Creators of the language abandoned it. As far as I understand, one of them works for Apple now and has something to do with Swift.

To those waiting for me to announce the best programming language and those being skeptical about all of this, I should say that I wasn’t going to agitate anyone for a particular language. All I wanted was to share the joy of discovery. Moreover, I’ve been thinking about this question for years, and the answer wasn’t obvious. Anyway, let’s move on.

Programming Language — What For?

Everyone will agree that a programming language is a tool, a means to express our thoughts (if there is a thought). As a rule, it’s interesting to express my thoughts only for solving a particular task. It’s a tool that we use to create software. Therefore, the only logical requirement we can and should apply to a programming language is to increase developer’s productivity here and now, in the short, medium and long term.

Many general-purpose languages are equally applicable to the majority of tasks (that’s why they are called general-purpose), and I am not going to consider cases when a language is obviously meant for the given task. Such cases are more or less clear and even if there arise some disputes, they’re more meaningful. We are more interested in the most common situation when a task can be solved in dozens of languages (which is usually the case). For instance, what should we choose for writing a server — Java, Go, or JavaScript? This will definitely result to a holy war.

The idea that language is a tool for creating software is undeniable for me. That leads to a requirement for a language to increase team’s productivity. In practice, people rarely discuss languages from this point of view.

Besides, in discussions about languages we divide languages into classes (dynamic typing, managed runtime, and so on), divide tasks into classes but we never divide “programmers” into classes. We usually divide them into novice programmers and other “programmers”, and it usually takes place when a newbie considers himself belonging to the class. However, this classification does not work when even the worst lamer can speak as a guru without thinking about what class he belongs to. If we classify not only languages and tasks but also discussers (and we should do this), there will be so many classes.

The subject of classification of programmers is an extremely interesting story on the verge of psychology (or psychiatry) that we can deal with some other time. As for now, I am going to provide several examples suggesting that the impact of an individual and his motives in matters of language evaluation is not less important (and maybe even more) than the language itself and tasks it is chosen for. For example:

Asshole

There’s this not very good friend of mine («not very good» meaning that I’m not proud to know him). About ten years ago, he shocked me when he told a story how being a student he had written a product for some company. He wrote the product in Clarion with his friend (I am not so old to tell you something about it). Being a student, the dude deliberately chose Clarion as he thought that it would be difficult to find a programmer in Clarion, so the customer would always return to the guys for system support and development.

I definitely told him that it was their crucial mistake, and forgot the story until I met the guy about half a year ago. He told me he was going to Brazil on a business trip. He was going to help Brazilians create a full-featured system of something in Scala. Unfortunately, the dude was going alone as his other mates did not have enough intelligence, but he was sure he could make it without them. Then, he added that he was really pleased to work with smart Brazilians and admired their plan. The plan was simple: write everything in Scala, and the architecture should be too complex for an ordinary person to understand. This would allow them to take control of a small but juicy niche market in North America, and live happily ever after receiving checks for the support of the most complex product ever.

When it comes to assholes, they don’t give a damn about productivity when choosing a programming language. Even if such question arises, it is definitely far from being important. However, there’s another extreme.

Microblogger

There are lots of different dudes showing genuine interest in programming languages. Due to their own inadequacy, these guys are sometimes interested in increasing their own productivity more than any of us (actually, they’re on the right side on this matter). For many years, they face fail after fail. Life goes by, and they have nothing to show as the result of their work. I’ve seen quite a few people of such kind. They gathered teams or did everything themselves. As a rule, they chose the language and technologies growing in popularity at the time, seriously thinking that it was the language to lead them to success. Such people associate all of their previous failures with bad tools they’ve used but never with themselves.

For example, there are some microbloggers telling stories about how cool are things I think to be too clever for me. They say how stupid other people are, even if they write in Haskell but didn’t have time to appreciate all the beauty of Idris (or something else). The problem is that the young generation listens to a microblogger. They nod in response and imagine a picture of a successful programmer who deals with smart things, and not trivial ones like they do. They do not know that in real life “the rockstar of functional programming” deals with millions of lines in Perl in a team of 100 people. Moreover, he has no practice applying all of this in real life. The rockstar has turned forty, and he hasn’t stayed in one company for more than three years. The whole Internet doesn’t have even a single line of his code, except for ported libraries from something in Haskell, or PHP or Perl.

In a language, microbloggers look for a magic stick that will allow them to create at least something themselves. The truth is, they don’t find it, and keep changing one language to another, hoping that each new language will suit their mental model, and they will be able to finally create, but no, no, and no. As a result, he does another dull work in Perl. Oh my God, I can cry now. But a microblogger doesn’t cry! He goes to social networks, and makes them see a guru of functional programming, the giant in thought, the top of the professional career. Dozens of inspired young people stop programming and begin to learn Haskell (or anything else the microblogger is considering as a magic stick for the moment), hoping to become just like him.

Despite the fact that the productivity for such people is the most important task fueled by paranoia and other mental problems, they can’t give an adequate language assessment in terms of productivity. Nature has simply forgotten to provide them with a productivity module. We can use these guys as a source of objective information. However, it’s quite harmful to listen to their thoughts. In favor of microbloggers, I should say that not all of them belong to the type described above. Some of them are simply curious, while it’s a hobby or science for others. Unfortunately, only a small part of them consider the subject they’re talking about in the context of their own productivity (just like not microbloggers do).

I have provided quite rare examples, although they are not unique. But I’d like to highlight another vast class of programmers characterized by an adequate attitude to a language simply because it’s not really important for them. These people usually can’t reverse a list or implement a hash table during the interview. They really don’t understand why this should be done. “What for? It has already been created for me”. The most interesting individuals ask how this can even be possible. As a rule, these people try to make something that will work by collecting everything at hand, and get money for this. A programming language does not really affect such guys’ productivity, so they don’t really care about it. Their entire experience of making a product of various artifacts from other people shows that the programming language does not affect their productivity comparing to quality and features of pieces he glued together.

Other Diseases

Anyway, life shows that people are usually inadequate and what should be logical is quite rare nowadays. In addition to various classifications of programmers and teams with different values and interests, there are some intellectual dysfunctions propagated from one programmer to another. Inexperienced young programmers are most easily infected when they get into an infected team as their first place of work. Since various viruses and germs are everywhere around us, every team can be easily infected without certain rules of hygiene and pills. Sometimes viruses are deliberately brought to the team. There are cases when people complicate systems on purpose, in order to increase the budget (these guys belong to the category of assholes). But viruses also occur in companies in the medium of stupidity.

A young person infected by the virus behaves the following way. There was a guy we had just hired and gave him a certain task. Well, he was doing something for several weeks. Then he came to us ask for an advice, his scheme was too bog for the white board but everything was almost fine, except a pair of use cases did not work well together, so he wanted to use just one of them. We advised him to throw all of this away and do two things instead. The dude hanged for five minutes in deadlock and then said: «But…this is too simple?!»

The virus disabling the ability to think simple is spread like flu. A graduate joins a company, that has already created a monster that falls to pieces, and it’s necessary to maintain that monster and maybe even develop new features in the worst case scenario. There will be various shit like workarounds and duct tape, as well as ten people instead of two, and all of them are infected with one of the brain viruses of the company. By the way, most young people come with a healthy brain, and that’s why we can often hear that “inexperienced programmers want to rewrite the entire code”. But no one will allow them to do this. He gets used to this, takes it easy, and gets infected. In a few years, he won’t even have a thought that it shouldn’t be like this. Software is a difficult thing. Programmers get lots of money for doing these difficult things, and it does not happen in a different way.

When people from well-known companies come to an interview, you can predict with a high degree of probability whether he is healthy or infected. You can also say what type of disease he has as the damn thing infects almost everyone with time. I distinguish it from the culture, which is like a magnetic field that stops affecting you after you leave the office. Programmers infected with viruses rarely think of the main requirement to a programming language. They’re interested in the wide variety of details but not productivity. They also don’t really care the question “What for?”

Programming Language — What For?

So, if not all programmers consider a programming language as a means to increase their own productivity, then maybe creators of languages make them in order to increase the productivity of programmers?

Of course not. The purposes of language creators are also surprisingly various. What was Odersky’s purpose to create Scala? Perhaps, he had purely academic (research) goals and he wanted to make something new in the idea of unifying functional and object-oriented programming.

From the presentation: when creating Scala, he was motivated by two hypotheses. Most other languages are not motivated by either one or both of these hypotheses. But what if the hypotheses are wrong? Where will Scala be? Where will other languages be in case the hypotheses are true? It is also possible that these hypotheses are some crap “for the beauty”. Maybe he was simply fulfilling some university “plan” or maybe Sun offended him somehow during their work.

Sun hired Martin Odersky to design Generics for Java, and the GenericJava compiler actually became the standard javac compiler shipped with the SDK as early as Java 1.2 (with the bits about generics disabled). Later on, a modified design of generics (with wildcards being the main new addition) was released with Java 1.5. Odersky, of course, went on to first design Funnel, then Scala, but his compiler still ships with Java 8.

Why not? Just imagine. Martin suggests some ideas and says this or that should be done this way and they don’t approve his ideas. As a result, his work does not go out into the world either in 1.2, or 1.3. 1.5 reveals something he does not really think right (I don’t have any information. It’s simply a conspiracy theory that came to my mind right now). Well, he got mad at them saying something like “_I will show you, the fucking idiots, the language that will make you feel who you are — The. Fucking. Idiots._”. So the language might have been created to rub it in someone’s face.

It goes without saying that a good language written by geniuses like Odersky can be used for different purposes, and he will still be good. However, a language will give maximum effect when used in accordance with purposes it has been created for.

Here’s the great Clojure. It was born out of amazing ideas by Rich Hickey about “state, identity, value, time, types”. The guy thought about new structures necessary for solving current and future problems of concurrency and parallelism. Initially, there was a problem, an idea and a solution in the sphere of Persistent Data Structures, STM, etc. I am absolutely sure that Persistent Vector appeared first, and then Clojure. The fact that Clojure looks like Lisp and is actually the dialect of the latter can be simply a coincidence. It is most likely that Lisp was the language Rich was ready to implement as quickly as possible and he was fine with it. He might have created another language. My idea is that the language is secondary here.

I would like to emphasize the importance of goals of language creators. Someone will say that Clojure is great as he can smoothly manage the state, concurrency, and other things. No! It’s not the programming language (Clojure as Lisp dialect) that allows you to do this but the ideas by Rich. The language has been added to these ideas as a means for using them. Implementing these concepts in other languages (and they don’t require any “special” language), the programmer will get the same things that make other people love Clojure. We need to realize what we like in a language: concepts that can be easily transferred to other languages (like PDS used in JavaScript) or you like the language itself (the Lisp dialect in our case).

I’d like to say that creators of languages rarely make their main goal the creation of a language that will help a programmer to be more productive. They often solve some other tasks, and the language appears as a result of solving these tasks. JavaScript is a good example here. No one ever thinks that JavaScript has been created to allow you increase your productivity and write code faster and better. Or maybe someone thinks so (I’m smiling here)?

From the creator: brendaneich.com/2008/04/popularity. Actually, Brendan Eich was invited to Mozilla to write Scheme for the browser. If the initial plan hasn’t been changed, all of us would write in Scheme saying how great and up-to-date it is. The fact that you are writing now not in Scheme but in JavaScript is in no way connected with the desire to make you more productive. To begin with, Scheme did not work out as the management wanted a language with the syntax similar to the one in Java being released at the same time. Due to lots of reasons not related to programming and productivity, you have a language created in record time. I guess the language creator doesn’t actually realize why the language has become so popular. At the same time, the language fulfills its main purpose (to my mind) — it increases programmer’s productivity.

The Main and Only Purpose

With such a variety of programmers, languages and tasks, all of these three parameters can come together in absolutely any way perfect for the given case. No matter how silly it seems to be talking about “the best programming language in the world”, I will still do it. I will get back to a programming language as an instrument and I will speak for myself.

Language can be adequately assessed by one purpose only — productivity.

Productivity is when we know what we should do (although we might not know how to do this), have certain deadlines and other restrictions and also have a real reward/penalty for the result or lack of it.

The truth is (it can also be the reason for such a variety of opinions about languages) that most of us have an interest in languages having various purposes (education, curiosity, self-esteem increase), except for the increase of productivity at work. We often simply don’t have a manufacturing capability to change the language. That’s why we don’t have the productive interest for languages most of the time. Our interest is usually either educational or it’s a simple curiosity. You can also be designing a language but it’s a pretty rare case.

The programmer should consider the language as a tool for increasing the productivity of his own and his colleagues, right here and right now and not in the distant future. That is when the opinion about the language will be more or less adequate. If you’re not ready to take the language to production right now — your interest can be anything but production necessity. You can dispute with your colleagues on features and concepts of any language with any result that brings no sense except for self-development or degradation of people you’re discussing it with.

Programming language as a means of production should have just one feature. Just one damn feature, and all other ones are not important. I mean they’re not important at all. It doesn’t matter whether you have generics and other stuff. What important is the impact of all of this on productivity. The production tool should increase the team’s performance in the short, medium and long term. That’s it.

In 1999, I worked for quite a big company. There were two popular holy war topics at that time. Since there were no dozens of topics like we have today, the fight was to death — Windows vs Linux and C++ vs Java. While people were arguing, I was laughing to myself (and sometimes aloud). There was a simple reason. I had a small project at the time, a sort of an Intranet search engine or something like this. Due to the reason that young people provide nowadays as an argument (the ecosystem), I decided to write it in C. Following this argument, I couldn’t write in Java as 1.2 was still in beta, and the ecosystem was no good. As for C++, they had some useful libraries and frameworks.

There was no Lucene in the world of Java at the time. Having decided to write in C++, I had lots of problems. Instead of real programming, I thought of the compiler, combined libraries, and so on. Fortunately, I had the opportunity to rewrite everything in Java. My colleagues didn’t like the idea at first, as they thought that we wouldn’t have enough speed. So I showed them that we only read the file system, and it had nothing to do neither with Java nor C++.

The process of rewriting everything in Java took me 10 times less than wiring the initial variant. Fortunately, I had documents describing indexing algorithms and crawling from some guys from Stanford. I guess their names were Sergey and Larry. Everything was simple and clear, and their proprietary ranking algorithm of search results was not necessary and maybe even useless for our volumes. By the way, the two guys were starting a company that was dealing with web search at the time.

Anyway, I was listening to talks about templates, overload and overriding what was possible, as well as macros, allocators, performance, and multiple inheritance (!). C++ gurus attacked young students and showed them the entire power of the language. You won’t be able to do this and this in your Java. As for me, I was simply laughing to myself and smiling. I don’t give a damn about your allocators, templates, and multiple inheritance. I don’t care what you can do and how you can do this, asI can write code 10 times faster than you. Well, an experienced C++ programmer can write faster, which means that I will do this 5 times faster than him. Or at least 2-3 times faster. If I can do the same thing 2 times faster, who cares about his templates? What about limitations? There were none. We had enough speed and memory, and we were not going to write system kernels.

It’s absolutely incredible when you write code freely, almost without thinking without expecting core dumped before each run. It’s amazing when features are added one by one. We can do this and this now! Do you really think I should care about having no templates? I don’t even miss them. Productivity is the main goal of every programmer who creates things, and it’s the only task of the tool he uses.

It’s a very bright moment when you write everything as usually, just like when building a house, and suddenly you get a great tool, a magic stick, and bricks form the house themselves. I had only several such moments in my life during more than twenty years of programming for money. I have already told you about the transfer from С++ to Java. It was almost the same when we developed desktop applications in Visual C++ 1.0, 1.5 or something like that. Making a dialogue with three buttons (that won’t work like they should for a long time) was a big task for a day. All of these macros and other crap I don’t remember, fortunately. To understand how your code communicates with Windows, we had to go through dozens of C++ libraries.

That’s when Delphi appeared. Someone might not believe me, but it was an actual revolution. If you’re one of them, I must say that the architect of Delphi, Anders Hejlsberg was tempted away by the shocked Microsoft where Anders became the chief architect of C#. Anyway, Delphi allows you to do whatever is necessary: the user interface, low level, etc. All flow are clear and you can add what you want to. Something like the support for new controls from Microsoft without waiting for a new version of Dephi. You can easily see everything up to the layout of virtual method tables in memory. The main thing is that you write the same software but 10 or even more times faster. Limitations? None. That’s why it is much easier to go into the depths of the operating system.

Looking at these two stories one might think that I’m for simplicity. This is not the case, and everything is not so simple in simplicity :) I’ve remembered about a talk by Rich Hickey “about simpilcity” — it’s a really good thing. In the context of programming languages, I’m not for complexity or simplicity of a language. I am for the power of the compiler and the ease of its use. The better it understands me and the more it does for me — the better, but only if any language/compiler complexity will increase my productivity rather than reduce.

There are some good examples in the JVM world. Java itself can be another example. When comparing Java to C++ feature by feature, Java will lose the fight with a crushing score. but JVM has a complex thing that is not available in C++ — Garbage Collector. Java without a GC (it wouldn’t be Java at all) wouldn’t give us an opportunity to write code much faster. No matter how you simplify or complicate it again. Programmer productivity has significantly risen thanks to garbage collection (it is when the compiler and runtime think for you, constantly) that does not create difficulties. Except for recent times, due to the low cost of memory and the trend to write every single bit in Java. In this case, GB becomes a problem again.

Generics in 1.5 have not complicated the use of Java at all but increased productivity. I guess the same thing is with lambdas (to tell the truth, I didn’t work with them). The increase in productivity has made me think of a more productive language than Java in 2008, and that’s why I hoped for Fantom. I want to provide it as an example of the language, the main idea of which is the increase of programmer productivity. The guys who created Fantom made productivity their main goal, right here, right now, in our real work:

Fantom is designed as a practical programming language to make it easy and fun to get real work done. It is not an academic language to explore bleeding edge theories, but based on solid real world experience. During its design we set out to solve what we perceived were some real problems with Java and C#. Our background is heavily Java, but many of Java’s problems are shared by C# and .NET also.

If someone bothers to read their forum, you will clearly understand it. The focus on engineering productivity has attracted me in the language. The process of experiencing the language was similar to my transfer from C++ to Java when the code is written so easily and you understand that Java wouldn’t allow you to do same things at the same speed, and you feel more freedom. That’s when you realize that it’s the dose of productivity you’ve been looking for. You get and use it, and you always want more. (As for Fantom, it does not limit a Java programmer providing convenient FFI and native classes, and it also gives you the browser as a platform.)

I have decided to provide Fantom as an example as it has no generics. The productivity Fantom provides compared to Java is not connected with the availability or absence of generics. I am telling about the absence of generics to the vast class of programmers who are looking for features in a language, not productivity. Do you really think that language creators couldn’t add generics or anything else? Fantom is a great example of the language people created for their own use, for their own business. They’ve made it for their own productivity and the productivity of their business as a whole.

They did it not for us (by and large), and they did not want to compete with other languages. They didn’t do it for scientific articles or anything else. They did it just for themselves as they wanted to be more efficient programmers. That’s where these guys are honest and trustworthy to me. The language had no generics as the creators doubted whether adding them to the language would make language users more productive or maybe less. They simply doubted and if they were wrong it would mean that the language loses the benefits it could give to programmers (if is a keyword here).

I am trying to say that it’s silly to compare languages by features. What means is the entire look. Looking at features is like choosing a girlfriend by the pictures of her body parts: you will look separately at her ears, and then eyes, etc. You will set a requirement for her to have boobs, and will get something really scary in the end. At the same time, you might have had an absolutely stunning girl with no boobs at all (sorry, generics. These are synonyms).

Separate body parts are definitely important but not as much as things you pay attention to in life. Proportions are important. In programming, we face various imbalances to one way or another. We all know about the harm and benefits of abstractions. Ability to find a balance between abstraction and concrete actions is one of the talents a decent programmer should have.

I was quite shocked at the time. Being a fan of object-oriented programming from the ‘90s, I always tended to write the most abstract (still reasonable enough to run well) code. Actually, writing object-oriented code in 90’s was a sort of a rebellion. There were no more object-oriented programmers than those writing in functional style only.

So, my propensity for abstractions got a cold shower in 2002 when I “found” eclipse. Eclipse has fascinated me with its architecture and design. Unfortunately, you won’t hear much good things about Eclipse nowadays but you will hear this from people who haven’t seen the inside of it, and even if they did, they didn’t look deep enough.

I have met few platforms designed with such a quality. There’s no surprise here as Erich Gamma is one of Eclipse Platform architects. He is one of the four authors of the popular at the time book called “Design Patterns”. I’m not sure is popular today but at the turn of 2000 all companies used its design patterns on interviews.

So, I’m looking inside Eclipse and don’t understand what’s wrong. On the one hand, everything looks neat and nice, I might even say fascinating. But on the other hand — we might reuse here and there, and guys are deliberately copy-pasting here. Something’s wrong here. They could have definitely reused the code, but don’t do this. To find the answer, I had to go beyond my infant programming needs, and look at the world through the eyes of a grown man.

Any fact of (re)using anything rises a dependency on this thing. While a dependency for me is a good thing (efficient reuse) that leads to increased productivity, it’s an evil for people who create a platform that implies the simultaneous run of hundreds of plugins, various versions and dozens of vendors. Any additional dependency for them is really bad. Being a programmer, we always have to pay for something. When someone shows another solving-all-problems feature or tells about a new programming language with high-level abstractions, the first adequate question should be: “What will we pay for it?” If they say it’s absolutely free, ask them when we will pay for it.

I don’t believe we can achieve success in the extremes, creating too abstract or too specific languages. When a language goes to extremes, its role in increasing programmer productivity is a big question.

Summary

A few words about the ecosystem. The ecosystem is certainly important, but appealing to it is like moving the question to a different angle. Working with new technologies and languages if like working on the stock exchange: a common man gets rid of the deposit in the 90% of cases. Well, it’s not so severe in programming but the sense is the same. When the crowd runs to buy assets — all the growth is over, and the best has been taken. I took the Java “stock” in 1999 (I wasn’t in the forefront). At that time, the ecosystem was poorly developed. But the growth of productivity for me and my team, as well as the incredible growth of Java during the following ten years, has allowed me to keep smiling now, when programmers try to appeal to the ecosystem. It’s like when you say that we shouldn’t buy the Apple stock as they are really cheap.

Haha! We shouldn’t buy shares of stock when they are expensive, as their growth potential has been emptied. All you can buy is a relatively long or not long stability. To buy the right asset, we should really understand its value (despite the low price), and be sure the purchase will bring you dividends immediately, rather than in the distant future. In a similar way, we have grown on eclipse “stocks” since 2002, when it had an amazing potential for growth and its assets reached their maximum by 2008. Since then, I have tried to leave the stocks of Java and eclipse, and move on to other technologies, as the growth potential of these two has been used up. Languages and technologies give you a competitive advantage. But if you use the same languages and technologies that half of other programmers do — there’s no technological advantage here.

Getting back to the choice of the right language, I don’t care about language features, it can have few or a lot. What I’m interested in is how the language will increase the productivity of my team, now and in the future, for the known and unknown tasks. That’s it. All the rest doesn’t matter. As a part of productivity, the language should unload my brain. I shouldn’t think about the language like I have to think in Scala or Rust. I don’t want to keep hundreds of details in my head that are not necessary to keep, like in languages with dynamic typing. Looking at the code of someone else, I should understand what’s going on there rather than researching everything like in the example with Scala. Not because I can’t do this but because there’s no sense in it. I can’t see how it will make me more productive. That’s why I don’t believe it.

For those who are interested, I will tell in the third part about the language I’ve found. Since the intrigue is gone, I have to say that it’s really Nim. But I want to explain my position. I want power, the power of compiler that will do lots of things for me and that is easy to manage. Requirements are still the same, just like requirements to a car. I want a strong, reliable, and comfortable car that is easy to use and is always the first one. It should also have door closers and other small pleasures that add comfort and let us think less about the car. I’m not into racing through desserts and swamps. I want a comfort and efficient use. Such people care about desires other than the desire to work efficiently on the development of software.

Do you know this feeling when you get out of a dull old car and sit into your modern one with three of our hundred horsepower under the hood? It’s so great to fell all the power of technologies that allows you do to what you want and how you want this to be done. This is called freedom.

Cheers. @Platoff