Two-level organization of the source code. Inevitably or pointless?

I have been developing software for a long time, and all this time I can’t get rid of the idea that directly programming languages ​​either do not develop at all, or develop extremely sluggishly. The whole development since the 80s is in the form of some, sometimes obscure, dances around C ++. In fact, we are still writing on what was invented 30 years ago, excluding minor “amendments”.

Perhaps, of course, I cringe a little here, but you must admit that the development environments themselves have changed much more.

The topic, of course, is very serious. There are many aspects and directions where you can move. In this case, I want to consider only one thing.

I proceed from the fact that the vast majority of developers have not written in text editors for a long time, but to one extent or another uses fairly advanced development tools. I propose taking another fundamental step in this direction. Namely, to get away from the flat-text way of working with source codes. For example, let's take the same HTML, for example, it’s not really important. The main point is that the development environment, if you adhere to the chosen analogy, will act as a source code browser with the ability to edit it. That is, we will not see / edit the source code in its final form, but the code in a more convenient representation for us at one time or another. Just as we now see in the browser not the HTML source, but something more “pleasant”. What do we solve by this? In my opinion, a lot.

1. The problem of unification of code formatting is solved. Each individual developer does not care about formatting the code, but in the settings of the development environment sets the parameters that are more convenient for him. Say indentation, right edge, etc. As a result, different developers can perfectly safely work with the same code, but in a different representation.

2. The problem of separation of entities is solved. Well, in the most common example, these are types and variables. Now this is being solved haphazardly, for example, in Java types it is customary to write with a capital letter, variables with a small one, in Delphi types begin with "T", etc. But all this is rather clumsy. In the proposed approach, a user-declared type of, say, Table will look like Table for the user only, for the environment it will be something like , it doesn’t matter, it’s important that the development environment at any given time will know that this is the data type, even without having the file “at hand” where this type is defined. As a result, we can safely define types, variables, etc. in one register, without any prefixes, suffixes, etc. But, nevertheless, the developer will always know for sure what Table is in front of him, since he will always be highlighted in a special way, for example, in font and (or) color.

3. The problem of documenting the source code is solved. Yes, of course, now there are tools like JavaDoc, but in addition to dubious aesthetics, it has a number of limitations. For example, try to describe the code in different languages ​​or to describe each function parameter separately. In the proposed approach, there will be no such problems. We can easily attach an arbitrarily large and arbitrarily multilingual unit of documentation to literally every word of the code. In this case, the documented text will be completely invisible to the user until he himself wants to see it.

4. We will be able to store resources, any, up to sounds and pictures, directly in the source code, and linking them directly to it. Perhaps the most common example for this is visual development, when form data is stored in separate resources, the same .dfm in Delphi, xml resources in Android, etc. The design will turn out more stable and convenient and, probably, more functional.

5. The following, now completely unthinkable constructions will become available, such as the type



or description of function parameters in the form of a table, and class elements in the form of a tree.

6. Localization directly in the source code. That is, for example, we can set several values ​​to the same string constant. In the editor, it will look something like this:

const Message = "Hello world!";

Except there may be some kind of icon next to it, when you click on it you can view / correct the text in any language.

Yes, of course, the proposed approach also has its drawbacks, and some rightly point to them, and some, quite possibly, go further and call the whole idea nonsense. But, as for me personally, I am absolutely convinced that movement in this direction is inevitable. The only question is who and when will take the first step.

Also popular now: