Conference noted::hackers_v1

I generally prefer C myself since I feel it's most flexible.  This is in spite
of the fact that C's character string processing is incompatible with the
rest of the VMS universe (i.e. the RTL, etc) and the default file options
s*ck.  Both these faults can be traced to its UNIX origins.

-Mike

    "C" for yourself that "C" is the language of choice!
    
    If you want to keep your investment in your application I would
    choice "C".  Also, you may not be thinking about porting it to
    other OS's, but you should keep it in mind.  Remember, VMS
    is NOT DEC's only OS anymore (thank goodness).
    
    Though I have not used it yet, C++ does seem promiseing.

    If you want real portability and also access to most modern ideas
    in language design, use Ada.  If you want a semi-portable mid-1970's
    language that doesn't have nested routines, strong-type checking,
    reasonable support for composite type, etc., use "C".  If you want
    to use an attempt to turn such a primitive language into a modern
    one use C++.
    
    /Bevin

    Many thanks for the replies!  I also prefer C, although Pascal is my 
    "pet" language.
    
    There have been several statements here that most systems are still
    being built in Fortran then any other language, and that Fortran
    should be used.  I find this rather hard to believe.
    
    Any views?
    
    Regards,
    Denis
                                                                     

    Up until fairly recently, I took language calls here at the Customer
    Support Center in Colorado Springs.  The languages that we took
    the most calls on were
    
    	1) Fortran
    	2) Cobol
    	3) Basic

    I saw a lot of new code development in all three.  Fortran is still
    being used for scientific applications, Cobol for financial
    applications and Basic for most anything (it's typically the first
    language that people learn).
    
    The award for the largest increase in call volume went to C.  When
    I first started supporting C, the call volume was a trickle.  I
    am no longer in that group, but the call volume in C is getting
    to be quite respectable.
    
    						Dave()

	I've been writing VMS applications in C for about 4 years and
	am  quite  pleased with VAX-C.  I agree with the earlier note
	that passing string descriptors to RTL routines is a bit of a
	pain, but it's something I've gotten used to.

	I'm  in  the process of cooking up less hostile interfaces to
	the  various  RTL  routines I use, enabling me to simply pass
	the address of a string instead of a descriptor.

	Someone  in  our  group  recently  threw  a similiar question
	around and I believe they went with C (over Pascal).

	/ravi

The current philosophy (at least what I've been exposed to) is that the latest
undergraduate teaching language is MODULA 2 (replacing PASCAL); then the more
s/w engineering oriented usually transition to Ada.  Hopefully more dataflow and
simulation languages come about -- I think VHDL(VHSIC H/W Description Language),
which is Ada-like, may become popular when/if the IEEE standardization becomes
complete. 

Personally, I think all design level chores (routine interface specifications &
algorithms or pseudo-code) should be done with either Ada (my choice) or MODULA
2. Then, if that language is not appropriate for implementation, code it in the
target language (even if that means (gag) "C"). 

	regards,

		\rikki

    RE: .4
    
    I'm currently in residence at a site whose application language
    is exclusively FORTRAN.  Having just done a major conversion FROM
    a foreign computer environment, I can attest that FORTRAN is somewhat
    portable.
    
    However, there doesn't seem to be much else to commend FORTRAN for
    these applications (primarily database maintenance tasks).  The former
    "portability" of the code is now gone, as DEC extensions, system
    services, RMS calls, FMS calls, et. al. have been enthusiastically
    implemented.  Strict adhereance to "portability" goals would have
    severely restricted our functionality.
    
    In addition, the need for accessing RMS structures (particularly
    XAB's) made us really desire the ability to dynamically allocate
    structures, and to traverse linked lists using recursive techniques.
    Although we succeeded in doing so in FORTRAN, I would compare the
    process to so many of our favorite DENTAL SURGICAL procedures.
    
    Using Rdb, and the DML pre-processor, you may not have these problems.
    
    FORTRAN complies with the DIGITAL calling standard, supports every
    VMS data type I can think of, and provides an environment where
    most any reasonable operation is "possible" (caveat above).
    
    Given my choice of the three, I would probably opt for PASCAL, 
    [please, hold the rotten tomatoes until I get behind my shield].
    VAX PASCAL's nice homogenous (with VMS, RDB Calls, etc.) support of 
    string manipulation is very useful, while in "C" you must handle
    the required string descriptors and conversions manually.  Yes,
    defining external linkages is a pain in PASCAL, but the system services
    are all done for you (STARLET.PEN), and I believe there is a PASCAL
    flavor of the DML pre-processor to rescue the Rdb end.
    
    PASCAL is, by general concensus, not as portable as C, but with Rdb\VMS 
    as the main DB server, is portability to foreign systems a realistic goal?
    
    If strong coding standards are absent, and many programmers of uneven
    experience levels are to be coding, C permits greater "undisciplined-ness"
    which could lead to maintenance problems.  Many will take exception
    to this (WE certainly all intend to write clear, readable, well-
    structured code regardless of language used), but my opinion is that 
    any latitude available might be used by any programmer in any
    circumstances, and C certainly can be used to write code in a rich variety
    of undecipherable ways that PASCAL generally won't tolerate.  Strength
    or weakness?  Well, there is a certain amount of "built-in coding
    standard" in PASCAL, which I think is desirable.  If you choose
    C, give thought to rigorously defining your own.
    
    Programming languages to programmers become like religions or political
    party affiliations to other folks.  The long and short of reality
    is that it would be difficult to convince anyone who "religiously"
    espouses ADA, C, FORTRAN, PASCAL, or even COBOL (*ugh*), or BASIC
    (double *ugh*) that another way is "better".  My experience is that
    any of the languages can be made to work one way or another, so it
    may be most practical to go with a majority of your coders (Happy
    = Productive?), or alternatively, maybe a compromise of several VAX
    languages would be a good answer?
    
    Best of luck to you in figuring out how to handle the decision!
    
    					-- Brian
    
    
    
    

    	Write each piece in the language most suited...
    
    	I'm currently working on a product containing (in decreasing
    order):
    
    		BASIC 	(majority)
    		PASCAL  (some of the database access)
    	   	Macro	(variable argument list routines and some
    			 system-level/speed critical stuff)
    		C	(one whole interface piece)
    		FORTRAN (some old routines I had hanging around, plus
    			 some "ease of use"routines)
    
    
    	PASCAL's varying strings are a bitch to use with any other
    language.  Our data server interface is in C to support variable
    length arg lists and build self-describing data packets.  Our data
    server is in BASIC with a smattering of kernal mode MACRO code in the
    inter-process communication modules.  Most of the user interface
    is in BASIC.
    
    	At least one small FORTRAN module got put in because BASIC can't
    handle a class Z descriptor returned from the callable librarian
    while FORTRAN could care less.
    
    	It's a bit of a support nightmare, but it keeps me on my toes...
    
    						--Doug

    I tend to pick the language that best suit's the problem, I like
    Ada for large a project that is bound to need lots of maintenance, 
    or be the type of project that keeps building on itself. But I often
    find that I get caught up in making it something my Software
    Engineering Professor would like, and not make it very efficient.
    
    I like pascal if I want to get something done quickly, and have
    a good chance at maintaining it later.
    
    I use 'C' and Basic only for the machines/OS's that are written
    for/by them, like Un*X, IBM-pc's, and I cant get anywhere without
    them. I try hard to like 'C', but the version's I've used are just
    too frustrating,  error-prone, and tend to be WRITE-ONLY.

    
    I think Modula-2 will be the answer. BTW, does anyone know anything
    about Lilth (sp?) I think it is a machine/OS built around Modula-2,
    similiar to UN*X / 'C'

    Re: .9
    
    	I seem to recall having passed PASCAL varying strings to MACRO
    and FORTRAN, and don't remember having any serious problems.  I'd
    be interested in hearing what you've run into...
    
    Re: .8
    
        One additional caveat to using PASCAL that I ran into way back
    when:  You had to describe key fields in indexed files using an
    attribute imbedded in the record type declaration.  Since the CDD
    interface builds record type definitions, and since my CDD record
    definitions didn't have any key info (I was talking to DTR at the
    time), I couldn't use record structures from the CDD to talk directly
    to indexed RMS files.  Once again, maybe not important if your DB
    is going to be handled by Rdb/VMS, but it's something to think about.
    (PS:  anyone know if that's been fixed or worked around?)
    
    				Regards, Brian
    

    I like C a lot. 
    
    However, the project I just got finished with (a DBMS shop-floor
    control system) was exclusively written in FORTRAN. Now, FORTRAN
    is okay, but it can be a real pain when you're trying to modularize.
    
    Pascal, Ada and Modula-2 should all be put in the great bit-bucket
    in the sky. :-)  "You vill program ze vay Nicolas Virth zayz, und
    chu vill enchoy it!" I know what I'm doing; if I tell the compiler
    that a string is a binary integer, then it had better _do_ it, and
    not give me any grief about type-mismatches.
    
    COBOL is way, way, way too verbose. "ADD STUFF_1 TO STUFF_2 GIVING
    TOTAL" is just too annoying.
    
    BASIC isn't bad, but the word "GOTO" should be stricken from it...
    				- HBM

    I'm not sure how "TECHNICALLY" oriented you want the language to
    be .. but in Commercial applications these days you should be using
    either RALLY or the COBOL GENERATOR.  Both significantly reduce
    the development time using traditional hand-coding.
    
    
    The COBOL GENERATOR gives you all the flexibility of a 3GL and because
    it's based on the use of graphics and icons you don't have to key
    all those "verbose" move statements.  And two big gains with it
    are automated up-to-date documentation and reduced maintenance
    costs of your application.
    
    As you may have guessed, I have just been involved in presenting
    two one-day seminars on Digitals 4GL approach to application
    development and have even begun to believe it!

    Missing from all of the replies is (I have found) the most important
    selection criteria for a customers development project:
    
    	Pre-existing familiarity and bias.
    
    Nothing goes farther to enhance a projects final product and decrease
    the risk associated with it than having a language that most of
    the developers enjoy and know WELL.  Someone who has 5+ years of
    experience with a language can be many times more productive in
    it, can an enormous asset to less experienced developers, and can
    always seem to dredge up a language 'trick'(feature, peculiarity,
    whatever...) to get a project out of an unforeseen jam.
    
    I have my own personal preferences also (VAX BASIC).  But the VMS
    enviornment and it languages have been developed so that ALL of
    them are suitable for most programming projects.  We should take
    advantage of that fact by accomodating customers strengths and desires
    rather than trying to railroad them into our own personal way of
    thinking and programming.
    
    --  Barry

    	I have used many peculiar combinations of languages (Bliss main
    programme with Cobol subroutine, for example), and for a short project
    familiarity with a language must be one of the most important
    considerations.
    
    	For anything more serious you should look at what languages have
    the features you need after you have done a general design.
    
    	If you have to call LIB$SPANC to manage strings, LIB$GET_VM to
    manage your virtual address space or LIB$EXTZV to do bit diddling, then
    your code becomes less readable, and you prevent many chances of
    compiler optimisation compared with a language that handles these
    things internally.
    
    	I tend to use PL/1 for most serious things. It is strongly typed
    enough that it picks up must of my typing errors, and a few others as
    well, but if I really want to write nasty code it still has GOTO and
    UNSPEC.

    I have to concur with Bevin that you should probably be using Ada. It
    has marvelous development tools. 
    
    	Jon

    What about, dare I say it? DSM (Digital Standard Mumps)?
    DSM has some nice features that I have not seen in other
    languages.

         1.  Sparse arrays, if you have an array that is not
             completely populated, DSM will only allocate space
             for the part of the array that has data.

         2.  Having alpha-numeric indexes.  
             ie: instead of data(1),data(2),data(3), etc
                 you can have data("x"),data("y"),data("z")

    DSM tends to be cryptic and one can really get lost in the code.
    But if routines are written with care it is not bad.
    
    My 2 cents,  Paul
    

>    1.  Sparse arrays, if you have an array that is not
>        completely populated, DSM will only allocate space
>        for the part of the array that has data.
    
    	Same as VAX BASIC for DYNAMIC STRING arrays.

    	Hein.
    

    Well, when I need a quick thingie, I use FORTRAN.  However, for
    just about everything else, I use BLISS-32 or MACRO-32.  I haven't
    made a `typing' mistake (as in data-typing, not finger-fumbling)
    in years, so the lack of strong data-typing bothers me not at all.
    
    #ken	:-)}

    First, I should say I am still trying to wean myself from MACRO-32,
    since I have been coding primarily at that level for some time
    (and really enjoy it!).

    So, I guess it's natural that my favorite would be BLISS-32.
    Bliss is about the closest you can get to assembler, with its
    ability to JSB, direct access to VAX instructions, etc.  And,
    used properly (which applies to _any_ language), it is very
    structured and easy to follow.  Besides seeing "dots" before
    your eyes, my only other complaint is that it seems *very*
    difficult to learn completely.  I have done quite a bit of
    coding in Bliss and I still don't feel anywhere near being an
    "expert."

    Right now I'm learning C, and I remain a little disappointed.
    Portability would be a great benefit, but the type of programming
    I do tends to depend heavily on system services, RTL, and built-
    in "DECisms" of the language that tend to make life easier.  So
    my programs don't end up anywhere near portable.  The syntax for
    some of the C constructs, in my opinion, is terrible.  And how
    can high-level language programs look so cryptic as C programs
    do sometimes?  A book I was reading on C seemed to be patting
    itself on the back as to how programs could be made "simpler"
    and it occurred to me that they were probably merely _syntactically_
    simpler and, say, a Fortran compiler could generate the same (or
    even better) code although the source might look more verbose.
    But, I'm warming up to C.  It's relatively easy to learn and
    program in, and its standard RTL is a plus.

    PASCAL was my language of choice at school but I haven't used it
    since.  I still love its "structured-ness."

    As much as I hated COBOL at school, VAX COBOL isn't bad at all.
    If you adopt some standard practices that circumvent some of the
    lousier aspects of the language, you can write nice COBOL code.
    Sure, it will be verbose, but that's not necessarily bad.  A
    big weakness is the inability to receive arguments by value or
    descriptor.  Lots of data types and easy conversion amongst
    them is a plus.

    A similar thing can be said for FORTRAN.  Adopt a few practices
    of your own (like minimizing GOTO's), use some of the -77 features
    and "DECisms", and you can write nice, concise, readable programs.
    And the compiler is a champ.

    I haven't used BASIC since high school.  I want to say that BASIC
    programmers should graduate to something else, but I won't.  I'm
    sure if I looked into it I'd find a rich set of DECisms in VAX
    BASIC that make it in the same league as Fortran.

    It's fun comparing programming languages!!