Modern IDE. Definitely D, to some extent E, and certainly not I
I am working, therefore, on my research about the difficulties of supporting Legacy, and I noticed one obvious point that I completely lost sight of.
IDE users and IDE developers have problems understanding their tools. Used intuitively and anyhow. Surprisingly (pleasant), such use almost does not conflict with ignorance, although it generates corresponding holivars on the forums.
Now we will analyze how things are in development with tools, what is wrong with the concept of "IDE", and which tools should have appeared, but have not yet been developed.
E
It will not be a discovery that the environment is different for different projects. Even if they work on one stack. Can be used:
- Different ways of interacting with the user, which gives a big discrepancy on how the project starts and how it is tested. (CLI, TUI, web muzzle, GUI in the sense of Qt, GTK, etc.)
- Different test frameworks (unittest in one project, pytest in an adjacent one, in the context of Python). The bindings of multilevel tests (for example, combining the conclusions of stand-alone tests and integration through TAP) also fall here.
- Different VCS, but somewhere there may be hybrids (Git, as a client for Subversion in a special case).
- Within the same project can be used, including different editors. For example, Vim or nano for editing an interactive rebase script in Git, for editing chunks with partial registration of changes. Or to edit configs from under the root.
And these are far from all the options, I think that any developer with experience of 2 or more projects can throw more similar examples. Often I hear them in the form of the story "How I spent two days to set up a project for a new job."
From this we can conclude that the layout and configuration of the development environment in any case lies with the user.
Integrated?
Given the above, it makes sense to consider not "integrated", but "integrable" environments.
Then, from the user's point of view, a good integration tool is when:
- The environment is set up quickly.
- Its configuration can be stored and transferred.
- Ability to re- raise the working environment "one button".
For example, experienced Unixoids often reduce the "transition to working mode" to one team.
"Fast" here does not mean "easy for a beginner . " Personally, my position on this issue is: the dependence of the complexity of the solution of the problem on the complexity of the task itself should be at least linear.
Another peculiar aspect: the interface can be no one.
The most common example is using both the GUI and the CLI in a project.
I spoke about the use of several editors when working in the same environment on the same project.
Development
Now we can proceed directly to the tools themselves.
Reactor Browsers
It is impossible to create a powerful and universal browser refactor simply because refactoring does not exist now, as, conditionally, an academic discipline.
Fowler’s book , after all, is built around Java with minimal steps to the side. Plus, refactoring techniques are so attached to the "style-language-library" context that they are generated right on the spot by every single programmer.
I believe that the basic principles of refactoring can be described from the point of view of traversing the data tree in sections of code, and specific techniques can already be drawn from them . To do this, the browser refactor implementation should have:
- Easily extensible interface (to display the techniques created by the developer for his specific needs)
- The analyzers, the base (the aforementioned principles) and the editing scheme must be hidden in order to leave the developer the opportunity to expand the set of techniques without having to go into the guts of his editor. That is, DSL for describing refactoring techniques.
- Since extensibility will be followed by a sharp increase in the number of receptions, for display it is necessary to take into account the context scope in order to display in the selection menu only the operations applicable in a particular situation.
Runtime data tree analysis.
This aspect is about combining debugging and text editing. In fact, for the vast majority of languages, in order to check how changes affect the program, an explicit restart of the program is necessary. Much easier and more visual (and, as a result, with fewer possible errors), it will be possible to see in a single space how the entire data array in the debugged section of the code changes right as the code is edited .
The development of such a tool for different languages diverges greatly in complexity, and it is not only a matter of syntax, type system and performance features, but the essence of each individual language. For a Data Driven language, building this is a lot easier. Example: regular expression constructors, where in the process you can immediately see which parts of the text are covered by the regular structure being created.
Information and knowledge
The most, in my opinion, the most important item in this incomplete list.
We divide all the information the developer needs for, directly, programming into two large groups
- Documentation.
- Receptions \ development heuristics.
Firstly, to simplify the work of the programmer, access to the documentation should be directly from the editor window.
Various IDEs and editors solve this problem well: language specific IDEs from Microsoft, Emacs with its Info-mode, Frescobaldi, Sunny Builder; both for integrated into the source, and for external. However, many libraries and frameworks now upload their documentation only on the network and / or use different formats to store it, which complicates the possible integration into a single interface.
The second group is much more interesting.
It covers knowledge, both programming and development as a whole, and techniques specific to a particular language / stack. At the moment, this niche is almost entirely captured by Stack Overflow, and there is even its integration into the IDE, but the quality of expertise there is often low . For good, it will be much more efficient to select good decisions, mistakes, tricks and reduce it to a certain base, which the user can contact when he needs to solve his own problem.
In addition, modern analyzers allow you to warn about possible, not yet committed , errors. That is, in fact, we have, from a technical point of view, everything necessary for creating expert systemsfor developers offering solutions as they write / edit code. What is missing is only the decision bases / methods / errors themselves.
Conclusion
So, the summary:
- The development of refactor browsers should be based on operations on the data tree and be reduced to a DSL-like description of scripts for automated code editing.
- Runtime analyzers should come to the instant display of data changes during editing and writing a program. That is, the JAI approach can be applied to other programming languages.
- To remove the web browser from the user cases as a way to search and read the documentation.
- We need to develop plug-in (due to the fact that the environment is diverse) expert systems that will help the developer make decisions in the process.