I downloaded Eiffel Studio for Linux 64-bit from http://eiffel.com, un-TAR-ed it and... Well, I understand why there was no any GUI installer, and I needed to make all copyings by hand. "That's Linux, baby", like *nix-fans like to say, and it was a GPL edition. Well, no problem for me, the more the web-site contains detailed instructions on how to finish the installation... except where the Eiffel Studio's executable resides on. The only thing said at the site is that the executable is named "estudio". I needed to use "find" to actually find that executable in the wilds of directories. Well, nice beginning, I should say.
OK, finally I launched the Studio. It has loaded and first asked me whether I want to create a new project or not. OK, I said, create console "Hello World" for me. Step 2: "Do you want to precompile Eiffel libraries?" Why not, I thought and pressed "OK". Next 15 minutes I was waiting until the compilation finishes.
Finally the pre-compilation has finished and an editor with main application's class has opened. And I've started to experiment with the IDE.
The first question which arose in my mind after little playing with Eiffel Studio is: why so #%!$@ slow!? Seriously, even NetBeans on computer with graphics acceleraion turned off (due to dead graphics card) works faster, much faster, enormously faster. I even could see how separate windows were being repatinted, line by line.
The next questions were: 1) why should one need to bind separate keys on "auto-complete class name" and "auto-complete method name" functions? 2) how to bind key on "toggle/remove breakpoint" function (it is not listed in shortcuts menu); 3) how to set breakpo... oh... why can breakpoints be set/removed in debug mode only? 4) where the hell does application's output go? 5) why the hell should I see application's output in terminal where I launched the Eiffel Studio rather than in the IDE's "Output" window?
You may say: it's not Eiffel Studio's fault, it's Linux that fails, because Linux never had sane GUI-s and especially IDE-s. But I say: no. Eiffel Studio is written using Eiffel language and Eiffel method which are advertised as advanced technologies of writing software which allow to prevent 90% of the bugs from ever occuring — and what bugs remain are easily traced and repaired. Should I say that this is just a "classical" advertisement, not a truthful one?
...When I have finished my first "Hello World" with bells and whistles I decided to compile release version of it. I clicked "Finalize..." menu item (it is the function which compiles release version; I even have read about Eiffel™ Melting Ice©® to determine it), answered some questions and... For those who will use this piece of software there is a hint: your release executables are in "<project>/EIFGENs/F_code" directory. Not "bin", not "Release", not root one — not any generally accepted directory but "<project>/EIFGENs/F_code". Don't forget it.
The compiler first generates C code for your Eiffel classes and then compiles it using installed C compiler (GCC in my case) which results in executable highly optimized by speed and size. The C code is put into "C1", "C2", "C3" directories in "F_code" directory and looks like following: "r15(r19); C16* r16 = r1(r2, r35); r18(r19(*r20), r90());". The compilation lasts for about the same time as the precompilation of Eiffel's library, because it is needed to be optimized for release too. After the compilation succeeded I've got an executable weighing... 11 MB. I repeat: eleven megabytes of binary code. Man, are they even serious? 11 megabytes for just printing "Hello World" to STDOUT (OK, and sum up two integer numbers as well)? If that's an application with single class, what will enterprise-level system with thounsands of classes result in?
My next try was to recompile release executable with assertions disabled (which is in fact not recommended by Eiffel™ method). The result is not much better: approx. 2 MB. For comparison: main executable of "A7XPG" game written in D (the language developed by Digital Mars featuring contracts, automatic memory management and compiling into native binary code) weighs approx. 1.43 MB.
To complete the picture, I gave the Eiffel Studio™©® a try on my beloved OS, Windows XP. The installation process went much smoother, I just needed to double-click the "*.msi", to enter installation path and the language, and the installer made the rest... except that it hasn't found MinGW installed on my computer. Moreover, when I asked it to show me details of the warning, it has crashed on displaying dialog:
Nice beginning, too. But may be the installer is not written in Eiffel, may be it's MSI problem, so let's not blame the developers prematurely. The installer has put links to Eiffel Studio™©® executables into "Start" menu, so I didn't need to search for the executable myself. After the installation has finished, I've launched the IDE. Nice splash screen with shadows appeared for some time. Then main window appeared and the Studio asked me whether I want to create my first project...
I could not find adequate words to describe what I have seen, so you should look at it yourself:
(sorry for russian language; the symbols highlighted in the image do not exist in russian alphabet; in short, the encoding issue takes place), and the natural result of it:
The year is 2012. The curtain falls to the narrator speaking: "Eiffel language and Eiffel method allows to prevent 90% of the bugs from ever occuring — and what bugs remain are easily traced and repaired".
Resume. Canonical, theoretically sound OOP (not that truncated %@$# implemented in Java or, the more, in C++) looks very attractive for software developers: better code organizing due to classes and better software modularity as a result, high reliability of the software due to contracts, clearer division of labor and responsibility due to "open/close" principle etc. All of those were in real need in late 1960s, in time of structured paradigm domination, and Simula 67 looked like a breakthrough. Adepts of OOP prophesied era of reliable software and of high code reuse. But time passes and we still write linked lists and hash tables from scratch in every software project we start. Why, you ask? The answer is simple: OOP does not produce reliable and scalable code. In fact it is anti-modular pattern and is also anti-parallel (which is vitally important in modern times). It looks like it can result in reliable'n'scalable code but in fact it can not do it (and more and more developers all over the world start to understand it, there is plenty of "OOP fails", "OOP does not work" hype in Internet recently). The result is obvious: no matter whether you use canonical OOP or just write in C with namespaces, you get a piece of software which stinks the same. Just look into bug list in http://eiffel.com and compare it with one of http://eclipse.org. Try to find 10 differences.
Short resume. Our company will not use Eiffel for its projects. Oh, and object-oriented paradigm sucks. This time proven by Eiffel Software.
While I'm not particularly impressed by Eiffel myself (and Eiffelstudio was pretty terrible in my limited experience) - These Problems aren't due to Eiffel. They're also not the kinda Thing that contracts could protect against. That's just sloppy programming.
ReplyDeleteOh, and UIs on Linux don't suck in my experience either.
You know your projects stand out of the herd. There is something special about them. It seems to me all of them are really brilliant!
ReplyDeleteHbse