Here are some questions and answers that should help you getting into Eiffel, solve common problems and figure what you can do and cannot with Sofa.
Are there any other relevant FAQ's?
The Eiffel FAQ describes general questions about the language, tools books and vendors. The SmallEiffel FAQ deals with the particular compiler used for Sofa. Both documents are included with Sofa.
I'm new to Eiffel. Where should I start?
The first four chapters of the book "Object-Oriented Software Engineering with Eiffel" are also available for download as a PDF document from http://www.irisa.fr/pampa/EPEE/book.html. Chapter two gives an overview of Eiffel mostly by explaining short examples. This is particular useful if you already know some other programming language.
"Eiffel Object Oriented Programming" is a complete book about Eiffel. It's probably not the best book about Eiffel you can find, but it's free. You can find it at http://www.doc.mmu.ac.uk/library/notes/ajt/. (Use e.g aminet:dev/gg/wget.tgz to download a local copy).
A quite exhaustive collection of useful links for newcomers can be found at http://elj.com/eiffel/getting-started/. At the same site, you can find lots of other interesting links and daily news about Eiffel. Just start browsing at http://elj.com/.
On the long run, you probably should read "Object-Oriented Software Construction". You can find more information and excerpts from it at http://eiffel.com/.
Don't read "Eiffel the Language", second printing, as it is completely outdated. And don't read any of Bertrand Meyer's papers on Design by Contract or "introductions" to Eiffel, as they will only confuse you.
Are there any Eiffel modes for Amiga editors?
There is an Eiffel/Sofa mode for GoldEd Studio 6 at aminet:text/edit/envSOF*.lha. An older but unsupported version that works with GoldEd 4 (now freeware) can be found at aminet:text/edit/GedEiffel.lha.
Comparing the amount of postings in comp.lang.eiffel and comp.sys.amiga.programmer, about as dead as Amiga ;-)
I read all the FAQ's and introductions, but still have no clue what's Design by Contract.
If you still haven't understood any description of Design by Contract (DbC), here's anotherone that should be quite simple to grasp for beginners and give some motivation to use it:
The most important application of DbC is "Coding without Design". That means, you have an interesting, basic idea of a program, and just sit down and start hacking it in.
Of course there are a lot of people telling you that's not the proper way to create Software, but hell, what do they know? Most of them haven't written a program with 10000 lines of code in their lives. Just ignore them. (Well, maybe not for university exams).
But back to coding: When you hack in your Eiffel code, you can specify some sort of "self-test" with all these require, ensure and invariant stuff. When the program executes, it will test itself all the time.
This self-test can be very detailed, and there are whole books about how to test what. However, to be practically useful, just specify obvious conditions that are trivial to code. For example, are function parameters in range, is a certain data structure sorted, is a certain attribute greater than zero all the time and so on. This takes almost no additional time, and once it's there, it will be tested anytime you execute the program.
The most annoying thing about "Coding without Design" is that the program changes a lot during its development because you get to understand it better while you write it (brain-wankers nowadays call it "refactoring"). But often, the program doesn't work anymore after such a change because you fucked up some minor detail, and have to start digging what's wrong. And that takes the fun out of coding.
With DbC, this happens a lot less because the self-test will detect most of these silly small bugs you introduce by copying-and-pasting around. And because of this, it's useful. Once you figured that, you can start looking at the more esoteric corners of it (and maybe even read some papers of Bertrand Meyer).
I have no C compiler yet. Which one should I install?
If you can find a cheap copy of SAS/c somewhere, use it.
Otherwise, use Dice. It's quite simple to install.
The support for Vbcc is still somewhat flaky, partially because of the careless attitude of the SmallEiffel people towards portability beyond Windows and Linux, partially because of minor quirks in Vbcc. But both are constantly improving.
Gcc is only for real heroes. Also expect to read the SmallEiffel manual a lot before you can make it work without ixemul.library. Unfortunately, Gcc is quite different in many ways from other Amiga C compilers, thus the support in Sofa somewhat sucks. Feel invited to help fixing this.
I already have a C compiler, but it's not supported by Sofa. How can I add support?
The current support is already quite exhaustive, because it includes two relatively easy to setup freely distributable compilers (Dice and Vbcc). Maybe it's the easiest to just install one of them.
Nevertheless, it can of course make sense to support more C compilers, as long as they have some kind of command line interface. Normally, you should only have to add a couple of lines to SYSTEM_TOOLS and submit it to the SmallEiffel people.
Don't bother trying MaxonC. It can't deal with many simple ANSI C constructs, and thus is useless for the C code generated by SmallEiffel.
I just installed a C compiler, but even hello.c doesn't compile!
Bad luck. Check the manual, contact the support of the C compiler, or describe your problem in comp.sys.amiga.programmer.
Yes, but it should be included with your compiler anyway.
(If you toy with the C compiler options, you can also write certain programs without it. But if you are already that experienced, you wouldn't ask this question, would you?)
Do I need the AmigaOS includes?
Yes, unless you want to start messing. If you don't have them, get them, for example from the Developer CD.
No, if you don't want to use class DIRECTORY or sofa library, and don't mind a couple of warnings during installation.
I can compile hello.c with the C compiler, but when I try hello.e with SmallEiffel, it doesn't work.
Ensure that in your user-startup the "BEGIN sofa" part comes after possible initializations of your C compiler. If you have installed Sofa before your C compiler, this is probably not true. In this case, just load the user-startup in your editor and move the Sofa related stuff to the end of the file.
If this was not the problem, try again with SnoopDos (aminet:util/moni/) and submit the generated log to the Sofa Support.
A couple of minutes ago, everything worked fine, but now the C linker chokes!
Probably you changed the options passed to compile. For instance, you added a -boost. SmallEiffel's incremental compilation is not very smart in this respect, and doesn't automatically rebuild the program from the scratch.
Just type
clean root_class
to remove all traces of previous compilations. Then try to compile again.
I'm using SAS/c and just created a SCOPTIONS file. Now the C linker chokes!
With its minimalistic default options, SAS/c wouln't be able to compile the C code generated by SmallEiffel. (Major problems are the lack of a floating point link library and near code and data models.) So SmallEiffel usually passes appropriate options to SAS/c that guarantee that the C compiler and linker can cope with the C code, although they might cause some unnecessary bloat.
If you want to specify more optimal options or additional link libraries (such as the sofa library) in a SCOPTIONS file in the current directory, you have to manually specify those usually automatic basic options.
Just make sure that SCOPTIONS contains the following lines:
Data=far
Code=far
Math=ieee
Parameters=both
Batch
(Again ,this is not a very optimized set of options. But now the program should compile again, and you can refine them later.)
Furthermore, do not enable StringMerge, it will probably break your code.
Why are the compiled programs so big?
Maybe because you compiled them with assertions enabled. Checking assertions introduces a huge overhead both in performance and size, but also checks for bugs and gives detailed information about failed assertions. In production code, you can disable assertions by specifying -boost.
Nevertheless, Eiffel has a general tendency towards big executables. Even with -boost, you quickly get programs with 100 to 200K, although the source code might be ridiculously small. There are several reasons for that:
But once Eiffel programs have reached those 100 to 200K, they continue growing quite slowly.
Why are the compiled programs so slow?
First, they speed up a lot with -boost (see the previous question) because all assertion checks are disabled.
But a major reason is that Eiffel does a lot of dynamic memory allocations. For example, strings and arrays can grow as needed. This is quite different to most C programs, which use hardcoded limits and just crash at a certain size of input. ("Hey, but they crash much faster!").
Internally, SmallEiffel uses the ANSI C functions malloc() and calloc() for memory allocations. With some C compilers, they are very slow (e.g. SAS/c). Fortunately, there are libraries which can map malloc() to the memory pools, for instance aminet:dev/c/MemPools.lha. Just link it to the executable.
Can I use SmallEiffel to develop serious applications?
No.
The included version of SmallEiffel is particular vulnerable to all sorts of errors in the environment it is executed in. For example, it does not detect when it runs out of memory and cheerfully continues to read and write memory through NULL pointers (the C equivalent to Void). Furthermore, it simply ignores read and write errors during file access. Additionally, there are some limitations with garbage collection described below. And try to stay away from complex expanded classes (which don't really seem to work with any Eiffel compiler - duh).
Bwuahahaha! How can anyone possibly use this crap?
Well, many contemporary C++ and Java environments have similar problems. (Ok, error detection with file handling usually works). And take a look at the average C program: how many of them check for NULL after malloc(), how many of them check the result of puts() or fwrite()? Not many, you will find. And still, people even dare to sell such shit.
Consider SmallEiffel a nice toy for developing in-house tools or zero-reliability software like games. Apart from that, there is a certain chance that it will improve in future.
Can I use SmallEiffel to develop shared libraries or reentrant code?
Very unlikely.
The problem is that for reasons of portability, SmallEiffel heavily relies on ANSI C functions, which in turn many of them use global variables and buffers.
Additionally, Eiffel's once features don't fit well with them either.
Can I use SmallEiffel to develop applications that start new tasks?
Not in a way exec/CreateNewProc() would support it. And for similar reasons as above, it's unlikely that SmallEiffel will get built-in support for multi-threading soon.
However, you can use system in class GENERAL to start another program in an own task like
system("run <>nil: some_application")
Then use Rexx for communication between them.
Although sofa library doesn't support it yet, it should also be possible to use more flexible dos.library/System() for starting and the lighter exec message ports for communication.
Buhuu! Eiffel is nice, but SmallEiffel sucks. Aren't there any other Eiffel compilers for AmigaOS?
No.
There is an incomplete Eiffel compiler written in AmigaE available from aminet:dev/e/eiffel.lha. It has a lot of promising concepts, but too many things are missing to consider it useful and the original author has abandoned it.
Does garbage collection work in Sofa?
Yes.
Does garbage collection really work in Sofa?
The practical usefulness of a garbage collector depends a lot on the implementation. Too simple garbage collectors can freeze a program for a considerable time during collection, perform horribly in low-memory situations or crash at all, leak memory for certain special cases, have a considerable memory and performance overhead etc.
Most of these unfortunately apply for the garbage collector in Sofa.
Apart from that, there are a couple of problems with redefining dispose in class MEMORY (comparable to Oberon's dispose or Java's finalizers). Some of them are related to an incomplete implementation in SmallEiffel, others to undefined situations in the Eiffel language.
Does garbage collection work in general?
No, but it will still take some time for the software industry to grasp that.
Not considering that many practical implementations don't work because of the reasons mentioned in the previous question, garbage collection has several conceptional problems, which have not been solved even theoretically:
Despite all this, garbage collection is probably still an improvement to manual resource handling, at least for memory related resources. But it's in no way a solution for general resource handling.
Garbage collection is not very interesting from a technical point of view rather than a psychological one. It's a nice example for a "out of sight - out of mind" strategy which is very common among certain people(s). Freud would probably have called it a successful application of "Verdrängungsmechanismen".
According to the manual, SmallEiffel can compile to Java. So where is compile_to_jvm?
A compile_to_jvm executable has not been included with Sofa because nobody has yet done a remotely useful implementation of the Java Virtual Machine for AmigaOS. Yes, there is some stuff floating around, but if you can make it work you can easily figure how to compile compile_to_jvm.
For normal beings, it would only have wasted storage and bandwidth.