Beautiful features of JavaScript

I make your feet touch my lips, my eyes, my hearts, and my answers. Your most loyal ......

-- William Shakespeare, Love's Labor's Lost)

 

Last year I was invited to write an article for the book Andy Oram and Greg Wilson's Beautiful Code. This is a collection of theme-based expressions of computer programs. The section in my charge describes JavaScript, which proves that JavaScript is abstract, powerful, and useful. However, I want to stay away from browsers and other places that are suitable for using JavaScript. I want to emphasize its more weighty content to show that it is a respectable language.

I immediately thought of Vaughn Pratt's Top-Down Operator priority parser (Top Down Operator Precedence parser), and I used it in JSLint. In computer information processing technology, parsing is an important topic. Whether a language has the ability to compile a compiler for itself is still complete for the language

One test.

I want to include all the code of the JavaScript parser written in JavaScript in this article. However, my chapter is only one of the 30 or 40 chapters, and I feel bound to those pages. The bigger challenge is that most readers have no experience using JavaScript, and I have to introduce this language and its features.

So I decided to extract the subset of the language. In this way, I do not have to parse the entire language, and do not need to describe the entire language. I call this subset Simplified JavaScript (Simplified JavaScript ). It is not difficult to extract a subset: it includes the features required by the parser. This is what I describe in Beautiful Code.

Simple JavaScript is a good thing, including the following main content.

A function is a top-level object.

In simplified JavaScript, a function is a closure (lambda) with a lexical scope ).

Dynamic Objects Based on prototype inheritance

The object is classless. We can add a new member attribute to any object through a normal value assignment. An object can inherit member attributes from another object.

 

Object literal and array literal

This is a convenient representation for creating new objects and arrays. JavaScript literal is the source of inspiration for the Data Exchange Format JSON.

The subset contains the best part of JavaScript. Although it is a small language, it is very powerful and expressive. JavaScript has many additional features that should not be added, as you will see in the subsequent appendix, it has a lot of features that bring negative value. There is no ugly or bad content in the child set, and all of them are screened out.

Simplified JavaScript is not a strict subset. I have added a few new features. The simplest thing is to add pi as a simple constant. I am doing this to prove a feature of the parser. I also demonstrate a better reserved word policy and demonstrate which reserved words are redundant. In a function, a word cannot be used as a variable or parameter name, but also as a language feature. You can use a word on one of them and allow the programmer to choose it. This makes a language easy to learn, because you do not need to know the features you will not use. And it makes the language easy to expand, because it does not need to retain more reserved words to add new features.

 

I also added block-level scope. Block-level scope is not a required feature, but without it will confuse experienced programmers. The block-level scope is included because I expect the parser may be used to parse non-JavaScript languages that can correctly define the scope. The Code style of the parser I wrote does not care whether the block scope is available. I recommend that you use this method.

When I started thinking about this book, I wanted to further develop this subset. I wanted to demonstrate how to get an existing programming language by not making any changes, except for excluding low-value features, and make effective improvements.

We see a lot of feature-driven product designs, and the cost of features is not properly calculated. For users, some features may have some negative value, because they make the product more difficult to understand and use. We found that people only need to work on the products they want. It turns out that it is much more difficult to generate a design that works exactly the same way than to design a feature that combines big strings.

Features include defined costs, design costs, and development costs, as well as test costs and reliability costs. The more features you have, the more likely a feature has problems or interference with other features. In software systems, storage costs are insignificant, but they become important in mobile applications. They increase the efficiency cost of the battery because Moore's law does not apply to the battery.

Features include document costs. Each feature adds training costs to the Product Guide. The cost of all users is increased for features that only have value for a few users. Therefore, when designing products and programming languages, we want to directly use the Core Components, because these are the core components that create most of the value.

We can always find a good part of our products. We like simplicity and the pursuit of simplicity and ease of use. However, when products lack such features, we need to create them by ourselves. Microwave Oven has a lot of features, but I only use cooking and timing, the use of the timing function is enough trouble. For a feature-driven design, we can better cope with its complexity only by finding its essence and sticking to its use.

How nice it would be if the product and programming language were designed to leave only the essence.