Is Cocoa programming inevitable for iOS virtual machines?

Disclaimer: the entire article is either my speculation and desire, or a complaint.

Introduction: criticize Objective-C

Programmers, onlookers, and scholars have criticized Objective-C for a long time.

Complaints about languages and APIs include the lack of multiclass groups, substrings (slices), hash or syntax-level structures, lack of programming templates, lack of namespaces, and lack of default parameters for methods; operator overload is missing; immature garbage collector (there is no garbage collection mechanism on iOS); lengthy name conversion; package management is missing; for commercial APIs such as REST, SOAP, and SQL, native support is missing. The square brackets format of the method that is most often ridiculed should be changed (or corrected ).

None of these isolated criticisms is a substitute for Objective-C. You may say that if Objective-C needs to change so many aspects, the best way is to replace the entire language.

However, replacing the main development language is unpleasant for the development team. Apple will not do this for aesthetic or extremely small characteristics. The reason for replacing a language must be more practical and functional.

More specifically, Objective-C cannot be modified: complaints about the C itself, especially pointers in C.

If compatibility with C at the code layer is the best feature of Objective-C, Direct Memory Model is the most undesirable feature of Objective-C.

Direct access to memory is gradually fading out

Direct access to the memory mode, especially for projects using C language, is becoming increasingly undesirable.

According to the following 20 most popular programming languages (not just a scientific resource, but also persuasive), only 32% of people still use the direct storage mode language (C, C ++, Objective-C, Pascal, Delphi ). In the past 10 years, you may not see a language that directly accesses the memory in projects other than the kernel, driver, game, and underlying embedded software.

This means that no matter whether Apple is opposed to directly accessing the memory APIs (they probably won't), whether they introduce a new language or not, apple's official program environment will have an elastic acted memory model ).

Role of program virtual machines in Storage Virtualization

Technically, the current Objective-C garbage collector is a virtual storage mode. But I leave it out because it is not a fully virtual storage mode, and as long as Objective-C contains a C pointer, it will never be.

Because you do not need to release the memory, it does not mean that there will be no other memory problems. You still have pointers that may still point to something. You may still cross the array. You may still cause a buffer overflow. You may still overwrite a memory area. You may even make the Garbage Collector Recycle resources in use.

This is a fairly abstract vulnerability.

It is possible to create a virtual storage model without a Virtual Machine (see the following method). However, the virtual machine allows you to lock the virtual part, so there will be no unexpected vulnerabilities. You no longer need pointers. You won't overwrite the memory easily. You cannot cross-border arrays. You cannot cause a buffer overflow.

The VM can implement the above functions by providing commands to directly obtain the memory. On the contrary, commands on virtual machines are only associated with objects, attributes, and values-you cannot obtain error blocks in memory, and the garbage collection mechanism is more effective than the traditional method, because all storage references are completely definite.

The definition of the "virtual machine" I mentioned: "Virtual Machine" describes a computer that is not directly attached to a specific machine, but mapped to a specific machine. This Normal ing can be achieved through running explanations (such as the script language), Running Simulation (such as a computer simulator), or real-time compilation into the original machine language (such as java JVM. No matter how the "virtual machine" runs, the key is that the programmer only needs to process the virtual solution, and the exact structure and behavior of the target machine will not be directly involved.

Platform independence

The second discussion about virtual machines has little to do with language: platform independence.

Apple changed its CPU architecture twice in the past 17 years. It will happen again soon. Although the change to intel CPUs was incredibly smooth (I was shocked by its seamless transition ), however, it takes quite a long time to wait for the intel version of most programs and other developers to complete all the conversions.

Considering Apple's extra efforts on iOS devices, it is possible to imagine that a series of different CPUs can be used on a set of devices. fat binaries can only facilitate a small number of CPUs. If Apple intends to use a series of different CPUs, the unique way to run the bytecode is.

Good programming should avoid code that can only be applied to a specific hardware device. Separating the CPU and platform from the program is a logical step.

One interesting thing about running this topic on different CPUs is that Apple recently introduced a new platform-independent language: OpenCL, which runs on a JIT compiled virtual machine. I cannot predict whether there is a trend to use OpenCL to re-implement Cocoa (this method is more mysterious than Objective-C), but the technology to implement it certainly exists.

Virtual machines in new languages are not used

Note that virtual machines can be introduced before the new language.

If Apple determines that the fear of interactive storage management makes developers stop looking at it, but is not prepared to complete the transformation to the new language step by step, first switch to the Virtual Machine (benefits of the virtual storage mode) it is possible, and at the same time, the changes to the Code layer are relatively smaller.

Although this seems a strange thing, there are indeed two benefits.

The first is that the Objective-C running in the virtual machine can establish a bridge with the original Objective-C outside the virtual machine. If you remember that Apple once gave up bridging Java and Objective-C, the biggest technical difficulty at the time was that Java looked at the dynamic enforceability of an object as opposed to Objective-C, in addition, Java cannot track changes in methods and pointers at the end of Objective-C. Bridging the language in a virtual machine to a language outside the virtual machine is relatively simple in this model.

The second is that currently Cocoa is suitable for Objective-C feature settings. Using virtual machines alone can maintain the essential similarity of Cocoa, making apple's development work easier.

Update: Jesper once pointed out this and explained why the consistency between virtualized Objective-C and non-virtualized Objective-C may not be a good concern.

In short: a virtualized version of Objective-C (such as its previous C ++. NET) You need to remove a large number of language features or it needs to throw a running exception if your Code violates a series of rules (equivalent to not solving the virtual storage problem ).

A different approach

Of course, just because of the advantages mentioned above, it does not mean that this virtual machine is definitely the next step for Mac development and improvement.

There is indeed a language that does not require virtual machines for compilation, garbage collection, and storage security. This language fully meets the requirements of the virtual storage mode. Google's Go language is an example.

It is impossible for Apple to accept Go. Do not mention that Go is still under development. One problem is that Go cannot bridge with Objective-C. In fact, Go cannot easily Bridge with C or C ++.

Moving to a language similar to Go requires a blank gap, that is, there will be a forward compatibility problem. This interruption is possible (Carbon introduced to Cocoa is such an interruption ), I think it is more likely that Apple will choose to use a custom language or a custom variable in an existing language to maintain a certain degree of interoperability. I suspect that Apple once had the opportunity to replace Cocoa (on iOS), but it chose to maintain its original design. I suspect they have decided to continue using Cocoa on Mac in the future, even if the language and environment have changed.

Virtual machines provide better forward compatibility, bridging and portability, coupled with the excellent running capability of modern JIT, as a result, I believe that non-virtual machine selection cannot provide sufficient flexibility and the advantages of non-virtual machines are not enough to offset the inconvenience caused by language changes.

Conclusion

Obviously, I love Objective-C and Cocoa; I am sure that my point of view can be clarified from my blog and Debate articles about its characteristics. I do not agree with most of the criticisms listed above. I think these criticisms are superficial, or they are too philosophical and technically misleading.

However, Mac developers cannot resist an unstoppable trend of completely virtualized storage models, which has been expanded beyond Mac-related development.

Furthermore, I do not think the trend towards virtual machines is worth resisting. Currently, the main features of Cocoa and Mac programming are: focus on details, widget running methods, methods, classes, and APIs. In fact, most Cocoa can remain unchanged.

In the end, I am sure that Apple will switch to a new language;

You don't have to worry about doing this now. Of course, these are not required for iOS devices currently. Even on Mac, I think there will be several years of warning and preparation before something happens, and there is no need to force a change when it finally happens.

When I say that you don't have to worry about it, I mean: I think you can still release a new non-Virtual Machine for Mac within 10 years, cocoa/Objective-C Programs (you can still write Carbon programs if you want ). I just don't think Carbon is the most common choice.