| Ian,
I'm in total agreement with you on OOP, and many standard programmers (ones we meet at the San Diego Hacker Meetup) are coming around to our point of view, especially the language writers. The most annoying thing about OOP is that they have "borrowed" a lot of terms (like "component") which should intuitively apply to our constructs, and abusively redefined them to fit their world of mere namespace manipulations.
What we need to do, I think, is analyze the utility of OOP, or its apparent utility, so that we can provide a substitute (in the economic sense). "Code reuse" is a chimera, but namespace reuse is real, and management likes it, because it makes their task easier, or appears to (e.g. all those official name-strings connected by dots). Ignoring side effects and maintenance overhead makes it easier to plan projects (if not to execute them). The silent side effect is actually essential in spyware and "clicks" which send your information to a concealed third party. More constructively, OOP is the way graphical user interfaces are done: the apparent process-like independence of different "windows" is really a code tangle where anything touches anything.
It might be of interest (in reference to the last point) to figure out how "apps" are done for the iPhone or other trendy devices. But I personally tend to throw up my hands at UI programming and retreat to firmware and algorithms. I think the touchstone, the point we need to defend at all costs, is the in-principle software/hardware equivalence of processes. The beauty of this is that it's nestable, and if absolute remains inviolate no matter how many levels of programming you have, or how widely separated the programmers. Thus, we in the Dust project have devised a way of expressing channel transmission of data references as exchange of data "containers" that could physically be expressed as "sneakernet."
Moving from that foundation, and being open-minded about things like namespace reuse, I think it will prove fairly easy to replicate a lot of the niches that are now occupied by OOP. This would result in programming becoming equivalent in respect of reliability to other kinds of engineering, and the economic value would be immense.
Larry 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)
|