Conference turris::languages

	Having just completed reading the entirety of note #42, I realize
    that I am not the first person to ponder upon the prospects of a new
    DEC standard programming language.  However, I was hoping that this
    note would extend beyond a simple "yes" or "no" response to the question
    and regenerate an up-to-date disscussion of the latest pro's and con's
    of both having a DEC standardized language as well as what it should be.

	Gee, since I seem to be the only one around who reads this notesfile
    anymore, I suppose I could probably make some pretty rash proposals here
    and nobody would object to them.  Hmmmm...what say we go ahead with the
    VAXUL idea?

							-Dav0

	Gee Dav0, I think the VAXUL proposal is a great idea!  Now, if we
    only had a DEC standardized programming language to write it in...

						-VIP (Very Important Phony)

	Seriously folks, I'm going to take a default dive into VAX Pascal
    using BLISS for any low-level drivers that might be needed, unless,
    of course, someone can convince me otherwise.

	My reasons:

    1.	Well, I'm lazy.  I already know Pascal (among other asundry languages),
    and I also have plenty of somewhat recent (within this century) BLISS
    documentation on hand to learn that as well.

    2.	I keep hearing rumors that Pascal is going to be adopted as the
    corporate standard programming language.  Any news on this trend?

    3.	While I have since purchased the official ADA reference manual, I'm
    not too thrilled about the ramp-up process, especially if it isn't going
    to be adopted as the standard language here at DEC.  Besides, I don't
    plan on quitting DEC to go off and write any Star Wars junk (unless the
    DOD makes me an offer I can't refuse - i.e. if they draft me).

    4.	C sounded interesting at first, but after some investigation, it
    seems to fall short of what I would consider to be a wise choice for
    DECies (unless we hope to eventually merge with AT&T).

    5.	I find most of the other available languages either too kludgey,
    or antiquated in appearances, and thus somewhat of a turn-off.  PL-I
    for example may offer alot of flexibility, but so does machine-code.

	There, now that I have managed to piss-off everyone by denigrating
    there favorite language, tell me where I should go/what I should use,
    as well as expound on what DEC's standard programming language is/should be.

							-Dav0

re: P*****,

	Sounds like we've either wandered into a proprietary subject, or
    somebody just doesn't like it.  In either case, it sounds like I'm on
    the right track by sticking to Pascal for the time being.

	Interesting that you mentioned Alan, that I could probably access
    all of the system services I will need from any VAX/VMS language, the
    question is: will this be adequate for print symbiont coding?

	I was under the impression that I needed a low, or at least
    medium-level language (such as C or BLISS) to access hardware memory
    addresses and to optimize where neccessary.  It never occured to me
    maybe this wouldn't be neccessary.

	Besides, I also hear that a new ISO Pascal standard is going to
    be coming out within the year which will allow some of the flexibility
    neccessary for this sort of low-level access.  Any confirmations on
    this are welcome, I don't want to spread too many undocumented rumors.

						-Davo

    The ANSI working draft of the Extended Pascal standard is about to 
    go out for public comment, after which it will probably be approved
    as a new standard.

    The major extensions currently are :
    
    	o separate compilation - importing and exporting definitions
    		between modules, like Environment files only different.
    
    	o schemas - flexible/dynamic types, like conformant array
   		parameters, which can be used just about anywhere a 
    		regular type may appear.
    
    	o structured constants - constants may now take the form of
    		a user defined type, like an array or record.  Great 
    		for setting up default values for your favorite FAB 
    		block.
    
    	o value initialization - variables may be initialized before
    		execution of the program.  VAX Pascal already has 
    		the VALUE declaration section and value initializors
    
    There are also a bunch of other little goodies, like extended numbers
    which allow you to specify a number in any base from 2 to 36. 
    
    The new standard allows a lot more flexibility in programming, but
    it does not specifically help the low-level programmer.  Extended
    Pascal will not help you get at registers like Bliss does. 

    
			Barbara b.

        To the best of my knowledge (and I know Pascal developers
        personally... one's my wife), there hasn't even been any
        idle talk, much less serious planning, to try to push Pascal
        as a Bliss replacement for systems implementation.  As Barbara
        said, Pascal simply isn't up to that level of control.
        
        While there was a period where Digital was pushing Bliss
        very hard, that seems to have slacked off years ago.  It
        is perfectly acceptable to write your code in whichever language
        is most appropriate.  If you really need register and bit
        level diddling, then I'd suggest Bliss.  While it's possible
        to use C for some of that stuff, it's not as good at it as
        Bliss, and has some architectural problems getting along
        with VMS (although if you avoid the C library routines, you
        avoid most of that sort of problems).
        
        If you *don't* need that level of control, then Pascal or
        Ada are good possibilities.  Both have some difficulties
        with multiple-language programming, but provide mechanisms
        to (usually) work around the problems.
        
        Evaluate the options and make an engineering decision.  Use
        what's convenient and effective for the job at hand.  
        
        	/dave

The question of what language(s) you should use to develop your next
project is different from the question of which language(s) you should
learn to maximize your salary and job satisfaction over the next decade.

To answer the former, I suppose a vague guideline might be to use the
highest-level language you can find which has suitable support and allows
you to achieve your other project goals like reliability, maintainability,
evolvability and performance.  A pair of associated truisms might be that:

1.  Almost any VMS compiler generates code with adequate runtime performance.

2.  Almost any VMS compiler has sufficient access to underlying machine
features support almost any application.  Perhaps to the degree that
if you can't structure your design in the language, you may be doing
something wrong.  Hairy kernal-mode stuff is probably the exception.


To answer the latter, you will probably be better off over the long term
fostering an ability to quickly acquire basic ability in a new language,
rather than becoming a narrow specialist in one particular language. 
And anyhow, if someone were developing the successor to Bliss, the average
software engineer in Digital wouldn't need to know about it until after
it was designed and implemented.
	     			/AHM

re: .12,

	Boy, this note sure looks strangely familiar to the (now deleted)
    note #.4, oh well, gotta keep those secrets from falling into the hands
    of DEC employees.  I'll ask my wife if she's heard of P*****, she works
    at DG and always hears all the the latest DEC news before us "average"
    DEC software engineers ever do.  Just kidding.

    	Anyway, I suppose mail would be the safest approach for finding
    out about P*****.  In the meantime, I guess I can put the rumor of Pascal
    replacing BLISS on the back-burner (at least until I here some real
    evidence of this happening).  While it may or may not be a long term
    goal to push Pascal as the new corporate programming language standard,
    I think the issue of whether the new Pascal features will provide the
    same sort of low-level bit diddling and speed optimization as BLISS is
    clearly "NO".  But these are two different issues.

	The issue of whether Pascal will be adopted by the corporation as
    the new standard programming language for DECies should be the topic
    of discussion here (seeing as that's what I named the title).  The fact
    that I also asked about the new features of Pascal being somehow equivalent
    to that of BLISS relates to, but does not supersede this discussion.  It
    is not hard to convince me of the fact that Pascal will probably never
    offer this sort of low-level functionality.  However, it is hard to convince
    me that I shouldn't be concerned about what the future corporate plans
    are going to be regarding company adopted programming languages such as
    BLISS is/was - remember, I've been burnt before (once burnt, twice
    learnt).

	The question remains however, can a 3rd generation language program
    (VAX Pascal), through the use of RTL and system calls, access enough of
    the low-level features neccessary to program in it entirely (VAX Pascal),
    or would it also need to plan on the incorporation of various external
    procedures (written in your favorite bit-twiddle code - BLISS?).

	Do you see what I am getting at?  If I am going to be bit-twiddling
    in BLISS, then why not write the everything in BLISS and forget Pascal
    ever existed?  Are the advantages of using a higher level language (ADA
    Pascal, etc.) enough of a pay-off to use both a high-level and a low-level
    language?  Or how about a high,medium, and low level language sprinkled
    with a bit of machine code for extra mileage?

	While there are two separate issues here (corporate strategy for DEC
    standard programming language, and personal strategy for optimum software),
    I see them as very much interelated.  I am all set to venture off and learn
    BLISS, but I don't think I can handle the possibility that BLISS may up
    and die on me several months down the road (replaced by language X).

	It seems to me that there is a very compelling argument here to avoid
    the whole problem (lack of low-level access from Pascal or ADA as well as
    possible extinction of BLISS or any other DEC-only language) by simply
    using C, PL-I (arrgh), or any other language which does seem to offer
    this feature.  The problem with using C (as I see it) is the fact that it
    is mainly an AT&T language, and the problem with using PL-I (as I see it)
    is the fact that it is mainly an IBM language.  So, what is the DEC
    position on these issues?  Are we selling out or what?

	I'm personally looking for some guidelines so that I can plan my
    career in a way which benefits both my own sense of achievement, as well
    as that of the corporation as a whole.  In this sense, I am using my
    current situation as a typical DEC software engineer's dilemma (John Q.
    Progammer) to try and help decide what the corporate standard should be.

							-Davo

Re .9:

(A digressive question of history and taste).

Did the VALUE declaration section originate at Digital (say, within
Vax Pascal V1, or something for the PDP-11), or was it imported from outside?

Unless it is in widespread use outside of our customer base, I wouldn't
lobby for putting VALUE declarations into a Pascal standard that also has
"value initializers" on VAR declarations.

Sorry to second guess you, but I think you see what I am driving at.
				/AHM/THX

Here are the best guidelines I can figure:

Size:  Small -- use C or BASIC (easiest to hack in)
       Medium -- use most anything.
       Moderately Large -- use Modula or Ada.
       Really Large -- use Ada.

Portability:  Important -- Use C or Ada, depending on size.
	      Unimportant --  Use anything.

Application-Type:	Business -- BASIC, PASCAL, COBOL, PL/1, Ada
			Sci/Eng  -- FORTRAN, Ada, Modula
			Real-time -- Bliss or MACRO for critical parts

In general, use the highest-level language available for your target machine
that lets you get your job done and fits on the development engine. The idea
here is to let the compiler write as much of your object code for you as
possible.

I like Ada because it is rich enough to adequately support most of the range
from scientific to business and all but the hottest bits (count them 
microseconds!) of real-time without your entire program being built of 
implementation-specific extensions.  

What language will DEC be using?  One TR report I saw recommended Modula,
so I would expect that whatever is chosen will be chosen for strong data
typing (very important for large applications).  This suggests Modula, Ada,
C++, or suchlike.  (I very much doubt we'd see something too close to 
Smalltalk or CLU.)  Or maybe someone will roll their own.

From the standpoint of your career, there's no need to sweat over what
language to use. With the exception of C and BLISS, learning a new language
well enough to write good code in it once you know three or four others is a
matter of a month, if you're puristic and aggressive. Learning a new
language well enough to generally know the best way to code something
generally takes six months to a year. Once you are actively using several
languages, you can generally switch among them like shoes. :-)  C and BLISS
provide less support than many other languages, so you have to learn more
about the underlying system; thus, they take longer and they take more 
commitment.

					Just an opinion,

					    Ralph

re: .15,

	Thanks for the guidelines Ralph, I suppose by the time I learn
    all the languages (shoes) that I'll need to know for this job, I'll
    begin to seem like Emelda Marcos! ;^)

	I find it interesting that you only made mention of Pascal once,
    and it was for Business Applications programming!  This is hardly the
    sort of ranking I would have expected for an emerging corporate standard!
    I guess maybe if this rumor does turn out to be true, then it's sure
    going to surprise a few people.

	I'm also somewhat interested that neither Lisp nor OPS/5 were men-
    tioned in your breakdown, is this due to any problems you forsee in using
    either of the rule-based programming languages for general purpose pro-
    gramming, or was AI not included in this guideline as it might not be
    considered here as a "typical" programmer's tool?

							-Davo

        Why do you keep insisting that Pascal is supposed to be an
        "emerging corporate standard"?  If you believe every rumor
        you hear, you must be a very confused person.
        
        But don't worry... the truth may prove to be equally confusing.
        
        	/dave

> Once you are actively using several languages, you can generally switch
> among them like shoes.

But I keep putting them on the wrong feet!  Seriously, though, I agree with the
statement.  My most common mistake while rapidly switching between languages is
that I tend to use the wrong comment delimiters.  The code is fine, but MACRO
gets confused when it ORs a comment onto the last operand. 

-cw

    re .14  
    
    Mea culpa.  Extended Pascal proposes a VALUE declaration section
    and does not allow initializers on VARIABLE declarations.
    
    The new constant expressions look like VAX Pascal's current value
    initializers, which is probably what made me think of them while
    writing note .9 (that, and my eyes don't focus too well at 7 AM
    :-)
    
    			Bb

Re .19:

Actually, I don't follow the Pascal standard.  I wasn't trying to catch
you on a technicality.  Rather, I was surprised that the language would
have both a "good" and "bad" method of initializing variables.  Imagine
my surprise to read that it will only have the "bad" method.

Anyhow, thanks for the clarification.
				/AHM/THX

The corporate policy is that software must be written in a higher-level
language (as opposed to assembler) unless there is a good reason not to.
The policy does not dictate any particular higher-level language, but it
recommends using BLISS.

VMS Development has more strict rules concerning implementation language for
VMS bundled components.  VMS currently has pieces written in MACRO, BLISS,
PL/I, FORTRAN, and C.  All other languages are expressly prohibited.  For
future development, BLISS and MACRO are recommended.

It is absolutely false that Pascal is under consideration for becoming a
replacement recommended HLL in place of BLISS.

So go ahead and do your product using Pascal.  It is sanctioned by corporate
standards.  The fact that you know it well and are comfortable programming in
it is a completely valid engineering justification for using it.

--PSW

	Thanks Paul, I was beginning to wonder.  Anyway, now I won't feel
    so hesitant to go ahead and learn BLISS as well (seeing as how it's not
    going away anytime soon).

	This would then lead me to my other question: would it be wiser to
    use a high level language (such as Pascal) along with external procedures
    written in a medium-level language (such as BLISS) for certain critical
    portions, or would it be "better" to try to use one language for the
    entire program?

	If the answer is that one programming language would be the best
    approach, then I would think it would have to be a toss-up between
    C and BLISS for the sort of overall functionality one would need.  
    
							-davo

    p.s.  still not quite sure what to use, but narrowing it down a little.

  It's funny how programmers often ask a question in an apparently
straightforward way, yet the answer is always "It depends."  And so will
I answer your single/multiple-language question.

  It depends.  Where do you place your emphasis?  Is the engineer who will
be maintaining the code fluent in the 3 languages you use?  Are major and/or
important components of your system suitable for the specific capabilities
of a particular language which is not the main language of implementation?

  If you use an AI language for AI work and make a single AI 'decision' in
all of your code, and using that AI language causes the architecture of
your system to be very confusing and complicated, then maybe you made the
wrong decision.

  I see it as a simple tradeoff between how much does the change of language
offer and how much does the language detract from all the 'ability's of good
software engineering (portability, maintainability, etc).

John [99-&-44/100ths-pure PASCAL programmer - yes, I float]

re: -1,

>  It depends.  Where do you place your emphasis?  Is the engineer who will
>be maintaining the code fluent in the 3 languages you use?  Are major and/or
>important components of your system suitable for the specific capabilities
>of a particular language which is not the main language of implementation?

	3 languages?  Hold the phone!  I didn't mean to imply that I would use
    3 different languages.  I'm pondering the differences between using two
    languages together, a high-level combined with a medium-level (i.e. Pascal
    and BLISS), as opposed to using a single language (i.e. BLISS or C by
    itself).

	How else could one program in a high-level language (i.e. Pascal) and
    be allowed the low-level functionality which I plan on needing?  Would
    RTL, RMS, system services, and DCL alone be enough to allow a Pascal
    programmer sufficient low-level resources and optimization?  If so, then
    why do people bother with "low-level drivers" written in lower-level
    language?

							-davo

The answer is still "it depends."

It depends on what your overall goals are.  Pascal in general is a more
easily maintainable language than BLISS and much less prone to simple but
hard to detect coding errors.  On the other hand, it can be MUCH more
difficult to get close to the machine and operating system in Pascal.

How much low-level stuff are you doing?  How low-level is it, really?
Which is more important to your project:  speed, time to market, cost of
maintenance?

--PSW

re: What low-level am I doing?

    	Hmmmm....well, none yet.  That's part of the reason I'm asking
    about it.  I plan on eventually getting into some print symbiont
    coding for both existing printers and plotters: XEROX 8700, System
    Impact Printers (LP25 ,26 27, etc.), laser printers (LN01, 03, etc.),
    ink-jet printers (LCP01, etc.), LVP16 Color Graphics Plotter, CAD-Comp
    plotters, Benson Plotters, as well as anything else which can possibly
    be hooked-up to a distributed queueing system.  See .0 for more of a
    general description.

    	As such, I want to prepare myself for my eventual dive back under
    the surface (and back into the programming business), but it gets real
    foggy down there sometimes and I want to make sure I have a decent plan
    of action before I go (kind-of like shopping for a new religion).

    	Most of the stuff I've seen so far (and of which I will be supporting/
    modifying to a certain degree) consists of various (but sparse) high-level
    languages (FORTRAN-77, PL/I, Pascal, POSTSCRIPT, etc.) accompanied by
    medium to low-level device drivers and symbionts written in either BLISS
    or MACRO.

    	I see a clear need to learn BLISS, but on the same token, I see alot
    of movement in the general direction of C programming, and I don't want
    to "miss the boat" here by ignoring C.  I'll be dusting off my Pascal
    programming while I focus-in on my strategy, but so far it looks like
    I'll be safer than I thought at first by sticking to BLISS for any low-
    level programming that comes along.

    	I just want to make sure I'm not better-off trying to do everything
    in a medium-level language to begin with (instead of fooling around in
    Pascal), or whether the high-level language pays off as "icing on the cake"
    to any medium-level code.

    							-davo

    I normally don't read this conferences, but I just can't help getting
    my two cents in...
    
    RE: 97.*
    
    a) There are pieces of VMS written in VAX PASCAL.  EDIT/FDL (there
       may be a few other isolated pieces).
    
    b) I know of at least one group inside Digital that is using
       VAX PASCAL generated code in a completely stand-alone kernal-mode
       environment.  (No VAXELN is involved.)  I know their doing some
       good low-level stuff because they've asked us to put in MFPR
       and MTPR as VAX PASCAL builtin routines.  They're tired of calling
       MACRO routines to do it for them...  We already have kitchen-sink
       builtins for FIND_FIRST_BIT_{SET|CLEAR}, {ADD|SET|CLEAR}_INTERLOCKED
       (ADAWI,BBSSI,BBCCI), futures may include some of the interlocked
       queue instructions.  
    
    c) While I can't VMS device drivers in VAX PASCAL, you can write
       all sorts of interesting pieces of code.  Print symbionts, etc...
       without too many behind-the-back VAX PASCAL tricks.
    
    d) I believe that the new standard may make VAX PASCAL more interest
       for VAX/VMS software development, but I'm not really holding
       my breath.  I'd like to see everybody using it (can you tell
       I'm biased?), but...
    
    e) If memory serves me correctly, the VALUE section first appeared
       in V3 of the CDC-6000 series Pascal compiler back around 1979.
       VAX PASCAL V1 had it because that compiler had direct connections
       with the CDC compiler.  V2 carried it over as a V1 compatibility
       issue.
    
    f) Several non-VMS products use VAX PASCAL as their implementation
       language.  (The names of which allude me now, but there is a
       note back in the PASCAL notes file with a list of products that
       use VAX PASCAL.)
    
			-John    

    One more thing...
    
    RE: .15
    
    If you compare Modula-2 and VAX PASCAL, most of the features in
    Modula-2 over STANDARD Pascal are in VAX PASCAL as extensions.
    
    While I'm not saying avoid Modula-2, it really doesn't have much
    over VAX PASCAL except for portability to non-VMS systems.
    
			-John

re: John,

	Boy, this is sounding better all the time!  Considering the fact
    that I'll be doing alot of Pascal for the next four months anyway,
    (assuming I sign-up for classes at the Harvard Extension school as I
    am considering doing), now I know that none of it will be in vain either!

							-davo

    	Apart from languages you are probably not considering anyway
    (anyone volunteer a symbiont written in OPS5?) you can probably
    do pretty well anything you want in any language, so you have to
    consider rather marginal things.
    
    	Avoid Fortran, since it is not too good with complex data
    structures.
    	Avoid Cobol, it can't handle addresses of procedures too well.
    	Don't think of using Macro until you can identify *the* five
    lines in your programme that need it. Bliss often generates more
    efficient code if you are writing your source to be maintainable.
    	Use as high a level language as possible for the bulk of the
    code (someone else already said this), but that does not mean rule
    out Bliss. If your project is large enough to justify building up
    a bit of a library, then Bliss macros and structure definitions
    can make it a high level language tailored for your application.

    It's too bad that Digital doesn't see fit to have a supported MODULA-2
    compiler.  I have been using it for a few months now on my home
    machine and I really think it would solve your "high/low" delemma.
    As to the suggestion that VAX Pascal (or any Pascal) is about the
    same as MODULA, I say baloney!  Environment files are not as "powerful"
    as UCSD Units which are *very* weak compared to MODULA modules.
    In fact, since neither supports abstract data types or data hiding
    there really is no comparison.  VAX Pascal (and the rest) don't
    have procedure variables, type transfer functions, low level types
    of ADDRESS and WORD, concurrency (though UCSD *does* have a good
    implementation of this...), code procedures (the way Ada should've
    done it...), facilities for runtime information on objects and types,...
    
    Also, building support for a (more closely) real object oriented
    environment is "doable" and fairly reasonable in implementation.
    The result is much more than what you get with Ada generics though
    you do take a hit up front while building the support.
    
    O.K. now, I've gotten my $.02 in also.
    
    /Jon

    In CAD most all the "new" development is in Pascal or C. There's
    hundreds of thousands of lines of FORTRAN CAD code that very few people
    like. Portability is an issue, e.g., some CAD work (some SUDS code)
    used in the 8800 development would only run on DEC-20 machines. It was
    "cheaper" in terms of project time/money to buy a 2020 and 2060 and
    connect them to VAXen than rewrite the macro code.
    
    I got tired of programming in Modula-2 on my Mac because I spent way
    too much time maintaining consistency between definition and
    implemention modules. VAX Pascal's module system is MUCH more sane.
    
    When you leave the project, it will be easier to find a Pascal or C
    programmer to maintain the code when you're gone. Modula-2, Ada, and
    BLISS are nice languages, but what percentage of programmers are
    familiar with them -- particularly young programmers? 
    
    VAX Pascal often generates faster running code than VAX C or VAX Ada. I
    have strong type checking prejudice, and prefer Pascal to C. But I
    really like the formated IO of C. And VAX Pascal's READV and WRITEV
    are not portable. Where as sscanf and sprintf are pretty standard in
    Cs. Those come in handy when writing portable parsers.
    
    If you have to do bit twiddling, register manipulation, timing loops,
    do it assembler -- don't mess with BLISS. Chances are it's only going
    to be a few small routines anyway. 
    
    BLISS has only two advantages over other high-level languages:
    explicitly tying a variable to a particular register, and explicitly
    specifying JSB rather than CALL linkage between routines. But VAX
    Pascal does a very good job of allocating registers for most purposes,
    and it automatically generates JSB linkages where appropriate. Most
    people's BLISS programs don't use those features anyway, and the
    language is more difficult to become proficient at. In my opinion, it's
    not worth the effort to learn BLISS.
    
    It's common with BLISS programs to track down bugs due to a missing dot
    on a variable. Pascal "VAR" parameters is a much more reliable way to
    access by reference than putting remembering how many dots to put on
    the paramter. The MACRO facility in BLISS is so baroque that it often
    difficult to tell what somebody's MACRO is trying to accomplish. It's
    been my experience that I can use Pascal and C to write a correctly
    running program much more quickly than I can by using BLISS. I also
    know some old-time BLISS hackers who will argue that they can code in
    BLISS faster. 
    
    -George  (VAX Pascal gets my vote).

>    I got tired of programming in Modula-2 on my Mac because I spent way
>    too much time maintaining consistency between definition and
>    implemention modules. VAX Pascal's module system is MUCH more sane.
        
        If you don't change your definition module you don't need to
        fool with the corresponding implementation.  If you do, then
        it sure would be nice to maintain consistency!!!!!!!  Also, the
        supposed "sanity" of VAX Pascal's environment files buys *very*
        little in the way of system development support.  From what I was
        ever able to discern, it only gave you a form of separate compilation.
        Don't get me wrong, I think that VAX Pascal is one of the best
        implementations I've seen, and I even like Pascal.  But, ah, um,
        well, Pascal is Pascal....
        
        Analogy:
        In a way modules are to systems development what type checks are to
        procedure development.
    
>    When you leave the project, it will be easier to find a Pascal or C
>    programmer to maintain the code when you're gone. Modula-2, Ada, and
>    BLISS are nice languages, but what percentage of programmers are
>    familiar with them -- particularly young programmers? 
        
        First, why should this be such a big deal?  Second, I would expect
        this to start changing (for the first two).  I already know of a
        number of schools that are going with MODULA over Pascal.  And with
        such a big push on for Ada, I would think it will become quite
        common throughout the industry.
    
>    VAX Pascal often generates faster running code than VAX C or VAX Ada.
        
        Where did you see (hear) this??  From what I've seen, they're all
        about the same (mostly due to DEC's common backend...).
        
        
        /Jon

< Note 97.33 by CIM::JONAN "Hey, it's all line noise to me..." >

>>    VAX Pascal often generates faster running code than VAX C or VAX Ada.
>        
>        Where did you see (hear) this??  From what I've seen, they're all
>        about the same (mostly due to DEC's common backend...).


VAX Pascal does not use the VCG.

    	The Bliss macro facility may be "baroque" but I can write a
    macro which produces a sorted table from its arguments suitable
    for a binary search at run time. It may take longer to learn how
    to do this in Bliss than it takes to learn the same thing in Pascal.
    
    	For a symbiont, it is probably not going to require too much
    transportability.
    
    	For personal preference, if I am writing a few lines for my
    own amusement I use macro or fortran or teco or dcl or focal or
    sort/merge control files or sometimes even basic. If I am writing
    something that someone else might see then I tend to use PL/1 and
    Bliss.
    
    	Don't take it too seriously - they are all much the same. And
    in particular, don't take any advice from this notes file - we are
    all religious fanatics.
    
    		Dave

        It's very simple to do simple things with Bliss macros.
        Extremely complicated things are extremely complicated... but
        what do you expect?  It's the only language where you can *do*
        that sort of thing at compiletime (although the Burroughs XALGOL
        macro facility came close in some ways, it lacks a lot). 
        
        Bliss has the best macro facility of any language anywhere,
        and the best VAX code generator (although some of the others
        are getting pretty close).
        
        Although Bliss data structures are at a low level, they are
        *very* powerful and flexible, which is also a major advantage
        when trying to do complicated things.  They're easy to define,
        too, with SDL.
        
        *All* languages have their own strengths and weaknesses...
        though some like PL/I, RPG, and C have more weaknesses than
        strengths.  :-)
        
        Basically, the only really correct advice in this topic so
        far is Dave Monahan's in .35: we're all religious fanatics
        and you'd be better off not listening to any of us.
        
        	/dave

    Re: .36
    
    Ahem. I think any modern lisp's macro facility is much superior
    and much more powerful to Bliss's macros. The main reasons are
    (1) lisp code and data structure are the same, making it trivial
    to deal with code using normal list functions (2) it is much
    less prone to syntactic errors, since the substitutions are at
    the "token" level [use read macros for character-level syntactic
    changes] and (3) you can control and perform arbitrary operations
    at compile, load, or run time using the same syntax as the primary
    language.
    
    So I'd be careful saying things like "It's the only language where
    you can *do* that sort of thing at compiletime...".
    
    			---Walter
    

    BLISS macros have to be very powerful because you have to *do* so much
    more when all the data structures are so primative! I'd much rather
    have a more verbose Pascal program that's easy to read and understand
    (e.g., sets and enumerated types) than muck around with bit vectors.
    With BLISS I spend more time looking at the trees and see less of the
    forest. Of course, I haven't seen this SDL. I don't remember reading
    about SDL in my BLISS manuals (pretty old). Is it documented in the
    newer ones?
    
    I don't buy the assertion of better code generation in BLISS. BLISS
    does not do global optimization, e.g., automatic inlining of small or
    infrequently called local procedures, automatic use of JSB linkage, or
    pass parameters by register. I think VAX Pascal can do that kind of
    stuff. And the code generation of VAX Pascal in general is very good,
    e.g., puts NOPs to align starts of loops on longword boundaries. When I
    compile BLISS for speed, it seems to ignore it and compile for space.
    Is this a heritage from the days of VAX/VMS having to run on 256KB
    memory configurations? 
    
    I think BLISS was very good language in it's day. But it has outlived
    it's usefulness. The higher level languages now do 99% of what BLISS
    does, and do it more easilly and of equivalent quality. The other 1%
    should be done in assembler anyway. 
    
    -George (Come on! I want some BIG flames!)

        .37:  Hmm.  You're probably right: it was too general a
        statement.  I wasn't even aware LISP did compile-time macros.
        
        My statement was rather narrowly directed and rather widely
        phrased... extremely bad noting on my part.
        
        .38:  You can do *some* of what macros do in other languages;
        at least, what that language considers proper.  Macros provide
        much more flexibility.  I like flexibility... others prefer
        the compiler to force them to do things its way.  I'll admit
        it's largely a matter of taste.
        
        As for code generation, indeed many of the other compilers
        have gotten much better.  Pascal will inline some routines,
        but that's not *real* global optimization (e.g., optimizing
        variable usage throughout a program).  I can "inline" routines
        in Bliss by deciding whether to code them as macros or
        routines... and change back and forth trivially, without
        affecting the calls.  It's not automatic, but it's extremely
        easy.
        
        Yes, Bliss's penchant for space optimization is a holdover
        from the old days... and I've never really liked the way
        it does speed optimizations anyway.  The default is usually
        fine anyway... 
        
        By the way, SDL isn't part of Bliss... it's a structure
        definition language (a mostly internal-only product, although
        a version without the parser gets sent to customers).  There's
        a standard language for defining structures, routine calls,
        symbols, and such, and you can generate require/include files
        for a number of different languages (including Bliss) from
        the common source.  While the syntax of SDL isn't exactly
        optimal (it's PL/I based, for one thing), it generally works
        pretty well.  It has a notes conference, TLE::SDL (SELECT
        or KP7, etc.).
        
        	/dave

    I did the loop-alignment and much of the inlining for Pascal.
    Thanks for the good words!
    
    Howecer, I still prefer BLISS for implementation.  Why?  Well,
    because I (as a programmer know more about the expected run-time
    behaviour of my product than the compiler does.  The Pascal compiler 
    makes a guess about which routines should be inlined.  The BLISS compiler
    lets _me_ make the guesses, and allows me to do all sorts of nifty
    things with parameters.  My guesses are better, as I have a larger
    understanding of the system (and the help of PCA).
    
    Of course, this is only an advantage for systems where it is worth
    investing LOTS of programmer time.  For the normal case, having
    the compiler do the grunt work is reasonable.  This is a parallel
    to my willingness to use BLISS rather than MACRO.  I have used MACRO
    where the extra effort on my part was worth it.
    
    An example of what BLISS lets me do:  in a parser, there is a certain
    amount of state (the current token, current delimiter, position
    in the line, etc) which is preserved over routine calls.  BLISS
    lets me put this stuff into GLOBAL REGISTERs, and make the calls
    be JSBs for the small routines and CALLs for the larger ones.
    Pascal might inline some of the smaller routines, but would not
    detect the potential global registers.
    
    So, _we_ should be using BLISS for "systems" stuff where the
    hand-tweaking is justified, and <pick-your-favorite> for code where
    the compiler's optimizations are good enough.
    
    				-John Bishop

Re: 97.38

> When I compile BLISS for speed, it seems to ignore it and compile for
> space.  Is this a heritage from the days of VAX/VMS having to run on
> 256KB memory configurations? 
    
Actually, its probably a heritage from the fact that BLISS-11 had to
produce programs that would run in 60KB memory configurations.

    I'd be happy with a good 3GL with strong typing, syntactic sugar,
    declarations within any block, and definition and overloading of
    infix operators.  As long as the 3GL isn't PL/I.

< Note 97.42 by CLT::GILBERT "eager like a child" >


    I'd be happy with a good 3GL with strong typing, syntactic sugar,
    declarations within any block, and definition and overloading of
    infix operators.  As long as the 3GL isn't PL/I.

================================================================================

Isn't that language called "Ada"? :-)

    - Bill (VAX Ada)

    RE: .42

    Alright, I'll bite.  Why is everyone so negative about PL/I?  It really
    isn't that bad a language.  (Note that VAX PL/I is moderately strongly
    typed if you don't compile /NOWARN.  i.e. if you don't use built-in
    functions to convert data types, you will get errors for "unusual"
    operations, such as using concatenation with a number, etc.  Of course,
    it will "do the right thing" if you chose to ignore warnings...)

    It seems to me that a lot of people think of PL/I as an old upper-case
    leftover from FORTRAN days.  Sure, a lot of the full-language features
    like the DEFAULT statement, ISUB defining, etc., aren't exactly what
    we consider good programming practices these days.  On the other hand,
    both Ada and Pascal have a GOTO statement...

    Re: .44
    
    PL/I *is* an "old upper-case leftover from FORTRASH days" :-).  Standard
    PL/I is not typed and the VAX PL/I business of issuing warnings doesn't
    change this.  Nor is there any checks across compilation boudaries for
    consistency of type and number of procedure parameters.
    
    The structure and syntax of the thing are arcane and hamper
    readability.  PL/I has no user definable types - a *major* flaw; Nor does
    it have enumeration types or sets (and "But but, what about bit strings"
    doesn't make it either...).  Without any kind of user definable types
    you don't have *any* data abstraction capabilities.  Of course the newer
    concepts of ADT's and OO are completely out of the question.  And this
    list of "big ticket items" goes on: no concurrency, no data hiding (more
    like data *showing*), no overloading capabilities, and no generics (No,
    macros don't count, and besides they're VAX specific anyway...).  Pascal
    doesn't have all these things either, but it does have "enough" to get
    it out of the "stone age".  Ada and Modula have them all in one form
    or another.  And if you consider LISP, PROLOG, and Smalltalk, you can
    add a whole other chapter to the above.
    
    O.K., now that I've lit the fuse, I can just standback and watch the
    fireworks!! :-)
    
    /Jon

	    Wirth himself has abandoned Pascal for Modula-2.
			<_Jym_>

Re: .45
    
>    PL/I *is* an "old upper-case leftover from FORTRASH days" :-).  Standard
>    PL/I is not typed and the VAX PL/I business of issuing warnings doesn't
>    change this.  Nor is there any checks across compilation boudaries for
>    consistency of type and number of procedure parameters.

Quite a few PL/I implementations will issue warnings for "unusual conversions".
VAX PL/I is more strict than most.

>    The structure and syntax of the thing are arcane and hamper
>    readability.

Arcane?  Somewhat.  However, even Ada and Pascal have their glitches.  (I will
certainly admit that PL/I has more strange things that most... :-) )  As far
as hampering readability, I can't say that it does.  Writing readable programs
is not difficult in most languages (including PL/I), providing that you try
to write them readably.  There is a lot of PL/I code that wasn't written for
readability.  On the other hand, I've worked my way through several pieces
of read-world (production) extended Pascal code that were very hard to read.
(i.e. no easier or harder than PL/I code written in that style.)  Certainly,
the data typing facilities of Pascal (or other more modern langauges) can help
the readability of the code, and I agree that the lack of real data types in
PL/I is probably the biggest hole in the language.

>  PL/I has no user definable types - a *major* flaw; Nor does
>    it have enumeration types or sets (and "But but, what about bit strings"
>    doesn't make it either...).  Without any kind of user definable types
>    you don't have *any* data abstraction capabilities.  Of course the newer
>    concepts of ADT's and OO are completely out of the question.

That's certainly a very weak point of the language.  (There is LIKE which
allows you to approximate data types for structures, but it is admittedly
a very poor substitute.)

>  And this list of "big ticket items" goes on: no concurrency,

A model of concurrency is defined in IBM PL/I, although it is much more
"grubby" in nature than something like Modula-2 since it was an initial
cut at parallelism specifically designed to suit a multi-process implementation
on an IBM OS.

> no data hiding (more
>    like data *showing*),

Right.

> no overloading capabilities,

Operators, no, routine names, yes.  (Not in VAX PL/I, though.)

> and no generics (No, macros don't count, and besides they're VAX specific
> anyway...).

The preprocessor isn't VAX-specific.  It is directly based on the IBM PL/I
preprocessor.  (Again, it is certainly less eligant than Bliss, but it does
get the job done most of the time.)

>  Pascal
>    doesn't have all these things either, but it does have "enough" to get
>    it out of the "stone age".  Ada and Modula have them all in one form
>    or another.  And if you consider LISP, PROLOG, and Smalltalk, you can
>    add a whole other chapter to the above.

I still wouldn't call it the stone age.  Yes, there are times when various
features are need.  On the other hand, what percentage of "average" programs
do you think would use multi-tasking (monitors, whatever), even if they
were available in all languages in a reasonable form?  (A side note -
vanilla Pascal is just a teaching language and is not suitable for production
programming anywhere near as much as PL/I.  On the other hand, I would
probably take VAX Pascal over VAX PL/I for an implementation language if
I were free to choose, although it would depend on the application to some
degree.)

>    O.K., now that I've lit the fuse, I can just standback and watch the
>    fireworks!! :-)

I didn't claim that it was great.  On the other hand, I've heard quite a
few people grumble about the lack of things such as varying length strings
in Ada and Pascal.  (Yes, I know there is a VAX-specific extension for
varying length strings in VAX Pascal, but we aren't considering VAX-specific
extensions, right? :-) )

Basically, PL/I IS old, and Ada and extended Pascal implementations are
frequently preferable.  However, there are still a lot of useful and
non-grubby things that I can deal with in PL/I that are at best difficult
(or very slow) in Pascal or Ada.  (Examples?  Some types of varying-length
string manipulation, using structures where one field contains the sizes
of other fields in the structure, doing systems programming on a weakly-
typed system like VMS that commonly have overloaded address fields, ...)

Besides, given that people are toting the virtues of "C", PL/I must still
be useful... :-)

Kent

    Having started this small fire, let me do a little to squelch it.

    The reason for my comment is because most anything I can do with
    PL/I I can do more easily or better in either Pascal or Bliss (for
    varying strings I use Bliss, since it doesn't care what you do).

    I've written some very nice PL/I code, but have also seen 20 line
    PL/I routines (in production code!) that were indecipherable and
    unmaintainable.

re: Ada,

> Isn't that language called "Ada"? :-)

>    - Bill (VAX Ada)

	So, Bill...if Ada is so great, then why isn't there a version of it
    entered in the "Battle of the Languages" yet?


re: PL/I,

	Would the fact that this language comes from IBM have anything to do
    with it's percieved unpopularity here at DEC?  If so, then why is C not
    suffering from the same problem (being an AT&T property of sorts), or is
    it too causing friction?

							-davo

    About a year or so ago I mucked around quite a bit with a state machine
    for the language PROLOG. It was written in BLISS, and it uses the
    global declaration of register variables and JSB linkages. But
    eventually, I got to the point where I spent too much time tweaking
    simple little expressions in order to coax the compiler to generate the
    more efficient code -- the kind of code I could have written much more
    quickly in assembler. 
    
    One feature, lacking in BLISS is the GOTO. There are valid uses for the
    GOTO (state machines are one of them and exiting from nested loops is
    another valid use). For a language that developers prided themselves on
    for the freedom it gave the programmer, it really angered me that they
    were so arrogant as to also dictate what I can't do (They left GOTOs
    out because they didn't like them.) At least some versions of C allow
    one to insert assembly language code into the program for things that
    the C doesn't do well itself. No such feature in BLISS. 
    
    As for PROLOG itsef, well it's a nice language. But you can't declare
    named constants, e.g., something equivalent to "CONST MAX_VAL = 100;".
    Thus, code using a lot numeric values tends to be less readable than
    other languages. There's no type definitions in the language, e.g., no
    equivalent of "TYPE INDEX = 0..255;". And even the notion of types is
    not too well defined in the language. Variables can not be predeclared,
    therefore misspelled variables are assumed to be new variables or an
    atom -- like BASIC or the FORTRAN IMPLICIT (puke! yuk!). Most PROLOG
    implementations have no module concept (in the Parnas sense), or a very
    crude version of modules. MPROLOG, developed Hungary, is the only
    PROLOG to fully implement modules (the M in MPROLOG is for "module").
    PROLOG tends to be more readable than another very high level language,
    LISP. But it does not have the rich number of data types, and powerful
    IO of Common LISP. Historically IO is one of PROLOG's weakest features,
    which makes real-world programming difficult (much like Pascal in that
    aspect). But some of the newer implementations have added more powerful
    IO. The way the language controls flow of execution is a little
    "strange" to most programmers. And no two versions of PROLOG handle
    flow of control exactly the same way. Also, there is a wide variation
    in the syntax of the language between implementations, e.g., Sigma
    Prolog, Prolog II, and DEC-20 PROLOG. There is an effort in Britain and
    France to standardize the language. Right now, the language isn't as
    stable as most other languages. It's going thru a rapid evolution. I
    look forward to future versions versions of PROLOG, especially a
    standard PROLOG. 
    
    Oddly enough, PROLOG is one of my favorite languages. It's a great
    language for proto-typing. It supports the relational database model,
    but goes far beyond that in power. The QUINTUS PROLOG compiler on our
    cluster got broke on the VMS 4.4 upgrade. So, I haven't got around to
    writing a game of life in PROLOG. I'll try to remember to do that
    sometime.
    
    -George

	Re: .47


> On the other hand, what percentage of "average" programs
> do you think would use multi-tasking (monitors, whatever), even if they
> were available in all languages in a reasonable form?

	Well, I don't know about others, but I use these capabilities quite
	often!  They allow you to more easily and more rigorously model the
	problem space.
	

> ...  I've heard quite a few people grumble about the lack of things
> such as varying length strings in Ada and Pascal.

	Actually, *varying* strings in Ada are easily accomodated by the language.
	*Dynamic* strings are a problem because most (all?) implementations
	do not have garbage collectors.  Of course, CHAR(*) is just a varying
	string too...
	
> using structures where one field contains the sizes
> of other fields in the structure, doing systems programming on a weakly-
> typed system like VMS that commonly have overloaded address fields, ...)

	I don't see where doing this stuff is any kind of problem for Modula
	or Ada.  Of course, I've never tried them out in this area *on VMS*!!

	/Jon

re: .51, etc.,

>> ...  I've heard quite a few people grumble about the lack of things
>> such as varying length strings in Ada and Pascal.

>	Actually, *varying* strings in Ada are easily accomodated by the language.
>	*Dynamic* strings are a problem because most (all?) implementations
>	do not have garbage collectors.  Of course, CHAR(*) is just a varying
>	string too...

	DESIGN does such a decent job with dynamic strings, that I became
    somewhat spoiled coding in it.  I don't exactly look forward to being
    limited once again to fixed length strings in Pascal.

								-davo

< Note 97.49 by JUNIPR::DMCLURE "Vaxnote your way to ubiquity" >

	So, Bill...if Ada is so great, then why isn't there a version of it
    entered in the "Battle of the Languages" yet?

Actually, Peter Vatne (who entered the TECO version of LIFE), translated the
PASCAL program into Ada. It is a very similiar looking program, and doesn't
use any of the powerful features of Ada that can only be realized in a larger
scale project. Now, if you wrote the "correct" implementation of LIFE with
unbounded board size, some of the more powerful aspects of Ada would come
out. However, we haven't gotten around to doing that yet, if ever ...

re: .53,

> Actually, Peter Vatne (who entered the TECO version of LIFE), translated the
> PASCAL program into Ada.

	I can't wait to see it!
	
> It is a very similiar looking program, and doesn't
> use any of the powerful features of Ada that can only be realized in a larger
> scale project. Now, if you wrote the "correct" implementation of LIFE with
> unbounded board size, some of the more powerful aspects of Ada would come
> out. However, we haven't gotten around to doing that yet, if ever ...

	Note that I changed the rules to allow ANY version of *Life*, even
    though the unbounded feature would be far exceeding the specification I
    posted which was taken from an end-of-chapter programming assingment in
    one of my old Pascal textbooks.  I decided not to risk stifling anyone's
    creativity, and besides, such a version would be very educational, as
    well as fun to play.

	While this spec may not be "correct", at least it was simple enough
    to serve the purpose of an INTRODUCTORY programming language comparison.
    Don't think Ada won't be challenged to prove it's self in the second wave
    of the "Battle", I've got plans for it later.  In the meantime, It'll be
    nice to see an Ada version which satisfies the simple spec.

	Anyway, back to the subject...what language claims the best string
    manipulation features?  Lisp?

							-davo

< Note 97.52 by JUNIPR::DMCLURE "Vaxnote your way to ubiquity" >

    DESIGN does such a decent job with dynamic strings, that I became
    somewhat spoiled coding in it.  I don't exactly look forward to being
    limited once again to fixed length strings in Pascal.

Thanks Dave! I wrote all the code that implemented dynamic strings :-) And, *I*
had to worry about all the details of memory management, etc. As is often the
case, someone has to do the work. Somestimes its the users, sometimes its the
language/compiler writers.

    - Bill

    Harking back about twenty replies or so, there was a brief discussion
    about BLISS's wonderful macro capabilities.  I used to chafe at
    what C calls its "macro" facility -- it's really primitive.  But
    when I started using C under UNIX (no, please, really, I'm not trying
    to start a UNIX vs. VMS flame!) I discovered that there was an easy
    way to do anything that I once would have used macros in BLISS to
    do.
    
    UNIX has a whole pile of handy little text processing utilities
    that all play together really well.  Now, source code is just text.
    Every time I started pining for BLISS's macro facility ("Gee, I
    really hate to type all these function code names twice on each
    line, and I sure don't want to sort them by hand, and oh crud, I
    have to duplicate them in this other table over there") I realized
    it was easy to just write a little shell script to generate the
    source code in question.
    
    I suspect you could do the same kinds of things using TPU under
    VMS, although for me it's easier to just do it under UNIX and move
    the generated source over than to learn TPU and DCL to the extent
    necessary.
    
    Anyway, my point is that decent text-processing utilities basically
    make macro preprocessors superfluous.  And note that the same utilities
    (TPU and DCL on VMS;  sed, ed, awk, grep, cut and paste on UNIX;
    SNOBOL on TOPS-10/20) can be used to generate code for ANY language
    that is missing a macro facility.

    As far as tasking goes....  We've been using Ada on our project
    for a while now and it turns out that almost all of our non-trivial
    code makes heavy use of tasking.  Of course, the code is based on
    an event driven model that is naturally parallel.  

    ...
    
    I should dig up that old life program (written in Pascal) that
    implemented the board as a toroidal(?) data structure!
    
    -- michael

    Re: .56
    
    Macros of either the character substitution kind or of the token
    replacement kind are meant to serve as a syntactic abbreviation
    facility in the source code for human readers. Just automating the
    expansion of the macros at a time such that people will always see the
    expansion (if this is what you're saying) removes some of the
    modularity of the code. Those substitutions aren't invertible either,
    in general.
    			---Walter

    I don't often use multi-tasking in Vax Lisp, so I guess it's true
    the ``average'' program doesn't need it. But when you need it, it
    sure is handy to have around!
    			---Walter

re: .50

    Bliss has a LEAVE statement that exits multiple statement blocks.

re: .58

    Usually, you *don't* want to see the expanded macroes -- the source
    should be more readable or maintainable *with* them.

new:

    It's usually claimed that the great value of Bliss's macroes is
    in building tables.  While that may be one of the more important
    uses of Bliss's macroes, I'd rather have initialization routines
    that get executed at compile-time.  Occam's Razor applies (it is
    wasteful to use more when less will suffice) -- the same language
    and techniques could be used for both run-time and initialization.
    And I think macroes would still be useful.

Re .50:

Allowing unrestricted GOTOs in Bliss would have greatly complicated flow
analysis in the compilers.  It is done on the fly while parsing, at
least in Bliss-11 and all subsequent compilers.

Using GOTOs to construct an efficient state machine will cause most
optimizers in most language implementations to throw their hands up in the
air and produce code that is globally pessimistic.  Putting a CASE on the
state number inside a WHILE loop will probably not do any better, but it
doesn't require a new concept to blow it.

Every Bliss compiler I've ever used has had quite adequate facilities
for machine language insertion.  If your's hasn't, you must have had a
target machine architecture with variable-length instructions.

Note that Bliss's LEAVE statement does not arrogantly force the assumption
upon the programmer that only one loop needs to be exited (or continued).
The same cannot be said for C.
				/AHM

    RE: .61
    
    I agree that the "LEAVE" construct to exit loops in BLISS is nicer than
    say the "break" in C or GOTOs. Only some types of GOTOs make compiler
    optimizations difficult, e.g., LEAVE is really a type of GOTO and BLISS
    can still optimize. Exiting nested loops with a Pascal or C GOTO shouldn't
    cause problems for the compiler's optimiser.
    
    For a state machine there are frequently backward branchs (GOTOs to
    prior code). And yes, backward GOTOs and GOTOs out of a local routine
    can wreak havoc on the compiler's attempts to perform certain kinds of
    optimizations. 
    
    Assembly language programmers don't have to worry about that lost
    optimization though. The point I was trying to make in .50 is that if
    you really want to do low level coding (i.e., coding that a high level
    language like Pascal can't do) then it's also highly probable that
    BLISS won't be satisfactory also -- unless all you want is to declare
    global register variables and JSB linkages. In those instances some
    pain can be saved by using assembly language in the first place.
    
    If VAX Pascal ever developed extensions to specify global register
    variables, routine linkage, and added a few more machine specific
    instructions to the exisiting machine specific instructions, would
    there be any need at all for BLISS? 
    
    -George 

< Note 97.62 by LOGIC::VANTREECK >

    If VAX Pascal ever developed extensions to specify global register
    variables, routine linkage, and added a few more machine specific
    instructions to the exisiting machine specific instructions, would
    there be any need at all for BLISS? 

Not to get off the subject, but if VAX Ada ever developed extensions to specify
global register variables, routine linkage, and added a few more machine
specific instructions to the exisiting machine specific instructions, would
there be any need at all for BLISS OR Pascal? :-) 
    
I believe Ada is at least a superset of Pascal, so why even bother with Pascal?
[not to put down Pascal, but ...]

    -Bill

re: Ada,

	How many operating systems have been written in Ada?  Has it been
    thoroughly tested enough to rely on it for general purpose computing?


							-davo

    p.s.  I realize it passed the government benchmark tests...

    re: .63
    
    Good point! Ada would be an excellent alternative, particularly since
    the machine specific features (instructions, routine linkage, register
    usage) can be placed in pragmas which provides a clear seperation of
    standard from extended features. For example, if Digital were to port
    the software to a new computer architecture, it would be much easier to
    locate and change the machine specific pieces of code. Also, I hear the
    proposed ANSI C standard will include a #pragma.... 
    
    -George

	Ada *sounds* better all the time, but that's just it - all talk
    no action.  Am I going to have to write the Ada version of *Life* myself
    or what? ;^)

	Actually, now that we (DEC) have signed the agreement with Raytheon,
    I suppose it might be wise to consider picking-up Ada as a standard language
    for DEC programming projects (so we can talk the military rap).  I'm still
    not sure if (VAX) Ada is ready for this sort of widescale benchmark however.

								-davo

    I'd rather see the compiler do a good job of inter-module linkages
    than have programmers try to guess what would be best in terms
    of CALL vs. JSB, registers, etc.  Much easier to get right and
    debug, and more reliable in the long run.  With Ada and dependent
    compilation, this is POSSIBLE.  Some of the ideas, such as using
    JSB linkages when possible, are already being considered.
    
    The Raytheon agreement means nothing specifically as far as Ada
    is concerned.  My sentiment is that Ada is suitable for some
    internal projects but not for others - at this time.  If I couldn't
    use Ada, I'd use BLISS.
    
    As for the Ada version of LIFE - I started writing one, that would
    be a bit beyond the simple translation of the Pascal variant.  I
    had the thought of having each cell be a separate task, something
    that closely models the game concept, but it's just a bit TOO
    ridiculous.  I'll see if I get time to finish it.
    					Steve

    RE: .66
    
    Oh come on now.  Ada is NOT just a military language!  (Is COBOL?)
    We've been using Ada for about 9 months now and are VERY pleased
    with what it provides us.  We're doing a LARGE project (in the factory
    automation area) and large projects are where Ada really shines.
    
    I haven't written a Life program in Ada simply because I've been
    too busy writing Ada code trying to meet schedules.

    
    -- michael

re: .68,

	Ok, I suppose a little bit of my techno-snobbery is slipping out;
    I agree that Ada SIN'T just a military language the same way that I
    agree that DSM (Mumps) SIN'T just a medical language.

	Besides, I'm sure if someone decided to ride the military bandwagon
    in order to "sell" Ada to DEC programmers, that they might not get too
    far at all (we're all peaceniks right?  Anti-star-wars and the whole lot?).

	Anyway, now that Bill Meier entered an Ada version (#99.57), I guess
    Ada is officially off the hook for the time being (or "enlisted" in the
    "Battle" - whatever).

	So, speaking of Cobol...I wonder where all of the Cobol programmers
    are hiding out there?  BLISS's draft number is also up, where are the
    BLISS programs?  After all, BLISS is/was THE DEC standard programming
    language right?

								-davo

    p.s.  Just teasing you guys...he he...

    We are looking at a major rewrite of our product, and since parts
    of it may end up on iAPX86 class machines (IBM PC, AT, VAXmate,
    etc) doing the whole thing in Ada looks like a better alternative
    than what we did in V1.0 (part in BLISS, and a significant amount
    of duplicate code in Microsoft C).  Especially in view of the tie-in 
    to produce the iAPX86 back end for the VAX Ada compiler.
    
    In the next few months we are going to be evaluating what our next
    move should be, so war stories about what folks have learned in
    using Ada or other languages.  Of particular interest are projects
    that use DECnet and ASTs.
    
    john

    I would highly suggest you contact the VAX Ada Product Manager (me)
    at 381-2343 before you plan a significant project around an 80x86
    Ada cross compiler.  We are still in the process of determining
    which targets (1750A, 680x0, 80x86,...) should be supported in the
    first wave of our release of our new XD-Ada product set.  The decision,
    which is being made shortly will be based on which targets the market
    could financially support.   

	The more I read about Bliss, the more I like it.  The fact that it
    is an "expression language", as opposed to a "statement language" which
    allows it to do away with the goto by relying on a wide range of control
    structures.  My favorite control structures (so far) are the select and
    selectone expressions, which, together with the case expression (which is
    the only structure Pascal has to offer like this), allow for a tightly
    organized module of code.

	On the other hand, the more I talk to people about Bliss, the more
    I find out that coding a large project is going to involve some hurdles
    not found in other languages.  For example, GKS doesn't seem to include
    the neccessary require files for Bliss (although they are available
    through the grapevine).  I wonder why it seems that Bliss (even though
    the recommended language for DEC programmers) has such a lack of support
    from other products in the corporation?

							-davo

        Probably because Bliss has seen *very* limited use outside of
        DEC (I believe I saw a figure of *5* external sites who have
        shelled out the rather high fee for a Bliss kit).  It's easy
        for other products to overlook such a small number of customers:
        especially products which might be faced with media
        restrictions, etc.  As you said, the larger number of *internal*
        Bliss programmers can get at what they need anyway.

        	/dave

	This Bliss Primer I've got mentions that (among other things), the
    following products were written in Bliss: VAX-11 Common Run-Time Library,
    Linker, VAX-11 SORT, DEBUG and RMS-32 ISAM, DECnet utilities, and "at
    least four other high-level languages".

	Now, this book is dated 1979, back when Bliss was required for
    ALL new software developed within Central Engineering.  My question
    is this: Given that Bliss (like C), is considered a "medium-level"
    language, exactly which of our high-level languages are written in
    Bliss?  Are they all written in Bliss?  Is it even fair to be comparing
    Bliss (since it is a medium-level language) to a high-level language
    such as VAX-Pascal?

								-davo

As far as implementation languages:

    FORTRAN, Ada (front end), Pascal, Bliss, and (I believe) COBOL and
	BASIC are written in Bliss.
    C (front end) is written mainly in C with some Bliss.
    PL/I is written in PL/I, TBL, and Macro.
    The VCG (the backend for Ada, C, PL/I and SCAN) is written in PL/I,
	TBL, Ada, and Macro.

    RPG, DIBOL, CORAL-66, SCAN, etc... ?

Re .72:

>   The fact that it
>   is an "expression language", as opposed to a "statement language" which
>   allows it to do away with the goto by relying on a wide range of control
>   structures.

The fact that Bliss is an expression language has absolutely nothing
to do with the fact that it has no GOTO.

Re .73:

You must be thinking of Bliss-36 sales.
				/AHM

        .77: No, as far as I know, I'm talking about Bliss-32 sales;
        from information related by someone who used to be a Bliss
        developer.  That doesn't mean I remember it correctly, or that I
        heard it correctly, or that he was correct (:-)).  If you have
        better information, I'd like to hear it... 
        
        	/dave

    VAX OPS5 is written entirely in BLISS - both the compiler and the
    run-time-environment.  The compiler uses the Galileo parser which
    is also written in BLISS.
    
    New OPS5 project leader,
    Uncle Ray

    Vax Lisp is mostly written in Vax Lisp, with a good chunk in Bliss
    and a few lines in Macro. However we intend in the near future to
    rewrite a lot of the Bliss code in Lisp to get some significant
    performance improvements. We'll leave some of the array manipulation,
    interrupt and exception handling, and maybe some low level I/O routines
    in Bliss, since it's very good at those things.

    			---Walter

re: .77,

	Maybe I worded it wrong (it certainly wasn't an exact quote),
    but I was refering to the fact that in order to design the language
    without gotos, it was neccessary to be able to break code into
    expressions which could then be modularized in a top-down fashion
    into smaller modules until finally, all code could be proven correct.

	I left the book at work, I'll see if I can't rephrase this later,
    but from the way it looks, VAX Pascal (is most likely) written in Bliss
    and therefore it might seem a bit silly to be comparing the two on
    equal terms.  I guess the real question for this note then is:  "Why
    program in a high-level language such as Pascal, when you can get much
    more functionality, modularity, as well as speed from a medium-level
    language such as Bliss?"
   
						-davo

    BLISS can avoid GOTO because of its rich control structure - something
    Pascal and even Ada (which HAS GOTO!) can't compare with.  I don't
    see any relevance to BLISS being an expression language.
    
    The advantage of a language like Pascal over BLISS is that the latter
    is very weak-typed, putting the responsibility on the programmer
    of getting things right.  In some cases, that's a disadvantage too!
    				Steve

    I'm intrigued - could you go into more detail about the performance
    enhancements you will get by rewriting some of the BLISS in LISP?
    
    /Bevin

    Two of the biggest factors in the performance of a lisp system
    (and, actually, any AI-oriented system) is the speed of function
    calling and the speed of type determination. When the Vax Lisp
    project started, we wanted to implement the primitives of the
    virtual machine in an existing language and then build the lisp
    on top of that. As the compiler got smarter, it could potentially
    put some of the primitives inline for speed; meanwhile the rest
    of the lisp system could be written in lisp, since that constitutes
    the majority of the effort.
    
    One of the issues facing us was what language to use to implement
    those primitives. Bliss was the clear winner over C for several
    reasons, among them the ability to control the registers and to
    use JSB linkages. The overhead of CALLx was just too great for us
    to use it in our calls to our primitives. [For that matter, the
    same reasoning applied to its use in regular lisp function calls.
    Lisp function calls use neither CALLx nor JSB, and in function-call
    intensive benchmarks Vax Lisp can outperform the same benchmarks
    written in C.]
    
    Unfortunately, it turns out that the Bliss code generated for our
    primitives has a lot of setup stuff, saving registers and initializing
    intermediate pointers and whatever, that isn't normally needed,
    since the common code paths don't actually use many (any?) registers
    or other intermediate values. So for most calls to a common primitive
    like addition (remember, unless otherwise specified, lisp arithmetic
    is generic) there are several unnecessary instructions and memory
    references being executed. It's quite possible to reorganize the
    sources so that this overhead is reduced (and in fact we've done
    that in one important case), but that is annoying.
    
    There are other reasons to rewrite the Bliss code in Lisp, but it
    turns out that rewriting many of the primitives in lisp will be a
    performance win for us. In the new scheme of things, just doing
    a normal lisp function call will be faster than what we do now
    as a special case using JSB.
    
    			---Walter

    Re: .84
    
    Interesting.  If it's not some closely kept secret, could you say
    what LISP function calls *are* implemented with??
    
    /Jon

    It seems that the supposed speedup is due to inline subroutine
    expansion.  This sure does wonders at times, and BLISS doesn't have
    it, but you could get a similar effect with macros, if there were
    no other requirements.
    
    All of the register setup stuff BLISS does can be reduced or
    eliminated with a bit of work.  I'd be very curious to see if the
    speedup from rewriting in LISP could be even better by paying enough
    attention to what BLISS can do for you.
    
    					Steve

    Re: .85
    
    JMP.
    
    Re: .86
    
    No, for the Bliss routines I'm talking about, inline subroutines
    aren't applicable and wouldn't help. Inline functions are handled
    by the Lisp compiler, and that certainly helps a lot. But I was
    comparing the equivalent subroutines written with the same algorithms
    and in the same style in Bliss using the JSB linkage and in Lisp
    using our new function calling mechanism.
    
    Our current function calling mechanism is slower than the Bliss/JSB
    linkage (but faster than CALLx), which is why we now have both kinds
    of calls (among other reasons). It would be a lot cleaner not to
    have the two kinds, and I believe it's quite possible.
    
    			---Walter
    

    A VAX/VMS PROLOG being developed uses BLISS for some of the low-level
    things. The reasons for using BLISS were the ability to specify JSB
    linkages and explicit register allocation. However, most of PROLOG is
    written in in PROLOG. So, the total number of lines of BLISS code is
    rather small -- though critical for speed. If VAX Pascal or C had JSB
    linkage and register specification, we would have re-written it all
    into Pascal or C a long time ago... 
    
    -George 

	The DIBOL compiler is written in BLISS, the run-time system is
	in Macro.
	
	Mike (ex-DIBOL compiler developer)

    Re .88:
    
    You use JMP as your linkage?  I can see how that would speed
    up calling, and that it might even work for tail-recursive
    routines, but how do you get back from a routine?  And see the
    answer to .89 below.
    
    Re .89:
    
    VAX Pascal considered adding JSBs and register parameters to the
    language when I was on the project.  I did a study of various calling
    sequences, and found that JSBs are only faster for routines with
    small numbers of locals and small numbers of parameters (on the
    order of 6 or fewer total).  Those routines are also candidates
    for inline expansion (which VAX Pascal does), and the inline expansion
    is a MUCH bigger win.  The inline expansion is also done for recursive
    routines (only unwinds once, though--I'd recommended twice...).
    
    You only lose if you are calling routines which could be expanded
    inlined, but the routines are external and so the compiler does not
    know it can inline expand them.  In those circumstances the ability
    to specify linkages might help.

    					-John Bishop

    RE: .73 and .78 (BLISS Sales)
    
    Your figure of "5 BLISS lincenses per year" is in line with the
    BLISS-16 sales, which is why we are beginning the process of
    retiring it as a product.
    
    As for BLISS-32, you are not very close.  The report in front of
    me is "Preliminary totals for FY'86 License Only Sales".  It
    says that 116 BLISS-32 licenses were sold in FY'86.  BLISS
    definitely does not rank up there with FORTRAN, but it's holding
    its own!  It's considered a "tactical" product - necessary for
    our own use.
    
    Just setting the record a little straighter...
    
        					Joyce Spencer

    Re: .91

>    ...  The inline expansion is also done for recursive
>    routines (only unwinds once, though--I'd recommended twice...).
    
    I've heard this elsewhere also (I think Ada does it).  Again if
    it's not a secret, what sort of scheme do you use to achieve this?
    
    /Jon

    Easy: while building the tree for routine R, when you see a call
    of routine C, check the estimated sizes and locals of the routines
    to see if inlining looks like a win.  If it does, then create a
    bunch of new variables in R, one for each parameter of C and one
    for each local of C. Create assignments to the parameters. Now
    go on building the tree, using C as the input.  When C is done,
    go back to building the tree for R.
    
    Inline expansion at compile-time is sort of like interpreting the
    program at run-time: you have to build "frames" for the variables,
    and so on.
    
    If C=R, then set a flag in the symbol table entry.  If the flag
    is already set, that means a recursive call has already been expanded
    inline, so don't expand.
    
    The scheme depends on having the routine around to build a tree
    from. In VAX Pascal's case, we had a polish-postfix version available.
    The advantage of doing this at tree-building time is that the rest
    of the compilation thinks of this as just more ordinary code, so
    all the cleverness of the compiler is unleashed on it.
    
    				-John Bishop

    Lisp isn't the only one ... the CLU linker does in-line expansion
    to get rid of 'one-line' procedures.  It does that because
    onject-oriented languages tend to have lots of procedures who's
    body is simply 'return <expression>'.
    
    							jch