With the system language, why do we need a scripting language?

The scripting language, defined in Wikipedia, is a computer programming language created to shorten the traditional compilation-link-run process. It is usually simple, easy to learn, and easy to use. The purpose is to hope developers can quickly complete the compilation of some complex programs in a simple way ". Common programming tools, such as Ruby and Python, and JavaScript and Lua, are common programming tools that we have learned and learned from time to time.

The scripting language, defined in Wikipedia, is a computer programming language created to shorten the traditional compilation-link-run process. It is usually simple, easy to learn, and easy to use. The purpose is to hope developers can quickly complete the compilation of some complex programs in a simple way ".

According to this, the current wide range of computer languages can even be said to be three points in the world today, and the scripting language already occupies the second place. Complex programming tools such as Java and C #, common such as Ruby and Python, and simple such as JavaScript and Lua are common programming tools that we have heard and learned over the past. Most of them are independent and can be used to directly compile software with complete functions. In addition, the scripting language does not have high requirements on the quality of developers, and the development process is also short and fast. the version iteration cycle is gradually shortened, the extreme programming that has been popular in the past few years is also possible by taking advantage of this trend. As far as the market is concerned, it is also a fact that script language development is used. if there is no need for software companies to never access the system language.

Therefore, there are only a few systems languages on the market, such as C, C ++, Obj-C, Fortran, and Pascal. developers who use them are scarce resources, the companies that use them can be said to be large and high-end enterprises (it seems that they have rebounded with the development of the iOS platform ). I even dared to say that there were developers who never touched the system language for a lifetime.

The above description shows that the biggest difference between the system language and the scripting language is that the former usually directly generates executable files and has good operation and control capabilities on the computer system, and excellent execution efficiency; the latter runs on the additional abstract machine layer, shielding the direct control of computer systems, which also causes relatively low execution efficiency.

In other words, the system language must be able to do something that the scripting language can do (because it is theoretically based on a Turing machine or its equivalent model). On the contrary, what the system language can do is, even if the script language is barely completed, its execution efficiency is also very different. For example, operating systems, compiling systems, and other system software usually use the system language as the development tool. Of course, it is not ruled out that the script language is used, but it can only be regarded as a wonderful entertainment. no hero will use it.

As a matter of fact, we don't have to give up without discrimination. The system language and scripting language have their own advantages. we should develop strengths and circumvent weaknesses. This is why I am optimistic about game programming. it not only perfectly integrates a variety of artistic forms such as literature, painting and music, but also applies the technology. From game programming, we can at least learn one thing, that is, distinguish between the main application (game engine) and module application (game content ). That is to say, we will use the system language to develop core logic modules with little change, and use the script language to develop frequently changed modules, and finally integrate the two, or embed the script into the main application.

However, this method is not a novelty. Because we can use the dynamic connection module to install a large and medium-sized software, it is normal to see a pair of. dll. These are some system language and program segments, which are compiled with local machine codes and loaded as links when the main program is running. Its execution efficiency is the same as that of the main program and can achieve the above modular purpose. isn't it the silver bullet we dream?

So why do we have to embed scripts in system language programming? Why do we have to choose an inefficient solution? Is it easy to develop system languages? I'm sorry, Marx. The rise of scripting naturally has inherent requirements, for the following reasons:

1. lower the development threshold and improve development efficiency:

The difficulty of system language development is not nonsense. The so-called success, failure, and operation capabilities of hardware also make developers have to pay attention to the bottom layer of the machine. if they are not from a class, it is really difficult to apply them. even if they are not from a class, they will not be very skilled. In short, it is rare for someone to make full use of the true strength of the system language.

Moreover, for the development of general application software, there is no need to control the hardware, and there is no need for those difficult to grasp in the system language. Using the system language is tantamount to killing the chicken with a knife.

Furthermore, for the development of software companies, the execution efficiency of software is far less important than the development efficiency, saving one minute and earning 10 thousand yuan. Without the complexity of those features, you can naturally program more easily, and even people who have never learned programming can quickly deploy and develop, increase manpower at any time, without disrupting the entire project. So the more scripting languages are used, the more financial resources are available. why not?

2. enhanced development flexibility and updated convenience:

The functions and requirements of many application software change with the progress of the project, which can be said to be the norm of project development. Although I have carefully discussed the issues before development, I have made many inquiries and made clear requirements. However, the plan cannot keep up with the changes. we have to modify many of the completed modules frequently.

If the code is hard-coded and written to the main program, even some minor modifications have to be completely re-compiled. This is quite acceptable for the project. if the source file has dozens of megabytes or even hundreds of megabytes, it will be a little painful. In particular, if the performance of the sub-host is limited, it may also crash, and everything will go far. Even if you use the link library, you still need to re-compile the module and re-link loading. this is also very troublesome.

What is even more worth looking forward to is that many application software will now release the first version or trial version on the official website. They only have partial functions of the full version. after the user buys them, the other parts will be delivered to the user in the form of patches. If you use a dynamic link, you have to download the patch package explicitly, and then install the link for half a day. you may also encounter rollback failures due to configuration file errors! On the contrary, scripts can be run after being implicitly transmitted to the target machine using the background network, or directly decompress the patch package after downloading it. In this way, developers can fix bugs and add new features at any time. (It's a big operation to update the main program, so I won't talk about it)

3. reduce the coupling degree with the main program:

People are not sages. it is common to make mistakes by using system language development. these errors are often concealed and extremely painful to check and debug. Even after a lot of time is wasted, it turns out that a character is wrong. In addition, some insignificant bugs may directly Cut down the entire process. this is a tragedy for users. think about how many elderly people are scared to death on the blue screen.

If a module is often changed, the probability of making a mistake is even greater. Don't forget, the modularization is because changes are often needed. Therefore, we need to reduce the coupling between these modules and the main program that will not be modified frequently, so as to ensure software stability as much as possible. If a dynamic link library is used, the coupling degree is not significantly reduced during running, because the link is always a whole and runs on the local machine. If an error occurs, the link is still Cut, never neglect.

On the contrary, the scripting language runs in the interpreter or virtual machine, isolating the real machine (real or hardware abstraction layer ). In addition, they all have the exception handling function, which can easily capture the exceptions of script running and handle the exceptions accordingly, this prevents software running from crashing immediately due to small bugs.

4. enhanced code reusability:

Just as the Java advertisement "one compilation and four operations", this is also our dream feature, saving a lot of energy and energy. The system language is also said to be highly portable, but at most the source files can be reused, while the script language can be fully reusable.

In this way, we do not need to recompile the source files when developing different versions of different platforms. What's more, you don't need to use different platforms to support libraries (such as DirectX and OpenGL.

In addition, the scripts written in this project can even be directly used in other projects. you only need to copy and paste the scripts and use them directly. you do not need to distinguish between SDKs and runtime.

5. prevent users from performing reverse engineering:

If the system language is directly compiled and connected to an executable file running on the local machine, the running logic will be known and no software can be cracked. However, the script language is often compiled into bytecode and is specially encoded. at least there is no decompilation tool available. Even when you use some debugging tools, you can only see the running status in the virtual machine or interpreter. This greatly increases the difficulty of reading, but it is impossible to completely secure it. you can always crack it if you want to crack it.

In the final analysis, the script language adds a runtime abstraction layer, which reduces a series of tedious processes for local running and enhances the portability and security of executable files. It can be seen that the advantage of using a scripting language to assist the development of the system language is almost offset by the disadvantages, but it also brings a lot of convenience. it is a good deal to choose a scripting language development.

This article is available at http://www.nowamagic.net/librarys/veda/detail/1654.