Xref: utzoo comp.arch:20678 alt.folklore.computers:9399 Path: utzoo!utgpu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uunet!maverick.ksu.ksu.edu!unmvax!bbx!yenta!dt From: dt@yenta.alb.nm.us (David B. Thomas) Newsgroups: comp.arch,alt.folklore.computers Subject: JOVIAL (long) Message-ID: <1991Feb7.075425.2264@yenta.alb.nm.us> Date: 7 Feb 91 07:54:25 GMT References: <1665@digi.lonestar.org> <193900.598@timbuk.cray.com> Organization: yenta unix pc, rio rancho, nm Lines: 78 wws@raphael.cray.com (Walter Spector) writes: >I have a few questions on Jovial: > - When was JOVIAL written? > - What were the salient features of Jovial? > - What did it do/not do well? > - What machines was it developed on? and did it run on? > - Why did(/do) the Feds love it so much? > - What other good stories does anyone have? Up until very recently, I was working for a big company -- make that big, slow, stodgy, ungainly bureaucracy -- steeped in computer tradition. All of their business data, to this day, resides on a univac 1100 (vintage 1957.. not a good year for computers) which was set up poorly then, and still does not begin to do what it is capable of. Yes, that's good for a few shudders. They still use paper tape, EBCDIC, ... escuse me... okay, I'm back. Now where was I? Oh! Well, anyway, JOVIAL was one of the very newest and freshest things I got my hands on while I was there. We had to distinct compiler/linker/debugger toolsets (both full of bugs) running on VAXen under VMS. I'll probably get flamed for saying this, but I really liked J's handling of types, both builtin and user-defined. It did pointers and bit fields much more sensibly, but not as flexibly as C. You rode pretty close to the machine, and the structure was formal without being ridiculous. Linking with assembly code was a cinch. Lucky thing, too, since one of our compilers was messed up, in such a way that a "return from interrupt" was impossible to code in jovial. It HAD to be done in assembler. Oh well... most languages don't do that anyway. A nifty conecpt in J is that of a COMPOOL, which is sort of a cross between and .o and a .h file all rolled into one. You declare shared data in it, then compile the compool, and include it at the tops of your other sources. In C, global data must be externally referenced in the .h file, so all the sources know its type, but it must be declared in just one place, another .c file. So if it changes you have to change it in two places. The COMPOOL serves both purposes and allows you to keep exactly one description of each object that both specifies its type and defines/declares/allocates it. An interesting piece of J folklore: NO console i/o. None! Zippo! That really messed me up, since the most natural thing to do in a new language is to write a "hello, world" program. Aaack! I suppose I could have stuffed the bits in i/o registers and pretended that the registers were driving the display unit in an F-16 fighter (I really did work with some J code that might just be helping to delete a few iraqis along about now). If you really HAD to have console i/o there was a way you could link to a fortran object file. Imagine doing all that just to say "hello, world"! One more thing of note ... in C, you always end statements with a semicolon. In pascal, it's a bit trickier. Sometimes you'll mess yourself up with extra ones. In J you REALLY had to watch it. Even in such things as block definitions or the very last statement of a function, an extra semicolon could stop your code from compiling. >In short, what was Jules Schwartz thinking when he wrote >his Own Version of IAL? hahahhaa. Ever use that handy unix tool, Juan's Obsequious Implementation of 'N'? little david -- Computer interfaces and user interfaces are as different as night and 1.