Text Editors vs IDE
Recently, there has been a tendency of meaningless, from my point of view, discussions as to what is better - a text editor or IDE. At the same time, the topics where this issue is discussed are often 400 or more comments. So people are interested in this question. So you have to write an article.
So what are the goals of the article?
1. What is better for programming: a text editor or IDE
2. Vim and Emacs are not text editors.
Let's start with what programming is. Programming is the process of writing lexical, syntactic, semantic rules specified in the specification of a programming language (hereinafter referred to as PL), followed by its testing and obtaining a satisfactory final result.
So, programming is:
1. Writing the rules specified in the specification of the PL
2. Testing written rules
')
The whole essence of disputes arises, due to the fact that for the implementation of each item there is no clear set of rules. And for each person, based on his personal or team needs, certain tools are used. In other words, the choice of tools for the implementation of the full programming cycle is subjective. And if two or more people who do not understand this, a dispute or discussion begins, which does not carry any result, except for mutual hostility. I propose to disassemble each item separately, in order to separate flies from cutlets, otherwise the semantic component will tend or equal to zero.
In simpler language, programming is writing a text. Which implies input, editing and navigation, as well as syntax highlighting (the latter separates simple typing and text editing from programming). There is another item, but it will be discussed below. These actions are sufficient to implement this clause. All these simple actions are in any text editor or IDE. The only question is
what methods are used and how great their effectiveness. At the moment there are only three main options for implementation:
a) classical universal
b) modal
c) classic refined
The classic input method is used in almost all IDE and some basic level editors (a vivid representative of which can be called mcedit, nano), and text editors, which are basic level IDEs (which are disguised as a text editor for programming). A prominent representative of which is kate, geany.
The modal input method implies a change in the behavior of the editor depending on the modes. One of the most prominent representatives is Vim. And fork this eponymous product.
The classic advanced input method is presented to varying degrees in all IDEs and a text editor for a programmer, which is Emacs.
And here disputes immediately begin on which method of input, editing and navigation is better in the context of programming. And disputes are usually guided by only two points:
1. The method of input, editing and navigation is not critical
2. The method of input, editing and navigation is fundamental
Usually, when there are two or more people who have a diametrically opposite view of this issue, a dispute or dispute turns into a chaotic monologue from two sides. The result of which tends or equals zero.
Everyone has their own truth, and the truth is one. And the truth in this case is that the second type of people are right at 99.9 (9)%. Efficiency is important in any craft or its component. Whether it is knitting brooms or writing text. Why? Because an increase in the efficiency of any constituent inevitably leads to an increase in the efficiency of the whole process. Who does not understand this - he does not understand and explain why it is unlikely to succeed. Unfortunately or joyfully, it depends on the goals and aspirations of the opponent \ s.
So, there is 100% of the time, of which a certain percentage of time is spent on entering, editing and navigating through the written code. An increase in the efficiency of the components leads to an increase in the productivity of the entire programming process.
Nothing special to say. This method is sufficient for “Writing rules specified in the specification of the PL”. There is nothing more to say about this text management method. There is no point in explaining all its advantages and disadvantages, because if there were fewer disadvantages than advantages, then two alternative text management options would not have appeared.
Text input is carried out in one of the modes. Editing and navigation are in different \ their modes. The advantage of this method is that with these two modes it does not waste time on moving the programmer’s hands outside the block of characters. This means that the programmer does not need to move his hand on the mouse or on the arrows to the left \ right \ up \ down and block above (insert \ delete \ home \ end \ page up \ page down). On the one hand, it increases productivity, on the other hand, it eliminates diseases of the joints of the hands.
This type of text management appeared due to the lack of classic text management. Then I set out my own, subjective, view of this method of management. The advantages of this method are that some editing and navigation operations are placed on certain hot keys. On the one hand, this increases productivity, but on the other hand, if a hot key is not chosen correctly, it leads to muscle fatigue and / or unusual position of hands or hands and unusual finger movements, which in turn leads to the appearance of a disease like tunnel syndrome.
If we compare the advantages of this method with the modal, namely two vivid representatives of two control methods - Vim and Emacs, then very few people understand that Emacs is also modal, but it has an indirect modality. And this indirect modality is the reason why many choose Vim rather than Emacs. Why? This question you have to ask yourself. If you fail to give an answer to it, then most likely you don’t need it.
Testing of written rules is carried out using two methods:
1. Embedded in PL
2. External tools (scripts, cli tools)
Both the first and second paragraph c are implemented both in text editors and in the IDE. The only question is competence, laboriousness and expediency of the hours spent on their implementation. At the same time, in Vim and Emacs products, which are NOT text editors, in the basic delivery of the implemented methods or not, or they are in a deplorable state.
These products are not text editors. These are powerful frameworks for building highly efficient IDEs. Since both the one and the second are fully programmable. Starting from changing behavior, to integrating processing tools, in order to test written rules.
The lack of functions that are in the classic IDE, says that these frameworks are used by people who use other, different, methods for testing written rules, and these people / commands do not need to implement them. The only weighty argument from the world of classic IDEs is contextual editing of rules, which is not in the two frameworks mentioned above. And it is not for all the same reason that was mentioned above.
Question: And yet, what is better, IDE or text editors?
Answer: Programmable frameworks for building highly efficient IDEs! With one caveat: if necessary.
So what are the goals of the article?
1. What is better for programming: a text editor or IDE
2. Vim and Emacs are not text editors.
1. What is better for programming: a text editor or IDE
Let's start with what programming is. Programming is the process of writing lexical, syntactic, semantic rules specified in the specification of a programming language (hereinafter referred to as PL), followed by its testing and obtaining a satisfactory final result.
So, programming is:
1. Writing the rules specified in the specification of the PL
2. Testing written rules
')
The whole essence of disputes arises, due to the fact that for the implementation of each item there is no clear set of rules. And for each person, based on his personal or team needs, certain tools are used. In other words, the choice of tools for the implementation of the full programming cycle is subjective. And if two or more people who do not understand this, a dispute or discussion begins, which does not carry any result, except for mutual hostility. I propose to disassemble each item separately, in order to separate flies from cutlets, otherwise the semantic component will tend or equal to zero.
1. Writing the rules specified in the specification of the PL
In simpler language, programming is writing a text. Which implies input, editing and navigation, as well as syntax highlighting (the latter separates simple typing and text editing from programming). There is another item, but it will be discussed below. These actions are sufficient to implement this clause. All these simple actions are in any text editor or IDE. The only question is
what methods are used and how great their effectiveness. At the moment there are only three main options for implementation:
a) classical universal
b) modal
c) classic refined
The classic input method is used in almost all IDE and some basic level editors (a vivid representative of which can be called mcedit, nano), and text editors, which are basic level IDEs (which are disguised as a text editor for programming). A prominent representative of which is kate, geany.
The modal input method implies a change in the behavior of the editor depending on the modes. One of the most prominent representatives is Vim. And fork this eponymous product.
The classic advanced input method is presented to varying degrees in all IDEs and a text editor for a programmer, which is Emacs.
And here disputes immediately begin on which method of input, editing and navigation is better in the context of programming. And disputes are usually guided by only two points:
1. The method of input, editing and navigation is not critical
2. The method of input, editing and navigation is fundamental
Usually, when there are two or more people who have a diametrically opposite view of this issue, a dispute or dispute turns into a chaotic monologue from two sides. The result of which tends or equals zero.
Everyone has their own truth, and the truth is one. And the truth in this case is that the second type of people are right at 99.9 (9)%. Efficiency is important in any craft or its component. Whether it is knitting brooms or writing text. Why? Because an increase in the efficiency of any constituent inevitably leads to an increase in the efficiency of the whole process. Who does not understand this - he does not understand and explain why it is unlikely to succeed. Unfortunately or joyfully, it depends on the goals and aspirations of the opponent \ s.
So, there is 100% of the time, of which a certain percentage of time is spent on entering, editing and navigating through the written code. An increase in the efficiency of the components leads to an increase in the productivity of the entire programming process.
a) classical universal
Nothing special to say. This method is sufficient for “Writing rules specified in the specification of the PL”. There is nothing more to say about this text management method. There is no point in explaining all its advantages and disadvantages, because if there were fewer disadvantages than advantages, then two alternative text management options would not have appeared.
b) modal
Text input is carried out in one of the modes. Editing and navigation are in different \ their modes. The advantage of this method is that with these two modes it does not waste time on moving the programmer’s hands outside the block of characters. This means that the programmer does not need to move his hand on the mouse or on the arrows to the left \ right \ up \ down and block above (insert \ delete \ home \ end \ page up \ page down). On the one hand, it increases productivity, on the other hand, it eliminates diseases of the joints of the hands.
c) classic refined
This type of text management appeared due to the lack of classic text management. Then I set out my own, subjective, view of this method of management. The advantages of this method are that some editing and navigation operations are placed on certain hot keys. On the one hand, this increases productivity, but on the other hand, if a hot key is not chosen correctly, it leads to muscle fatigue and / or unusual position of hands or hands and unusual finger movements, which in turn leads to the appearance of a disease like tunnel syndrome.
If we compare the advantages of this method with the modal, namely two vivid representatives of two control methods - Vim and Emacs, then very few people understand that Emacs is also modal, but it has an indirect modality. And this indirect modality is the reason why many choose Vim rather than Emacs. Why? This question you have to ask yourself. If you fail to give an answer to it, then most likely you don’t need it.
2. Testing written rules
Testing of written rules is carried out using two methods:
1. Embedded in PL
2. External tools (scripts, cli tools)
Both the first and second paragraph c are implemented both in text editors and in the IDE. The only question is competence, laboriousness and expediency of the hours spent on their implementation. At the same time, in Vim and Emacs products, which are NOT text editors, in the basic delivery of the implemented methods or not, or they are in a deplorable state.
2. Vim and Emacs are not text editors.
These products are not text editors. These are powerful frameworks for building highly efficient IDEs. Since both the one and the second are fully programmable. Starting from changing behavior, to integrating processing tools, in order to test written rules.
The lack of functions that are in the classic IDE, says that these frameworks are used by people who use other, different, methods for testing written rules, and these people / commands do not need to implement them. The only weighty argument from the world of classic IDEs is contextual editing of rules, which is not in the two frameworks mentioned above. And it is not for all the same reason that was mentioned above.
Question: And yet, what is better, IDE or text editors?
Answer: Programmable frameworks for building highly efficient IDEs! With one caveat: if necessary.
Source: https://habr.com/ru/post/306048/
All Articles