About Dynamic Language)

Before the May Day holiday, I talked to several developers about the development of technology. One of the most prominent reasons is that everyone is focusing on dynamic languages. Some of them have been in use for many years, while others have a good development trend. They have a sense of foresight, while others have just been used and are still excited. Of course, they still have a wait-and-see attitude, however, even the most "conservative" can show respect for dynamic languages. This is a great improvement over the past two or three years. I remember two years ago, I worked with tangtao, a python enthusiast, to plan 《ProgramWhen I was the first "Dynamic Language topic", many questions were raised both inside and outside of China, with J2EE, the "enterprise-level" stick is used to question the "seriousness" of the Dynamic Language and ASP. net is immersed in the drag-and-drop GUI construction method, self-thinking development efficiency, the world's first, for Dynamic Language sneer. At that time, we felt that the development time of Dynamic Language in China was not mature, so we finally gave the topic a very helpless name: "Dynamic Language: a fire in the air". Two years later, our friends in the industry criticized our magazines and websites for being too weak in Dynamic Language and lagging behind industrial practices. Sorry, I have always been a supporter of this dynamic language and I can't help but like it: I can't think of a situation that will develop so fast!

According to my recent impressions, I boldly predicted that the popularity of Dynamic Language in China would not be too far away. The first is the rapid promotion of PHP in the Web development field. Dynamic languages will soon be widely used in the Internet industry (Internet applications oriented to the public. This is a major application and the most active and rapidly growing field. In this field, the combination of dynamic languages and open-source systems has made great progress and will certainly achieve greater success. The next step is enterprise applications. This is the main battlefield, and the traditional power in this field is still quite powerful. Dynamic Language is still a long way to go in the enterprise application field, but there are still great opportunities. The next step is the PC software development field. in foreign countries, dynamic languages are coming in, but this field is basically saturated and not very concerned. Software Products in China are developed in a small scale, with a single type and poor influence. In short, within a few years, dynamic language will surely spread like a wild fire, which is unstoppable.

My opinion is not only a summary of formal development, but also an understanding of the development trend of software technology. I talked about this issue when I had a video interview with gigix and xjy in csdn before. We feel that the widespread adoption of Dynamic Language is a trend determined by the rapidly changing reality of the Internet and enterprises.

Today's enterprise applications are much different from mis a decade ago, with constantly changing demands and endless changes. What about Internet applications? In terms of dramatic and frequent changes, compared with enterprise applications. This is essentially because enterprises are rapidly changing, consumers are rapidly changing, people's needs are rapidly changing, and the world is rapidly changing. Now more and more experienced Enterprise developers have come to a consensus, that is, analyzing enterprise applications in advance and fighting for demand changes is almost a dead end, no matter what advanced software engineering methods, modeling tools, or UML language you use, you cannot solve the problem at all. The target of your service is changing every day. How can you increase the demand of others and then increase the load slowly? Since changes cannot be avoided, it is better to adapt to changes. Instead of looking for ways to anticipate changes, it is better to give yourself the ability to respond quickly as needed, improve your ability to respond to changes, and reduce the cost of changes.

This is a consensus, and the question is how to respond on demand. The difference is here. XML is indispensable for ASP. NET and J2EE development today. XML is used to reconfigure the system when a change occurs. Taking J2EE as an example, a high-level J2EE developer writes XML files more and more complex, and uses XML as a domain language. To put it bluntly, it is to expand J2EE into a domain-oriented engine, and use a standardized, thin-bo XML to final programming. I call it the "strong engine, weak script" solution. There is a reason for doing so. Java/C # Is a compilation language, and the cost for changing, modifying, and re-deploying is relatively high. Therefore, it must be used with XML. But what is the result? Not ideal. First, the system design is still very difficult. You still need to design a strong engine. If it is not well designed, XML scripts will not be carried. It is still difficult to design this powerful engine, and it is difficult to modify the design error. It will inevitably take great effort to maintain the engine after it is released. This problem has not been solved much.

Secondly, what I personally dislike most is XML abuse. XML is essentially used for data exchange between programs. It is read and write to programs, not to people. From any perspective, XML is very unfriendly to reading and creating people. As a result, in concert with J2EE, it is really inhuman to drive the duck into the shelves and let XML act as DSL, forcing programmers to learn to read and write XML, a very interesting "language. Furthermore, to use various frameworks and fields, developers are likely to learn a variety of XML dialects with different semantics, and many of these XML dialects have not been designed, it was produced by the tufa. The two completely different languages are messy enough in one system. What's worse is that XML dialects produced by various soil methods are stirred up together in the system, as a result, XML with different semantics is spread in the program like a cancer cell. Such a system can only be described as disgusting.

In short, this "strong engine, weak script" approach, I think there is no future.

On the contrary, the dynamic language solution provides relatively small and flexible engines, powerful language mechanisms, and extremely rich Reusable Modules. You basically build the entire system within the scope of dynamic languages, and the scripts and core objects are integrated to solve the problem straight forward. There is no need to turn around, and there is no need to look subtle and actually helpless architecture and model. A Dynamic Language is generally used to unify data and programs. XML is basically not required, and the program is easy to change and can be modified at any time. The dynamic nature of language also gives you the convenience to simulate the language in the field. The result is that the ability to adapt to changes is greatly enhanced, and the cost of changes is greatly reduced. Many of the past are impossible.

Therefore, I think the changing world requires us to use a dynamic language that is friendly to changes. This is the conclusion.

In addition, from the programmer's perspective, using dynamic language programming is much easier and more interesting than using traditional compiling languages, especially compiling object-oriented languages. There are not so many rules, and there are not so many cities. For example, C ++, Java, and C # All strongly oppose the use of exceptions as a tool for program jump under normal circumstances. The so-called "using exceptions only in exceptional circumstances" is easy to say, it is usually a huge weekly chapter. Python/Ruby encourages you to use exceptions as a normal program flow control method. For example, the termination of the For Loop in python is implemented internally by triggering a stopiteration exception. Being able to use exceptions as a process control means can save a lot of brain cells. For example, many of the design patterns we often talk about are simply a single move in dynamic languages. Everything comes straight and doesn't have to be so smooth. For example, Ruby can modify the definition of this class at will when a class is defined and applied in the system. In python, only a subtotal can be omitted, this is impossible in traditional OOP languages. Ruby's ability to declarative language shown in rails, a signboard project, is amazing. To use these dynamic languages, we need to free up our thoughts first, and then we will feel free of limitations and free up our hands and feet. For programmers, this is of course very comfortable.