Explore the security of Java and Ruby language migration

In this article, we will explore the problem of risk prediction in Java and Ruby language migrations.

Generally speaking, "using Ruby with Risk" is a common view, for some reason. Because the use of new language is inherently risky. As Ruby on Rails moves into the mainstream of development, the risk will decrease over time as there are progressively growing groups of developers, components (or books called Gems and Plug-ins), and business partners communicating with you. But you can also hear the mainstream view that "using Java is safe". I hold a strong objection to this view. As language expands, such risks tend to grow as well. It is worthwhile to devote some energy to studying Java's initial application in order to understand what is happening in these views at present.

Introduction of new technology introduction

Many analysts have the description model needed for technology applications. One of the most popular models is defined in Ruby's web development Framework Iowa, which describes the application of agricultural products, and is later used to describe technical content in a book called Bridging the Chasm (crossing Chasm), written by Geoffrey Moore. In the book, Moore analyzes the five distinct groups that exist in the technical application cycle:

Technical experts. This group tends to adopt new technologies. Any promising technology will attract the attention of this group.

Prior adopters. Whether or not the technology is successful in mainstream technology, this group will adopt new technologies to enhance its competitive edge.

Pragmatists. Once new technologies are in mainstream use, or if there are steep growth curves to ensure that technology is widely used, pragmatists will actively adopt new technologies.

Conservatives. Only when new technologies become necessary will they consider adopting new technologies.

Skeptics. This group may be late to adopt new technologies, or it may be possible to use only one particular technology for ever.

Moore points out that the key to technology application is whether there are pragmatists in the team. Because pragmatists need new technology on a large scale, the middle group wants to see other pragmatic factions use the technology before the team makes a commitment. This is a phenomenon similar to the one described in the 22nd regulation, because the pragmatic factions are interdependent. For this reason, you will often see a downward trend in the market acceptance curve before the first adopters are ranked behind the technocrats and the pragmatists. Moore calls this decline a gap trend, and the idea should be centered around the risk of any new technology.

Moore's solution is to focus on bridging the gap. Generally speaking, it is difficult for you to cross the chasm through a huge leap. You need to have a well-defined niche market. Java technology first through the applet into the network client, and then to the server computing, mobile terminals, and other similar to mobile computing and enterprise architecture applications, and ultimately bring a strong impact on the network.

In the book "Beyond Java," I think the gap between programming languages is particularly serious. Most of us realize that spending on LISP will dramatically increase productivity, but it also makes it harder to find the right program developers, teaching resources, class libraries, and components. At the same time we will have to pay more to do some necessary integration work. For this reason, the mass market will only replace the mainstream programming language in approximately every 10 years. This trend can be clearly seen in the service-side programming language. The COBOL and Fortran languages appeared between 1954 and 1961. C language was born in the early 70 's, C + + was in the middle of the 80, the Java language appeared in 1996 years. I should think of the C # language as an integrated and efficient version of the Java language clone, although that might lead to some controversy. Many other languages are born at this stage, but none of the above languages can dominate. The accompanying risk is the most important reason for preventing the new programming language from being widely used.

The risk profile of Java

Using the Java language has been a great risk to overcome. At that time, most service-side programming was in the C + + language. C + + is an efficient operating system language that works well for application development. The C language family has performed well in this regard, as client/server programming and user interface development require a combination of program performance and adaptability that no other programming language can meet at the time. To overcome the risks associated with a new programming language, Java requires the following three conditions:

C + + developers have to go through a hard learning process. The presence of pointers (due to lack of compile-time security) leads to a wide variety of defects that are difficult to eliminate. Memory management makes memory leaks a common occurrence. C + + is too complex for most program developers. These issues add to the risk assessment for the C + + language.

Java needs to address some of the work that C + + languages cannot handle. The Java language has simple, flexible features and class library support that is not covered by many C + +. These elements reduce the risk assessment for the Java language and can keep the development team miniaturized and ultimately improve productivity.

Java needs a catalyst. As the network exploded, applets were widely embedded in Netscape browsers, making it possible for C-language developers to turn to the Java language. C + + is a simple transition because it is similar to Java syntax. Java has been able to quickly acquire a large number of user groups, and in the competition with Microsoft to gradually upgrade such a transition.

Java's expansion is faster than any technology we've seen before, and it may be bigger than any technology I've ever seen in my life, but the blueprint for Java's development has remained clear. In order to build a new language, the original language has not adapted to the needs of developers, the new language must overcome the shortcomings of the original language, and eventually with some catalytic effect of rapid aggregation of a large number of user groups.