From: martin@Chemeng.Ed.Ac.Uk (Martin Spenceley)
Newsgroups: comp.object
Subject: Re: Is Borland the leader in technology?
Date: 17 Dec 92 14:59:04 GMT
Reply-To: martin@Chemeng.Ed.Ac.Uk
Organization: Edinburgh University Chemical Engineering Department.
Originator: martin@wick

In article CTpm00WD5Ni0uYz@andrew.cmu.edu, jb7m+@andrew.cmu.edu (Jon C. R. Bennett) writes:
>
>henley@eng.auburn.edu (James Paul Henley) writes:
>>In article <Yf9te3C00WBEMfeqUe@andrew.cmu.edu> "Jon C. R. Bennett" <jb7m+@andr
>> ew.cmu.edu> writes:
>> >
>> Jon, the hard facts are this:  Chemical Engineers write Chemical Engineering
>> Software.  That is a fact.  The problem is that they don't do it well, and
>> they do it with outdated methods and inadequate tools.
>
>corect me if im wrong, but did i not say just that?
>
>> See my other post on this subject for a more detailed explanation of the 
>> problem.
>
>in your other post you give an example of the Tennesse Eastman plant where
>you say that the only programmers that are not Chem E's are systems
>analysts, must systems analysts that ive met would be proud to tell you
>that they dont write code, please dont degrade programmers by saying that
>systems analysts are programmers...... the problem with the plant in
>question and with the process that you describe is that it starts with
>
>>    Chemical Engineer writes some FORTRAN
>>    Chemical Engineer give FORTRAN to programmer
>
>when it should start with 
>
>Chemical Engineer gives brief problem statment to the programer, and they
>trade it back and forth until it is detailed enough for the programmer to
>code from, that your process has this loop
>
>>   REPEAT
>>      Programmer writes some C and links with Chemical Engineer's FORTRAN
>>      Programmer takes finished program to Chemical Engineer, and says:
>>       "Is this what you had in mind?"
>>      Chemical Engineer says:
>>       "No, that is not at all what I wanted."
>>   UNTIL time runs out, at which point Chemical Engineer lives with what
>>      he has at that point 
>
>tells me that you dont have a programing problem, you have a
>communications problem, and until you address the communications problem,
>you will continue to get poorly done programs as output.
>
>jon

I think this stereotype is becoming less frequent. I have studied ChemEng 
(B.Eng) and CS (M.Sc), I write programs in C++ and are developing visualisation and
user-interface techniques applied to process (chemical) engineering.

When I worked in a very large chemical company developing process engineering
programs for chemical engineers, there was a trend of moving away from
FORTRAN (when writing new programs) and moving to C (and now C++). Of
course 95%+ of all programs in chemical engineering are written in
FORTRAN, this is because of a historical thing. (Mind you some
engineers/CS mathematitions working in ChemE still prefer FORTRAN
(especially when matricies are involved).

Where I work now we have 30%CS and 70% ChemE researchers doing ChemE
related projects.  When CS people get involved there is a tendancy for
them to 'over' generalise Chemical Engineering problems. The ChemE
people then tend to either follow this generalisation (possibly becuase of 
their poor knowledge of CS) or try to resist this generalisation in 
order to be able provide a ChemE related proof to the concepts that are 
being generalised.

An example of this happened when we tried to define process engineering
objects for our application integration/communication system. The CS
people regarded an object as a collection of loosly defined attributes
related to process objects.

As it is almost impossible to define all the data that is required to
define a process object e.g a stream, this arguement sounds quite acceptable.
Only when one tries to justify the actual attributes describing what a
stream really is then it was neccessary to tighten up on the CS's
initial generalisation.

Having a purely CS or ChemE based group doing Chemical Engineering
software will lead to poor software (either in its understanding of ChemE 
problems or in its inefficent implementation into code). A mix of CS and 
ChemE tend to provide a group that are able to support each others weaker 
areas. Although sometimes friction can be caused by, say a ChemE not wanting 
to know about some pure unapplicable CS theory (or vise-versa), you do get 
a more dynamic group.

I think it is becoming less frequent for Chemical Engineers to write
their own programs.  Many engineers cannot get any support from CS
people to write their programs for them (I know of a company having 8
full time programmers supporting over 100 out of date FORTRAN IV and 77
programs for several hundred engineers!). All to often these engineers
resort to using a spreadsheets to develop their code on. This is a
nightmare situation for anyone trying to maintain or upgrade these
design routines.  What is needed for these engineers is either a lot
more investment in hardware and software resources (I was in a
situation where engineers were being bought 286 PC's while the
secretaries recieved 386 PC's!). Also, an object-oriented system to
provide the ease of use of a spreadsheet and the ability to develop a
design based on objects with its methods being easily extended would be
invaluable to all engineering disciplines.


Martin.
-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    Martin W. Spenceley                        Telephone 031 650 5891         
    Department of Chemical Engineering         Email M.W.Spenceley@uk.ac.ed   
    Edinburgh University                       or    martin@uk.ac.ed.chemeng