Difference between revisions of "Introduction"
(→Origins of the SmartEiffel project: retrofitting history) |
m (42 revisions: initial import from SamrtEiffel Wiki - The Grand SmartEiffel Book) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 60: | Line 60: | ||
The tools that we are going to integrate will, without any change to the language, focus on the following objectives: |
The tools that we are going to integrate will, without any change to the language, focus on the following objectives: |
||
* better predict [[FAQ#StaticVsDynamicType|dynamic types]] and obtain better execution performance, |
* better predict [[FAQ#StaticVsDynamicType|dynamic types]] and obtain better execution performance, |
||
− | * |
+ | * statically validate assertions as well as detect calls without a target (calls on [[Void|<code>Void</code>]]), |
* statically resolve all typing problems tied to [[Glossary#Covariance|covariance]] and to change of export status ([[FAQ#CATCALL|CATCALLs]]). |
* statically resolve all typing problems tied to [[Glossary#Covariance|covariance]] and to change of export status ([[FAQ#CATCALL|CATCALLs]]). |
||
Another way to describe the objectives of the SmartEiffel project is to give here our point of view on Eiffel, or more precisely on the spirit of Eiffel. |
Another way to describe the objectives of the SmartEiffel project is to give here our point of view on Eiffel, or more precisely on the spirit of Eiffel. |
||
Line 67: | Line 67: | ||
Strictly speaking, Eiffel is a language and not truly a method. |
Strictly speaking, Eiffel is a language and not truly a method. |
||
That being said, after more than ten years of work on Eiffel and for Eiffel, we cannot help but notice that Eiffel is a good vehicle for a particular way of thinking and therefore as a way of working with computer software.<br> |
That being said, after more than ten years of work on Eiffel and for Eiffel, we cannot help but notice that Eiffel is a good vehicle for a particular way of thinking and therefore as a way of working with computer software.<br> |
||
− | We |
+ | We assert here, without fear of contradiction, that Eiffel is most probably the best current language for doing what is commonly called '''software engineering'''.<br> |
− | This is |
+ | This is no surprise when one knows that ''software engineering'' was our guiding principle from the start when we were making choices concerning the Eiffel language. |
Before presenting other aspects that we take into account after each evolution of the language, it is good to keep in mind that the perfect universal computer language for all kinds of applications does not exist and will probably never exist.<br> |
Before presenting other aspects that we take into account after each evolution of the language, it is good to keep in mind that the perfect universal computer language for all kinds of applications does not exist and will probably never exist.<br> |
||
Today and probably for some time to come, the concepts of computer programming languages remain empirical and any given language is only effective for only a given spectrum of applications.<br> |
Today and probably for some time to come, the concepts of computer programming languages remain empirical and any given language is only effective for only a given spectrum of applications.<br> |
||
− | We will try to give |
+ | We will try to give below the principal guides that influenced our choice. |
Software engineering is the principal guide in the conception and the choices made concerning the Eiffel language.<br> |
Software engineering is the principal guide in the conception and the choices made concerning the Eiffel language.<br> |
||
Line 81: | Line 81: | ||
Of course, the '''security''' aspect is also one of our primary concerns. |
Of course, the '''security''' aspect is also one of our primary concerns. |
||
− | Moreover, as for the software engineering aspect, we propose to set the bar even higher: to put forth a language capable of fully exploiting all machine resources, a |
+ | Moreover, as for the software engineering aspect, we propose to set the bar even higher: to put forth a language capable of fully exploiting all machine resources, a language and set of tools to truly generate [[Performance|'''high performance programs''']]. |
Revision as of 22:04, 3 March 2013
Origins of the SmartEiffel project
During the course of his work on his thesis, Dominique Colnet, principal author of SmartEiffel, discovered the Eiffel language while editing an encyclopedic work on object oriented languages ([MNCLT 1989], [MNCLT 1991]).
Holding the post of Assistant Professor of Computer Science in 1989, the Powers That Be at his educational institution at the time decided, in 1990, to use the Eiffel language for introductory computer science. It is amusing to mention here that Dominique Colnet was at the time a fervent defender of Smalltalk. As everyone knows, it's a pretty good thing that it's not up to a young Assistant Professor of Computer Science to decide which programming language is the best to use. So, it is amusing to note that Dominique Colnet was forced to use Eiffel against his will in 1990!
In order to reconcile his teaching and research work on the compilation of object oriented languages, Dominique Colnet decided therefore to abandon Smalltalk for Eiffel and to establish a project to kill two birds with one stone: combine interesting research with a free product that would also be useful for teaching.
The SmartEiffel project, originally named SmallEiffel actually commenced during the year 1994 when Dominique Colnet decided to write his own Eiffel compiler.
Writing an Eiffel compiler is no small undertaking. Before making this decision, Dominique Colnet had begun to write a new Eiffel class library whose architecture simply corresponded nearly word for word with the base classes one could find at that time in Smalltalk-80 libraries ([GR 1983], [Goldberg 1984]). Because of the very bad quality of the commercial Eiffel compilers available at that time the decision was taken to write a new one from scratch. The new compiler was named SmallEiffel to make reference to both Smalltalk and Eiffel ([OOSC 1988], [ETL 1992]). An entire year was necessary to write the first version of SmallEiffel and it was not until July 1995 that SmallEiffel was able to compile itself. Since that time, more than ten years have passed and more than thirty versions have seen the light of day.
Little SmartEiffel developing into something big?
Starting out as simple research prototype and teaching aid, SmartEiffel has seen its capabilities steadily increase from version to version since 1995.
In 1998, on the occasion of a visit to LORIA by Richard Stallman, president and founder of the FSF (Free Software Foundation), the GNU designation was added to the project's name.
From 2002 and up to 2005, Dominique Colnet participated actively in meetings with the initial objective of standardizing the Eiffel language (ECMA standards committee TC39-TG4, ECMA standard number 367). Of course it goes without saying that the entire SmartEiffel team is associated with the standards work and its many long discussions...
Finally, in May 2005, the SmartEiffel project announced that it was going to continue to work on the true Eiffel language. In reality, the language described by the ECMA TC39-TG4 working group clearly diverges from what is conventionally called Eiffel. ECMA-Eiffel is a very different language, and above all, not yet experimented. The SmartEiffel team will never implement ECMA TC39-TG4.
At July 2005, at the time when we write these lines, after more than 10 years of work not only on the compiler but also on the Eiffel language itself, we, the SmartEiffel project, consider that the Eiffel language as we know it today, now contains nearly all desirable features. Therefore, version 2.2 of SmartEiffel marks the debut of a new level of stability and corresponds to what we think of as being the true Eiffel language.
Objectives of the SmartEiffel project
The language is entering into a period of stability. In fact, in version 2.2, the only important thing that is still missing is distributed programming, the SCOOP mechanism. Needless to say, the implementation of SCOOP will not negatively affect any existing software. In our opinion, it is evident that one must truly move towards a stable and validated language experimentally through work on a large palette of programs.
We anticipate in the short term an important effort which began in version 2.2 concerning the implementation of libraries. We are also going to more fully open up the project in order to augment the dynamics around SmartEiffel: to work on a Wiki for consolidation of documentation and to increase the number of people authorized to contribute to the source code of the project.
Without modifying the language, we will work on novel tools in the domain of dynamic type prediction and on static assertion validation. In fact, we think that the Eiffel language should remain simple. The tools that we are going to integrate will, without any change to the language, focus on the following objectives:
- better predict dynamic types and obtain better execution performance,
- statically validate assertions as well as detect calls without a target (calls on
Void
), - statically resolve all typing problems tied to covariance and to change of export status (CATCALLs).
Another way to describe the objectives of the SmartEiffel project is to give here our point of view on Eiffel, or more precisely on the spirit of Eiffel.
Eiffel, the spirit of Eiffel or the Eiffel method?
Strictly speaking, Eiffel is a language and not truly a method.
That being said, after more than ten years of work on Eiffel and for Eiffel, we cannot help but notice that Eiffel is a good vehicle for a particular way of thinking and therefore as a way of working with computer software.
We assert here, without fear of contradiction, that Eiffel is most probably the best current language for doing what is commonly called software engineering.
This is no surprise when one knows that software engineering was our guiding principle from the start when we were making choices concerning the Eiffel language.
Before presenting other aspects that we take into account after each evolution of the language, it is good to keep in mind that the perfect universal computer language for all kinds of applications does not exist and will probably never exist.
Today and probably for some time to come, the concepts of computer programming languages remain empirical and any given language is only effective for only a given spectrum of applications.
We will try to give below the principal guides that influenced our choice.
Software engineering is the principal guide in the conception and the choices made concerning the Eiffel language.
The following fundamental points flow from this guideline:
- Eiffel is designed especially for large and even very large programs,
- Eiffel should facilitate working on a team, communication and documentation,
- Eiffel should facilitate maintenance and test of software components.
Of course, the security aspect is also one of our primary concerns. Moreover, as for the software engineering aspect, we propose to set the bar even higher: to put forth a language capable of fully exploiting all machine resources, a language and set of tools to truly generate high performance programs.