From: MERC::"uunet!WKUVX1.BITNET!MacroMan" 20-APR-1992 20:51:02.00 To: CC: Subj: BLISS vs. C: Which is the better language for VMS? This message contains the text of several personal e-mail messages among Ed Heinrich, Jamie Hanrahan, and me (Hunter) about BLISS vs. C. We're making the comments public now to see what other people think. I'm also cross-posting this to vmsnet.internals and to comp.arch, where a BLISS discussion has been going on the past few days. Our BLISS seminar scheduled for DECUS was cancelled because too few people signed up for it. However, there appears to be a *lot* of interest in BLISS, because 58 people have picked up the BLISS article from my file server (send SEND BLISS-ARTICLE-PS in a mail message to FILESERV@WKUVX1.BITNET) since I announced it the other day. I don't have any idea how many people have picked it up via ftp from ftp.spc.edu ([.MACRO32]). (You must have access to VMS to unpack the PostScript article.) It all started with the following comment that I made to Jamie: HG> For years, DEC HG> said to program in BLISS to protect yourself from machine changes; now that HG> Alpha's coming out, they're saying we should use C. I, for one, loathe C HG> and love writing in BLISS. Hopefully, DEC will start emphasizing BLISS HG> too, and there'll be enough interest to do the seminar in the fall. Ed then sent Jamie the following message: EH> Hunter forwarded this message on to me. Seeing that you are interested in EH> BLISS and that, given your DECUS "relationship", I was wondering if you EH> could formally express a WISH that Digital make BLISS available under EH> Alpha/VMS in a manner similiar to the way that Macro-32 is bundled on a EH> VAX/VMS system. EH> EH> There are people, such as Hunter and I, who really enjoy programming in EH> BLISS, and who listened to DEC years ago when they said that BLISS is EH> portable and will allow you to recompile VMS code under "future" hardware EH> platforms. Now that Alpha is being announced, DEC appears to be saying that, EH> although a LOT of VMS is written in BLISS and 3rd party products are also EH> coded in BLISS, that they aren't sure they want to make BLISS generally EH> available under Alpha. EH> EH> BLISS is the ONLY language that is available, on BOTH VAX and Alpha, to EH> write privileged code in. DEC (Alpha) C will allow access to internal EH> VMS routines, but as you well know, VAX C doesn't. (Unless you want to EH> do funky things things, i.e., fixup CALLS/RET instructions to be JSB/RSB EH> at runtime. I Saw the post about privileged code in C and have seen an EH> example of a program that, at execution time, patches the C CALLS EH> instructions to be JSBs, its UGLY! The JSB pragma only works for routines EH> internal to the module, not for externs so that is USELESS). EH> EH> If DEC would say that BLISS will be bundled w/ Alpha, then we would really EH> have a portable environment that would allow us to keep the SAME source EH> code, conditionalized of course w/ %IF statements, for both VAX and Alpha EH> VMS privileged code. I would appreciate it if you could, in your position EH> of heading up the internals SIG, request that DEC commit to BLISS for the EH> common man. To which Jamie responded: JH> This would be a reasonable project (white paper) for the internals working JH> group. What we need to do is present a case to DEC that establishes that it JH> is in their business interest to do this. Having said all of that, Jamie and I got into discussions of the merits of BLISS vs. C: JH> (Personally, I prefer C's strong typing to Bliss's laissez-faire JH> attitude... There are some nice things in Bliss, but if I'm going to JH> code in a high-level language, I want it to do type checking, JH> including argument checking, for me... also, Bliss's structure JH> definitions are obscure and awkward to say the least, particularly for JH> nested structures.) I responded and Jamie wrote: JH> Now, on to the fun stuff (maybe we should move this to the newsgroup and JH> let others join in): HG> Hmmm. Valid complaints about BLISS, but I find it to be a much more HG> logical language than C. It has many of the same powerful features HG> (multiple assignments in one expression) but isn't nearly as cryptic. JH> I've lost count (already -- and I haven't been working in Bliss that JH> long) of the number of times I've been bitten by one . too many or too JH> few. C would have caught these at compile time! This is *not* a JH> trivial thing to lose. Valid point. More in a minute.... JH> Also re type checking, if I (in C) define ucbptr as a pointer to a JH> struct of type ucb, lo and behold the compiler will not let me move JH> anything that ISN'T a pointer to a ucb into that field. Bliss just JH> doesn't care and will gladly let you shoot yourself in the foot just JH> as easily as Macro will. True. However, that's never been a problem for me in BLISS or MACRO. Having spent most of the last six years writing almost exclusively in MACRO, I'm not used to having to define specific types of structs, etc., so it's not much of a problem for me. One of the big advantages for me of moving from MACRO to BLISS has been the ability to use names like UCB when dealing with specific registers in kernel-mode code (UCB for R5, for example). Just naming variables correctly goes a *long* way toward solving problems that C's type checking enforces. JH> And it is utterly ludicrous to have to write "increment A by one" as JH> JH> A = .A + 1; JH> JH> The . should be required on both sides of the =, or on neither. This JH> is completely opposite to *every* other language I've worked with -- JH> INCLUDING Macro. Well, the dot notation *always* throws people off when they first start using it (it did me). But once you think about it, it all makes sense. Variable names in BLISS *always* refer to the *address* of the data, not the data itself. The "." is used to fetch the value stored at that address. If you wrote A = A + 1; you'd be taking the address A represents (say 200) and incrementing by one, storing it back at 200. To increment the value stored at address 200, the "." is used to fetch that value. BLISS is an expression language. There are no statements; everything has a value. You can choose to ignore that value, but everything has one. This means that the left side of the expression above could have been any sequence that generates a valid address. For example (and I must admit that this starts getting a little confusing until you think about it), you could write: B = A; !Store the address A (200) at B (204) .B = .A + 1; !Increment value at A and store back in A The value of ".B" is the address of A, so .A+1 is stored back in A. This provides for some very flexible programming, though you must be careful (and document stuff like that). JH> Re the problems with structure defs in Bliss, someone told me "yeah, JH> but you can use SDL for structure definitions", to which I replied, "I JH> rest my case". If the language needs another software package to build JH> data definitions for it, then the language is broken! I will agree that BLISS strongly lacks decent structure defs. *If* DEC made SDL available to everyone (by bundling it with VMS!!!), the problem is, I think, solved. BLISS's structure defs are not really any different from MACRO's---using SDL lets you generate the symbols for *both* languages (indeed, all (most?) of the others too). However, BLISS *does* let you define how a STRUCTURE is to be referenced. In essence, it's like writing a macro that lets you make a structure reference any way that is necessary. HG> And, in general, there are fewer ways to accomplish the same thing---seems HG> like C will let you do anything a dozen different ways, leading to HG> confusion when different people work on the same programs. JH> This is just a matter of idioms. After you work with C a little bit JH> you get used to most of the common idioms and they don't bother you JH> any more. Well, maybe you get used to it, but I don't think you should *have* to get used to it. HG> C just doesn't sit well on VMS. Everything seems like a work-around when HG> calling system services and run-time library routines. JH> Nyah. The only problem here is if you use VMS string-handling JH> routines *and* the C RTL. If you stick to all descriptor'd strings, JH> things work just as easily as in Macro or Bliss. True. But that means you can't use the internal string stuff with your descriptored strings (not without messing with adding nulls to the end but not counting them in the length, etc.). JH> otoh, there are lots of nice things re string handling in the C RTL. JH> And I've never found the problems to be that tough to overcome. No, but it's a pain in any case. Now, new things: BLISS's macro facility is more powerful than that of any other language I've ever seen. Virtually everyone who has used BLISS agrees with this. Matt Kirk (kirk@tallis.enet.dec.com) posted in comp.arch: MK> The two things I like about Bliss are the macro facility, which beats MK> the pants off C and most other languages I've tried, and that (at least MK> with the Digital variants) you can write systems level code easily. So MK> some of the code that I would otherwise have had to write in Macro I can MK> write in Bliss. If you've ever seen the source to Matt Madison's MX, you'll know just what you can do with BLISS macros! 8-) To not leave anything out, Matt Kirk also says: MK> Otherwise, I much perfer C++. Bliss is a bit more flexible because you MK> have virtually no requirements as to how you do what you must do, but MK> C++ (or C) provides much more support for what I need to do. Which isn't systems-level (i.e., privileged) programming, I'll venture. The *biggest* reason I prefer BLISS to C is that, with BLISS, you know exactly what you're getting: whatever you tell the compiler to generate. BLISS has no run-time support, so you never have to worry about the compiler generating a call to an external BLISS run-time routine. This is invaluable when trying to write privileged code---with C, you have to make sure you don't make any calls to built-in functions when running in kernel mode (depending on what you call) or at elevated IPL (since you *will* page fault). With BLISS, you never have to worry about external calls generated by the compiler *because it doesn't make any*! The *only* way an external call is made is if you call one of the system service or a VMS run-time library routine (or another external module). The compiler doesn't build in calls to its own run-time library because there isn't one. This gets back to the heart of this discussion: BLISS *is* a better systems programming language under VMS than C because you can write systems-level code in it *without* regard for a compiler's run-time support. The only other language for which this is true is MACRO-32. C lets you do most of it, but you have to be *very* careful (and there are no JSBs, no macros that will elevate IPL for you and acquire spinlocks, etc.). The problem with DEC preaching C for Alpha is that that means you *cannot* write code for VAX VMS that will compile without modification on Alpha VMS, since any calls to system routines (the EXE$ routines, etc.) have to be done via JSB, which C doesn't support. The only thing I've found that BLISS lacks is direct support for JMPs (though the compiler can be fooled into producing them). And BLISS is a GOTO-less language! 8-) Well, I think I'll rest my case for now. Comments from anyone else? Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251