| Ruth
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.
Ian On 27 Sep 2012, at 22:06, Ruth Ivimey-Cook wrote:
Ian
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:
DATA TYPE point
PRIVATE INT x, y:
INT FUNCTION getX() IS x:
INT FUNCTION getY() IS y:
point FUNCTION scale(VAL INT s)
point newp:
VALOF
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?
Regards
Ruth
--
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)
|