| 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) – 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) – transparent support for project modularity, i.e. the use of pre-existing or separately developed code (replacing #USE) – support for binding specification and design, visual, textual or both (guaranteeing refinement) – protection against deadlock via formal static verification (e.g. of client/server architecture) – (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.) 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 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. 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. Very best Ian On 26 Sep 2012, at 22:55, Rick Beton wrote: Hi friends, Ian East Open Channel Publishing Ltd. (Reg. in England, Company Number 6818450) |