The role of the scripting engine is to enhance the configurable nature of the program. Scripts are needed from games to management systems, and even industrial-grade office, 3DS Max, and AutoCAD add their own scripting languages. The advent of DHTML allows us to embed scripting languages in web code, and the advent of technologies such as PHP and ASP allows us to change the interface of an application to a Web page, and the logic is written in scripting languages. With a wide variety of scripting languages, Python's development has enabled the boost library to support Python, and the rails framework has grown Ruby's strength, and Lua has been heavily used in game development. Windows even provides wscript so that we can invoke the code for JavaScript and VBScript.
Now that we have so many scripting engines to choose from, why do we still have to develop our own scripting engines? First, we do not guarantee that the existing scripting engine will be able to satisfy the system we are making. Because the script we need may be simple, it's wasteful to use an existing scripting engine. Or our scripts are complex, but the functionality is "magical" (SQL, for example) so that there is no scripting engine to meet our needs. Because the script is not necessarily a common language, the script is just for the sake of our enhanced system's configurable nature. Second, the scripting engine is complex enough to train our programming capabilities. In our spare time the development of the program is not entirely in order to meet the needs of an application generated, it may be our own improvement for the groping. Developing a scripting engine is enough to be one of the ways to exercise.
The computer language as a computational definition needs to be understood before we develop the scripting engine. For several languages that are currently popular, we can abstract a set of orthogonal properties to describe them.
One, imperative and descriptive
A language is imperative or descriptive depending on whether the language is used to tell the computer what to do or what to do. For example, SQL and Prolog are descriptive languages, while C + +, C #, and so on are imperative languages. When we use SQL, we tell the server what conditions we need to meet, rather than tell the server what calculations we need to get the data items we need. The advantage of descriptive language is its good readability. C # 3.0 adds LINQ to data queries so that we can write code query data similar to SQL in C #.
Another, more obscure example, is Haskell. Haskell it is difficult to distinguish between an imperative language or a descriptive language. Because formally we tell the compiler what we want to do rather than what we want to do, but the granularity of the tools Haskell gives us is so thin that we still need to consider how a problem can be solved in order to tell the compiler what to do.
Ii. calculation by value and inertia calculation
The language of lazy computing is so rare that many people may not know that "the original language can be this way". The spirit of lazy computing is not to execute useless code. What is the useless code? As long as the value of this code does not have any effect on the outside world, such as not to the screen, hard disk or other places to write some data, it is useless. Of course, as to what's going on in the code, it doesn't matter.
To give a simpler example, suppose you now have the following code:
function PrintAndReturn(Message,Result)
{
Print(Message);
return Result;
}
function DoSomething(BoolA,BoolB)
{
If(BoolA || BoolB) Print(“!”);
}
DoSomething(PrintAndReturn(“Hello”,true),PrintAndReturn(“World”,false));