Hi RickOn 27 Sep 2012, at 13:38, Rick Beton wrote: I have to confess to quite limited knowledge of Honeysuckle, Ian. I've embedded some further remarks below. You could download a paper or two on the website, though the language has evolved a little. My apologies for not having a good tutorial put together.
– 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.
fred and Peter have implemented mobile objects via a data type qualifier in their language. I prefer an explicit 'send' and 'acquire' operation, akin to '!' and '? in occam. The only difficulty is in maintaining a guarantee of no access following transmission. (The symmetry is with value- versus reference parameters in Pascal. In Honeysuckle, you can either transit a value or an object between concurrent processes.)
– 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.
At CPA 2012, Peter announced plans (for Fred) to implement this. – transparent support for project modularity, i.e. the use of pre-existing or separately developed code (replacing #USE)
Ditto previous comment.
I've proposed a visual language akin to plumbing, but with a textual equivalent. A program can then statically and incrementally (as it's refined) be verifieda formal refinement of the design. I think software should be engineered, which means a tangible design, before implementation. – 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.
I'm quite confident it can be done. It's just expensive. It needs a grant (which I came close to getting) or commercial backing. Contrary to what most companies think, a private language is economic, given a reasonable scale. It requires (according to a private comment by Tony Hoare) about three fte people of reasonable calibre. The return is in both integrity and productivity. – 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.
I think it's essential to sell concurrent programming widely. Quite sensibly, no-one wants to introduce more sources of serious error. In Honeysuckle, no compilable program should deadlock. No math skills are required to achieve this. Client/server computing is well established. Moving it into programming should not cause an additional obstacle. – (admittedly a pet vexation) a do-while-do loop, with multiple exits (I use 'em all the time, in pseudocode at least). Imitation is the finest flattery… 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.
The problem is resources. It is very tough to get grant funding for core computing, even though (IMHO) it has far the biggest potential return. Crappy software is everywhere now. One can only hope that critical care devices are more reliable than the typical set-top box. 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.
We have not yet successfully sold processes and channels, so going hyperdimensional with them does not seem a great idea to me.
I salute the efforts of the Transterpreter folk, who have added a great little book to their toolset.
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?
I think we need to talk to ML programmers. I am no fan of functional programming, but I think they do this. I confess I have a ML book in front of me I have not read properly. Straight lists and trees should be no problem, but many algorithms associated with data structures depend on pointers. 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. Maybe. I remember the fight that Les Hatton had though. I think he went back to fluid dynamics…
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.
Can't really comment on that, but you might want to look at what Fred and Peter plan in the way of generating CSP which can be tested with FDR. Ian
Ian East Open Channel Publishing Ltd. (Reg. in England, Company Number 6818450)
|