On 27 September 2012 09:23, Ian East <ian.east@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi folks
Just thought I'd add a reminder of my own proposal for an alternative path to occam-pi, in Honeysuckle. Â(Draft document and past papersÂhere.)
To my mind, the big things missing in occam were :
â Âsymmetry processes in sequence and parallel, with the ability to pass object itself over channel (mobile objects)
This seems an interesting idea for research, but I don't know whether it would lead anywhere useful yet.
Â
Â
â Âadequate support for data abstraction, including dynamic objects like lists and trees
(this means Hoare's (1975) Recursive Data Structures, including invariants, which eliminate the need for explicit pointers)
This is a major problem IMHO that Occam-Pi has and was a motivation for me to spend some time on new ideas.
Â
â Âtransparent support for project modularity, i.e.Âthe use of pre-existing or separately developed code (replacing #USE)
Ditto previous comment.
Â
â Âsupport for bindingÂspecification and design, visual, textual or both Â(guaranteeing refinement)
This is probably desirable in the long term. ÂI'm not optimistic it will happen any time soon. ÂGood tools have often eluded us.
Â
â Âprotection against deadlock via formal static verification (e.g.Âof client/server architecture)
This is also a question of good tools. Definitely desirable but a slightly different topic.
Â
â Â(admittedly a pet vexation) a do-while-do loop, with multiple exits (I use 'em all the time, in pseudocode at least).
Â
Honeysuckle addressed all of these, at least as a proposal. ÂProducing a compiler is somewhat costly, as it adds yet more static verification. Â(I still plan to implement one but that has to wait until I've finished home-educating my two boys â another four years, so it's open to anyone else with an interest.)
It sounds like Occam is the only game on at the moment.
Â
Note that I do notÂshare an enthusiasm for anything else mobile beyond objects. ÂI believe that the model for abstraction represented by a language must be both accessible to a large community, to provide adequate recruitment, and be sufficiently transparent to eliminate as much opportunity for error as possible, even among "black-belt" programmers. ÂIn other words, be a lot more like engineering of hardware, bridges etc. The proportion of students I have encountered who would stand any chance of getting mobile processes and channels right is vanishingly small â even smaller than the proportion who could be trusted with pointers.
I've tinkered with mobile channels and I share your worry that they may prove to be a bit too hard. ÂSimple cases are easy enough, but Occam-Pi allows a whole lot more. ÂStill, I don't have a strong view for or against this at the moment.
I noted this last CPA that the Kent team plan to implement recursive data types. ÂI raised the issue of just how programmability compares with pointers, but was slapped down by Peter. ÂWhile I'm well aware of how one programs lists and trees this way (without pointers), issues still remain. ÂI've just implemented an AVL tree ADT and can't help wondering how I'd do tree rotations without pointers. ÂI think I could do it, but it's certainly unfamiliar, and might be a hard sell to many.
I'll defer to professional computer scientists on this one. ÂCan I naively hope that it's just a matter of applying standard algorithms though?
Â
Lastly, I think we should be well aware of the cost to our mission of allowing the perception that we're in conflict with traditional OOP. ÂIt's certainly the case that there is hostility among some of us, but this is an image we cannot afford, and we have certainly failed to address the biggest weakness in our flagship language, occam â that it does not support the construction of anything more ambitious than a simple record or array, and is therefore unsuitable for a host of applications.
Conflict with OOP may be healthy - Functional Programming proponents are doing this too. ÂWhat would be unhealthy would be to over-emphasise the point to the exclusion of other more positive advantages.
Another area Occam is not making enough clarity in is testing. ÂFirstly, if Occam is to be credible for commercial work, the sequential code must be demonstrably in accord with certain codified expectations. ÂThat's the basis of unit testing. ÂEvery other mainstream language has its JUnit or equivalent.
Secondly, if we're serious about concurrency, we must be serious about how it will be tested. ÂThis is a challenge because we know that deadlock, race, livelock, starvation etc are not provably absent just by testing alone. ÂSurely we can do better than this and come up with clear strategies that ordinary developers can apply. ÂAutomated testing is not sufficient but it is still necessary.
Cheers,
Rick :-)
Â