Re: Occam-Tau - the natural successor to Occam-Pi

On Sep 27, 2012, at 5:38 AM, Rick Beton <rick.beton@xxxxxxxxx> wrote:

<SNIP>

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.

My analogy here is a frontier. Since the 1990s, all trails have led to "California" (i.e. OOP and variants), which is not a value-maximization strategy. Some trails should lead to "Nova Scotia" (a completely different foundation, i.e. resource-oriented programming) just to cover all the territory including tasks for which "California" is a very poor fit. That is our job. Trying to be everything just leads to a complexity explosion --- noticeable in many of the post-occam proposals --- and we trail along at the back of the pack calling "me too!"

Occam's greatest strengths are the hardware-software equivalence and the "black box" process with no side effects except those explicitly specified. This fits well-designed functional programming too (we have Haskell-lovers in our group). We are preserving these strengths by design in Dust, but adding zero-copy resource transmissions, code reusability, finite recursion, type expandability and type inference (if desired). Our design is such that old blocks of code can be used with zero maintenance costs - certainly not the case with any form of OOP, because of deep side effects and the inflexible, separately-coded driver model for hardware interaction. (The last is wider-spread than OOP but does not apply to Transputer occam with its two-priority, i.e. interrupt system).

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.

Please explain the difficulty here. Surely occam is perfect for testing, as long as there are a few extra links or channels lying around. I have even written C in an "occam style" (lots of processes with interconnecting "channels", i.e. sockets, including spares) which specifically permits realistic testing of running units, complete or partial. Only an interrupt-capable, Transputer-occam-like language with high priority can allow true testing of hardware drivers.

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.

This is actually our strongest point, but it is a POLITICAL problem since all of "California" (in my analogy) have solved the problem by hiding their head in the sand, and are not pleased if we remind them of the flaws. Black boxes with known effects are the perfect and only system for testable design (e.g. resistor within alternator within engine within classic car; or standard skyscraper construction). They are also the only way of constructing genuinely reusable code modules (without an army of programmers dedicated to "maintenance"). This is the "Nova Scotia" answer to large projects: not the same, but much better!

I agree that a first step would be to qualify for their definition of "automated testing". But then we lead on to something better.

Larry

Cheers,
Rick :-)

Re: Occam-Tau - the natural successor to Occam-Pi - or is there one already?