[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?



Hi Larry

I was once lucky enough to have a brief chat with Tony Hoare about programming languages and why we remain condemned to such poor tools.  I think he was wary of what sounded like cynicism, and responded by citing the "high cost" of maintaining one's own language and tools.  He said at least three people would need to care for these full time.  But this is eminently affordable to many, many organisations, public and private.  So I'm left wondering just why there is not more experimentation.

I believe a particular problem lies in education; you only have to look and see that there are no books about programming per se.  Every last one is bound to some or other language.  The last true programming book of which I'm aware is Wirth's in 1975, when things seem to have just stopped.

I think there is an opportunity to tackle the problem at GCSE level now, with the new GCSE in Computing (OCR), which I think presents a balanced view (Simon Peyton Jones is behind it) and delivers most of the material I'm used to teaching in first year at uni.  If we could build on this at A-Level, and uni, and seek to influence how things develop?

Ian


On 28 Sep 2012, at 16:11, Larry Dickson wrote:

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

On Sep 28, 2012, at 4:19 AM, Ian East <ian.east@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

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)







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