Conference turris::languages

283.0. "Choosing Implementation Languages for DEC Internal" by GRANE::HEINTZE () Sun Aug 26 1990 20:37

    I started a topic (256 in the C++ conference) that is more appropriate for
    this conference.  I'm starting the topic again in this conference to
    solicit comments from individuals who may not read the C++ conference.

    Fault Management CSSE has created its own software developement group
    in Colorado Springs and I have been assigned the task of choosing a
    Design/Analysis/Programming Paradigm(s) for our group.

    Consequently I am soliciting comments on the criterea we should use for
    selecting Design/Analysis/Programming Paradigm(s).

    From the C++ conference I was surprised to learn that LISP and TRELLIS
    were options since they are supported on multiple platforms and can be
    compiled such that the user does not need a LISP (or, I assume,
    TRELLIS) liscence.

    Our management is concerned about portability.  We are concerned about
    maintainability.

    My personal bias on Programming languages is toward high level
    languages when appropriate (which is 99% of the time).  I think about
    Object oriented paradigms a lot so I guess they are a bias of mine
    also.  I was pleased with using ADA for our last project and I use C++
    a lot for midnight projects.
    
    I think my bias towards OO can be justified because of the nature of
    the project.  See if you agree after reading the description of the
    project (below).

    I don't consider C a high level language because you cannot use the
    subscript notation ([]) inside a routine that receives a two
    dimensional array unless the dimensions on the array are compile time
    constants.

    I don't consider BLISS a high level language because it requires too
    much attention to dereference operators ('.').

    In light of the notion that DEC won't have a C++ VMS compiler until next
    January (see note 217.3 of the C++ conference - I believe Q3FY91
    tranlates to Jan-Mar 1991)  What options are there available for
    Developing products in high level programming languages?

    The application is going to be the successor to VAXsimPLUS which is
    written in BLISS.  VAXsimPLUS does things like look at error logs  to
    predict disk failures and tries to copy the contents (via the
    shaddowing utility) to another disk before the disk fails.  VAXsimPLUS
    is not available for customers to purchase.  Instead, you get it with a
    Field service contract.  When FS installs it on the customer's machine,
    they (the system managers) inevitably ask what it is going to cost them
    (in terms of performance).  We are proud to say that that the current
    implementation does not impact them greatly.
    
    Do you think Trellis and LISP are candidates for an application like
    this?    None of the goals for the successor have been formalized, but
    some of the things on our mind are:  (1) maintainability,  (2)
    portability, (3) access to things like callable mail, system services
    and routines for graphic displays (4) security (ie, the prediction
    algorithms are highly propietary and compiled BLISS serves this goal
    well) (5) implementation of AI paradigms (expert systems or nerual
    network methods) to predict disk failures.

    The tells that this new entity called MCC will be portable substitute
    for VMS system services so we will need to call this a lot.  I really
    doubt it will be a complete substitute however.
    
    The current implementation uses compiled BLISS if statements to predict
    failures.  This seems to work reasonalby well but its not very
    maintainable and adding new devices is costly.  I'm not sure just how
    much we need to be concerned about AI methods in light of our
    performance and security concerns. (It would probably be best to
    discuss this issue further in another conference - any suggestions?) 
    Our management likes to say that the current product is AI and we
    always have to currect them.  Then they say that the successor will
    have to use AI.  I'm not sure I understand their logic.  I suspect they
    like to use buzzwords.
    
    All of the above leads me to believe we need a language that is
    compiled like ADA or C++.  However, an expert system would be
    a lot easier to implement in a language like LISP or - better yet -
    PROLOG.  How is Trellis in this capacity?
    
    Whew!  That is a lot to think about!  I look forward to your reply!
    Please tell me what langauges you recommend and why.
    
                             Sieg

IMHO you have to solve another problem: your concern is maintainability and
your management thinks that portability is important. What do they mean by
portability in the case of VAXsim+ ? Does it have to run on our RISC-line,
or do they just mean "any VAX"?

   Hi, Sieg.  I know where your project stands, John Wilmes was out talking
to me a few weeks ago...

   Anyways, my estimation is that your project is not yet ready to pick
an implementation language.  You need to design the system first, and then
pick the appropriate language for the appropriate pieces.  This was a lot
easier when VMS was the only OS and everyone except C could easily follow
the calling standard.  In a more-or-less "open" world, there's less freedom.

   Seriously, design your application first, and then decide what language
makes the most sense.  There are plenty of languages out there, and most
of them have their relative benefits and drawbacks.  We don't need a "what's
your favorite language" war here in this conference again, I've seen and
participated in enough of them myself.

   You should pick your language based on:

	- applicability to the problem/solution
	- availability of compilers on interesting platforms
	- experience/familliarity on the part of the developers
	  (i.e. Trellis might be the best language, but if nobody knows it
	   well, it might not make sense.)
	- Quality of generated code (i.e. if you're planning on using a
	  BASIC compiler VMS, keep in mind that its code is typically not
	  as good as say... VAX Pascal.)

   I'm going to supress all the desires to go on language tirades again and
just leave it at that... (now THAT's will-power!)

					-Mike Grier