[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Occam-Tau - the natural successor to Occam-Pi - or is there one already?


I agree that component interface syntax is important, to both process and object, and that it should be a part of any language extending occam.  However, I do not think that the standard OOP-world convention is right.  Get and Set 'methods; that do no more than return a value (and add unnecessary lines of code show IMHO that something is very wrong.

The one thing that any occam derivative must maintain is the principle of not adding entities unnecessarily.

I stand by my approach of adding a layer of abstraction which defined a design, i.e. a collection of components and their interconnection, which avoids adding clutter to a program and aids transparency instead.

I strongly believe that the conventional interpretation of OOP is fundamentally flawed and results in the loss of both simplicity and transparency, in the name of dogma, rather than reason.  It must be left behind (preferably buried, without honour).  As Les Hatton observed, it failed to achieve any of its ends and actually decreased productivity and integrity, as he showed.  (And was excommunicated as a consequence.)

David May was rather more explicit in his condemnation.


On 27 Sep 2012, at 22:06, Ruth Ivimey-Cook wrote:


What I would be interested to see would be if a computer languages scientist can bring some of the power and flexibility of, say, the C# Class and Interfaces structures into one language with Occam's parallel constructs. Does that necessarily and automatically break the use of occam as a formal language?
I would definitely stay the hell away from anything that looked like C++, C# or Java, because they have no formal foundation (however hard some try to put one in afterwards).  My philosophy was to build on occam, and try for a solid foundation (in CSP/FDR) where anything differed.

I actually have a good respect for at least the foundations of C#. I don't include Java or C++ as I have far too little experience with Java and C++ is a language that perforce inherited most of the problems of C, such as lack of formalism, and then the standards bodies threw the kitchen sink at it. C# is IMO a well-conceived language that in my experience does what you expect. It does of course suffer from the same OO-based issues as most other OO languages, but the rest is well put together.

What I actually asked was not "lets throw C# into occam" but "can we bring some [elements of] the C# Class and Interface structure into occam. Put another way: "Is it impossible to include any OO element into an occam-like language without breaking the formal basis of the result?"

To my mind, OO has things to offer. For example, many people use classes to model a part of the system, which in an ideal world actually be a process, but there are also very useful abstractions you can do with classes : think of, e.g. creating a data type such as a Point or Rectangle, where you may well want pure functions attached to it and the functions apply whoever is calling.

What I'm saying is that I can see both sides: processes are good, in their place (and their place is a lot more frequent than many programmers realize), but classes are good as well, again, in their place.

At a first glance: could we introduce, in Occam terms:




  point FUNCTION scale(VAL INT s)
    point newp:
      newp[x], newp[y] := x * s, y * s
      RESULT newp

Note that my code here only uses pure functions. As it stands it's pretty useless because you can't initialise x or y, but I'm sure such issues can be resolved.

Would that be so terrible? Have I missed something important?


Software Manager & Engineer
Tel: 01223 414180
Blog: http://www.ivimey.org/blog
LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/ 

Ian East
Open Channel Publishing Ltd.
(Reg. in England, Company Number 6818450)