🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.transputer
Article #118

Re: occam

#118
From: Jan Vorbrueggen
Date: Wed, 12 Aug 1992 10:34
81 lines
3955 bytes
   Elegant tool for expressing parallelism? definitely.
   Elegant tool for expressing everything else? definitely not.

   The Occam syntax leaves a lot to be desired:


Agreed.

   (1) It is not free formatted; I thought the days of counting columns 
       were over.

Actually, I think this is an advantage. Have you ever looked at the PASCAL
source of TeX, as it is produced by Tangle? Incredible what a "freeformatted"
language will allow! Why do you expect any decent development environment
to have a prettyprinter, and people can never agree on the rules to give it?
Why do we actually have bugs _found_ by looking at prettyprinted listings
("ah, damn, I'd thought I'd {opened|closed} thos braces seventeen lines
{before|later}!")? Naa, I'll take the indentations and a decent folding editor
any time  it's even good for my laziness, as a single return saves me all the
BEGINs and ENDs and ;s.

   (2) I fail to see the advantage of having no operator hierarchy or default 
       data types:

       why write this:

	  (1.0 (REAL32) + (2.0 (REAL32) * 3.0 (REAL32)))  4.0 (REAL32)

       and count brackets when all I'm trying to do is:

	  1.0 + 2.0*3.0  4.0

Hmm, yes, the operator hierarchy  I tend to agree with you. On the other
hand, who _can_ remember the hierarchy in C or C++? But a little syntactic
sugar would indeed be nice. But please leave out the default data types. 
Look at the mess you get into when you try to convert a C programme to a 
64 bit architecture  all those constants you forgot to tack an L onto,
for instance. Of course, all those (REAL32) are tiresome, but then you have
those nice VALs...

   (3) Is it really elegant to write this:

	IF
	  var1 < 1.0 (REAL32)
	    SEQ
	      var1 := 2.0 (REAL32)
	      var2 := 2.0 (REAL32)
	  TRUE
	    SKIP

	instead of  If( var1 < 1.0 ) Seq{var1 = 2.0;var2 = 2.0;}

No, it's not elegant, but since when is elegance of consideration when
designing a language :)? But it does give nice formal semantice to the
thing. I think, however, that the default should have been TRUE SKIP instead
of TRUE STOP.

   > On a similar note the TDS, like every new and elegant code managing tool;
   > once one is fluent with it's workings, has its own continually growing set
   > of advantages over traditional editors.

   I think I'll complain about this one too :)

   TDS is not a bad tool; it does have a reasonably good editor and file management
   system. My objection is why?. Who needs a new editor?; I mean just how many 
   ways can you do a cutandpaste operation!. Personally I like to keep the
   option of using any editor I wish (this may ore may not be origami) and I 
   like to have more direct control over the files on my disk. As soon as the 
   toolset came out, I gladly converted away from the TDS.

Actually, I think the control of disk files is what the TDS does best. When
we converted our main Occam programme from TDS to the toolset, a collegue
spent several days of labour (as in GULAG) to produce the makefile. And every
time you add a file to the thing, you start thinking about the dependencies
and what you have to add to the makefile. None of that with the TDS. On the
other hand, developing with multiple authors is that much harder, and some
sensible versioning system would have enhanced the value of the TDS much.

 Jan Vorbrueggen
 jan@neuroinformatik.ruhrunibochum.de
Technical Details
Message-ID: <JAN.92Aug12103429@pallas.neuroinformatik.ruhr-uni-bochum.de>
Path: arc1-ca.pugleaf.net!sparky!uunet!wupost!darwin.sura.net!Sirius.dfn.de!rz.ruhr-uni-bochum.de!jan
References: <2490@news.cerf.net>

Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.transputer
Path: arc1-ca.pugleaf.net!sparky!uunet!wupost!darwin.sura.net!Sirius.dfn.de!rz.ruhr-uni-bochum.de!jan
From: jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Subject: Re: occam
Message-ID: <JAN.92Aug12103429@pallas.neuroinformatik.ruhr-uni-bochum.de>
In-reply-to: jcbhrb@nic.cerf.net's message of 11 Aug 92 20:57:33 GMT
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
References: <2490@news.cerf.net>
Date: 12 Aug 92 10:34:29
Lines: 81