| Hi Ian,
At the last San Diego Hacker Meetup, Trey Hunner expressed enthusiasm for the ideas found in a video called "Inventing on Principle" by Bret Victor (transcript on http://blog.ezyang.com/2012/02/transcript-of-inventing-on-principleb/ ). Trey made the particular point that this involved finding a wrong turn that the rest of the world has made, and fixing it. (You can find this near the end of the transcript, in reference to modes, e.g. paragraph 39:30.)
Trey's love of this in-the-teeth-of-the-culture approach made a lot of sense to me, and I deliberately did NOT bring up the problem, which is that you can't find funding. Perhaps in his youthful enthusiasm he can, or just do it in off hours. The point you make about three people is excellent --- and as to "why there is not more experimentation," the answer is that three people is just beyond what a "Trey Hunner" type of volunteer can deal with using spare time and cash.
The fact that there exists such youthful enthusiasm for doing the right thing --- apparently arising independently of any of our efforts --- is profoundly encouraging. The job of education (or self-education, more likely) is then to provide the tools. And our job is to provide a simple principle; and I think "a language where a software block, a process, is strictly equivalent to an independent hardware unit" is clear and easy to follow. That in my opinion should right the wrong of OOP/driver side-effect-hiding code structure.
Larry
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 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)
|