Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.objective-c,comp.lang.eiffel,comp.object,comp.databases.object,de.comp.lang.c++
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.psc.edu!hudson.lm.com!news.math.psu.edu!news.cac.psu.edu!newsserver.jvnc.net!newsserver2.jvnc.net!howland.reston.ans.net!newsfeed.internetmci.com!news.mid.net!news.dra.com!indigo.dra.com!news.starnet.net!wupost!waikato!comp.vuw.ac.nz!actrix.gen.nz!dkenny
From: dkenny@atlantis.actrix.gen.nz (Des Kenny)
Subject: Re: OOPSLA'95: CFP Workshop on OO Legacy Systems
Keywords: Eiffel, Evolution
Message-ID: <DC9xJ1.HBE@actrix.gen.nz>
Sender: Des Kenny
Summary: Statistics can only relate the past 
Organization: Actrix - Internet Services
Date: Tue, 25 Jul 1995 13:30:37 GMT
References: <3ujbvp$gfi@gate.fzi.de> <DC0Lq2.EDp@actrix.gen.nz> <3uvrlh$pui@gate.fzi.de>
X-Nntp-Posting-Host: atlantis.actrix.gen.nz
Lines: 358
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:140593 comp.lang.smalltalk:26329 comp.lang.objective-c:4210 comp.lang.eiffel:10003 comp.object:35605 comp.databases.object:6664

In article <3uvrlh$pui@gate.fzi.de>, Eduardo Casais <fzi.de> wrote:
> > I suggest that the best long term solution is to throw away the old
> > C++ code and reengineer the original problems using Eiffel. I would bet that
> > this would be the more economical solution. Life is a gamble and sometimes 
> > it is better to cut your losses, even if it hurts at the time.
> 
> As an organizer of the workshop on OO legacy systems at OOPSLA, I welcome
> all useful contributions to the discussion. Reports on the economic aspects
> of re-engineering OO legacy code are particularly interesting. A paper 
> showing, on the basis of actual numbers, that throwing away legacy C++ code 
> and reimplementing a system in Eiffel brings more long-term benefits and is 
> more economical than trying to restructure the C++ application would be an 
> extremely important contribution indeed --- especially if one considers the 
> sheer size of some industrial OO systems, where development effort in the 
> order of 100-200 person-years is not uncommon.
> 

  Your request for statistical information is quite reasonable.

  However, I am not sure that you are going to get a lot of hard
  evidence at this point in history, I would like to be proved wrong.

  In some respects Eiffel is such a major shift from C++ that
  it comes down to judgement on the basis of the QUALITY of the
  philosophies, methods and tools of the Eiffel school compared
  to those of the  C++ school.

  My own observation is that the Eiffel school is such a major paradigm
  shift compared to the C++ school that historical data is not very
  useful in making predictions. The extrapolation from past to future
  has a discontinuity and you have, to some extent, to jump the 
  discontinuity.


  In other words you can not really use statistical inference
  based on the QUANTITY of C++ code in existence to predict the future.

  In any case, any good stock market analyst will advise you never to
  assume that the past will be the future. There are too many 
  unpredictable and hidden variables.

  I am talking about QUALITATIVE judgement based more on 
  the QUALITY of the two competing methodologies.

  Maybe some form of deductive reasoning might help.

  Such as:

 1.  Eiffel is a better designed language from the point of view 
    that it emphasises and facilites QUALITY in software engineering.

 2. Quality is becoming the dominant Economic dimension of software 
    enginering,  particularly as hardware resource performance/price ratios
    grow at exponential rates and staff costs increase or at least don't 
    decrease.

    (Some would argue that Quality has always been the dominant Economic 
    factor)

 3. Therefore Eiffel is a better choice than C++ for the future

  
  Unfortunately I do not have a large QUANTITY of statistical
  evidence to back up my hypotheses above.

  Time will tell if I am right.

  But that is the nature of the future sometimes we have to use our personal
  judgement and the past may not always be the best source of information.

  I am sure you are already aware of numerous cases of this phenomenon,
  popularised by Khun as a 'paradigm' shift in his book on scientific
  revolutions.

  I do have a little statistical information:

  I have heard of cases of people that have redeveloped systems
  that were originally developed in C++ and then reengineered in Eiffel.

  One such project was in France at French Telecom.
  Herbert Divoux ( divoux@issy.cynet.fr) can tell you more details.

  This was a pilot project called "The Margot Marine pilot project"
  which is concerned with Telecom network sytems.

  C++ was used initially for 3 months and then it was abandoned and 
  Eiffel was used instead.

  This was then not really a very old legacy system, but some transition
  would have been required. I assume that they believed that it was better
  to abandon the C++ code and start again with Eiffel.

  I have heard of other cases of C++ being abandoned in favour of Eiffel
  after various periods of time.

  I readily admit that in statistical terms this is mainly hearsay, 
  qualitative data.

  If there is any more hard statistical data I would certainly like to
  see it also.

  So I suggest that anyone that has been involved in such a transition might 
  like to contribute to this thread and explain why this happened and what 
  were the costs and benefits involved in abandoning C++ in favour of Eiffel.

  I have also heard of cases in the very early days of Eiffel where
  people started using Eiffel and abandoned it because the tools
  were not sufficiently  advanced for their needs, or were too slow.
  I do not think that this is the case now. Eiffel tools have advanced in 
  capability and speed considerably over the last few years.
  
> > The term "legacy systems" has come from the frustration of people
> > having to deal with systems that are no longer economic to maintain.
> >   
> > Instead what should be happening is that every high quality component of a 
> > system is a "rich legacy" available for future generations of software 
> > engineers to reuse.
> 
> My experience shows that this is quite difficult, even when software
> developers
> aim at designing and implementing reusable components. The result is that all
> OO libraries at some point or another need to be thoroughly reorganized
> --- thus
> our proposal for a workshop on this problem.
>
  I agree that it is difficult. I also agree that it is a process of
  continuous refinement and can never be complete or perfectly correct.
  
   Reasoning:

   1.   A class library is a classification system.

   2.  It is not possible to build a complete, perfect classification system 
       because this implies complete, perfect knowledge which we appear to 
       lack.
   
    (This is probably just another variation of Godels Theorem)

  It is the very difficulty of the activity of classification of knowledge
  ,which is what we are trying to do, that we need the greatest support 
  from  the language and methods at the human level.
  
  We need to be able to use a language that is as close as possible to 
  our natural language that we use daily and yet sufficiently rigorous to
  facilitate the development of reliable systems. My impression is that
  Eiffel is a much better candidate than C++ for this very difficult
  exercise.

  The building of such classification structures will take many years,
  and require contributions from many people from many branches of human
  knowledge.

  The classification structures of Mathematics are still evolving after
  several thousand years of effort by thousands of mathematicians, and there
  is no end in sight.

  There is no short cut to quality. The advent of the text editor and the 
  word processor have allowed a dramatic acceleration in text produced to
  describe algorithms. There may have been a corresponding decrease in
  deeper thinking at the same time! More may have been less.

  In Eiffel features can be declared as Obsolete. This helps to facilitate
  the continous evolution of the class library. Features can be renamed and 
  redefined in descendants as you might expect.

  I agree class library evolution is a major issue since 
  systems spend most of their life being maintained. The prospect of 
  completely reorganising the entire class library should diminish with
  time. I believe what will happen is what has happened in many 
  classification system throughout history.

  Initially there is a period of ferment and rapid change. Then the 
  higher level , or more fundamental, parts of the structure start
  to stabilise more and more. The lower level, or more detailed, parts will 
  evolve at a faster rate and may continue to evolve indefinitely.

  Occasionally a major hole will be discovered at some level and tools
  need to be able to cope with this significant discovery of new knowledge.

  You can see this behaviour in the classification systems of
  Mathematics, Biology, Chemistry, Physics, Astronomy, Engineering, 
  Economics, Law and a number of other areas that attempt to use formal 
  or semi-formal classification structures. There are periods of stable 
  growth, followed by the occasional major discontinuity, and then a 
  return to stable growth,and so on.   


 
> > The very fact that this meeting is needed at all demonstrates quite
> > clearly that C++ has already failed to solve the  historical problem of
> > "Legacy Systems". I do not believe that C++ will ever solve this problem,
> > in fact I think it will accelerate the problem because I do not think C++
> > has a high enough QUALITY factor to succeed in reusability.
> 
> I would welcome a well-thought out contribution on the extent to which
> features
> of programming languages correlate with the inflexibility of legacy systems,
> or

  Evolution Issues:

  Readability: Eiffel tends to be easier for people to read and understand
               than C++. Therefore easier to maintain and will evolve more
               easily.

  Standards:   The Eiffel vendors have standardising on a single
               Base libary classification structure that will work
               on all vendors implementations that conform to the
               international standards for Eiffel published by
               NICE ( The Non Profit Consortium for Eiffel).

               C++ libraries from different vendors tend to be radically 
               different and incompatible. This does not preclude future
               agreements among C++ vendors but so far they are 
               conspicuously absent, possibly because of the 
               complexity of the language.
  
  Small Syntax: The Eiffel Syntax is small and easy to understand.
                C++ syntax is complex, cryptic and appears to have
                a large number of exceptions to the many rules. This 
                complexity is an impedance to evolution, because
                systems have first to be understood by people before they
                can be changed. The learning curve for new staff to maintain
                old C++ systems is likely to be much longer than for
                Eiffel systems of the same age.

Design by Contract:
                Eiffel implements assertions explicitly as expressions
                of the user specification constraints. That fact that 
                these propositional logic statements are part of the 
                source text BUT not part of the procedural logic
                of the implementation code is a major conceptual
                shift from C++. The assertion handling mechanism
                in Eiffel is operating as a Quality Management System
                outside the procedural logic where the actual work of
                inquiry and changes to the system state are carried out.

                 This dual activity strategy simplifies procedural logic
                 very significantly. It means less procedural code 
                 because assertions define the contract between the client
                 and supplier OUTSIDE the procedural logic. Less code
                 means that less needs to be changed during system evolution.

                 For example: 
                 There is less need for complex case statements 
                 because the assertions already eliminate many cases
                 that no longer need to be evaluated in procedural
                 logic.  More of the decisions are made in the declarative
                 logic of assertions
                  ( the preconditions, postconditions and invariants of the
                    class).      

                 Less procedural code means that systems are less complex
                 to maintain and therefore more economical.

Generic types:
                  Generic types in Eiffel seem to be more effectively 
                  designed into the language structure than templates
                  in C++, which seem to be a more recent bolt-on.
                  Constrained genericity has been available for many
                  years in Eiffel. I don't believe it is available in C++
                  even today. These concepts have been well designed into the
                  Eiffel language from the beginning. 

                 Language structures are like any other structures in some
                 ways they have a number of fundamental concepts on which 
                 the whole system is constructed. If the structure is missing
                 the fundamental concepts from the beginning than bolting
                 on pale imitations onto a limited foundation does not really
                 work very satisfactorily.

------------------------------------------------------------------------------
                 The nature of evolution is that some structures outgrow
                 their time and are abandoned. This process has been
                 going on in computer languages for a few years as it has in 
                 many other systems for millions of years.

                 My impression is that Eiffel will replace C++ until an
                 even better language comes along. Such is the birth and 
                 extinction of languages and all systems.


> how the problems of OO re-engineering relate to the programming language (or
> the
> OOAD method) used to develop the legacy system in the first place.

  A relatively new OOAD methodolgy, which has evolved from the concepts of
  Eiffel is the BON (Business Object Notation) methodolgy. It carries the 
  concept of contracts between classes upwards to the Analysis phase as
  Constraints.

  Eiffel has been used by a number of people as a specification language
  and a PDL even before the more graphical notation of BON was formalised.

  The reason is that by using design by contract you can specify the
  relation between clients and suppliers which together with signatures
  gives a more complete interface specification than is possible with C++,
  quite apart from the fact that the Eiffel text is more likely to be 
  a great deal more readible than the C++ text. All Eiffel vendors 
  supply tools to extract this short form of classes from the source text.

  So the source text contains the specification text which can also 
  automatically checks the implementation code for conformity to the
  specification.  

  But the implementation code can not alter the specification in any way
  because it is propositional logic not implementation logic.

  Putting assert statements in C/C++ code is not the same thing at all, 
  because they are still part of the implementation logic.
  
  I am not aware of any C++ system that can implement design by contract
  at all, let alone in the straight forward way that it is done in 
  Eiffel.

  C++ reminds me of PL/1. This was a language that tried to be all things
  to all people. As you probably know it failed. It was another example 
  of a language that had a complex syntax with many exceptions to the 
  many rules. It was quite widespread on many machines. There were even 
  microprocessor versions (PL/M). I think that most compiler
  vendors have abandoned PL/1.

  So here is an example where QUANTITY, in the sense of being widely
  avialable on many machines, was not sufficient. The PL/1 paradigm
  failed and the system became effectively extinct. The past was not the 
  future.

  The same fate could await C++, Quantity of code may not be sufficient
  to save it from extinction.
  


> Quantitative
> information, actual experience reports and systematic arguments will be
> greatly
> appreciated, hand-waving will not.
> 

  I hope this is of interest.

  If there are any other people who have experience in both the Eiffel school
  and the C++ school I would also like to see the contributions of their 
  experience to this thread.

> Sincerely
> 
> -- 
> Eduardo Casais
> 
> FZI - Forschungszentrum Informatik          e-mail:     casais@fzi.de
> Haid-und-Neu-Strasse 10-14                  tel:        +49 721 9654 602
> D-76131 Karlsruhe                           fax:        +49 721 9654 609


Sincerely

--Des Kenny

