We all know that several thousand programming languages ​​have been created in the world. Only the list of programs Hello, world from the site Wikibooks includes 230 categories (the full list today consists of 402 items). At the same time, the well-known TIOBE rating confirms an obvious consideration: the majority of these languages ​​are more likely dead than alive. Already the top ten languages ​​account for 76.77% of all projects taken into account by TIOBE. The second ten increases this share to 85.61%. Therefore, the remaining 30 languages ​​(TIOBE takes into account only the first 50 languages ​​when calculating percentages) account for less than 15% of references.

It is clear that the ratings imply a certain amount of cunning, since even a language that is unpopular in general terms can be extremely important for any narrow sphere. Take the favorite one here by many Erlang or Haskell (39th and 41st places in the ranking) or even more obvious Simulink and LabVIEW, which were not in the Top 50 at all, but irreplaceable in their fields. On the other hand, it is obvious that languages ​​really come and go, and the popularity of, say, Pascal is doomed to decline, since more progressive languages ​​are replacing, marking in the same niche. (Let us not mention Delphi here, in which only the basic syntax remains of Pascal. For a traditional Pascalist, Delphi listing can cause the same stupor that I had the first Visual Basic 6 program that I saw, with these Private and Public, Option Strict and Dim As, completely absent in his native BASIC ZX Spectrum.)

However, all languages ​​were created for something, and not just. And before finally sending one or another language to the archive of history, one should fully understand its legacy used in current programming practice. And it may be that some languages ​​are generally written off for nothing. The only question is how to competently conduct an audit, an inventory of all this stuff from hundreds and thousands of languages, how to extract nuggets of meaning from the mountains of waste rock? I would like to talk about this. I must say, I have no good answers, but there are good questions.
')

Duck Syndrome and Winning Peepers

To begin with, I would like to put forward the thesis that the most popular languages ​​today are not objectively the best. My former supervisor once said gloomily: "It seems that the worse the language, the more popular it is." I will not go so far in my conclusions. Suffice it to say that the popularity of any language is really largely due to external factors.

The most obvious is duck syndrome . What we were shown in childhood is what we love. And the longer we work with any system, the better we understand it and, therefore, the less we have the motivation to switch to something else. I could bring my own story here, but I don’t see much sense in it: most likely, most programmers are familiar with this phenomenon from personal experience. For the sake of truth, it should be noted that the holy war "language vs. language "little understood. Research clearly demonstrates that the productivity of development is almost entirely provided by the programmer, and not by language (this is, of course, about languages ​​of about the same level that can compete with each other).

Raised "duckling" can contribute to the victory of a particular party. So, at one time Microsoft made a bet on Basic and C ++, and in Borland - on Pascal (their solutions in C ++ clearly lagged behind), the consequences of which we have been seeing for the past two decades. A more recent example is Objective-C (5th place in the TIOBE ranking). Who would have remembered him if it were not for Apple? In 2007, Objective-C was in a lowly honorable 46th place and, I would venture to say, could be considered relatively dead. Being a solution to far from the first freshness (1983), this language was learned by ducklings from Apple and is now included in the list of the most popular languages ​​in the world.

The argument about the right way to break an egg is meaningless, and the victory of the party of little-pointed people does not mean the superiority of their ideas. Just so the stars were formed. If, when learning a new programming language, I set a goal to increase my chances in the labor market, the TIOBE rating is useful. If I want to dig deeper, study the best examples of the architecture of the language, other selection criteria are required. In general, do not dismiss the half-forgotten languages. Blunt-knots are capable of taking revenge, and it may be that tomorrow they will begin to praise completely different languages ​​everywhere than today.

Fort assault

Under the strong influence of my other supervisor, I had long been eyeing FORTH language (38th position in the TIOBE list). My experiments have not yet gone beyond the simplest exercises, but I can already draw some conclusions for myself. I think my experience is quite indicative, so I want to dwell on it in a bit more detail.

For a start, what is the Fort language? In short, a unique system of almost missing syntax is implemented in Forte. The program is essentially a sequence of names, separated by spaces:

w1 w2 w3 ...

Each name (in the terminology of the Fort - "word") - it's just a call to the appropriate procedure, built-in or user-defined. That is, in C, the same program would look like

w1 (); w2 (); w3 (); ...

Words (procedures, I mean) can be defined using the following simple syntax:

: NewWord w1 w2 w3 ...; \ when calling NewWord w1, w2, w3, ... are called in sequence ...

There are two stacks in the system: one of them (the return stack) is designed to store the return address from a called procedure, and the second (it is usually called just the “stack”) exchanges data. Any function can read and write data stored on stacks.

Another important point: in principle, the program on the Forte is compiled into some intermediate code (usually using embroidered code ), and then executed. But at the same time, the compiler is part of the system and is always available. Inside the procedure, you can switch to compilation mode and compile a new fragment (for example, loaded from disk). In addition, any word can be assigned two different actions: the action at the time of compilation and the action at the time of execution. Say, constants in Forte are also implemented through procedures. In C, it would look something like this:

double PI () {return 3.14; }

At the time of compilation, the word-constant must allocate memory for itself, and at the time of the call, it must return the stored value.

All these opportunities are realized by literally five to ten keywords embedded in the general flow of words separated by spaces. Everything else can theoretically be implemented by the user. For example, you need a loop of the form DO ... LOOP. You can program it yourself. The word DO puts its return address on the stack. Then the words between DO and LOOP are executed. The word LOOP checks the condition of the loop, and if the loop must be repeated, LOOP puts the address stored by the word DO on the return stack. Thus, instead of a normal return from the procedure, the system jumps again to DO. Similarly, you can implement IF ... THEN, SWITCH ... CASE, any data structures.

In fact, any text consisting of words separated by spaces can be interpreted as a correct FORTH program. Therefore, with the help of the Fort, you can implement a particularly brain-consuming idea of ​​domain-specific language: you turn the input data into an executable program! In other words, the data interprets itself. For example, let the word A type the text ".-", and the word B - the text "-...". Then the execution of the correct ABABB Fort program will result in the printing of the corresponding sequence in Morse code.

Often FORTH is remembered as the language of Master Yoda because of the reverse Polish record used. In fact, this is just a consequence of the general syntax as a stream of procedural calls separated by spaces. A record of the form “5 2 +” is interpreted as a procedure call with the name “5”, putting the number 5 on the stack, then “2” (by convention, any procedure with a numeric name simply puts the number on the stack). Then the "+" procedure takes two numbers from the stack and puts the result back. The implementation of a full-fledged infix notation would be contrary to the general spirit of the language.

In general, this is inconsequential detail. Much more serious criticism of the Fort as a write-only language . Experts will argue that unreadable nonsense can be written in any language, but the reality is that at Forte it is much easier to make it. For unsurpassed flexibility you have to pay a lot. Say, taking the arguments through the stack, you have to remember their order. It is possible to describe function signatures unless in comments. In mathematical expressions, it looks especially wild. Let's say to calculate the value (a - b) / (a ​​+ b) for a and b on the stack, you need to run the sequence

OVER OVER + ROT ROT - /

You need to be a complete fortor to find this code readable. However, enough about the fort. If you are interested in this language, you can discuss it another time. We have to move on.

Debriefing

Of course, I am not writing this article to introduce you to the basics of FORTH. I just wanted to demonstrate that even the language of the fourth dozen TIOBE, and the language alone in its ideology (as opposed to Haskell and Erlang, having a lot of relatives) can teach a completely different programming process, indicate a non-standard approach to the way a software system is designed. This method is more than the Fort language; it is a style of thinking that is gained by practice. One of the participants of a fort forum noticed that he wrote a lot more fort programs in C than in Fort.

And now the questions. With and without answers.

1. Is it necessary? At first glance it seems that from “non-mainstream” languages ​​like the Fort you can extract a lot of useful for professional growth. But where to get an independent review of programming approaches (books like Sebesta are good, but not quite so)? Maybe some kind of decision only seems original and reasonable, but in practice it is a long time past stage, which proved its inconsistency?

2. What languages? The fort is an unusual language, clearly capable of giving food for thought to the modern programmer. But Algol, for example, turned out to be so influential that all its elements somehow migrated to other languages. Unless it is worth studying separate mechanisms like call by name .

3. What to study? Let's face it: it is unlikely that in all seriousness tomorrow I will start programming exclusively on Forte. Rather, I would be interested in a certain minimum basis, which would allow me to penetrate the ideology of the language, but at the same time not to spend months on total immersion. I could have written separate modules on Forte and connected them to my C ++ projects.

4. Where to get the literature? Decent textbooks for newbies around the Fort were published under Brezhnev . Now they either publish educational articles suffering from a lack of systematicity, or serious books for serious specialists. Old books are no good: the authors focus their attention not on those things that would be worth it (in accordance with modern concepts). A new book is missing.

5. How to overcome yourself? Reading classic textbooks is also difficult because you have to go to the first grade again. It is hard to spend the whole weekend programming a solution to a quadratic equation or implementing the simplest card file. I would like specialized training materials designed for people like me. Where they will not describe in detail what a stack or a function is, but immediately proceed to discuss the principal things for which I am ready to dive into this topic.

Well, in general, is there any point in my reasoning?

Upd : I want to emphasize that the Fort here is given only as an example, we are not discussing it.