I just thought I'd mention that a few hackers including myself are working on Dust, another attempt at extending occam concepts in the direction of usability (not yet developed enough for any presentation). Part of its foundation is my set of design principles (compare www.tjoccam.com/fix.html document tacliwhp.pdf), but other members of the team are focused on usability and expected modern features.
On Sep 27, 2012, at 5:38 AM, Rick Beton <rick.beton@xxxxxxxxx> wrote:
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).
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.
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.