Walnut/intro

From Erights

Contents 1 Introduction 1.1 Why E? 1.2 Why not E? 1.3 Why this Book? Why not this Book? 1.4 Fireworks In Part II 1.5 Rune and Trace Log

Introduction

Why E?

Java, Perl, Python, C++, Tcl, and on and on. Don't we have enough languages already? How could we justify bringing yet another programming language into the world?

In fact, there is still a compelling reason for developing better programming languages: we keep on writing more complicated programs. And worse, we keep on writing more complicated systems of interdependent programs.

We have entered the age of globally distributed computing with a vengeance. Anyone who has cobbled together a major system with a hodgepodge of Web servers, Java, JSP, SQL, CGI, CORBA, RMI, XML, and Perl knows that this cannot be the toolset we will use in 20 years. The sooner we move up to the tools of 20 years hence, the better off we will be. Into this situation we introduce E:

E uses a specific flavor of capability-based security known as object capabilities. With object capabilities, capability-oriented programming has the same flavor as object-oriented programming, except that capability-oriented programming takes the usual OO strictures more seriously. Often when using object capabilities for security, one finds that a more secure program is simply a program that follows OO principles of modularization more closely.

• E has significant advantages compared to other popular programming languages for distributed computing. As one quick example of its power, E's promise-pipelining architecture ensures that deadlocks cannot occur.

• E has dramatic advantages for secure distributed systems. All communication in E is strongly encrypted, transparently to the programmer. Capability-based security enables the concise composition of powerful patterns of interoperation, patterns that enable extensive cooperation even in the presence of severely limited trust. Excluding user interface code, a simple but effective peer-to-peer secure chat system has been written in less than 30 lines of code; no more lines of code were required to write a basic digital-money bank server despite the severe security issues involved. When the time comes for a security inspection, capability security allows simple reachability analysis to exclude huge swaths of code because they cannot embody a threat. As a consequence, auditing a system for security becomes cost effective to an extent that is simply unimaginable with other approaches, as documented in the DarpaBrowser report. With E, it is straightforward to create systems that run across the Internet that are as secure and safe as if the entire system were running on a single computer in your basement. As one of the original developers of Smalltalk observed, upon learning about the object-capability paradigm from E, capability security is "natural security": if you shouldn't use it, you just can't see it.

• E can even enable the fearless yet powerful use of multi-party limited-trust mobile code. "Mobile code" is just about anything executable on your computer that you get from somewhere else. Every time you turn on a word processor, play a game of Solitaire, or double click on an email attachment, you are executing mobile code written by someone you probably don't know and should not trust. Yet we give Solitaire, Barbie Fashion Designer, and Christmas Elf Bowling the full power to read our most private documents, sell them on EBay to the highest bidder, and then delete all your files. Our grandchildren will laugh at how silly this was, yet today there is no choice. If Microsoft used E instead of Visual Basic for its application language, Word and Excel would not be vectors for attacks like the original Love Letter virus. If all software were written in E, Klez and BackOrifice could never have existed: indeed, the term "virus", so loved by the press because it implies incurability, would never have been applied to computing.

These qualities cannot be achieved with traditional security approaches. Do not expect the next release of Java, Windows, or Linux to fix the problem: the flaws in these systems lie at the heart of their architectures, unfixable without breaking upward compatibility, as we shall discuss in the chapter on Secure Distributed Programming. Of course, there is nothing to prevent people from advertising that they are releasing a new, upward compatible, totally-secure version of a product. Just don't jump off the Brooklyn Bridge to buy it.

E wraps these strengths in a C/Java syntax to make it quickly comfortable for a large number of software engineers. It is built with objects at the core of its design, making it easy to write modular, readable, maintainable software using the strategies familiar from Java. It has the kind of powerful string handling that will be recognized and seized upon by the Perl programmer. For both better and for worse, E is a dynamically typed language like Smalltalk, not a statically typed language like Java. Users of Perl and Python will immediately assert this is an advantage; Java and C++ programmers will not be so sure. A discussion of the merits and demerits of static typing could fill a book the size of this one. Many of the most complex yet most reliable systems in the world today have been developed with dynamically typed languages. If you are a Java programmer, unshakably convinced of the perfect correctness of static typing, all we can do is urge you to try E first and form your conclusions later. We believe you will find the experience both pleasant and productive, as the long heritage of programmers from Scheme to Smalltalk to Perl and Python have found in the past.

Why not E?

E is not a panacea. The current implementation of E runs on top of the Java Virtual Machine. As such, it is not a good language for low-level machine manipulation. So do not try to use E for writing device drivers. And E's performance is quite unfavorable compared to raw C, so do not write the real-time kernel of a missile guidance system with it, either.

Actually, most arguments over performance miss the most important points about software development. One of the few time-tested truths of software development is, "first get it to work, then get it to work fast". E is an excellent language for getting a system to work. Once it is working, you can gain the performance rewards by profiling to see which portions of the code actually affect performance, then rewriting those (typically small) portions in Java, or C, or assembler, depending on your needs. In fact, for many traditional compute-intensive activities, E is just as performance-efficient as anything else: when creating windows and buttons on the screen, you use the GUI widgets from the underlying JVM. Since the JVM uses native drawing machinery, there is little distinction among languages when working with windows.

So perhaps E is in fact almost a panacea. But not quite.

Why this Book? Why not this Book?

This book is intended as an introductory text for practical E programming. Comparisons to Java are frequent, so some understanding of Java is desirable. If you wish to write software with point-and-click user interfaces, familiarity with either the Java Swing classes or the IBM Standard Widget Toolkit (SWT) is practically required.

This book is not a language specification. This book is an introduction to get you started and productive. If you encounter some surprising behavior not explained here, please join the e-lang discussion group and ask there: many helpful people can be found. If you need a precise specification, look to the reference materials posted by the language author and keeper, Mark Miller, at the ERights web site. You can join the e-lang discussion group at the same site.

Fireworks In Part II

When a very early version of E and E in a Walnut were presented to a programmer chat group, this was one of the comments:

"I think the key to hooking someone is to make them read the whole walnut cause it just looks like another scripting language until you get into the security and distribution then its like fireworks."

Though E is a powerful language with which to write single-CPU programs, the main power of E becomes evident only after you move into distributed programming. It would be tempting to introduce the distributed computing features first...except that you can't really do any meaningful computing without the basic data, flow, function, and object structures. So this book introduces "Ordinary Programming" Part I before getting into the serious distributed computing facilities. However, since E was designed in the C/Java syntax tradition, an experienced programmer can probably glean enough from the Quick Reference Card to skip directly to Part 3 on Distributed Computing. If you are short of time and have the requisite background, we recommend that strategy. Go back and read Part I when you are convinced that E's power for distributed programming meets your needs.

Rune and Trace Log

If you have read this far, you will probably want to retrieve a current version of E. Follow the installation directions in the distribution.

You will find the rune interactive interpreter by going into the E directory and typing

java -jar e.jar --rune

Rune will be your friend for experimentation as you learn E. Indeed, you may find, as others have, that rune is useful even when developing ordinary Java: with this scratchpad you can quickly explore what the API for Java really does when you use it, quickly and easily, before you put Java code into the middle of a program that is difficult to test.

 # E sample
 pragma.syntax("0.9")

Using Rune: One-line commands start with a question mark prompt and return the result on the next line in a comment:

 ? 2 + 2
 # value: 4

Commands that cannot be completed in a single line will receive close-angle-bracket continuations when you press carriage return at the end of the first line; the whole set of lines from the question mark down to the end of the command (the closing brace) will be evaluated when you close the statement:

 ? if (3 < 5) {
 >     println("is less")
 > }
 is less

Another one of the wonderful little E features that helps enormously in rune is the help(obj) function. Type "help(interp)" into rune, and you will get a complete listing of all the methods you can call on the interp object. You will be surprised at first glance by the number of methods there; these methods are explained throughout the course of the book, starting at the end of the discussion of E objects.

You can get a list of all the objects available in the privileged scope using the "bindings" method, and then ask for help on any of them:

 ? privilegedScope.bindings()
 ...
 #        stdout
 #            a TextWriter
 #        stderr
 #            a TextWriter
 #        stdin
 #            a NearRef
 ...
 ? help(stdin)

We will present examples both as straight E source and as rune source, depending on how complex the example is.

The Trace Log will be one of your best friends when you step outside of rune and start writing E programs. When you install E, one of the items in the "eprops.txt" file is a specification of the directory where trace information should be written when a program fails during execution. Find your etrace directory (enter interp.getProps()["TraceLog_dir"]), and go there when you need debugging information. This is an important resource--more than one early adopter of E has kicked himself for forgetting that it is there, then spending several hours trying to understand a problem that was simple and obvious if you just looked at the log.

If you find it annoying to have to keep opening the log file, you can get log messages sent to stderr by setting TraceLog_dir to -. You can put configuration settings in ~/.e/user-eprops.txt. For example, this configuration sends trace logging to the console and removes the need to press Return after the program exits dues to an error:

# ~/.e/user-eprops.txt
DTraceLog_dir=-
e.onErrorExit=report

Next Part: Ordinary Programming