The 8th Programming Environment

Transcription

2 Overview This is a somewhat technical overview of some of the decisions which went into the design of 8th. The overall design was dictated by various factors, some contradictory. In weighing them, the top considerations were: 1. Cross platform unity 2. Ease of use 3. Reliable and steady performance 4. Data security Cross platform unity means that the same code must produce the same results on all platforms, to the ultimate extent possible. It also means that the programmer need not write platformspecific code unless there is a compelling reason to do so. Ease of use from the programmer s perspective. The language 8th is based on Forth, but with an emphasis on making the programmer s life easier. A typical programmer should require no more than three days to start being productive with 8th. The reasons for the uncommon choice of Forth as a basis for development will become clear later in this document. Reliable and steady performance means that in the most common scenarios, the end-user should not notice any perceptible difference between a program written in 8th and one written in a native solution. It was not, and is not, the goal of 8th to be as fast as a C++ solution (for example). However, it should not be possible for the end-user to discern that the program was written in 8th due to sub-optimal performance. Data security means that the deployed executable program should be hack-resistant. That implies that the executable should become inoperable and notify the end-user if it was tampered with. It also means that encryption is built-in to 8th, available for the programmer to use as desired to secure communications and data storage. In addition, the important libraries on which the 8th engine relies are built into it, preventing their surreptitious replacement. Cross platform unity There are a number of cross-platform solutions available today, but each suffers from various deficiencies. When I was looking for a cross-platform development tool to help me write an application targeting both mobile and desktop platforms, I did not find any which met all the criteria listed in the introduction. The Android platform requires you write in Java. The ios platform requires Objective-C. Windows programs are typically either C++ or C#, while Linux are usually C or C++. Quite apart from the plethora of languages one must use to support an application for all these platforms, the platforms themselves have wildly different programming interfaces (APIs). This makes writing cross-platform applications very difficult, time-consuming and expensive. On the desktop platforms there are a couple reasonable solutions: wxwidgets and Qt. Both are C++ libraries which abstract the underlying OS differences, and I had a fair bit of experience using wxwidgets. But wxwidgets does not support mobile, so I looked into using Qt. Apart from being 2

3 unable to get Qt to work across platforms, their licensing fees were out of my reach. So I kept looking. On the mobile platforms there is (also, as of recently) Qt as well as PhoneGap (and other similar products). The PhoneGap solution revolves around writing your application using a combination of HTML, CSS and Javascript. The end result is a slow, yet insecure application (since it is trivial for anyone to see your application s code). All of this, and PhoneGap does not support desktop applications nor does it allow access to third-party libraries. So I kept looking. In 8th, the language used is identical across all target platforms. The API which 8th exposes to the programmer is identical between platforms. Every effort is made to make it possible for the programmer to ignore platform specifics. That said, it is, nevertheless, trivially possible for the programmer to write platform-specific code. Not only because he can query the platform at runtime (via the 8th API), but he can dynamically run code specific to a platform (loaded over the net, from a database, or hard-coded in the application). The GUI (graphical interface) used by 8th is called JUCE. I looked for a long time to find a GUI library which was capable, worked on all my target platforms, had a usable API, and had a reasonable licensing model. JUCE was the only library I found which met all the criteria. As a result, 8th programs look exactly the same across all platforms. It is even possible to embed fonts in an 8th application, thereby having almost 100% identity between platforms. As JUCE is improved, 8th will also improve. Ease of use As mentioned at the beginning of this paper, 8th is a Forth derived language. There are several reasons for this. First, a Forth interpreter can be very small and fast. Second, I have experience writing Forth interpreters (my public-domain Reva Forth is still popular). But most important in my opinion is the very minimal syntax Forth incurs. This minimalist syntax means that an 8th program can be almost as readable as one s native language. It also means that only that which is required is written. For example, the canonical hello world program in 8th can be as short as "Hello, world!". bye. Contrast that to the monstrosity required in Java or C#. Ease of use also means: Most programmers will become productive with 8th in a matter of days. The facilities a programmer needs to get the job done are easily available. No need to write basic data structures they re already built-in. Access to third-party libraries is not only possible, but simple. Skills acquired learning one aspect of the language translate to other parts that is, the built-in words are consistent. There is no single, proper, way to do it. 8th gives the programmer considerable leeway in terms of self-expression. 3

4 Reliable and steady performance The topic of performance is a tricky one. From the end-user perspective, it makes no difference if an action takes 10 milliseconds or 50 milliseconds. But once the 100 millisecond boundary is reached, users will start to notice. It is up to the programmer to keep the user from noticing when things get slow. Performance, security, and ease-of-use are somewhat conflicting goals; in 8th my choice was to place a higher priority on security and ease-of-use. Despite that, the overall performance of 8th is quite acceptable (certainly better than PhoneGap, though not as good as native C++). Internally, items in 8th are allocated in pools, and reference-counted. This prevents rampant memory allocation and fragmentation, and improves locality of reference (which can help improve performance). 8th uses spin-locks to coordinate access to the pools, because they are global to the application (rather than per-thread). This means that access is slower than it might otherwise be, but is also transparently thread-safe to the programmer. The use of spin-locks rather than heavier system locks helps improve performance. Threaded execution is easily available to the programmer, allowing her to offload time-consuming activities to a background task and thus making the user-experience more responsive. Data security There are several related issues with respect to data security. First of all, an 8th program is packaged as an end-user application using our patent-pending process. That process creates an encrypted package using AES-256-GCM encryption to ensure that if that package is tampered with in any way, the 8th engine knows that and can take an appropriate action (notifying the user and quitting). Furthermore, that package is also signed using public-key encryption so that the engine knows that the package came from a valid authority (either us, or the developer s team). The package mentioned above also includes any assets the developer chose to include. Those could be graphics, fonts, data tables or anything else required for the application. Because all the assets as well as the source of the application are encrypted, not only are they tamper-resistant but they are also hack-resistant. It is not simple for an attacker to decipher the package and uncover the developer s trade-secrets. 8th has built-in support for communication over https channels, as well as utilizing encryption for other purposes (such as storing data in an encrypted manner). The encryption engine is builtin, as are all the support libraries used by the 8th engine, and thus quite difficult to subvert. 4

5 Contrasts To summarize, I would like to illustrate the differences between how 8th does things and how some other languages work. There are things which I have found, over the years, to be a hindrance and an irritation so 8th doesn t do them: most languages: reserved words, restrictions on naming. 8th has no reserved words, and no restrictions on naming except that you cannot have whitespace inside a name. Python: rigid use of whitespace. I never did understand the rationale for this Python feature. 8th lets you put as much or as little whitespace in your code as you like, and lets you arrange your code in whatever arrangement seems good to you. C++: virtual destructors: If you forget to make a destructor virtual in C++, your application may run, but have a subtle bug you will spend a long time debugging. 8th doesn t have this because its model of object-orientation is very different from C++ or Java C++: pointers vs references: If you pass a reference to a C++ local variable, you will be surprised if the object you passed it to uses it after your function went out of scope. 8th does not let you use pointers or references. Instead, you always have an item which is a referencecounted and self-contained thing, whose scope is determined solely by its reference-count. Java: verbosity. If you ve ever used Java, you know how verbose it is. 8th starts off terse, and only becomes as verbose as you want or need it to be. Javascript: ambiguity. What does that string evaluate to? Is it the number zero, a string with a zero or a false? How can you be sure? You can t, because Javascript is just about the most poorly designed language out there. 8th is not ambiguous. Each item has a type, and conversion from type to type must be done by the programmer, thus ensuring that one always knows with what kind of item one is dealing. HTML+CSS: consistency. Writing HTML and CSS is relatively easy, and getting a reasonable UI is not too difficult. However, it is almost impossible to make your UI look truly the same across different platforms, because the web browsers interpret HTML and CSS in subtly different ways. You will spend an enormous amount of time, effort, and money trying to get a consistent UI using HTML+CSS. In 8th the UI code is identical across platforms, and looks and feels the same. Mobile: debugging. Especially on Android, debugging an application is a terrible nightmare. 8th lets you develop and debug your application on a convenient desktop system. You can test and verify each word (e.g. function) in your code before you deploy it. Thus, your application will probably work on the mobile device without further debugging, though you can use the logging facility to assist in debugging on the device if you need to do that. These are only a few examples of differences between 8th and other languages or platforms, and I hope that now you better understand the reasons for the design decisions I ve made with 8th. 8th: One Effort, Multiple Platforms. Get it now! 5