Two-level organization of source code. Inevitably or meaningless?
I have been engaged in software development for a long time, and all this time I can’t get rid of the idea that programming languages themselves either don’t develop at all or develop extremely sluggishly. All development since the 80s is in the form of some, sometimes obscure, dancing around C ++. In fact, we still write on what was invented 30 years ago, excluding the minor “amendments”.
Perhaps I’m a bit of a twist 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.
I proceed from the fact that the overwhelming majority of developers have not written in text editors for a long time, and to some extent uses sufficiently advanced development tools. I propose to take another fundamental step in this direction. Namely, to get away from the flat-text way of working with source codes. Take the analogy, for example, the same HTML, in fact, is not the point. The main point is that the development environment, if you stick to the chosen analogy, will act as a browser of the source code with the ability to edit it. That is, we will see / edit not the source code in its final form, but the code in a representation that is more convenient for us at one time or another. Just as we are now in the browser, we see not the HTML source, but something more “pleasant.” What do we solve it? In my opinion, very much.
')
1. The problem of unifying code formatting is solved. Each individual developer does not care about formatting the code, and in the settings of the development environment exposes those parameters that are more convenient for him. Let's say indents, right edge, etc. As a result, different developers can work quietly with the same code, but in a different representation.
2. Solves the problem of separation of entities. Well, in the most common example, these are types and variables. Now it is solved as horrible, for example, in Java types it is customary to write with a capital letter, variables with a small one, in Delphi types start with “T”, etc. But all this is rather clumsy. In the proposed approach, the type declared by the user, say, Table will look like Table only for the user, for the environment it will be something like <type name = "Table" />, it’s not important time will know that this is the type of data, 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 exactly what the Table is in front of him, since he will always be highlighted in a special way, for example, with a font and / or color.
3. The problem of documenting the source code is solved. Yes, of course, now there are tools, such as JavaDoc, but besides dubious aesthetics, it also has a number of limitations. Try, for example, to describe the code in different languages or to describe each parameter of the function separately. In the proposed approach, there will be no such problems. We can easily attach an arbitrarily large and arbitrarily multilingual documentation block to literally every word of code. In this case, the documented text will be completely invisible to the user as long as he does not want to see it.
4. We will be able to store any resources, up to sounds and pictures, directly in the source code, and associating them with it directly. The most common example for this is probably 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 steady and convenient and, probably, more functional.
5. The following, now completely unthinkable constructions, such as
or the description of the parameters of the function in the form of a table, and the elements of the class in the form of a tree.
6. Localization directly in the source code. That is, for example, we can set several values for the same string constant. In the editor, it will look something like this:
const Message = "Hello world!";
With the exception of there may be some icon next to, when clicked, you can view / correct the text in any language.
Yes, of course, the proposed approach has its drawbacks and some will quite rightly point out them, and some, quite possibly, will go further and the whole idea will be called nonsense. But, as for me personally, I am absolutely convinced that movement in this direction is inevitable. The only question is who will take the first step and when.
Perhaps I’m a bit of a twist 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.
I proceed from the fact that the overwhelming majority of developers have not written in text editors for a long time, and to some extent uses sufficiently advanced development tools. I propose to take another fundamental step in this direction. Namely, to get away from the flat-text way of working with source codes. Take the analogy, for example, the same HTML, in fact, is not the point. The main point is that the development environment, if you stick to the chosen analogy, will act as a browser of the source code with the ability to edit it. That is, we will see / edit not the source code in its final form, but the code in a representation that is more convenient for us at one time or another. Just as we are now in the browser, we see not the HTML source, but something more “pleasant.” What do we solve it? In my opinion, very much.
')
1. The problem of unifying code formatting is solved. Each individual developer does not care about formatting the code, and in the settings of the development environment exposes those parameters that are more convenient for him. Let's say indents, right edge, etc. As a result, different developers can work quietly with the same code, but in a different representation.
2. Solves the problem of separation of entities. Well, in the most common example, these are types and variables. Now it is solved as horrible, for example, in Java types it is customary to write with a capital letter, variables with a small one, in Delphi types start with “T”, etc. But all this is rather clumsy. In the proposed approach, the type declared by the user, say, Table will look like Table only for the user, for the environment it will be something like <type name = "Table" />, it’s not important time will know that this is the type of data, 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 exactly what the Table is in front of him, since he will always be highlighted in a special way, for example, with a font and / or color.
3. The problem of documenting the source code is solved. Yes, of course, now there are tools, such as JavaDoc, but besides dubious aesthetics, it also has a number of limitations. Try, for example, to describe the code in different languages or to describe each parameter of the function separately. In the proposed approach, there will be no such problems. We can easily attach an arbitrarily large and arbitrarily multilingual documentation block to literally every word of code. In this case, the documented text will be completely invisible to the user as long as he does not want to see it.
4. We will be able to store any resources, up to sounds and pictures, directly in the source code, and associating them with it directly. The most common example for this is probably 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 steady and convenient and, probably, more functional.
5. The following, now completely unthinkable constructions, such as
or the description of the parameters of the function in the form of a table, and the elements of the class in the form of a tree.
6. Localization directly in the source code. That is, for example, we can set several values for the same string constant. In the editor, it will look something like this:
const Message = "Hello world!";
With the exception of there may be some icon next to, when clicked, you can view / correct the text in any language.
Yes, of course, the proposed approach has its drawbacks and some will quite rightly point out them, and some, quite possibly, will go further and the whole idea will be called nonsense. But, as for me personally, I am absolutely convinced that movement in this direction is inevitable. The only question is who will take the first step and when.
Source: https://habr.com/ru/post/151678/
All Articles