Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to understand editor thinking and system design ideas". The content of the explanation in this article is simple and clear, and it is easy to learn and understand. let's study and learn "how to understand editor thinking and system design ideas"!

Preface

Compared with the history of human society, the history of computers is so short that the fifties and sixties of the last century can be called ancient times. But the history of computers is magical, and early ideas are often very advanced and advanced. For example, EJB technology was proposed in 1998, but its design is very advanced, such as micro-services and other technologies are more or less draw lessons from its ideas. By understanding the history of the development of computer technology, we can often find many creative ideas that can help us solve current problems. So, today, I'd like to break the historical gossip of Emacs and Vim, two enduring antique software, and see if there is anything worth learning.

Vim's gossip

Vim genealogy

Starting with the origin of the Vim editor, the following figure shows the genealogy of Vim:

The predecessor of Vim was the ed editor:

Ed, one of the oldest programs on the UNIX system, has been resident since the first version, written by Ken Thompson (one of the authors of UNIX). It provides basic Line-oriented editing commands.

Ex is a superset of ed, Bill 喜悦 (one of the founders of Sun) enhanced ed when developing BSD, so he named it ex. But ex is still a line-oriented editor.

Bill 喜悦 then provided a visual interface (Viusal Interface) for ex, providing full-screen editing capability, so it was named vi.

In order to port vi to Amiga machines, Bram Moolenaar developed Vi IMitation (Vi imitation). With the increasing number of features, the name has been upgraded to Vi IMproved (improved version of Vi), or Vim.

Ed Editor

Ed is very different from modern editors such as VSCode and Sublime Text. As mentioned earlier, it is a line editor (highlighted here), that is, the edited object is an entire line of text.

Ed is divided into command mode and editing mode. After starting ed, it enters the command mode by default and waits for the user to enter one command after another. By executing these commands, ed finally achieves the goal of editing the file. Students who use Mac computers can try to execute ed in the terminal. The format of the ed command is [addressing] [command]:

Addressing: select the target line to be operated. Ed provides three addressing methods: line number: an integer starting at 1; and $represents the last line. Pattern: select the row that matches the regular expression. By default, the first matching row is selected, starting with the current row. Such as / re/. Add the prefix g to make a global match. For example, g/re/ range: an addressing range consisting of two addresses, [address], [address]. Such as / BEGIN/,/END/

Command: represented by a single character. The following is the most commonly used command: P: show, output the target line. I: insert, inserting the content into the previous line of the target line. A: append, append the content to the next line of the target line. C: change, replace the contents of the target line. D: delete, delete the target line. S: replace, replace the matching line content with a regular expression.

The I, a, c commands make ed enter edit mode from command mode, and enter a line in edit mode. Returns to command mode. Here are a few examples of ed editing:

Delete all blank lines: G / ^ $/ d. Globally search for the regular expression / ^ $/ with the prefix g and execute the delete command.

Output all lines that contain "re": g/re/p. Similarly, globally search for the regular expression / re/, and execute the display command. Because this function is so commonly used, a command "grep" has been specially developed.

Editor thinking

As mentioned earlier, the ed editor is very different from the modern editor, it is actually an editing command interpreter, but the ed editor is very much the same as the modern editor, the essence of all editors is to constantly execute "addressing" and "commands". The only difference between different types of editors is that they edit different objects:

Ed is the text line editor: the object you edit is the text line.

Microsoft Word is a document editor: the object of editing is the document elements such as chapters, paragraphs, words, etc.

Sketch is a graphic editor: the objects you edit are points, lines, faces, and other graphic elements.

IntelliJ IDEA contains the Java code editor: the edited objects are Java semantic elements such as classes, methods, statements, and so on.

JQuery is the DOM editor: the object being edited is the DOM element. First use CSS Selector addressing, select the DOM element you want to process, and then perform a series of editing actions with a contiguous expression.

……

Thus it can be seen that editor thinking is everywhere, as long as it meets the "addressing + command" mode, it can be called an editor, so everything can be edited! The essence of editor thinking, or editing, in terms of what developers are more familiar with is CRUD:

If anyone questions that the developer is just doing simple additions, deletions, changes and queries in the future, please bravely tell them: in fact, I am doing a vertical editor!

If you realize that what you are doing is actually an editor, you can use editor thinking to quickly discover the shortcomings of the system's capabilities. Take the commodity management system as an example, if the commodity management only provides the function of querying goods through ID, just as the ed editor only supports addressing by line numbers, it is very inconvenient to use. We can learn from the pattern matching addressing ability of ed through regular expressions, and provide the ability to match goods through information such as commodity names, or even similar goods through commodity photos. Similarly, the ability to create goods can also draw on the ability of the editor to copy and paste, provide the ability to quickly create new items with similar items, and even provide the ability to move from other platforms.

Ed's genealogy

The previous article only introduced the interactive editing function of ed. In fact, ed also supports scripting editing, that is, saving the editing commands input to the terminal as a script file for subsequent repeated runs. The advantage is that you can batch edit as many files as you want with the same editing command.

The above picture is the genealogy of the ed editor, and the subsequent derivative programs select and increment some of the capabilities of ed. For example:

The branch of ex, vi, and vim chooses the interactive route.

Grep, fgrep, and egrep chose the pattern matching route.

Sed and awk chose the scripted route.

Emacs's gossip

Defected from the Vim camp

I used to be a heavy user of Vim, because the operating system used in college is Debian Linux, whether it is writing C code or Java code, it is a shuttle in Vim. The advantage is that you can write directly in a closed written exam, while the students who use Eclipse basically can't remember the full name of JDK API. :-p

After graduation, I joined a foreign company and had to start using the Windows XP system. When I wrote something in my notepad one day, I found that I would often unconsciously press the Esc key. Students who have used Vim must know that this is switching mode. I realized that the multi-modal design of Vim is very anti-human. When Vim starts, it doesn't enter editing mode by default, and when novice users haven't learned anything, they can't use Vim as a normal notepad. There was a joke about Vim about how to get a string of random codes, and the answer was to let a Vim novice try to quit Vim.

This approach is not to my taste, and I try to find a new editor-when nothing is learned, it can be used as the most common notepad, and when advanced features are needed, it can be called out through shortcuts and other ways. It turns out that Emacs happens to meet this requirement, so I defected from the Vim camp to the Emacs camp since 2010. I think this difference in usage is the most fundamental difference between Vim and Emacs: Vim forces users to follow its rules from the start, while Emacs requires relatively little pre-knowledge. There has been a learning curve of an editor on the Internet, which is quite appropriate:

The Origin of Emacs

Ed, the predecessor of Vim, comes from UNIX system, while TECO, the predecessor of Emacs, comes from Multics system, which is the predecessor of UNIX system.

In the 1970s, Richard Stallman, the founder of GNU, invented the TECO editor while working in MIT's AI lab, which runs on PDP-10 machines. Like ed, TECO is also a command interpreter-- receives and executes editing commands-- and uses a single character as the command name, such as "l" to move one line and "5l" to move five lines. MIT group of bosses want to use TECO commands to complete some complex editing work, so they added branch judgment, looping and other functions; but due to congenital deficiencies, TECO did not design the command into a complete programming language, resulting in subsequent improvements are also very difficult, such as the command name can only be a single character, and soon the characters will not be enough.

The so-called foundation is shaky, and we all agree that we need to replace TECO's semi-finished scripting language with a rigorous and complete programming language. So a professor named Bernie rewrote TECO with MacLisp on the Multics system and named it Emacs, and wrote a detailed manual for it to teach people how to extend the editor to meet the needs of their work. As a result, this version of Emacs was so successful that even Bernie's secretary-- who claims to know nothing about programming-- followed the manual and wrote Lisp code to extend the editor's functionality. After this caused a sensation in the lab, Bernie made a summary of it: if there is an application-- a program that can help you do something useful-- it is embedded in Lisp and can be expanded through the Lisp program, which is a very good way to start learning programming! For those who think they can't program, this approach will give them the opportunity to write small but useful programs and grow in practice until they find that they are programming.

Stallman, they think it's a really cool idea! At the same time, they wanted to migrate this useful version of Emacs to other systems outside the Multics system, but only Multics systems had a complete Lisp environment-- both compilers and interpreters-- not on systems such as UNIX.

Here is another episode. James Gosling, the father of Java, wrote a cross-platform version of Emacs called Gosmacs. Originally, the community wanted to work together to improve this version, but Gosling sold it to a commercial company, and its underlying Lisp is not a real Lisp, but a fake Lisp called Mocklisp, which is syntactically similar to Lisp. So the community eventually gave up this option and decided to make a new Emacs, or GNU Emacs, from scratch. Stallman first uses C language to develop a cross-platform Lisp interpreter-Emacs Lisp, and then uses Lisp to implement editing logic. This allows you to write Emacs extensions in the same Lisp dialect on all platforms while taking into account performance.

After GNU Emacs developed for a while, because Stallman was too busy on its own, the community created a branch called XEmacs, which enhanced font anti-aliasing and other features. Later, the maintenance of GNU Emacs became active again, merging many XEmacs features back to GNU Emacs, so now XEmacs is almost abandoned, and the mainstream version is still GNU Emacs.

System design

Editor jihad

The world of programmers is full of disdain chain, including editor contempt chain, programming language contempt chain, operating system disdain chain. Why these jihad can never be finished, is it like in Gref's travels that the Lilliputian launched a war by debating whether to peel eggs and break the big head or the small head, or is it really impossible to have both?

As mentioned earlier, Vim likes to force users to do things in its own way. Vim inherits the features of the line editor from ed, and the underlying model is based on "rows", so it forces all edited objects to fit into its underlying model. You use Vim to write Java code, you edit the line of text; you use Vim to write a blog, you edit the line of text; you use Vim to write a paper, you edit the line of text; whether you edit classes, functions, paragraphs, directories or any other content, you must first translate in your mind the corresponding dd, yy and other line-oriented editing commands.

Emacs is a personalized editor that allows users to transform Emacs into a target object, which can recognize the target model, such as paragraphs, chapters, catalogs, etc. In a fashionable way, Emacs has an industry Know-How. The same example: write Java code in Emacs, and you edit classes, methods, statements. You use Emacs to write a blog, and you edit paragraphs and sentences. You write a paper in Emacs, and you edit the catalogue, chapter, text, index.

Two design methods

The reason for the above difference is that there are two different design methods behind it, called top-down (Top Down) and bottom-up (Bottom Up):

The method describes the top-down, bottom-up description of splitting large tasks step by step into small tasks with appropriate granularity-- small enough and able to do something practical-- perfecting the underlying programming language, etc.-- making the underlying infrastructure constantly approach the business domain-- to adapt to the advantages of the task. The goal is clear, the iteration is fast, the function is complete, the adaptability is too tight with the current demand, the ability to cope with change is weaker, and the progress is slow.

Editing with Vim is a top-down approach-- the editing task is continuously split and eventually split into line-oriented editing commands; just like the daily development of Java, it is split step by step and eventually split into JDK's API. Emacs editing is a bottom-up approach-- first improve the underlying Emacs Lisp language, gradually abstract the business-oriented domain-specific language, and finally use DSL to complete the editing task; for example, to edit an Markdown document, it will provide specific editing operations for the Markdown domain, such as moving to the next paragraph, the next list item, the next cell of the table, and so on.

The difference between the two design methods does not mean that the code is written in a different order, but the difference in the abstraction process of the system, which is finally reflected in the difference of system expansibility. I personally divide the scalability of the system into four levels:

Hard coding: when the system is running, the data and behavior are written dead and cannot be changed.

Configurable: when the system is running, the data can be changed dynamically, but the behavior is fixed.

Controllable: when the system is running, the data can be dynamically changed, and a variety of predefined behaviors can be dynamically selected.

Programmable: when the system is running, the data can be changed dynamically, and the behavior can be dynamically added during the operation, that is, the user can redo the system behavior.

The top-down extreme is hard-coding, which prematurely limits functionality to current requirements, and later requirements can only approach the initial model as much as possible; the bottom-up extreme is programmable and easy to transition design. provide flexibility for scenarios that cannot be changed in the future, or even become a general-purpose programming language.

There is no absolute right or wrong between the two design methods, and each has its own applicable scenarios. Using either method alone will have problems, and it is necessary to make a tradeoff between rapid implementation and system expansibility according to the actual situation. It is precisely because there is no difference between right and wrong that the jihad of the editor can never be finished.

Thank you for your reading, the above is the content of "how to understand editor thinking and system design ideas". After the study of this article, I believe you have a deeper understanding of how to understand editor thinking and system design ideas. The specific use of the situation also needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.