Request for information concerning Eiffel's competitive advantages 
Author Message
 Request for information concerning Eiffel's competitive advantages


Quote:
>I find I'm faced with two inter-related questions, one the more specific
>version than the other:
>1) What are the business costs and benefits in
>using an OOP development metaphor?

Costs: some difficulty in encapsulating legacy or off-the-shelf systems
that are not OO, or not programmed in your development language.

Benefits: Modular code that directly implements business rules.

 2) What are the business costs and

Quote:
>benefits in using Eiffel, as opposed to C++ (which is viewed, by
>management, as the default OOP language (since programmers have always
>told them it is "the way to go"))?

Costs: Its not mainstream (sorry, Bertrand).  Hence most of the off-the-shelf
systems available will need some kind of Eiffel wrapper put around them,
most CASE tools don't generate Eiffel skeletons or reverse-engineer Eiffel
code.  BON does of course, and CASE vendors will be typically be prepared
to add such functionality for a few tens of thousands of pounds.
Incidentally, ISE has a product to encapsulate C++ interfaces in Eiffel
automatically.  This can help a lot.

Benefits: A decent language.  This cannot be emphasised enough.  The
implementation language makes a huge difference to the final product,
including its costs.  Take a look at the Rainbow project description on
the ISE web site (amongst others).  Large, successful Eiffel project.

Quote:
>My aim is to develop a cost/benefit analysis of continuing to develop in
>C, compared with C++ or Eiffel. I'm interested in costs to the business
>1) initially (during startup), 2) over time, and 3) the various risks
>each option holds.

>Issue  1 ----------- * Are you able to provide me with relevant metrics,
>or relevant studies, that compare programmer efficiency, bug levels,
>flexibility of code changes, etc. when coding in structural (C) languages
>versus OOP (C++ or Eiffel)?

No.  I doubt that anyone is (but would be very interested in such figures
myself).  All we have is enthusiastic reports from everybody who has
tried Eiffel on a real project.

Most people who try C++ are fairly enthusiastic as well, but lots of them
have run into problems trying to tame the language.

 * What costs (I suppose, per function point)

Quote:
>is involved in interfacing OOP code with an existing C code-base? (ie.,
>what needs to be done; how much pain could be involved)

See above comments.  Don't rate it per function point, rate it per routine
or data structure element.

C++ (thanks to its C base) can usually import C headers easily, although the
divergence between C++ and ANSI C is likely to cause problems.

* What amount of

Quote:
>retraining is generally required to retrain an adequate
>structural-oriented programmer into an adequate object-oriented
>programmer? (This may or may not be a big issue for us, depending on who
>we hire.)

Tricky.  There are two issues: learning the language and aquiring "object
think".

Language: There are plenty of C++ programmers out there, but Eiffel is very
easy to learn.  Not a lot of difference on balance.  If you expect to grow
your own C++ programmers then expect it to take a very long time: C++ is
hard.  Also, beware of anyone who claims C++ on their CV without plenty
of real experience.  C++ is not something you learn at a one week course.

OO-think: This is more difficult.  Structured developers have a particular
way of tackling things.  OO does it differently.  Developing this new mindset
can only be done by experience.  Again, beware inexperienced C++ weenies.

Quote:
>Issue 2 ----------- * Are you able to provide relevant metrics, or
>relevant studies, that compare programmer efficiency, bug levels,
>flexibility of code changes, etc. between C++ and Eiffel?

Nothing quantitative, but this is generally reckonned as one of the great
benefits of Eiffel.  Again, see the Rainbow project report on this.

In general the benefits of Eiffel will come downstream.  Flexible,
maintainable, readable software is far better to own and look after
than the stuff you get with C++.

* What cost

Quote:
>differences could there be between interfacing C and C++ between
>interfacing C and Eiffel codebases?

See above.

* What level of training is generally

Quote:
>required to retrain a competent C++ programmer for Eiffel?

Not much.  Eiffel is very easy to learn.  Your C++ programmers will love
you for it.  They should be producing code in two or three days.

* Have there

Quote:
>been any studies done to determine whether top-notch programmers are more
>or less likely to *want* to work for a company that develops in Eiffel,
>as opposed to C++?

Somebody who has looked at Eiffel outside of their current work has
demonstrated a broad interest in software engineering that goes beyond
their next paypacket.  I don't know of any studies, but I'm quite sure
that if you advertise for Eiffel you will get the best.

(ie., do programmers reject jobs from companies using

Quote:
>Eiffel because the skill-sets they are investing in are not in as great a
>demand? or do they view it as a strategic advantage? Is there any study /
>evidence to support the position.)

On the other hand, I dare say that grunt programmers who are more interested
in their CV than your project will be put off by Eiffel.  Which sort do
you want to hire?

 * What costs are likely to arise using

Quote:
>a cross-platform C++ implementation (are there any?) versus Eiffel for
>cross platform programming?

Most Eiffel compilers produce C, which then has to be compiled and linked
with an precompiled run-time library.  The main cost would be paying your
vendor to port the run-time to your target, and tweak the generated code
to conform to any odd requirments or bugs of your target compiler.  Neither
of these are large costs, but would need to be negotiated.

* Is Eiffel capable of producing high

Quote:
>performance, multi-threaded server applications?

Existing Eiffel compilers do not support multi-threading.  You can write
CORBA front ends.  ICL do a CORBA-Eiffel product.  This might also help
you encapsulate legacy or off-the-shelf applications.

ISE is about to release a threaded Eiffel compiler.  However this is new
technology, and I would not want to bet a large project on it.

* How would you

Quote:
>characterise the performance (hardware demands) of a well-written
>single-threaded, server application that communicates via a network
>written in C++ versus Eiffel?

No particular difference.

* How would you characterise the

Quote:
>performance (hardware demands) of a well-written multi-threaded, server
>application that communicates via a network written in C++ versus Eiffel?

See above comments about multi-threaded Eiffel.

Quote:
>* Do you have any evidence to support the view that multi-threading,
>concurrency, etc. is easier / quicker / less costly to implement in
>Eiffel than C++? (or vice versa)

Multi-threading is not directly supported by C++, but its fairly easy
to create class libraries to do rendevous and message passing.  Or you
can just use CORBA.

Threaded libraries don't work with Eiffel because the garbage collector
has to know what the stack is doing, and threads work by maintaining multiple
stacks.

* Does Eiffel enable the production of

Quote:
>CORBA objects?

Yes.  Talk to ICL.

Quote:
> How would you characterise the risk of investing heavily
>in Eiffel, when it isn't supported by large tools vendors? Partly in
>extension to this: How would you characterise the risk of Eiffel tools
>makers not keeping their technology development in synch with other
>related technologies (CORBA is a case in point; COM/DCOM could be another
>one), or having significant time-lags in implementing necessary new
>technology?

Eiffel has been around for 10 years, and is showing slow but steady growth.
Its not about to go away.

Graphical CASE tools are less important for Eiffel because your analysis and
design is embedded in the code.  See above for comments about tool vendors.

CORBA is already available.  I'm not sure about the DCOM situation.

 * Can Eiffel produce dynamically loaded modules, such as

Quote:
>DLLs? (I've skimmed the DLE paper. Is this equivalent to DLLs? or is this
>something different?)

This is something different.  Eiffel has problems with DLLs because of the
system-wide optimisations it does: when it compiles a DLL, it has no
information about the future systems it may be linked to, and so cannot
do these optimisations.  C++ gets around this problem by forcing the
programmer to do these optimisations instead.

Despite this, Visual Eiffel from Sig can produce DLLs.

Paul.

--
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+




Mon, 15 Nov 1999 03:00:00 GMT  
 Request for information concerning Eiffel's competitive advantages

Quote:

>I find I'm faced with two inter-related questions, one the more specific
>version than the other: 1) What are the business costs and benefits in
>using an OOP development metaphor? 2) What are the business costs and
>benefits in using Eiffel, as opposed to C++ (which is viewed, by
>management, as the default OOP language (since programmers have always
>told them it is "the way to go"))?

>My aim is to develop a cost/benefit analysis of continuing to develop in
>C, compared with C++ or Eiffel. I'm interested in costs to the business
>1) initially (during startup), 2) over time, and 3) the various risks
>each option holds.

I am interested in seeing the result of this investigation. Could you post
the results of your investigations to this group and email it to me?

As far as I know, there is very little available documentation on this
sort of thing. I have read about one study that showed C++ as more costly
than C in the long run (with code mantainence in particular being more
expensive!!). The little that I have seen is often vauge about details so
it is hard to see _why_ one solution cost more than another.

On the issue of selling Eiffel to management, one approach is to call it
"an OO high level automatic C code generator". Many (most?) Eiffel
compilers generate C code (I think I have even seen one that generates
C++) that is then compiled to the target platform. Boast about all the
security, mantainability, OO, etc gained by using Eiffel as a tool to
automaticly generate C code!

ABO



Mon, 15 Nov 1999 03:00:00 GMT  
 Request for information concerning Eiffel's competitive advantages

Quote:

> I am joining a "new company" next week. The organisation is an
> independent R&D group, funded by an existing corporation. We are charged
> with developing network-based applications, based on the company's core
> platform---which is a transaction-based system.

> We will mostly be developing applications in the mid-tier. Clients range
> from terminals on private networks to Java devices via the internet. The
> platform communicates with a large number of Hosts (mostly mainframes,
> UNIX supercomputers, etc.).

> The existing platform is written in C and compiled for a range of UNIX
> platforms and Windows NT.

> I am charged with investigating key developments for this platform, and
> in investigating the technologies with which we should implement the
> developments.

> I find I'm faced with two inter-related questions, one the more specific
> version than the other: 1) What are the business costs and benefits in
> using an OOP development metaphor? 2) What are the business costs and
> benefits in using Eiffel, as opposed to C++ (which is viewed, by
> management, as the default OOP language (since programmers have always
> told them it is "the way to go"))?

1) Read the literature, but there is ample evidence for OO being the way
to go.

Check out Ian Joyner's C++ critique if you want a language comparison.

Do the programmers know of, or have used, any other OO languages than
C++?

Some of the cost comparisons with C++ are not obvious. For example, with
C++
you have to maintain makefiles, and buy the make, (or aquire it) in the
first place. Maintainance of makefiles doesn't come cheap. In Eiffel,
you just
don't do this. The complier does the work.

Look at C++. Programmers spend a lot of effort and time writing memory
management code. It is very error prone. There are lots of programs
to help you find these errors, Purify, Sentinel etc ... These cost
money,
and to use them they cost money. You would rather have your programmers
producing end usable code. Eiffel - not an issue, let the Garbage
collector
do it for you. Also GC is faster. Reference counting doesn't always
work.

Read Scott Meyers and others about how to write robust C++. All those
rules and
Gotchas, some very {*filter*}. Look at all the C++ lint programs using AI
style
rules to check code (just on the market). The cost money to buy and use.
(see above)

Quote:
> My aim is to develop a cost/benefit analysis of continuing to develop in
> C, compared with C++ or Eiffel. I'm interested in costs to the business
> 1) initially (during startup), 2) over time, and 3) the various risks
> each option holds.

> Issue  1 ----------- * Are you able to provide me with relevant metrics,
> or relevant studies, that compare programmer efficiency, bug levels,
> flexibility of code changes, etc. when coding in structural (C) languages
> versus OOP (C++ or Eiffel)? * What costs (I suppose, per function point)
> is involved in interfacing OOP code with an existing C code-base? (ie.,
> what needs to be done; how much pain could be involved) * What amount of
> retraining is generally required to retrain an adequate
> structural-oriented programmer into an adequate object-oriented
> programmer? (This may or may not be a big issue for us, depending on who
> we hire.)

Retraining Structured programmers to OO is another issue. Read up on the
literature. However, we have accountants, and mathematicians all using
Eiffel, all of whom hadn't used it before. They write code that goes
into a production system. I doubt that C++ houses would allow end users
to do that. Learning Eiffel is relatively easy, even for C++
programmers.
They may complain about the lack of braces, but if they cannot cope with
the change from } to end, then they show a remarkable lack of
flexibility.
Are you really sure you want to employ them?

Productivity wise. I much better off in Eiffel than C++.

Quote:
> Issue 2 ----------- * Are you able to provide relevant metrics, or
> relevant studies, that compare programmer efficiency, bug levels,
> flexibility of code changes, etc. between C++ and Eiffel? * What cost
> differences could there be between interfacing C and C++ between
> interfacing C and Eiffel codebases? * What level of training is generally
> required to retrain a competent C++ programmer for Eiffel?

I didn't have any. It took a very short period of time. Best idea I can
suggest is to get them to read OOSC II. (It will make them a better
programmer anyway)

Quote:
> * Have there
> been any studies done to determine whether top-notch programmers are more
> or less likely to *want* to work for a company that develops in Eiffel,
> as opposed to C++? (ie., do programmers reject jobs from companies using
> Eiffel because the skill-sets they are investing in are not in as great a
> demand? or do they view it as a strategic advantage?

I do. Every other programmer he is good. They have PhDs, and or give
presentations at conferences. If I was recruiting the other way, use
of Eiffel would score highly.

Quote:
> Is there any study /
> evidence to support the position.) * What costs are likely to arise using
> a cross-platform C++ implementation (are there any?) versus Eiffel for
> cross platform programming? * Is Eiffel capable of producing high
> performance, multi-threaded server applications? * How would you
> characterise the performance (hardware demands) of a well-written
> single-threaded, server application that communicates via a network
> written in C++ versus Eiffel? * How would you characterise the
> performance (hardware demands) of a well-written multi-threaded, server
> application that communicates via a network written in C++ versus Eiffel?
> * Do you have any evidence to support the view that multi-threading,
> concurrency, etc. is easier / quicker / less costly to implement in
> Eiffel than C++? (or vice versa)

My one experience of C++ for a distributed system was a disaster. There
were
experienced people, who had written such systems in the past. We bought
in
software to do the networking.

Quote:
> * Does Eiffel enable the production of
> CORBA objects? How would you characterise the risk of investing heavily
> in Eiffel, when it isn't supported by large tools vendors? Partly in
> extension to this: How would you characterise the risk of Eiffel tools
> makers not keeping their technology development in synch with other
> related technologies (CORBA is a case in point; COM/DCOM could be another
> one), or having significant time-lags in implementing necessary new
> technology?

ICL sell such a package. I have never used it.

Quote:
>* Can Eiffel produce dynamically loaded modules, such as
> DLLs? (I've skimmed the DLE paper. Is this equivalent to DLLs? or is this
> something different?)

I believe ISE can, and Visual Eiffel on PCs.

Quote:
> Should you have any other key issues that would impact on my R&D group
> using Eiffel vs C vs C++ please let me know. I've only recently
> "discovered" Eiffel; and am quite e{*filter*}d about its philosphy,
> methodology and notation. I do expect it to be difficult to sell it to my
> management. So, in producing this cost/benefit analysis, I'm interested
> in both startup and lifecycle costs, as well as technological and
> market-driven risks. It is true that marketing dominates the software
> industry; that mindshare is very important---because the intellectual
> capital that one builds in utilising a technology can be a significant
> asset, or liability. However, if you don't also focus on the technical
> merits, regardless of the latest fashion, you could be  injuring the
> quality, timeliness and reliability of your development.

Eiffel is mature. Java isn't. C++ is a moving target. If you look at C++
why is it that all of the compilers don't meet the standards.

In Eiffel you can concentrate on producing the correct model, in C++
you have to concentrate of what the compiler is up to, and writing code
that you shouldn't be, such as memory management. Listen in on the C++
groups and within a day you'll get the idea.

Quote:
> I'm attempting to develop a business case that weighs both these factors.
> Your response will be appreciated.

--

Nick



Mon, 15 Nov 1999 03:00:00 GMT  
 Request for information concerning Eiffel's competitive advantages


Quote:

[snip]

> 2) What are the business costs and
>>benefits in using Eiffel, as opposed to C++ (which is viewed, by
>>management, as the default OOP language (since programmers have always
>>told them it is "the way to go"))?

[snip]
>Benefits: A decent language.  This cannot be emphasised enough.  The
>implementation language makes a huge difference to the final product,
>including its costs.  Take a look at the Rainbow project description on
>the ISE web site (amongst others).  Large, successful Eiffel project.

Without reading the Rainbow project description, I would have to say that
I don't belive the choice of language makes much difference at all when
compared to the big picture. There are many more things to a big software
project than just code. Coding is infact only a very small part.

In my experience, the procedures used and mental approach make a bigger
difference than the language used. Good design, coding, documenting,
testing, configuration, etc practices matter far more than the language.

However, it is true that a good language can encorage you to use good
practices, and help reduce the coding (and sometimes documenting) effort a
bit. It is also true that programmers with experience in languages like
Eiffel usualy also have experience with good practices in general.

Another thing that can compensate for a "bad" programming language is a
good development environment. When comparing different languages, make
sure to take into account the whole package.

ABO



Mon, 15 Nov 1999 03:00:00 GMT  
 Request for information concerning Eiffel's competitive advantages

[...]

Quote:
> In my experience, the procedures used and mental approach make a bigger
> difference than the language used. Good design, coding, documenting,
> testing, configuration, etc practices matter far more than the language.

Well, it is hard so see if a design is good, until it is implemented in
a
running system. So, when you design something poorly, or you discover
a better design later you want to use a language that makes it easier
for you to change the code safely.

The Rainbow project has gone through many such changes, where a better
design was discovered only after a design was already coded and
used in the production environment.

Eiffel makes it easier to move to the new design mostly because of
static type checking and assertions, and partly due to the  ISE's
environment, garbage collection, no make files etc.

Quote:
> However, it is true that a good language can encorage you to use good
> practices, and help reduce the coding (and sometimes documenting) effort a
> bit. It is also true that programmers with experience in languages like
> Eiffel usualy also have experience with good practices in general.

Some of Rainbow's most productive programmers, were not programmers at
all (i.e. they may have taken some courses on programming, but never
programmed for a living). Instead they had much deeper understanding
of the problem to be solved.

...richie

--


*          Home page:   http://www.netlabs.net/hp/richieb          *
*        "Fight software piracy, use free software!" (me)          *
*        (Remove XYZZY  from my address before replying)           *



Mon, 15 Nov 1999 03:00:00 GMT  
 Request for information concerning Eiffel's competitive advantages

Quote:
> Despite this, Visual Eiffel from Sig can produce DLLs.

With a limitation: the interface of the DLL must be a flat procedural
interface using only the basic types (similar to the interface of a normal
C .DLL).

(The feature can still be useful, I'm just saying that in case some people
start to dream about objects flying over DLL boundaries.)



Mon, 15 Nov 1999 03:00:00 GMT  
 Request for information concerning Eiffel's competitive advantages

Quote:


> [...]

> > In my experience, the procedures used and mental approach make a bigger
> > difference than the language used. Good design, coding, documenting,
> > testing, configuration, etc practices matter far more than the language.

> Well, it is hard so see if a design is good, until it is implemented in
> a
> running system. So, when you design something poorly, or you discover
> a better design later you want to use a language that makes it easier
> for you to change the code safely.

> The Rainbow project has gone through many such changes, where a better
> design was discovered only after a design was already coded and
> used in the production environment.

> Eiffel makes it easier to move to the new design mostly because of
> static type checking and assertions, and partly due to the  ISE's
> environment, garbage collection, no make files etc.

I haven't been working on Rainbow as long as Richie. However I was
shocked at the scale of changes that were being made to the system.
Large changes to code hierarchies, if necessary were made. When I made
the first of these changes I was horrified at what I was doing. I
thought the risks involved in making such modifications were too large.
In practice, they aren't for the reasons Richie has mentioned.

Quote:
> > However, it is true that a good language can encorage you to use good
> > practices, and help reduce the coding (and sometimes documenting) effort a
> > bit. It is also true that programmers with experience in languages like
> > Eiffel usualy also have experience with good practices in general.

> Some of Rainbow's most productive programmers, were not programmers at
> all (i.e. they may have taken some courses on programming, but never
> programmed for a living). Instead they had much deeper understanding
> of the problem to be solved.

--

Nick



Tue, 16 Nov 1999 03:00:00 GMT  
 Request for information concerning Eiffel's competitive advantages

:I am joining a "new company" next week. The organisation is an
:independent R&D group, funded by an existing corporation. We are charged
:
:I find I'm faced with two inter-related questions, one the more specific
:version than the other: 1) What are the business costs and benefits in
:using an OOP development metaphor? 2) What are the business costs and
:benefits in using Eiffel, as opposed to C++ (which is viewed, by
:management, as the default OOP language (since programmers have always
:told them it is "the way to go"))?

One question you might ask yourself is "Does your management believe that
Eiffel must firmly prove its case, whereas C++ gets a free ride of
'innocent until proven guilty?'"  This may be a damaging philosophy.

The question to ask your management is "Do I have the authority to make
engineering and technology decisions if I am responsible for the
consequences?"   And also perhaps, "If we use the same tools as our
competitors, how easily will it be to realize a qualitative advantage?"

There are other, perhaps less obvious factors.  What is the impact on
programmer morale?  Will 'buying into Eiffel' in the current
market position encourage especially skilled and demanding
programmers who recognize "Dilbert-free" management? :-)

As far as support by "large tool vendors" consider that Microsoft summarily
disposed of its fortran (90!) compiler quite recently.



Tue, 16 Nov 1999 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Forth - A competitive advantage

2. Competitive advantage

3. Information on Digitalk's Visual Smalltalk Requested

4. Request for ISE post of Eiffel lex/parser for Eiffel

5. Concerns about reuse in Eiffel Implementations

6. Nobrainer concerning 'scan' command

7. Beginner's questions concerning Oberon V4 from J.Templ-CD

8. Why I'm concerned with FIB(20) benchmarks

9. Concerning int's interrupting eachother?

10. Forth's portability & advantages

11. A list of prog. lang.'s advantages

12. Advantage of VISA VI's?

 

 
Powered by phpBB® Forum Software