Monday, March 27, 2006

 

Eiffel's shortcomings for Enterprise Development

OK, that title is a bit intentionally controversial, in the hopes of sparking some useful conversation :-)

I am a relative newcomer to Eiffel, and would count myself as a friend and supporter but not a convert. Why do I hold back? That is an interesting question, that I felt fair to put some thought into. The following post is a summary of the results of that thinking. It is my thinking alone, but it is my hope that it might spark some conversation and lead to some useful plans for the future.

What is important in software development has changed drastically since the 1990’s, when the language wars were at their most significant. At that time, you had to write most of your application and infrastructure yourself, so your language choice was of pre-eminent importance. This is no longer the case. The biggest story of the 2000’s is that tools, libraries, and frameworks have far more impact on your productivity (and quality of output, given a fixed resource availability) than language choice.

This shift has very much changed the tenor of the conversation. How would I go about developing a (non-Eiffel) enterprise application at this point? I would most likely start by identifying the components that I most wanted to use (for example, to give an interesting mix of Open Source and proprietary, Spring, Hibernate, JMX, TIBCO's EMB, and Microsoft's WPF for UIs), and only then choose a development language by determining the most convenient common denominators (in this case, Java server side, C# client side, Web Services as a platform independent protocol between them).

To be honest with ourselves, we have to admit that Eiffel’s story on tools, libraries, and frameworks is poor, especially compared to languages with a huge company behind them (.NET), or a vibrant open source community (PHP, AJAX), or both (Java). In my opinion, if the Eiffel community can not address this question, the use of Eiffel will by necessity be relegated to small, internally focused projects where integration and framework needs are limited.

How can we address this question? I am not certain. Trying to encourage open source projects in Eiffel that port or otherwise replicate some of the functionality of the most significant frameworks out there (GUI toolkits, application servers, dependency injection, persistence tools, schedulers, etc.) might be a solution, but it is not clear to me that there are enough Eiffel programmers out there to make a real difference.

Another approach is to really focus on the areas where Eiffel brings the most benefit: the building of robust, verifyable, and clean core business logic. If there were enabling technologies that helped us cleanly connect Eiffel business logic to the "rest of the world", allowing us to reap the benefits of Eiffel where it counts most while still having all of the proprietary, open source, and other community work done in other languages and environments available to us, it could be a win/win for everyone.

There are certainly counter arguments to be made. First, most Eiffel environments provide the ability to link in or otherwise access non-Eiffel code. Second, the sophistication of Eiffel allows needed functionality to be replicated more quickly and efficiently that one might expect. Finally, by bridging to another language/environment you, by necessity, lose much of the type safety and verification that makes Eiffel so powerful. And, on a case-by-case basis, these arguments are indeed correct. It is when one stands back and looks at the immensity of what the Eiffel community would have to reproduce to catch up to, say, the Java community, that these arguments become questionable, at least in my mind.

I would appreciate the thoughts of the Eiffel community.

Comments:
I think it all depends on what libraries you need.

If I start a project in most other languages, I don't have libraries for stacks, hash tables, and the like. Or I don't have lex or yacc.

If you're a GUI person, you might miss something. But as HTML will take over the world, I suggest you reskill.

Or go to Eiffel.NET which gives you access to all .NET code. BTW, you can easily take your .net EXE and run it on Linux with Mono. Works amazingly well if you of course restrict yourself to libraries that are available on both platforms.

For the enterprise part, I agree. I finally understood why Eiffel wasn't used more in the Windows world when I seriously started to use ISE Eiffel some years ago. Impossible to write stuff for Microsoft Transaction Server. You can't write an NT service in Eiffel. Accessing COM libraries was possible, but not as easy as in VB or Delphi.
 
I disagree that avaiable libraries is the most significant factor that affects productivity.

The clarity of style you achieve by writing in Eiffel reduces maintenance time by so much that it more than offsets the samll time it takes to generate a wrapper around a C library using EWG.
Or if you are on .NET, then you don't even need to do this.
 
An interesting and insightful post, Bradley.

> we have to admit that Eiffel’s story
> on tools, libraries, and frameworks
> is poor

Agreed, the exception being users whose needs happen to match what is provided with EiffelStudio.

> encourage open source projects in
> Eiffel that port or otherwise
> replicate some of the functionality
> of the most significant frameworks
> out there ... but it is not clear
> to me that there are enough Eiffel
> programmers out there

There surely aren't enough Eiffel programmers for that. We have even had some of these Eiffel frameworks in the past, but lacked enough programmers to keep them running with new compiler/kernel versions.

For now, I think having clean interfaces to existing frameworks (written Java, C, .NET, etc) is the most practical approach.

It's a real shame that Dominique Colnet and Bertrand Meyer couldn't agree on the evolution of Eiffel, because now each sub-platform effectively only has half as many people working on tools and libraries for it.

> Another approach is to really focus
> on the areas where Eiffel brings
> the most benefit: the building of
> robust, verifyable, and clean core
> business logic

If you look at Eiffel success stories to date, they have almost all been enterprise-scale projects where the overhead of developing their own tools and libraries was a small part of the overall project size. This has been true since at least the early 90s.

> by bridging to another
> language/environment you, by
> necessity, lose much of the type
> safety and verification that makes
> Eiffel so powerful

Yes, and you also lose the elegance that makes the aplication so writable and readable, but it's the best we can do at the moment. If the interface to the other environment is compact, clear and robust then it's manageable.

> I am a relative newcomer to Eiffel,
> and would count myself as a friend
> and supporter but not a convert. Why
> do I hold back?

Take care, Eiffel is a powerful drug that doesn't let go easily once it takes hold :-)
 
What market are you addressing here?

Embedded? Mainframe? Web apps? Desktop apps? Custom software development/consulting?

People always used to rip on the mainframe developers because "the system did everything for them"; meaning it was easy to focus on helping your customers rather than worrying about debugging pointer errors. You would learn a compatible language, utilize a rich API, easy interaction with the persistence layer, and then be productive, simple, the ultimate "framework".

These days the major technologies, Java and .NET, are aspiring to mainframe success. Each has simple languages, rich APIs, easy persistence interaction (the extreme being LINQ with .NET), and there you go: just find some programmers and you are ready to make money.

Maybe you should be asking the question "In what situation would we make the most money by choosing technology X?" where X is Eiffel. The answer to that question would be a worthwhile area to pursue.
 
Hi all. Thanks for your comments. In seeing your responses, I realized that I might not have been clear enough about what I mean by 'Enterprise Development'. I am talking about large scale systems must be distributed for scalability reasons. In my particular field, we are concerned with real-time, event-driven systems with the requirement to process massive amounts of parallel transactions and feed summarized data back to the users in near real time.

All of this requires a sophisticated architecture, and many infrastructural components (such as messaging middleware, distributed transaction management, etc) that are a bit more complicated to develop than a hash table (although I must say that every useful & modern language that I am aware of has decent container support these days. We need to stop comparing Eiffel to C++ if we want to be taken seriously)

Eiffel.NET has a lot of promise as an integration solution, but it has not yet lived up to that promise. Each time I have tried to use it, it has lacked some feature that was necessary to properly use the library I was trying to access (last example was the ability to create a true Attribute in an Eiffel class). I fear that there are not enough people using Eiffel.NET for it to have the resources necessary to keep up with Microsoft.

I must respectfully disagree with Anonymous. For small project, clarity of style might possibly trump the productivity boost that you can get by using a library that encapsulates ten's of man years of development effort, but any reasonable project with more typically "messy" requirements will not. Our own blog recently posted a comparison to C++ that showed that Eiffel might (under the BEST of circumstances) be 2x as productive as C++; this just isn't going to compensate for having to write everything yourself.

Roger, thanks for your encouragement. I agree with your observations. How do we encourage the development of such integration in a way that we can share in the Eiffel community? My TIBCO/Rendezvous wrapper library doesn't do much good if it is locked inside our source control system...

Someday, perhaps I will be able to choose a project based on what language I want to use instead of the other away around. I've heard of that, and I think it is called 'retirement' :-)

Thanks for all of your thoughts.
 
In re-reading my post, I realized that I mis-spoke a bit about 'small project', which might have sounded derogatory. I more mean projects with a narrow focus. They may have a very high degree of complexity within that narrow focus, and be very powerful and productive tools.

Sorry!
 
Bradley wrote:
> real-time, event-driven systems with
> the requirement to process massive
> amounts of parallel transactions and
> feed summarized data back to the users
> in near real time

That describes the needs of ebay, paypal, hotmail and amazon, as well as just about every bank and other financial institution.

It's a huge opportunity for any software tool that can get a share of that market.

> Eiffel.NET has a lot of promise as
> an integration solution, but it has
> not yet lived up to that promise.

Before Eiffel.NET, ISE developed Eiffel# which was a slightly-diluted version of Eiffel specifically designed to integrate perfectly with .NET (even to the extent of using .NET idioms for e.g. object creation and inheritance).

I thought Eiffel# would have been very successful and was disappointed when ISE dropped it for Eiffel.NET which is more pure but less appealing to the average .NET developer.

> My TIBCO/Rendezvous wrapper library
> doesn't do much good if it is locked
> inside our source control system...

Because yours is a wrapper for a specialized proprietary product, I suggest to get ISE to negotiate with the vendor to add it to their list of API bindings (as ISE did with the Eiffel binding for Matisse). (TIBCO's lawyers don't want me to link to the webpage where they list their current API bindings for Rendezvous.)

> Someday, perhaps I will be able to
> choose a project based on what language
> I want to use ... I think it is called
> 'retirement' :-)

You can do that before retirement too, in which case it's called 'poverty' :-)

Grant wrote:
> Maybe you should be asking the
> question "In what situation would
> we make the most money by choosing
> technology X?" where X is Eiffel.

An interesting question indeed, and I'm struggling to come up with a good answer...
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?