Just my small comment. I am a little bit amased by the discussion thread. In all honesty (and pardon me if I am wrong as I am not an academic) even this occam community seems to be heavily influenced by what is politically correct. (or does that mean: state of the practice ? Fortunately nobody mentioned UML yet). Questions : Has anyone been looiking at Oz ? Has anyone being looking at Erlang ? Has anyone been looking at Oberon ? On the latter I received a rather pragmatic paper from a group in Kiev (Ukraine). Can anyone comment ? ---------------------- FROM : -------------------------- Eric.Verhulst@xxxxxxxxxxxxxxxxxxxxxx Skype me at: ericverhulstskype Mob. +32 477 608339 Systematic Systems Development Methodologies Trustworthy Embedded Components http://www.OpenLicenseSociety.org ----------------------------------------------------------- " "Concept" is a vague concept", L. Wittgenstein -----Original Message----- From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On Behalf Of tjoccam@xxxxxxxxxxx Sent: Friday, June 23, 2006 10:31 PM To: F.R.M.Barnes Cc: java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx Subject: Re: Is OO a deliberate fraud? > > Hi, > > On Wed, Jun 07, 2006 at 11:10:05AM -0700, tjoccam@xxxxxxxxxxx wrote: >> >> We need to go back to scratch, to static non-virtual assembly >> language design, and build all serious design in a higher-level >> language free of OO and other infinite metaphor. Once we control the >> harness, they can use OO if they want for what it is good for: >> manipulating graphic widgets in a GUI. > > I'm not completely convinced that OO is good for this either -- makes > for good reasoning about the system's structure, but I've had issues > with this sort of thing and C++ in the past (Java suffers a bit less > here). Won't bore you with the detail here; for the curious, > http://frmb.org/rapp.html I agree, but I want to leave SOME opening for OO: it's legacy code that needs to be made workable, even in a "dream system" that is robustly founded on process-oriented design. In other words, there will be a way to do it right, IF we control the harness, and IF robust design principles are applied even within the OO domain. For instance, the intuitive notion of a GUI screen as overlaid opaque subscreens needs to be supported by a model that enforces exactly that. > > On language design, we were pondering a while back about an occam-ish > scripting language for bolting systems together. It's currently > incomplete, though there is a bit of a parser and execution engine in > the pipeline. A description of what we were thinking about can be > found at, http://frmb.org/oscript.html I looked at it, and it really looks promising. Be sure and look at the old Inmos toolset ".PGM" files, which are strongly analogous to scripts, and work robustly in both multitasking and multiprocessing. Imagine yourself with total control of both boot and OS. If you want to look at my recent white paper or old papers and programs, let me know; I did get this kind of thing working in DOS with an extension of .BAT files. I am convinced that a clean scripting language is the way to introduce the rest of the world to CSP/occam/process-oriented (i.e. robust) programming. Larry > > > Cheers, > > -- Fred > >
Attachment:
White Paper.zip
Description: Binary data