Introduction to Eiffel
In the late 1970s, when I was a journeyman laboring over the macro assembler language, a simple, elegant, and expressive language called C emerged from the structured programming tradition. My friends advised me to forget C, to learn a “real programming language” like PL/1 or Ada, available on many more of the important platforms, and with commercial staying power due to the support of the government and major corporations. Ignoring this advice, I concentrated on C. Some of you may agree my choice was the right one for its time.
Now, more than a decade later, another simple, elegant, and expressive language has emerged, this time from the object-oriented tradition. With roots in Simula, beholden to no backwards compatibility issues, the Eiffel programming language was designed from scratch by Bertrand Meyer and his colleagues for the purpose of enabling the construction of robust, general, reusable software components. With commercial support from a few vendors, availability on several significant platforms, and some success stories in development of major commercial applications, this language bears careful observation.
I have known of Eiffel since 1989, when I read Dr. Meyer's book, Object Oriented Software Construction (Prentice Hall, 1988). I was impressed with the language, much as I had been impressed with C when I read Kernighan and Ritchie's classic, The C Programming Language (Prentice Hall, 1988), ten years earlier. The opportunity to give Eiffel a try presented itself with the Linux port announced in 1994 by Bertrand Meyer's company, Interactive Software Engineering of Goleta, California.
So what is all this noise about object-oriented programming, and what sets Eiffel apart from the pack of object-oriented languages?
Much of the promise shown by object-oriented software construction may be attributed to the possibility of code reuse, particularly the reuse of software components.
By reuse, I mean the incorporation of previously written software unmodified into new programs. In the US we have a saying: “if it ain't broke, don't fix it.” This folk wisdom highlights the result of research studies which indicate the great hazard of introducing new problems when working on existing software. Ideally, it should be possible to write something once, then put it on ice to be reused but never modified, except to fix bugs and perhaps to add new features. Existing users should be protected, if possible, from effects of such changes.
Unfortunately reuse has succeeded in only limited ways so far. For example, the Unix C library or the various widget libraries used in constructing Graphical User Interfaces are widely used across many platforms. These notwithstanding, most of the significant computer programs produced today contain great volumes of handcrafted code. The difficulty of producing software components with enough built—in flexibility is prominent—and a great part of this difficulty must be ascribed to language issues.
The Eiffel programming language was designed to promote re-use. Bertrand Meyer recounts in the preface to Eiffel: The Libraries (Prentice Hall, in press) how he started out to write reusable components and how he came to abandon the attempt to use existing languages and instead wrote a language for the purpose.
Compiled and strongly typed, with genericity (templates), polymorphism, dynamic binding, exceptions, garbage collection, a genuinely useful implementation of multiple inheritance, and unique handling of assertions, Eiffel should be considered a contender on purely technical grounds.
Eiffel provides assertions as language primitives that furnish both in-line design documents and optional runtime error checking. Assertions are inherited. This serves to guarantee that descendents will live up to or exceed their ancestors' promises. Use of these assertions is a part of what is called “design by contract”. These represent an application of responsibility-driven design at a language level.
There are also other factors:
Eiffel has a published, non-proprietary design, coordinated by a nonprofit consortium whose decisions all existing vendors agree to observe.
Simple and consistent syntax makes Eiffel an easy language to learn. You will find no dense nests of parentheses, asterisks, brackets, or ampersands in this language. If you delight in special cases and obscure exceptions to rules, with attendant language primitives just for handling these things, Eiffel is not the language for you.
Precedence of arithmetic operators gives the order of evaluation of mathematical expressions you would expect, unless your native programming language is Smalltalk, Lisp, or Forth.
Eiffel is available on a wide range of platforms.
The design of Eiffel has been placed in the public domain by Interactive Software Engineering, Bertrand Meyer's company. The Eiffel trademark is owned by NICE, the Nonprofit International Consortium for Eiffel, which has been liberal in bestowing use of the trademark. A validation suite will be available from NICE later this year. Major Eiffel vendors and users, including representatives from corporations and academia, are represented on NICE. Membership is open to any interested party. Proposals of NICE are published on the newsgroup comp.lang.eiffel. Anybody may participate in the ensuing discussion.
The official language definition is Eiffel: The Language, By Bertrand Meyer (Prentice Hall, 1992). Almost 600 pages long, this volume contains a precise definition of the language, many examples, and a great deal of discussion. The formal syntax definition occupies only eight pages.
NICE is in the process of standardizing the libraries. PELKS, the Proposed Eiffel Library Kernel Standard, is in the final stages of adoption, even as the vendors hasten to bring their own class libraries into line with it. Other libraries may follow.
Eiffel is available or announced from a number of vendors on a roster of operating systems or platforms including Windows 3.1, VMS, SunOS, Solaris, Ultrix, OSF/1, DG Aviion, IBM RS/6000, Silicon Graphics, Macintosh, OS-2, and NEXTSTEP, as well as Linux.
Many Linux users are interested in seeing vendor interest in our operating system, and a few astute vendors are beginning to join the fold. It seems not too surprising that vendors of a language that is in many respects years ahead of the pack should also be astute enough to recognize the nature of the Linux community. And they have—all four Eiffel vendors offer Linux ports.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide