0

We are looking to build a website on top of an existing Eiffel business-tier core, which is sitting over a MS SQL Server database. I am presently considering the advantages and disadvantages of writing the web and mobile tiers either purely in Eiffel, purely in typical web-stacks, or some hybrid.

For us, there are clear advantages to pure Eiffel, not the least of which are:

  1. Inheritance and other language notation mechanisms not found in other languages.
  2. The compiler cannot see into code from other languages, so we are at the same disadvantage one we cross out of Eiffel into something else.
  3. Auto-Test is something we heavily rely on in our Eiffel code, which takes clear advantage of Design by Contract. In other languages, we lose this power and are left with TDD (e.g. their version of Auto-Test in Eiffel).
  4. We now have to learn more than: Eiffel, HTML-5, CSS-3, JS, and whatever JS framework(s) we use.
  5. Every new language and tool adds more complexity to the project.
  6. Eiffel programs are compiled to C --> EXEs, which are far faster than their scripted and interpreted counterparts.

I think there are also some clear advantages to existing, non-Eiffel languages as well:

  1. Existing frameworks and tools can develop simple to moderate web sites and mobile applications rather quickly.
  2. Existing "best-practices" are not terrible and producing reasonably reliable and maintainable code.

I am not sure what all of the advantages and disadvantages are, so I am asking. However, at the end of the day: Our core business suite is pure Eiffel. That will never change.

Thanks in advance for the feedback!

Liberty Lover
  • 844
  • 10
  • 12

2 Answers2

1

Here is what I can say from my own experience (I have create several web applications in different frameworks including one in Eiffel). First, the Eiffel Web Framework is quite usable right now. The advantage of other frameworks are their features. Here is a list of the major problems I encounter when I created my web application with Eiffel:

  • I had to create the MVC design myself (other frameworks like Django, Rails or Laravel does that automatically).
  • Eiffel lack is a good templating system. The Smarty library is ok, but it really lack some really good template features that other has. Also, trying to work with UTF-8 file in Smarty can be quite difficult (this has been a pain for me).
  • I had to do some session management based on cookies because the one in Eiffel Web Framework was quite primitive.
  • The release process (removing Nino) was not easy and lack good documentation (I was using Apache, I don't know about IIS)

That's it, other than that, every thing went quite smoothly.

Louis M
  • 576
  • 2
  • 4
  • Hello Louis! Thank you for the very quick and helpful response. I look forward to hearing from others. Perhaps I can query you further based on your responses above: – Liberty Lover Mar 19 '15 at 17:08
  • 1. "Eiffel lacks a good templating system"—Looking at "Smarty" reveals that it is just a tag replacement system, where HTML templates loaded with "replacement tags", which are then served up to the client by the server. Is that basically it? If yes, then I don't see why such templates could not be stored as Eiffel class constant {STRING} features with tags and replaced on calls to {STRING}.replace_substring_all (s). – Liberty Lover Mar 19 '15 at 17:17
  • 2. The session management is of concern to me and I will ask the EWF team about the matter. 3. Why did you choose to use Apache Vs. Nino? It seems that if one uses Nino, then the release process is pretty straight forward. 4. What about the release process was difficult? Thank you kindly for your responses! P.S. — I hear the "poor documentation" rant LOUD AND CLEAR and I AGREE! It is an area of extreme need. – Liberty Lover Mar 19 '15 at 17:17
  • 1
    1 - Smarty is not only a string replace system. You can add some logic to it like iterate over a list or if condition. So, no, I don't think it can be replace with a simple replace_substring_all call. 2 - Ok. 3 - As I understand it, Nino is only a debugging tool (so that you can debug directly into EiffelStudio). So I think that, in the feature and security department, I have more trust in Apache. 4- What is difficult is making a virtual host to accept the Eiffel program. But then again, maybe I did it wrong (the documentation was not very helping me in that process). – Louis M Mar 19 '15 at 17:47
  • About Smarty, this is more than just tag replacement. It was inspired by http://smarty.net/ and has condition, loop, variable support, and others. It would need improvement related to unicode or utf-8 but as it is now, it can be used. But I also agree with Louis, that if we had a better template library it would not hurt. – Jocelyn Mar 23 '15 at 09:30
  • About deployment concern for EWF, using apache and libfcgi , nothing is specific to Eiffel or EWF. You can refer to any documentation for libfcgi and apache2. However I agree, the EWF project should provide more documentation for this specific task, and eventually a tool to generate apache2 configuration settings. – Jocelyn Mar 23 '15 at 09:35
  • About session management, Louis, it could be great if you could share your session management system, as a standalone library, or also by contributing to EWF project. Don't hesitate to contact me if needed. – Jocelyn Mar 23 '15 at 09:36
  • Of course I can share my work on session management in the future. But for now, I do not have the time to document it and create the actual library. When I did, I will put it on my github. – Louis M Mar 23 '15 at 21:08
1

The next list of disadvantages is from my naïve point of view:

  1. The EWF package is not finished, it's going to have more nice capabilities in the future, therefore you may need to follow the new development to take advantage of new functionality.
  2. Eiffel compiler makes it impossible to update a web program on the fly, it needs to be recompiled and redeployed.
  3. If the program is going to be multithreaded, you need to learn a structured way to deal with concurrency based on the SCOOP model.
  4. Some tools (e.g., XSLT processors) are not readily integrated into EWF, you may need to do this yourself.
  5. The current EWF API is rather low-level, so before higher-level frameworks built on top of EWF become widespread, you may need to do more low-level programming than expected (by low-level I mostly mean the way to generate HTML/XML/or some other format your web service is going to produce).
  6. Having to use just one language to do both application logic and HTML generation, that allows for easy debugging, may lower the requirements for the developers and their skills, that may affect your business model.
  7. There are several tools that address specific needs like wiki, simple web-page creation, authorization, etc., but you may need to enhance them to get richer functionality as well as to design the architecture of your software, because some idioms and usage patterns are not established yet.
Alexander Kogtenkov
  • 5,770
  • 1
  • 27
  • 35
  • If deployed on Unix (e.g. a Gnu/Linux), then you can do 2, using `fork` and `exec` system calls. You basically create a new process, that is listening to same ports, and exec the new program, then signal the old process to exit. – ctrl-alt-delor Jul 25 '15 at 21:16